gitx
gitx copied to clipboard
laullon
merge commit changes not shown
If i select a merge commit that definitively has changes (as verfidied by git show) these changes are not shown.
Your master at f6e69682 plus my changes to make it compile on 10.5/PPC. I have reorganized my fork and rebased all of my changes on your master. You might as well consider my bugfixes.
@laullon: There are indeed some interesting commits in @uhees' master branch, worth cherry-picking in your master.
Basically @uhees' changes to make stuff compile on 10.5 could be omitted, depending on the type of support you intend to provide (I could understand one would prefer sticking with the current OS only, but it can be argued). However, the other commits (bug fixes/feature improvements) are worth including anyhow.
@uhees: Could you provide a "test case" that shows your bug? I'd be satisfied with a set of git commands on a fresh repository that end up advertising the faulty behavior when viewed in GitX (L).
I see a little clearer now that I have looked closer at the git show output. The point ist that diffs which start with
diff --git a/name b/name
are shown, but merge commits (as well as stash commits) begin with
diff --cc name
are not shown. Sadly I have no solution yet.
I've seen this behavior as well, as far back as @pieter's original tree. I don't think this is a regression, at least not a recent one.
@laullon try:
git show 571082a5d01e7db9c1273ff10934f32f1937e9d4
on your repo. What GitX does:
git diff-tree --cc 571082a5d01e7db9c1273ff10934f32f1937e9d4
yields basically the same result, starting with:
571082a5d01e7db9c1273ff10934f32f1937e9d4 diff --cc GLFileView.m index 255af36,a08850f..dcedd3a --- a/GLFileView.m +++ b/GLFileView.m
@laullon I've done it! Please consider to pick my changes. Should I file a pull request, even if I don't want you to pull all changes from my branch?
I just pulled uhees changes, and it makes me realize that perhaps we should treat merges as a special case.
Diffs only make sense against a specific parent commit, and merges have at least two, possibly more. So if the only way to display the change is with a two-way diff, then we should have the option to pick which parent we want the diff to be calculated against.
As it currently stands, it appears to always show the diff using the last listed parent. If we aren't going to give the user the choice of picking which parent to diff against, we should probably be diff'ing against the first parent.
Just my 2¢.
@darconeous
As it currently stands, it appears to always show the diff using the last listed parent. If we aren't going to give the user the choice of picking which parent to diff against, we should probably be diff'ing against the first parent.
With my branch you merged you should see diffs against all parents simultaneously. Should be equivalent to the output of git show on the commit.