[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feedback on 3.0 source format problems


On Tue, Jan 03, 2017 at 06:48:10PM -0800, Nikolaus Rath wrote:
> I'd think that anything that's relevant for upstream development is
> forwarded to upstream by the maintainer in whatever format upstream
> prefers. This requires extra time, but I would be surprised to hear if
> there are maintainers that have sufficient time to create patches that
> are suitable for upstream, but don't have the little extra time to send
> them upstream.

On Wed, Jan 04, 2017 at 02:47:36PM +1000, Russell Stuart wrote:
> This is not a novel requirement.  Most projects I've worked with insist
> you rebase your patches.  This is not new.  Before git they insisted
> your patches applied cleanly - which amounts to the same thing. 
> Breaking up large patches into a series of smaller independent patches
> each with a simple and documented purpose isn't an unusual requirement
> either.

Indeed.  When forwarding a patch upstream, you'll need to ensure it
applies cleanly.  The easiest way is to start a new branch based on the
current upstream HEAD, and cherry-pick your commit onto it.  git
minimises the amount of manual resolution required.

On Wed, Jan 04, 2017 at 10:28:10PM +0100, Sebastian Andrzej Siewior wrote:
> I can't think of an example where having a patch history somewhere else
> than within the patch itself is useful. My thinking is probably limited
> by my workflow :) Would you have an example where and how this could be
> usefull?

In most cases, when you merge a new upstream release, git transparently
handles dropping and refreshing patches, which saves a lot of time.  For
example, after forwarding a patch upstream as I just described, merging
a new upstream release will not usually result in any conflicts, even if
the cherry-pick required manual resolution.

Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply to: