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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> I still haven't received a response: which makes more sense?
>>
>> a)
>>
>>       % git checkout svn-ext
>>       % git fetch
>>       From .
>>        * branch            master     -> FETCH_HEAD
>>       # oops
>>       % git fetch git-svn
>>       % git log ..FETCH_HEAD
>>       % git merge FETCH_HEAD
>>
>> b)
>>
>>       % git checkout svn-ext
>>       % git fetch
>>       From git://git.kernel.org/pub/scm/git/git
>>          680ed3e..de3a5c6  master     -> origin/master
>>       # oops
>>       % git fetch svn-ext
>>       % git log ..FETCH_HEAD
>>       % git merge FETCH_HEAD
>
> I think with the scenario you are following, a) would prepare the
> FETCH_HEAD with her local git-svn branch which is her svn-ext topic
> is based on, but you illustrated it to fetch 'master', which I think
> is a minor typo.
>
> Modulo that typo, the step before the #oops makes perfect sense.  It
> fetched where she told Git her work on svn-ext is based on.
>
> But the step after that does not make much sense in that flow.

You don't get to decide what Sally (I'm naming her) does, all you get
to decide is what Git does.

Sally wants to fetch from the true upstream: svn-ext, but in the
process does by mistake a 'git fetch' *without arguments* (WHICH IS
WHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer:
a) or b).

You whole argument resides on this question, because you assumed the
answer is a), but that's an *assumption*, answer the question and
you'll see why. But your solution to a question that would undermine
your argument is to just ditch it. Great.

> So, the short answer is neither, but a) can be fixed (not in code
> but in the typescript) to make more sense, perhaps like this:

Do not avoid the question.

>     % git checkout svn-ext
>     % git fetch
>     % git log ..FETCH_HEAD
>     % git rebase FETCH_HEAD
>     # The last three can be "git pull --rebase".

If she does 'git pull --rebase', then the whole thing is irrelevant
for the disunion about GIT FETCH WITHOUT ARGUMENTS.

She didn't want to fetch '.', nobody does; she wanted to fetch a real
remote repository.

>     # ok, did Eric do something in the meantime?
>     % git checkout git-svn
>     % git fetch
>     From git://git.bogomips.org/git-svn.git/
>      * branch  master -> git-svn/master
>     % git rebase FETCH_HEAD

This 'git fetch' is irrelevant, because it's not fetching from '.'.

>     # now let's rebuild the svn-ext on top
>     % git checkout svn-ext
>     % git pull --rebase

No fetch without arguments here either.

All these commands are red herrings.

Is it a) or b) or are you just going to never allow your argument to
be challenged? That's a great way to "win" arguments, but a bad one to
arrive to good solutions.

-- 
Felipe Contreras
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]