On Thu, Aug 18, 2011 at 10:56, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Michael Witten venit, vidit, dixit 18.08.2011 07:52: >> On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >>> It would be really nice, though, if Git could somehow >>> "stash" such files when checking out a different branch. In general, I >>> would prefer if uncommitted changes and untracked and/or ignored files >>> stuck to the branch where they were created. >> >> As an aside, the problem here is likely a manifestation of the fact >> that nobody understands what a branch is; the word 'branch' is > > I would reject "nobody"... Is it really necessary to attack something that is obviously hyperbolic rhetoric? The point is that a lot of people struggle with git's concepts, and I think that the reason is largely two fold: * Terminology that is inaccurate by virtue of terminological baggage. * Terminology that is imprecisely used across the documentation. >> TERRIBLE, as everyone has a different idea for what that should mean. > > ... and insist that this statement is true either trivially true for all > words, or for none, depending on your understanding of "everyone has a > different". So, precision is impossible? The word 'branch' is clearly a sticking point, and you know it. You can't deny that people have a hard time with what a branch really is in git. >> In my opinion, `git branch' should become `git ref' or the like. > > "branch" and "tag" are boths refs. Their only essential difference is > that one "moves" and the other doesn't. Indeed, and it seems like there's room for abstraction; a tool like `git ref' or `git pointer' or `git ptr' could probably handle both quite well. Terminology for references is a problem that was solved by the Ancients, so it's a wonder we didn't use their work (pointers, constant pointers, dereferencing, etc.). >> One of git's worst faults is that a complicated and imprecise >> interface has been draped over a very simple and precise underlying >> structure. > > A name is a name and just that. The use of any existing word may clash > with someone's expectations. Yeah? So why wasn't the term 'foobar' used instead of 'branch'? Most terms are chosen for their associations (and only really novel concepts receive an entirely new label), and I proffer that 'branch' has too many associations to be considered accurate enough. The idea was that one line of development can 'branch' off from another, so it was called a 'branch'. But what is a line of development? (merges certainly make the concept fuzzy; tree branches usually don't join with the tree trunk again). The thing is, though, when you're working with what git calls a 'branch', you're really just working with a pointer to a commit object; the term 'pointer' would have been much more accurate. Now, I'm not saying we should be using 'pointer', but what I am saying is that it's necessary to choose words carefully, preferably in a way that carries just enough associations to aid the user in remembering what a term describes. > I find the concepts "file created on a branch", "commit created on a > branch" silly, it's part of what drove me from hg to git early on. There's no shortage of that kind of thinking in the git community, which is my point. The reason is a failure of both accurate terminology and precise usage. > git's branches do exactly what I (and many others) expect branches > to do and what I need daily, even coming from a svn and hg background. Yes, well, many figure it out EVENTUALLY; it just requires them to ignore most of the associations of 'branch', thereby tacitly translating the word 'branch' into 'pointer'. -- 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