Bonjour Thomas, On Wed, Jul 06, 2011 at 15:12 +0200, Thomas Preud'homme wrote: > Le mercredi 6 juillet 2011 14:38:36, Wolodja Wentland a écrit : > > First, thanks for posting your git workflow. It is for me very interesting to > see different ways of dealing with upstream also using git. No problem. It was basically what felt right at that time and was driven by the necessities. I have the impression by other comments that a style like this is not very common though. My main motivation right now is to *see* a couple of different established workflows, so I can get a better understanding of it. As a new maintainer you are trying to get to grips with various tools, regulations and workflows and I enjoy a "See what others are doing and combine the best parts" approach. > > [SNIP] > > > > I know that I could just download the tarball from github and use > > git-import-orig to import the release, but I basically see upstream as > > simply another remote branch whose tags are packaged. I would welcome any > > feedback, criticism and praise for this workflow. > There was a thread recently about using tarballs or tags on debian-devel@l.d.o > recently. No consensus was reached as it clearly depends on your needs and > probably also your tastes. Yeah, TMTOWTDI is good and nice, but you are also often unsure what is good and what not. Do you recall the subject of the thread? I skimmed through my archive and nothing met my eye. > Personally I work with upstream tarball. Yet, I do keep remote branches to > follow upstream development in the same repository, but it's mainly for having > convenient cherry-picks. Your setup greatly interest me. Yeah, this tarball-centric style seems to be quite typical. But after playing around I found that the tarball is *only* needed to populate the pristine-tar branch as everything else is already in the repositories. I just wasn't sure how repacking (with/without helpers) is handled. > > This, however, raises some questions: > > > > ii. Another way would simply merge the remote changes into 'upstream' and > > 'debian' and basically boils down to: > > > > $ git fetch UPSTREAM_GH_USER > > $ git checkout upstream ; git merge UPSTREAM_GH_USER/master > > $ git checkout master ; git merge NEW_TAG_TO_PACKAGE > > $ uscan --rename > > $ pristine-tar commit ../foo_NEW_TAG_TO_PACKAGE.orig.tar.gz > > $ cd debian ; HACK_AWAY > The problem with this solution setup is that a clone of the alioth repository > would not setup a remote upstream branch, thus you can't just run git > buildpackage after the clone. On the other hand you could republish the > upstream branch on alioth but you make all people download more data for > nothing. Yeah, that is exactly the problem I am facing there and a major problem with this approach. I guess that "upstream" should be used in the way intended by git-buildpackage. If "real upstream" branches are needed they can be added later and tracked locally under a different name. (suggestions?) > > 2. How to repack tarballs/tags? (DFSG, etc) This question still interests me. Is this *really* done manually? How do, for example, jh_repack (in the watchfile) and get-orig-source fit into the picture? Thanks for your input, that was quite helpful. I guess the one *very* important aspect is that people should be able to "debcheckout foo" and "git-buildpackage" and don't run into problems. -- .''`. Wolodja Wentland <babilen@gmail.com> : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
Attachment:
signature.asc
Description: Digital signature