Re: git-migration: Changes to 'master'
On Tue, Jan 09, 2007 at 09:35:01AM +0100, Michel Dänzer wrote:
> On Mon, 2007-01-08 at 22:08 -0500, David Nusinow wrote:
> > On Mon, Jan 08, 2007 at 09:06:19PM -0500, David Nusinow wrote:
> > > Is this worth the overhead of maintaining the upstream branches? I'm not
> > > sure. Currently, our deltas from the usptream releases aren't that big for
> > > anything but the server, so this really may not be worthwhile. I tend to
> > > just look through the whole log and debian/changelog myself, so I'm not
> > > sure I'd even use the upstream branch for this. What does everyone else
> > > think? Is this just another vendor branch that we really don't need? I'm
> > > struggling to come up with another usage case for it, which probably means
> > > that the idea is flawed.
>
> I think the upstream-* branches would be useful for visualizing the
> relation between upstream and Debian history, e.g. using gitk, which is
> something SVN couldn't provide.
Ok, let's just keep them then. If we decide to stop using them, it should
be just as easy as it was to stop using the vendor branches.
> > Ok... more brainstorming. The easiest method of dealing with moving changes
> > around in git is to pull or push them all. Cherry-picking is supported, but
> > it's not really the ideal model. So here's how you would create a change
> > destined for upstream and get it upstream using a pull/push-only method.
> > Say it's going to unstable and it's going to implement our Rock 'n Roll
> > feature.
> >
> > 1) Create local branches of debian-unstable and upstream-unstable. Call
> > them debian-rock and upstream-rock. No one will see these branches but
> > you in this scenario.
> >
> > 2) Make your changes of interest to the code in the upstream-rock branch.
> > Pull them in to debian-rock when you're ready to go.
> >
> > 3) Oops! We screwed up. You can either git-revert, git-reset, or just fix
> > your commit.
> >
> > 4) Re-checkout debian-rock, and merge upstream-rock again.
> >
> > 5) Build 'n test. Yay! Success! We're now ready to bring the rock.
> >
> > 6) Check out upstream-unstable. Pull the changes from upstream-rock.
> >
> > 7) Pull upstream-unstable in to debian-unstable.
> >
> > 8) Build, test, upload. Yay! It looks like our users are rocking out!
> > We're ready to let the rest of the X world experience the rock.
> >
> > 9) Pull upstream-unstable in to your local copy of upstream's HEAD. You'll
> > want to make sure it merges properly. Then push it to freedesktop.org.
>
> The procedure looks good to me, but I suspect the "Merge branch
> 'upstream-unstable'" commit may not be that useful in the upstream repo,
> so cherry-picking might be better than merging in the last step.
The problem with cherry-picking is that it would be a pain to cherry-pick a
ton of changes, if your branch is a bit more substantial. That was Drew's
scenario, and I thought it was worth figuring out if it was possible to
make that easier to deal with. For simple changes though, I think you're
right and I'd probably cherry-pick as well.
- David Nusinow
Reply to: