I suggest group-commits-by-file , group-commits , or group-by-file, depending on whether you want it to make sense out of context and whether you ever group commits differently. You might then feel compelled to add a final line like “… and 12 files with 1 commit each”, or even to enumerate them, which sounds like it’d be useful anyway. “what” isn’t doing any work, there’s already an implicit “what” in the call-response paradigm. “Changed” implies you’re detecting changes, but you’re not, you’re operating on a data structure that happens to represent changes.
My new Git utility `what-changed-twice` needs a new name
41–50 of 65 posts
Re: My new Git utility `what-changed-twice` needs a new name
#42Why does it needs a new name? I had a good idea of what it did before reading the article, it is a long name but not Java-long, and none of the suggestions so far are clear to me, even after reading the article. The only somewhat confusing part is the "twice", because it can be more than twice. But if you think about it, if it has been changed more than twice, it had to be changed twice at some point, so it is not to…
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’.
Re: My new Git utility `what-changed-twice` needs a new name
#43"what-changed-twice" tells me exactly what the command does. "squash-what" tells me nothing, why is the program name asking me what to squash, and then why does it not squash? The only inaccuracy I can think of in the name is that it's technically "what-changed-more-than-once." But if something has changed thrice, by definition it's also been changed twice.
> “squash-what" tells me nothing, why is the program name asking me what to squash, and then why does it not squash?
‘squash-candidates’ would address all of that.
Re: My new Git utility `what-changed-twice` needs a new name
#44Earlier 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’.
[deleted]
Re: My new Git utility `what-changed-twice` needs a new name
#45Why did you opt for "highly-abbreviated commit IDs"?
Instead of:
``` calendar/seasons.blog 196 40 d1
196 196e749
40 40c52f4
d1 d142598The tool should simply display:
``` calendar/seasons.blog 196e749 40c52f4 d142598 ```
That's it!
The second table only complicates the output.
PS:
`what-changed-twice` is a good name.
Re: My new Git utility `what-changed-twice` needs a new name
#46Earlier 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’.
Just gonna +1 this. It's still fairly short, descriptive and to the point, which I generally prefer to something more "trendy" or "clever". I like it.
Re: My new Git utility `what-changed-twice` needs a new name
#47I 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. [...]"
The Boost thread starts with an example of how Bjarne replaced a bunch of complicated code with it.
It may be just two stable partitions, but “just” is doing a lot of work there. The algorithm becomes obvious once someone has identified it.
Re: My new Git utility `what-changed-twice` needs a new name
#48Website is down.
Re: My new Git utility `what-changed-twice` needs a new name
#49oops-i-did-it-again
Re: My new Git utility `what-changed-twice` needs a new name
#50Earlier 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).
If you want atomic commits, you need to set up your CI/CD to ensure that each intermediate commit builds and passes tests. Most pull requests should probably be squashed to appear as a single commit in the final history. But you should have the option of leaving history intact, when you want that, and then your CI/CD should run the checks as above.
You don't need squash here, though. If your CI/CD ensures that merge commits (PRs) are atomic/build and pass tests, you can `git bisect --first-parent` to just bisect your merge commits/integration points/pull requests, without tossing the other history from the git DAG.