----- 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html