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

Switch to git after all?



Hi team,

should we switch to git? After all, git has won™.

What changed my mind?
I noticed that it is not so much darcs vs. git that I’m concerned about,
but rather workflows and repository layouts. I really dislike the
git-buildpackage’s approach. It might be suitable for one or few
complicated packages, but I find it unsuitable for our style of
mass-maintenance of a large number of very simple packages.

Especially with the helpers in our tools repository (mass-upgrade.hs,
diff-upgrade.sh, mass-release.sh, mass-build.sh and mass-upload.sh) I
can be very efficient in maintaining lots of packages. In particular, I
can upgrade dozends of packages without having to unpack the upstream
tarball at all! (Besides what happens during the build, but that is
automated.) Also, I can have all our repos checked out without wasting
lots of space. And I don’t see the point of pulling the history of, say,
gtk2hs just to upgrade a version.

With these scripts and tools like debchange, I hardly called darcs
directly anyways. In the end, we use darcs as a simple file storage with
tagging and history. Git would suit us equally well here.

What would we lose? 
 * The nice plain view on the repos at
        http://anonscm.debian.org/darcs/pkg-haskell/tools/all-packages/
   This is somewhat approximated by gitweb.
 * http://pkg-haskell.alioth.debian.org/cgi-bin/pet.cgi needs to be 
   modified to work. But maybe switching to git means that we can simply
   start using a PET3 hosted by http://pet.debian.net/.

Anything else?

So the way forward would be to convert all our darcs repos into git
repos (the latest version of darcs can do that, preserving history), but
with the existing debian/-only layout. Then our various scripts need to
be adjusted, and a round of mass-changing the VCS-fields. Anything else?

We could then also drop the unmaintained darcs-monitor from the
repository.

Thoughts?

Greetings,
Joachim

PS: If above description of the workflow is news to you, maybe I need to
talk more about it. I get the impression (e.g. from obviously not
sbuild-built uploads) that not all are aware of the possibilities, and
I’m worried that some of you spent unnecessary amount of work on
avoidable tedious work.

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: