performance - Git Extensions takes over 1.5 minutes to show a diff of a merge commit due to the diff with parent feature

07
2014-07
  • Coder

    Git Extensions diff is slow when looking at the diff of a merge commit between two branches that have significantly diverged due to the diff with parent being shown. The diff with parent was added a few versions ago and has significantly degraded the performance of git extensions.

    The diff with parent used to only show the diff on the current branch only for merges, now it shows the current branch and the diff with the other branch (part of a merge). The problem is that almost every file was modified in the repository between the two branches, and displaying the diff with the other parent takes about 1.5 minutes or more.

    Either of the following solutions would be acceptable: -improve the performance of the diff with the second parent to reasonable levels (say 10 seconds) -disable the diff with the second parent all together.

    I am using Git Extensions 2.47.3 on Windows 7 using 1.8.5.2.msysgit (but it was the same issue with other versions of git as well). The slowdown happened when the git diff in Git Extensions was changed to show the diff with both parents instead of just the one as it used to (this happened a few versions ago).

    • Answers
    Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

    Related Question

    git rewrite commit parent?
  • IttayD

    I have two commits based on some parent: P -> A -> B

    I'd like for them to be based on another parent: P' -> A' -> B'

    EDIT: My situation is that I'm working with other team members. We have a central git repository. In my configuration, 'git pull' does rebase while for the others it creates a merge. Every now and then, when I issue 'git pull', git starts rebasing commits that I didn't do and I need to resolve conflicts for code I didn't write. This is long and error prone.

    I assume the reason is that something similar to this happens:

            /--A--B---- // my repository
       /
--C1--C2--------M-  // the remote
   \   M       /
    \-D-M'-E--/     // another developer

    So a developer merges C2 and then pushes his changes which makes git think some commits are new (my guess only). What I end up with is having to rebase other people commits.


    • Related Answers
  • Jawa

    Let's assume this as the situation:

            A---B (topic1)
       /
...---P---C---D (topic2)

    If your current branch is 'topic1', you can move commits A and B into topic2 branch by issuing git rebase topic1 topic2. Then the repo graph would look like

                    A'--B' (topic1)
               /
...---P---C---D (topic2)

    where commit D is what you considered as P'. Note, that the new parent commit needn't to be changed.

    Or, more generally, if you need to move some commit(s) as descendant(s) of any commit (not necessarily the head of branch), you can use --onto parameter:

             A---B (topic1)
        /
...Q---P---C---D (topic2)

    git rebase --onto topic2~3 topic1~2 topic1 or git rebase --onto Q P topic1 where Q and P are commits' SHA1s.

         A'--B' (topic1)
    /
...Q---P---C---D (topic2)

    If these weren't what you intended, care to explain your situation a bit more?