Why does 'submodule add' stage the relevant portions?

Why does 'submodule add' stage the relevant portions?

[Ramkumar Ramachandra]

Hi,

I find this behavior very inconsistent and annoying.  Why would I want
to commit the submodule change immediately?  Maybe I want to batch it
up with other changes and stage it at a later time.  Why should I have
to unstage them manually now?  I get the other side of the argument:
what if the user commits the .gitmodule change at a different time
from the file change?  In other words, the user should have a way of
saying 'submodule stage' and 'submodule unstage'.

Now, for the implementation.  Do we have existing infrastructure to
stage a hunk non-interactively?  (The ability to select a hunk to
stage/ unstage programmatically).  If not, it might be quite a
non-trivial thing to write.

Git 2.0 is coming soon, so I'm excited about breaking a lot of
backward compatibility ;)

Thanks.

Ram

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

[Jens Lehmann]

Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
> I find this behavior very inconsistent and annoying.  Why would I want
> to commit the submodule change immediately?  Maybe I want to batch it
> up with other changes and stage it at a later time.  Why should I have
> to unstage them manually now?  I get the other side of the argument:
> what if the user commits the .gitmodule change at a different time
> from the file change?  In other words, the user should have a way of
> saying 'submodule stage' and 'submodule unstage'.

Hmm, AFAIK you are the first to bring up such a feature, as in most
use cases doing a "git (submodule) add <path>" is expected to stage
what you added. Maybe you could teach the stage/unstage code to also
stage/unstage the corresponding part of the .gitmodules file, but
I'm not sure it is worth the hassle.

> Now, for the implementation.  Do we have existing infrastructure to
> stage a hunk non-interactively?  (The ability to select a hunk to
> stage/ unstage programmatically).  If not, it might be quite a
> non-trivial thing to write.

Have fun when adding two submodules and unstage only one of them
later. I think this feature will not work unless you analyze
.gitmodules and stage/unstage section-wise.

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

[Ramkumar Ramachandra]

Jens Lehmann wrote:
> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
>> I find this behavior very inconsistent and annoying.  Why would I want
>> to commit the submodule change immediately?  Maybe I want to batch it
>> up with other changes and stage it at a later time.  Why should I have
>> to unstage them manually now?  I get the other side of the argument:
>> what if the user commits the .gitmodule change at a different time
>> from the file change?  In other words, the user should have a way of
>> saying 'submodule stage' and 'submodule unstage'.
>
> Hmm, AFAIK you are the first to bring up such a feature, as in most
> use cases doing a "git (submodule) add <path>" is expected to stage
> what you added.

In my opinion, the 'git submodule add <path>' form is broken, because
it doesn't relocate the object store of the submodule repository (a
bug that we need to fix?).  I always use the 'git submodule add
<repository> <path>' form, which puts the object store of the
submodule repository in .git/modules of the parent repository.  This
form is nothing like 'git add', but more like a 'git clone': arguably,
'submodule clone' is a better name for it.

> Maybe you could teach the stage/unstage code to also
> stage/unstage the corresponding part of the .gitmodules file, but
> I'm not sure it is worth the hassle.

Maybe not.  I'm still not an heavy user of submodules; I notice many
breakages and inconsistencies, but I'm not sure what to fix first, and
how to go about fixing it.  I'm yet to look at git-subtree and draw
inspiration from its design.

Maybe the WTF "You need to run this command from the toplevel of the
working tree" needs to be fixed first?  I think it's a matter of a
simple pushd, popd before the operation and building the correct
relative path.  I'm not sure how it'll work with nested submodules
though.  Then again, I think nested submodules are Wrong; submodules
are probably not the right tool for the job.

>> Now, for the implementation.  Do we have existing infrastructure to
>> stage a hunk non-interactively?  (The ability to select a hunk to
>> stage/ unstage programmatically).  If not, it might be quite a
>> non-trivial thing to write.
>
> Have fun when adding two submodules and unstage only one of them
> later. I think this feature will not work unless you analyze
> .gitmodules and stage/unstage section-wise.

Yes, which is why I asked if we have existing infrastructure to make
this possible.

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

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Git 2.0 is coming soon, so I'm excited about breaking a lot of
> backward compatibility ;)

Don't.

I lack the sense of humor normal people seem to have, so even with
the smiley, anybody making such a comment will be thrown into my "do
not pay attention to them" box ;-).

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

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Git 2.0 is coming soon, so I'm excited about breaking a lot of
>> backward compatibility ;)
>
> Don't.

push.default is the necessary exception?

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

[Jonathan Nieder]

Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:

