clarification on git, central repositories and commit access lists

[Johannes Sixt]

Thiago Macieira wrote:
> That counts as atomic commits to me. But that's *still* not what I want. I
> want to have atomic changesets. That is, I don't want to have one big commit
> saying "updating API XYZ and adapting to it throughout". I want to send one
> changeset containing the API changes (possibly more than one commit), plus
> the adaptations. That way, if something breaks in the future, you won't go
> back to find one humongous diff that says "new API".
> 
> Git provides that "atomic changeset" behaviour, but not across modules. Not
> even across submodules, so I'm beginning to thing an eventual KDE Git server
> would still have one big tree. We'll need Git to support partial-tree
> checkouts.

Oh, it does provide that atomicity - via the superproject. Any
cross-module change must be accompanied by a final superproject commit,
which tells the revisions are "compatible".

So:
1. you make a series of commits that change the API in kdelibs,
2. then make one (or more) commits that adjust the callers in the other
modules,
3. finally, you make a commit in the superproject.

If you do a diff in the superproject, you get this big "new API" diff;
but when you look into the submodules, you have all the details that you
want.

-- Hannes