Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My new Git utility `what-changed-twice` needs a new name

blog.plover.com

Post reply on HN
Print view View original

21–30 of 65 posts

Re: My new Git utility `what-changed-twice` needs a new name

#21

Post by nothrabannosir »

zahlman wrote: post #20

When I make Bash aliases or functions for Git functionality, I always name them as `git-something-or-other`. That way they're namespaced in a way that I find pleasant both for tab completion and for easy of memory. I think that should apply to more complex utilities, too. By my usual naming conventions, this one would be `git-repeatedly-changed`.

Last but decidedly not least: if you have `git-foo` on the PATH, you can do `git foo` and it will automatically pick up your program.

If I remember early git days correctly, that's how git was implemented: a bunch of separate utilities working together on the database which is the .git folder.

Re: My new Git utility `what-changed-twice` needs a new name

#22

Post by gavmor »

nothrabannosir wrote: post #21
zahlman wrote: post #20

When I make Bash aliases or functions for Git functionality, I always name them as `git-something-or-other`. That way they're namespaced in a way that I find pleasant both for tab completion and for easy of memory. I think that should apply to more complex utilities, too. By my usual naming conventions, this one would be `git-repeatedly-changed`.

Last but decidedly not least: if you have `git-foo` on the PATH, you can do `git foo` and it will automatically pick up your program. If I remember early git days correctly, that's how git was implemented: a bunch of separate utilities working together on the database which is the .git folder.

These are called alternative "porcelains:"[0] third-party, user-friendly interfaces built on top of Git's stable, low-level plumbing commands.

0. https://git-scm.com/docs/git.html#_low_level_commands_plumbi...

Re: My new Git utility `what-changed-twice` needs a new name

#24

Post by quuxplusone »

MontagFTB wrote: post #5

I am familiar with an algorithm that stably brings a disjoint selection of items together around a specified point. Sounds similar to this case, where the disjoint selection are changes that happened to a given file. The name of the algorithm is “gather”, by Sean Parent and Marshall Clow.

https://github.com/stlab/adobe_source_libraries/blob/7659244...

https://listarchives.boost.org/Archives/boost/2013/01/200366...

I gotta say, I don't see the greatness any more than most of the repliers in that Boost thread — it's just two stable_partitions in a row.

"[...] Or is there some optimization that gather provides over (stable_)partition? —— Nope. [...]"

Re: My new Git utility `what-changed-twice` needs a new name

#26

Post by schrodinger »

codewritero wrote: post #3

Jujutsu has a command which is helpful for this sort of workflow called absorb which pushes all changes from the current commit into the most recent commit which modified that file. (Each file may be merged into a different commit).

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: git add . git commit --amend

and when I make a nee "keyframe commit": git commit -m "wip: [desc 2]"

and still amend fixes.

Occasionally I'll make a change that I know fixes something earlier (i.e. an earlier "keyframe" commit) but I won't remember it. I'll commit and then do: git add . git commit -m "fixup: wip desc, enough to describe which keyframe commit should be amended"

at the end I'll do a git rebase -i main and see something like:

123 wip: add readme (it's already had a number of amends made to it) 456 wip: add Makefile (also has had amendments) 789 wip: add server (ditto) 876 fixup: readme stuff 098 fixup: more readme 543 fixup: makefile

and I'll use git rebase -i to change it to reword for the good commits, and put the fixups right under the ones they edit. then i'll have a nice history to fast forward into main.

Re: My new Git utility `what-changed-twice` needs a new name

#27

Post by CorrectHorseBat »

koterpillar wrote: post #14
codewritero wrote: post #3

Jujutsu has a command which is helpful for this sort of workflow called absorb which pushes all changes from the current commit into the most recent commit which modified that file. (Each file may be merged into a different commit).

git-absorb ( https://github.com/tummychow/git-absorb ) does a bit more, figuring out the exact changes that should be fixed up.

JJ absorb does the same as far as I understand

Re: My new Git utility `what-changed-twice` needs a new name

#29

Post by mcintyre1994 »

_dark_matter_ wrote: post #9
eru wrote: post #6

> 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).

The other benefit of this is the git bisect workflow. If you can’t build your intermediate commits then you likely can’t easily identify whether a bug was present on that commit (for many types of bug), and you therefore can’t identify the commit that introduced the bug.

Re: My new Git utility `what-changed-twice` needs a new name

#30

Post by baq »

mjd wrote: post #12
_dark_matter_ wrote: post #9

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.

…and that’s why squash merge should be the default setting in PRs.
Post reply on HN