Hi Yue, On Thursday, June 22, 2017 at 4:50:21 AM UTC+2, [email protected] wrote: > > The "git worktree add" will give the .git file of submodule the right path > automatically, so you don't touch that file. > And it creates extra folder "worktree" which store some necessary data for > using different working tree. >
Yes, I already addressed this in my previous e-mail (note the last sentence in the quote below), where I perceived the "extra" worktree related stuff unnecessary, and just "polluting" the submodule repository. On Wednesday, June 21, 2017 at 10:33:37 PM UTC+2, Igor Djordjevic wrote: > > What looks like an easier (and less intrusive) solution may be to just > edit the ".git" _file_ of each submodule we want to reroute (and then > delete corresponding submodule repository inside ".git/modules/", as > already mentioned) -- this is basically what step 5 described above does to > ".git" file, but here without other (unneeded and might be unwanted) > "worktree" related stuff. > On Thursday, June 22, 2017 at 4:50:21 AM UTC+2, [email protected] wrote: > Only modify the .git file of submodule, well, two working tree will use > the same index file, the same branch, the same HEAD file, ... mum... as > you said, something wrong. :P > (suppose that's way git introduce the worktree feature since git 2.5.) > Yeah, after playing with it for a while, I tend to agree with this now. Even further, I`d say the "worktree" approach might be actually a natural solution for the "problem" in question, as that is basically what the idea was - to have a single submodule repository with multiple working trees (one per project that`s using it), and as the repository really should be aware of all these working trees so they don`t get out of sync, "worktree" pops out on its own. On Thursday, June 22, 2017 at 4:50:21 AM UTC+2, [email protected] wrote: > > For example: > projects/project1/.git/modules/library_XYZ/*worktrees*/library_XYZ/ > *HEAD* > I was actually surprised to see that: projects/project1/.git/modules/library_XYZ/worktrees/library_XYZ/HEAD ... inside the ".git" file was correctly recognized as a submodule, with that additional stuff appended at the end (not that I`m a git expert, but still ;), in comparison to what would a "submodule" approach contain there (just the first part, omitting marked suffix). > Another HEAD file for project2/library_XY! > > Those worktree data allow project2/library_XYZ to use its own checkout > commit and different working tree from project1/library_XYZ. Cool! :D > And this is a huge thing, even though I still don`t really like the feeling of submodule repository being kind of aware of other projects using it (through dedicated per project branches and working trees), it does feel as a sane and natural approach... I guess :) ASFAIK, you still can use "submodule update" for daily work. suppose > no drawbacks. :) > Basically, I`m only concerned with submodule ".git" file looking a bit differently than in a "clean" submodule approach, and if that additional "/worktrees/.../HEAD" stuff at the end could cause any issues in every day work from within the project repository, using the submodule. But anyway, thanks for a chance to learn something new :) Regards, Buga -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
