On Tue, Oct 10, 2017 at 6:03 AM, Heiko Voigt <hvo...@hvoigt.net> wrote:
>> > As mentioned in the cover letter. This seems to be the only test that >> > ensures that we stay compatible with setups without .gitmodules. Maybe >> > we should add/revive some? >> >> An interesting discussion covering this topic is found at >> https://public-inbox.org/git/20170606035650.oykbz2uc4xkr3...@sigill.intra.peff.net/ > > Thanks for that pointer. So in that discussion Junio said that the > recursive operations should succeed if we have everything necessary at > hand. I kind of agree because why should we limit usage when not > necessary. On the other hand we want git to be easy to use. And that > example from Peff is perfect as a demonstration of a incosistency we > currently have: > > git clone git://some.where.git/submodule.git > git add submodule > > is an operation I remember, I did, when first getting in contact with > submodules (many years back), since that is one intuitive way. And the > thing is: It works, kind of... Only later I discovered that one actually > needs to us a special submodule command to get everything approriately > setup to work together with others. I agree that we ought to not block off users "because we can", but rather perform the operation if possible with the data at hand. Note that the result of the discussion `jk/warn-add-gitlink actually` warns about adding a raw gitlink now, such that we hint at using "git submodule add", directly. So you propose to make git-add behave like "git submodule add" (i.e. also add the .gitmodules entry for name/path/URL), which I like from a submodule perspective. However other users of gitlinks might be confused[1], which is why I refrained from "making every gitlink into a submodule". Specifically the more powerful a submodule operation is (the more fluff adds), the harder it should be for people to mis-use it. [1] https://github.com/git-series/git-series/blob/master/INTERNALS.md "git-series uses gitlinks to store pointer to commits in its own repo." > If everyone agrees that submodules are the default way of handling > repositories insided repositories, IMO, 'git add' should also alter > .gitmodules by default. We could provide a switch to avoid doing that. I wonder if that switch should be default-on (i.e. not treat a gitlink as a submodule initially, behavior as-is, and then eventually we will die() on unconfigured repos, expecting the user to make the decision) > An intermediate solution would be to warn That is already implemented by Peff. > but in the long run my goal > for submodules is and always was: Make them behave as close to files as > possible. And why should a 'git add submodule' not magically do > everything it can to make submodules just work? I can look into a patch > for that if people agree here... I'd love to see this implemented. I cc'd Josh (the author of git-series), who may disagree with this, or has some good input how to go forward without breaking git-series. > Regarding handling of gitlinks with or without .gitmodules: > > Currently we are actually in some intermediate state: > > * If there is no .gitmodules file: No submodule processing on any > gitlinks (AFAIK) AFAIK this is true. > * If there is a .gitmodules files with some submodule configured: Do > recursive fetch and push as far as possible on gitlinks. * If submodule.recurse is set, then we also treat submodules like files for checkout, reset, read-tree. > So I am not sure whether there are actually many users (knowingly) > using a mix of some submodules configured and some not and then relying > on the submodule infrastructure. > > I would rather expect two sorts of users: > > 1. Those that do use .gitmodules Those want to reap all benefits of good submodules. > > 2. Those that do *not* use .gitmodules As said above, we don't know if those users are "holding submodules wrong" or are using gitlinks for magic tricks (unrelated to submodules). > > Users that do not use any .gitmodules file will currently (AFAIK) not > get any submodule handling. So the question is are there really many > "mixed users"? My guess would be no. I hope that there are few (if any) users of these mixed setups. > Because without those using this mixed we could switch to saying: "You > need to have a .gitmodules file for submodule handling" without much > fallout from breaking users use cases. That seems reasonable to me, actually. > Maybe we can test this out somehow? My patch series would be ready in > that case, just had to drop the first patch and adjust the commit > message of this one. I wonder how we would test this, though? Do you have any idea (even vague) how we'd accomplish such a measurement? I fear we'll have to go this way blindly. Cheers, Stefan > > Cheers Heiko
