From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 03/16] pull: cleanup documentation
Date: Thu, 31 Oct 2013 13:27:11 -0700 [thread overview]
Message-ID: <xmqqr4b1425c.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAMP44s1-pVDoLrEC9m0J+fRCxnvMb+P0ANMxS7vzBhFub_Yv6Q@mail.gmail.com> (Felipe Contreras's message of "Thu, 31 Oct 2013 13:51:42 -0600")
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Thu, Oct 31, 2013 at 1:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Thu, Oct 31, 2013 at 12:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>>> --- a/Documentation/git-pull.txt
>>>>> +++ b/Documentation/git-pull.txt
>>>>> @@ -39,7 +39,7 @@ Assume the following history exists and the current branch is
>>>>> "`master`":
>>>>>
>>>>> ------------
>>>>> - A---B---C master on origin
>>>>> + A---B---C origin/master
>>>>> /
>>>>> D---E---F---G master
>>>>> ------------
>>>>
>>>> This change is wrong; the illustration depicts the distributed world
>>>> (i.e. a fetch has not happened yet).
>>>
>>> That is an irrelevant implementation detail, specially at this high
>>> level. In the user's mind origin/master means master on origin.
>>
>> You are wrong. In the user's mind, origin/master means the commit
>> that used to be at master on origin, and the point of this
>> illustration is to make them understand that they live in a
>> distributed world, where their last observation will go stale over
>> time.
>
> Wrong. That would make sense in 'git fetch', but here the point of the
> illustration is to make them understand what 'git pull' will do,
> namely a merge.
>
> Which refs point to C at which points in time irrelevant information,
> the user wants to know that 'git pull' will create a merge.
Merge with what, and how do the users know what will be merged?
Think.
The users need to learn that origin/master they were told to use
with "git log origin/master.." etc. trails reality, "git fetch" is
how they can get them in sync, and the reason they do not need to
run "git fetch" separately when they "git pull" is because it is run
for them internally.
That is what the illustration and the paragraph that follows teach
them.
I've said enough on this.
next prev parent reply other threads:[~2013-10-31 20:27 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 9:25 [PATCH 00/16] Trivial patches Felipe Contreras
2013-10-31 9:25 ` [PATCH 01/16] merge: simplify ff-only option Felipe Contreras
2013-10-31 18:04 ` Junio C Hamano
2013-10-31 9:25 ` [PATCH 02/16] t: replace pulls with merges Felipe Contreras
2013-10-31 9:25 ` [PATCH 03/16] pull: cleanup documentation Felipe Contreras
2013-10-31 18:11 ` Junio C Hamano
2013-10-31 18:37 ` Felipe Contreras
2013-10-31 19:00 ` Junio C Hamano
2013-10-31 19:27 ` Max Horn
2013-10-31 19:42 ` Junio C Hamano
2013-10-31 20:43 ` Junio C Hamano
2013-10-31 21:16 ` Felipe Contreras
2013-10-31 23:40 ` David Aguilar
2013-11-01 1:56 ` Felipe Contreras
2013-11-01 2:48 ` David Aguilar
2013-11-01 3:50 ` Felipe Contreras
2013-11-01 11:05 ` SZEDER Gábor
2013-11-01 12:20 ` Felipe Contreras
2013-10-31 19:51 ` Felipe Contreras
2013-10-31 20:27 ` Junio C Hamano [this message]
2013-10-31 21:15 ` Felipe Contreras
2013-10-31 9:25 ` [PATCH 04/16] fetch: add missing documentation Felipe Contreras
2013-10-31 18:10 ` Junio C Hamano
2013-10-31 19:08 ` Felipe Contreras
2013-10-31 9:25 ` [PATCH 05/16] revision: add missing include Felipe Contreras
2013-10-31 18:11 ` Junio C Hamano
2013-10-31 9:25 ` [PATCH 06/16] shortlog: add missing declaration Felipe Contreras
2013-10-31 19:05 ` Junio C Hamano
2013-10-31 19:33 ` Felipe Contreras
2013-10-31 20:07 ` Junio C Hamano
2013-10-31 21:17 ` Felipe Contreras
2013-10-31 9:25 ` [PATCH 07/16] branch: trivial style fix Felipe Contreras
2013-10-31 20:46 ` Junio C Hamano
2013-10-31 9:25 ` [PATCH 08/16] sha1-name: trivial style cleanup Felipe Contreras
2013-10-31 9:25 ` [PATCH 09/16] transport-helper: trivial style fix Felipe Contreras
2013-10-31 9:25 ` [PATCH 10/16] describe: trivial style fixes Felipe Contreras
2013-10-31 9:25 ` [PATCH 11/16] pretty: trivial style fix Felipe Contreras
2013-10-31 9:25 ` [PATCH 12/16] revision: trivial style fixes Felipe Contreras
2013-10-31 9:25 ` [PATCH 13/16] diff: trivial style fix Felipe Contreras
2013-10-31 9:25 ` [PATCH 14/16] run-command: trivial style fixes Felipe Contreras
2013-10-31 9:25 ` [PATCH 15/16] setup: " Felipe Contreras
2013-10-31 20:48 ` Junio C Hamano
2013-10-31 9:25 ` [PATCH 16/16] add: avoid yoda conditions Felipe Contreras
2013-10-31 19:48 ` Martin von Zweigbergk
2013-10-31 19:56 ` Felipe Contreras
2013-10-31 20:31 ` Junio C Hamano
2013-10-31 20:42 ` Felipe Contreras
2013-10-31 18:03 ` [PATCH 00/16] Trivial patches Max Horn
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=xmqqr4b1425c.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
/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).