51–60 of 65 posts
Earlier quoted context omitted.
I agree. I decided years ago that that was a lot of work for little or no benefit. It's enough for the tests to pass at each merge point.
…and that’s why squash merge should be the default setting in PRs.
Earlier quoted context omitted.
git-autofixup is better and easier to install: https://github.com/torbiak/git-autofixup
Could you elaborate how it is better?
Earlier quoted context omitted.
This is why I no longer do atomic commits. I've just never had it be a benefit to walk through and guarantee that each commits tests and builds successfully. I so rarely back out changes that when I do, I test then that everything is working (and let's be honest, I back out usually at the PR level, not the commit).
I agree. I decided years ago that that was a lot of work for little or no benefit. It's enough for the tests to pass at each merge point.
Sit in draft until you're ready to use the CI - which you verified locally or run manually in draft, before convert to reviewable - then review, maybe tweak, merge.
Atomic commits would endanger me losing unfinished work or eventual dead-ends with no record. This seems inefficient.
Earlier quoted context omitted.
At the time I started writing the article, the utility was called `analyze-commits`. Hard to think of a worse name than that! By the time I finished writing it I had come up with a less crappy name, but I thought I'd leave the question in the post anyway.
If you’re looking for something descriptive and not clever/catchy, I propose ‘find-repeat-changes’.
> There's bonus information too. If a commit is not mentioned in the report, then it only changed files that didn't change in any other commit. That means that in a rebase, I can move that commit literally anywhere else in the sequence without creating a conflict. Only the commits in the report can cause conflicts if they are reordered. This is only true in the textual level. Semantically, re-shuffling commits like t…
This is why I no longer do atomic commits. I've just never had it be a benefit to walk through and guarantee that each commits tests and builds successfully. I so rarely back out changes that when I do, I test then that everything is working (and let's be honest, I back out usually at the PR level, not the commit).
If you never look at individual commits in your history, you might as well squash them.
Earlier quoted context omitted.
This seems very similar to how I work by default. I sort of think in terms of "keyframes" and "frames", or "commits" and "fixes to commits." Whenever I sit down to code with a purpose, I'll make a branch for that purpose: git checkout -b wip/[desc] When I make changes that I think will be a "keyframe" commit, I use: git add . git commit -m "wip: desc of chunk" (like maybe "wip: readme") if I make refinements, I'll do…
I think you might be aware given the specific words you use but for the benefit of others: Git commit --fixup lets you attach new commits to previous hashes you specify and then can automatically (or semi-manually depending on settings) squash them in rebases.
$ commit frobinator/ -m "refactor the frobnicator"
[ more work ]
$ commit echaton/ -m "immanentize the eschaton"
[ oops, missed a typo ]
$ commit frobinator/ --fixup :/frobic
Earlier quoted context omitted.
This seems very similar to how I work by default. I sort of think in terms of "keyframes" and "frames", or "commits" and "fixes to commits." Whenever I sit down to code with a purpose, I'll make a branch for that purpose: git checkout -b wip/[desc] When I make changes that I think will be a "keyframe" commit, I use: git add . git commit -m "wip: desc of chunk" (like maybe "wip: readme") if I make refinements, I'll do…
I think you might be aware given the specific words you use but for the benefit of others: Git commit --fixup lets you attach new commits to previous hashes you specify and then can automatically (or semi-manually depending on settings) squash them in rebases.
The other post about being able to do it on a substring match sounds way more ergonomic though, I’ll have to try that!
Earlier quoted context omitted.
Git's repository includes quite a bit of Perl, but they want to get rid of it.
Is there any reason for doing so?
Second, Windows doesn't really have a 'fork' API. Creating a new process on Windows is a heavyweight operation compared to nix. As such, scripts that repeatedly invoke other commands are sluggish. Converting them to C and calling plumbing commands in-process has a radical effect on performance.
Git for Windows is more of a maintained fork than a real first-class platform.
Also, I believe it's a goal to make it possible to use Git as a library rather than as an executable. That's hard to do if half the logic is in a random scripting language. Library implementations exist - notably libgit2 - but it can never be fully up to date with the original. Search for 'git libification'.
Many IDEs started their Git integration with libgit2, but subsequently fell foul of things that libgit2 can't do or does inconsistently. Therefore they fall back on executing `git` with some fixed-format output.