On Tue, 2017-01-03 at 18:37 -0800, Russ Allbery wrote: > Even if we never used tarballs, and instead our unit of operation was > the upstream Git repository plus Debian branches, I would maintain a > rebased branch of Debian changes to upstream 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. To me this is just the software engineering 101 rule "break just large software projects into smaller, easily understood and documented modules" applied to change control. The reason is identical - it's so someone coming along behind you can easily understand what you have done and why. For those of us at a certain age, that someone else coming along behind might be ourselves a few months later. Whether it's mandatory seems to depend on how big the team is. A large DD team packaging who submits patches upstream to large project will find it unavoidable. (The Debian kernel currently carries 400 patches, totalling 50K lines. Managing that as a single lump would be impossible.) On the other hand a one person team who doesn't contribute upstream could reasonably say it's pointless. I know most Debian packages are a one horse affair, but I am still surprised by the number of DD's here claiming this software 101 process is _always_ pointless. Source format "3.0 (quilt)" is a straightforward way of storing a series of small documented patches. This is in contrast to quilt(1) the program, which is a way maintaining those patches. I'm not fond of quilt(1) as I regularly manage to get myself into states I can only get out of using "rm -r; dpkg-source -x ...; reapply work done so far". The kernel uses git as a better quilt (both are spin-offs from the kernel). Gits adds some new tricks. It doesn't get into impossible to recover from states (yeh!). The history it keeps allows it compare and merge change sets - something that has to be done manually with quilt. That history also provides some extra features like git bisect, and the ability to trace copyright - but they aren't so important. What is important is git as it is used by the kernel devs still produces small, rebased, documented patches. If it didn't I doubt the kernel would be using it. The central issue here appears to be that none of the proposed ways of using git within Debian help with that task. Debian packages that do use git and have patches don't use git to generate the patches. Eg, the kernel team appears to use quilt(!) to maintain its patch series, even though they use git too. If you are using quilt anyway because you like small documented patches, but you are a one horse team and so aren't concerned about parallel work flows a reasonable question is: why use git at all?  I'm not on the kernel team, so I can't be sure about them using quilt. I guess they do because their debian/bin/test-patches tool does use quilt.
Description: This is a digitally signed message part