Re: rebase --continue confusion

[Eli Barzilay <eli@barzilay.org>]

On Jun  6, Jeff King wrote:
> On Sun, Jun 06, 2010 at 06:32:58PM -0400, Eli Barzilay wrote:
> 
> > > >   $ git add foo
> > > >   $ git status -s
> > > >   M  foo
> > > >   $ git commit --amend foo
> > > >   # On branch master
> > > >   # No changes
> > > >   $ git status -s
> > > >   M  foo
> > > 
> > > I'm confused. Is there some context for when you are issuing these
> > > commands?  Because the "git commit --amend foo" should actually
> > > commit foo, and does for me.
> > 
> > Heh, in that case it was more effective than I thought...  My point in
> > the previous posts was also about missing information (in that case,
> > make `git add' tell you when adding it canceled previously added
> > changes, and also make `git status' tell you if you're in the middle
> > of a merge or rebase and in a clean state).
> > 
> > In any case, here's the prelude to the above:
> > 
> >   $ mkdir t; cd t; git init
> >   $ echo foo > foo; git add foo; git commit -m foo
> >   $ echo bar > foo; git commit -o foo -m bar
> >   $ echo foo > foo
> 
> Ah, I see. Your problem has nothing to do with explicit pathnames (which
> I thought was the interesting bit from your snippet), but rather that
> you are amending it to the same as HEAD^.

Yes.


> Probably it would be helpful in the case of an amend to indicate
> what has happened (you have no changes, but it is not immediately
> obvious that you have no changes against HEAD^, not HEAD). We could
> even suggest "git reset HEAD^", which is probably what you want (the
> only other thing you could want is to create a commit with no
> changes, which we generally try to avoid).

Yes, that sounds reasonable.  (When I realized what happened I
wondered why it didn't do the reset itself, but that would obviously
be a bad idea.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!