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

Shawn Pearce [off-list ref] 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?

I'm leaning towards the repo config for the latter, with say:

	[branch "pu"]
		rewinds = true
		description = This branch contains some proposed updates to git.\n\
	It rewinds often, as different updates are proposed or merged into 'next'.

but looking at that think its rather horrible looking.  :-)

However for the former it may be useful if the client can download
the repo config from the remote repository, such as to fetch
the branch description data.

For the former, I was hoping that we could do a new action
against remote repository that is "get remote information". Just
like we have "ls-remote" as a protocol neutral front-end to get
what git native protocol would give "peek-remote", git native
protocol would have get-repository-info action to transfer this
information, and http and dumb transports do a file download
from a known file, just like they download files prepared with
update-server-info.  Most likely, that get-repository-info is
just a glorified single file transfer and nothing more.

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.

	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.

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.

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.

 * Dumb transports would just do a file transfer, and we add a
   new command (like "upload-pack", "upload-archive") for git
   native transport to read that file.  We might want to have a
   protocol neutral wrapper (just like "ls-remote").

 * Cloners and fetchers would do the file transfer and use
   repo-config to read from that transferred file to find out
   which are rewinding branches.