your point that "...only the *published* (or sent in the form of a patch series)
history is sacred but your *local* history is not..."
is very interesting, and while I appreciate the point, and like the sound of
it, I'm not sure how to apply it. For me, I try out this, I try out that,
maybe it runs, maybe it crashes, maybe it runs but has a bug, etc. From time
to time I'll branch and work on the branch, but then, if the idea in the branch
pans out, I end up (if I have the correct term) fast forwarding so that the
latest branch commit just goes to the head of the master branch(?), and it just
seems like so much wasted effort to have made the branch at all.
At least for me, it generally seems easier to just stay on the master branch,
and then from time to time I'll branch a version number when a certain amount
of progress is achieved, but even then, I rarely find myself going back to an
old version. I realize I just shifted the topic from commits to branches.
The downside to this approach is that there are a ton of commits as I futz
around, and most of them are pointless. I haven't really found a good mix yet
(I was only using compiling as an example because it's black-or-white. Of
course some scripts aren't compiled at all, and maybe a testing framework is
used, so you could say "passes all tests", etc.)
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.