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

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
>> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
>>> 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.
> 
> 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