Nicolas Pitre [off-list ref] writes:
But again I think it is important that the URL to use must be a per
branch attribute i.e. attached to "default/master" and not just
"default". This way someone could add all branches of interest into the
"default" group even if they're from different repositories, and a
simple get without any argument would get them all.
I think the "one group per one remote repository" model is a lot
easier to explain. At least when I read your first "branch
group" proposal that was I thought was going on and I found it
quite sensible (and it maps more or less straightforwardly to
the way existing .git/refs/remotes is set up by default).
On 2006-11-15 13:11:36 -0500, Nicolas Pitre wrote:
On Wed, 15 Nov 2006, Junio C Hamano wrote:
quoted
Nicolas Pitre [off-list ref] writes:
quoted
But again I think it is important that the URL to use must be a
per branch attribute i.e. attached to "default/master" and not
just "default". This way someone could add all branches of
interest into the "default" group even if they're from different
repositories, and a simple get without any argument would get
them all.
I think the "one group per one remote repository" model is a lot
easier to explain. At least when I read your first "branch group"
proposal that was I thought was going on and I found it quite
sensible (and it maps more or less straightforwardly to the way
existing .git/refs/remotes is set up by default).
I think one group per remote repo is how things should be by default
too. But we should not limit it to that if possible.
Without the limitation, we risk name collisions when getting all
branches from the remote repository (that is, including any new
branches we previously didn't know about).
--
Karl Hasselström, kha@treskal.com
On Wed, 15 Nov 2006, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
But again I think it is important that the URL to use must be a per
branch attribute i.e. attached to "default/master" and not just
"default". This way someone could add all branches of interest into the
"default" group even if they're from different repositories, and a
simple get without any argument would get them all.
I think the "one group per one remote repository" model is a lot
easier to explain. At least when I read your first "branch
group" proposal that was I thought was going on and I found it
quite sensible (and it maps more or less straightforwardly to
the way existing .git/refs/remotes is set up by default).
I think one group per remote repo is how things should be by default
too. But we should not limit it to that if possible.