Re: git log --follow after subtree merge

[Konstantin Khomoutov]

On Wed, May 10, 2017 at 02:15:23PM -0500, Samuel Lijin wrote:

> On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist
>  wrote:
> > Hi,
> >
> > After doing a subtree merge, using 'git log' and 'git log --follow' on
> > files in the subtree show only the merge commit in which they were
> > added.
> >
> > After reading around I understand that the issue is that git log
> > --follow doesn't track renames that occur during a merge.
> 
> Try git log --follow -M. (You may also want to combine this with -l and/or 
> -C).
> 
> > Has there been any work (or are there any plans) to allow git log
> > --follow to work in this case? I couldn't find anything in the mailing
> > list archives aside from a couple of threads from 2011 explaining the
> > issue.

Please note that technicaly there wasn't any "rename during merging":
the subtree merge took the three object of the tip commit you were
merging and recorded in in the merge commit as appearing under another
tree object -- identifying the directory which was used as the subtree
prefix.  The result is that the merge commit and the commits recorded
after it have the files of the merged-in history under that prefix, but
the merged-in history itself has them "as is".

Since Git does not record renames (that is, the `git mv` command does
not record a rename either -- the file it "moves" merely "reappears" in
the next commit under a different name), there are two solutions to your
problem.  The first one is to use the usual heuristics of rename/copy
detection at the time of the history traversal -- as suggested by
Samuel.

The second one -- if you don't need the merged-in history to be kept
"pristine" -- is to first run a `git filter-branch` command on it to
relocate the files in all the reachable commits it contains under the
same prefix which you have used for subtree merge and then do that
subtree merge.

Of course, that only works if that history is "yours" and the merging is
considered to be a one-off operation (that is, you won't be updating the
original merged-in line of development).

Re: git log --follow after subtree merge

[Jeff King]

On Thu, May 11, 2017 at 02:35:49AM -0400, Jeff King wrote:

> > > After doing a subtree merge, using 'git log' and 'git log --follow' on
> > > files in the subtree show only the merge commit in which they were
> > > added.
> > >
> > > After reading around I understand that the issue is that git log
> > > --follow doesn't track renames that occur during a merge.
> > 
> > Try git log --follow -M. (You may also want to combine this with -l and/or 
> > -C).
> 
> You shouldn't need to specify "-M" with --follow, as the diff done by
> try_to_follow_renames() turns on rename (and copy) detection explicitly.
> I suspect the problem is that git-log does not do merge diffs at all by
> default, and you'd need "-c" or "--cc" (or maybe even "-m") to turn them
> on.
> 
> I wouldn't be surprised if there are other problems where that code path
> isn't quite ready to handle merge commits, though.

Hmm. It does seem to work out of the box in a simple example:

  git init repo
  cd repo
  
  seq 100 >one
  git add one
  git commit -m base
  
  echo foo >unrelated
  git add unrelated
  git commit -m unrelated
  
  git checkout -b side HEAD^
  git mv one two
  git commit -m rename
  
  git checkout master
  git merge --no-edit side
  
  git log --oneline --raw --follow two

And it does not seem to need any special diff options like "-c" to
trigger it.

It may be that more complex cases fool it (perhaps history
simplification has an effect, or perhaps it's the old issue that
--follow has a single global idea of the "current" filename, even though
it may be traversing down multiple lines of history).

Jonny, is it possible for you to share the repo that shows the problem?

If not, it might be possible to demonstrate the problem with
"fast-export --anonymize", though I think that won't work if the rename
is accompanied by a change in the same commit (because it anonymizes
away the relationship between two almost-identical files).

-Peff

Re: git log --follow after subtree merge

[Jeff King]

On Wed, May 10, 2017 at 02:15:23PM -0500, Samuel Lijin wrote:

> On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist
>  wrote:
> > Hi,
> >
> > After doing a subtree merge, using 'git log' and 'git log --follow' on
> > files in the subtree show only the merge commit in which they were
> > added.
> >
> > After reading around I understand that the issue is that git log
> > --follow doesn't track renames that occur during a merge.
> 
> Try git log --follow -M. (You may also want to combine this with -l and/or 
> -C).

You shouldn't need to specify "-M" with --follow, as the diff done by
try_to_follow_renames() turns on rename (and copy) detection explicitly.
I suspect the problem is that git-log does not do merge diffs at all by
default, and you'd need "-c" or "--cc" (or maybe even "-m") to turn them
on.

I wouldn't be surprised if there are other problems where that code path
isn't quite ready to handle merge commits, though.

-Peff

Re: git log --follow after subtree merge

[Samuel Lijin]

On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist
 wrote:
> Hi,
>
> After doing a subtree merge, using 'git log' and 'git log --follow' on
> files in the subtree show only the merge commit in which they were
> added.
>
> After reading around I understand that the issue is that git log
> --follow doesn't track renames that occur during a merge.

Try git log --follow -M. (You may also want to combine this with -l and/or -C).

> Has there been any work (or are there any plans) to allow git log
> --follow to work in this case? I couldn't find anything in the mailing
> list archives aside from a couple of threads from 2011 explaining the
> issue.
>
> Thanks,
> J.

git log --follow after subtree merge

[Jonny Gilchrist]

Hi,

After doing a subtree merge, using 'git log' and 'git log --follow' on
files in the subtree show only the merge commit in which they were
added.

After reading around I understand that the issue is that git log
--follow doesn't track renames that occur during a merge.

Has there been any work (or are there any plans) to allow git log
--follow to work in this case? I couldn't find anything in the mailing
list archives aside from a couple of threads from 2011 explaining the
issue.

Thanks,
J.