Re: git-migration: Changes to 'master'
On Wed, 2007-01-03 at 23:02 -0500, David Nusinow wrote:
>
> 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.
I guess there's some confusion about what the upstream-* branches are
supposed to be. I (and apparently Drew) thought they were supposed to be
1:1 copies of the corresponding upstream branches (directly from the
upstream repos with git-fetch). But your description sounds like you
envision merging from upstream into the upstream-* branches instead. I
actually like that idea after thinking about it a bit. E.g. one problem
with the 1:1 copies would be that git-fetch would no longer work after
cherry-picking fixes onto our copies.
> 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.
You don't even need to check out a branch to see its log. :)
> > 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.
AFAICS the beryl repositories don't have merge commits from upstream
repos though, so one still has to figure out which upstream branch(es)
the upstream bits came from, and there's no upstream history. Is that
intended? If so, IMO that would diminish the value of the upstream-*
branches considerably.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Reply to: