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

From: Joshua Jensen <jjensen@workspacewhiz.com>
Date: Oct 21, 2010, 20:06 UTC
Message-ID: <4CC09D40.4050303@workspacewhiz.com>
In-Reply-To: <9089D1F5-A19B-4030-A6ED-463F250E450B@gernhardtsoftware.com>

----- Original Message -----
From: Brian Gernhardt
Date: 10/21/2010 1:39 PM

Show 10 quoted lines

> 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