[arch-dev-public] Git for the repos

Dan McGee dpmcgee at gmail.com
Wed Aug 24 19:04:33 EDT 2011

On Wed, Aug 24, 2011 at 3:53 PM, Florian Pritz <bluewind at xinu.at> wrote:
> So it came up in IRC again and I'll try to sum up the discussion:

Great. Another bitchfest on this topic! I'm going to get a bit pissy
here because it isn't like git wasn't around when we moved to SVN, and
we came to the conclusion then that the workflow with git was no
better/worse than the one proposed by Jason Chu using SVN.

Obviously git has changed since then (as has SVN), but we're putting
the cart ahead of the horse here- our (well, not mine) insistence on
using git to manage packages, rather than actually listing the damn
problems we have now in an objective manner.

> SVN checkouts tend to break,
Examples? Or is this just hearsay like everything else because we're
on a witchhunt, and SVN looks like one. I've had a full repo checkout
for 2 years that has never broken. Ever.

> some people only use it for our repos and
> not anywhere else, it's slow.
Don't disagree with you on this point, however your amazing git 'one
repo per package' idea below sounds like a nightmare for those of us
that like having full checkouts and updating them regularly.
Submodules or not, its going to be disastrous.

> We agreed on one git repo per package because you can't do partial
> checkouts in git and you hardly need the history of all packages anyway.
Oh really? I tend to like having full history and a timeline,
especially when I can link it to a move from [testing] to [core] of 60
other packages. So we're throwing any sort of atomicity and ordering

You also realize that the full git history of current SVN weighs in at
only 120 MB? This isn't all that bad, and at least there we have a
bloodline of all packaging activity rather than having that scattered
across 4339 git repositories.

> To keep track of released packages, dbscripts maintains it's own (git?)
> meta database which contains only the package version and pacman repo of
> the package. The version corresponds to a tag in the package's git repo.
> We can't use tags like "testing-i686" because you can't reuse tags in git.
So how do we know what version is in testing vs what version is in
core vs trunk/master? Branches?

> I'd like to hear some comments about this.
My comments are this- last time I proposed a git solution[1] (yes, I
did this back in 2007!) I at least made a sample repo and demo of it,
which let people weigh it against the SVN option also on the table at
the time. I'm not happy with change just to change, and this current
"let's move to git" plan sounds half-baked, and not all repercussions
thought out.

Like I said, sorry for being pissy about this. I'm glad the new blood
here is trying to push change for the better, but I'm worried you are
just pushing change fore the sake of change, given that we've spent
time researching and developing our switch from CVS and chose SVN over
git at the time.

Here is the former discussion lead email:
And see the October 2007 archive, search "Killing CVS", for many more:


[1] http://mailman.archlinux.org/pipermail/arch-dev-public/2007-October/002191.html

More information about the arch-dev-public mailing list