101–110 of 147 posts
Earlier quoted context omitted.
Shouldn’t that be the commit message ? Or is the goal to also link forward in time, such as “we realised this commit introduced bug #123” ?
haha wait do you actually read long commit messages( more than a line) all the way through? like line-by-line, imo commit msg = tweet, git note = blog post.
Whatever is needed goes into commit message and referencing tickets in separate system is a feature not a bug - because JIRA or any other system is used to communicate with non developers. Like business analysts don't get access to code or repositories at all for example or support people don't get access to the repositories and code.
Yeah I can see how one could write front end to get the notes visible/editable by non developers but it still does not make any sense because BA/Support others don't care about specific commits and a single feature might fit into a commit but most likely does not. Even more fun is when you have multi repo and your feature touches couple services then git notes are quite useless because then you really need reference to outside system.
It is not coolest most unloved feature. It is a gimmick feature that could have been cool in some really specific cases like team of only developers running the whole company. Whatever is needed goes into commit message and referencing tickets in separate system is a feature not a bug - because JIRA or any other system is used to communicate with non developers. Like business analysts don't get access to code or repo…
Yes, but isn't it insane? What is the benefit from treating your own product as a black box? Yet that's mainstream. Sometimes I have the analyst (not on my team, but from a team we share a monorepo with) asking me questions that can be answered literally with a line of code. And she's a technical kind, knows SQL and such. And we write very idiomatic, high level code. But still, culture cannot change itself until it dies due to inherent inefficiency.
Another little-known feature is git trailers: https://alchemists.io/articles/git_trailers These are key-value structures data that can be included on a commit when it is created. These are used by some systems for attaching metadata. For example, Gerrit uses this for attaching its Change-Id.
Interesting, I wasn't familiar with this feature. I'm a big fan of conventional commits, and trailers seem like a better way of adding such metadata. Is adding them manually to the commit message functionally equivalent to using the `--trailer` flag?
Another little-known feature is git trailers: https://alchemists.io/articles/git_trailers These are key-value structures data that can be included on a commit when it is created. These are used by some systems for attaching metadata. For example, Gerrit uses this for attaching its Change-Id.
Earlier quoted context omitted.
> The Acked-By and mailing list discussion link examples don't seem to be good examples. Both of these are likely already known when the commit is made. Discussion regarding a commit (is: review) and acknowledgment of a commit cannot happen before the commit has been made. > One use case I think might be a better example is to add a git note to a commit that has later been reverted. Commit messages are better for thi…
You’re treating a commit as an atom, which is not true in patch based git situations like Linux. Most of the rest of us do not work this way, but they still do. The rest of us also only have to deal with three way merges most of the time, instead of octopus merges. Though I jokingly call, “fixing an incorrect three way merge” a “five way merge” because you end up doing a star shaped pattern of diffs to re-resolve the…
In practice I get a lot of value out of referencing commit hashes. If I fix a problem I introduced in a previous commit (for example, commit bumped version, and I forgot to bump it somewhere), my fix will say "amends ab12cd34". That way when I need to cherry-pick that commit, or do something similar (bump again), I can search for the hash of the commit I'm looking at to find what might be missing. UI is worse than gi…
you kinda doing by hand what git commit --fixup could do for you, and what git rebase -i could pick up automatically.
And if not rebasing, since --fixup does not include the hash only the commit message, it's bad for this.
I tried using git notes for distributed secure reviews but hit some road block with merges. It is a good idea that has limitations that limit its adoption
Earlier quoted context omitted.
> Discussion regarding a commit (is: review) and acknowledgment of a commit cannot happen before the commit has been made. It can't happen before the commit on a feature branch, but it can happen before merging the commit back to the main development branch. Given that a rebase or merge commit is already frequently necessary to integrate changes from a feature branch after review is finished, I don't see why this typ…
The history-destroying problems of rebasing are a rant on their own.
Where I agree with your take partially is that the UX for all of this in git is not great, and that ends up meaning that most people don't actually use git in this way. If the process of manually structuring the commits to clean up history on a feature branch were more intuitive, then I'd predict the issues of history-destroying rebases to essentially be moot; everyone would just present the commits for review exactly as we'd want them before review, and then we'd fast-forward merge into the main development branch without any issue. The problem is that doing this sort of restructuring after the fact isn't actually easy to learn how to do because of the poor ergonomics of the git CLI, so it's both tedious and error-prone for almost everyone. My perspective is that most of the concern around messing with history in git comes from being burnt by changes that were not intended by the one making them, and that workflows that avoid it (like merge commits) are essentially a compromise to avoid that risk by accepting a certain amount of cruft in the history of the main development branch. I don't blame anyone for using them, since the problems that make the rebase workflow harder are very real, but I don't think that the fact that rebase changes history is the real issue as much as it provides a mechanism for the actual underlying issues to manifest.