From: Miles Bader <miles@gnu.org>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Thore Husfeldt <thore.husfeldt@gmail.com>, git@vger.kernel.org
Subject: Re: Git terminology: remote, add, track, stage, etc.
Date: Tue, 19 Oct 2010 13:49:06 +0900 [thread overview]
Message-ID: <buopqv6kcsd.fsf@dhlpc061.dev.necel.com> (raw)
In-Reply-To: <vpq8w1v5gce.fsf@bauges.imag.fr> (Matthieu Moy's message of "Mon, 18 Oct 2010 23:41:21 +0200")
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> We already came up with a better wording, namely "upstream", and used
> in in "git push --set-upstream". Probably a next step would be to
> deprecate any other occurence of --track meaning the same thing
That doesn't make much sense to me; "upstream" and "track" are not
alternatives; rather, they're complementary: "upstream" is a _thing_,
and "track" is an _action_ -- one _tracks_ _upstream_. "--track", then,
merely implies "upstream", which seems fine to me, as I'm not sure
there's anything else it could refer to.
I think the original post, while well-meaning is a bit overwrought, and
reflects the difficulty in learning any new system as much as it does
any inconsistency in git's terminology[*] -- Git's huge sin, after all
(judging from most complaints I see about it), is that It Doesn't Use
Exactly The Same Model (and thus Terminology) That CVS Did...
[SVN's great sin, of course, is that It Does (interpret "CVS" liberally
here).]
[*] Git is certainly guilty of using inconsistent terminology --
cached/staged/index/yada is my personal complaint -- but I don't think
to anywhere near the degree implied by that post.
-Miles
--
Do not taunt Happy Fun Ball.
next prev parent reply other threads:[~2010-10-19 4:49 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-18 20:45 Git terminology: remote, add, track, stage, etc Thore Husfeldt
2010-10-18 21:15 ` Jonathan Nieder
2010-10-18 22:48 ` [RFC/PATCH] reset: accept "git reset <removed file>" Jonathan Nieder
2010-10-18 23:56 ` Junio C Hamano
2010-10-19 0:23 ` Jonathan Nieder
2010-10-19 17:34 ` Junio C Hamano
2010-10-19 22:34 ` Jonathan Nieder
2010-10-18 21:35 ` Git terminology: remote, add, track, stage, etc Sverre Rabbelier
2010-10-19 0:03 ` Junio C Hamano
2010-10-19 17:51 ` Ramkumar Ramachandra
2010-10-19 18:28 ` Jonathan Nieder
2010-10-19 18:34 ` Sverre Rabbelier
2010-10-19 18:43 ` Thore Husfeldt
2010-10-19 19:04 ` User manual: "You cannot check out these remote-tracking branches" Jonathan Nieder
2010-10-19 20:52 ` Matthieu Moy
2010-10-19 19:15 ` Git terminology: remote, add, track, stage, etc Nicolas Pitre
2010-10-19 19:20 ` Junio C Hamano
2010-10-19 22:10 ` [RFC/PATCH 0/4] reset: be more flexible about <rev> Jonathan Nieder
2010-10-19 22:11 ` [WIP/PATCH 1/4] reset -p: accept "git reset -p <tree>" Jonathan Nieder
2010-10-19 22:12 ` [PATCH 2/4] reset: accept "git reset <tree> <path>" Jonathan Nieder
2010-10-19 22:13 ` [PATCH 3/4] reset: accept "git reset -- <path>" from unborn branch Jonathan Nieder
2010-10-19 22:14 ` [PATCH 4/4] reset: accept "git reset HEAD " Jonathan Nieder
2010-10-19 23:08 ` Junio C Hamano
2010-10-19 23:26 ` Jonathan Nieder
2010-10-27 15:03 ` Git terminology: remote, add, track, stage, etc Ramkumar Ramachandra
2010-10-27 15:16 ` Drew Northup
2010-10-27 16:08 ` Matthieu Moy
2010-10-28 15:20 ` Ramkumar Ramachandra
2010-10-28 18:25 ` Matthieu Moy
2010-10-18 21:41 ` Matthieu Moy
2010-10-19 4:49 ` Miles Bader [this message]
2010-10-19 7:19 ` Wincent Colaiuta
2010-10-19 7:48 ` Miles Bader
2010-10-19 8:05 ` Wincent Colaiuta
2010-10-19 15:09 ` Eugene Sajine
2010-10-22 20:16 ` Paul Bolle
2010-10-22 21:00 ` Eugene Sajine
2010-10-22 21:46 ` Drew Northup
2010-10-20 9:53 ` Thore Husfeldt
2010-10-20 11:34 ` Matthieu Moy
2010-10-20 14:01 ` Drew Northup
2010-10-18 21:57 ` Jakub Narebski
2010-10-19 8:05 ` Matthijs Kooijman
2010-10-19 8:27 ` Jakub Narebski
2010-10-19 17:30 ` Thore Husfeldt
2010-10-19 20:57 ` Jakub Narebski
2010-10-21 8:44 ` Michael Haggerty
2010-10-21 11:20 ` Drew Northup
2010-10-21 12:31 ` Thore Husfeldt
2010-10-21 12:56 ` Drew Northup
2010-10-21 14:06 ` Thore Husfeldt
2010-10-21 20:06 ` Drew Northup
2010-10-22 4:07 ` Miles Bader
2010-10-22 11:51 ` Drew Northup
2010-10-19 14:39 ` [PATCH v3] Porcelain scripts: Rewrite cryptic "needs update" error message Ramkumar Ramachandra
2010-10-27 14:55 ` Ramkumar Ramachandra
2010-11-05 22:38 ` Junio C Hamano
2011-02-12 23:14 ` Ævar Arnfjörð Bjarmason
2010-10-19 21:53 ` Git terminology: remote, add, track, stage, etc Drew Northup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=buopqv6kcsd.fsf@dhlpc061.dev.necel.com \
--to=miles@gnu.org \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=thore.husfeldt@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).