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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Oct 22, 2010, 06:35 UTC
Message-ID: <4CC130A5.6050802@viscovery.net>
In-Reply-To: <4CC08AA5.8070502@workspacewhiz.com>

Am 10/21/2010 20:47, schrieb Joshua Jensen:

Show 8 quoted lines

> 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