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, 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)
--
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.
