On Tue, Jul 26, 2016 at 1:25 AM, Stefan Beller <sbeller@xxxxxxxxxx> 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. > So here is what I did: > * s/git submodule init/git submodule update --init/ > * added a test_pause to the last test on the last line > * Then: > > $ find . |grep da5e6058 > ./addtest/.git/modules/submod/objects/08/da5e6058267d6be703ae058d173ce38ed53066 > ./addtest/.git/worktrees/super-elsewhere/modules/submod/objects/08/da5e6058267d6be703ae058d173ce38ed53066 > ./addtest/.git/worktrees/super-elsewhere/modules/submod2/objects/08/da5e6058267d6be703ae058d173ce38ed53066 > ./.git/objects/08/da5e6058267d6be703ae058d173ce38ed53066 > > The last entry is the "upstream" for the addtest clone, so that is fine. > However inside the ./addtest/ (and its worktrees, which currently are > embedded in there?) we only want to have one object store for a given > submodule? How to store stuff in .git is the implementation details that the user does not care about. As long as we keep the behavior the same (they can still "git submodule init" and stuff in the new worktree), sharing the same object store makes sense (pros: lower disk consumption, cons: none). > After playing with this series a bit more, I actually like the UI as it is an > easy mental model "submodules behave completely independent". > > However in 3/4 you said: > > + - `submodule.*` in current state should not be shared because the > + information is tied to a particular version of .gitmodules in a > + working directory. > > This is already a problem with say different branches/versions. > That has been solved by duplicating that information to .git/config > as a required step. (I don't like that approach, as it is super confusing > IMHO) Hmm.. I didn't realize this. But then I have never given much thought about submodules, probably because I have an alternative solution for it (or some of its use cases) anyway :) OK so it's already a problem. But if we keep sharing submodule stuff in .git/config, there's a _new_ problem: when you "submodule init" a worktree, .git/config is now tailored for the current worktree, when you move back to the previous worktree, you need to "submodule init" again. So moving to multiple worktrees setup changes how the user uses submodule, not good in my opinion. If you have a grand plan to make submodule work at switching branches (without reinit) and if it happens to work the same way when we have multiple worktrees, great. > I am back to the drawing board for the submodule side of things, > but I guess this series could be used once we figure out how to > have just one object database for a submodule. I would leave this out for now. Let's make submodule work with multiple worktrees first (and see how the users react to this). Then we can try to share object database. Object database and refs are tied closely together so you may run into other problems soon. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html