Re: git-migration: Changes to 'master'
On Thu, Jan 04, 2007 at 09:38:35AM +0100, Michel Dänzer wrote:
> 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.
Right, sorry about that. I'll explain the upstream* branches in reply to
Drew's mail below a little better.
> > 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. :)
Oooh... cool!
> > > 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.
Right, in this case the upstream-* branches are just tarball imports. We
can probably use git-svn though if we want. In that case, Shawn would have
a local branch that he could name whatever he wanted (Thierry and I seem to
be talking about using upstream-master as a common name though) that he
could fetch the upstream sources from using git-svn. He'd then pull the
tagged release in to upstream-unstable, and push that to alioth. He'd merge
from upstream-unstable in to debian-unstable, and the package would be
built from there.
If he doesn't use git-svn and we stick with just copying in tarballs then
you're right, it's not nearly as useful, but at least the repo would be
organized like all the others. The most important part though is the
ability to use git-buildpackage, which expects an upstream branch.
- David Nusinow
Reply to: