Re: Why does 'submodule add' stage the relevant portions?

[Ramkumar Ramachandra <artagnon@gmail.com>]

Jens Lehmann wrote:
> Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra:
>> Doesn't that sound horribly crippled to you?  Is there any advantage
>> to leaving the .git directory inside the submodule?  Isn't it always
>> better to relocate it?
>
> It's not crippled at all, that is just the way it was from submodule
> day one. And no, it isn't always better to relocate it. E.g. when
> you want to be able to just tar away work tree and history someplace
> else because you don't have (or don't want) an upstream to push to,
> you'd be very surprised a "submodule add" moved your .git directory
> someplace else effectively nuking the backup of your history and
> refs (guess under what circumstances you'll notice that). While I
> believe most submodule users would benefit from such a relocation, I
> consider the other use cases as valid and we would introduce silent
> breakage on them. On the other hand I made all relevant commands
> complain loudly about the .git directory in the submodule's work
> tree when it matters, so users can do something about it when they
> need it and are told so.

I see.  Thanks for the explanation.

>> Why a new subcommand?  Is there a problem if we do the relocation at
>> the time of 'add'?  Will some user expectation break?
>
> For me relocation at the time of 'add' would be ok with a new option
> (and it might also make sense to have a config option changing the
> default for users who want that), but not as the default.

Makes sense.  This seems trivial to implement: I'll get to work on it soon.

> And leaving aside 'add', there are tons of submodules out there
> which were cloned with older Git who have their .git directory
> inside the work tree. So a new subcommand (or at least a helper
> script in contrib) to relocate the .git directory would really help
> here to migrate these legacy submodules without users having to
> worry about data loss.

The question is: after using a "non-relocated submodule" for some
time, will the user suddenly decide to make it a "relocated submodule"
one day?

>> I meant a variant of add that would clone, but not stage.  I was
>> arguing for a new subcommand so that I don't have to touch 'submodule
>> add', not for a rename.
>
> Ah, now I get it, I was confused by your reference to 'git submodule
> add <repository> <path>'. I have to admit I still don't understand
> the use case you have for adding a submodule without staging it, but
> maybe it is just too late here.

I usually reset after running 'git submodule add', because I rarely
commit the added submodule immediately after adding it.