Removing branches in git causes gitk to become wild

Question

I decided to remove several branches from my (personal project) repository, which were merged with master after confirming with #git that the remaining branches were not needed.

However, the visualization of my gitk repository history was completely corrupted.

Basically something like this:

With these branches, the commits appearing out of nowhere eventually return to the other commits ahead. The merge did not happen at all points, and I only had about 5 additional branches.

This is normal? Is there any solution for this?

Answer 1

Did you try to restart your display? Sometimes gitk gets a little confused, but shutting down and rebooting or rebooting ( File > Refresh , or Ctrl - F5 ) can help redraw the stories in a more friendly way.

edit : now that i see the repository i see what happens.

It looks like you did some development on the wizard, and also worked on some side branches. While you were doing this, you merged master into these side branches several times. gitk displays the commits in the list, so it needs a linear commit order. Whenever you have a branch history, there are several possible linear orders in which you can put this history. For example, the following structure:

  /-- c -- e --\ a -- bg -- h \-- d -- f --/ 

Any of the following methods can be ordered:

• a, b, c, e, d, f, g, h
• a, b, c, d, e, f, g, h
• a, b, c, d, f, e, g, h
• a, b, d, c, e, f, g, h
• a, b, d, c, f, e, g, h
• a, b, d, f, c, e, g, h

By default, gitk uses a topological ordering that tries to group together, commits each branch so you can see the logical progression of the commit for each branch, not the commits of each side of the branch interspersed depending on when they happened. So, for example, it can display them in order (1):

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

This ordering works just fine if you just look at a linear log, and also works great on gitk if you don't merge between branches very often (as in the example above). But if you do what you do, often merge master into topic branches, then this creates the mess you see; first, commits to the master are performed, then commits to the side branches, but the frequent merging of master into the side branches becomes long bonds that accumulate and make the story confusing. (Note that Git does not actually store which commits came from which branch, but as it sorts them, it finishes saving commits from each branch, appears).

The easiest way to handle this that I know of is to simply show the commits in gitk in chronological order. Go to View > Change View ... and select the Strictly sort by date check box. You should now see that your story looks much healthier. To run directly into this view, you can pass the --date-order parameter to gitk .

Answer 2

I don’t know what your story looks like, but there is something to keep in mind: deleting merged branches only removes names (refs), not commits or any part of the story.

Thus, history visualization tools will still display all branching that occurred in the past.

Answer 3

Branching occurs only when you have different heads pointing from root (for example, in a tree), and not when you have n-lines returning to the main branch (a joined ranch is not much different from the branch into which it was joined) . Check out gitk --all to see all the branches that you have in the repository (as color shortcuts pointing to the head of each branch). And carefully check the merge points that gitk shows you, if they have two parents, then they are real merges. git log --graph can help you see that it does not produce gitk.