4 ms·
This. There is no need to introduce a new concept like "commit groups" to permeate through everything. Just use merges and display them nicely. The problem is
by exclipy 5y ago
This. There is no need to introduce a new concept like "commit groups" to permeate through everything. Just use merges and display them nicely.
The problem is getting all the visualization tools on the same page.
Bazaar got this right. Their official UI displays a linear history with the ability to expand any merge commit to show the side branch.
https://commons.wikimedia.org/wiki/File:Bazaar_Explorer_-_Log.png https://commons.wikimedia.org/wiki/File:Bazaar_Explorer_-_Lo...
- vertere 5y agoThanks, I did not know that about Bazaar. I wish that were the norm in Git-land. But I can see why people might still desire more explicit constructs to handle history organization. The expectation that the commit graph should be both logical and historical causes a sort of cognitive dissonance, which these sorts of conventions don't fully resolve.
- nixpulvis 5y agoIn your .gitconfig l = log --graph --abbrev-commit --date=relative Im not sure about collapsing history though.
- TomSwirly 5y agoMerges are truly horrible, though. They're a commit with two parents, one of which has no real meaning anymore because it doesn't exist anywhere else. They break a lot of tools because of this.
- ric2b 5y ago> one of which has no real meaning anymore because it doesn't exist anywhere else. What do you mean? That's the feature branch, what's the issue?
- joshka 5y agoThe first parent is (generally) main. The second parent is the last commit of a series of commits starting at a commit, sometime in the past on the main branch, followed by all the new commits that represent the feature that is being merged. Merges are horrible, if you don't have a mental model of git that aligns exactly to the above.