Re: [RFC] git commit --branch

[Shawn Pearce <spearce@spearce.org>]

Martin Waitz <tali@admingilde.org> wrote:
> 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.