On Thu, 19 Dec 2013 01:53:57 -0800 (PST) THUFIR HAWAT <[email protected]> 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 thing. 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
