[pkg-otr-team] gbp vs. 1.0 source format

[Antoine Beaupré]

On 2014-02-22 13:47:07, intrigeri wrote:
> Hi,
>
> Antoine Beaupré wrote (20 Feb 2014 16:08:16 GMT) :
>>> So, my question is:
>>>
>>> Say I cherry-pick an upstream commit into the patches branch, upload
>>> to Debian. So far so good, `git log master..patches' shows me what we
>>> have in Debian, that hasn't been merged and released upstream yet.
>>>
>>> Then, upstream puts out a new release, that includes the patch I've
>>> cherry-picked. I merge their tag into our patches branch. Is Git
>>> clever enough *not* to show me that patch in `git log
>>> master..patches'?
>
>> I think so, if you merge master in patches, it should technically point
>> to the same commit, unless there's a merge of some sort.
>
> Unfortunately, at this point the "patches" branch has a duplicate
> commit (the cherry-picked + merged one), and `git log master..patches'
> shorws me that commit, even if it is *not* a Debian-specific delta
> anymore. Demo:
[convincing demo snipped]
>
> ... and that's why those who maintain such patches branch rebase them
> on top of the upstream code, instead of merging: git rebase *is*
> clever enough to detect when a patch carries the same changes as
> another one, even if they haven't the same commit id (due to not
> having the same parent), and avoid duplicating it, while git merge
> cannot possibly do that (and it's obvious, once you think of what
> operation git merge actually does).

Of course, that makes sense.

> So, this seems to confirm my initial intuition, unfortunately. In this
> context, I'm not sure what a "patches" branch buys us at all, and I'm
> not sure what we should do anymore.

What about what I suggested in that other mail: instead of having one
patch file in debian/patches/foo for each change, we could have a foo
branch for each change?

And we don't need to merge or rebase the foo branch with master! As with
a patch, we can either leave it like that (but of course merge it in
debian) or rebase it.

What's wrong with rebasing it anyways? :) Yes, I know that it will
create merge commits if people pull that branch, but how often would
that branch be pulled itself? If it's part of the workflow that those
topic branches can be rebased at will, then we can just make them so...

This could potentially provide a solution.

But it would still require ASCII art, I believe, as we would have now
Θ(N) branches instead of Θ(2). :P

Really, I don't mind quilt so much.

A.

PS: I can't believe this problem wasn't solved in the git world, this
seems like a typical problem to resolve: "what patches I made were not
merged upstream?"

-- 
Software gets slower faster than hardware gets faster.
                         - Wirth's law
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-otr-team/attachments/20140222/3791a5d9/attachment.sig>