On Fri, Oct 05, 2007 at 02:15:11PM +0930, Ron wrote: > Sorry, perhaps I wasn't clear there. I'm not advocating total chaos > inside any single repo, or any group of repos maintained by the same > people. Localised consistency in these things is highly desirable, > for all the reasons you mention and more. The issue I see is that > global consistency is an impossible goal, there are already many such > conventions among different groups and its highly unlikely they will > ever converge without some really compelling reason and a lot of > renaming of existing branches/tags in existing repos. > > If I'm pulling an upstream branch from such a source I have two choices, > re-tag it and rename its branches, or deal with the upstream system and > minimise confusion when communicating with them about tag/branch names. This is why git-buildpackage and the other tools can be taught easily about the desired repository layout. You can specify the branch names to act on by default as well as the desired tag format used for upstream and debian branches. Maybe the documentation wasn't very clear on this, I've updated the docs at: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html The documentation shipped with the current packges in unstable/experimental is a bit outdated. [..snip..] > This is the curse of frameworks in general. You trade your ability to > work in heterogeneous environments for the convenience of performing > certain functions by rote. That doesn't necessarily make them Bad, > it just makes them difficult or impossible to use in circumstances > that they didn't envisage or assume when they were first created. I honestly can't figure out which repository layouts aren't suitable for gbp - I'm still interested to hear which workflows gbp doesn't cover _easily_ at the moment though. [..snip..] > > > So if you happen to have many different git repos, all using different > > > conventions for these things, you can still use the same tool, without > > > needing to modify its config, to extract source packages from all of them. > > I don't see why this can't be done with git-buildpackage too. While you > > do: > > > > gitpkg branch1 branch2 > > > > git-buildpackage does: > > > > git-buildpackage --git-debian-branch=branch1 --git-upstream-branch=branch2 > > The biggest practical difference there right now (aside from the amount > of typing ;) is that the former is actually: > > gitpkg tree-ish [tree-ish] > > I agree that is an improvement that shouldn't be too hard to apply to > gbp too though, but I'm not sure how deep the assumption of being on > a branch HEAD really runs in it. I added this functionality to the current package in experimental, basically since I wanted to be able to do a clean build after an export since quiet some time. [..snip..] > If you are pulling upstream source directly (as opposed to importing > tarballs on an upstream branch), then the upstream branch may have > similar issues, the tagged release that you want to make a deb of > may no longer be their HEAD commit at the time you make it, even if > your deb branch is at its current head. You may even want to package > from a commit slightly later than their tagged release if some errata > was committed shortly after that (as an alternative to cherry picking > what is really a fast-forward on the upstream branch). As I sad the simple solution was to create a new branch that used the tree you wanted as head and use that one as upstream-branch. The version in experimental tries to figure out the upstream version by itself now (by looking at the corresponding to the version in debian/changelog) if that doesn't fit you can now also pass in any treeish object with --upstream-branch. > gitpkg also copes automatically with 'debian native' packages and > repos that aren't debian native but where everything is on a single > branch (I don't really recommend the latter given the choice either, > but it is a trivial case to handle ;). It's not clear to me if gbp > can handle them yet either? You can do this too by simply giving a treeish object to --upstream-branch when running git-buildpackage, but this doesn't look like a clean and easily maintainable repo layout to me. Cheers, -- Guido
Attachment:
signature.asc
Description: Digital signature