eekee wrote:
What prevents me from looking at what I previously did before resuming work? The fact that ideas come to mind when I'm away from the computer. Can I mentally save them for later or throw them away? Not really, many are major clarifications of concept or development of intermediate goals. I imagine you have much less of this if you're working to standards or a preexisting design, or if you just select goals from things you already understand.
Not really.
Right now I have many different places "under construction" in my PDCLib. I started working on locales (because it's one of the few non-math headers still to be done for C99 support, and the underpinning for wide and multibyte support). I then realized that I will need, basically, full Unicode support to "do it right", so I shelved locales and started working on Unicode. I got tangled up there and shelved the whole project for a while. Then I got a downstream request for thread support, so I started working on that, and finished it to about 98% -- I need some more tests, and some things (like the handling of errno) still needs to be adapted to utilize the thread support. I also realized I got a couple of bugs in freopen(). Then I got a downstream request to implement a thread-safe strtok(), so I had a look into the bounds-checking interfaces...
But that does not mean I couldn't have single-purpose "sprints" and commits. I don't mix threading code and bounds-checking code in one commit. I work on
one of those things at a time. If I have an idea I want to preserve, I add a comment to a file and commit that, or I add some prose to the project website so I will be reminded later. But my point remains: Each commit should be about
one thing.
This is my commit log. The main purpose of commit comments is that, when looking at that log, I can quickly find that half-remembered commit that (for example) "removed that test artifact", because I want to look at it again. (Bad example but I wanted to pick something that's on the first page of the log.)
You will see there's a lot of intermediate, patch-y stuff in there, because right now I am working from my smartphone more often than from my desktop, which makes for lots of "the train will arrive in five minutes, I have to wrap this up for now" type of commits. That's not a bad thing, a
commit is not a
release. The only reason
not to commit changes just yet is if they break compilation. Committed code should
always compile (even if it might not
test ok yet).
eekee wrote:
I have very little code at this stage, it's mostly prose and bullet points.
Concept work and similar shouldn't be held in the code repository. Set up a project wiki -- you get much the same functionality as from a VCS (versioning, safekeeping, history, accessibility), and you don't get your working directory cluttered up by loads of *.txt. Consider your source repo to be about "what a client will see"; that shouldn't include concepts, temporary work, or experiments.
Korona wrote:
...if you come back after 3 weeks to uncommitted changes, it's always good to remember that git gives you a vast amount of tools to deal with the situation. You could `git stash` your changes and focus on something else. You can `git stash -p` them if you want to retain most changes for now. You could break them down to sensible commits using `git add -p` or `git add -i`. You can reorganize existing (non-upstreamed) commits using `git rebase -i`. `git commit --fixup` / `git rebase --autosquash` comes to mind. If even `git cherry-pick` or `git merge --squash` to a different branch if your patch set is getting messy. `git checkout -p` sometimes also works nicely for that.
And right here, boys and girls, we can see the major reason I advise
against git for small projects,
especially one-man projects. I mean,
look at all that! It's nice that git offers it all, and it sure can be helpful if working as a repo maintainer for a huge code base with dozens of developers contributing. I will also freely admit that git is the better choice if you're working offline on a regular basis.
But for one man and his hobby project, it just gets in the way too often. The "vast amount of tools" needs to be learned, remembered, and applied with caution because git
does make it possible to make a huge hash of everything (no pun intended). It's very easy to lose track of things you "stashed", rebasing has the potential of really screwing with your history, and generally speaking git's interface is a mess.
Especially when you have problems keeping yourself organised and focussed in the first place. Git is a bunch of tools that
enable, but don't really
help with, your organization. (As exemplified by the various "workflows" that are out there, hotly debated for their pros and cons.) Compared to that, SVN has a very clear and concise "modus operandi", and a well-documented and consistent interface.