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 <[email protected]> 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. >-- >Raphaël Hertzog ◈ Debian Developer > >Discover the Debian Administrator's Handbook: >→ http://debian-handbook.info/get/ > > >-- >To UNSUBSCRIBE, email to [email protected] >with a subject of "unsubscribe". Trouble? Contact >[email protected] >Archive: >https://lists.debian.org/[email protected] -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
