Re: git-migration: Changes to 'master'
Hi Drew,
On Thu, Jan 04, 2007 at 02:25:05PM +1100, Drew Parsons wrote:
> David asked:
> > > URL: ssh://git.debian.org/git/pkg-xorg/$debian.git
> > > -Pull: refs/heads/master:refs/heads/master-origin
> > > +Push: refs/heads/master:refs/heads/debian-unstable
> > > +Push: refs/heads/upstream-master:refs/heads/upstream-master
> >
> > Why did you use 'upstream-master'? I probably was unclear in what I wrote
> > down, looking back on the draft. What I had in mind was
> > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that
> > this is the best way to divide up the branches though. Do you think having
> > 'upstream-master' is a better way of handling things?
>
> The way I understood it, we wanted our copies of the upstream branches
> to keep their own upstream names verbatim but with an "upstream-"
> prefixed to avert name clashes. Otherwise it would get really
> confusing figuring out which of our "upstream-" branches corresponds to
> which actual branch upstream.
I'm not really sure if that would work out. Aside from master, there's no
really long-lived branches from upstream, so if we were to use any of the
other branches from upstream, we'd have to re-create it every time we
wanted to use a different short lived topic branch with a new name.
Even harder would be if we wanted to pull from multiple topic branches
(which is something I'm thinking about doing for the server). The thought
of having upstream-pci-rework-randr1.2-for-server-1.2 sounds really
horrendous to me :-)
I had envisioned that if you want to know which upstream version we pulled
from, you can just checkout the appropriate upstream branch and run git
log.
If you do want to map by name what version we're shipping, we could use the
tag name (upstream-1.2 for example), but then we'd have to create a new
upstream branch every time upstream makes a new release, which would
quickly get ugly. Besides, that's why we have tags anyway.
The idea behind having a simple 1:1 mapping between our debian branch and
the upstream branch at least makes it simple on our end to see what
upstream version maps to what debian distro. You can check out the
upstream-unstable, check the log, and know that that's what's in unstable.
Granted, checking the log isn't instant recognition, but it prevents us
from having too many branches getting out of control.
Please correct me if I'm misinterpreting you. I wouldn't be surprised if I
missed something in your message.
> On a different note, if we're forgoing a "master" branch in favour of
> debian-unstable, then when I run git clone, which branch will present
> by default, will it be debian-unstable?
That's the idea. I'm setting up the beryl repositories right now according
to this system, and I'm setting HEAD to be debian-unstable by default. I'm
currently using upstream-unstable to import the upstream source, but if we
decide to use upstream-master (or whatever else) it'll pretty trivial to
create the new branch and delete the old one.
- David Nusinow
Reply to: