Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

["Jakub Narębski" <jnareb@gmail.com>]

W dniu 2016-07-26 o 20:15, Stefan Beller pisze:
> On Tue, Jul 26, 2016 at 10:20 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Tue, Jul 26, 2016 at 1:25 AM, Stefan Beller <sbeller@google.com> wrote:
>>> So what is the design philosophy in worktrees? How much independence does
>>> one working tree have?
>>
>> git-worktree started out as an alternative for git-stash: hmm.. i need
>> to make some changes in another branch, okay let's leave this worktree
>> (with all its messy stuff) as-is, create another worktree, make those
>> changes, then delete the worktree and go back here. There's already
>> another way of doing that without git-stash: you clone the repo, fix
>> your stuff, push back and delete the new repo.
>>
>> I know I have not really answered your questions. But I think it gives
>> an idea what are the typical use cases for multiple worktrees. How
>> much independence would need to be decided case-by-case, I think.
> 
> Thanks!

Hopefully the Git User's Survey 2016 would answer what people really
use worktrees for, and what use submodules for.  You are welcome to
submit proposed questions for the survey:
  http://thread.gmane.org/gmane.comp.version-control.git/299032

> My sudden interest in worktrees came up when I learned the
> `--reference` flag for submodule operations is broken for
> our use case, and instead of fixing the `--reference` flag,
> I think the worktree approach is generally saner (i.e. with the
> references you may have nasty gc issues IIUC, but in the
> worktree world gc knows about all the working trees, detached
> heads and branches.)

I think the problem with `--reference` is that it does not
setup backreferences to prevent gc removing borrowed objects;
which is a hard problem to solve, except for limited cases...
like git-worktree.
 
> So I think the current workflow for submodules
> may need some redesign anyway as the submodule
> commands were designed with a strict "one working
> tree only" assumption.
> 
> Submodule URLs  are stored in 3 places:
>  A) In the .gitmodules file of the superproject
>  B) In the option submodule.<name>.URL in the superproject
>  C) In the remote.origin.URL in the submodule
> 
> A) is a recommendation from the superproject to make life
> of downstream easier to find and setup the whole thing.
> You can ignore that if you want, though generally a caring
> upstream provides good URLs here.

Also, this URL might have change if the repository moves
to other server; even when checking out ancient version
we usually want to use current URL, not the one in currently
checked-out .gitmodules file.
 
> C) is where we actually fetch from (and hope it has all
> the sha1s that are recorded as gitlinks in the superproject)

Is it? Or is it only the case if you do `git fetch` or
equivalent from within inside of submodule? You can fetch
updates using `git submodule ...` from supermodule, isn't it?
But I might be wrong here.

Also: if .git file is gitfile link, do submodule even has
it's own configuration file?

> 
> B) seems like a hack to enable the workflow as below:

It has overloaded meaning, being used both for current URL
of submodule as seen in supermodule, AND that submodule
is checked out / needs to be checked out in the worktree
of a supermodule.  There might be the case when you check
out (in given worktree) a version of a supermodule that
do not include submodule at all, but you want to know that
when going back, this submodule is to be checked out (or not).

The second information needs to be per-worktree. How to
solve it, be it per-worktree configuration (not shared),
or a special configuration variable, or worktree having
unshared copy of configuration -- this what is discussed.

> Current workflow for handling submodule URLs:
>  1) Clone the superproject
>  2) Run git submodule init on desired submodules

Or 1-2) clone the superproject recursively, with all its
submodules.

>  3) Inspect .git/config to see if any submodule URL needs adaption

Which is usually not needed.

>  4) Run git submodule update to obtain the submodules from
>     the configured place

Or 2+4) run `git submodule update --init`

>  5) In case of superproject adapting the URL
>     -> git submodule sync, which overwrites the submodule.<name>.URL in the
>     superprojects .git/config as well as configuring the
>     remote."$remote".url in the submodule

This takes information from current .gitmodules, isn't it?

>  6) In case of users desire to change the URL
>     -> No one command to solve it; possible workaround: edit
>     .gitmodules and git submodule sync, or configure  the submodule.<name>.URL
>     in the superprojects .git/config as well as configuring the remote."$remote".url in
>     the submodule separately. Although just changing the submodules remote works
>     just as well (until you remove and re-clone the submodule)
[...]


> "Moving back" sounds like you use the worktree feature for short lived
> things only. (e.g. in the man page you refer to the hot fix your boss wants
> you to make urgently).
> 
> I thought the worktree feature is more useful for long term "branches",
> e.g. I have one worktree of git now that tracks origin/master so I can
> use that to "make install" to repair my local broken version of git.
> 
> (I could have a worktree "continuous integration", where I only run tests
> in. I could have one worktree for Documentation changes only.)
> 
> This long lived stuff probably doesn't make sense for the a single
> repository, but in combination with submodules (which is another way
> to approach the "sparse/narrow" desire of a large project), I think
> that makes sense, because the "continuous integration" shares a lot
> of submodules with my "regular everyday hacking" or the "I need to
> test my colleague work now" worktree.

One thing that git-worktree would be very useful, if it could work
with submodules: you could use separate worktrees to easily test
if the supermodule works with and without its submodules present.
 
[...]
> If you switch a branch (or to any sha1), the submodule currently stays
> "as-is" and may be updated using "submodule update", which goes through
> the list of existing (checked out) submodules and checks them out to the
> sha1 pointed to by the superprojects gitlink.

Which might be simply a problem that submodule UI is not mature enough.
I would like to see automatic switch of submodule contents, if 
configured so.

-- 
Jakub Narębski