Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 22, 2013, 22:12 UTC
Message-ID: <CAMP44s3jJRt8Jd6_oMwGBEj31ddQvHJukfYr8ySrk_zBaTjCPA@mail.gmail.com>
In-Reply-To: <7vtxlvj6vq.fsf@alter.siamese.dyndns.org>

On Wed, May 22, 2013 at 11:50 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> She told Git that her local svn-branch was the basis for svn-next. She
>> DIT NOT TELL Git to fetch from there. She told Git to fetch from any
>> location Git thought best to fetch from, either a) or b) would fetch
>> from the wrong location, but a) would be wronger, you just don't want
>> to admit it.
>
> "(a) is more wrong" is just your opinion, and you are simply wrong.

My opinion based on very solid grounds; the whole purpose of 'git fetch; is to FETCH from a REMOTE. a) is not doing that at all.

In addition, the vast majority of users don't have a clue as to what  the hell

>From .

        * branch            master     -> FETCH_HEAD

means.

a) is wronger. Period.

You say it's not, but give no explanation at all. This is no way to argue.

Show 8 quoted lines

> She is working on svn-ext based on her local git-svn the latter of
> which has some changes of her own on top of Eric's tree.
>
> When working on _any_ branch that bases its work on something else,
> you have @{u} available, but that @{u} will not stay up-to-date if
> you forked from work that is done outside your repository.  That is
> what an unqualified "git fetch" is designed to help when run on a
> branch that bases its work on something else.

The fact that it's designed that way doesn't mean it's a good design, and it doesn't mean the user expects that.

> If you happen to know
> that yoru current branch is forked from git-svn that is a local
> branch,

That's a very big *IF*.

> then running "git fetch" becomes unnecessary for the purpose
> of updating @{u} (it already and always is up to date), so doing no
> object transfer and no ref update is absolutely the right thing to
> do.  That is what "remote = ." gives you.

Jumping to conclusions based on assumptions again.

Sally doesn't know what the designers intended, Sally doesn't remember what is the upstream of the current branch, of it has any upstream at all. Sally does 'git fetch' instinctively, and expects Git to do the right thing, but it doesn't, it does an utterly irrelevant and useless action; non-fetching from a local-remote.

> In addition, that does not break the "pull = fetch + merge"
> equivalence you seem to be ignoring.

Do you want me to count to you the many times I've proved to you that pull is NOT fetch + merge?

YOU are the one ignoring the fact that it's not: it's only that way in very specific circumstances, certaily ver far from being a universal truth.

Show 5 quoted lines

> If she wants to check what Eric has been doing, she can do "git
> fetch git-svn", giving the remote name she calls Eric's tree with.
> At that point, she is not saying "I want to check what is happening
> to the upstream of my _current_ branch" (and the fetched result is
> not something she can immediately use while on her current branch).

Irrelevant.

> On the other hand, an unqualified "git fetch" that slurps from my
> tree, which is your (b), is just plain wrong.

But that's *EXACTLY* what we do when there's no upstream branch, is it not?

> My tree is not even
> related to what she is working on.

Unless you are prepared to say fetching from any other tree that @{u} is wrong, and 'git fetch' should forbit it, this is irrelevant.

The user can fetch from wherever they want.

> Of course, when she is interested in what have been happening in my
> tree, she can say "git fetch origin".

Irrelevant. We are not changing that behavior.

-- 
Felipe Contreras