Re: [RFC] git commit --branch

From: Martin Waitz <tali@admingilde.org>
Date: May 29, 2006, 21:22 UTC
Message-ID: <20060529212249.GF14325@admingilde.org>
In-Reply-To: <20060529204158.GC28538@spearce.org>

hoi :)

On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:

Show 8 quoted lines

> 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 :)

Show 6 quoted lines

> > +		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