Re: [RFD] making separate-remote layout easier to use

[Junio C Hamano <junkio@cox.net>]

Jakub Narebski <jnareb@gmail.com> writes:

> Well, the question is if git-clone would generate appropriate config 
> entries in addition to or instead of $GIT_DIR/remotes/origin file...

What I meant by "irrelevant" is that it is purely syntax.  I
would rather nail down the desired semantics first, and then
worry about the syntax.  We have done remotes/origin file by
default and allowed the same thing specified in configuration
file for people who prefer configuration file, and I do not see
an immediate need to change that.

Only if/when the desired semantics turns out to be too complex
to be expressed in the remotes/ file scheme and at the same time
if configuration file is easier to express the same information,
we should start talking about favoring configuration file over
remotes/ file, and perhaps generating the config entries by
default without generating remotes/.

In either case, I do not think generating _both_ by default is a
bad idea.  They will become out of sync and the user either need
to delete one or the other to avoid confusion.

> By the way, what do you think about extended refspec syntax, namely
> in addition to <remote name>:<local name> it would allow to say
> <remote name>:<local name>:<local branch to merge into>?

I do not think it is reasonable to assume that one remote branch
is to be always merged into one fixed local branch, so that is
too limiting as an extension.  In the configuration file, I
think we already allow the default remote to be fetched from and
remote branches to be merged per branch statically.  A
reasonable thing to do is to see how satisfied users are with
that facility, what they find missing there. Worrying about the
syntax should wait until we know what kind of things need to be
expressed; that can be done both by extending the existing
configuration and/or introducing a new entries in remotes/
files but the point is that is mere implementation detail.