91–100 of 147 posts
Earlier quoted context omitted.
The history-destroying problems of rebasing are a rant on their own.
That's a UI problem with git making it hard to find hidden commits (pre-rebase). The commits aren't destroyed, they are hidden. The Jujutsu CLI is nice because it fixes this UI problem.
Earlier quoted context omitted.
One more similar feature from a different system: PostgreSQL COMMENT https://www.postgresql.org/docs/17/sql-comment.html This allows you to attach text to various database objects in PostgreSQL. I wish PostgreSQL had a feature that was more like structured key-value database object metadata that could be edited.
I love PostgreSQL COMMENT. I built a prototype app for a buddy with Supabase and added a COMMENT to every table.
Sounds really cool, but how do notes play together with the "history rewriting" features (amend, rebase, etc) where you effectively replace a commit with a modified copy? It sounds as if the notes are attached to a specific commit (or tree or blob) ID. Are git rebase etc smart enough to also copy over the notes to the new commit, or will they just vanish? What happens on interactive rebases, e.g. if I squash multiple…
> Are git rebase etc smart enough to also copy over the notes to the new commit... This is configurable. By default, amend and rebase operations will copy them forward. See git-config(1) under `notes.rewrite`.
There are many "Git's coolest, most unloved feature", e.g.: bisect, pickaxe, reflog, range-diff, archive, annotated tags, etc. Sadly they are often forgotten as many people thing of Git only as a glorified Google Drive...
Ha, I expected to know the features you were going to list, but got surprise attacked by pickaxe. What the hell? I guess I shouldn’t be so confident
Shameless plug: I recently did a webinar on how the pickaxe options are better than `git-blame`) that you can find here: https://nofluffjuststuff.com/webinar/142/level_up_your_git_g... (Note: It requires you to provide an email address).
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.
Side note: I really miss Gerritt from my time working at GOOG, but man is its deployment story kinda crap in the 2020s. I tried to run an instance locally and was hoping to integrate it with my github hosted repo ended up just frustrated. Is there anything equivalent -- that handles tracking changes over commits etc better than GH -- that is more actively developed and friendly for integration with GH? I hate GH's co…
To be honest, though, I find it easiest to create several branches with Jujutsu and then manually chain the MRs. That’s what glab does under the hood with glab stack commands. Looking forward to the code review tools in a future version.
For GitHub, though, I think Graphite is the best tool I’ve looked at so far, but I use GitLab at work so I’m not the best judge of GitHub tools for lack of experience using them at scale.
Earlier quoted context omitted.
I used git notes for marking which of my commits in my branch I had run the unit tests for (and thus my script would skip those). This was useful when working with open source upstream where you want the massage the branch to perfection with git rebase -i. It seems git trailers would now be the better place to put that information. Regarding change ids: I wish git itself had those, as then also the tooling would unde…
One trick for running tests in rebase-heavy workflows is to use the tree hash of the commit as the cache key, rather than attach metadata the commit itself. - That way, tests will be skipped when the contents of the commit are the same, while remaining insensitive to things like changes to the commit message or squashes. - But they'll re-run in situations like reordering commits (for just the reordered range, and the…
Of course, if the notes mechanism didn't exist, then I could have just used a local file.. But it's nice to see the messages in the git log.
But yeah, both kinds of keys would be useful for this purpose, depending on the exact needs.
A 9 year old feature request for notes support in GitLab was closed recently https://gitlab.com/gitlab-org/gitlab/-/issues/15029 You have to log in to read it unfortunately, but any gitlab.com account should work.
> This feature request is being closed as our current focus isn't in this area.
Earlier quoted context omitted.
One more similar feature from a different system: PostgreSQL COMMENT https://www.postgresql.org/docs/17/sql-comment.html This allows you to attach text to various database objects in PostgreSQL. I wish PostgreSQL had a feature that was more like structured key-value database object metadata that could be edited.
It's a great feature, but GitHub's parser chokes on it. Compare: https://github.com/jchester/spc-kit/blob/eb2de71d815b0057e20... To: https://github.com/jchester/spc-kit/blob/main/sql/02-spc-int... Basically the original rendering makes me look incompetent to a casual skimmer. Plus tools like JetBrains IDEs can suss out what comments belong to what DDL anyway.
The COMMENT feature isn't even a good choice for a VIEW, PROCEDURE, or FUNCTION, each of which already supports comments inline in the object definition on the server. No, the main benefits are adding comments to objects that DON'T retain them, like a TABLE, COLUMN, CONSTRAINT, ROLE, etc.
Earlier quoted context omitted.
Side note: I really miss Gerritt from my time working at GOOG, but man is its deployment story kinda crap in the 2020s. I tried to run an instance locally and was hoping to integrate it with my github hosted repo ended up just frustrated. Is there anything equivalent -- that handles tracking changes over commits etc better than GH -- that is more actively developed and friendly for integration with GH? I hate GH's co…
GitLab is actively developing native support for stacked diff workflows. CLI support for creating stacks landed in GitLab 17, and now they’re working on the code review workflow for it. To be honest, though, I find it easiest to create several branches with Jujutsu and then manually chain the MRs. That’s what glab does under the hood with glab stack commands. Looking forward to the code review tools in a future versi…
1. "Please change this" 2. 3. Comment keeps association with the original line and/or its new replacement.
Gerrit has no problem w/ this flow. GH and GL both can't do it.
GH wants to force you to put a pile of "fix" commits in and then either do a merge commit (eww) or squash the whole thing into one commit (not ideal in some cases).
A 9 year old feature request for notes support in GitLab was closed recently https://gitlab.com/gitlab-org/gitlab/-/issues/15029 You have to log in to read it unfortunately, but any gitlab.com account should work.