Re: merging individual files

[Michael J Gruber <git@drmicha.warpmail.net>]

Chris Marshall venit, vidit, dixit 14.08.2009 16:31:
> Michael J Gruber <git <at> drmicha.warpmail.net> writes:
>>> This strikes me as not too bad of a procedure, as long as there is a 
> graceful
>>> way of determining the most recent common ancestor of br1 and master.  
> What's
>>> the simplest way of doing that?
>>>
>>
>> That would be simply git merge-base master br1.
>>
>> BUT: The main problem here is that git is not file based, but
>> revision/commit/tree based. In the above, you're basically losing all
>> the history common_ancestor_commit..br1 which produced br1's version of
>> f1 and f2, in the sense that a git log master will not show that part of
>> the history at all.
> 
> Well put, I agree.  One of the main arguments I am going to use to try to 
> convince my fellows to switch from perforce to git is the usefulness of git 
> blame.  I would be defeating that with my procedure.
> 
>>
>> If it makes sense to change f1 and f2 without changing f3 that probably
>> means that the pertinent commit should have been split. Is it an option
>> for you to rewrite br1's history? That would be the most gittish solution.
> 
> Yes, I like the idea of rewriting br1's history.
> 
> So, given that f1, f2, ..., fn were changed together in one commit X on br1, I 
> want to break f1 and f2 out of X and put them into X', then leave the rest of 
> the f3,...,fn changes in Y'.
> 
> Let's say X was the last commit on br1.  
> 
> What would the commands to do that look like?
> 

If you're on br1, I would:

git rebase -i X^
# change "pick" to "edit" in front of X in the list you get
git checkout X^ -- f3 f4 f5
git commit --amend
git checkout X -- f3 f4 f5
git commit

For the 2nd commit, using the -c option may be beneficial.

Cheers,
Michael