I think I finally agree that it's best to develop submodules further
rather than introduce a new tool for the functionality I require. Here
are some explicit proposals for submodules so we can at least establish
agreement on what should be done. These are in order of decreasing
importance (to me)
la@bq:~/tmp/super$ git mv sub movedsub
fatal: source directory is empty, source=sub, destination=movedsub
This error here indicates that we didn't teach git to properly move
a submodule yet. It is one of my next goals to make "git [submodule]
mv sub movedsub" do the right thing here.
I'll digr
Quoting "Jens Lehmann" :
If the
submodules ever get reorganized and foo is moved to ./bar, then it is
impossible to check out older versions or alternate branches, since
the submodule is no longer where it is expected to be at the origin.
Your initial statement is not correct.
Please elabor
Quoting "Junio C Hamano" :
If the
submodules ever get reorganized and foo is moved to ./bar, then it is
impossible to check out older versions or alternate branches, since
the submodule is no longer where it is expected to be at the origin.
Isn't that exactly what the "module name" vs "module
Quoting "Junio C Hamano" :
Now
the subdirectory repositories are bound as submodules of the top
level directory just fine.
This is indeed possible, but with some serious caveats.
Firstly, if you simply do "git submodule add ./foo" (the obligatory
"./" being quite an unobvious pitfall), you g
Hello.
I intend to work on a "subrepository" tool for git, but before I
embark on the actual programming, I thought to first invite comments
on the general design.
Some background first. I know that there are several existing
approaches already for managing nested repositories, but none o
6 matches
Mail list logo
