Re: Standardizing the layout of git packaging repositories

[Manoj Srivastava <srivasta@golden-gryphon.com>]

hi,

  in my analysis, features a and b are indeed long lived branches with multiple commits over time, independently evolving, until such time they are folded in upstream.


   I will address the other point when I an motte awake, I recognize that git-dpm creates ephemeral branches, but the commits there live as parents accessible from the commits on the integration branch


  Manoj

On August 27, 2014 1:24:21 AM PDT, Raphael Hertzog <hertzog@debian.org> wrote:

Hi,

On Wed, 27 Aug 2014, Matthias Urlichs wrote:
 Brian May:
 I don't think you should use normally be feature branches with git-dpm.
 Rather you edit the commit directly (whether by rebase or --amend).
 
 If Upstream uses git and wants you to send a pull request when you add a
 feature (or fix a bug), then using a feature branch is what you do – so our
 git-aware packaging tools should work well with them.

I think you're not understanding each other.

Unless the "feature" is complex enough to require multiple commits, Brian
is saying that evolving the feature is done by amending the commit that
is in the feature branch !
 instead
of adding supplementary commits in the
feature branch.

debian/patches should be seen as stacked/linearized series of features
branches.

HTH.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.