Deleting branches in git causes gitk to go wild

Question

I decided to delete a few branches from a (personal project) repository of mine that were merged into master after confirming on #git that leftover branches aren't really necessary.

However, gitk's visualisation of my repository's history as a result has been completely screwed up.

Basically something like this:

With those branches from commits appearing out of nowhere eventually going back into some other commits up ahead. A merge did not occur at all of the points, and I only had around 5 extra branches.

Is this normal? Is there any fix for this?

Answer 1

Have you tried reloading your display? Sometimes gitk gets a bit confused, but quitting and restarting it, or reloading (File > Reload, or Ctrl-F5) can help it re-draw the history in a more friendly fashion.

edit: Now that I see the repository, I can see what's going on.

It looks like you did some development on master, while also working on some side branches. While you were doing this, you merged master into those side branches several times. gitk displays commits in a list, so it needs a linear ordering of commits. Whenever you have branching history, there are several possible linear orderings you can put that history in. For instance, the following structure:

       /-- c -- e --\
a -- b               g -- h
       \-- d -- f --/

Could be ordered an any of the following ways:

1. a, b, c, e, d, f, g, h
2. a, b, c, d, e, f, g, h
3. a, b, c, d, f, e, g, h
4. a, b, d, c, e, f, g, h
5. a, b, d, c, f, e, g, h
6. a, b, d, f, c, e, g, h

By default, gitk uses a topological ordering, which tries to group together commits on each branch, so you can see a logical progression of commits for each branch, rather than commits of each side of the branch interspersed based on when they happened. So, for instance, it might display them in ordering (1):

a -- b -- c -- e ------------ g -- h
       \----------- d -- f --/

This ordering works fine if you're just looking at a linear log, and also works fine in gitk if you don't merge between the branches very often (as in the example given). But if you do what you did, merging master into the topic branches frequently, then this produces the kind of mess that you're seeing; the commits on master are shown first, then the commits on the side branches, but the frequent merging of master into the side branches become the long connections that pile up and make the history look confusing. (Note that Git doesn't actually store which commits came from which branch, but the way it sorts them it winds up keeping the commits from each branch together, it appears).

The easiest way to deal with this that I know of is just to display commits in gitk in chronological order. Open View > Edit view..., and check the Strictly sort by date option. Now you should see your history displayed much more sanely. To launch directly into this view, you can pass the --date-order option into gitk.

Answer 2

A branch is only when you have different heads pointing from root (like in tree), not when you have n-lines going back to main branch (merged ranch is not really different from branch it was merged to). Check gitk --all to see all branches you have in repository (as colour labels pointing at head of each branch). And check carefully merge points which gitk shows you, if those have two parents, then they're real merges. git log --graph can help you to see that it's not issue of gitk.

Answer 3

I don't know what your history looks like, but something to keep in mind: deleting merged branches only deletes the names (refs), not the commits, nor any part of the history.

So tools that visualize history will still show all the branching that has occurred in the past.