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

[Shawn Pearce <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> > So now we're at a point of:
> >
> >  * how do we get this branch information from the remote?
> >  * how does the remote store this branch information?
> 
> For the former, I was hoping that we could do a new action
> against remote repository that is "get remote information".

Yes, that is completely sane.  :)
 
> As an implementation detail, I think it is one possibility to
> store this information in the config of the repository being
> cloned from.  We should be able to use repo-config to
> parse that file in config-like syntax to extract what we would
> want, so we do not have to come up with a new syntax nor a new
> parser, which is a big plus.

Also quite sane.  Nobody wants to write new code if we don't really
have to. :)

> 	Side note: repo-config, especially the updating side of
> 	it, is one of the programs I find the most brittle in
> 	the whole system, and it always makes me hesitate when
> 	somebody proposes to use config file in any important
> 	way read-write for this reason.  But this "reading out
> 	per-branch information from the file" is read-only so I
> 	would not worry too much about it.

Now you tell me.  git-gui uses repo-config for all of its option
data.  It writes back to the config file to save user configured
options, including window layout at quit.  It also uses both the
user global and the local repository config files. :)

We can safely update the index, symrefs and refs.  Why can't we
also safely update the config file?  The biggest problem is its
also a hand-modified file complete with support for comments,
so users expect the file to stay intact during edits.  Aside from
that little issue its really a fairly simple format...

> Strictly speaking, however, the config file is a wrong place to
> store it.  For one thing it has core.sharedrepository and
> receive.denynonfastforwards that are true configuration to
> control the behaviour of git _at_ _the_ _repository_ the
> configuration is at.  The new "branch property" are primarily to
> help the other end, and the "filtering rewinding ones" we want
> at the clone/fetch side wants that information only and not
> interested in the true configuration information at that
> repository.

Yes, of course.  I never suggested copy the entire configuration
as is.  What we really want to do is take the branch data from the
remote and rewrite it for every branch we fetched into a ref, e.g.:

  remote:
    [branch "master"]
        rewinds = false
        description = blah blah

  local:
    [branch "remotes/origin/master"]
        rewinds = false
        description = blah blah

while skipping other configuration sections and options that have
no meaning for the local repository.  core.sharedrepository is just
one of *many* configuration options that the local repository should
not inherit.  remote.<name>.url is another...  etc.

> So my preference is:
> 
>  * store it in a fixed filename under $GIT_DIR/$something, in a
>    format that is similar to the true config file.

At which point you might as well put it into $GIT_DIR/config.
People are going to use git-repo-config to edit that file, even if
you say its brittle and maybe shouldn't be used for heavy editing.
Its just damn handy.
 
Besides of which, lets not forget that something like:

  [branch "master"]
      rewinds = false
  [branch "pu"]
      rewinds = true

is not only data for the client to examine.  It can be useful in
say git-receive-pack as a much more fine-grained alternative to
receive.denynonfastforwards.  If the server's policy is to not
rewind a branch then receive-pack shouldn't let a remote user
rewind it.  At which point its useful to have that branch data
in $GIT_DIR/config.  :-)

--