From: Stefan Beller <firstname.lastname@example.org> To: Junio C Hamano <email@example.com>, git <firstname.lastname@example.org>, Andreas Urke <email@example.com> Subject: Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name? Date: Thu, 21 Dec 2017 14:57:40 -0800 Message-ID: <CAGZ79kYRYHdpyXD+VtO-Xhg_BqTkrj4qgbgEFK7opQGXGhNiAw@mail.gmail.com> (raw) In-Reply-To: <CAPc5daUJXS9DJr7BRuKbNotKA-3kBnzHfn3566su+ZDwafirstname.lastname@example.org> On Thu, Dec 21, 2017 at 2:08 PM, Junio C Hamano <email@example.com> wrote: > That sounds like a bit of revisionist history, but you weren't around > back then, so... > > https://firstname.lastname@example.org/#r > > is my summarization of discussions before that time. There is a > mention of "three-level" > thing by Steven Grimm in > https://public-inbox.org/git/464E4C94.email@example.com/ > in the thread, and together with messages like > https://firstname.lastname@example.org/ > you can see that we already knew that submodule identity (name), path > in the superproject (path) and where it > comes from (url) need to be separate things that need to be tied > together by .gitmodules. Taking this private reply back to the list, I hope you don't mind. I think linking into the archives (hence making the huge unstructured archive a bit more discoverable by these links) is a good idea. Yes, I was not around when these discussions happened, hence I came up with a narrative that I can rationalize best. This message https://public-inbox.org/git/464CF435.email@example.com/ helps (me) most as that states the problem that need to be solved and I agree with the issues and how to solve it. The "symbolic names", however, are the crux there. They must not be changed, so as Andreas says, maybe "ID" is a better notion than "submodule name". I am of the opinion that we'd even want to go as far as to not expose this symbolic to the user. So if we redesign from scratch, I would not have "gitlink entries" but rather "special blobs", that contain the submodule sha1, as well as their ID. A special blob could look like: git cat-file "kernel/" version <sha1> id <another hash value, determined at creation time> Additionally you'd have slight guidance of id -> URL in an extra ref, versioned independently of the main history: <other hash> -> git://kernel.org/... (A) So if linux moves away from kernel.org, you can change that ref independently of your history at that time, such that even old versions of your main history can obtain the kernel from the correct URL. Of course a porcelain command could do the double lookup such that the user can say "kernel/ -> newURL" without needing to have knowledge of the internal ID. (B) Now if you want to move the submodule locally, you can do so by having that special blob at a different path in your tree. git-mv "just works" even for nested submodules. No need to rewrite the .gitmodules file. (C) What if you want to drop linux and use some BSD? Then you change the ID such that a new submodule repo is created inside .git/modules/. Of course it is also pinned to a different sha1. A porcelain command such as "git submodule replace" would sound like a good porcelain-ish. I think this so far is a clean design, but it is incompatible with history. The really big difference is that the ID is the core thing that everything revolves around (similar to the submodule name), but is tied to the path and is hidden as much as possible from the user, who can use given commands for each of the scenarios. The big flaw of this that the ID is sort of random and not based on content, which is counter to Gits philosophy as a content addressable FS. Maybe the ID can be set to HASH(<first version> +<path>), such that when two people independently of each other make a submodule pointing at the same commit at the same path, they'd have the same tree-id. Thanks, Stefan  An in office discussion hinted at that "special blobs" are not that special. git-LFS uses this mechanism, but of course their design flaw is to keep it out of main-Git. But one could posit "submodules can be implemented using smudge filters alone".
prev parent reply index Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-18 23:18 Andreas Urke 2017-12-19 18:02 ` [PATCH] " Stefan Beller 2017-12-19 22:19 ` Junio C Hamano 2017-12-19 22:33 ` Stefan Beller 2017-12-20 8:22 ` Andreas Urke 2017-12-20 17:54 ` Stefan Beller 2017-12-21 16:21 ` Andreas Urke 2017-12-21 18:55 ` Stefan Beller 2017-12-21 22:17 ` Andreas Urke 2017-12-21 23:08 ` Stefan Beller [not found] ` <CAPc5daUJXS9DJr7BRuKbNotKA-3kBnzHfn3566su+ZDwafirstname.lastname@example.org> 2017-12-21 22:57 ` Stefan Beller [this message]
Reply instructions: You may reply publically 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=CAGZ79kYRYHdpyXD+VtO-Xhg_BqTkrj4qgbgEFK7opQGXGhNiAw@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox