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

Re: a poll for Dgit workflows



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.


Reply to: