From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Michael Witten <mfwitten@gmail.com>,
geoffrey.russell@gmail.com, Ralf Ebert <info@ralfebert.de>,
git@vger.kernel.org
Subject: Re: understanding how remote tracking works
Date: Mon, 09 Aug 2010 12:31:32 -0700 [thread overview]
Message-ID: <7vaaov60rv.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20100809021900.GA10596@burratino> (Jonathan Nieder's message of "Sun\, 8 Aug 2010 21\:19\:00 -0500")
Jonathan Nieder <jrnieder@gmail.com> writes:
> Michael Witten wrote:
>> On Sun, Aug 8, 2010 at 20:53, Geoff Russell <geoffrey.russell@gmail.com> wrote:
>
>>> I'm working my way through Jon Loeliger's Git book and it's
>>> confusing when the actual behaviour differs from that in the book
>>
>> This probably results from the git culture's conflation (or should I
>> say confusion?) of low-level and high-level representations and
>> commands.
>
> I guess I’ll bite. What does that mean? We have “show-ref” and
> “update-ref” precisely as low-level commands that are independent
> of representation.
I tend to agree with Michael (modulo s/ culture/'s early&/) here. Many
documents written in the early days, the "tutorial" document by Linus
being the most prominent example, were written in a way to focus exposing
the implementation details to show how simple the structure is. These
documents and tips by early adopters, simply by virtue of being old, are
found more easily by search engines. Later we started encouraging use of
show-ref and update-ref to isolate users from the implementation details
that can be changed for performance reasons.
> Probably the more relevant question: what do you want to do about it?
Continue the current course of encouraging the use of plumbing commands
and not looking at the low-level implementation detail. Perhaps help
people update their documents, moving stale descriptions into "historical
note" sections.
next prev parent reply other threads:[~2010-08-09 19:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-09 1:17 understanding how remote tracking works Geoff Russell
2010-08-09 1:31 ` Ralf Ebert
2010-08-09 1:53 ` Geoff Russell
2010-08-09 2:13 ` Michael Witten
2010-08-09 2:19 ` Jonathan Nieder
2010-08-09 3:46 ` Geoff Russell
2010-08-09 19:31 ` Junio C Hamano [this message]
2010-08-09 20:53 ` Jonathan Nieder
2010-08-09 23:07 ` discarding refs/original/* after filter-branch (Re: understanding how remote tracking works) Jonathan Nieder
2010-08-09 1:32 ` [PATCH/RFC] Documentation: add a FILES section for show-ref Jonathan Nieder
2010-08-09 19:33 ` Junio C Hamano
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=7vaaov60rv.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=geoffrey.russell@gmail.com \
--cc=git@vger.kernel.org \
--cc=info@ralfebert.de \
--cc=jrnieder@gmail.com \
--cc=mfwitten@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).