repositories that contain 2 un-merged, unrelated histories. In doing so, I've often found
myself confused or mistaken due to the way "git-log --oneline --graph" handles
unrelated histories: by presenting them as if they were one continuous string of
commits.
To create an example of how git-log --oneline --graph presents unmerged
unrelated histories, let us use the following minimal reproducible example.
In ~/repos/git-history-1:
* dec7d4c (HEAD -> main, origin/main) History 1 - Add README.md
* 3f25318 History 1 - Add gitignore
In ~/repos/git-history-2:
* (HEAD -> main2, origin/main2) e5698bf History 2 - Add SECURITY.md
* 7260dff History 2 - Add .gitattributes
If both are pushed to ~/git-history-origin, that repo's log (git-log --graph)
looks like:
[...]
| Add SECURITY.md
|
* commit 7260dff47ffb6233b5f7ccfd62a1be29047d813d
Author: Josh Brunton <josh.brunton@xxxxxxxxx>
Date: Tue Dec 3 09:57:43 2024 +0000
Add .gitattributes
* commit dec7d4cab044e37dd340b487a4d1d8b8b0cac867 (HEAD -> main)
| Author: Josh Brunton <josh.brunton@xxxxxxxxx>
| Date: Tue Dec 3 09:55:50 2024 +0000
[...]
There is a clear disconnect between commits dec7d4c 7260dff, showing that
they represent 2 unrelated histories. However, passing --oneline as well produces
the following output:
* e5698bf (main2) History 2 - Add SECURITY.md
* 7260dff History 2 - Add .gitattributes
* dec7d4c (HEAD -> main) History 1 - Add README.md
* 3f25318 History 1 - Add gitignore
With this graph, one might be forgiven for the assumption that dec7d4c is the
parent of 7260dff, as it would be visually indistinguishable if that were the case
and is far more likely than having 2 unmerged, unrelated histories. This can lead
to some confusion and/or bad assumptions about the history.
It is not until we merge the 2 histories that git log --oneline --graph shows
any indication at all that those histories were unrelated:
* 15177d2 (HEAD -> main) Merge branch 'main2'
|\
| * e5698bf (main2) History 2 - Add SECURITY.md
| * 7260dff History 2 - Add .gitattributes
* dec7d4c History 1 - Add README.md
* 3f25318 History 1 - Add gitignore
I therefore suggest that a separator line (perhaps a blank line) might be
added between unrelated histories which would otherwise seem related in --oneline
--graph. In other words, the separator should appear between any 2 consecutive lines
where * appears in the same column, where the above line's commit has no parent(s).
I believe unrelated histories are clearly represented in other cases.
I have considered that doing so may require that each commit in the log would
have to undergo an additional check to see if it has any ancestors. Though I am
not knowledgeable on how resource-heavy this operation would be, I am wary that
it may pose a significant performance impact. Thus, I suggest that this feature
might be opt-in via a config setting named along the lines of
log.delimitUnrelatedHistories.
In implementing this proposal, the above unrelated histories would become:
* e5698bf (main2) History 2 - Add SECURITY.md
* 7260dff History 2 - Add .gitattributes
* dec7d4c (HEAD -> main) History 1 - Add README.md
* 3f25318 History 1 - Add gitignore
While if some other factor were to create the same effect of clarifying that
the histories are unrelated, the output would remain unchanged:
* e5698bf (main2) History 2 - Add SECURITY.md
| * 3c3cade (branch3) Add CODEOWNERS
* | 7260dff History 2 - Add .gitattributes
|
* / dec7d4c (HEAD -> main) History 1 - Add README.md
|/
* 3f25318 History 1 - Add gitignore
Depending on approval here, I am prepared to attempt to implement this
feature myself, though would appreciate input from those more knowledgeable about the
git codebase and experienced with contributing.Attachment:
publickey - josh.brunton@proton.me - 0x4DBFDC41.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
