Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> writes:
> Lars Hjemli wrote:
>> Multiple checkout paths for a single submodule will bring havoc on
>> this plan, so I need to ask: what is the use-case for multiple
>> checkout paths?
>
> A use-case is the admin directory in the KDE repository. It has:
>
> KDE (superproject)
> +- kdelibs (subproject)
> | +- admin (subproject)
> | +- subdir1
> | +- ...
> +- kdebase (subproject)
> | +- admin (subproject)
> | +- subdir2
> | +- ...
> +- kdenetwork (subproject)
> | +- admin (subproject)
> | +- subdir3
> | +- ...
> ...
If these three instances of 'admin' are truly the same project
created in multiple places in the directory hierarchy, what is
the reason that it is not arranged like this instead?
KDE
+- admin
+- kdelibs
| +- subdir1
| +- ...
+- kdebase
| +- subdir2
| +- ...
+- kdenetwork
| +- subdir3
| +- ...
...
When kdelibs/subdir1 needs to access stuff in admin, instead of
going to ../admin, it could very well go to ../../admin couldn't
it?
It makes me wonder if the KDE's layout you quoted is a good
practice we would want to recommend for other people to follow.
If not, I doubt it is a good idea to model our important concept
after that layout to begin with.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