>>> Git 2.0 is coming soon, so I'm excited about breaking a lot of
>>> backward compatibility ;)
>>
>> Don't.
>
> push.default is the necessary exception?

A while ago there was a discussion of changes of the "If we were
starting over today, it would be obvious we should have made it work
the other way" kind and potential transition plans for them leading up
to 2.0.  It's way too late to throw new breakage in.

More generally, it doesn't make a lot of sense to save thinking about
such questions for the last minute before a new major release.  If an
important change will require breaking compatibility and can only be
done using a painful 5-year transition, start today (and send patches
to the ML when an appropriate quiet moment comes to get review) so the
5-year counter can start ticking.

Hoping that clarifies,
Jonathan

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

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>> Junio C Hamano wrote:
>>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>>>> Git 2.0 is coming soon, so I'm excited about breaking a lot of
>>>> backward compatibility ;)
>>>
>>> Don't.
>>
>> push.default is the necessary exception?
>
> A while ago there was a discussion of changes of the "If we were
> starting over today, it would be obvious we should have made it work
> the other way" kind and potential transition plans for them leading up
> to 2.0.  It's way too late to throw new breakage in.
>
> More generally, it doesn't make a lot of sense to save thinking about
> such questions for the last minute before a new major release.  If an
> important change will require breaking compatibility and can only be
> done using a painful 5-year transition, start today (and send patches
> to the ML when an appropriate quiet moment comes to get review) so the
> 5-year counter can start ticking.

I agree that big important changes that break backward compatibility
(like adding generation numbers to commit objects) will require this
kind of time and effort to stabilize.  Does a saner push.default
value, or even tweaking the output of 'git status' to show what 'git
status -sb' shows now (git status is porcelain, and no person in the
right mind will write a script to parse it), require this?  I'm
talking about slightly better defaults at the porcelain level, at
most.

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

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> I'm talking about slightly better defaults at the porcelain level,
> at most.

If a change does not even have to break backward compatibilty, that
is a regular enhancement and independent from 2.0, no?

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

[Jens Lehmann]

Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
>>> I find this behavior very inconsistent and annoying.  Why would I want
>>> to commit the submodule change immediately?  Maybe I want to batch it
>>> up with other changes and stage it at a later time.  Why should I have
>>> to unstage them manually now?  I get the other side of the argument:
>>> what if the user commits the .gitmodule change at a different time
>>> from the file change?  In other words, the user should have a way of
>>> saying 'submodule stage' and 'submodule unstage'.
>>
>> Hmm, AFAIK you are the first to bring up such a feature, as in most
>> use cases doing a "git (submodule) add <path>" is expected to stage
>> what you added.
> 
> In my opinion, the 'git submodule add <path>' form is broken, because
> it doesn't relocate the object store of the submodule repository (a
> bug that we need to fix?).

I don't think it is broken. Leaving the .git directory inside the
submodule makes perfect sense for some users (e.g. those which never
intend to push their submodule somewhere else) and doesn't do any
harm unless you want to remove it again in the future (or need to go
back to an older commit where the submodule directory would be in
the way). We have to think very hard before making such changes to
behavior quite some people may rely on, even though I agree some use
cases would profit from it and I think we would do it differently if
we could start over again.

What I think we need rather soonish is "git submodule to-gitfile",
which would help your case too. We should then hint that in those
cases where we refuse to remove a submodule when using "git rm" or
"git submodule deinit" (or the "git mv" for submodules I'm currently
preparing).

>  I always use the 'git submodule add
> <repository> <path>' form, which puts the object store of the
> submodule repository in .git/modules of the parent repository.  This
> form is nothing like 'git add', but more like a 'git clone': arguably,
> 'submodule clone' is a better name for it.

Hmm, it does a clone first and then adds the submodule and the change
to .gitmodules, so I still believe "add" is the correct term for it.
So I really like the color the shed currently has ;-)

> Maybe the WTF "You need to run this command from the toplevel of the
> working tree" needs to be fixed first?  I think it's a matter of a
> simple pushd, popd before the operation and building the correct
> relative path.

I won't object such a change (even though I suspect it'll turn out
more complicated than that).

>  I'm not sure how it'll work with nested submodules
> though.  Then again, I think nested submodules are Wrong; submodules
> are probably not the right tool for the job.

How did you come to that conclusion? Nested submodules make perfect
sense and most people agree that in hindsight --recursive should have
been the default, but again we can't simply change that now.

