Hi, On Tue, 16 Jan 2007, Steven Grimm wrote: > Johannes Schindelin wrote: > > That is correct, but --ignore-if-in-upstream actually tests the hash of the > > _diff_, not of the commit. So, if c really introduces the same change as f > > (i.e. the diffs are identical), git-rebase will ignore f: > > > > a---b---c---d > > \ > > e'---g' > > > > Totally untested, of course. But this is what --ignore-if-in-upstream was > > written for. > > > > Okay, great, that is certainly an improvement over what I thought was > happening. But it won't work if you had to manually resolve a conflict during > the rebase, yes? In that case the diffs would presumably not match. Correct. There is no automatic way any program could verify that such a patch is indeed what is already in upstream. 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. Ciao, Dscho - 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