Re: rebase --onto might "loose" commits

[Nicolas Pitre <nico@cam.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1515 bytes --]

On Tue, 19 Feb 2008, Björn Steinbrink wrote:

> Hi,
> 
> On 2008.02.19 11:05:40 +0000, Johannes Schindelin wrote:
> > On Tue, 19 Feb 2008, Björn Steinbrink wrote:
> > 
> > > when there's nothing to rebase (ie. upstream..branch is empty), rebase 
> > > fails to find any commits to rebase and correctly says "Nothing to do", 
> > > but when --onto is given, we already did a "reset --hard" to newbase, so 
> > > it already _did_ something.
> > 
> > Yes, it did something.  But if you had that:
> > 
> > A - B - C - D - E
> >   \
> >     F
> > 
> > your HEAD was E, and you said "git rebase --onto F E" what exactly do you
> > want it to do?  There is no commit between E and E, so it rebases
> > _nothing_ onto F.  Which means that F should be your new state.
> 
> Strictly, it's correct, but the "Nothing to do" message is a bit
> misleading (IMHO) and the error message made me think, that it actually
> didn't want to do anything.

Yes, the message should probably be changed in that case.

> I'm a bit unsure about rebase being degraded to a "reset --hard" in this
> case is a good idea. Might be a nice user-protection to make rebase
> abort when there's nothing to rebase and --onto is given. But I don't
> care that much.

The "reset --hard" in that case is really the correct behavior.  Rebase 
might be used like 'git pull --rebase', and if your local branch 
contains no commits of your own then the 'git reset --hard' is really 
what needs to happen.

The "user protection" lives in the reflog.


Nicolas