also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.28.1524 +0200]:
> I understood this, but I wonder why you use two distinct branches for
> this. IIUC, your build branch will consist only on merges with the
> master branch and updates of patches, right? What benefits do you get by
> cluttering the history with those merge commits? There must be something
> I'm missing...

As far as I know, there is no way with topgit to extract/flatten the
patch series as it was at some point in history. Therefore, it is
impossible to extract debian/patches/* files from the feature
branches for an earlier version, which is why I keep them in files
in the build branch.

> > build holds the actual source from which the package was built.
> > master holds the development line for ./debian/
> Imagine I agree on the purpose of the two branches "build" and
> "master". Shouldn't "build" be "master"? And "master" something
> else (e.g. "debian")? In most git repositories, the package is
> built from the "master" branch, and it seems to me that this is
> what git-buildpackage expects.

If git-buildpackage expects master, then it is inflexible; you
should be able to tell it to build from build.

Anyway, I can see arguments for your proposal, mainly that the
default gitweb branch shown is master, and that's what makes sense
to have on, right? Anyway, this is really just

> BTW, have you considered collaborating with Guido Günther to make
> git-buildpackage work better with topgit?

I don't have the time, and I have yet to be convinced of
git-buildpackage. I am happy to support anyone who tries though.

 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'` -
  `-  Debian - when you have better things to do than fixing systems
i've not lost my mind. it's backed up on tape somewhere.

Attachment: digital_signature_gpg.asc
Description: Digital signature (see

vcs-pkg-discuss mailing list

Reply via email to