Delete gitlink entry but keep .gitmodules file unmodified

Delete gitlink entry but keep .gitmodules file unmodified

[Semen Vadishev]

Suppose one has a properly initialized submodule in a tree like this:

$ git ls-tree HEAD
100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1	.gitmodules
160000 commit ec633ea81e3cf64c3735ef4acd5ff9a490ed54eb	ext
100644 blob 597d6924118c00054efd526d9e48f68198f7da12	file.txt

$ git show HEAD:.gitmodules
[submodule "ext"]
         path = ext
         url = $URL

Then one pulls a modification that replaces 'ext' gitlink by some blob 
or tree entry, but keeps '.gitmodules' the same:

$ git ls-tree HEAD
100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1	.gitmodules
040000 tree 82e3a754b6a0fcb238b03c0e47d05219fbf9cf89	ext
100644 blob 597d6924118c00054efd526d9e48f68198f7da12	file.txt

Are there any possible downsides of such modification we should be aware of?

Thanks,

-- 
Semen Vadishev,
TMate Software,
http://subgit.com/ - git+svn on the server side!

Re: Delete gitlink entry but keep .gitmodules file unmodified

[Jens Lehmann]

Am 18.04.2012 15:19, schrieb Semen Vadishev:
> Suppose one has a properly initialized submodule in a tree like this:
> 
> $ git ls-tree HEAD
> 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1    .gitmodules
> 160000 commit ec633ea81e3cf64c3735ef4acd5ff9a490ed54eb    ext
> 100644 blob 597d6924118c00054efd526d9e48f68198f7da12    file.txt
> 
> $ git show HEAD:.gitmodules
> [submodule "ext"]
>         path = ext
>         url = $URL
> 
> Then one pulls a modification that replaces 'ext' gitlink by some blob or tree entry, but keeps '.gitmodules' the same:
> 
> $ git ls-tree HEAD
> 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1    .gitmodules
> 040000 tree 82e3a754b6a0fcb238b03c0e47d05219fbf9cf89    ext
> 100644 blob 597d6924118c00054efd526d9e48f68198f7da12    file.txt
> 
> Are there any possible downsides of such modification we should be aware of?

Yes, unfortunately current git isn't able to do that (even though work
is ongoing to make future versions handle that just fine). Right now
the populated submodule "ext" won't be removed when you switch to a
branch where it doesn't exist. If the new branch has a tree there,
you'll almost certainly get an error when trying to switch to it as
that would overwrite files left over from the submodule (end even if
it doesn't, you'll might get lots of untracked files in the tree
after the checkout).

As a workaround you could use a symbolic link (assuming you FS supports
that) and switch that around between two different directories:

100644 .gitmodules
100644 ext -> ext_sub
160000 ext_sub

100644 .gitmodules
100644 ext -> ext_tree
160000 ext_tree

If you then add ext_sub and ext_tree to the .gitignore of each side it
isn't present in, everything should work just fine (and when git learns
to handle that case, you can get rid of that workaround for future
commits).

Re: Delete gitlink entry but keep .gitmodules file unmodified

[Semen Vadishev]

> Yes, unfortunately current git isn't able to do that (even though work
> is ongoing to make future versions handle that just fine). Right now
> the populated submodule "ext" won't be removed when you switch to a
> branch where it doesn't exist. If the new branch has a tree there,
> you'll almost certainly get an error when trying to switch to it as
> that would overwrite files left over from the submodule (end even if
> it doesn't, you'll might get lots of untracked files in the tree
> after the checkout).
We assume such modifications are rare enough, so this downside is fairly 
minor in our case.

And what about these obsolete [submodule "foo"] sections left in 
.gitmodules and .git/config files? Do they bring any problems? Maybe for 
some older git versions?

Thank you,

Semen Vadishev,
TMate Software,
http://subgit.com/ - git+svn on the server side!


On 4/18/12 17:42, Jens Lehmann wrote:
> Am 18.04.2012 15:19, schrieb Semen Vadishev:
>> Suppose one has a properly initialized submodule in a tree like this:
>>
>> $ git ls-tree HEAD
>> 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1    .gitmodules
>> 160000 commit ec633ea81e3cf64c3735ef4acd5ff9a490ed54eb    ext
>> 100644 blob 597d6924118c00054efd526d9e48f68198f7da12    file.txt
>>
>> $ git show HEAD:.gitmodules
>> [submodule "ext"]
>>          path = ext
>>          url = $URL
>>
>> Then one pulls a modification that replaces 'ext' gitlink by some blob or tree entry, but keeps '.gitmodules' the same:
>>
>> $ git ls-tree HEAD
>> 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1    .gitmodules
>> 040000 tree 82e3a754b6a0fcb238b03c0e47d05219fbf9cf89    ext
>> 100644 blob 597d6924118c00054efd526d9e48f68198f7da12    file.txt
>>
>> Are there any possible downsides of such modification we should be aware of?
> Yes, unfortunately current git isn't able to do that (even though work
> is ongoing to make future versions handle that just fine). Right now
> the populated submodule "ext" won't be removed when you switch to a
> branch where it doesn't exist. If the new branch has a tree there,
> you'll almost certainly get an error when trying to switch to it as
> that would overwrite files left over from the submodule (end even if
> it doesn't, you'll might get lots of untracked files in the tree
> after the checkout).
>
> As a workaround you could use a symbolic link (assuming you FS supports
> that) and switch that around between two different directories:
>
> 100644 .gitmodules
> 100644 ext ->  ext_sub
> 160000 ext_sub
>
> 100644 .gitmodules
> 100644 ext ->  ext_tree
> 160000 ext_tree
>
> If you then add ext_sub and ext_tree to the .gitignore of each side it
> isn't present in, everything should work just fine (and when git learns
> to handle that case, you can get rid of that workaround for future
> commits).

Re: Delete gitlink entry but keep .gitmodules file unmodified

[Jens Lehmann]

Am 18.04.2012 16:34, schrieb Semen Vadishev:
> And what about these obsolete [submodule "foo"] sections left in .gitmodules and .git/config files? Do they bring any problems? Maybe for some older git versions?

None that I'm aware of, that should work just fine.