From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
David Turner <David.Turner@twosigma.com>,
Brandon Williams <bmwill@google.com>
Subject: Re: [PATCH 0/6] git-rm absorbs submodule git directory before deletion
Date: Tue, 13 Dec 2016 11:38:57 -0800 [thread overview]
Message-ID: <CAGZ79kYsfybEBnWzv4OjCCLe70fNS=roZdKDbN_DSb4PDVJj7g@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79kZCza=cwtzQ7raU3ch_Z_5TDqt0AGN2fPHiRSTDu66Fag@mail.gmail.com>
On Tue, Dec 13, 2016 at 11:13 AM, Stefan Beller <sbeller@google.com> wrote:
> On Tue, Dec 13, 2016 at 11:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>>> I do not think there is no dispute about what embedding means.
>>>
>>> double negative: You think we have a slight dispute here.
>>
>> Sorry, I do not think there is any dispute on that.
>>
>>>> A
>>>> submodule whose .git is inside its working tree has its repository
>>>> embedded.
>>>>
>>>> What we had trouble settling on was what to call the operation to
>>>> undo the embedding, unentangling its repository out of the working
>>>> tree. I'd still vote for unembed if you want a name to be nominated.
>>>
>>> So I can redo the series with two commands "git submodule [un]embed".
>>>
>>> For me "unembed" == "absorb", such that we could also go with
>>> absorb into superproject <-> embed into worktree
>>
>> With us agreeing that "embed" is about something is _IN_ submodule
>> working tree, unembed would naturally be something becomes OUTSIDE
>> the same thing (i.e. "submodule working tree").
I do not agree, yet.
So I thought about this for a while.
The standard in Git is to have the .git directory inside the working tree,
which is why you are convinced that embedded means the .git is in the
working tree, because you approach this discussion as the Git maintainer,
spending only little time on submodule related stuff.
The desired standard for submodules is to have the git dir inside the
superprojects git dir (since 501770e, Aug 2011, Move git-dir for
submodules), which is why I think an "embedded submodule git dir"
is inside the superproject already.
I think both views are legit, and we would want to choose the one that
users find most intuitive (and I think there will be users that find either
viewpoint intuitive).
So when you have typed "git submodule ", I wonder if a user would
assume a submodule-centric mindset of how submodules ought to
work or if they still look at a submodule as its own git repo
that just happens to be embedded into the superproject.
I guess the latter is the case, so embedding is actually inside the working
tree and un-embedding is the relocation to the superproject.
next prev parent reply other threads:[~2016-12-13 19:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-13 1:40 [PATCH 0/6] git-rm absorbs submodule git directory before deletion Stefan Beller
2016-12-13 1:40 ` [PATCH 1/6] submodule.h: add extern keyword to functions Stefan Beller
2016-12-13 1:40 ` [PATCH 2/6] submodule: modernize ok_to_remove_submodule to use argv_array Stefan Beller
2016-12-13 1:40 ` [PATCH 3/6] submodule: add flags to ok_to_remove_submodule Stefan Beller
2016-12-13 1:40 ` [PATCH 4/6] ok_to_remove_submodule: absorb the submodule git dir Stefan Beller
2016-12-13 1:40 ` [PATCH 5/6] t3600: slightly modernize style Stefan Beller
2016-12-13 1:40 ` [PATCH 6/6] rm: add absorb a submodules git dir before deletion Stefan Beller
2016-12-13 3:28 ` brian m. carlson
2016-12-13 17:51 ` Stefan Beller
2016-12-13 18:06 ` David Turner
2016-12-13 7:28 ` [PATCH 0/6] git-rm absorbs submodule git directory " Junio C Hamano
2016-12-13 17:55 ` Stefan Beller
2016-12-13 18:53 ` Junio C Hamano
2016-12-13 19:07 ` Stefan Beller
2016-12-13 19:11 ` Junio C Hamano
2016-12-13 19:13 ` Stefan Beller
2016-12-13 19:38 ` Stefan Beller [this message]
2016-12-13 19:47 ` Junio C Hamano
2016-12-13 20:09 ` Stefan Beller
2016-12-13 20:22 ` Stefan Beller
2016-12-13 19:54 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGZ79kYsfybEBnWzv4OjCCLe70fNS=roZdKDbN_DSb4PDVJj7g@mail.gmail.com' \
--to=sbeller@google.com \
--cc=David.Turner@twosigma.com \
--cc=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).