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

[Joshua Jensen <jjensen@workspacewhiz.com>]

----- Original Message -----
From: Brian Gernhardt
Date: 10/21/2010 1:39 PM
> On Oct 21, 2010, at 2:47 PM, Joshua Jensen wrote:
>> 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.
> Git stores no per-file metadata.  The closest we come is .gitattributes and .gitignore.
>
>> By comparison, integrates work at a file level in Perforce.  That means I can integrate a file from one branch to another, and parentage is stored such that I can follow the file back through its history.
>>
>> Are there any facilities to do this now?
> Git simply does not have the idea of the history of a file.  Nothing in git will help merge "just a file" from one branch to another.  Either we have merged the two commits or not.
I'm not super interested in per file merging (which is a great concept, 
works well in Perforce, but is irrelevant here).  I merely want to 
preserve the original parentage so facilities like blame (ultimately 
rev-list?) can walk the extended history.  I'm fine even passing in a 
flag.  I do not care in preserving the original parentage for purposes 
of merging.

> You can use git-filter-branch to create a new branch that contains only that single file and only the commits that affected it.  Something like the following (untested):
>
> I would recommend using cherry-pick to pull any further changes to the file across branches (be careful of commits that touch more than that file!).  I think git-filter-branch could be used to keep the one file branch up to date, but that is likely more effort than it's worth.  I would specifically advise against merging the single file branch into both "src" and "dest", as I think any later merge of the two would find these commits as a merge-base.
Thanks for the info.

The problem with using cherry-pick is that the commits in question 
contain more than one file.  Perhaps the individual file should have 
been committed separately, but the damage was long ago done.

git format-patch --stdout HEAD..otherbranch -- the/filename | git 
am           or
git diff HEAD..otherbranch -- the/filename | git apply

Seem to be the appropriate methods of copying the file over with fake 
history or squashed together.

Josh