Re: Delete gitlink entry but keep .gitmodules file unmodified
Show 8 quoted lines
> 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:
Show 45 quoted lines
> 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).
