On Thu, 19 Dec 2013 01:53:57 -0800 (PST)
THUFIR HAWAT <hawat.thu...@gmail.com> wrote:

> 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.)

Well, I reckon you mostly use Git for single-developer workflow.
This is perfectly OK, of course, but makes understandings the
usefulness of certain concepts and best practices harder.

An interesting property of a version control tool is that it provides
for different things: you might use it as an easy *backup tool* for
"what if?..." style explorations off the main line of development, you
can use it as a convenient tool for *sharing* the code between different
workstations, you can use it for direct *collaboration* (read: pull
requests), you can use it for another level of collaboration, when you
prepare an implementation of a feature, and this implementation will
later be delivered to the project maintainers in some other form --
typically a patch series.  As you can see, there are many uses, and
they all imply using different approaches to using the tool.  You don't
see the point of making branches?  No problem: in a single-developer
workflow working right on the master does not harm anyone.

Having asked your original question you made me think you're concerned
about the quality of individual commits (mostly useful for applying
`git bisect` to nail down a commit introduced a bug later), and I tried
to explain that with Git, a typical approach for achieving this is to
have "dirty" throw-away branches which receive reasonably chaotic
sloppy commits but then got rewritten by means of rebasing into
something sensible.

"The trick" to get how to apply this practice is understanding *why* we
might want the history to look sensible.  To understand this, it helps
to imagine yourself undertaking a task of developing a feature for
some complicated and highly visible project; suppose you're developing
a driver for Linux.  So you clone a sensible tree (usually the one
maintained by the leutenant responsible for the kernel's subsystem your
driver is for) and start hacking away.  Now imagine your changes are
ready to be reviewed by the maintainer.  Imagine you're *the*
maintainer who's about to review your changes.  Does it have sense for
you to work over every single commit titled "fix typo in comment",
"forgot to initialize that counter variable" etc etc eес.  Surely, no:
you'd better like to see a series of clean commits each implementing a
particular feature or reworking some APIs in the kernel to suit your
needs.  In other words, the project as a whole is not interested in
gory details of how exactly you were crafting your feature, it's only
interested in a beautiful sensible history, even if it's a synthetic

You might find more on this in a classic explanation of what to rebase
and what not to given by Linus Torvalds in [1].  It looks at this
problem at a slightly different angle (it asserts the reader already
knows what `git rebase` is for) but contains lots of wisdom anyway.

Do you need it for your workflow, I do not know.
Basically, we arrived to this discussion along this logic: you ask if
it's okay to do commits which potentially represent a broken state of
the project, we explain that that's okay until you either do not care
about this fact (bisecting is a non-issue for you) or you might
subsequently prettify the history, you ask why you'd want to prettify
it, so I'm trying to explain.  Hope this helps.

1. http://thread.gmane.org/gmane.comp.video.dri.devel/34744

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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to