From: Jonathan Nieder <jrnieder@gmail.com> To: Stefan Beller <sbeller@google.com> Cc: Brandon Williams <bmwill@google.com>, Jeff King <peff@peff.net>, git <git@vger.kernel.org> Subject: Re: [PATCH 2/2] submodule: munge paths to submodule git directories Date: Wed, 15 Aug 2018 19:34:46 -0700 Message-ID: <20180816023446.GA127655@aiede.svl.corp.google.com> (raw) In-Reply-To: <CAGZ79kYfoK9hfXM2-VMAZLPpqBOFQYKtyYuYJb8twzz6Oz5ymQ@mail.gmail.com> Hi again, Stefan Beller wrote: > On Tue, Aug 14, 2018 at 2:12 PM Jonathan Nieder <jrnieder@gmail.com> wrote: >> What if we forbid directory separator characters in the gitdirname? > > Fine with me, but ideally we'd want to allow sharding the > submodules. When you have 1000 submodules > we'd want them not all inside the toplevel "modules/" ? That's a good reason to permit slashes in the gitdirname. If I understood the rest of your reply correctly, your worry was about dangerous gitdirname values in .gitmodules. I never had any wish to read them from there anyway, so this worry hopefully goes away. [...] >> In this proposal, it would only be read from config, not from >> .gitmodules. > > Ah good point. That makes sense. > > Stepping back a bit regarding the config: [...] > Now that we have the submodule.active or even > submodule.<name>.active flags, we do not need (b) any more. > So the URL turns into a useless piece of cruft that just is unneeded > and might confuse the user. > > So maybe I'd want to propose a patch that removes > submodule.<name>.url from the config once it is cloned. > (I just read up on "submodule sync" again, but that might not > even need special care for this new world) > > And with all that said, I think if we can avoid having the submodules > gitdir in the config, the config would look much cleaner, too. Yes, I understand and agree with this. I should further spell out my motivation with this gitdirname suggestion. The issue that some people have mentioned in this thread is that urlencoding might not be perfect --- it's pretty close to perfect, but it's likely we'll come up with some unanticipated needs later (like sharding) that it doesn't solve. Solving those all right now would not necessarily be wise, since the thing about unanticipated needs is that you never know in advance what they will be. ;-) So it would be nice, for future-proofing, if we can change the naming scheme later. As a bonus, that would also make interoperability with other implementations easier. For example, suppose we mess up in JGit and urlencode a different set of characters than Git does. Then a mixed Git + JGit installation would have this subtle bug of the submodule .git directory not being reused when I switch to and from and branch not containing that submodule, in some circumstances. That sounds difficult to support. Whereas if we have a gitdirname configuration variable, then JGit and libgit2 and go-git do not have to match the naming scheme Git chooses. They can try, but if one gets it subtly wrong then that is okay because the submodule's directory name is right there and easy to look up. All at the cost of recording a little configuration somewhere. If we want to decrease the configuration, we can avoid recording it there in the easy cases (e.g. when name == gitdirname). That's "just" an optimization. And then we have the ability later to handle all the edge cases we haven't handled yet today: - sharding when the number of submodules is too large - case-insensitive filesystems - path name length limits - different sets of filesystem-special characters Sane? Thanks, Jonathan
next prev parent reply other threads:[~2018-08-16 2:34 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-07 23:06 [RFC] " Brandon Williams 2018-08-07 23:25 ` Jonathan Nieder 2018-08-08 0:14 ` Junio C Hamano 2018-08-08 22:33 ` [PATCH 0/2] munge submodule names Brandon Williams 2018-08-08 22:33 ` [PATCH 1/2] submodule: create helper to build paths to submodule gitdirs Brandon Williams 2018-08-08 23:21 ` Stefan Beller 2018-08-09 0:45 ` Brandon Williams 2018-08-10 21:27 ` Junio C Hamano 2018-08-10 21:45 ` Brandon Williams 2018-08-08 22:33 ` [PATCH 2/2] submodule: munge paths to submodule git directories Brandon Williams 2018-08-09 21:26 ` Jeff King 2018-08-14 18:04 ` Brandon Williams 2018-08-14 18:57 ` Jonathan Nieder 2018-08-14 21:08 ` Stefan Beller 2018-08-14 21:12 ` Jonathan Nieder 2018-08-14 22:34 ` Stefan Beller 2018-08-16 2:34 ` Jonathan Nieder [this message] 2018-08-16 2:39 ` Stefan Beller 2018-08-16 2:47 ` Jonathan Nieder 2018-08-16 17:34 ` Brandon Williams 2018-08-16 18:19 ` [PATCH] submodule: add config for where gitdirs are located Brandon Williams 2018-08-20 22:03 ` Junio C Hamano 2018-08-16 15:07 ` [PATCH 2/2] submodule: munge paths to submodule git directories Junio C Hamano 2018-08-14 18:58 ` Jeff King 2018-08-28 21:35 ` Stefan Beller 2018-08-29 5:25 ` Jeff King 2018-08-29 18:10 ` Stefan Beller 2018-08-29 21:03 ` Jeff King 2018-08-29 21:10 ` Stefan Beller 2018-08-29 21:18 ` Jonathan Nieder 2018-08-29 21:27 ` Stefan Beller 2018-08-29 21:30 ` Jeff King 2018-08-29 21:09 ` Jonathan Nieder 2018-08-29 21:14 ` Stefan Beller 2018-08-29 21:25 ` Brandon Williams 2018-08-29 21:32 ` Jeff King 2018-08-16 0:19 ` Aaron Schrab 2019-01-15 1:25 ` [RFC] " Jonathan Nieder 2019-01-17 17:32 ` Jeff King 2019-01-17 17:57 ` Stefan Beller
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=20180816023446.GA127655@aiede.svl.corp.google.com \ --to=jrnieder@gmail.com \ --cc=bmwill@google.com \ --cc=git@vger.kernel.org \ --cc=peff@peff.net \ --cc=sbeller@google.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
git@vger.kernel.org list mirror (unofficial, one of many) This inbox may be cloned and mirrored by anyone: 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 # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 git git/ https://public-inbox.org/git \ git@vger.kernel.org public-inbox-index git Example config snippet for mirrors. 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.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ code repositories for the project(s) associated with this inbox: https://80x24.org/mirrors/git.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git