>>> Now, for the implementation.  Do we have existing infrastructure to
>>> stage a hunk non-interactively?  (The ability to select a hunk to
>>> stage/ unstage programmatically).  If not, it might be quite a
>>> non-trivial thing to write.
>>
>> Have fun when adding two submodules and unstage only one of them
>> later. I think this feature will not work unless you analyze
>> .gitmodules and stage/unstage section-wise.
> 
> Yes, which is why I asked if we have existing infrastructure to make
> this possible.

Not that I know of.

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

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> I'm talking about slightly better defaults at the porcelain level,
>> at most.
>
> If a change does not even have to break backward compatibilty, that
> is a regular enhancement and independent from 2.0, no?

Okay, I'm confused: why are you waiting for 2.0 to change push.default
then?  Isn't that just a "slightly better default at the porcelain
level" and hence a "regular enhancement"?

You're not worried about breaking everyone's muscle memory (is that
not part of backward compatibility)?  So, if I understand correctly, I
can do changes like the following at any time (provided the reviewers
agree that they're sane):
1. Don't make 'git submodule add' stage (which is what this thread was
originally about).
2. Set pull.autostash to true (I still have to re-roll and finish it ofcourse).
3. Set color.ui to auto.
4. Alias 'git status' to 'git status -sb'.
5. Set help.autocorrect to 20.

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

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

> Okay, I'm confused: why are you waiting for 2.0 to change push.default
> then?  Isn't that just a "slightly better default at the porcelain
> level" and hence a "regular enhancement"?

No.  Among other aspects, "git push" is used heavily by scripts.

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

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> Okay, I'm confused: why are you waiting for 2.0 to change push.default
>> then?  Isn't that just a "slightly better default at the porcelain
>> level" and hence a "regular enhancement"?
>
> No.  Among other aspects, "git push" is used heavily by scripts.

Oh, I see.  I would've expected scripts to specify the refspec
explicitly, instead of relying on a default like this.  Then again, I
saw jc/push-2.0-default-to-simple -- massive changes to scripts in our
own testsuite.

This whole "backward compatibility" thing is not black-or-white: it's
shades of gray.  Can I ask about how "backward incompatible" the other
suggestions I listed were, just so I get a rough idea of your scale?
Junio seems to be very extremist today.

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

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

> This whole "backward compatibility" thing is not black-or-white: it's
> shades of gray.  Can I ask about how "backward incompatible" the other
> suggestions I listed were, just so I get a rough idea of your scale?

It depends on how important the change is and how painful the proposed
transition is.

Please don't gratuitously break things.  If there is a smooth way to
accomplish the intended effect without much downside, that is
generally preferred, even if it is harder to write the code.

There are no absolutes here.  It is about helping people in the
real world who never asked for such-and-such feature to avoid
suffering real breakage.

Hope that helps,
Jonathan

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

[Ramkumar Ramachandra]

Jens Lehmann wrote:
> Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:
>> In my opinion, the 'git submodule add <path>' form is broken, because
>> it doesn't relocate the object store of the submodule repository (a
>> bug that we need to fix?).
>
> I don't think it is broken. Leaving the .git directory inside the
> submodule makes perfect sense for some users (e.g. those which never
> intend to push their submodule somewhere else) and doesn't do any
> harm unless you want to remove it again in the future (or need to go
> back to an older commit where the submodule directory would be in
> the way). We have to think very hard before making such changes to
> behavior quite some people may rely on, even though I agree some use
> cases would profit from it and I think we would do it differently if
> we could start over again.

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?

> What I think we need rather soonish is "git submodule to-gitfile",
> which would help your case too. We should then hint that in those
> cases where we refuse to remove a submodule when using "git rm" or
> "git submodule deinit" (or the "git mv" for submodules I'm currently
> preparing).

Why a new subcommand?  Is there a problem if we do the relocation at
the time of 'add'?  Will some user expectation break?

>>  I always use the 'git submodule add
>> <repository> <path>' form, which puts the object store of the
>> submodule repository in .git/modules of the parent repository.  This
>> form is nothing like 'git add', but more like a 'git clone': arguably,
>> 'submodule clone' is a better name for it.
>
> Hmm, it does a clone first and then adds the submodule and the change
> to .gitmodules, so I still believe "add" is the correct term for it.
> So I really like the color the shed currently has ;-)

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.

>> Maybe the WTF "You need to run this command from the toplevel of the
>> working tree" needs to be fixed first?  I think it's a matter of a
>> simple pushd, popd before the operation and building the correct
>> relative path.
>
> I won't object such a change (even though I suspect it'll turn out
> more complicated than that).

I'll have to investigate.

