Highlights from Git 2.54
github.blog
Highlights from Git 2.54
1–10 of 98 posts
Re: Highlights from Git 2.54
#2the new git history command seems to be useful for quick reword, altho since i use lazygit/magit i don't really see much of a problem to me
Re: Highlights from Git 2.54
#3Nice to see some seemingly jujutsu inspired features getting into Git core.
git history reword ~= jj describe
git history split ~= jj split
Re: Highlights from Git 2.54
#4Nice to see some seemingly jujutsu inspired features getting into Git core. git history reword ~= jj describe git history split ~= jj split https://git-scm.com/docs/git-history https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-split
Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?
Re: Highlights from Git 2.54
#5I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?
Re: Highlights from Git 2.54
#6I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new…
> what workflows have worked best for you to get everyone to run the hooks
By running the linters and any other checks on CI instead.
Re: Highlights from Git 2.54
#7the new git history command seems to be useful for quick reword, altho since i use lazygit/magit i don't really see much of a problem to me
Wish reword took a commit range though
Re: Highlights from Git 2.54
#8Nice to see some seemingly jujutsu inspired features getting into Git core. git history reword ~= jj describe git history split ~= jj split https://git-scm.com/docs/git-history https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-split
Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?
jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
Re: Highlights from Git 2.54
#9I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new…
> what workflows have worked best for you to get everyone to run the hooks By running the linters and any other checks on CI instead.
autoformatter and autofix linter results can be committed and pushed by CI into the PR branch itself. this is a pain sometimes, but as a repo owner it should protect your sanity.
Re: Highlights from Git 2.54
#10Nice to see some seemingly jujutsu inspired features getting into Git core. git history reword ~= jj describe git history split ~= jj split https://git-scm.com/docs/git-history https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-split
Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?
Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit.
‘jj describe’ lets you add a message to a commit as it’s not there by default.