Re: Newbie: report of first experience with git-rebase.

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 1 Nov 2007, Sergei Organov wrote:
> 
> > Junio C Hamano <gitster@pobox.com> writes:
> > 
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > >> On Wed, 31 Oct 2007, Sergei Organov wrote:
> > >>
> > >>> Yes, and that's the problem. Why 'git --continue' didn't just skip this 
> > >>> patch that *already became no-op* after conflict resolution and forced 
> > >>> me to explicitly use 'git --skip' instead?
> > >>
> > >> Isn't that obvious?  To prevent you from accidentally losing a commit.
> > >
> > > In case it is not obvious...
> > >
> > > A rebase conflict resolution that results in emptiness is a
> > > rather rare event (especially because rebase drops upfront the
> > > identical changes from the set of commits to be replayed), but
> > > it does happen.
> > 
> > Funny how 2 of my first 3 commits suffer from this "rather rare event",
> > and it was not Friday, 13 ;)
> 
> They are rare events.  In your case I guess that subtly different versions 
> were _actually_ applied (such as white space fixes),

That's actually pretty common, in my experience.

> which is why such a rare event hit you.

I'm using git to track some changes I submitted to a project that's
mainly text, and that I only get release tarballs of.  On my most recent
rebase all my patches got applied, but the text also got re-wrapped and
re-indented at the same time.  So all but I think one or two of a dozen
patches ended up with a conflict resolution and then --skip.

Which may not be a case git's really intended for--fair enough.  But
I've found it's pretty common in my kernel work too.  Either I'm
rebasing against changes I made myself, or else a maintainer took my
changes but fixed up some minor style problems along the way.

--b.