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
vcs-pkg-discuss mailing list