[Kde-scm-interest] Git roadmap

[Johannes Sixt]

Thiago Macieira schrieb:
> Johannes Sixt wrote:
>> Thiago Macieira schrieb:
>>> 2) the conversion from Subversion to git
>>>   Chris's work on the git-svn-fastexport tool is a good start, but our
>>> repository is extremely complex. We need to develop the tool further
>>> to be able to import the repository correctly.
>> Sorry, but I have to ask: What can be "complex" in an SVN repository?
> 
> All moves.
> 
> We've done once a "trunk move" -- see revisions 409200 through 409209. No 
> svn-to-git tool that I have tried so far can handle that. We need a tool 
> that understands that.

OK.

> We've also got partial branches: when you make a copy of a subtree of a 
> module. That's a valid branch and should be handled too. I have no idea 
> if:
> a) we want to keep those branches (the official ones are always full-tree)
> b) any tool can handle it

I have the impression that such partial copies usually coincide with 
submodule boundaries. Where this is not the case, manual fixup is needed, by 
pretending that a full tree (the containing sub-module) was copied, but only 
part of it was ever touched.

> There's also the issue of issue of copy-with-history across modules.

I *think* this could be solved with git's git has a merge strategy 
"subtree", which is sort of a "poor man's sub-module" support:

1. Use git filter-branch --subdirectory to extract the history from the 
source module.

2. Splice the directory with git merge -s subtree into the destination.

3. If necessary, follow up with another suitable git filter-branch in the 
destination to fix the history.

Maybe this can even be automated.

>> The most important information to be recovered are where merges
>> happened. It would be invaluable to represent them in the converted git
>> repository.
> 
> These, I think, can be done manually. I.e., after converting to git, we 
> can use grafts to mark the commits that were merges and then do a single, 
> major filter-branch to make the grafts permanent.

Agreed.

>> I don't think that it's necessary to have a finer-grained separation.
> 
> I do think that applications in extragear, kdereview and playground can 
> each have a module of its own. The progress of an application, leading to 
> extragear, would be a simple change in submodule relationships.

Sure, why not.

> The progression of kdereview->main modules would be handled with the 
> copy-with-history tool.

You would create the modules in kdereview as totally separate repositories. 
Once they are mature, they are either integrated as sub-module in the 
destination module, or merged with merge-subtree strategy, at which time you 
have the history preserved, and also spliced the module as a proper 
subdirectory inside the destination.

git-gui inside git's own repository is handled like this.

>> IMHO, there should exist "the one and only official KDE repository".
>>
>> And only few people have push access to it.
>>
>> Those people are the "integrators". They pull from the "trusted
>> lieutenants" (who are probably in charge of the individual submodules)
>> and publish to this official repository.
> 
> Unfortunately, I don't agree (read through, please). This goes against the 
> KDE developer culture.

Having read through your arguments, I think we have a good deal of agreement 
after all.

Lets give things names: Let there be git://git.kde.org/. Then I propose this 
arrangement of repositories:

The /master hierarchy (only push-accessible by (few) integrators):
/master/KDE.git         that's the "umbrella", supermodule
/master/kdelibs.git
/master/kdebase.git
/master/koffice.git
...

Note that the "umbrella" lives as a sibling of its submodules, because we 
are talking about bare repositories, i.e. without a working directory.

Application or topic specific hierarchies, accessible by single users or the 
public, according to each group's policies:

/kate/master/KDE.git
/kate/master/kdelibs.git
/kate/master/koffice.git
/kate/dhaumann/KDE.git
/kate/dhaumann/kdelibs.git
/kate/dhaumann/kdebase.git
/kate/public/KDE.git
/kate/public/kdelibs.git
/kate/public/kdebase.git
/phonon/...
/krita/...
/kde3support-removal/...
/kio/...
/i18n/...

I picked kate as the prominent example because I know it best. It should 
illustrate that:
- there is a "master" that represents the current development version and it 
is push-accessible only by kate's (few) "lieutenants";
- there are private repositories that are push-accessible only by single users
- there is a public area where everyone can push to.

An important point is that the hierarchy is organized primarily after 
applications or topics, *not* sub-modules.

I propose to arrange that public pushes cannot advance other people's 
branches. For example, in kate/public/kdebase.git, I (j6t) can only push to 
branches whose names begin with j6t/:

git push git://git.kde.org/kate/public/kdebase.git \
              indent-fix:j6t/indent-fix

This way I cannot overwrite (accidentally or deliberately) other people's 
changes.

Then I can ask (eg.) Dominik (one of the kate gurus) to pull this branch (or 
cherry-pick from it). Once Dominik is satisfied with my changes, he would 
eventually push them into kate/master/*, and then himself ask $integrator to 
pull from git://git.kde.org/kate/mater/kdebase.git.

> We have lots of people going through all modules and fixing bugs. The 
> whole KDE 4 porting effort has led to that: if you change something in 
> kdelibs that makes other modules break, you are responsible for fixing 
> ALL other modules too -- KDE modules, koffice, extragear, etc.
> 
> Where would those people push to?

Fixed a kate bug? Push to kate/public/*
KIO related? Push to kio/public/*

It should be possible to find a category (topic or application) for any 
change, even if it touches many modules at the same time. By having an extra 
hop before a change enters the official master, you (almost) automatically 
get peer review with all its benefits.

-- Hannes