Re: [PATCH] glossary: add "remote" and "submodule"
On Wed, May 27, 2015 at 4:05 PM, Junio C Hamano wrote: > Stefan Beller writes: > +[[def_submodule]]submodule:: + A <> inside another repository. The two + repositories have different history, though the outer repository + knows the commit of the inner repository. >>> >> ... But correctness trumps brevity indeed. > > I do not think the correct way is that much longer, though. > > A repository inside another repository. The two repositories have different > history > A repository that holds the history of a separate project inside another > repository > > Heh, they are the same length, no? > >> >>> >>>A repository that holds the history of a separate project >>>inside another repository (the latter of which is called >>>superproject). >> >> This is better than what I proposed, but confusing. When naming >> a project a submodule, my mental standpoint is the superproject. >> ("This project has the submodule foo and bar"). But In your description >> the superproject is called "another repository". > > That is because you are adding an entry for "submodule" to the > glossary, no? I was writing from submodule's point of view, i.e. "I > (submodule) is inside another repository, and my project is separate > from that other repository's". The submodule doesn't know it's a submodule though, so the point of view "I (as a submodule)" only happens rarely in the real world? I have a library in mind when talking about submodules. And the libraries maintainer may not care if their library is used as a submodule or just "make install"ed or just put somewhere in the filesystem Usually submodules are only interesting from the superprojects point of view, like "I want to upgrade libfoo now, so I make a commit changing the gitlink of the submodule to point at that tag/commit" That's why I found the presented perspective a bit strange. > >>>The containing superproject knows about the >>>names of (but does not hold copies of) commit objects of the >>>contained submodules. >> >> That makes sense to point out here. Though should we also introduce >> "superproject" now? > > Yes, that is what I was hinting at. ok -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: add "remote" and "submodule"
Stefan Beller writes: >>> +[[def_submodule]]submodule:: >>> + A <> inside another repository. The two >>> + repositories have different history, though the outer repository >>> + knows the commit of the inner repository. >> > ... But correctness trumps brevity indeed. I do not think the correct way is that much longer, though. A repository inside another repository. The two repositories have different history A repository that holds the history of a separate project inside another repository Heh, they are the same length, no? > >> >>A repository that holds the history of a separate project >>inside another repository (the latter of which is called >>superproject). > > This is better than what I proposed, but confusing. When naming > a project a submodule, my mental standpoint is the superproject. > ("This project has the submodule foo and bar"). But In your description > the superproject is called "another repository". That is because you are adding an entry for "submodule" to the glossary, no? I was writing from submodule's point of view, i.e. "I (submodule) is inside another repository, and my project is separate from that other repository's". >>The containing superproject knows about the >>names of (but does not hold copies of) commit objects of the >>contained submodules. > > That makes sense to point out here. Though should we also introduce > "superproject" now? Yes, that is what I was hinting at. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: add "remote" and "submodule"
On Wed, May 27, 2015 at 3:29 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Noticed-by: Philip Oakley >> Signed-off-by: Stefan Beller >> --- >> Documentation/glossary-content.txt | 10 ++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/glossary-content.txt >> b/Documentation/glossary-content.txt >> index bf383c2..e303135 100644 >> --- a/Documentation/glossary-content.txt >> +++ b/Documentation/glossary-content.txt >> @@ -469,6 +469,11 @@ The most notable example is `HEAD`. >> <> to describe the mapping between remote >> <> and local ref. >> >> +[[def_remote]]remote repository:: >> + A <> which is used to track the same >> + project but resides somewhere else. To communicate with remotes, >> + see <> or <>. >> + > > OK. > >> @@ -515,6 +520,11 @@ The most notable example is `HEAD`. >> is created by giving the `--depth` option to linkgit:git-clone[1], and >> its history can be later deepened with linkgit:git-fetch[1]. >> >> +[[def_submodule]]submodule:: >> + A <> inside another repository. The two >> + repositories have different history, though the outer repository >> + knows the commit of the inner repository. > > I'd stress that they are not just different histories (as the > 'master' and the 'maint' branches of my project has different > histories) but they are separate projects. Perhaps like this? This is a very subtle distinction IMHO, as both master and maint "are the same project". Looking from enough distance, it's just the git project without the fine detail of what makes these 2 histories different. I tried coming up with a short paragraph, which may explain my choice of words. But correctness trumps brevity indeed. > >A repository that holds the history of a separate project >inside another repository (the latter of which is called >superproject). This is better than what I proposed, but confusing. When naming a project a submodule, my mental standpoint is the superproject. ("This project has the submodule foo and bar"). But In your description the superproject is called "another repository". >The containing superproject knows about the >names of (but does not hold copies of) commit objects of the >contained submodules. That makes sense to point out here. Though should we also introduce "superproject" now? > > It is not like that it is strange or unintuitive that the > superproject knows about some commits in its submodule. "X, though > Y" however makes it sound as if Y is true "despite X". I do not > think there is any "despite" here. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: add "remote" and "submodule"
Stefan Beller writes: > Noticed-by: Philip Oakley > Signed-off-by: Stefan Beller > --- > Documentation/glossary-content.txt | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/glossary-content.txt > b/Documentation/glossary-content.txt > index bf383c2..e303135 100644 > --- a/Documentation/glossary-content.txt > +++ b/Documentation/glossary-content.txt > @@ -469,6 +469,11 @@ The most notable example is `HEAD`. > <> to describe the mapping between remote > <> and local ref. > > +[[def_remote]]remote repository:: > + A <> which is used to track the same > + project but resides somewhere else. To communicate with remotes, > + see <> or <>. > + OK. > @@ -515,6 +520,11 @@ The most notable example is `HEAD`. > is created by giving the `--depth` option to linkgit:git-clone[1], and > its history can be later deepened with linkgit:git-fetch[1]. > > +[[def_submodule]]submodule:: > + A <> inside another repository. The two > + repositories have different history, though the outer repository > + knows the commit of the inner repository. I'd stress that they are not just different histories (as the 'master' and the 'maint' branches of my project has different histories) but they are separate projects. Perhaps like this? A repository that holds the history of a separate project inside another repository (the latter of which is called superproject). The containing superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules. It is not like that it is strange or unintuitive that the superproject knows about some commits in its submodule. "X, though Y" however makes it sound as if Y is true "despite X". I do not think there is any "despite" here. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] glossary: add "remote" and "submodule"
Noticed-by: Philip Oakley Signed-off-by: Stefan Beller --- Documentation/glossary-content.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index bf383c2..e303135 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -469,6 +469,11 @@ The most notable example is `HEAD`. <> to describe the mapping between remote <> and local ref. +[[def_remote]]remote repository:: + A <> which is used to track the same + project but resides somewhere else. To communicate with remotes, + see <> or <>. + [[def_remote_tracking_branch]]remote-tracking branch:: A <> that is used to follow changes from another <>. It typically looks like @@ -515,6 +520,11 @@ The most notable example is `HEAD`. is created by giving the `--depth` option to linkgit:git-clone[1], and its history can be later deepened with linkgit:git-fetch[1]. +[[def_submodule]]submodule:: + A <> inside another repository. The two + repositories have different history, though the outer repository + knows the commit of the inner repository. + [[def_symref]]symref:: Symbolic reference: instead of containing the <> id itself, it is of the format 'ref: refs/some/thing' and when -- 2.4.1.345.gab207b6.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html