Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
Russ Allbery <rra@debian.org> writes:
> Goswin von Brederlow <goswin-v-b@web.de> writes:
>> Russ Allbery <rra@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 tried creating the upstream branch from the master branch and then
removing the debian dir. But then on the next merge git complains about a
merge conflict (modify/delete) when any file in debian/ was changed. I
googled a bit but couldn't find any hint on how to tell git to always
(and only) ignore changes to the debian dir on merge. Any ideas?
So I switched to the fallback option of using git-import-orig. But as
you say then the upstream and master branch aren't based on each other.
Since in my case all the history is in the master branch I then merged
the master branch into the upstream branch using:
% git checkout upstream
% git merge -s ours master
All the upstream changes are already there from git-import-orig so the
"-s ours" only ignores the debian dir. I think that should give the
right history for the upstream branch. At least it looks nearly right in
qgit.
What I would like to do is combine the git-import-orig with the merge
into a single commit. I've tried doing:
% git checkout upstream
% git merge -s ours --no-commit master
% git commit --amend
fatal: You are in the middle of a merge -- cannot amend.
Next I tried doing the merge before git-import-orig:
% git checkout upstream
% git merge -s ours --no-commit master
% git checkout master
% git-import-orig ...
That gave no error but surprisingly shows 2 commits to the upstream
branch. First the "Import Upstream version x.y" and second, which is the
surprising part, a "Merge branch 'master' into upstream.
Well, guess that has no easy solution. I think I can live with the
import and merge being shown seperately. But the upstream/x.y tag I feel
is wrong and should be on the merge, where the hirtory of upstream and
master a connected, instead on the import. So lets move the tag:
% git-import-orig ...
% git checkout upstream
% git merge -s ours master
% git tag -f upstream/x.y
The histoy in qgit looks like this:
+ [upstream][upstream/1.2] Merge branch 'master' into upstream
|\
| + [master][debian/1.2-1] Release 1.2-1
| + change foo
| + change bar
| + change baz
+ | Imported Upstream version 1.2
+ | [upstream/1.1] Merge branch 'master' into upstream
|\|
| + [debian/1.1-1] Release 1.1-1
| |
Maybe the debian/x.y-z tag should be after the merge? What do you think?
>> 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.
I don't think / hope I won't need that. But I can always create a debian
branch when I need it.
With 3.0 (quilt) format any upstream change that is debian specific
would end up in debian/patchs/... and I can add "unapply-patches" to
debian/source/local-options so that the change is only in git as
debian/patches/... and not applied in the working directory. It then
remains out of the orig tarballs even if I keep the patch across
upstream releases.
So I think i can carry debian only changes to upstream just fine in the
master branch if I need to. But time will tell. As long as I keep the
options option there should be no problem.
In a more complex package I would probably create a feature branch and
use --git-prebuild=... to generate debian/patches/feature from that
automatically before a build. Beter to record the changes to the plain
source instead of changes to the patch. A diff of diffs is much harder
to read. But since I currently have nothing that complex I haven't
worked out what works best there. For now I want KISS.
MfG
Goswin
Reply to: