Le mercredi 6 juillet 2011 14:38:36, Wolodja Wentland a écrit : > Hi all, Hi Wolodja, First, thanks for posting your git workflow. It is for me very interesting to see different ways of dealing with upstream also using git. [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. 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. > > This, however, raises some questions: > > 1. What to do for new releases/tags? > > i. One way would be to run "git-import-orig --uscan" and be done with it, > but I would probably lose all upstream history on the upstream branch if I > do that. Upstream history is not lost since there is still the upstream branches available. > > 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. > > 2. How to repack tarballs/tags? (DFSG, etc) > > I am really not sure how to repack tarballs in this workflow which might be > needed to make it DFSG compliant or simply because some files should not be > shipped. (jars for Java for example). My feeling is that I'd have to work > on the actual tarball acquired with uscan and repack it, before commiting > to the pristine-tar branch. > > There are also some helper that can be incorporated into the watch file > (such as jh_repack), which would essentially mean that the tarball does > *not* correspond to an upstream tag. It also seems to be good practice to > implement get-orig-source in the rules file, in which the repacking could > also happen. Does pristine-tar work if the upstream branch contains files which have been removed during repack? > > 3. Repository overkill > > The packaging should probably be pushed to a git repo on alioth, which > would mean that "master" and "pristine-tar" track the alioth repo, and > "upstream" needs to be pushed explicitly to alioth as it tracks the > upstream repository. This difference in the branch setup is a potential > source of error and I would like to avoid it, but am not sure how. In my setup all branches (upstream, pristine-tar and master) track those on alioth, while the copy of upstream development branches track the upstream branches. There is few confusion in this scheme. > > In short > -------- > Am I nuts? I don't think so. > What are your workflows? See above. > Do you *only* work with tarballs and don't use/track the upstream > repositories at all? > > * only use git-import-orig > * Repository lives only on alioth and all branches track alioth It's perfectly possible to track upstream repositories and use tarballs at the same time. This way cherry-pick and upstream changes review is still easy but the alioth repository is not full of non-debian commits. I acknowledge that the latter argument can't be seen as a weakness. > > If not: How do you work with the *real* upstream branches? How do you > generate tarballs? > > Sorry for the wall-of-text and for all your advice in advance :) No problem, thanks for your post.
Attachment:
signature.asc
Description: This is a digitally signed message part.