Re: [PATCH 03/16] pull: cleanup documentation
On Fri, Nov 1, 2013 at 5:05 AM, SZEDER Gábor wrote: > On Thu, Oct 31, 2013 at 09:50:51PM -0600, Felipe Contreras wrote: >> On Thu, Oct 31, 2013 at 8:48 PM, David Aguilar wrote: >> > On Thu, Oct 31, 2013 at 07:56:03PM -0600, Felipe Contreras wrote: >> >> >> Nobody is forcing you to read them. >> > >> > You're missing the *key* point. >> > No one wants to interact with a rude arrogant loudmouth. >> >> Then don't. Problem solved. > > Nope, it just recreates another old problem. We've been there before, > not long ago: Don't worry. That was the last time I sent those patches. I will only resend the patch series that receive attention. Happy? -- Felipe Contreras -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 09:50:51PM -0600, Felipe Contreras wrote: > On Thu, Oct 31, 2013 at 8:48 PM, David Aguilar wrote: > > On Thu, Oct 31, 2013 at 07:56:03PM -0600, Felipe Contreras wrote: > > >> Nobody is forcing you to read them. > > > > You're missing the *key* point. > > No one wants to interact with a rude arrogant loudmouth. > > Then don't. Problem solved. Nope, it just recreates another old problem. We've been there before, not long ago: On Sat, Oct 12, 2013 at 02:24:50AM -0500, Felipe Contreras wrote: > Clearly, a lot of my patches have not been reviewed properly [...] Best, Gábor -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 8:48 PM, David Aguilar wrote: > On Thu, Oct 31, 2013 at 07:56:03PM -0600, Felipe Contreras wrote: >> Nobody is forcing you to read them. > > You're missing the *key* point. > No one wants to interact with a rude arrogant loudmouth. Then don't. Problem solved. -- Felipe Contreras -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 07:56:03PM -0600, Felipe Contreras wrote: > On Thu, Oct 31, 2013 at 5:40 PM, David Aguilar 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 wrote: > >> > Junio C Hamano 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. You're missing the *key* point. No one wants to interact with a rude arrogant loudmouth. You could have explained this without being sarcastic and annoying. It does not help your cause. Sure, these are "subjective" people skills (that don't "matter" to the code) but this is a social activity. If your defense is to whine and say, "well, people on LKML are rude and flippant all the time!" then that's a lame argument that's not even true. Your patch may in fact be a good one, but your anti-discussions hurt them. Discussion are good, not an insane attack fest. What fun is that? It's s lame. That's all I'm saying. You can defend it but no one cares. Anyways, I'm out to have fun at a party with friends. Try and get out, have fun, and come back when you're not looking for someone to abuse. -- David -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 5:40 PM, David Aguilar 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 wrote: >> > Junio C Hamano 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 / D---E---F---G master ^ origin/master in your repository Assumes that: 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 cancelled 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: A---B---C origin/master / D---E---F---G master 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. -- Felipe Contreras -- 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
Re: [PATCH 03/16] pull: cleanup documentation
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 wrote: > > Junio C Hamano 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. -- David -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 2:43 PM, Junio C Hamano wrote: > Junio C Hamano 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. -- Felipe Contreras -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 2:27 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, Oct 31, 2013 at 1:00 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >>> On Thu, Oct 31, 2013 at 12:11 PM, Junio C Hamano wrote: > Felipe Contreras 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, Merge with C. > and how do the users know what will be merged? They don't, not after they run 'git pull' anyway. > The users need to learn that origin/master they were told to use > with "git log origin/master.." etc. trails reality, Yes, but they don't *need* to learn it *right now*. All they need to learn is that 'git pull' will do a merge with 'master' from 'origin', AKA 'origin/master'. -- Felipe Contreras -- 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
Re: [PATCH 03/16] pull: cleanup documentation
Junio C Hamano writes: > Max Horn writes: > >>> ... The "reality" is more like this: >>> >>> origin/master in your repository >>> | >>> v >>> A---B---C master at origin >>> / >>>D---E---F---G master in your repository >>> >>> if you really want to write origin/master somewhere in this >>> illustration. >> >> Actually, I kind of like that. After just reading the existing >> phrasing in git-pull.txt, I doubt that a newbie would catch the >> difference between "origin/master" and "master at origin". With this >> illustration, it's very clearly conveyed that there is a difference. > > Yeah, after re-reading the part of the documentation with the > illustration replaced with the above, I was coming to the same > conclusion. As Felipe spotted in his response, "A" is not something you already have, so the picture need to look like the amended patch below. 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. Something like this, perhaps. Note that I think "on" sounds funny and it should probably be "at" instead, but this weatherbaloon patch does not change it. -- >8 -- Subject: doc/pull: clarify the illustrations The second illustration that shows the history after "git pull" spelled the remote-tracking branch with "remotes/" prefix, which is not necessary. Drop it. To match the assumption that a remote-tracking branch is used to keep track of the advancement of the master at the origin, update the first illustration that shows the history before "git pull" to show the distinction between the master currently at origin and the stale origin/master remote-tracking branch. Noticed-by: Felipe Contreras Helped-by: Max Horn Signed-off-by: Junio C Hamano --- Documentation/git-pull.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index beea10b..e83f3ce 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -42,6 +42,8 @@ Assume the following history exists and the current branch is A---B---C master on origin / D---E---F---G master +^ + origin/master in your repository Then "`git pull`" will fetch and replay the changes from the remote @@ -51,7 +53,7 @@ result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. - A---B---C remotes/origin/master + A---B---C origin/master / \ D---E---F---G---H master -- 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
Re: [PATCH 03/16] pull: cleanup documentation
Felipe Contreras writes: > On Thu, Oct 31, 2013 at 1:00 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >>> On Thu, Oct 31, 2013 at 12:11 PM, Junio C Hamano wrote: Felipe Contreras 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. -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 1:00 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, Oct 31, 2013 at 12:11 PM, Junio C Hamano wrote: >>> Felipe Contreras 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. >> If you want to be pedantic, this is the "reality": >> >> >> D---E---F---G master >> > > You are wrong again. The "reality" is more like this: > > origin/master in your repository > | > v > A---B---C master at origin > / > D---E---F---G master in your repository > > if you really want to write origin/master somewhere in this > illustration. Wrong. You probably mean: A---B---C master on origin / D---E origin/master \ F---G master But 'master on origin' doesn't exist in "reality" according to you, so: D---E origin/master \ F---G master -- Felipe Contreras -- 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
Re: [PATCH 03/16] pull: cleanup documentation
Max Horn writes: >> ... The "reality" is more like this: >> >> origin/master in your repository >> | >> v >> A---B---C master at origin >> / >>D---E---F---G master in your repository >> >> if you really want to write origin/master somewhere in this >> illustration. > > Actually, I kind of like that. After just reading the existing > phrasing in git-pull.txt, I doubt that a newbie would catch the > difference between "origin/master" and "master at origin". With this > illustration, it's very clearly conveyed that there is a difference. Yeah, after re-reading the part of the documentation with the illustration replaced with the above, I was coming to the same conclusion. -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On 31.10.2013, at 20:00, Junio C Hamano wrote: > Felipe Contreras writes: [...] > >> >> If you want to be pedantic, this is the "reality": >> >> >> D---E---F---G master >> > > You are wrong again. The "reality" is more like this: > > origin/master in your repository > | > v > A---B---C master at origin > / >D---E---F---G master in your repository > > if you really want to write origin/master somewhere in this > illustration. Actually, I kind of like that. After just reading the existing phrasing in git-pull.txt, I doubt that a newbie would catch the difference between "origin/master" and "master at origin". With this illustration, it's very clearly conveyed that there is a difference. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH 03/16] pull: cleanup documentation
Felipe Contreras writes: > On Thu, Oct 31, 2013 at 12:11 PM, Junio C Hamano wrote: >> Felipe Contreras 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. > > If you want to be pedantic, this is the "reality": > > > D---E---F---G master > You are wrong again. The "reality" is more like this: origin/master in your repository | v A---B---C master at origin / D---E---F---G master in your repository if you really want to write origin/master somewhere in this illustration. -- 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
Re: [PATCH 03/16] pull: cleanup documentation
On Thu, Oct 31, 2013 at 12:11 PM, Junio C Hamano wrote: > Felipe Contreras 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. If you want to be pedantic, this is the "reality": D---E---F---G master -- Felipe Contreras -- 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
Re: [PATCH 03/16] pull: cleanup documentation
Felipe Contreras writes: > 'origin/master' is very clear, no need to specify the 'remotes/' prefix, > or babysit the user. > > Signed-off-by: Felipe Contreras > --- > Documentation/git-pull.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt > index beea10b..03a39bc 100644 > --- 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). The next sentence after this picture reads: Then "`git pull`" will fetch and replay the changes from the remote `master` branch since it diverged from the local `master` In other words, your (remotes/)origin/master has _not_ caught up to the reality. > @@ -51,7 +51,7 @@ result in a new commit along with the names of the two > parent commits > and a log message from the user describing the changes. > > > - A---B---C remotes/origin/master > + A---B---C origin/master >/ \ > D---E---F---G---H master > This is a good change, especially in today's world. Thanks. -- 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
[PATCH 03/16] pull: cleanup documentation
'origin/master' is very clear, no need to specify the 'remotes/' prefix, or babysit the user. Signed-off-by: Felipe Contreras --- Documentation/git-pull.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index beea10b..03a39bc 100644 --- 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 @@ -51,7 +51,7 @@ result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. - A---B---C remotes/origin/master + A---B---C origin/master / \ D---E---F---G---H master -- 1.8.4.2+fc1 -- 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
