On Jan 16, 2007, at 4:49 PM, Jakub Narebski wrote:
Johannes Schindelin wrote:
Usually, however, this results in a conflict which you have to
resolve.
And _you_ do not have a hard time verifying that the patch already
went
in, and you just say "git rebase --skip" and the rebasing will
continue
_without_ having committed the now obsolete patch.
Unfortunately, at least with git 1.4.4.x, not quite. You have to have
index clean to do "git rebase --skip", while usually there would be
conflict when applying patch that is already present some deeper.
I think that is a bug in git-rebase.
Agreed. I tend to "git checkout HEAD -- files" before a "git rebase
--skip" to fix that, although I guess "git reset --hard" would work
just the same. But by saying "--skip" means "these changes are
irrelevant", so it should clean up after itself. It's a definite
usability snafu.
I'd put a simple patch to add the reset to git-merge.sh, but I'm not
sure I understand what --skip is doing in there with a 30 second
peek. Maybe if I get more tuits, I'll do it, but someone more
familiar with it can probably do it much faster (and be more certain
it's the right thing to do).
~~ Brian
-
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