Re: git-migration: Changes to 'master'
David wrote:
> On Sun, Jan 07, 2007 at 08:38:08PM +1100, Drew Parsons wrote:
> >
> > 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 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.
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?
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 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?
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!
Drew
Reply to: