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

On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:

Hi,

On Thu, 1 Nov 2007, Sergei Organov wrote:

quoted

Junio C Hamano [off-list ref] writes:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Wed, 31 Oct 2007, Sergei Organov wrote:

quoted

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.