On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: > On 21 August 2011 13:53, Michael Witten <mfwitten@xxxxxxxxx> wrote: >> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga >> <hilco.wijbenga@xxxxxxxxx> wrote: >>> Isn't a branch simply a way to track changes separately? >> >> Well, what does that mean, really? You can certainly use branches to >> help you achieve that goal. > > It means my commits are chained together separate from, say, master. Well, that's not what a git branch provides in general. >> In git usage, a `branch' is just a human-readable name for any given >> commit object; it points to a commit object, and you can change to >> which commit it points. Furthermore, to help you work with commit >> lineages, some of the git machinery updates these branches (or >> `pointers', if you like) automatically (for instance, when you make a >> new commit object with `git commit', then the `current branch' is >> updated to point to the newly created commit object). >> >> Of course, 2 different branches may be used to point to the same commit object. >> >> You should really think of your repository as a giant web of commit >> objects (or, more technically, as a directed acyclic graph where each >> node is a commit object); a commit object can point 'backwards' >> towards its parent commit objects. A branch (like `master') just >> points to one of these commit objects at any given time (that is, a >> branch just gives a nice human-readable label by which to reference >> one of these commit objects at any given time). > > Yes, I agree with all of that (especially the last sentence). I don't > see how it changes the concept of a branch is, though. You are, I > think, simply listing the technical implementation. No, I'm simply listing the reality of what a branch is. > ... > > I feel like we're talking in circles. I get (and even agree with) what > you're saying but I don't see how it changes the concept of a branch. > > In any case, what I'm more interested in is knowing whether we can > (optionally) add state (i.e. untracked/ignored files and unstaged > changes) to a branch. No, because a branch doesn't IN ANY WAY provide the structure for that kind of thing. Of course, you could use what git calls a 'branch' in order to implement what you imply is a 'branch', but git's concept of a branch and your concept of a branch are not at all the same concept (which is why the term 'branch' is so unfortunate). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html