Re: git-migration: Changes to 'master'
On Mon, Jan 08, 2007 at 02:32:30PM +1100, Drew Parsons wrote:
> David wrote:
> > 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 understand then that the idea behind the upstream branches is not for
> pushing patches upstream as such, but rather is a kind of technical
> convenience. For instance we could use them to generate orig tarballs if
> the ones provided upstream were not available for some reason.
Right, exactly. That's actually what git-buildpackage does right now. I
think it may have a bug where it doesn't properly use the .orig.tar.gz if
it's present though. I need to check this...
> The Debian subdirectory will only appear in the Debian branch, of
> course. Am I correct in understanding that no code patching at all is
> to be done in the Debian branch? Code changes are made to the upstream
> branch which is then merged across to the Debian branch? I can imagine
> a practical problem with this: for me the most convenient way of
> testing my code changes is to generate a test package which I install.
> But if the code changes are in one branch while the packaging is in
> another, this becomes less straightforward. I can think of a couple of
> ways of handling it, for instance copying the Debian directory across
> manually without committing it to the upstream branch, but what did you
> have in mind here?
Right, I don't think it's realistic that we'll be applying code to the
upstream branch first for the reasons you mention. I think what's most
realistic is that we'll do it in a local branch of the debian branch. Then
there's two ways of doing it, either way is fine by me (and I wrote the
proposed policy that way).
1. cherry-pick the change(s) to the upstream branch, then pull from
the upstream branch to the debian branch.
2. pull the changes from your local branch to the debian branch, and then
cherry pick the change in to the upstream branch.
There's not a huge difference between these two methods really.
Unfortunately, I don't think git allows you to "cherry-push" patches, so it
has to be pulled in to the upstream branch. We also can't just pull or push
all the changes from the local debian branch to upstream branch because
then it'll take the packaging with it.
> What procedure do we propose for pushing a patch upstream? Would we
> individually pull "master" down from f.d.o and transfer the appropriate
> commits from our upstream-unstable branch, say, into this master
> branch?
I think we probably want to deploy a patch in Debian first before pushing
it upstream. So do the above, upload, 'n test. Then once we're happy with
it, you'll probably want to cherry-pick or pull the change to your local
copy of the upstream HEAD. If you cherry-pick, you can do it from either
the upstream or debian branch. If you push, you'll need to do it from the
upstream branch, although I'm not sure how well this will work if upstream
HEAD is wildly diverged from our upstream branch.
> I also understand that part of the idea in using git is that git will
> contain our own patches applied (in the upstream branch) over the
> original upstream source. This will make debian/patches somewhat more
> empty, with quilt being somewhat superseded by git's revision history.
> But if this is correct, then we lose one of the advantages of holding
> explicitly separate patches, that is in order to push a patch we
> developed to fix a specific bug, we'd have to trawl through the entire
> git history entry by entry to collect any relevant commits, which is
> more troublesome than having one patch containing all the required
> changes collected in one file. What will the role of quilt be under
> git?
You've got a good point. I hadn't considered that we'd have several commits
to push a patch upstream. You can probably use a couple of local branches
to make it so you can pull or push the changes, but I'm not sure if there's
a way to make this easier. The simplest I can think of right now is to just
serially cherry-pick the relevant changes.
>From what I learned doing the 6.9 packaging, what quilt is really best at
is to keep a stack of patches that we want to preserve across several
releases. Every patch we put in to quilt that's pulled from upstream is one
more that we have to remove when we do the full update. So I think that we
can keep the patches in quilt that need to be preserved across releases so
that we don't have to worry about deleting them when they become obsolete.
On the other hand, we can just cherry-pick changes from upstream and we
don't have to worry about deleting them, since git should (in theory :-)
just merge correctly when we get the new version from upstream.
> I have a feeling I'm still missing something. Sorry! Hopefully it won't
> take too many more iterations of this discussion to be sure we've got
> it all straight!
All this discussion is great! It keeps me revisiting the organization and
making sure I've got my ideas in order. I'm not 100% sold on having the
upstream branches in alioth for instance. The best real use case I can see
for having them is for us to see what code we're shipping. You can just
look at the log for the upstream branch and see what changes we have in the
packages without wading through the packaging changes. It also makes it
easy for upstream to compare what we're shipping without looking at the
packaging changes.
The only problem with that is the stuff we're keeping in quilt won't be
included. I don't have a good solution except that we should probably take
a serious look at stgit in the future.
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.
- David Nusinow
Reply to: