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 <hert...@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. >-- >Raphaël Hertzog ◈ Debian Developer > >Discover the Debian Administrator's Handbook: >→ http://debian-handbook.info/get/ > > >-- >To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org >with a subject of "unsubscribe". Trouble? Contact >listmas...@lists.debian.org >Archive: >https://lists.debian.org/20140827082421.gb23...@x230-buxy.home.ouaza.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
