Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
Russ Allbery <rra@debian.org> writes:
> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> 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?
>
> When I do this, I use three branches, so master doesn't contain the debian
> directory. upstream is based off master, and there's a debian branch that
> adds the debian directory (and anything else I change specifically on
> Debian).
But then you have to split your workflow again. You have to edit
upstream files in the master branch and debian files in the debian
branch. Switching between the branches becomes a pain and working in 2
workdirs is also a pain. To testbuild you then need to merge from master
to debian and so on. That is basically as bad as having 2 seperate git
repositories, one for upstream and one for debian.
> It sounds like you're instead looking at a two-branch setup with only
> upstream and master. I'm not sure what upstream is buying you in that
> case. In my three-branch setup, upstream is the mediator between upstream
> development in master and the debian packaging based on the tarball
> releases that are imported into upstream.
The upstream branchs buys me that other people stop complaining that my
package is native.
>> 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.
>
> Yes, that's how I generate an upstream branch for a long-standing project
> that had debian on master. See the end of:
>
> http://www.eyrie.org/~eagle/notes/debian/git.html#combine
>
> although the summary is basically just "yes, that works."
>
>> What I would like to do is combine the git-import-orig with the merge
>> into a single commit.
>
> That's what debian/import-upstream in the openafs source package does.
> Take a look at it. It does some very specific things to construct the
> correct merge commit, and I'm fairly sure that git-import-orig doesn't
> know how to do those things.
I glanced at it but wasn't sure how to apply that to my setup where I
merge from master to upstream. Looking at it again I think
debian/import-upstream tarball master upstream/x.y
would be correct. Will try that when I find the time to recreate the
repository.
> I keep meaning to try to turn that into a patch for git-import-orig that
> teaches it how to manage this sort of repository structure, but Python is
> not a language I know well and I haven't had much time.
Yes please. I also looked at git-import-orig to see if it would be easy
to add and thought: python - ugh - not today.
>> 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.
>
> Yeah, I did that for a while too when I realized that I really needed a
> Debian-specific patch. It works, but quilt is really another VCS, and I
> don't like layering one VCS on top of another. VCS management is too
> complicated already! :)
+1
MfG
Goswin
Reply to: