Re: Following history of a copied file from another indirect branch

[Johannes Sixt <j.sixt@viscovery.net>]

Am 10/21/2010 20:47, schrieb Joshua Jensen:
> It has become a necessity to copy a file from one long-lived branch to
> another.  It is not possible to merge the branches at this time.
> 
> I would like to have 'git gui blame' follow the copy back through its
> original history, but I don't believe Git has metadata for storing this. 
> Something along the lines of a 'followparent' in the commit object, for
> instance, would allow the revision walking code to wander the history down
> an alternate line.

You can branch off one commit form that long-lived branch that undoes
everything except the file F you are interested in since the last
merge-base. Then you merge that single commit into the other branch.

   ---o--o--B     <- long-lived
     /  /    \
    /  /      U   <- the-file
   /  /        \
 -o--A----------M <- master (the other branch)

i.e. 'git diff A..B' shows a lot of changes, but 'git diff A..U' shows
only changes to the file you are interested in. 'git diff -R B..U' differs
from 'git diff A..B' only in the changes to the file you are intersted in.

When you later find that you need new changes to F that were made on
long-lived, but you still cannot merge long-lived, then you can merge
long-lived into the-file (resolve conflicts by removing the conflicted
files and also remove newly added files), and then you merge the-file into
master again.

WARNING: When you later merge long-lived into master, the merge will lose
all changes made on long-lived. You work it around by temporarily grafting
away the merge parents that point to commits listed by
long-lived..the-file. After you complete the merge, you can remove the
grafts again.

-- Hannes