| If git plan helps get the work done, that's great for you. I don't really understand the need to dunk on git in passing (a lot of people do this). I mean, there is no demonstration that git, by itself, encourages bad habits. For example: > Neither of those choices are good, but git doesn't give us much choice. and > Git forces you to write your commit message at the end of your coding session - after you've already turned your thoughts into code anyway. No, git tends to not force anything, it gives you tools to stash, commit, rebase, push, etc. you are free to use them at any point of your coding session.
There is little to none workflow made mandatory by git, which is how various workflows can be supported by it (github, patches over emails, git-flow, etc.) > If you context-switch during your coding session, git is not aware of it. In-fact, git isn't even a part of the picture until after you've finished writing code. maybe that's a problem of your workflow, not the tool, and again if git plan helps you with part, that's cool. This is however does not look like a typical git situation to me. > The "right" thing to do is to spend time un-tangling your changes, staging them in groups and committing with well thought-out commit messages. The encouraged thing is to commit early, commit often (http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.htm...): > So commit early and commit often: you can tidy up later with rebase. In your examples, my workflow would be to use git between each context switch. > Picture the scene, you're in the zone working on a new feature in your codebase when you spot a typo and fix it. magit-status, mark the line, commit it with a quick message "fix typo".
If you find that magit is cheating, then (1) it feels like cheating, in a good way, and (2) git add -p file is still quite easy to do? > Then, to facilitate the feature you're working on you decide to make a small architectural change elsewhere in the codebase. oh, let's git stash first > Finally, before finishing your session you decide to refactor some code in one of the files you were working on. Ok but first, let's do a quick git commit, then work on that.
Eventually I rebase interactively to write better messages, clean things up, then push. |