git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Antonio Ospite <ao2@ao2.it>
To: Stefan Beller <sbeller@google.com>
Cc: git <git@vger.kernel.org>,
	Richard Hartmann <richih.mailinglist@gmail.com>
Subject: Re: [RFC 01/10] submodule: add 'core.submodulesFile' to override the '.gitmodules' path
Date: Wed, 18 Apr 2018 13:43:57 +0200
Message-ID: <20180418134357.1e417fb22201b6a6b67c02c0@ao2.it> (raw)
In-Reply-To: <CAGZ79kajTdkPKpcjH3NXBE75qWnNCCq_OefAjQsw17hK_VEyCw@mail.gmail.com>

On Mon, 16 Apr 2018 14:22:35 -0700
Stefan Beller <sbeller@google.com> wrote:

> On Mon, Apr 16, 2018 at 9:37 AM, Antonio Ospite <ao2@ao2.it> wrote:
> > On Thu, 12 Apr 2018 16:50:03 -0700
> > Stefan Beller <sbeller@google.com> wrote:
> >
> >> Hi Antonio,
> >>
> >> On Thu, Apr 12, 2018 at 3:20 PM, Antonio Ospite <ao2@ao2.it> wrote:
> >> > When multiple repositories with detached work-trees take turns using the
> >> > same directory as their work-tree, and more than one of them want to use
> >> > submodules, there will be conflicts about the '.gitmodules' file.
> >>
> >> unlike other files which would not conflict?
> >> There might be file names such as LICENSE, Readme.md etc,
> >> which are common enough that they would produce conflicts as well?
> >> I find this argument on its own rather weak. ("Just delete everything in
> >> the working dir before using it with another repository"). I might be
> >> missing a crucial bit here?
> >>
> >
> > All the vcsh repositories _share_ the same work-tree; they may control
> > it taking turns but, in general, all files are meant to be checked out
> > at all times as the basic use case is: *distinct* sets of config files.
> >
> > Maybe saying that the repositories "take turns" is confusing.
> > It's an unnecessary information, so I will omit that part form the
> > commit message.
> 
> So they all have the same workdir, do they track the same set of files
> or do they track a disjoint set of files, and ignoring the other repositories
> files via the ignore mechanism?
>

To recap,

vcsh[1] sets $HOME as the work-tree of multiple repositories to track
different sets of dotfiles in distinct repositories, while still having
the files directly available in $HOME. Each repository can ignore
untracked files via the ignore mechanism (namely core.excludesFile).

[1] https://github.com/RichiH/vcsh

For all this to work well, the sets of the tracked files would also need
to be disjoint, and usually they "practically" are, once a few
exceptions are taken care of.

Common intersecting items like LICENSE and README can be handled via
sparse-checkout to have "disjoint checkouts" and this solves most of
the problems, but the same mechanism cannot be used for .gitmodules as
it needs to be checked out.

And the problem cannot be worked around like done with .gitignore
(using core.excludesFile instead) because .gitmodules is unique and
hardcoded.

> This sounds like an interesting setup. I never though of that as something
> useful (in either configuration).
>

Give vcsh a try maybe.

[...]
> > However I guess that my point here is that the gitmodules file is
> > something that influences git behavior so it should not be on the user's
> > shoulder to manage conflicts for it, and most importantly it needs to
> > be checked out for git to access it, doesn't it?
> 
> Good point! I wonder if the cleaner solution would be to just
> tell git to use HEAD:.gitmodules and not check out the file?
> then you would not need to come up with a namespace for names
> of the .gitmodules files and scatter them into the worktree as well?
>

Any solution which:

  1. prevents the gitmodules file to be checked out
  2. but still tracks it in the git repository

OR
  
  1. allows to set the gitmoudles file under some namespace

would work for vcsh I guess.

> 
> >> > -               value=$(git config -f .gitmodules submodule."$name"."$option")
> >> > +               gitmodules_file=$(git config core.submodulesfile)
> >> > +               : ${gitmodules_file:=.gitmodules}
> >> > +               value=$(git config -f "$gitmodules_file" submodule."$name"."$option")
> >>
> >> I wonder if it would be cheaper to write a special config lookup now, e.g.
> >> in builtin/submodule--helper.c we could have a "config-from-gitmodules"
> >> subcommand that is looking up the modules file and then running the config
> >> on that file.
> >>
> >
> > Can you give an example from the user point of view of such a
> > "config-from-gitmodules" command?
> >
> 
>     git submodule config <name> <option>
> 
> as an 'alias' for
> 
>                gitmodules_file=$(git config core.submodulesfile)
>                : ${gitmodules_file:=.gitmodules}
>                value=$(git config -f "$gitmodules_file"
> submodule."$name"."$option")
> 
> The helper would figure out which config file to load form
> (.gitmodules in tree, HEAD:.gitmodules, your new proposed gitmodules file,
> .git/config... or the special ref) and then return the <option> for <name>
> 
> So maybe:
> 
>     $ git clone https://gerrit.googlesource.com/gerrit && cd gerrit
>     # ^ My goto-repo with submodules
> 
>     $ git submodule config "plugins/hooks" URL
>     ../plugins/hooks
> 
>

I may look into such supporting changes once you decide the approach to
take for the bigger problem.

Thank you,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 22:20 [RFC 00/10] Make .the gitmodules file path configurable Antonio Ospite
2018-04-12 22:20 ` [RFC 01/10] submodule: add 'core.submodulesFile' to override the '.gitmodules' path Antonio Ospite
2018-04-12 23:50   ` Stefan Beller
2018-04-16 16:37     ` Antonio Ospite
2018-04-16 21:22       ` Stefan Beller
2018-04-18 11:43         ` Antonio Ospite [this message]
2018-04-18 18:44           ` Stefan Beller
2018-04-12 22:20 ` [RFC 02/10] submodule: fix getting custom gitmodule file in fetch command Antonio Ospite
2018-04-12 23:55   ` Stefan Beller
2018-04-16 16:18     ` Antonio Ospite
2018-04-16 19:23       ` Stefan Beller
2018-04-16 20:46         ` Antonio Ospite
2018-04-12 22:20 ` [RFC 04/10] submodule: document 'core.submodulesFile' and fix references to '.gitmodules' Antonio Ospite
2018-04-12 22:20 ` [RFC 05/10] submodule: adjust references to '.gitmodules' in comments Antonio Ospite
2018-04-12 22:20 ` [RFC 06/10] completion: add 'core.submodulesfile' to the git-completion.bash file Antonio Ospite
2018-04-12 23:36 ` [RFC 00/10] Make .the gitmodules file path configurable Stefan Beller
2018-04-16 11:33   ` Antonio Ospite
2018-04-16 19:22     ` Stefan Beller
2018-04-13  8:07 ` Antonio Ospite
2018-04-13  8:07 ` [RFC 07/10] FIXME: wrap-for-bin.sh: set 'core.submodulesFile' for each git invocation Antonio Ospite
2018-04-13  8:07   ` [RFC 08/10] FIXME: submodule: fix t1300-repo-config.sh to take into account the new config Antonio Ospite
2018-04-13  8:07   ` [RFC 09/10] FIXME: submodule: pass custom gitmodules file to 'test-tool submodule-config' Antonio Ospite
2018-04-13  8:07   ` [RFC 10/10] FIXME: add a hacky script to test the changes with a patched test suite Antonio Ospite
2018-04-13 20:05   ` [RFC 07/10] FIXME: wrap-for-bin.sh: set 'core.submodulesFile' for each git invocation Stefan Beller
2018-04-16 11:36     ` Antonio Ospite

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=20180418134357.1e417fb22201b6a6b67c02c0@ao2.it \
    --to=ao2@ao2.it \
    --cc=git@vger.kernel.org \
    --cc=richih.mailinglist@gmail.com \
    --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 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