6 ms·
I feel like the linear history and rebasing always causes problems. I too like linear history, and feel like the problem is with how git displays its history.
by l72 4y ago
I feel like the linear history and rebasing always causes problems. I too like linear history, and feel like the problem is with how git displays its history.
Before moving to git, we used bazaar (bzr). Merges ALWAYS come in with a merge commit. This makes it linear for when the branch came into master. When you look at the history in bazaar (bzr log), it _only_ shows the merge commit. All of the subcommits are hidden by default, as what is really important is that something was merged.
> - 2022-08-01: Merged feature y
> - 2022-07-25: Merged feature X
> ...
If you need or want to see the subcommits, you can run `bzr log --include-merges`. Unlike git, which still shows a single linear history, bzr instead shows only the commits to master as linear, and then bundles all the subcommits with the merge as a tree, so it looks something like:
> - 2022-08-01: Merged feature y
> + 2022-07-26: Fixed review comments
> + 2022-07-21: Implemented features for y
> + 2022-07-19: Added test to show desired behavior for y
> - 2022-07-25: Merged feature X
> + 2022-07-24: Tidied up code
> + 2022-07-22: Fixed edge case
> + 2022-07-18: Implemented feature x
> ...
This is quite different than `git log --graph` which still shows each commit individually as linear. This to me is much less confusing!
For git, what we do, is we don't rebase merges, we instead just always do a merge commit (We never do fast forwards either, so every feature/bug/task comes in as a merge commit). Then, by default, we only run `git log --first-parent`. This only shows the commits directly into master, which in our case, is always just the merge commit. Because of this, every thing is linear, and it is easy to see exactly what was merged into master and the order. If you want to see the commits that happened in a specific feature branch, then you can look at the log/diff for a specific merge commit. It isn't as nice as bazaar, but to me, makes things much clearer.
Unfortunately, tools like github aren't configureable, and by default, just show the standard `git log`, which to me isn't helpful or useable. This means, we almost always need to drop to the command line.
- WorldMaker 4y agoI also wish tools like GitHub had more `--first-parent` oriented views as an option. On GitHub itself I find it means that I mostly don't use the Commits views on my own repositories. If I require things to be PRed and always use merge commits, the Closed PRs view sorted by time is a much better view of the main branch than the Commits view. (And vice versa, the `git log --first-person` view is the PR log in the command line.)