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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21555.53935.131317.238...@chiark.greenend.org.uk
