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

[intrigeri]

Hi,

Antoine Beaupré wrote (20 Feb 2014 14:57:26 GMT) :
> In the past, I have use the 3.0 (quilt) format even with git-managed
> packages.

Short version of what happened: I've been doing that for ages too
(with gbp-pq to mitigate the pain), and I must say I'm very tired of
having to use quilt instead of Git for patch management, and to see
diffs-of-diffs in the Git history. Holger also expressed he would like
to do pure Git, so the two choices we had were 1.0 or 3.0 (quilt) +
single-debian-patch. Holger prefers 1.0, and I don't care much, so
we've come up with this 1.0 + pure Git workflow.

> So that covers part of the problem (namely patches that sit in Debian
> ignored forever), but not the actual problem of tracking what are those
> patches and why.

> I don't know how to fix this, but maybe there could be a branch where
> those changes would be done?

> Say we have:

>  * master -> upstream code
>  * debian -> debian/ directory and patches

> We could have another branch:

>  * patches -> debian patches to master branch

> "Graphically":

> * (master)
> |   * (debian, 1.1-1) upload to unstable
> |  /|
> | / * bar change in debian package
> | * (patches) second patch against upstream
> |/| * foo change in debian package
> * (foo-1.1) new upstream release
> | * | first patch against upstream
> |/ / 
> * / foo upstream change
> |/
> * (foo-1.0) first upstream release
>
> That way, instead of looking at the Debian branch which mixes
> debian-specific changes, upstream and patches, we can just look at the
> patches branch to see what's going on.

This looks good, and I wanted to try that, but I'm not sure how well
this can work in practice without rewriting the history of the patches
branch (and I've not verified yet), and I didn't want to raise
complicated workflow discussions while only Holger and I had expressed
interest in this topic, so I just went with the simplest thing.
But well, I'm happy to dig further into it, now that I see that a few
of us are interested in it :)

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'?

If it is, then I say we go for the "patches" branch!
Else, I'm unsure what this buys us compared to 1.0 + pure Git.

> Just throwing an idea out there.

Thanks a lot! :)

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc