W dniu 2016-07-26 o 20:15, Stefan Beller pisze:

On Tue, Jul 26, 2016 at 10:20 AM, Duy Nguyen [off-list ref] wrote:

quoted

On Tue, Jul 26, 2016 at 1:25 AM, Stefan Beller [off-list ref] wrote:

quoted

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