Hi, On Tue, 16 Jan 2007, Jakub Narebski wrote: > 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. > > Then git-rerere would help, I think. AFAICT no. First, git-rerere can only resolve conflicts for which it has seen a conflict resolution. Unlikely here. Worse, the way git-rerere would _have_ to resolve the conflict, a commit would _fail_ (since no change should be committed if a munged version of it was already applied). 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