0

So I've been experimenting with groups of commits as discussed here -- Is there a way to group commits in Git? and here -- https://news.ycombinator.com/item?id=27722221

Having simple groups of commits by using git merge --no-ff worked, but then I decided to try groups of nested sub-groups, and when I tried to view the result with git log --graph and gitk I got some weird output.

The test repo I'm using is at https://github.com/maratbn/test_nested_sub_groups_of_commits

This repo contains 2 groups of commits, first one for Feature 1 and a second for Feature 2.

Now, the group for Feature 2 itself contains 2 nested sub-groups of commits, one for Feature 2A and another for Feature 2B.

All of the commits themselves are correctly identifying all of their parents and children, and git log --graph seems to work correctly just for the feature2 branch:

$ git log --graph --oneline
*   8e4b5f4 (HEAD -> feature2) Merge branch 'feature2b' into feature2
|\  
| * 0ce0350 (feature2b) Feature 2B commit 3.
| * c935021 Feature 2B commit 2.
| * 0bb1c7d Feature 2B commit 1.
|/  
*   58df7c0 Merge branch 'feature2a' into feature2
|\  
| * 682a2ab (feature2a) Feature 2A commit 3.
| * 0f567b0 Feature 2A commit 2.
| * 77a551a Feature 2A commit 1.
|/              (...here the branch was switched to 'feature2'...)
*   1895612 Merge branch 'feature1' (...into 'master'...)
|\  
| * 3809d12 (feature1) Feature 1, 3rd commit.
| * ed91ea8 This is for feature 1, 2nd commit.
| * ffe515d First commit for feature 1.
|/  
* 228a1ab Added 'test1.txt'.

But after I git merge --no-ff feature2 into master (to create groups themselves having nested sub-groups) same command produces this weird output:

$ git log --graph --oneline

01  *   d6cde88 Merge branch 'feature2'
02  |\  
03  | *   8e4b5f4 (feature2) Merge branch 'feature2b' into feature2
04  | |\  
05  | | * 0ce0350 (feature2b) Feature 2B commit 3.
06  | | * c935021 Feature 2B commit 2.
07  | | * 0bb1c7d Feature 2B commit 1.
08  | |/  
09  | *   58df7c0 Merge branch 'feature2a' into feature2
10  | |\  
11  |/ /  
12  | * 682a2ab (feature2a) Feature 2A commit 3.
13  | * 0f567b0 Feature 2A commit 2.
14  | * 77a551a Feature 2A commit 1.
15  |/              (...here the branch was switched to 'feature2'...)
16  *   1895612 Merge branch 'feature1'
17  |\  
18  | * 3809d12 (feature1) Feature 1, 3rd commit.
19  | * ed91ea8 This is for feature 1, 2nd commit.
20  | * ffe515d First commit for feature 1.
21  |/  
22  * 228a1ab Added 'test1.txt'.

Notice how the commit 58df7c0 is displayed as if it is connected to the master branch even though it was made in the feature2 branch, and commits 77a551a to 682a2ab are displayed as nested off the master branch rather than feature2.

Does this look like a bug with git log --graph?

maratbn
  • 188
  • 1
  • 9
  • What exact version of Git is this? – Matt Jul 04 '21 at 06:36
  • 4
    It looks like you ran the `git log` output through some software that inserted a backslash in front of each asterisk. Other than that, this looks normal enough. The merge into `feature2` is displayed as a commit "on the feature2 mainline", because it *is* such a commit. The three commits below it (all only on "feature2a" initially) are now on "feature2" as well and there's no reason that `git log --graph` sees to indent them more, though if it did so, the display would be easier to eyeball. – torek Jul 04 '21 at 06:58
  • @Matt git version 2.17.1 – maratbn Jul 04 '21 at 18:48
  • 1
    `git` does not keep track of branches ; when a commit is created, there is no information saying "this commit was created when the active branch was `feature2a`". The graph you see is consistent, it displays (correctly) that `77a551a` forked from commit `1895612`, and that the history after that was merged into your current branch at commit `d6cde88`. And all of these commits are now also part of your current branch's history. – LeGEC Jul 04 '21 at 21:17
  • @torek Thanks for noticing the issue with the backslashes, I removed them. Regarding git not having a reason to indent the 3 commits 77a551a, 0f567b0, and 682a2ab it seems to me they should be indented because the commit 58df7c0 was never merged directly into 'master', and is displayed indented. Furthermore, I think it is odd that git rendered connecting links on lines 10 and 11 as there is no actual direct connection to 'master' at that point. – maratbn Jul 05 '21 at 19:12
  • 1
    The display at lines 10-11 shows that the commit at line 9 (`58df7c0 Merge branch 'feature2a' into feature2`) has two parents, namely commits `1895612` (1st parent) and `682a2ab` (2nd parent). `git log` draws the first parent connection as a vertical bar and the 2nd parent connection as a backslash, then takes as many additional lines as are needed to bring the two parent connections down to join the commit or line-leading-to-commit necessary to let you find, by eyeball, the two parents. Line 11's two forward slashes achieve this. – torek Jul 05 '21 at 19:47
  • @torek @LeGEC really appreciate your help explaining the output of `git --graph`! Your comments are the answers to my question. Thank you! I was able to use git "empty" commits as a workaround to the default way git renders graphs to be able to nest and sub-nest groups of commits -- https://github.com/maratbn/test_nested_sub_groups_of_commits/tree/master--w-empty-commits – maratbn Jul 08 '21 at 04:48

0 Answers0