Re: git-migration: Changes to 'master'
On Sun, Jan 07, 2007 at 08:38:08PM +1100, Drew Parsons wrote:
> Michel 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:
> > > > >
> > > > > 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.
>
> Yeah, Michel is probably right, it seems I don't really understand what the
> intention with the upstream branches is. I had thought the idea was to
> facilitate pushing patches back to upstream, but if they are a merged
> amalgum of multiple upstream sources then this wouldn't work so well.
>
> The wiki doesn't seem to explain the meaning of the upstream branches.
> Could you explain the motivation for them again?
Sure, sorry about that. Let me try again. I'll clean up the wiki tonight
also.
The reason for using upstream branches is twofold:
1) git-buildpackage expects to have it. It's nice to actually have access
to this tool where we couldn't use svn-buildpackage, although there's
still a few things I'd like to iron out.
2) It lets us easily separate the code and the packaging. It seems to be
the standard recommendation in the git world to make extensive use of
topic branches to do your work, and then pull in changes from a trusted
source. This essentially makes our repo set up so that we have a topic
branch for the upstream code that we ship and a topic branch for the
packaging. This should avoid problems with merging in the future.
3) Because we can't figure out a way to set things up so that when you
clone the alioth repo, you get a branch cloned from freedesktop also,
this ensures that people at least get some standard upstream branch
that we can use.
The upstream branches aren't strictly necessary. We could potentially patch
git-buildpackage to work without an upstream branch if we want. But after
working with git's pull everything by default model for a little while, and
seeing how you're supposed to use the cheap branching to avoid problems, I
feel like we should hedge our bets and separate the code work from the
packaging.
I hope that's a little clearer. If I'm off my rocker (I'm definitely no git
expert) then let's figure out why and fix this before we make the move.
- David Nusinow
Reply to: