Re: dgit and upstream git repos

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Enrico Zini writes ("dgit and upstream git repos"):
> This is my scenario: I'm the upstream developer, I have an existing git
> repo with all the project history, and I'd like to be able to git push
> to debian using dgit.
> 
> I ran "dgit fetch", I ran "git checkout -b dgit/sid dgit/dgit/sid" and
> all was fine.
> 
> When I had my new upstream version ready, however, and tried to merge it
> into the dgit branch, I realised that my development branch did not
> contain ./configure, Makefile.in and other autogenerated stuff, while
> the dgit branch of course did.

Right.

Since dgit is a way of editing the Debian archive using git, you
obviously have to have the actual complete contents of the Debian
package in your dgit git trees.

It appears that you want the Debian package to contain a different set
of files to the upstream git history.  I think this is a bad idea and
I have a rant about the meaning of `source code' which I will write at
the end of this message.

But nevertheless, doing this with dgit is easy.

> If anyone is working in a similar scenario and has a handy workflow
> with dgit, can you please tell me how you do things?

I think you can do what you want like this:

  dgit fetch sid
  git checkout -b dgit/sid dgit/dgit/sid
     # equivalent to   git checkout dgit/sid   I think
  git reset --hard upstream
  git merge -s ours dgit/dgit/sid
  git clean -xdff
  ./autogen.sh
  git add .
  git commit -sm 'Add autogenerated files'
  ed debian/changelog
  dgit push

This assumes that your `upstream' branch has debian/ files.  If it
doesn't then you will need to do something more complicated.  One way
is this:

  git checkout -b dgit/sid dgit/dgit/sid
  git merge -s ours upstream-tag-corresponding-to-this-debian-version
  git merge upstream
  ./autogen.sh
  git commit -asm 'Update autogenerated files'



On `source code': I think everyone should have the same definition of
`source code' for git as for tarballs.

That means either:

 1. configure, Makefile.in, etc. are supplied in both.  If you edit
    configure.ac, you run autogen.sh and commit the result.  This
    works perfectly fine and I work this way with many of my own
    projects.  In the Xen project (which I work on during my day job)
    we even commit flex and bison output because some of our
    contributors are using old distro releases with prehistoric
    versions.

    A disadvantage is that sometimes you see a conflict in configure
    (or another autogenerated file), but you can always solve them
    with ./autogen.sh so it's never a problem.  And you see diffs to
    configure etc. in your VCS history.

    The advantage is that people on deficient operating systems, who
    may not have the necessary version of autoconf or whatever, can
    still build your package from git.  This is quite important if you
    want to be able to take bug reports and code contributions from
    such people!  You can hardly say `pls try latest tip' if they
    can't build it.

 2. None of the autogenerated files are in git or the tarball.  The
    INSTALL file doesn't say `./configure && make && make install';
    it says `./autogen.sh && ./configure ...'.  debian/rules always
    runs ./autogen.sh.

    The advantage is that everyone is always building the package
    fully from the ultimate source code.  The disadvantage is that
    your build-dependencies now always include the latest and greatest
    autoconf or automake or whatever, or you have to delay using new
    features in your build infrastructure until all your downstreams
    and contributors have finally stopped using Centos 5.


Thanks,
Ian.