5 ms·

"Knowing the benefits of this approach, I don't understand why anyone would want to reject it." It's always difficult to have these kinds of conversations in t

by olau 12y ago

"Knowing the benefits of this approach, I don't understand why anyone would want to reject it." It's always difficult to have these kinds of conversations in the abstract, but for me it's a slightly cumbersome distraction (unless you don't write commit messages). But if it works for you, you should certainly keep doing it. I tend to divide stuff into small chunks so never work on something for long without something that can be committed.

akavel 12y ago
Most usually I still do write commit messages, and that's actually an important additional value of this workflow for me. That said, the commit message is again often a quick and raw: usually a quick in-progress summary of the most important work in the commit, but not perfected at all - just quick something, can have errors, ignores all Commit Message Guidelines like length or whatever. One benefit is, as well noted in other post in the thread, that it will remind me "what the hell was I thinking doing that" when I look at it tomorrow. Second one, obviously, is to help distinguish those commits when doing any sculpting/molding later (i.e. "git rebase -i" & "git cherry-pick" & "git merge --squash"). But that, as I said, is most usually. Sometimes, as you considered, I do write just "WIP" or "dump of current state". The second one, mostly when I already don't remember WTF was I doing here... (i.e. when I forgot to commit month ago and left some stuff on the table). The first one... I'm not sure now. But I know I sometimes do; with some guilt too; but usually the need for having that particular stuff committed is stronger than the guilt... So, still can't really understand why anyone would want to reject it :) but that said, thanks a lot for expressing your approach. As much as it still puzzles me :)

5 ms·

"Knowing the benefits of this approach, I don't understand why anyone would want to reject it." It's always difficult to have these kinds of conversations in t

by olau 12y ago

akavel 12y ago
Most usually I still do write commit messages, and that's actually an important additional value of this workflow for me. That said, the commit message is again often a quick and raw: usually a quick in-progress summary of the most important work in the commit, but not perfected at all - just quick something, can have errors, ignores all Commit Message Guidelines like length or whatever. One benefit is, as well noted in other post in the thread, that it will remind me "what the hell was I thinking doing that" when I look at it tomorrow. Second one, obviously, is to help distinguish those commits when doing any sculpting/molding later (i.e. "git rebase -i" & "git cherry-pick" & "git merge --squash"). But that, as I said, is most usually. Sometimes, as you considered, I do write just "WIP" or "dump of current state". The second one, mostly when I already don't remember WTF was I doing here... (i.e. when I forgot to commit month ago and left some stuff on the table). The first one... I'm not sure now. But I know I sometimes do; with some guilt too; but usually the need for having that particular stuff committed is stronger than the guilt... So, still can't really understand why anyone would want to reject it :) but that said, thanks a lot for expressing your approach. As much as it still puzzles me :)