> Actually, I misread t3410 a great deal. The situation is as follows: > > ... UPSTREAM > \ > ... A - B - C -D > > A is a patch the upstream does not have, B is a patch UPSTREAM has, > and "git diff C^!" (i.e. the diff of C to its first parent) is _also_ > identical to a diff of a merge that is in UPSTREAM. > > Basically, t3410 tests that after "git rebase -i -p UPSTREAM" and leaving > the rebase script as-is, essentially, A and D are cherry-picked on top of > UPSTREAM. Cool--I "knew" that, but could not have articulated the case as succinctly. > > Does this mean you're just getting rid of the code that calls "rev list > > --cherry-pick"? > > Only now do I understand. > > I misread the code for --cherry-pick. For merges, it adds the diff to the > first parent! Ah, so that is how --cherry-pick works--I'd never looked into the patch-id stuff before. Makes sense, both of how it is leveraged by rev-list --cherry-pick and also that it doesn't make sense to only be against the first parent of merges. > So I adapted my code to find the "dropped" merges in > git-rebase--interactive, too, for now, but I guess the proper fix is > something like this: So, if C, as a merge commit, doesn't get a patch id anymore (right?), does that mean that C is included with A and D in the cherry-picking on top of UPSTREAM (because with no patch id it cannot be recognized as a duplicate)? So then C' is an empty-commit? This would be fine, I think, or can you detect that C is a noop somehow without patch ids? Thanks, Stephen -- 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
