[Kde-scm-interest] Git roadmap

[Thiago Macieira]

On Tuesday 18 September 2007 10:58:24 Johannes Sixt wrote:
> Thiago Macieira schrieb:
> > 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.

Exactly. No tool that I know of currently handles this. But I do believe it's 
something that can implemented in the fast-export tool without *too* much 
difficulty.

My idea so far is:
1) we seed it with the "trunks" - SVN paths that should correspond to the git 
branch "master"
2) it walks the SVN history and every time a directory was copied from one of 
the known branches, it records a new branch. It also records the relative 
path to the module root.

Renaming branches in git is easy and painless.

> > 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.

Indeed. This is what I want to do with a new tool called "git-xcopy". My 
current git-svn import of kdebase does that for the copy-from-kdelibs 
directories. I did the merging manually, though, by using grafts -- this 
worked because I was importing from SVN and the final product of the merge 
was already there.

I do believe the conversion will have to follow such a procedure. That is, the 
fast-export tool will need to simulate filter-branch --subdirectory, 
introduce the commits and then do the merge (two "from" lines).

One thing though: I don't understand step 3. What fixes are you thinking of 
there?

> > 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.

Sounds like the task for "git-xcopy" is not so difficult after all. We just 
need to automate the procedure.

My only concern is not the progression or normal evolution of a module, but 
instead "move back and forth" of something. Granted, that doesn't happen 
often, but it could. I know it happened once in 
kdelibs->kdebase->kdelibs->kdebase (KSSL-related). That specific case we can 
easily solve by hand, but what about the future?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20070918/b1b568f7/attachment.pgp