- Original Message -
From: Jeff King p...@peff.net
Sent: Thursday, October 10, 2013 1:36:28 PM
Subject: Re: A workflow for local patch maintenance
... snip ...
That being said, there are some new downsides, as you noted:
1. Resolving conflicts between your version
On Fri, Oct 11, 2013 at 09:22:28AM -0400, Stephen Bash wrote:
To mitigate problem 1, I will sometimes revert a local topic before
doing the upstream merge, if I know it has been reworked.
Peff (slightly off topic) - A coworker of mine actually ran into this
problem earlier this week. Is
Jeff King p...@peff.net wrote:
Do you need to keep the modifications you make on top of upstream as a
nice, clean series of rebased patches? If not, then you can avoid the
repeated rebasing, and just use a more traditional topic-branch
workflow. Treat modifications from upstream as just
On Thu, Oct 10, 2013 at 05:53:57PM +0100, Tony Finch wrote:
Our aim is to get as many patches into the upstream version as we can,
which is why my starting point is a clean rebased patch series. I am also
thinking that this will help me to know when a patch can be dropped from
the series
Jeff King wrote:
3. The pain in doing the big rebase-test-deploy cycle meant that we
often delayed it, keeping us several versions behind upstream.
This is bad not only for the end product (you aren't getting other
bugfixes from upstream as quickly), but also because the
On Tue, Oct 08, 2013 at 07:12:22PM +0100, Tony Finch wrote:
We often need to patch the software that we run in order to fix bugs
quickly rather than wait for an official release, or to add functionality
that we need. In many cases we have to maintain a locally-developed patch
for a
This is a copy of an article I published at
http://fanf.livejournal.com/128282.html
I'm sending a copy here because I'm interested to know what other ways
there might be of handling this situation.
--
We often need to patch the software that we run in order to fix bugs
quickly rather than wait
7 matches
Mail list logo
