[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Git and tarballs

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

Reply to: