> It is valuable history: it is archaeological evidence of what has been attempted before.
Except that is not readily accessible. When looking at a particular section of code, you could either run git blame, or run git log and filter it to only list commits that updated that file.
Either way, you're not going to easily be able to find what previous implementations were tried, or why they were not used compared to the current implementation.
But if you make a clean commit with the working implementation and include an explanation of what other approaches were tried and why they weren't used, then someone could use git blame to get the information pretty easily.
It sure is valuable, which is why it's retained in your reflog. You don't have to push it out anywhere though (or at least not somewhere where it pretends to be part of the project).
My reflog can sometimes be useful for myself, but I can't imagine anyone ever taking time to go through someone else's (either literal or in form of commits) messy reflog. If that's your argument, then no, it's not exactly what I'd call "valuable".
My argument was that the only cases where going through unfiltered chain of WIP commits is somewhat valuable are well served by browsing through your reflog. I don't see any value in peeking at other people's unfinished stuff (unless doing something like pair programming or teaching). Any decisions that are worth noting go into commit messages anyway. That "archaeological evidence" has, in general, no reason to leave the local machine at all.
Maybe it does, but couldn’t the developer write more descriptively?
The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages.
Presenting that argument as a rationale for avoiding straight merges while preferring squashing and/or rewriting history is the strawman.
> Maybe it does, but couldn’t the developer write more descriptively?
Commonly while you're fixing things up there's nothing of worth to be descriptive about. "made test x pass" is a useful checkpoint during development, it's not a useful step to conserve forever.
> The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages.
I see your accusation of strawmanning was just projection. Thank you for the insight, have a nice day.
”Made test x pass” is still a bad commit message, as it says nothing about what changes were made to the codebase — which are always made when ”fixing things up”!
I did not intend for my comment to be taken as an accusation, as that would imply intention on your part. I simply meant to point out the logical fallacy in statements I read online, i.e. ”because someone on the Internet was wrong”.
Trying to gaslight me with personal accusations of psychological projection, however, is crossing a line. Do not do that to other people, it is violence.
You do not know what I think or feel, only what I write.
Spending excessive time authoring high quality commit messages for low value commits [during development] is a waste of time. In general it will end up costing you in pure velocity, and reduce how much can get done in a day.
You do know that temporary commits made locally that usually should never leave your development machine are not the ones that you push out to review and merge, right?
That works when your developer laptop can actually run all the tests. If you're writing code which runs on something like AIX then generally you need to push code to CI in order to get it tested at all. And even for stuff which should test correctly both locally and in CI a lot of time gets burned yak shaving fixing the CI configuration, which can't be done locally. With something like Windows there's often issues between the configuration of the CI builders/testers and what you're running in some kind of virtual environment locally.
The idyllic world of "when it passes on my machine it always passes in CI" doesn't exist once you start doing sufficiently complicated testing and have a sufficiently large test matrix.
And as you pull in dependencies (different version of the underlying language/framwork, different versions of upstream or downstream deps that you need to test against) everything gets messy and even if you could reproduce the full matrix on your laptop it would take a day to run to completion.
> That works when your developer laptop can actually run all the tests.
That's completely orthogonal. A remote branch that nobody looks at except you and your CI service is also part of what I'd consider "developer machine", you're just not necessarily sitting right in front of it. The important part is: these are not the commits that go anywhere further in the development process, and you certainly don't push them out to review. There's absolutely no reason for anyone to look at my "aaaa" and "fix" commits full of commented out code that serve as nothing more than an "undo" feature for what happened in my brain.
Because why not? It's an undo feature for my brain, and a way to trigger remote CI process. Using tools to help with thinking is not "a problem", and even printf debugging has its perfectly valid uses.
My temporary commits can be as messy as it's reasonable for them to remain helpful, because they're not influencing the review in any way.
"Should" is a funny word. I push funky commits to development branches often, because I always try to sync my work to the git host at the end of the workday in case I wakeup to a non-functioning laptop the next morning. Better to have a risk of ugly commits in a wip branch than risk losing work.
> Temporary commits .. are not the ones you push out to review, right?
Fully agree with this; I am a clean freak and groom the entire branch differential into sets of atomic or related commits before submitting a merge request.
> I push funky commits to development branches often, because I always try to sync my work to the git host at the end of the workday
I do that too, and also to get CI artifacts - but I consider that an "implementation detail" that doesn't affect any other part of the development process ;)
How often does someone go through your code commit-wise? What is the business value of grooming commits, if the reviewer only looks at the branch diff (as they very well should, lest they miss something in the big picture)?
They are valuable when using git blame to see the line in the context of the change it was part of and the associated commit message. That information could help avoid introducing a regression for example.
I go through individual commits during review quite regularly. Sometimes it's enough to look at the diff of the whole branch, but sometimes it's much more manageable to look at individual commits for meaningful review.
No, there's no reason to preserve commit messages you used during development.
When I am developing, I make many tiny commits with an automatically generated title ('Modify util/files.py') each time my tests pass, or really, when I do anything of value. (I use `git-infer`: https://github.com/rec/gitz/blob/master/git-infer)
This makes it impossible for me to lose work, and acts like a coarse-grained undo for me, where I can quickly move back and forth between spots that the tests worked if I decide I'm going the wrong way, or create a new branch, move back a bit, and make some changes and compare.
_Before anyone sees this code_ I rebase it down to a logical sequence extremely-carefully named and organized commits. (The word "manicured" has been used more than once.)
As I go through code review, I make tiny commits and at the end, rebase them into my carefully-named commits.
I create at least five commit IDs for each final commit I created. No one wants to see these.
I spend considerable time organizing everything so just the information you need to see is in the final commits. All the information should be there.
It helps in terms of maintenance. For example, when changing some code, you could look at the commits that arrested the lines of coffee you're going to modify. With well crafted commit messages, you may be able to avoid introducing a regression based on information in those past commit messages.
If you keep all the intermediary commits, it's pushing more process onto the dev in the middle of coding. Some people may do this well, but more often than not I do just see "WIP (test broken)" etc.
With a squash/rebase, the development has to write an accurate commit message once & they're doing it when they've fully understood the solution they've written.
It doesn’t seem logical to me that someone working on solving an intellectual puzzle would do so without having a consistent internal narrative of what they are doing.
If a developer can’t fit their change description on one line or don’t even know where to start describing the changes, chances are they could commit much more often.
The way I see it, a commit message like ”WIP (test broken)” is unprofessionalism bordering on self-sabotage.
> it's pushing more process onto the dev in the middle of coding
Uhm, how exactly? Splitting & merging things into sensible, atomic commits with proper commit messages is usually what you do right before pushing it out for someone else to see, definitely not "in the middle of coding".
