From: Andreas Ericsson Date: Fri, 02 Nov 2007 10:13:20 GMT Subject: Re: Newbie: report of first experience with git-rebase. Message-ID: <472AF840.1070609@op5.se> In-Reply-To: <7v8x5hbtvv.fsf@gitster.siamese.dyndns.org> Junio C Hamano wrote: > "J. Bruce Fields" 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