Fossil User Forum

git’s commit workflow is backwards, and encourages bad habits
Login

git’s commit workflow is backwards, and encourages bad habits

git's commit workflow is backwards, and encourages bad habits

(1) By sean (jungleboogie) on 2021-03-30 01:03:15 [source]

(2) By Stephan Beal (stephan) on 2021-03-30 02:26:17 in reply to 1 [link] [source]

https://rory.bio/posts/git-plan/

Though i'm an unashamed non-fan of git, i think in this case it's the blog poster who's backwards. His complaint is squarely aimed at git:

... you are forced to write a description of your work after you have already completed it. That workflow is backwards, and git should instead allow preemptive commit messages.

but applies to every single SCM ever created. (Perhaps he doesn't know that git is not the only SCM?) Writing a commit message before one writes the code is backwards. Knowing all of what one is going to code in advance is something that rarely - almost never - happens to me. My typical sessions correspond closely to his opening paragraph:

Picture the scene, you're in the zone working on a new feature in your codebase when you spot a typo and fix it. Then, to facilitate the feature you're working on you decide to make a small architectural change elsewhere in the codebase. Finally, before finishing your session you decide to refactor some code in one of the files you were working on.

Apparently there are a handful of people whose productivity benefits from reversing the natural order of events, but i dare say they are rare. And backwards. But the world would be mighty strange if we were all the same.

(3) By jamsek on 2021-03-30 03:23:22 in reply to 2 [link] [source]

I'm in complete agreement with Stephan.

I will say, however, that Fossil's multiple checkout workflow—several
concurrent checkouts in different directories—helps solve a lot of what
I'm understanding to be the author's problem/complaint. A context-switch
and unrelated commit is a tmux tab away (i.e., two key presses).

(4) By anonymous on 2021-04-06 09:53:39 in reply to 1 [link] [source]

I could see a utility for a context or a session marker in addition to commit message.

Say, oftentimes, one begins to work on a logged issue (so the context is known ahead). Luckily, it's promptly fixed in a single commit, so the commit message could be picked up from the session mark. Alternatively, when the issue fix involves deep dives with along-the-way commits, then the session mark may just be a connecting thread, simply for attribution.

Similarly, when doing new development, the session mark can be a stand-in for the interim empty message commits until the WIP is done and an in-depth message is entered as needed.