On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: > On 21 August 2011 16:06, Michael Witten <mfwitten@xxxxxxxxx> wrote: >> 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. > > Er, so what *does* a Git branch provide then? I think my other replies (including the link) repeat myself quite enough. A branch is just a pointer. That's it. Quit saying `branch' to yourself. Start saying `pointer' or `reference' or `commit label' or even `special tag'. >>> 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. > > Obviously, we'd need to expand that structure. > > I tried (ab)using git stash to get what I want but it ignores > untracked/ignored files (not a big surprise, of course). It seems the > functionality is almost there. If I could just combine git checkout > with git stash (and have it work with untracked/ignored files) in a > script or alias, I'd be a happy camper. I'll have to give it some more > thought. This cobbling together of git's components for this purpose is actually a fairly frequent story on this list. Either git does indeed need something more substantial as a `branch', or people (meaning you) need to change the way they think (and I'm not sure which solution would be best, honestly). If there is a change, then what is currently called a `branch' should be renamed explicitly to `pointer' or a `reference' or something like that. >> 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). > > You've completely lost me. You may very well be right but all I see is > that you're pointing out how branches are implemented in Git. That last sentence and your earlier sentence: > Obviously, we'd need to expand that structure. vindicate everything I've said about the choice of nomenclature. The term `branch' is a TERRIBLE choice. -- 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