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

[Ian Jackson]

Robie Basak writes (""git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]"):
> 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.

AIUI .gitignore does not affect whether git shows you diffs to files
that have changed.  It simply suppresses listing of _added_ files.

> 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".

`dgit clone' disables these .gitattributes; provides a separate verb
for disabling them in other trees; and `dgit fetch' warns about them
if it finds them.

> 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.

Obviously having sensible remotes is nice, but not IMO essential.

> 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.

dpkg-buildpackage -B does not need an upstream tarball.

It seemed obvious to me when writing dgit that it would be too hard to
to make a uniform data model and workflows that could be used to
generate source packages from git.

Anyway, I don't think a wrapper that does "unescaping" of .git is a
good idea.

Ian.