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 
on that.

(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

Reply via email to