On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
> > On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> >>
> >>> Junio already sent a similar patch, but I think this is simpler.
> >>
> >> I agree that this is simpler, but I am not sure if the behaviour is
> >> necessarily better (note that this is different from saying "I think
> >> the behaviour of this patch is worse"). The motivation I read from
> >> the original discussion was that new people did "git pull" (no other
> >> parameters) to "sync my tree with the central repository" as if it
> >> were SVN, and because we are not SVN, projects that prefer rebases
> >> were unhappy, and the other one was to address *only* that use case.
> >> I do not personally like that special casing (i.e. "only when no
> >> 'integrate with what from where' is given"), and applying the "you
> >> must be explicit between rebase and merge" like this series does
> >> uniformly might (or might not) be a good thing. I dunno.
> >
> > As I already said; there's is essentially no difference between "git
> > pull" and "git pull origin".
>
> We know what you said earlier. That does not make it right or wrong,
> but I do not think it is in line with the original discussion (that
> is why John Keeping is kept on the Cc: line).
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong thing to do since it will be
backwards and break --first-parent.
But for (2) a merge is almost always the correct thing to do (in fact it
may even be correct to create a merge commit even when this fast
forwards) because this most likely comes for a pull request workflow.
> I do not think we know what we want is to affect "git pull origin".
I consider "git pull $remote" to be an artifact of the way git-pull is
implemented on top of git-fetch; perhaps I'm missing something but I
can't see a scenario where this is useful. In the series currently in
"next", we treat this as (2) above but that's primarily because it is
difficult to differentiate these in git-pull.sh without adding code to
understand all of the options to git-fetch (or at least those that can
accept unstuck arguments).
Changing this so that "git pull $remote" is treated as (1) would be
better, but I think it is more important to avoid catching case (1) in
the same net which is why jc/pull-training-wheel simply checks if "$#"
is zero; the cost of getting this completely right outweighed the
benefit of getting code in that will catch 99% of users.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html