Re: [PATCH] Make git-clone --use-separate-remote the default

From: Junio C Hamano <junkio@cox.net>
Date: Nov 24, 2006, 00:17 UTC
Message-ID: <7vlkm1hf57.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061123234203.GN7201@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 9 quoted lines

>> Even though I fully agree that use-separate-remotes should be
>> the default, to the point that I think we do not even
>> need a backward compatibility option.  People who want to use
>> traditional layout for simple one-remote-branch-only project
>> would not suffer anyway because 'origin' still means origin in
>> the new layout (refs/remotes/origin/HEAD).
>
> I don't know, we still at least need to keep the functionality for
> --bare.

I agree --bare should continue to be a "snapshot mirror"; I am not advocating for the removal of the internal implementation detail such as $use_separate_remote variable.

However, I think having one sane behaviour is the right thing to do for a clone that prepares a repository with a working tree (including the one made with -n option, which only means "do not do the check-out immediately after cloning" for such a repository).

The traditional layout is slightly simpler for a project with the simplest needs (that is, a single upstream repository that has a single 'master' branch), but I do think even that is not an advantage anymore.

With the separate-remote layout, git-fetch would still fetch and update the "origin" (although that is now remotes/origin/master which is pointed at by remotes/origin/HEAD) and the user can still refer to it with "origin". Commands "git-pull origin", "git-pull . origin", and "git-merge origin" all will continue to work the same way as before for such a project as in the traditional layout, and that is why I think we do not need backward compatibility flag in this case.