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. _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss