On Mon, Jun 12, 2017 at 04:31:48PM +0100, Ian Jackson wrote: > Robie Basak writes ("Re: What to do with .git directories in source package > uploads?"): > > In mitigation, we have "build" and "build-source" wrappers that could > > always do the correct unescaping here. Then you'd only fall into the > > trap if you aren't using the wrapper. > > If these wrappers are what I think they are, they are IMO a bad idea.
I don't like them either, but for the moment, they are IMHO necessary. I would like to see them go away, so I have been keen on not requiring them for any workflow. I'd also like to make sure that all documentation makes it clear how to _not_ use the wrappers. However, if you don't use them, there is a growing list of caveats of which you need to be aware, usually for edge cases. Some examples: Upstreams that ship .gitignore confuses distribution developers (IMHO) who want to see *everything* that has changed. I'd like to work with git upstream in adding a repository level configuration option (or similar) to completely ignore all dotfiles in the worktree that affect git's behaviour. As a distribution developer, git's behaviour should come from me, not some random upstream whose package I happen to be working on. In the meantime, our wrapper warns you if these are present. Similarly, there are upstreams that use $Id$ and similar abominations. The only sensible way to handle these and other corruptions is to turn off ident, text and eol in .git/info/attributes, which our wrapper adds on "git ubuntu clone". Having sensible default refspecs and dealing with sharing repositories when you can't push to the main importer repository is a pain. This is amplified when few developers work across many packages and don't keep persistent local git repositories for them. So "git ubuntu clone" and "git ubuntu remote add" deal with setting up reasonable default remotes and refspecs. In Ubuntu, the importer must maintain separate pristine-tar branches for Debian and Ubuntu because orig tarballs may not necessarily match. We try to make them match, but the importer must be able to represent everything that happened, including past mistakes. But "git clone" followed by "dpkg-buildpackage" won't be able to find the upstream tarball, and nor can gbp without adjusting the local pristine-tar branch. This is solved by "git ubuntu build-source", which takes care of getting the upstream tarball for you first. None of these things *require* the wrappers, but we currently have no way of making the things that they do unnecessary without causing developer onboarding or edge case pain. I believe there are other cases too; these are just off the top of my head. Robie
Description: PGP signature
_______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss