Re: merging individual files

From: Chris Marshall <christopher.marshall@merchantlink.com>
Date: Aug 14, 2009, 14:31 UTC
Message-ID: <loom.20090814T135614-375@post.gmane.org>
In-Reply-To: <4A851887.5010701@drmicha.warpmail.net>

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

Show 10 quoted lines

> > 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?