Re: Delete gitlink entry but keep .gitmodules file unmodified

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]