[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: clarification on git, central repositories and commit access lists
From:       Johannes Sixt <J.Sixt () eudaptics ! com>
Date:       2007-08-20 11:28:47
Message-ID: 46C97AEF.7CEE3FC3 () eudaptics ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]