> Do I want every PR to be a long ugly list of trivial half-done commits with messages like “fix typo” or “partial checkpoint of encabulator functionality”? No. Does everything need to be hammered down into a single wad? Also no. There is a middle ground and people should be trusted to find it, and even to have their own opinion on where it is.
IMO `git merge --squash` was perhaps a cultural mistake. Few people use that command but the apparent cultural impact seems to have been great (if that was where it came from).
GitHub squash is a bullet list of all the commit messages. That’s just inviting a ball of mud changelist[1]. But because of the all too convenient "squash" shorthand we now have to explain every time: Yes, there is a middle ground between having one monolithic commit and keeping every little trivial checkpoint and correction.
[1]: The change: the diff. The list: try to correlate each bullet point with something in the diff. (In cases where that applies, some things will have been done and undone and won’t show up in the diff.)
> Might as well squash as nobody wants to deal with untested in-between crap.
I would rather deal with nice and tidy but untested commits rather than a very well-tested but too monolithic squash. If you test the eventual merge then you have done no less testing than the squash case.
I found a bug in a OSS program where an entry contained a gibberish string. This was C so apparently it was some not-properly initialized variable. I couldn’t hope to trace down where that occurred. But with time to write a bisect script and half an hour to run the bisect session I was able to find the commit.
There’s plenty of data which is extra-commit (doesn’t belong in the commit messages but is relevant). Like if the tests passed[1], manual testing notes, iteration on code review, notes for code spelunking when you find a problematic 6+ month old commit.
Yeah but GIT notes are not the best tool for that unless you are single dev working on your project or you have team of only devs.
If you have manual testers they have their own set of tools and most of them don’t use or have working knowledge of GIT.
For code reviews everyone is using PRs and it is not because they don’t know about GIT notes but because no one is doing reviews per commit and there is no support for discussion and other tools that are baked in forges PR flows.
You can always use git notes for yourself but it is as I called it gimmick feature. I can make a bet you will use it for a week maybe couple weeks and then just stop because in description it sounds good but in practice - no one is using it.
> You can always use git notes for yourself but it is as I called it gimmick feature. I can make a bet you will use it for a week maybe couple weeks and then just stop because in description it sounds good but in practice - no one is using it.
There are many uses for Git notes even though you might use a project management tool. Particularly all those things which are relevant for developers only, or that the developers can use as the data source for "higher-level" goals.
By default no copying will be done. While `notes.rewrite.amend` and `notes.rewrite.rebase` are true you also need `notes.rewriteRef` which tells it what notes refs should be rewritten. And it has no value by default. (you can set it to a glob copy over all notes refs)
I use Git Notes all the time. It doesn’t look like the article mentions that you can attach the notes to emails you send out with git-format-patch(1) and git-send-email(1). I use them for emails to attach comments on patches that shouldn’t go into the commit message:
I did <insert research notes> and found no other places in the code base where this needs to be fixed.
And as the cover letter for a single patch (if needed/not cowered by the commit message).
And also like a commit message on the iterations on the patches. So for a patch series that go over three versions the note may say what updates where done in versions 2 and 3.
And other than that I use notes for:
- Private notes on how I’ve manually tested the commit
- Link to CI
- A localized changelog for customers (who are not technical)
awesome to see a user in the wild! if you weren't aware, you can publish your git-bug issues to the project's issue tracker, assuming that it's on one of the supported bridges today (github, gitlab, jira).
the bridges exist within git-bug to support adoption of the tool and interop with existing platforms.
`git bug bridge pull` and `git bug bridge push` use the bridge's API, and don't attempt to pull from or push to the git remote.
hrm... what's your current workflow like? if there's anything you think git-bug could be doing to make that workflow easier, would you mind hopping in our matrix channel [1], or opening an issue [2]?
I create issues for myself. I sometimes create branches with informal issue keys like `<three letters>-<incrementing number>`. I use `git bug webui` to type edit issues. That’s it.
All I would like as a nice-to-have is support for making those issue keys that I use automatic. For me it’s all local to me so it doesn’t need to be globally unique. But those N-letter prefix does make collision less likely on a single project. I’ve mentioned it here: https://github.com/git-bug/git-bug/issues/75#issuecomment-19...
IMO `git merge --squash` was perhaps a cultural mistake. Few people use that command but the apparent cultural impact seems to have been great (if that was where it came from).
GitHub squash is a bullet list of all the commit messages. That’s just inviting a ball of mud changelist[1]. But because of the all too convenient "squash" shorthand we now have to explain every time: Yes, there is a middle ground between having one monolithic commit and keeping every little trivial checkpoint and correction.
[1]: The change: the diff. The list: try to correlate each bullet point with something in the diff. (In cases where that applies, some things will have been done and undone and won’t show up in the diff.)