thanks! and a tiny comment

[Yaroslav Halchenko]

Hi Martin,

Please pardon me if I simply misunderstood something and the last bottle
of beer wasn't actually necessary... I beg your pardon in advance since
my writing is not as enjoyable as yours.

Your blog article came right in time -- me and Michael Hanke have spent
some time today disgusting our (future) organization of git
repository for packages of common interest and of co-maintainership.
Then Michael pointed me to your blog article and the discussion was
frozen to read your writing ;-)

One of the issues we were discussing is an obvious issue of patch
maintenance. Feature branches of git seems to be a good straight
solution, BUT the possible problem of conflicts among them, necessity to
retract them, necessity to differentiate applied patch sets
(sorry -- merged branches), needed more thought. Let me present (and
hopefully discuss or just get resolved) few issues/ideas on top of the
workflow you have presented

0.
As you mentioned, upstream-patches might (and I think should) be actually
also a set of feature branches (like deb/... are) since 

 * some changes might not be accepted upstream, so they might simply
   become deb/... branch later on

 * to avoid cherry-picking relevant changes which might be needed to fix
   maint/... branch later on (or right now ;-))

So I guess they should precede but be handled the same way as deb/...
branches and be named something like up/...

1.
In you poor-mans-gitbuild you rely on the sorting of patches to be
applied as listed by "git for-each-ref" and by default it is a refname.
ok -- at least it is deterministic. But would not it be better to have
an explicit control over the order as well as the set of patches to be
applied? (like debian/patches/00list[.arch] within dpatch). Some patches
might need to be applied only for specific architecture (so we might
need master-<arch>/build-<arch> branches I guess), or some subset
of them to be for a specific maintenance branch.

To resolve this I would rely on an old mechanism --
debian/patches file which would keep refnames of necessary
feature branches to be applied. and obviously its native location should
be master[-<arch>] (and any maint/codename) branch. That would allow to have easy
control over what patches get applied and in what order, so you don't
have to wait to see a conflict as a result of merge when upstream
accepted the patch but introduced its own beautification of it -- just
remove that branch from the debian/patches and be happy.  Nevertheless
feature branch should often be kept alive for a while even after being
absorbed upstream since it might need to be used in some maint branches

2.
quite often in my case, introduced by me patches (either tentative upstream
patches and/or patches to be debian specific) collide in their changes,
so that merge would fail. Since 
 
 * I would like to branch all (or at least up/...) my patches off
  upstream branch, so that upstream has no problem applying them

 * I do not want to pollute any of up/... patches with merge-order
  specific changes, since I can't be sure that upstream would accept 
  them all at once

I think it might make sense to introduce such a policy: if a collision
occur during merge of feature branch up/bla1 (listed in
debian/patches) into build branch, then branch up/bla1  into
up/bla1-up and cherry-pick necessary change into up/bla1 after the
conflict get resolved. Upstream should get ...-up branch then

 Later on if work is needed on the branch -- work in up/bla1-up and
 merge those changes into up/bla1, and verify that build merges fine.
 This way, I think, upstream is guaranteed to get a patch which applies
 cleanly and we do not hit the same merge issue if we ever need to
 unroll and reapply all (or a subset) pf up/.. and deb/...
 patches applied within build branch.

Does it make any sense what I just said or I do not see something
obvious, or use cases I am foreseeing are as rare as a sober night of a
Russian teenager? ;-)

Thanks in advance for any feedback

P.S. As the next step I should make my next attempt to convert my
SVN's repository for fail2ban packaging over to git to finally close
reported by you bug(s). Why did I branch and tagged that much? grr....
;-)

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik