3 ms·

> Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge

> Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use. The frustrating thing about this is that this "omg minor commits on a merged branch clutter up the log!" is entirely a UI problem created by github's naive view of history where it shows things in a bafflingly obtuse linear order instead of letting you do something like `--first-parent` like the command line client lets you do. Git itself has more than enough tools to give you that 'squashed' view without actually squashing anything, github just has no interest in providing it to you for whatever reason. Also yes to the sibling comment that if you want to make something happen with a commit use `--allow-empty` and not "bump number" or "add random whitespace". Please.

slaymaker1907 5y ago
It would also help if people were better about keeping a clean commit history for PRs. Ideally, a new commit should only get pushed to a branch per change relevant for reviewers. If the CI is causing the error, people should work on a temporary branch and resolve it there first before cherry picking things over into the PR branch (after rebasing the intermediate commits on the temp branch). Rebasing is a really nice tool, though I think the UI is really lacking. A simple GUI for interactive rebasing would help a lot. Most clients I've used (which isn't a ton since I generally prefer the CLI) don't even have an option for rebasing at all.
- gregmac 5y ago
  GitKracken and Fork both have an excellent rebase UI.
- travbrack 5y ago
  Love the sub-branch idea. I'm going to use that.
mwt 5y ago
> github's naive view of history where it shows things in a bafflingly obtuse linear This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear to not-so-linear ...
- rectang 5y ago
  Try this: git log --oneline --graph Seeing the --graph output really helps in understanding the branch history. The lack of a view similar to --graph on Github drives me bananas. I don't like typing "git log --oneline --graph" all the time, so in my profile I have a `git slog` alias which is similar but adds date and author, plus truncates each line at 100 columns so it doesn't wrap: slog = log --pretty=tformat:'%C(bold blue)%h %C(bold red)%ad %C(bold blue)%aN%C(auto)%d %<|(100,trunc)%s%C(reset)' --date=short --graph My terminal has a light background. If you prefer a dark background, I suggest changing "bold blue" to "bold green" and "bold red" to "bold yellow": slog = log --pretty=tformat:'%C(bold green)%h %C(bold yellow)%ad %C(bold green)%aN%C(auto)%d %<|(100,trunc)%s%C(reset)' --date=short --graph
- stormbrew 5y ago
  The obtuse part about github's linear view isn't that it's linear, it's that it's interleaved by time in ways that form a chaotic view even for a linear one. Like, picking a random large project for an example, take a look at swift's history on github[1]. Because there's a bunch of PRs that were being operated on in parallel, and some probably that are even kind of old, the view you wind up with is likely a large streak of "PR merged" commits and then all the commits from those PRs jumbled together in an incoherent mess. Likely you'd have to scroll a few pages to even find some of those PR's commits (Note: git-log also has this as its default order, but you have some choices like --topo-order). That said, I really really recommend you look at git's native --first-parent output, as I mentioned. That is likely the linear history you really want and it's right there in the client. It's the exact same thing as you get from a squashing strategy, except the history isn't gone it's just hidden. I agree that the interactive tree views are chaotic and incoherent in their own ways. I don't use them either. I use --first-parent usually to find what I want and then I might dig in deeper if I need to. But leaving that history there underneath means tools like git bisect can actually work, or if you need to narrow down onto a small change you actually can. [1] https://github.com/apple/swift/commits/main https://github.com/apple/swift/commits/main
  - rectang 5y ago
    I sometimes hack author dates just so that commits show up in the right order in the stupid Github linear view. It doesn't always work (on a big project like Swift it would be a lost cause), but because I care a lot about presenting my work as a sequence of commits optimized for reviewability, I try.

slaymaker1907 5y ago

It would also help if people were better about keeping a clean commit history for PRs. Ideally, a new commit should only get pushed to a branch per change relevant for reviewers. If the CI is causing the error, people should work on a temporary branch and resolve it there first before cherry picking things over into the PR branch (after rebasing the intermediate commits on the temp branch). Rebasing is a really nice tool, though I think the UI is really lacking. A simple GUI for interactive rebasing would help a lot. Most clients I've used (which isn't a ton since I generally prefer the CLI) don't even have an option for rebasing at all.

gregmac 5y ago
GitKracken and Fork both have an excellent rebase UI.
travbrack 5y ago
Love the sub-branch idea. I'm going to use that.

mwt 5y ago

> github's naive view of history where it shows things in a bafflingly obtuse linear This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear to not-so-linear ...

rectang 5y ago
Try this: git log --oneline --graph Seeing the --graph output really helps in understanding the branch history. The lack of a view similar to --graph on Github drives me bananas. I don't like typing "git log --oneline --graph" all the time, so in my profile I have a `git slog` alias which is similar but adds date and author, plus truncates each line at 100 columns so it doesn't wrap: slog = log --pretty=tformat:'%C(bold blue)%h %C(bold red)%ad %C(bold blue)%aN%C(auto)%d %<|(100,trunc)%s%C(reset)' --date=short --graph My terminal has a light background. If you prefer a dark background, I suggest changing "bold blue" to "bold green" and "bold red" to "bold yellow": slog = log --pretty=tformat:'%C(bold green)%h %C(bold yellow)%ad %C(bold green)%aN%C(auto)%d %<|(100,trunc)%s%C(reset)' --date=short --graph
stormbrew 5y ago
The obtuse part about github's linear view isn't that it's linear, it's that it's interleaved by time in ways that form a chaotic view even for a linear one. Like, picking a random large project for an example, take a look at swift's history on github[1]. Because there's a bunch of PRs that were being operated on in parallel, and some probably that are even kind of old, the view you wind up with is likely a large streak of "PR merged" commits and then all the commits from those PRs jumbled together in an incoherent mess. Likely you'd have to scroll a few pages to even find some of those PR's commits (Note: git-log also has this as its default order, but you have some choices like --topo-order). That said, I really really recommend you look at git's native --first-parent output, as I mentioned. That is likely the linear history you really want and it's right there in the client. It's the exact same thing as you get from a squashing strategy, except the history isn't gone it's just hidden. I agree that the interactive tree views are chaotic and incoherent in their own ways. I don't use them either. I use --first-parent usually to find what I want and then I might dig in deeper if I need to. But leaving that history there underneath means tools like git bisect can actually work, or if you need to narrow down onto a small change you actually can. [1] https://github.com/apple/swift/commits/main https://github.com/apple/swift/commits/main
- rectang 5y ago
  I sometimes hack author dates just so that commits show up in the right order in the stupid Github linear view. It doesn't always work (on a big project like Swift it would be a lost cause), but because I care a lot about presenting my work as a sequence of commits optimized for reviewability, I try.