Re: Git terminology: remote, add, track, stage, etc.

> Thank you all for your many and well-thought out replies. I learned
> a lot.
> 
> Jonathan Nieder:
> 
> JNi> So what would be a better term [for tracking]?
> 
> Trailing is better than tracking, since it hints at some degree of
> sloth, but I have not thought this through. (I also think that it
> may be a strategic mistake to advocate looking for a new name; as
> long as tracking is used consistently the problem with a misleading
> metaphor is not so big, and the name change alienates a large group
> of people whose consent is important.)

> Matthiey Moy:
> 
> MM> Git's huge sin, after all (judging from most complaints I see
> MM> about it), is that It Doesn't Use Exactly The Same Model (and
> MM> thus Terminology) That CVS Did...
> 
> 
> My analysis of Git’s wickedness is interestingly different. Git has
> a clean and simple model that should be very easy to
> understand.

> The steepness of the learning curve (rather than the divergence from
> other systems’s terminology) is the single biggest complaint against
> git, evidenced by my own anecdotal evidence from web surfing, and by
> the Git user survey. It should be viewed as Git’s biggest current
> problem by an order of magnitude. It makes me think twice and thrice
> before asking my colleagues to collaborate with me using Git; I will
> probably learn Mercurial and advocate using that instead; it’s
> almost as nice, and I don’t feel embarrassed advocating it. Using
> git for myself is great (now I understand it) but it is unclear if I
> should invest social capital to convince others to use it as well.

> Sverre Rabbelier:
> 
> SR> What do you mean with the last part (about `git branch -r`)? The
> SR> fact that 'refs/remotes' is not immutable?
> 
> Well, consider for example the simple obfuscatory mastery of the
> following line in the user manual:
> 
> > $ git branch -r			# list all remote branches

> 
> 
> Yes, I get it *now*. And I begin to feel the corruption spreading in
> my own brain already: I myself start to think of origin/master as a
> ``remote branch''. Give me a few more weeks and I will be
> completely assimilated in the mindset.
> 
> (Note to self: submit a patch about this before my assimilation is
> complete. I already fixed it and committed to my local branch.)

> 
> Matthieu again:
> 
> MM> We already came up with a better wording, namely "upstream", and
> MM> used in in "git push --set-upstream".
> 
> Oh, I didn’t know that. I was convinced that "upstream" was
> cruft from when git was chiefly a tool to help Linus maintain the
> Linux kernel. Let's see if I get this right:
> 
> The remote-tracking branch "origin/master" is *upstream* (the
> upstream?) of the local branch "master",

> 
> I’m not sure I like the particular word, but that’s a minor complaint. 
> 
> ( For completeness: A small terminological quibble is that upstream
> doesn’t verb well.

> A bigger conceptual quibble is that this decision is not
> workflow-neutral. It enforces git’s hierarchical linux-kernel
> development tradition, rather than embracing a truly distributed
> model where everybody is the same. When I think of distributed
> version control I like to think of Alice having a remote-tracking
> bob/master and Bob having a remote-tracking alice/master. Of course,
> it is still meaningful for Alice to say "the upstream of
> bobs_latest_crazy_ideas is bob/master", and for Bob to say "the
> upstream of alices_inane_ramblings is alice/master". But it
> introduces a notion of hierarchy that is inimical to the concept of
> distribution, and not workflow-neutral. )

> 
> Of course, upstream could be called supercalifragilistic and I would
> still like it. Consistency is more important than having good
> metaphors. (But good metaphors would be better, all other things
> being equal.)
> 
> Jakub Narebski:
> 
> JNa> Note that it is not as easy as it seems at first glance.  There
> JNa> are *two* such options, which (as you can read in gitcli(7)
> JNa> manpage) have slightly different meaning:
> 
> Wow. Thanks for pointing this out, I did not know that, and it
> explains a lot. I must say that to everybody else than a git
> developer, this state of affairs is a proof that something is wrong,
> rather than an obstruction for improvement.

> 
> ??> I do not think debating on changing the terminology is a
> ??> particularly productive use of our time.
> 
> I agree in the sense that *how* the words are used is more important
> than *which* words are used, and I realise that I should not have
> put "terminology" in the headline, because that makes it about
> words, not *explanations* or terminological *discipline*.