Re: [RFC] git commit --branch

[Martin Waitz <tali@admingilde.org>]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]