Re: [GSoC 11 submodule] Status update

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [GSoC 11 submodule] Status update

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:32

Phil Hord [off-list ref] writes:
It frightens me because it seems like a fundamental break from the
current submodule functionality.  Today a submodule exists as a git
repository with no knowledge that it is a submodule or who its
super-repository is.
The use of .git that is a text file that records where the real directory
is not limited to submodules.  Placing that "real directory" somewhere in
the .git directory of the superproject is merely a convention.

In other words, it does not change anything fundamental.
Once it finds it, it will
(safely, today) assume that is the .git directory relating to its
files.  After this change, the tool will be broken.
Then it is already broken if it does not pay attention to .git that is not
a directory but is a text file that records where the real directory is.
I think I can answer my other concerns now.  Do these answers sound right?

- What happens if the submodule working directory is dirty?  
- But what if the submodule working directory is 'clean' after considering
  .gitignore?  Do untracked/ignored files also get deleted?
- What if a 'git checkout' results in the submodule being removed?
- What if a 'git checkout' or 'git merge' results in submodule 'foo' being
  added where there is already a file named 'foo'?
These "different" questions are answered exactly the same way, which is:
  Treat it the same as git does for its own working directory.
When switching to another branch, a directory that does not exist in the
switched-to branch needs to be removed, but we would refrain from "rm -fr"
that directory if it has any leftover cruft in it (untracked and unignored
files). A submodule directory should behave in the same way.

Re: [GSoC 11 submodule] Status update

From: Phil Hord <hidden>
Date: 2016-06-15 22:51:32

On 06/29/2011 05:58 PM, Junio C Hamano wrote:
Phil Hord [off-list ref] writes:
quoted
It frightens me because it seems like a fundamental break from the
current submodule functionality.  Today a submodule exists as a git
repository with no knowledge that it is a submodule or who its
super-repository is.
The use of .git that is a text file that records where the real directory
is not limited to submodules.  Placing that "real directory" somewhere in
the .git directory of the superproject is merely a convention.

In other words, it does not change anything fundamental.
Thanks for pointing that out.  I was unaware of that feature until I saw
it discussed in another thread this week.  Even then, it was not clear
to me that this is the same feature being employed here.
When switching to another branch, a directory that does not exist in the
switched-to branch needs to be removed, but we would refrain from "rm -fr"
that directory if it has any leftover cruft in it (untracked and unignored
files). A submodule directory should behave in the same way.
Thanks.  I am suitably enclued and no longer afraid.

Phil
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help