Junio C Hamano wrote:
"J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
