Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

Petr Baudis [off-list ref] writes:

AFAIK the plan is to centralize all the kernel repositories to a single
one. For that, developers would generally push into branches with name
different that "master".

I did not know about that plan, but that is interesting and now
I understand why you think it is important to be able for more
than one person to push into a single repository.

How will the namespace of N-hundred branches in that repository
be managed?  To avoid collisions, wouldn't there be some
coordination, and there will be branch names there that
everybody agrees that they are owned by you?

At that point, wouldn't it be easier for _you_ (as one kernel
developer who owns such globally unique branch names) to name
your branch you intend to push there the same way in your
working repository as well?

Hi,

On Thu, 28 Jul 2005, Junio C Hamano wrote:

Petr Baudis [off-list ref] writes:

quoted

AFAIK the plan is to centralize all the kernel repositories to a single
one. For that, developers would generally push into branches with name
different that "master".

I did not know about that plan, but that is interesting and now
I understand why you think it is important to be able for more
than one person to push into a single repository.

Is it possible that those plans only mean to centralize .git/objects/ and
leave the rest in single repositories? Seems much more sensible to me.

Ciao,
Dscho

Dear diary, on Thu, Jul 28, 2005 at 06:52:45PM CEST, I got a letter
where Junio C Hamano [off-list ref] told me that...

Petr Baudis [off-list ref] writes:

quoted

AFAIK the plan is to centralize all the kernel repositories to a single
one. For that, developers would generally push into branches with name
different that "master".

I did not know about that plan, but that is interesting and now
I understand why you think it is important to be able for more
than one person to push into a single repository.

For that particular thing, this is only part of the motivation. The much
bigger part of the motivation are projects which don't have a central
maintainer but where group of people needs to be equal in access to a
central repository. That's actually vast majority of larger projects, I
think.

How will the namespace of N-hundred branches in that repository
be managed?  To avoid collisions, wouldn't there be some
coordination, and there will be branch names there that
everybody agrees that they are owned by you?

You could name your branches e.g. "davej/agpgart", "davej/cpufreq", etc.
But those proposals of central repository were certainly quite
preliminary, and perhaps I overstated saying "the plan is".

At that point, wouldn't it be easier for _you_ (as one kernel
developer who owns such globally unique branch names) to name
your branch you intend to push there the same way in your
working repository as well?

And if you are cloning locally or whatever, you have to mention the
branch name explicitly.

One of the Cogito design bits is that branch name is something local to
the repository. When you are adding a branch, the local name you assign
it is your private thing repository-wise, and doesn't have to have any
correlation to other repositories you might interact width.

As I already argued, this helps when you are importing someone else's
master as your branch called whatever (obviously not master), and if you
have to deal with two remote branches with the same name (such a
conflict is bound to happen and bound to be vulnerable to be a huge
hassle). That also applies to pushing, you might be pushing to multiple
repositories - say you are working on some cool kernel stuff for SuSE,
so you might want to push to kernel.org _and_ into the deep bowels of
some SuSE kernel infrastructure (whatever - I'm not familiar with those
things yet if you are now drooling to get some insight about how this is
working in SuSE].

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Hi,

On Thu, 28 Jul 2005, Petr Baudis wrote:

For that particular thing, this is only part of the motivation. The much
bigger part of the motivation are projects which don't have a central
maintainer but where group of people needs to be equal in access to a
central repository. That's actually vast majority of larger projects, I
think.

Are you really sure you want to slave git into being a "better
Subversion"? IMHO, if you need a central repository, you should also have
one central HEAD.

Just my tucence,
Dscho

On Thu, Jul 28, 2005 at 07:32:55PM +0200, Johannes Schindelin wrote:

Is it possible that those plans only mean to centralize .git/objects/ and
leave the rest in single repositories? Seems much more sensible to me.

I think that's accurate.  It can be done without the repositories even
really noticing if "git relink" is used aggressively to migrate
hard links into the repository regularly.  (Though, "packs" cause some
confusion in that scheme, I think.)


-- 

Ryan Anderson
  sometimes Pug Majere

Hi,

On Thu, 28 Jul 2005, Ryan Anderson wrote:

On Thu, Jul 28, 2005 at 07:32:55PM +0200, Johannes Schindelin wrote:

quoted

Is it possible that those plans only mean to centralize .git/objects/ and
leave the rest in single repositories? Seems much more sensible to me.

I think that's accurate.  It can be done without the repositories even
really noticing if "git relink" is used aggressively to migrate
hard links into the repository regularly.  (Though, "packs" cause some
confusion in that scheme, I think.)

