"git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Robie Basak]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20170612/a316f92d/attachment.sig>