Re: [RFC] git commit --branch

From: Shawn Pearce <spearce@spearce.org>
Date: May 29, 2006, 21:35 UTC
Message-ID: <20060529213543.GA29054@spearce.org>
In-Reply-To: <20060529212249.GF14325@admingilde.org>

Martin Waitz <tali@admingilde.org> wrote:

Show 12 quoted lines

> On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:
> > Interesting.  I have been kicking around doing the very same
> > thing myself but just have not gotten around to it.  Its complex,
> > especially if the current HEAD isn't strictly the merge commit
> > between the topic branch and the previous value of HEAD; in that
> > case you may want to replay the commits which are on HEAD but are
> > post the merge commit using a form of git-rebase.  Except you would
> > want to preserve any merges which happened by remerging them rather
> > than simply exporting a massive patch and reapplying it.
> 
> Perhaps something like merge-recursive makes sense, except that
> I have no clue how it works ;-)

merge-recursive isn't the right tool here. Its job is to perform a 3 way merge "quickly" by dealing with file adds, deletes, renames and patch application when a file was modified by both parents.

Now that diff+apply is probably faster than a 3 way merge in
read-tree precisely because it doesn't need to run merge-recursive
I'm starting to look at how we can use apply to do partial
application of a patch and use RCS' diff3 or just drop a reject
file out when a hunk doesn't apply cleanly.

> But then an operation as important as commit has to be bullet-proof
> and I don't like to do anything complex in there.

I agree. But I'd like to see some sort of functionality to automatically handle some common topic branche cases in commit. Of course I consider the current commit tool to already be too complex (like being able to pull the commit message from any random commit).

-- 
Shawn.