41–50 of 98 posts
the 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
I do almost no direct git work myself these days. Using claude in Conductor. Working on a team. I'll tell claude what do do in git sometimes, but there doesn't seem to be much need to do it myself anymore, even with complicated rebases, reflogs, etc.
That way you're still "blazingly-fast with your SOTA-LLM!!!" while also understanding why :)
I 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…
I think there should probably be a way to specify canonical git configuration for things like hooks and LFS and all of that. It would be nice if when you clone, git prompts you to trust the remote config or to ask you to accept each new change as they come or fully reject them.
Having to scrape through the readme of every repo and then run arbitrary scripts doesn't seem like the most secure solution. When there's a canonical flow gitlab GitHub and all the tooling can support it and have proper permissions around it.
It's really disappointing how much lack of empathy there is when talking about new git features. Forget empathy. There's outright disdain for discussing alternative workflows.
`git history reword` is great. Using `git rebase -i` just to fix a spelling error is overkill and doesn’t actually do what I want.
I hate to be the worry wart, but I am worried folks are going to avoid `git rebase -i` even more now. It is such an excellent excellent UI in my opinion: it shows you the history of what is clearly, and let's you modify it as you please!
But what about local heads referred to only by a "soft" tag? Is their history rewritten, or is it left to refer to the old history?
Earlier quoted context omitted.
We do run the linter on CI as well, but I think our comitters would get faster feedback if they ran those checks locally.
Well you can tell them to please enable hooks in the PR guidelines, but you cannot really police what they do or don't run on their own machines.
LFS needs an install step and it needed to be brought into git itself to cut through all of the problems. Manually managing hooks is not sufficient.
No amount of "please don't fuck it up" in the readme is going to save you.
Even CI checks for what should and shouldn't look like an lfs stub is non-trivial. I don't think such a thing even exists today.
Earlier quoted context omitted.
I don't want you to run arbitrary hooks on my machine. As with CI/CD... your hooks should simply point to a script instead
Ok well what about when I pay you and give you a local machine to work on? Can I pay you to run hooks on the work machine I own because it saves a lot of work on the share build machines? Can we talk about making that situation less error prone?
Why force git to be a build tool?
Just document how to execute the scripts/checks that will be used by ci. Provide a simple script in the repo that folks can intentionally execute.
Earlier quoted context omitted.
Well you can tell them to please enable hooks in the PR guidelines, but you cannot really police what they do or don't run on their own machines.
This is very much not a serious solution. Look at the case of LFS. LFS needs an install step and it needed to be brought into git itself to cut through all of the problems. Manually managing hooks is not sufficient. No amount of "please don't fuck it up" in the readme is going to save you. Even CI checks for what should and shouldn't look like an lfs stub is non-trivial. I don't think such a thing even exists today.
Nice 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
If this is meant to be a dig, you should keep in mind how much jj owes to git.
Nice 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