Hello, 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