Re: Newbie: report of first experience with git-rebase.
- From
Andreas Ericsson <ae@op5.se>
- Date
- Nov 2, 2007, 10:13 UTC
- Message-ID
- <472AF840.1070609@op5.se>
- In-Reply-To
- <7v8x5hbtvv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 23 quoted lines
> "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