Goswin von Brederlow <goswin-...@web.de> writes: > Russ Allbery <r...@debian.org> writes:
>> http://www.eyrie.org/~eagle/notes/debian/git.html > Where were you 2 years ago when I first asked about how to use git when > being both upstream and debian maintainer? :) Posting that site to Planet Debian. :) In August of 2008 and then again in July of 2009, to be precise. > You are thinking way to complex here :) > libaio-ocaml% ls > CHANGES Makefile OMakefile debian/ lib/ > LICENSE OCamlMakefile README.txt examples/ > This is a really small and simple package. No automake or such. Also I'm > a fan of autoreconf so probably wouldn't include generated files in the > tarball at all. But if one does include generated files in the tarball > then you are right. Then git-import-orig would be the way to go. >> Also see README.source in the openafs source package for another technique >> for maintaining the upstream branch that I want to move to eventually. > Well, that [1] sounds complicated and doesn't seem to relate to any of > this. It relates to this because git-import-orig gives you a detached upstream branch (detached in that it has no relationship to master, even though it shares the same files). That's fine -- it doesn't exactly *hurt* anything. But it does mean that your debian packaging is not based on your master development branch, even though it really is. It's based on a branch of imported tarballs. The further innovation described in the openafs README.source is to, instead of just doing a straight git-import-orig, have the import of the tarball be committed as a *merge* commit between the current upstream branch and master, with the generated files added as new content in the merge. Then, your debian branch is directly based on your master branch and you can meaningfully do things like git cherry. > I'm upstream so there isn't anywhere to pull from and I don't need to > clean up files from the upstream tarball, bounce changed around mltiple > branches or cherry-pick stuf. I need to do all of those things sometimes even though I'm upstream. :) Sometimes I need to temporarily patch things for Debian that are only applicable to Debian and that I therefore don't really want to have on master, but may have to carry for a little bit, or I want to pull an immediate fix into a Debian package without doing a new upstream release. I thought the way that you did for a while and used earlier strategies that didn't give me the full flexibility of letting the debian branch diverge and converge, and I found that while I didn't *need* those capabilities, there are times when they're very helpful. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty1z8x4y....@windlord.stanford.edu