Hi! Jeff King <p...@peff.net> wrote: > For the first one, showing all diffs is what I want. For the second, it > only makes sense to for the first parent case, as following other > parents would zig-zag through history.
Lucky you! :) You probably don't need to inspect 9 month old ex-svn branches with sync (i.e. 'trunk'->'feature') merges *-...-*-...-*-...-*-.......-*---trunk \ \ \ \ / *-...-*-...-*-...-*-...-*---feature (Not to forget some funny legacy inter-feature merges.) It's not like `git diff X^2 X` is a big problem, but too much of a copypaste. The other thing that bugs me is that you can easily `git cherry-pick -m 2 X`, but to see the diff that you are going to apply is not that trivial. > But perhaps you have some other use case in mind. In cases like these, I > think it is a good idea to implement the feature, and run with it for a > while, seeing how it can be used. And then if it proves useful, post the > patch to the list describing your experiences. I'll try. BTW, should it be like '-m[=parent]' for consistency, or '-m [parent]' is ok? PS Another idea: '-m parent' makes sence in a normal, 2-branch merge. But what to do in a case of an octopus merge? In a normal case I can treat '-m 2' as 'the diff regarding the second parent', but also as 'the changes contributed by the first parent (plus "evil")'. But with 3 and more branches '-m 3' means 'the changes from 1 and 2'. Would it be possible to get only the contribution from the second or third parent in this case? Yeah, I know, there is `git diff parent1...parent3` etc, but not all the changes from parent3 will always get to the merge commit. -- Mit freundlichen Grüßen, Anatoly Borodin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
