Russ Allbery <[email protected]> writes:
> Goswin von Brederlow <[email protected]> writes:
>
>> 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.
>
> This is how I actually want to work; I prefer the separation. But I can
> see why you don't want to do things this way (and indeed several of my
> coworkers prefer to maintain our local packages as native packages to
> avoid this separation). It does mean cherry-picking things back and forth
> a bunch while solving some packaging-related problems.
>
>> The upstream branchs buys me that other people stop complaining that my
>> package is native.
>
> Ah! Okay, I had somewhat misunderstood the problem. So in that case the
> only purpose the upstream branch is serving for you is that it's an export
> of the tarball distribution that you can base pristine-tar on, without
> forcing pristine-tar to maintain a delta to remove all the debian/* files.
>
> In that case, I would not bother with any of the merging logic and would
> maintain the upstream branch as a pure tarball import with git-import-orig
> without merging it. That means it would be a disconnected branch without
> the "correct" history, but at that point you don't care since it's only
> there for pristine-tar to use. Git will still do global object
> deduplication, so you'll get the compression advantages.
>
> So, in other words, branch upstream off of master, remove and commit the
> removal of the debian/* files, and then from that point forward your
> packaging method is to run make dist (which would omit the debian/*
> files), git-import-orig the tarball with --no-merge, and then build with
> git-buildpackage as you would normally do.
>
>> 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.
>
> Yes, that would work if you want to preserve the history. But since
> nothing other than pristine-tar is going to look at the upstream branch,
> I'm not sure I'd bother.
Other people might. So say RH wants to see what has changed between
upstream/1.0 and upstream/1.1 then the interconnect of the histories
will allow them to see the seperate commits. Looks better in qgit even
to me, better than as disconnected branch.
I'm fine with experimenting a bit now trying things and will use that on
5 or 6 projects. Making things easier for other people is a good thing.
If I can do it with just some initial overhead and no running costs
(other than some extra commands in the release target or so) then I'm
all for it.
MfG
Goswin
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
