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

[intrigeri]

Hi,

Antoine Beaupré wrote (20 Feb 2014 16:08:16 GMT) :
> Well, the advantage 3.0 has, if I am not mistaken, is that we have
> clearer separation of the debian patches in the resulting upload, at
> least...

> So I would prefer 3.0 + single to 1.0.

Point taken. 3.0 + single-debian-patch is fine with me.
But Micah is not too happy with it, so this is not a consensus.
Gonna read Micah's email and reply right now.

>> 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:

  $ cd $(mktemp -d)
  $ git init
  $ git checkout -b master
  $ echo bla > bla
  $ git add bla    
  $ git commit -m 'Add bla.'
  $ git checkout -b debian
  $ mkdir debian
  $ touch debian/control
  $ git add debian/control
  $ git commit -m 'Add debian/control'
  $ git checkout -b patches master
  $ git checkout master
  $ echo bli > blu
  $ git add blu
  $ git commit -m 'Add blu.'
  $ echo bli > bli              
  $ git add bli
  $ git commit -m 'Add bli.'
  $ git checkout patches
  $ git cherry-pick master
  $ git checkout debian
  $ git merge patches 
  # upload
  # new upstream release
  $ git checkout patches 
  $ git merge master  
  $ git log master..patches
  commit 04daa3777337fb2b77bb43a9f4725fb4117c4544
  Merge: c68aef0 eac75c4
  Author: intrigeri <intrigeri at boum.org>
  Date:   Sat Feb 22 18:39:07 2014 +0000
  
      Merge branch 'upstream-master' into patches
  
  commit c68aef0608c34edf63aa1ad8cdb3ac5721d56a3a
  Author: intrigeri <intrigeri at boum.org>
  Date:   Sat Feb 22 18:37:41 2014 +0000
  
      Add bli.

... 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).

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.

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