On 03/21/2016 09:43 PM, Sean Whitton wrote:
> When there's a new release, I fetch upstraem's tags and then run
> something like `git merge 1.1.1 && dch -v1.1.1`. In the case you
> describe where 1.1.1 cannot be cleanly merged with 1.0.2, I would just
> run `git merge --strategy recursive --strateg
Le Mon, Mar 21, 2016 at 06:43:58PM -0700, Sean Whitton a écrit :
>
> In my usage of git-buildpackage, I've been using a different approach to
> that suggested by Russ and I thought it might be useful to share it in
> this thread.
>
> I think of (local) branches as things that I expect to make com
Hello,
On Sun, Mar 20, 2016 at 04:35:27PM -0700, Russ Allbery wrote:
> Ross Vandegrift writes:
>
> > In my packaging, I've worked on 1.0.0, and updated for 1.0.1 and 1.0.2.
> > So my packaging looks like this:
>
> > o---ooooo master
> > \
Ross Vandegrift writes:
> In my packaging, I've worked on 1.0.0, and updated for 1.0.1 and 1.0.2.
> So my packaging looks like this:
> o---ooooo master
> \ \
> o---o 1.0.0o---o 1.1.0
>\
Hello all,
I've been working on packages using git-buildpackage, and have been
wondering if there's a better pattern out there.
Upstream makes periodic releases, which often receive a few maintenance
updates. For upstream, often looks like this:
o---ooooo ma
5 matches
Mail list logo
