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

Re: Git?

Joachim> Not being able to modify stuff outside of debian/ is considered
Joachim> a feature by some :-)

+1.  If I dget a package I've never looked at before, it's much easier
for me to understand Debian-specific patches if they are coherent and
commented in debian/patches, than if they are applied directly to the
upstream tree.

John> I was forced to abandon [Darcs] due to all the conflicts it
John> generated.  Eventually, its merge-in-exponential-time problem
John> became so severe that it became unusable.

This has significantly improved in Darcs 2, as long as you use the
darcs-2 repository format introduced in 2.0.  Note that it only became
the default for new projects ("darcs init") in 2.2.

Joachim> I made the same experience when packaging xmonad. I think that if we use
Joachim> darcs (which would be worth a try), we should not try to mix it with any
Joachim> upstream darcs repository – just import upstream from the released
Joachim> tarballs. Or just keep debian/.

+1.  My experiences trying to maintain the Darcs debian package as a
branch of the upstream repository have been unpleasant.  I think this
was primarily because I imported a .diff.gz (from before I took over the
package) which created an ongoing whitespace conflict in configure.ac.

Joachim> I’m inclined to favor Darcs and tracking only debian/, extending
Joachim> debcheckout and darcs-buildpackage to handle the debian/-only tracking
Joachim> and see if it works out ok.

+1.  Darcs' slowness and conflictiness seem to be improving a faster
than git's UI, but I admit I'm a biased observer (though I use both) :-)

Reply to: