Re: git-migration: Changes to 'master'
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?
Drew
Reply to: