Re: [RFC] pull/fetch rename

From: Thomas Rast <trast@student.ethz.ch>
Date: Oct 22, 2009, 09:48 UTC
Message-ID: <200910221148.28335.trast@student.ethz.ch>
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 12 quoted lines

> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> 
> > So that's ten days of #git. I left out a bunch of duplications (most
> > were "pull == fetch", "pull == update" and "pull to update
> > non-checked-out branch").
> 
> Interesting; this shows that people who do not understand what "pull" does
> expect different behaviour from "pull", use the word "pull" to express
> what they want to happen, expect other people interpret the word to mean
> the way they think it does.  At the same time, judging from different
> behaviour expected by these people, push/pull asymmetry does not seem to
> have much to do with the confusion.

This of course is where our conclusions differ. I haven't counted them, but Björn (thanks again for the excellent survey) points out that most duplicates are confusion with fetch, (imagined) update or "update to not checked out branch".

Pull is none of these, but if it was (current) fetch, at least the first group of people would have had the right idea of what it does.

> I am actually even Ok, at least in the long run (like in 3 years), if we
> were to deprecate the refspecs with colon given on the command line to
> "pull" and "fetch" altogether [*1*].

As an aside, there are actually some use-cases, e.g., to grab the git-svn refs from a freshly cloned repository you would run:

  git fetch origin refs/remotes/*:refs/remotes/*

(and then 'git svn init' etc.) I've also had some weird requests on IRC that could be solved by clever (and of course dangerous) use of 'git fetch . glob:otherglob'.

Hiding that power behind an option could be a good idea though.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch