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

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:

> Now separate-remote layout is the default for newly cloned
> repositories, I think it is a good time to make further effort
> to make things easier to use.  Here are some of the ideas off
> the top of my head.
[...]
> * Change the default contents of $GIT_DIR/remotes/origin

The question is: do we continue to use remotes/ file, or do we
save remotes info in the config file: remote.<name>.url,
remote.<name>.fetch, remote.<name>.push and branch.<name>.merge
(in our case '[remote "origin"]' section)?
 
> Currently we list all the remote branches that exist when the
> clone is made, making sure that the branch pointed at by HEAD at
> the remote is listed first.  The intent is to track every branch
> at the remote but merge in the "primary" branch to us.
> 
> Two issues that have been raised about this is:
> 
>  - the intent to track every branch is good, but the current
>    implementation means we would not notice new branches at the
>    remote.
> 
>  - merging the "primary" branch is good only when the user is on
>    the corresponding "primary" branch.  It is usually a wrong
>    thing to do when on another branch.
> 
> The first issue can be solved, with the help of recent "glob
> pattern refspec in fetch" from Andy.  I am thinking about making
> the default contents of $GIT_DIR/remotes/origin to be:
> 
>       URL: <url of the cloned repository>
>       Pull: +refs/heads/<primary>:refs/remotes/<origin>/<primary>
>       Pull: +refs/heads/*:refs/remotes/<origin>/*
> 
> to address this issue.

I hope that it also works with the remote.origin config file
section instead of $GIT_DIR/remotes/origin

>       Side note: <primary> is what HEAD pointed at at the
>         remote when the clone was made, and <origin> is usually
>         'origin' but "git clone -o $origin" can override it.
> 
> Forcing with '+' is debatable, but with separate-remote layout,
> remotes/*/ hierarchy is to track what the remote has, and you
> cannot do much else other than noticing and warning when the
> remote end does funny things to its refs anyway, so I think
> having '+' might be a better default.

Perhaps, perhaps not. It would be nice to have configuration option
that would tell that history of given branch is being changed, and
the ability to ask about it remotely, so git-clone would be able
to add this + _when needed_ automatically.

But it's a fact that with separate remote the need to use fast-forward
check is lessened, and it might be more important to not confuse first
time user with having to modify $GIT_DIR/remotes/origin or remote.origin
config section to fetch from the repository he/she cloned from.

> The right thing to do to address the second issue is less clear.
> If the "upstream" has two more-or-less equally prominent
> branches, say 'main' and 'test', it may make sense to use
> corresponding two branches on the local side and merge 'main'
> from the remote when on local 'main' and merge 'test' when on
> local 'test'.  Even when dealing with a specific topic branch,
> that would hold true for most of the time.  A topic branch
> refs/heads/bug#2073 to work on the bug 2073 can be published at
> the central distribution point.  The proposed updates to
> $GIT_DIR/remotes/origin file would track it with
> refs/remotes/origin/bug#2073 and interested people can create a
> local branch refs/heads/bug#2073 from it and work on it, which
> makes it easy to polish a topic branch in a collaborative way.
> 
> I am not sure if 'merge in corresponding branch' is the only
> valid workflow, however. I am reluctant to make the system
> automatically do so if the solution makes other workflows more
> painful to follow.  Automatically merging remotes/origin/$foo
> when on $foo branch is not good enough, in other words (also,
> there may be a hierarchy under remotes/ other than origin).  It
> might make sense to introduce "Merge: " in remotes/ file and if
> they are present use "Pull: " only to decide what are fetched
> and use "Merge: " to decide what is merged (if we were doing the
> system from scratch, the former would have been named "Fetch: "
> but it is too late now).

If you add "Merge: " in remotes/, then please add it also in
remote section in config file. Config file has now 
branch.<branchname>.merge (and it would be nice if clone would
set ou this for local branches corresponding to remote branches),
but it is not the same.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git