>>  I'm not sure how it'll work with nested submodules
>> though.  Then again, I think nested submodules are Wrong; submodules
>> are probably not the right tool for the job.
>
> How did you come to that conclusion? Nested submodules make perfect
> sense and most people agree that in hindsight --recursive should have
> been the default, but again we can't simply change that now.

Okay, I'll do it step-by-step now, with a live example:
1. git clone gh:artagnon/dotfiles, a repository with submodules.
2. git submodule update --init .elisp/auto-complete, a repository that
contains submodules.
3. .elisp/auto-complete/.gitmodules lists the submodules (lib/fuzzy,
lib/ert, and lib/popup).  Let's try to initialize them from that
directory ... No! go back to toplevel.
4. Fine.  Where are those submodules?  git submodule status doesn't list them.
5. Okay, let's join the paths by hand and try anyway: git submodule
update --init .elisp/auto-complete/lib/fuzzy.  Did you forget to 'git
add'?  Fantastic.
6. How am I supposed to initialize the darn submodules?!
7. git submodule update --init --recursive .elisp/auto-complete is the
ONLY way (is this even documented anywhere?).  But I just wanted to
initialize one, not all three!
8. Okay, now I want to execute a 'git submodule foreach' on just those
three submodules.  Seems impossible.  Fine, I'll do it myself: for i
in "lib/ert lib/fuzzy lib/popup"; do cd $i; git checkout master; git
reset --hard origin/master; cd ../..; done
9. Whew.  git status.  Changes in auto-complete.  git diff.
"Submodule .elisp/auto-complete contains modified content".  I'm not
allowed to see what changed now?
10. git checkout master; git reset --hard origin/master in
auto-complete.  git status.  How do I stage the changes in just
auto-complete, and not in auto-complete's submodules?  What is going
on, seriously?

This is just two levels of nesting: with more levels of nesting,
things only get worse.

>>>> Now, for the implementation.  Do we have existing infrastructure to
>>>> stage a hunk non-interactively?  (The ability to select a hunk to
>>>> stage/ unstage programmatically).  If not, it might be quite a
>>>> non-trivial thing to write.
> [...]
> Not that I know of.

Damn.  Then, it's certainly not worth the effort.  Atleast not now,
when there are bigger problems.

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

[Jens Lehmann]

Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:
>>> In my opinion, the 'git submodule add <path>' form is broken, because
>>> it doesn't relocate the object store of the submodule repository (a
>>> bug that we need to fix?).
>>
>> I don't think it is broken. Leaving the .git directory inside the
>> submodule makes perfect sense for some users (e.g. those which never
>> intend to push their submodule somewhere else) and doesn't do any
>> harm unless you want to remove it again in the future (or need to go
>> back to an older commit where the submodule directory would be in
>> the way). We have to think very hard before making such changes to
>> behavior quite some people may rely on, even though I agree some use
>> cases would profit from it and I think we would do it differently if
>> we could start over again.
> 
> 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'm not against changing that per se (we already did that for the
"update" case when cloning submodules), but I'm really not convinced
it is worth the downsides here (which it definitely was in the
"update" case).

>> What I think we need rather soonish is "git submodule to-gitfile",
>> which would help your case too. We should then hint that in those
>> cases where we refuse to remove a submodule when using "git rm" or
>> "git submodule deinit" (or the "git mv" for submodules I'm currently
>> preparing).
> 
> 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.

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.

>>>  I always use the 'git submodule add
>>> <repository> <path>' form, which puts the object store of the
>>> submodule repository in .git/modules of the parent repository.  This
>>> form is nothing like 'git add', but more like a 'git clone': arguably,
>>> 'submodule clone' is a better name for it.
>>
>> Hmm, it does a clone first and then adds the submodule and the change
>> to .gitmodules, so I still believe "add" is the correct term for it.
>> So I really like the color the shed currently has ;-)
> 
> 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.

>>> Maybe the WTF "You need to run this command from the toplevel of the
>>> working tree" needs to be fixed first?  I think it's a matter of a
>>> simple pushd, popd before the operation and building the correct
>>> relative path.
>>
>> I won't object such a change (even though I suspect it'll turn out
>> more complicated than that).
> 
> I'll have to investigate.

Ok, looking forward to that as I believe this would be a worthwhile
improvement.

