Dear diary, on Thu, Jul 28, 2005 at 06:52:45PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> 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.
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
