On Wed, Mar 23, 2016 at 12:57:59PM -0700, Manoj Srivastava wrote: > On Wed, Mar 23 2016, Adam Borowski wrote: > > > On Wed, Mar 23, 2016 at 01:32:59PM +0000, Ian Jackson wrote: > >> Adam Borowski writes ("Re: a poll for Dgit workflows"): > >> > On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote: > >> > > Ah yes, source format 1.0 fits better here. Thanks for the pointer and > >> > > comments (Manoj, too). > >> > > >> > Please don't use source format 1.0, it sucks. Instead, you can: > >> > echo single-debian-patch >debian/source/options > >> > which gives you all upsides of 3.0 without the big downside, aka quilt. > > And creates a source package that does not correspond to my > repository. I don’t need to have a ./debian/patches in my repository; > all that information, along with a rich history of changes, is already > in git.
echo .pc/ >>.gitignore echo debian/patches/ >>.gitignore > I admit, I don’t much care whether the source debian.tar.xz > reflects my repository or not, if it didn’t leave artifacts that > dirtied my working tree when creating the source package. These artifacts are no different from the rest of build droppings, ie, they can be gitignored just the same. > I also sometimes unpack debian source packages on machines without dpkg > on them; source format 1.0 makes it somewhat easier. Valid point. [snip] > And, if I ma channel Marco here, multiple tarballs and purging > upstream debian/ does nothing for me. But there is nothing in that that > is tied to source format 3.0 (quilt); in theory all these features, if > deemed important enough an itch to scratch, can be addressed. I'd argue it's far less work to beat 3.0 into shape than to reimplent stuff for 1.0. > As long as arbitrarily serialized patch sets are not my > preferred form of modification, ./debian/patches seems like busy work. Hell yeah! Quilt is a (primitive) VCS, trying to put that into git is VCS-in-VCS which is lossage that breaks a good amount of git's upsides, such as bisect. Most upstreams today use git as well, using the same VCS means taking patches both ways is a cherry-pick away, and git deals with already applied patches without any user intervention. These days it's git and non-linear history that's a preferred form of modification. -- A tit a day keeps the vet away.