>>>  I'm not sure how it'll work with nested submodules
>>> though.  Then again, I think nested submodules are Wrong; submodules
>>> are probably not the right tool for the job.
>>
>> How did you come to that conclusion? Nested submodules make perfect
>> sense and most people agree that in hindsight --recursive should have
>> been the default, but again we can't simply change that now.
> 
> Okay, I'll do it step-by-step now, with a live example:
> 1. git clone gh:artagnon/dotfiles, a repository with submodules.
> 2. git submodule update --init .elisp/auto-complete, a repository that
> contains submodules.
> 3. .elisp/auto-complete/.gitmodules lists the submodules (lib/fuzzy,
> lib/ert, and lib/popup).  Let's try to initialize them from that
> directory ... No! go back to toplevel.

That has got nothing to do with nested submodules but is the toplevel
requirement you already mentioned.

> 4. Fine.  Where are those submodules?  git submodule status doesn't list them.

Did you try 'git submodule status --recursive'? Without that option
nested submodules won't work well at all (maybe we need a config
option to let the user enable --recursive by default?).

> 5. Okay, let's join the paths by hand and try anyway: git submodule
> update --init .elisp/auto-complete/lib/fuzzy.  Did you forget to 'git
> add'?  Fantastic.

You either use --recursive to include all submodules or have to cd
into the submodules superproject (.elisp/auto-complete here) to do
"git submodule update --init lib/fuzzy".

> 6. How am I supposed to initialize the darn submodules?!
> 7. git submodule update --init --recursive .elisp/auto-complete is the
> ONLY way (is this even documented anywhere?).  But I just wanted to
> initialize one, not all three!

This is not the only way, see above. Patches to update submodules
across nested submodules are welcome.

> 8. Okay, now I want to execute a 'git submodule foreach' on just those
> three submodules.  Seems impossible.

What about 'git submodule foreach --recursive .elisp/auto-complete'?
Or - if that is your only populated submodule - a simple 'git
submodule foreach --recursive' will do it too.

> Fine, I'll do it myself: for i
> in "lib/ert lib/fuzzy lib/popup"; do cd $i; git checkout master; git
> reset --hard origin/master; cd ../..; done

... and check out some arbitrary commit which most probably doesn't
match what is committed in their superproject .elisp/auto-complete.
You asked for it ...

> 9. Whew.  git status.  Changes in auto-complete.  git diff.
> "Submodule .elisp/auto-complete contains modified content".  I'm not
> allowed to see what changed now?

Thought about stepping into .elisp/auto-complete and doing a diff
there to see what is modified? What does 'git status --recursive'
show?

> 10. git checkout master; git reset --hard origin/master in
> auto-complete.  git status.  How do I stage the changes in just
> auto-complete, and not in auto-complete's submodules?

By simply committing .elisp/auto-complete? Unless you record a
submodule commit in its superproject, there is nothing to commit,
right?

>  What is going on, seriously?

Pilot error, mostly omitting the --recursive option and some
- fixable - usability issues. Patches welcome.

> This is just two levels of nesting: with more levels of nesting,
> things only get worse.

Yes, you cannot have the cake and eat it. Either you incorporate
everything into a single repo (e.g. using subtree) and loose the
strong distinction which content belongs to which upstream repo
(which AFAIK is a valid choice unless you want to contribute back
to the submodule's upstream) or you'll have to cope with the
submodule borders showing up from time to time, reminding you
which part of the work tree has another upstream.

>>>>> Now, for the implementation.  Do we have existing infrastructure to
>>>>> stage a hunk non-interactively?  (The ability to select a hunk to
>>>>> stage/ unstage programmatically).  If not, it might be quite a
>>>>> non-trivial thing to write.
>> [...]
>> Not that I know of.
> 
> Damn.  Then, it's certainly not worth the effort.  Atleast not now,
> when there are bigger problems.

Yep, that's what I think too.

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

[Duy Nguyen]

On Mon, Mar 25, 2013 at 12:38 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Git 2.0 is coming soon, so I'm excited about breaking a lot of
> backward compatibility ;)

It's a long way to 1.39 before we jump to 2.0 ;)
-- 
Duy

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

[Ramkumar Ramachandra]

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.

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

[Jens Lehmann]

Am 26.03.2013 08:57, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> 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 think quite some users - and definitely myself - will do that as
soon as the full recursive checkout materialized, as that allows to
remove submodules without any directory remaining and even to replace
a submodule with a directory containing other files. And even with
current Git you already get a clean work tree when using "git rm" or
"git submodule deinit" (in current master) on a submodule iff it has
its .git directory stored in the .git directory of the superproject.
It is definitely not a Must Have right now, but I expect it to be
that in the near future.

>>> 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.

I'm not sure many submodule users do the same, but even then the
normal ways of unstaging the submodule and .gitmodules should be
sufficient here, no? I'd rather avoid adding a new command to git
submodule for that.