-=| gregor herrmann, Fri, Apr 10, 2009 at 01:14:56AM +0200 |=- > On Thu, 09 Apr 2009 11:14:08 +0300, Damyan Ivanov wrote: > > # refresh the local copy of upstream repository > > $ git fetch upstream-repo > > # merge the relevant upstream tag into the local upstream branch > > $ git co upstream > > $ git merge 2.1.10 > > ^ vs. v > > > # use git-import orig for pristine-tar integration and > > # debian/changelog bump > > $ git co master > > $ git-import-orig --pristine-tar ../clive_2.1.10.orig.tar.gz > > Why do you have the upstream source twice, once via their git repo > and once from the tarball? "Twice" is not entirely true :) What really happens is: > > $ git co upstream > > $ git merge 2.1.10 Now the upstream branch has accomodated the commits from the upstream repository up to the '2.1.10' tag (which is also provided by the upstream repository). > > $ git co master > > $ git-import-orig --pristine-tar ../clive_2.1.10.orig.tar.gz git-import-orig does several things: * switches to the upstream branch (in the local repository, not related to the upstream repository) * extracts the .orig.tar.gz * commits (nothing as the changes to the new upstream version are already in the upstream branch) * creates an 'upstream/2.1.10' tag * switches to 'master' and merges 'upstream/2.1.10' into it * invokes pristine-tar which stores some information about recreating .orig.tar.gz from the 'upstream/2.1.10' tag into the 'pristine-tar' branch Some explainations: * although it appears that the upstream source is stored several times (in upstream-repo/master, upstream-repo/2.1.10 tag, 'upstream' branch, upstream/2.1.10 tag and in pristine-tar branch, as well as the merged copy in the master branch), this is not so. Merging between branches does not copy the content, it only creates some reference tracking information so that git knows how to get to the content which stays in one place. * the pristine-tar thing is different. it does not contain copy of the .orig.tar.gz, but as Paul Wise explained, it only stores some information necessary to recreate binary-identical .orig.tar.gz from the 'upstream/2.1.10' tag. Two very small files are created (checkout the pristine-tar branch and see for yurself). Using pristine-tar one doesn't have to carry the .orig.tar.gz around, it is easily created via "pristine-tar checkout ../clive_2.1.10.orig.tar.gz". (of cource, this implies you trust the person that invoked git-import-orig to not tamper with the .orig; for paranoids (me included), uscan -f remains at service :)) I admit the clive upstream merge had some hiccups. "The Imported Upstream version 2.1.10" commit (a62417d) should have been empty, but it has a significant diff. So I guess the merge from upstream-repo/master into upstream branch was badly made (by me, there were some conflicts (surprisingly) and I haven't paid enough atention when resolving them). Fixing this is possible, but would involve rewriting the history, which would break any clones of the repository so I leave things as they are. It should behave better next time. > > The only way I can think of to avoid this is to stop merging tags > > (and therefore commits) from upstream repository to the upstream > > branch (and consequently to the master branch). Instead, > > git-import-orig could simply roll the .orig.tar.gz into the > > upstream branch and create a single "new upstream release" commit > > that is then merged into master. > > Hm, maybe my question is not totally unrelated to your question :) If I didn't merge from upstream-repo, then git-import-orig would create a big commit in the upstream branch, which is later merged into master and thereforre will appear in the commit-notification mails. That commit would (naturaly) contain the whole diff between the old and new upstream versions, which is only slightly less likely to trigger the moderation request (because of the headers of the individual commits not being present). It would avoid flooding the IRC bot with all the individual commits, though. Hm, should I stop merging from upstream-repo? I do it only because it "feels right". The code flows from upstream and we add debian/ to it and then create the package. Or, should the post-recieve hook be improved somehow to not notify about commits that were merged into master (only by the 'merge' commit itself)? That would require using --no-ff when merging from upstream to master. Something to try for the next time... -- dam JabberID: dam@jabber.minus273.org
Attachment:
signature.asc
Description: Digital signature