[git-users] Re: multiple projects sharing submodules optimization?
Hi Yue, On Thursday, June 22, 2017 at 4:50:21 AM UTC+2, yueli...@gmail.com 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, yueli...@gmail.com 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, yueli...@gmail.com 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: multiple projects sharing submodules optimization?
Igor Djordjevic於 2017年6月22日星期四 UTC+8上午6時39分33秒寫道：
>
> On Wednesday, June 21, 2017 at 10:33:37 PM UTC+2, Igor Djordjevic wrote:
> Hmm, it may be worth noting that working with submodules like this, where
> each one points to _exactly the same repository_ (and not being a clone of
> it), could be pretty confusing, to say the least -- you basically end up
> with a single repository ("main" submodule repository) with multiple
> working trees (one inside each project using the submodule), but with
> originating Git repository _not being aware of it_, thus not able to assist
> with (multiple) working tree synchronization :/
>
> Not being careful enough, one can easily find himself in a pretty
> messy/awkward situation...
>
> From this perspective, the "worktree" approach seems safer, as multiple
> working trees are transparent/known to the originating Git repository,
> being aware of the mechanism (and all the working trees). I`m just not sure
> if it has drawbacks of its own...? (besides the main submodule repository
> needing to know/keep branches/worktrees for each project using the
> submodule)
>
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.
For example:
projects/project1/.git/modules/library_XYZ/*worktrees*/library_XYZ/*HEAD*
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
ASFAIK, you still can use "submodule update" for daily work. suppose
no drawbacks. :)
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.)
Yue Lin Ho
--
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[git-users] Re: multiple projects sharing submodules optimization?
On Wednesday, June 21, 2017 at 10:33:37 PM UTC+2, Igor Djordjevic wrote:
>
> Hi Yue,
>
> On Wednesday, June 21, 2017 at 3:18:09 AM UTC+2, yueli...@gmail.com wrote:
>>
>> After some tests, I got a better way to do that: Just use git worktree
>> feature.
>>
>> Here is an example:
>>
>> Suppose you have 2 (or more) projects, and they use a library_XYZ
>> submodule:
>> /home/projects/project1/library_XYZ
>> /home/projects/project2/library_XYZ
>>
>> Then, you just need to do these:
>>
>> 1. Delete /home/projects/project2/library_XYZ
>> because the coming worktree command needs no folder there
>> 2. Delete /home/projects/project2/.git/modules/library_XYZ
>> no need it anymore, just save your hard disk space. :P
>>
>> 3. cd /home/projects/project1/library_XYZ
>>
>> 4. Create a branch "project2" in /home/projects/project1/library_XYZ
>> if you don't have a branch for the coming worktree
>>
>> 5. run "git worktree add ../../project2/library_XYZ project2"
>> this is the magic commend. :D
>>
>
> I`m not sure if "git-worktree" is the right tool for the job here... While
> the proposed steps do seem to work from the perspective of "project2" so
> far, "project1/library_XYZ" submodule is effectively "polluted" with an
> extra branch ("project2") and an additional (linked) working tree attached
> to it.
>
> This feels hacky to say the least - I`m not sure if there are any
> unexpected drawbacks from usability perspective, but it`s certainly does
> not seem necessary to accomplish the desired goal.
>
> 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.
>
> For the given example of two projects using the same submodule:
>
> (*1*) /home/projects/project1/.git << project
> repository
> /home/projects/project1/.git/modules/library_XYZ << submodule
> repository
> /home/projects/project1/library_XYZ/*.git* << submodule *file*
> /home/projects/project2/.git << project repository
> /home/projects/project2/.git/modules/library_XYZ << submodule
> repository
> /home/projects/project2/library_XYZ/*.git* << submodule *file*
>
> ... we can edit "/home/projects/project2/library_XYZ/.git" file to point
> to "library_XYZ" submodule repo inside "project1", by changing this:
>
> (*2*) gitdir: ../.git/modules/library_XYZ
>
> ... to this:
>
> (*3*) gitdir: ../../project1/.git/modules/library_XYZ
>
> ... and deleting "/home/projects/project2/.git/modules/library_XYZ"
> submodule repository as it`s not used anymore (as explained above), getting
> to this (note we have submodule repository only once now):
>
> (*4*) /home/projects/project1/.git << project
> repository
> /home/projects/project1/.git/modules/library_XYZ << submodule
> repository
> /home/projects/project1/library_XYZ/*.git* << submodule *file*
> /home/projects/project2/.git << project repository
> /home/projects/project2/library_XYZ/*.git* << submodule *file*
>
>
> Even better, if possible/preferred, we could make the situation look like
> this:
>
> (*5*) /home/projects/library_XYZ/.git << project repository
> /home/projects/project1/.git << project repository
> /home/projects/project1/library_XYZ/*.git* << submodule *file*
> /home/projects/project2/.git << project repository
> /home/projects/project2/library_XYZ/*.git* << submodule *file*
>
> ... where we can than have a "clean and obvious" repository for
> "library_XYZ" outside of any other project, and just reroute all submodule
> files inside other projects to it.
>
> For the given example of "/home/projects/project1/library_XYZ/.git" and
> "/home/projects/project2/library_XYZ/.git" files, edit them to:
>
> (*6*) gitdir: ../../library_XYZ/.git
>
>
> *p.s.* If "/home/projects/project*X*/library_XYZ/.git" is a Git
> _repository_ and not a file (and "/home/projects/project*X*/.git/modules/
> library_XYZ" repository probably does not exist), you can run:
>
> (*7*) $ git submodule absorbgitdirs
>
> ... inside every "project*X*" repository, so submodule "library_XYZ"
> repository is moved from "/home/projects/project*X*/library_XYZ/.git" to "
> /home/projects/project*X*/.git/modules/library_XYZ", and "
> /home/projects/project*X*/library_XYZ/.git" becomes a file you can
> edit/reroute, deleting "/home/projects/project*X*/.git/modules/library_XYZ"
> afterwards, as explained above.
>
Hmm, it may be worth noting that working with submodules like this, where
each one points to _exactly the same repository_ (and not being a clone of
it), could be pretty confusing,
[git-users] Re: multiple projects sharing submodules optimization?
Hi Yue,
On Wednesday, June 21, 2017 at 3:18:09 AM UTC+2, yueli...@gmail.com wrote:
>
> After some tests, I got a better way to do that: Just use git worktree
> feature.
>
> Here is an example:
>
> Suppose you have 2 (or more) projects, and they use a library_XYZ
> submodule:
> /home/projects/project1/library_XYZ
> /home/projects/project2/library_XYZ
>
> Then, you just need to do these:
>
> 1. Delete /home/projects/project2/library_XYZ
> because the coming worktree command needs no folder there
> 2. Delete /home/projects/project2/.git/modules/library_XYZ
> no need it anymore, just save your hard disk space. :P
>
> 3. cd /home/projects/project1/library_XYZ
>
> 4. Create a branch "project2" in /home/projects/project1/library_XYZ
> if you don't have a branch for the coming worktree
>
> 5. run "git worktree add ../../project2/library_XYZ project2"
> this is the magic commend. :D
>
I`m not sure if "git-worktree" is the right tool for the job here... While
the proposed steps do seem to work from the perspective of "project2" so
far, "project1/library_XYZ" submodule is effectively "polluted" with an
extra branch ("project2") and an additional (linked) working tree attached
to it.
This feels hacky to say the least - I`m not sure if there are any
unexpected drawbacks from usability perspective, but it`s certainly does
not seem necessary to accomplish the desired goal.
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.
For the given example of two projects using the same submodule:
(*1*) /home/projects/project1/.git << project repository
/home/projects/project1/.git/modules/library_XYZ << submodule repository
/home/projects/project1/library_XYZ/*.git* << submodule *file*
/home/projects/project2/.git << project repository
/home/projects/project2/.git/modules/library_XYZ << submodule repository
/home/projects/project2/library_XYZ/*.git* << submodule *file*
... we can edit "/home/projects/project2/library_XYZ/.git" file to point to
"library_XYZ" submodule repo inside "project1", by changing this:
(*2*) gitdir: ../.git/modules/library_XYZ
... to this:
(*3*) gitdir: ../../project1/.git/modules/library_XYZ
... and deleting "/home/projects/project2/.git/modules/library_XYZ"
submodule repository as it`s not used anymore (as explained above), getting
to this (note we have submodule repository only once now):
(*4*) /home/projects/project1/.git << project repository
/home/projects/project1/.git/modules/library_XYZ << submodule repository
/home/projects/project1/library_XYZ/*.git* << submodule *file*
/home/projects/project2/.git << project repository
/home/projects/project2/library_XYZ/*.git* << submodule *file*
Even better, if possible/preferred, we could make the situation look like
this:
(*5*) /home/projects/library_XYZ/.git << project repository
/home/projects/project1/.git << project repository
/home/projects/project1/library_XYZ/*.git* << submodule *file*
/home/projects/project2/.git << project repository
/home/projects/project2/library_XYZ/*.git* << submodule *file*
... where we can than have a "clean and obvious" repository for
"library_XYZ" outside of any other project, and just reroute all submodule
files inside other projects to it.
For the given example of "/home/projects/project1/library_XYZ/.git" and
"/home/projects/project2/library_XYZ/.git" files, edit them to:
(*6*) gitdir: ../../library_XYZ/.git
*p.s.* If "/home/projects/project*X*/library_XYZ/.git" is a Git
_repository_ and not a file (and "/home/projects/project*X*/.git/modules/
library_XYZ" repository probably does not exist), you can run:
(*7*) $ git submodule absorbgitdirs
... inside every "project*X*" repository, so submodule "library_XYZ"
repository is moved from "/home/projects/project*X*/library_XYZ/.git" to "
/home/projects/project*X*/.git/modules/library_XYZ", and "
/home/projects/project*X*/library_XYZ/.git" becomes a file you can
edit/reroute, deleting "/home/projects/project*X*/.git/modules/library_XYZ"
afterwards, as explained above.
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[git-users] Re: multiple projects sharing submodules optimization?
After some tests, I got a better way to do that: Just use git worktree feature. Here is an example: Suppose you have 2 (or more) projects, and they use a library_XYZ submodule: /home/projects/project1/library_XYZ /home/projects/project2/library_XYZ Then, you just need to do these: 1. Delete /home/projects/project2/library_XYZ because the coming worktree command needs no folder there 2. Delete /home/projects/project2/.git/modules/library_XYZ no need it anymore, just save your hard disk space. :P 3. cd /home/projects/project1/library_XYZ 4. Create a branch "project2" in /home/projects/project1/library_XYZ if you don't have a branch for the coming worktree 5. run "git worktree add ../../project2/library_XYZ project2" this is the magic commend. :D Yue Lin Ho -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: multiple projects sharing submodules optimization?
yueli...@gmail.com於 2017年6月17日星期六 UTC+8下午5時20分31秒寫道： > > rough steps: > > 0. suppose there are A and B branch in TheSubmodule repo, A is used by > ProjectA, and B is used by ProjectB > 1. move Projects/ProjectA/.git/modules/TheSubmodule to a common folder, > say Projects/Common/TheSubmodule. > 2. delete the key worktree of Projects/Common/TheSubmodule/config file > this step may be wrong. maybe modify the key worktree value to the correct one. > 3. modify Projects/ProjectA/TheSubmodule/.git file, make the gitdir points > to the new path inner that common folder. > 4. rename Projects/ProjectB/TheSubmodule to > Projects/ProjectB/TheOldSubmodule > 5. run command `git worktree add ../../ProjectB/TheSubmodule B` in > Projects/ProjectA/TheSubmodule > 6. delete Projects/ProjectB/TheOldSubmodule and > Projects/ProjectB/.git/modules/TheSubmodule > > Yue Lin Ho > -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: multiple projects sharing submodules optimization?
Stefan Klein於 2017年6月15日星期四 UTC+8上午12時28分16秒寫道： > > Hi, > > i do have multiple projects which share the same submodules. > Each project might point to a different commit of a given submodule, but > the submodules are exactly the same. > No problem with this so far. > It just bothers me that each submodule occupies disk space, that i have to > fetch each submodule multiple times although the local repository for each > submodule should be exactly the same. > Is there an easy way, which doesn't interfere with my colleges, to have > the submodule of each project use the same local repository? (and still > have their own individual working directory) > Closest I found so far in documentation are worktrees but i found no clue > on how they might work with modules. > > regards, > Stefan > rough steps: 0. suppose there are A and B branch in TheSubmodule repo, A is used by ProjectA, and B is used by ProjectB 1. move Projects/ProjectA/.git/modules/TheSubmodule to a common folder, say Projects/Common/TheSubmodule. 2. delete the key worktree of Projects/Common/TheSubmodule/config file 3. modify Projects/ProjectA/TheSubmodule/.git file, make the gitdir points to the new path inner that common folder. 4. rename Projects/ProjectB/TheSubmodule to Projects/ProjectB/TheOldSubmodule 5. run command `git worktree add ../../ProjectB/TheSubmodule B` in Projects/ProjectA/TheSubmodule 6. delete Projects/ProjectB/TheOldSubmodule and Projects/ProjectB/.git/modules/TheSubmodule Yue Lin Ho -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