I guess that's where git-daemon comes into play.

Ciao,
Dscho

Hi, Johannes Schindelin wrote:

Are you really sure you want to slave git into being a "better
Subversion"?

Since git is better than all of these, we should be able to easily write a
SVN-like porcelain, so ... ;-)

IMHO, if you need a central repository, you should also have
one central HEAD.

I disagree. Larger projects have multiple HEADs (stable, oldstable,
development, ...). I don't like putting those in different repositories,
you end up with a heap of housekeeping effort to hardlink duplicate
objects, all of which is going to be wasted when different people run
"git repack".

Not everybody has 100-GB disks and multi-MB Internet pipes to play with...

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
On ability:
	A dwarf is small, even if he stands on a mountain top;
	a colossus keeps his height, even if he stands in a well.
		-- Lucius Annaeus Seneca, 4BC - 65AD

Hi,

On Thu, 28 Jul 2005, Matthias Urlichs wrote:

Hi, Johannes Schindelin wrote:

Since git is better than all of these, we should be able to easily write a
SVN-like porcelain, so ... ;-)

Sorry, you're correct.

quoted

IMHO, if you need a central repository, you should also have
one central HEAD.

I disagree. Larger projects have multiple HEADs (stable, oldstable,
development, ...). I don't like putting those in different repositories,
you end up with a heap of housekeeping effort to hardlink duplicate
objects, all of which is going to be wasted when different people run
"git repack".

Sorry again. I should have been clearer: If you have a larger project
which does have production releases which have to be patched for a while,
and thus need several branches, then there is still a *very good* reason
not to play games with the names of those branches or the tags.

Naming the remote HEAD differently than the local HEAD is just *wrong*
when you want to push back to them. I agree that it is a fine intellectual
challenge to keep juggling a few remote HEADs, and throw in a few local
HEADs, but all that is *complicated*. And complicated things lead to
complications.

BTW I am a Jeff, I use git branches extensively in two projects.

The only sane way if you have to have different local and remote HEADs
that I can think of, would be to allow only the current local active HEAD
to be pushed to a certain remote HEAD (preferably identified by a file in
.git/branches).

Ciao,
Dscho

Petr Baudis [off-list ref] writes:

One of the Cogito design bits is that branch name is something local to
the repository. When you are adding a branch, the local name you assign
it is your private thing repository-wise, and doesn't have to have any
correlation to other repositories you might interact width.

I do not disagree with that.  I think branch name is mostly a
local matter.  However, I happen to think that two repositories
you use send-pack (not clone which uses completely different
protocol) to sync one from the other are semantically equivalent
ones, except that the destination may be a strict subset.  I
think of it as "a copy I throw at a public place to show what I
have in my private repository I work in", so,...

Dear diary, on Fri, Jul 29, 2005 at 04:24:40AM CEST, I got a letter
where Junio C Hamano [off-list ref] told me that...

Petr Baudis [off-list ref] writes:

quoted

One of the Cogito design bits is that branch name is something local to
the repository. When you are adding a branch, the local name you assign
it is your private thing repository-wise, and doesn't have to have any
correlation to other repositories you might interact width.

I do not disagree with that.  I think branch name is mostly a
local matter.  However, I happen to think that two repositories
you use send-pack (not clone which uses completely different
protocol) to sync one from the other are semantically equivalent
ones, except that the destination may be a strict subset.  I
think of it as "a copy I throw at a public place to show what I
have in my private repository I work in", so,...

Aha, so it seems our problem is hopefully only in terminology, great.

So, what do you mean by "clone" here? And what command should I use for
pushing then?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Dear diary, on Thu, Jul 28, 2005 at 10:14:35PM CEST, I got a letter
where Johannes Schindelin [off-list ref] told me that...

Hi,

Hello,

Naming the remote HEAD differently than the local HEAD is just *wrong*
when you want to push back to them.

But you might not know that in advance. That's one of they key points of
the distributed systems, after all - when you are cloning, you needn't
know in advance that you will want to do local commits, and don't need
upstream approval. You also might not know in advance that you will want
to push them back. Sure, distributed systems are more complicated. If
you don't like complicated things, there's always RCS. ;-)

The only sane way if you have to have different local and remote HEADs
that I can think of, would be to allow only the current local active HEAD
to be pushed to a certain remote HEAD (preferably identified by a file in
.git/branches).

Well, but (if I understand you correctly) that was always the _point_.
It's what I was talking about all the time. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox