0

I am currently taking a look at the SWI Prolog git repository (cloned to my local machine).

For this, I display the commit graph using

git log --graph --full-history --all --color \
--pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s"

As well as using gitk

Here is a part of the git log output:

git log output of SWI Prolog git commit graph

If I interprete the above correctly:

  1. There is a branch that ends with the tag "V7.4.1" (red circle around commit df973c8). This branch has become stale as no further work has been done on it. Is this right?
  2. The same branch was fed from the master branch a bit earlier (blue circle around commit 675a4049 coming after 2f745e6). I don't understand the back-and-forth diagonal lines at that point though. Why do they "overshoot"?
  3. If I compare with the output of gitk (output below), the branch ending in tag "V7.4.1" is completely invisible in gitk. There is nothing branching off 2f745e6 ("CLEANUP: allow gcc...") at all (red circle in image below), only the master branch and its next commit, c6b9256, "Updated clib", is displayed. Is there a way to see the "stale" branch, too?

gitk log output of SWI Prolog git commit graph

David Tonhofer
  • 14,559
  • 5
  • 55
  • 51
  • 1
    @msw Given that the OP stated adding `--all` to the `git` command-line arguments, but didn't state adding anything similar to the `gitk` arguments, I don't see any reason for assuming there's any bug in gitk just yet. –  May 21 '17 at 18:05
  • @hvd Ah yes, that simple. I would have assumed there would be a menu item or something. `gitk --all` indeed. The branch becomes apparent. Point 3 solved, thanks! – David Tonhofer May 21 '17 at 18:13

1 Answers1

4

Commits in Git are connected one-way; a commit knows what its parents are and that's it. When git log or gitk display a graph, they have to start reading the graph at a certain point, a branch or tag or commit. And then they can only see the ancestors of that tag. By default, both gitk and git log work this way and start with your current commit.

But you used git log --all. This will start at every branch head and tag and display everything reachable. It'll show you every branch and every tag and all their ancestor commits.

gitk, in contrast, will work from the current commit backwards. You'll only see ancestors of the current commit. v7.4.1 is not an ancestor of the current commit, so it doesn't even know about it.

Compare apples to apples: gitk --all with git log --all and gitk with git log.

There is a branch that ends with the tag "V7.4.1" (red circle around commit df973c8). This branch has become stale as no further work has been done on it. Is this right?

This isn't a branch, it's a tag. Both branches and tags are just labels which point at a commit, but tags are not supposed to move. Tags are intended to mark a single commit, in this case the release of v7.4.1, so they will always be "stale". Don't delete them, they're there so you can find important commits.

The same branch was fed from the master branch a bit earlier (blue circle around commit 675a4049 coming after 2f745e6). I don't understand the back-and-forth diagonal lines at that point though. Why do they "overshoot"?

Branches in Git are literally branches. What you're seeing is Git drawing those branches. But it can't always fit it neatly on the screen, so sometimes they cross. It's like looking down on a highway overpass.

675a4049 is where 2f745e6 and something else further down merged.

Schwern
  • 153,029
  • 25
  • 195
  • 336