Johannes Schauer writes ("Re: Idea: sbuild/pbuilder "--dgit" option"): > sbuild already has an option to do just that: > $ sbuild --dpkg-source-opts="-i\.git/ -I.git" ... > Or by putting the following in the config file: > $dpkg_source_opts = ["-i\\.git/", "-I.git"]; > (hope I got all the backslash escaping right there).
Right. I wonder if a --dgit option ought to (perhaps optionally) do something different about package clean targets. Does sbuild already have an option to use `git clean' (and maybe `git reset') instead of the package clean target ? I always do all my builds-for-upload with dgit --clean=git-force (aka dgit -wgf) now; this is pretty much a requirement when working on a package whose maintainer is not using dgit, because package clean targets are often troublesome. > Unfortunately, typing this is much more involved than just putting --dgit Precisely. > but maybe we can do even better. I wonder: > > - are there other git-based workflows than dgit which need these cleaning > options? Then the option name could be picked to be more general and not > dgit specific I'm not aware of any but there are so many gitish workflows in Debian that it's hard to say for sure. I think it is quite unlikely. Here are some arguments for thinking this is unlikely: * Any git-based Debian workflow needs to ignore .git at least. There is no convenient way to do exactly that: the options to do exactly that (as seen above) are obscure, requiring a careful reading of the docs. Conversely, there is the -i (without value) option which is documented with vague but encouraging wording in dpkg-source(1) and which many tool authors have discovered and used already. * For maintainers using git-based workflows, the lack of .gitignore (or updates to .gitignore) in source packages is invisible, because such maintainers never work with the source packages for their own packages. (There was not really a viable non-maintainer git workflow, before dgit.) * dgit is the only tool I'm aware of which actually insists, and checks, that the git tree and the source package are equivalent (for any value of equivalent). All the other tools that do git<->dsc conversions are `open loop', and conversions are typically unidirectional. So the .gitignore anomaly would not be detected by other tools. If you want a more generic option name `--faithful' would be a good one, if perhaps rather tendentious :-). Personally I think `--dgit' is a good one because if we discover that there are other things that would work better if the builder did them differently, we can have a single option where the user declares their workflow. > - is there a reliable and future-proof way for sbuild/pbuilder to > auto-detect that they are working on a dgit package? Maybe by > examining the Vcs-Git field? Then they could pick the right > options for dpkg-source automatically. That's a nice idea. However, "we are using dgit" is not a property of a package. It's a property of the user's workflow. The same package (and perhaps even the very same git branch) can be worked on, at one time, by a user who is not using dgit, and at another time by a user who is. For example, a dgit-using NMUer may work on packages with many different (or totally absent) Vcs-Git fields. They may even do a dgit-based NMU based on a history they found on alioth, or something. Even if we restrict ourselves to maintainers, a maintainer who uses dgit also needs to store their un-uploaded git commits somewhere. The dgit git server does not do this (yet). So often that will be the maintainer's own server, or a team repo on alioth.  dgit is so compelling for the NMU use case (particularly, for an NMU campaign) that the fact that need to wrap your build with dgit is only a minor inconvenience. > Otherwise (and also being a dgit user myself) I'm open to adding a --dgit > option to sbuild. I'd just want to hear your ideas about the above first > because I don't want to add an option just to deprecate it one release later. These are all good questions. Please do ask more probing questions. Before anyone actually implement this I would also like to hear from at the very least the pbuilder maintainers. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. _______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss