> download-repos
> fatal: git checkout: updating paths is incompatible with switching
> branches. Did you intend to checkout 'origin/development/2.0' which can
> not be resolved as commit?
Should be fixed by now
>
> Just out of curiosity, why did you not use submodules? For strigi all one
> has to do is clone the meta repo and then git submodule update and it
> pulls in everything else.
I have done a lot of internet research about tools to manage a collection of
sub-repositories. Among the few available solution, git submodules was
probably the solution which suited my needs least. I'd even say that git
submodules is either unfinished work, or written for a very narrow usecase.
Why? The main flaw is that a submodule is referenced by a commit id (SHA1). It
is not on a branch. If you do work in libkexiv2 (remember you are not on a
branch, so extra work is needed before you can commit), push, you have to go
to the super-repo, update the reference, and push the superrepo. As you dont
want to do that for every commit, a submodule setup can be used to have a
stable snapshot unchanged for some time, but it is in no way suited for a
setup like ours where all modules are changing rapidly and are essentially
developed by the same people. Probably a minor change, a --track option, would
be sufficient to make submodules usable; patches have been proposed, but were
rejected for reasons unknown to me.
With the gitslave tool, we have a tool which does essentially the same, but
just works the way we like (perl script patched at some small places)
Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
