[Kde-scm-interest] Git roadmap
thiago at kde.org
Tue Sep 18 11:47:46 CEST 2007
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
My idea so far is:
1) we seed it with the "trunks" - SVN paths that should correspond to the git
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
> > 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
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
More information about the Kde-scm-interest