Re: [RFC] pull/fetch rename

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

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. If the verb used by people who know git to call this operation were "distim", these people would also say "distim" and expect different things from it. I would foresee exactly the same problem if the verb were "update" for that matter.

It is just natural, as everybody learns a new language by listening how others talk and by imitating them.

Another thing I noticed while lurning on the #git channel for the past few days is that too much flexibility actually hurts new people. They do not want flexibility, but want to follow a set recipe. It just overwhelms to get too much flexibility upfront without enough guidance.

And there are too much historical flexibility that remain merely for historical reasons. We more or less killed the concept of separate object store and $GIT_DIR (i.e.one objects/ directory shared between more than one .git/ directories) when we made receive-pack aware of alternate repository information---it used to be that objects/ directory did not belong to a single set of refs/ hierarchy, but now it does and the receiving end of "git push" uses that knowledge to tell the sender what not to send in order to minimize the transfer. We will be gradually killing other kinds of historical flexibility that do not buy much in practice anymore, and that would reduce the issue of overwhelming flexibility.

For example, I am in favor of deprecating the "pull $there $src:$dst" notation. Before we standardized on the separate remote layout, it was sometimes handy to be able to use $dst that is a local branch, but these days, especially when repository $there has remote.$there.fetch mapping configured so that we can compute from $src what remote tracking branch we should store the fetched commit, the flexibility is more confusing than it is useful. "pull $there $src" (and "pull $there $src1 $src2" to build an octopus) should stay, but even there, it probably is a good idea for these notations to start updating remote tracking branches for $src ($src1 and $src2 in the octopus case) if the repository is configured to track them anyway, to match what "pull $there" that uses the default configuration 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*]. The rule will become "if you are going to use tracking branches to store what you fetch, you _must_ always have the tracking mapping defined in remote.$there.fetch configuration, and the location where one particular branch from the remote is stored is always determined by that mapping." It robs us the flexibility to fetch my 'next' and store it to your 'next' branch today and to your 'mext' branch tomorrow, and instead you would need to first fetch and then do an explicit "git branch mext origin/next" if you really want to do so, but I think the flexibility outlived its usefulness --- the primary value of these kinds of flexibility is to experiment with various workflows and UI concepts they allow, but I think we have gained enough experience to start judging what works (and is useful) and what doesn't (and is Ok to make it much more cumbersome to make or even impossible to do).

[Footnote]

*1* Except perhaps when deleting branches from the remote with "push", but even there we _could_ force people to do a deleting push separate from normal push and say "push --delete $there $this $and $that".