hoi :) 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 ;-) But then an operation as important as commit has to be bullet-proof and I don't like to do anything complex in there. In any case, this functionality needs a lot of testing. Any contributions to the test case are welcome :) > > + git update-ref "$onto_branch" $commit2 && > > If this is going into next perhaps you would like to considering adding > the -m flag to your git-update-ref calls and include a log message > in the reflog (if the user has it enabled for the current branch and > the topic branch)? Makes sense. > Also shouldn't this be 'git-update-ref'? Yes, all the rest uses git-*, too. If the move to buildin commands continues at the same speed we may soon be able to remove some "-"s, but it's not time for that yet. -- Martin Waitz - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2.1.8 : 2006-05-30 07:24:28 EST