On Thu, Oct 31, 2013 at 5:40 PM, David Aguilar <dav...@gmail.com> wrote:
> On Thu, Oct 31, 2013 at 03:16:57PM -0600, Felipe Contreras wrote:
>> On Thu, Oct 31, 2013 at 2:43 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> > Junio C Hamano <gits...@pobox.com> writes:
>> > The other reason the original did not say "origin/master" is because
>> > this holds true even if you do not have such a remote-tracking
>> > branch for the master at the origin, but the illustration that shows
>> > the history after "git pull" finishes spells remotes/origin/master
>> > out, so I think it would be an improvement to make the two pictures
>> > consistent by drawing where the origin/master is before this "git
>> > pull" is run.
>> So you care about "reality" when it fits your argument, but not when
>> it doesn't. Got it.
> What exactly do these flippant remarks accomplish?
> Keep these to yourself. No one deserves this treatment nor does
> anyone care to read it.
Nobody is forcing you to read them.
However, they happen to be true. Junio used as an argument that
'origin/master' is not better than 'master on origin' because the
"real" 'origin/master' might be pointing to something else, however,
when he himself realized that 'origin/master' might not exist at all,
then suddenly the "real" 'origin/master' is not so important.
If this was a rational discussion I would ask you to point out where
exactly the previous explanation is incorrect, but alas, if experience
serves, this is not one of those.
The facts are very simple, Junio's proposal:
A---B---C master on origin
origin/master in your repository
1) The user did 'git pull origin', not 'git pull $url', or any other remote
2) 'origin/master' points to E, which might not be true, the user
might have issued a 'git fetch', or a previous pull might have been
Both issues are overridden by the comment "Assume the following
history exists", so one has to assume that origin/master points to E,
but if one assumes that, then my proposal is also correct:
Because one has to assume that 'origin/master' points to C, which is
entirely possible. But more importantly, for the purposes of
explaining 'git pull' it lightens the mental load needed by the user.
Either Junio's argument applies to both proposals, or none, but
selectively cherry-picking where the argument applies is akin to a
feminist that argues men and women are equal, but men should pick the
check in a restaurant.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html