Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state

["SZEDER Gábor" <szeder@ira.uka.de>]

On Wed, Jan 14, 2009 at 04:43:14PM -0800, Junio C Hamano wrote:
> I've always had trouble with the instruction we give for splitting one
> commit into two using the interactive rebase in the documentation, as it
> always had a strong "Huh?" effect on me when it suddenly starts talking
> about doing a "git reset HEAD^"; I suspect your change may improve this
> situation quite a bit.

I think we might want do differentiate editing a commit (modifying
either the commit message or the patch or both) or splitting a commit.

The first is served well with the current 'edit' rebase command IMHO.
I don't really see the point of the additional 'git reset --soft
HEAD^'.

 * If you want to edit the commit message only, then you are
   better off with 'git commit --amend', because it preserves the
   previous commit message.  But with 'git reset --soft HEAD^' and
   'git commit' the commit message is "lost"; you have to use 'git
   commit -c ORIG_HEAD' instead, which is not that straightforward
   (and we don't have completion support for it).

 * If you want to modify the patch, too, then you would have to use
   'git add' anyway, regardless of whether there was a 'git reset
   --soft HEAD^', or not.  The only benefit of that 'reset' I'm seeing
   is that in that case 'git diff --cached' would show all the changes
   that would be committed; without the 'reset' 'git diff --cached
   HEAD^' is needed.

   But I'm not sure whether that benefit would offset the confusion of
   one more rebase command with just slightly different meaning.

For the second we could introduce a new rebase command like 'split',
which would do the same as 'edit' but would also perform that 'git
reset HEAD^' mentioned in the documentation automatically.  Or perhaps
it could be called 'divide', since the 's' abbreviation for 'split' is
already taken by 'squash'.  (Or maybe use capital 'S' for 'split'?
might be confusing...)


Regards,
Gábor