Bug with git-submodule and IFS

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

 



Hi there,

I ran into an interesting bug with git submodules today.  It appears that if your IFS is not set to what git-submodule expects it to be (i.e. the standard IFS), it will break in a fun way.

Example:

$ git init
Initialized empty Git repository in /home/adranse/test/.git/
$ git submodule add github:/repos/perf
Cloning into 'perf'...
remote: Counting objects: 5744, done.
remote: Compressing objects: 100% (4627/4627), done.
remote: Total 5744 (delta 2400), reused 1579 (delta 343)
Receiving objects: 100% (5744/5744), 28.78 MiB | 4.56 MiB/s, done.
Resolving deltas: 100% (2400/2400), done.
$ export IFS="
> "
$ git submodule update --init --recursive
No submodule mapping found in .gitmodules for path ''
$ unset IFS
$ git submodule update --init --recursive
Submodule 'perf' () registered for path 'perf'

As a solution, I would suggest setting IFS to the expected value before calling the git-submodule shell script.

Thanks,

Andrew Dranse
OANDA Corporation
adranse@xxxxxxxxx
--
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]