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

Junio C Hamano [off-list ref] writes:

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 ;)

-- 
Sergei.

Hi,

On Thu, 1 Nov 2007, Sergei Organov wrote:

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), which is why such a 
rare event hit you.

Ciao,
Dscho

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.

"J. Bruce Fields" [off-list ref] writes:

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

quoted

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.

quoted

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.

Ok, so I retract that "rare" comment.

Now, we have established that this is a real problem worth
solving, what's next?

Junio C Hamano wrote:

"J. Bruce Fields" [off-list ref] writes:

quoted

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

quoted

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.

quoted

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.

Ok, so I retract that "rare" comment.

Now, we have established that this is a real problem worth
solving, what's next?

Make "git rebase --skip" skip patches regardless of tree and index state,
but still refuse to *start* with dirty tree or index. That way, there's
no risk of losing anything that can't be re-created unless the user asks
for it.

To be really anal, stash the current mess somewhere, re-apply the same
patch and diff the two states. If they're identical, do "git reset --hard"
and hop to next patch in rebase-series. If they're not, ask user to say
"--force-skip" instead.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Andreas Ericsson [off-list ref] writes:

Junio C Hamano wrote:

quoted

Now, we have established that this is a real problem worth
solving, what's next?

Make "git rebase --skip" skip patches regardless of tree and index state,
but still refuse to *start* with dirty tree or index. That way, there's
no risk of losing anything that can't be re-created unless the user asks
for it.

Sounds like a plan.