Am 15.10.2012 00:59, schrieb Lauri Alanko:
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
Quoting Junio C Hamano gits...@pobox.com:
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
Am 14.10.2012 12:19, schrieb Lauri Alanko:
Quoting Junio C Hamano gits...@pobox.com:
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
Quoting Jens Lehmann jens.lehm...@web.de:
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
Am 14.10.2012 17:27, schrieb Lauri Alanko:
Quoting Jens Lehmann jens.lehm...@web.de:
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
Am 14.10.2012 17:27, schrieb Lauri Alanko:
Quoting Jens Lehmann jens.lehm...@web.de:
What's wrong with making git clone all submodules together with the
superproject (when the user said he wants to update all submodules on
clone too by setting a - still to be added - config option)?
Depends
Am 14.10.2012 17:27, schrieb Lauri Alanko:
Quoting Jens Lehmann jens.lehm...@web.de:
Did you notice that git fetch fetches all those submodules too which
have been updated in the commits fetched for the superproject, no matter
on what branch they are on?
No. This would be great, but this is
Jens Lehmann jens.lehm...@web.de writes:
Again, the user experience is currently suboptimal.
You mentioned multiple things in your responses that you are
planning to address, but I am wondering if the first step before
doing anything else is to have a list of known-to-be-suboptimal
things and
Am 14.10.2012 20:04, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
Again, the user experience is currently suboptimal.
You mentioned multiple things in your responses that you are
planning to address, but I am wondering if the first step before
doing anything else is to
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 of
Lauri Alanko l...@iki.fi writes:
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
Quoting Junio C Hamano gits...@pobox.com:
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
Lauri Alanko l...@iki.fi wrote:
I'm going to get a bit religious here:
anything longer than a screenful shouldn't be written in shell ...
Whence cometh this religion? I've heard of a modularity principle
wherein no one function, in any language, ought to be longer than a
page, but what's
Lauri Alanko l...@iki.fi writes:
Firstly, if you simply do git submodule add ./foo (the obligatory
./ being quite an unobvious pitfall), you get something quite
fragile, since now we have submodule.foo.url = ./foo. If the
submodules ever get reorganized and foo is moved to ./bar, then it is
14 matches
Mail list logo