clarification on git, central repositories and commit access lists

[Thomas Zander]

On Monday 20 August 2007 08:52:32 Adam Treat wrote:
> Your talk focused heavily on the evils of a central repository versus
> the benefits of a distributed model.  However, I wonder if what you
> actually find distasteful is not a central repository per se, but
> rather designing an SCM that relies upon *communication* with a central
> repository to do branching/merging or offline development.

Hi Adam.

Isn't there a git user ML?  I personally dislike people sending me emails 
with generic questions. Maybe Linus does as well :)

Reading your mail I do think the thing you are struggling with is how to 
map the old KDE workflow to git, and/or how to map the Linux kernel 
workflow to KDE.
I think a better way to look at it explore what options the software gives 
you. The options for different workflows is nearly endless with 
distributed source repositories and I think we need experimentation and 
we most probably will not end up with just one that is the most useful 
for everybody in KDE.

I personally learned the distributed stuff with darcs, there is a good 
page that is generically enough to be useful for git as well, and will 
help you a little. I bet git has good docs as well.
http://wiki.darcs.net/DarcsWiki/BestPractices

I just want to comment on two points; 
> What if I want to make a commit to kdelibs that will require changes in
> other modules for them to compile.  I will no longer be able to make a
> single atomic commit with changes to multiple submodules, right?
Don't think too long about that one; neither CVS nor SVN allow you to make 
atomic commits either.

> Also, won't we lose history when moving files/content between
> submodules?  
First; doesn't happen very often. And I think that just pointing to the 
other repo (in your commit message) tends to be enough as the user can 
then grab the other repo to get the rest of the history.

Anyway, to answer these questions you post requires *you* to work with 
distributed SCMs to find your own answers, I doubt anyone outside KDE can 
give an ideal scenario that just works for you.  In fact, I doubt there 
is such a scenario that works for the whole of KDE.  And that is the 
point of distributed SCMs.  It allows for a much more organic way of 
working based with merging done based on what this module or sub module 
needs.

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070820/17fc3ae1/attachment.sig>