51–60 of 185 posts
Earlier quoted context omitted.
If you really want just one commit on your PR you can reset your branch to its target before you merge: git reset --soft Which will undo all commits and leave all modified files in the staging area. Then you can make one commit and force push it to replace your branch @ remote.
Or just git rebase -i like normal people.
I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.
Writing a good commit message within those constraints is kind of like writing a haiku. It's kind of entertaining sometimes, though I think it should be a suggestion rather than a rule.
Earlier quoted context omitted.
> 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…
> 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…
git log --oneline --graph
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 % slog = log --pretty=tformat:'%C(bold green)%h %C(bold yellow)%ad %C(bold green)%aN%C(auto)%d %Earlier quoted context omitted.
> 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…
> 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…
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.
Earlier quoted context omitted.
Or just git rebase -i like normal people.
Not sure why downvoted, this is the "correct" way. Can also do --autosquash etc. at the same time.
Earlier quoted context omitted.
> 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…
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…
I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like feat: support new line chart fix: update props for new line chart chore: bump dependency version What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore…
[1] https://github.com/github-changelog-generator/github-changel...
Earlier quoted context omitted.
> 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…
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 str…
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.
I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…