threads / discuss / 52739

git log FILE vs git log --follow FILE missing commits

Subject: git log FILE vs git log --follow FILE missing commits

## tl;dr

3 messages between Feb 2, 2020 and Feb 2, 2020.

replies: 2people: 2as markdown or json

Chris Packham· Feb 2, 2020, 21:27 UTC · lore

Hi,

I've just hit a problem where git log doesn't want to tell me about a commit that touches a specific file.

I wanted to point someone at a particular change that I knew was made to a file so I fired up 'git log FILE' and to my surprise it wasn't listed. I wondered if I had remembered wrong so went grepping to confirm the change was in the file I thought it was, sure enough it was there.

Poking around a bit I found that git log --follow FILE shows the intended commit but git log FILE doesn't (it does show other commits that touch the file, most of which have tags if that's significant). The file hasn't been renamed so I didn't really expect --follow to change any behavior.

The version of git I'm using is 2.25.0 from http://ppa.launchpad.net/git-core/ppa/ubuntu bionic main. I also tried 2.24.1 and 2.23.1 with the same problem.

Any suggestions for tracking this down?

Thanks, Chris

Kevin Daudt· Feb 2, 2020, 21:42 UTC · re: Chris Packham · lore

Re: git log FILE vs git log --follow FILE missing commits

On Mon, Feb 03, 2020 at 10:27:52AM +1300, Chris Packham wrote:

Show 25 quoted lines

> Hi,
> 
> I've just hit a problem where git log doesn't want to tell me about a
> commit that touches a specific file.
> 
> I wanted to point someone at a particular change that I knew was made
> to a file so I fired up 'git log FILE' and to my surprise it wasn't
> listed. I wondered if I had remembered wrong so went grepping to
> confirm the change was in the file I thought it was, sure enough it
> was there.
> 
> Poking around a bit I found that git log --follow FILE shows the
> intended commit but git log FILE doesn't (it does show other commits
> that touch the file, most of which have tags if that's significant).
> The file hasn't been renamed so I didn't really expect --follow to
> change any behavior.
> 
> The version of git I'm using is 2.25.0 from
> http://ppa.launchpad.net/git-core/ppa/ubuntu bionic main. I also tried
> 2.24.1 and 2.23.1 with the same problem.
> 
> Any suggestions for tracking this down?
> 
> Thanks,
> Chris

Hey Chris,

Try `git log --full-history FILE`. When passing a path to `git log` will enable history simplification, which might explain why certain commits are not shown.

Kind regards, Kevin.

Chris Packham· Feb 2, 2020, 21:53 UTC · re: Kevin Daudt · lore

Re: git log FILE vs git log --follow FILE missing commits

On Mon, Feb 3, 2020 at 10:42 AM Kevin Daudt <me@ikke.info> wrote:

Show 35 quoted lines

>
> On Mon, Feb 03, 2020 at 10:27:52AM +1300, Chris Packham wrote:
> > Hi,
> >
> > I've just hit a problem where git log doesn't want to tell me about a
> > commit that touches a specific file.
> >
> > I wanted to point someone at a particular change that I knew was made
> > to a file so I fired up 'git log FILE' and to my surprise it wasn't
> > listed. I wondered if I had remembered wrong so went grepping to
> > confirm the change was in the file I thought it was, sure enough it
> > was there.
> >
> > Poking around a bit I found that git log --follow FILE shows the
> > intended commit but git log FILE doesn't (it does show other commits
> > that touch the file, most of which have tags if that's significant).
> > The file hasn't been renamed so I didn't really expect --follow to
> > change any behavior.
> >
> > The version of git I'm using is 2.25.0 from
> > http://ppa.launchpad.net/git-core/ppa/ubuntu bionic main. I also tried
> > 2.24.1 and 2.23.1 with the same problem.
> >
> > Any suggestions for tracking this down?
> >
> > Thanks,
> > Chris
>
> Hey Chris,
>
> Try `git log --full-history FILE`. When passing a path to `git log` will
> enable history simplification, which might explain why certain commits
> are not shown.
>
> Kind regards, Kevin.

Yes that shows the commit in question.

Based on the description of the default mode that actually makes sense. The change in question was a removal, but there was a merge of another branch that never contained the code that was removed. So the simplest history involves commits from the branch that never contained the change I was after.