Martin Waitz <tali@xxxxxxxxxxxxxx> 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. - : 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