Re: [BUG] Possible bug in `remote set-url --add --push`
Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano: Jardel Weyrich jweyr...@gmail.com writes: I believe `remote set-url --add --push` has a bug. Performed tests with v1.8.0.1 and v1.8.1 (Mac OS X). Quoting the relevant part of the documentation: set-url Changes URL remote points to. Sets first URL remote points to matching regex oldurl (first URL if no oldurl is given) to newurl. If oldurl doesn’t match any URL, error occurs and nothing is changed. With --push, push URLs are manipulated instead of fetch URLs. With --add, instead of changing some URL, new URL is added. With --delete, instead of changing some URL, all URLs matching regex url are deleted. Trying to delete all non-push URLs is an error. Here are some steps to reproduce: 1. Show the remote URLs jweyrich@pharao:test_clone1 [* master]$ git remote -v origin /Volumes/sandbox/test (fetch) origin /Volumes/sandbox/test (push) 2. Add a new push URL for origin jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \ /Volumes/sandbox/test_clone2 3. Check what happened jweyrich@pharao:test_clone1 [* master]$ git remote -v origin /Volumes/sandbox/test (fetch) origin /Volumes/sandbox/test_clone2 (push) The original pushurl was replaced with the additional one, instead of being left and the new one getting added. That looks certainly wrong. However, the result of applying the attached patch (either to v1.7.12 or v1.8.1) still passes the test and I do not think it is doing anything differently from what you described above. What do you get from git config -l | grep '^remote\.origin' in steps 1. and 3. in your procedure? This question is trying to tell if your bug is in git remote -v or in git remote set-url. I'm not sure, if there is a bug at all. According to man git-push: The pushurl is used for pushes only. It is optional and defaults to url. (From the section REMOTES - Named remote in configuration file) the command: git remote add foo g...@foo-fetch.org/some.git will set remote.foo.url to g...@foo-fetch.org. Subsequently, fetch and push will use g...@foo-fetch.org as url. Fetch will use this url, because remote.foo.url explicitly sets this. push will use it in absence of a remote.foo.pushurl. Now, we're adding a push-url: git remote set-url --add --push foo g...@foo-push.org/some.git Relevant parts of config are now looking like: [remote foo] url = g...@foo-fetch.org/some.git pushurl = g...@foo-push.org/some.git Since, pushurl is now given explicitly, git push will use that one (and only that one). If we add another push-url now, git remote set-url --add --push foo g...@foo-push-also.org/some.git the next git-push will push to foo-push.org and foo-push-also.org. Now, using --set-url --delete on both of these urls restores the original state: only remote.foo.url is set; meaning implicitly pushurl defaults to url again. To me this is exactly what Jardel was observing: In step 2, Git replaced the original push URL instead of adding a new one. But it seems to happen only the first time I use `remote set-url --add --push`. Re-adding the original URL using the same command seems to work properly. And FWIW, if I delete (with set-url --delete) both URLs push, Git restores the original URL. Or am I missing something here? Might be that the bug actually is that the expectation was git remote add foo g...@foo-fetch.org/some.git should have created a config like: [remote foo] url = g...@foo-fetch.org/some.git pushurl = g...@foo-fetch.org/some.git since that is what git remote -v reports. If that is the case, we might want to amend the output of 'git remote -v' with the information that a pushurl is not explicitly given and thus defaults to url. Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Completion must sort before using uniq
I can't see the difference and in fact don't understand uniq's -u option al all Linux man pages say: only print unique lines, but that is what uniq does by default anyway?!? From the german translation of uniq's man-page, you can deduct that only print unique lines actually means: print lines that are _not repeated_ in the input. A short test confirms that. i.e.: printf a\nb\nb\nc\n | uniq -u gives: a c Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
Am Freitag, 23. November 2012, 16:55:21 schrieb Heiko Voigt: I am still a little bit undecided about an automatically crafted commit. At $dayjob we sometimes update submodules to their tip without any superproject changes just to make sure we use the newest version. Most of the time the commit messages are along the lines of updated submodule x to master. On one hand Junio is right that the person updating to the newest submodule stuff has no clue what to write in this message. I've been thinking about that for a while, when I started using submodules. In the end, I concluded, that what I really want to see in the commit message, is something similar to $(git shortlog $OLD_SHA1..$NEW_SHA1). I've scripted that and taught my CI-Server to do it automatically, if possible. So most of the time, I really don't want an automatically crafted commit whenever something causes the tip of a submodule to be at a new SHA1. Just my $.02, though. Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: upload-pack is slow with lots of refs
Am Mittwoch, 3. Oktober 2012, 16:13:16 schrieb Jeff King: On Wed, Oct 03, 2012 at 12:41:38PM -0700, Shawn O. Pearce wrote: Out of curiosity, how are you thinking about triggering such a new behavior in a backwards-compatible way? Invoke git-upload-pack2, and fall back to reconnecting to start git-upload-pack if it fails? Basically, yes. New clients connect for git-upload-pack2. Over git:// the remote peer will just close the TCP socket with no messages. The client can fallback to git-upload-pack and try again. Over SSH a similar thing will happen in the sense there is no data output from the remote side, so the client can try again. This has the downside of authentication twice over SSH, which may prompt for a password twice. But the user can get out of this by setting remote.NAME.uploadpack = git-upload-pack and thus force the Git client to use the current protocol if they have a new client and must continue to work over SSH with an old server, and don't use an ssh-agent. It's a shame that we have to reestablish the TCP or ssh connection to do the retry. The password thing is annoying, but also it just wastes a round-trip. It means we'd probably want to default the v2 probe to off (and let the user turn it on for a specific remote) until v2 is much more common than v1. Otherwise everyone pays the price. Would it be possible to use this workflow: - Every client connects per default to v1 - If server is capable of v2, it sends a flag along with the usual response (A v1 server will obviously not send that flag) - If client is also capable of v2 and gets the flag, it enables v2 for just that remote (probably unless the user said, i never want to) - Next time the client connects to that remote it will use v2. I'm not sure, if this is possible, since I think to remember that I have read in the Documentation folder something along the line: Capabilities announced from the server mean I want you to use exactly these flags. Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Submodule design
Am Dienstag, 2. Oktober 2012, 20:53:28 schrieben Sie: Hi, Today I learnt that a gitlink is a commit object embedded in a tree. However, I can't seem to be able to cat it. $ git ls-tree HEAD 100644 blob 5a91f388f3648b98ae34a19ec42ba9acc7852ef4.gitmodules 16 commit 8daa12004db8862b22f6c7dd244a88ac6108b194 dotfiles $ git cat-file 8daa12004db8862b22f6c7dd244a88ac6108b194 fatal: git cat-file 8daa12004db8862b22f6c7dd244a88ac6108b194: bad file Why is this? Does the object not exist in the object store at all? Correct. The tree entry is a pointer to the commit inside your submodule that shall be checked out. Obviously the submodule's commit is not part of the superproject. IOW: There are are actually 2 object stores: the superproject's and the submodule's. This tree entry makes a (perstiable) connection between the two. Then how was it embedded in the toplevel tree object in the first place? The .gitlink for submodules has quite some special handling associated to it. You can commit (and diff) it like any other blob. Also, why (how) does 'git diff' give me the impression that it's a blob? $ git diff diff --git a/dotfiles b/dotfiles index 8daa120..ff61f40 16 --- a/dotfiles +++ b/dotfiles @@ -1 +1 @@ -Subproject commit 8daa12004db8862b22f6c7dd244a88ac6108b194 +Subproject commit ff61f40e0938024aa3b748eb733a974b17082ec2 See above. Git smartly converts the state of the submodule into a one line text, allowing you to diff 2 states of the submodule cd dotfiles git pull # pulls some updates cd .. git add dotfiles git commit -mUpdate dot files to Version xxx git push This will record the dotfiles submodule's new HEAD SHA1 as the current one inside the superproject. When you now checkout the superproject to another location and do: a git submodule update --init it will clone the dotfiles submodule and checkout the exact same version that you just commited with the above commit. If it is really a blob, I should be able to stage and unstage it normally, but the following command is a no-op: $ git checkout -- dotfiles What is going on? Shouldn't we get rid of these ugly inconsistencies? HTH, Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Am Sonntag, 23. September 2012, 17:04:15 schrieb Ralf Thielow: On Sat, Sep 22, 2012 at 11:57 PM, Sascha Cunz sascha...@babbelbox.org wrote: As I know how hard translations can be, esp. with that much technical terms inside, I'm usually expecting _not_ to yield the same result when translating a software's translation back to English. Yeah, I think the goal is not making translations which are looking nearly the same when somebody translates them back to English in the first place. Exactly. The meaning is more important then the exact wording. Please consider this: Es wurden Neuaufbau- / Zusammenführungs-Informationen gefunden. Falls ein Neuaufbau bereits im Gange ist, versuche bitte: git rebase (--continue | --abort | --skip) Sollte dies nicht der Fall sein, können die Informationen durch rm -fr $(GIT_DIR)/rebase-merge entfernt werden. Es wird angehalten, falls etwas Schützenswertes gefunden werden sollte. It sounds way cleaner (to me at least) and transports all of the meaning. Esp. for the last sentence, it's very hard to find something in German that doesn't sound 'destructive'. Btw: In the past I've seen quite a few topics on translation on this list - is this at all the right place for that kind of discussion? Sascha However, git-rebase just threw these two sentences at me (And though i know their meaning, i couldn't get the meaning from the message, it gave). Both are in context of starting a rebase while one is already in progress. first is: Original: ... and I wonder if you are in the middle of another rebase. German git translation: ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. And a re-translation back to English from my understanding as native German speaker: ... and it would be astonishing (=i'd be surprised), if a rebase was already in progress. We try to avoid translating terms like I wonder if.. and similar as ich wundere mich, because it's very unusual in German messages of computer programs. Translators should have the freedom to reword terms a bit to make a more optimal translation, but the meaning must not be lost, and I can't say that this is the case. Translate the term in the middle of word-by-word would result in in der Mitte eines, which can be interpreted as a place somewhere or that an action is in progress. To avoid a possible confusion, we decided to translate this term as im Gange sein (be in progress) in the whole translation. I also think that in der Mitte einer Zusammenführung sein doesn't sound really good. It tends to mean a place, not an action. And second: Original: I am stopping in case you still have something valuable there. German git translation: Es wird angehalten, falls bereits etwas Nützliches vorhanden ist. I wanted to point out that etwas Nützliches is more something useful that something valuable. But the more I thought about it, the more it started to I've been thinking about possible different translations, and the only one I have in mind is wertvoll. But translating valuable as wertvoll (bereits etwas Wertvolles vorhanden) sounds a bit like we've found a treasure, instead of something which has a value in the meaning of content. I think having a translation which is more like useful than valuable does also hit the point of the message, doesn't it? confuse me (even the original text) - and now I feel like I don't understand the meaning of the last sentence at all; neither in English nor in the German translation: After removing the directory with all rebase-information inside it, WHERE should something valuable still be left over? Is it referring to my working tree? Yeah, I think it means the working tree and/or the index which would make sense. Ralf -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Am Sonntag, 23. September 2012, 17:36:08 schrieb knittl: Sharing my thoughts on this one, … [...] What about wichtig? I think that transfers the meaning pretty well. Es wird angehalten, um den Verlust wichtiger Infos zu vermeiden maybe? I hope the above spends some inspiration :) Thanks, Daniel, _this_ translation now let me even understand the English wording: I somehow added an implicit second again in that line, thinking this information is associated with the words and run me again. But what it actually wants to say, is probably: I won't remove the rebase- merge directory on your behalf, because you might have something valuable left over _from a previous rebase / merge run_ Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Am Sonntag, 23. September 2012, 19:34:23 schrieb Ralf Thielow: On Sun, Sep 23, 2012 at 5:41 PM, Sascha Cunz sascha...@babbelbox.org wrote: Exactly. The meaning is more important then the exact wording. Please consider this: Es wurden Neuaufbau- / Zusammenführungs-Informationen gefunden. We can't change the ... Verzeichnis *rebase-merge* ... part of the message, because rebase-merge is a substitution and we have to use all of them. Falls ein Neuaufbau bereits im Gange ist, versuche bitte: git rebase (--continue | --abort | --skip) Sollte dies nicht der Fall sein, können die Informationen durch rm -fr $(GIT_DIR)/rebase-merge entfernt werden. Es wird angehalten, falls etwas Schützenswertes gefunden werden sollte. It sounds way cleaner (to me at least) and transports all of the meaning. Esp. for the last sentence, it's very hard to find something in German that doesn't sound 'destructive'. Not sure why you change vorhanden ist to gefunden werden sollte. Maybe we should use a combination? See below. Probably a result of my initial misunderstanding of the original text. As I pointed out in another mail on this thread, I think the real meaning is: Es wird [jetzt] angehalten, _weil_ dort [im Rebase-Merge Verzeichnis] noch etwas Schützenswertes vorhanden sein könnte. Btw: In the past I've seen quite a few topics on translation on this list - is this at all the right place for that kind of discussion? Different translation teams use different places for discussions. The German uses this list. Like this, maybe. Yes, that is already much better. [PATCH] l10n: de.po: improve translation of a rebase message The word still was translated as bereits, change it to noch. valuable was translated as nützlich which is more like useful than valuable, change it to schützenswert. Noticed-by: Sascha Cunz sascha...@babbelbox.org Signed-off-by: Ralf Thielow ralf.thie...@gmail.com diff --git a/po/de.po b/po/de.po index 2739bc0..7fc0185 100644 --- a/po/de.po +++ b/po/de.po @@ -5756,8 +5756,8 @@ msgstr \t$cmd_live_rebase\n Wenn das nicht der Fall ist, probiere bitte\n \t$cmd_clear_stale_rebase\n -und führe dieses Kommando nochmal aus. Es wird angehalten, falls bereits\n -etwas Nützliches vorhanden ist. +und führe dieses Kommando nochmal aus. Es wird angehalten, falls noch\n +etwas Schützenswertes vorhanden ist. #: git-rebase.sh:395 #, sh-format -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Message from 'git-rebase'; German translation
As I know how hard translations can be, esp. with that much technical terms inside, I'm usually expecting _not_ to yield the same result when translating a software's translation back to English. However, git-rebase just threw these two sentences at me (And though i know their meaning, i couldn't get the meaning from the message, it gave). Both are in context of starting a rebase while one is already in progress. first is: Original: ... and I wonder if you are in the middle of another rebase. German git translation: ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. And a re-translation back to English from my understanding as native German speaker: ... and it would be astonishing (=i'd be surprised), if a rebase was already in progress. And second: Original: I am stopping in case you still have something valuable there. German git translation: Es wird angehalten, falls bereits etwas Nützliches vorhanden ist. I wanted to point out that etwas Nützliches is more something useful that something valuable. But the more I thought about it, the more it started to confuse me (even the original text) - and now I feel like I don't understand the meaning of the last sentence at all; neither in English nor in the German translation: After removing the directory with all rebase-information inside it, WHERE should something valuable still be left over? Is it referring to my working tree? So, for completeness, the full English message: It seems that there is already a rebase-merge directory, and I wonder if you are in the middle of another rebase. If that is the case, please try git rebase (--continue | --abort | --skip) If that is not the case, please rm -fr /work/lg2/src/.git/rebase-merge and run me again. I am stopping in case you still have something valuable there. Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bringing a bit more sanity to $GIT_DIR/objects/info/alternates?
[..] - By design, the borrowed object store MUST not ever lose any object from it, as such an object loss can corrupt the borrowing repositories. In theory, it is OK for the object store whose objects are borrowed by repositories to acquire new objects, but losing existing objects is an absolute no-no. [...] In practice, this means that users who use clone -s to make a new repository can *never* prune the original repository without risking to corrupt its borrowing repository [*1*]. [...] Given your example of /git/linux.git being a clone of Linus' repository, cloning a related repository using it as --reference: $ cd /git $ git clone --reference /git/linux.git git://k.org/linux-next.git mine Wouldn't it be by far a less intrusive alternative to do the following (in the clone step above): - create the file /git/linux.git/objects/borrowing/_git_mine (This is where we borrow FROM). This file would hold a packed-ref list of HEADs from the /git/mine clone of the repository. _git_mine here is slash-stripped version of the destination path. Maybe the packed-ref format could also be extended by a single line containing a full path to the foreign repository. - On every update-ref to /git/mine, update the 'borrowing' refs in /git/linux.git - On any maintenance on /git/linux.git (gc, prune, repack, etc.) consider refs in the packed-refs at objects/borrowing to be valid references. If packed-ref format was adopted like stated above, we could stat() here if this directory still exists and error out if it doesn't (In this case the user should tell us if she moved or removed the clone). Any alternatives for looking up the packed-refs list for borrowing would also be doable; i.E. putting the list of valid borrowing-packed-refs-files into the config file (as opposed to lookup $GIT_DIR/objects/borrowing above). Putting this list into the config file would eliminate need for the packed-ref format change and give the user the ability to maintain her clones with well- known command 'git config' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] Use work tree to determine if it supports symlinks
From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001
From: Sascha Cunz sas...@babbelbox.org
Date: Fri, 27 Jul 2012 22:54:56 +0200
Subject: [PATCH] Use work tree to determine if it supports symlinks
When creating a new repository, we check some capabilities of the
underlying file system(s). We check the file system for its case
sensitivity and the ability to create symbolic links.
Before this patch the .git-dir was used for this check, while the
comments in code clearly state to test on the work tree.
This patch teaches the tests for symbolic links and utf8 precomposion
to use the work tree instead of the .git directory.
Signed-off-by: Sascha Cunz sas...@babbelbox.org
---
builtin/init-db.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
In recent discussion[1] on libgit2, we found this little inconsistency
and it's not exactly clear, whether the git implementation or documentation
should be followed.
I left out to change the case-insensitive check. If you think, this patch
is useful at all (I actually have a hard time to find a real world use
case), i would reroll it with that change included. I think in this case,
the probe_utf8_pathname_composition might be refactored: We don't have a
file in the work tree yet = we must create one, test its accessibility
with a different name and finally unlink it. That's more or less what
probe_utf8_pathname_composition does.
SaCu
[1] https://github.com/libgit2/libgit2/pull/844#issuecomment-7311677
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 244fb7f..2f988ad 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -273,6 +273,23 @@ static int create_default_files(const char *template_path)
}
if (!reinit) {
+ const char *work_tree = get_git_work_tree();
+
+ /* Check if the filesystem is case-insensitive */
+ path[len] = 0;
+ strcpy(path + len, CoNfIg);
+ if (!access(path, F_OK))
+ git_config_set(core.ignorecase, true);
+
+ /* Point 'path' to the work tree */
+ len = strlen(work_tree);
+ if (len sizeof(path)-8)
+ die(_(insane working directory %s), work_tree);
+
+ memcpy(path, work_tree, len);
+ if (len path[len-1] != '/')
+ path[len++] = '/';
+
/* Check if symlink is supported in the work tree */
path[len] = 0;
strcpy(path + len, tXX);
@@ -285,11 +302,6 @@ static int create_default_files(const char *template_path)
else
git_config_set(core.symlinks, false);
- /* Check if the filesystem is case-insensitive */
- path[len] = 0;
- strcpy(path + len, CoNfIg);
- if (!access(path, F_OK))
- git_config_set(core.ignorecase, true);
probe_utf8_pathname_composition(path, len);
}
--
1.7.12.rc0.23.g3f449e7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Use work tree to determine if it supports symlinks
On Friday, July 27, 2012 02:55:49 PM you wrote: Sascha Cunz sascha...@babbelbox.org writes: From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001 From: Sascha Cunz sas...@babbelbox.org Date: Fri, 27 Jul 2012 22:54:56 +0200 Subject: [PATCH] Use work tree to determine if it supports symlinks When creating a new repository, we check some capabilities of the underlying file system(s). We check the file system for its case sensitivity and the ability to create symbolic links. Before this patch the .git-dir was used for this check, while the comments in code clearly state to test on the work tree. That is simply because a layout that has .git and its containing directory (i.e. the working tree) on a separate filesystem when we run git init is not supported, But isn't enforced either. Are there known issues? and more importantly, we do not want to step outside .git, which is the simplest and safest way to avoid touching the end-user data that sits in the working tree. While I think that this is true, I don't see the connection. The code comment is about checking the filesystem that houses both the working tree and .git; if the user later wants to turn .git into a separate mount point, or if the user wants to use GIT_DIR and GIT_WORK_TREE to create a funny layout, the user should know how to muck with .git/config to adjust to the peculiarity. Ok, so repository and working directory are simply not meant to be on different file systems. Thanks for the clarification. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Use work tree to determine if it supports symlinks
On Friday, July 27, 2012 03:58:49 PM you wrote: Sascha Cunz sas...@babbelbox.org writes: Ok, so repository and working directory are simply not meant to be on different file systems. Thanks for the clarification. I did not mean and that is a rule we need to enforce and keep forever. I did not parse your statement as such - I just realized, that i probably won't find a valid use case for using 2 file systems with different capabilities. Which lead me to conclude that your is not supported is a sufficient response. Though, I think I have a valid use case for using different file systems: For speed reasons one could setup .git to point to a different drive. I wanted to try this ever since I saw, it would be possible - but I never came around actually trying it. However, if this would turn out to be an improvement, I don't think one would mix file systems with different capabilities (i.e. FAT+ext2). I was just answering your (implied) question why does code comment, behaviour and documentation disagree?, to give a data point that would be useful when discussing what the ideal behaviour should be. I think, that 'git init --separate-git-dir' (without a 'different filesystems' restriction) is some kind of support for creating non-bare repositories where work tree and .git dir are located on different file systems. Then, in case a user _did_ setup a peculiar layout, an invocation of 'git submodule init' might make a call to 'git clone', which _should_ set core.symlinks to false but doesn't. At that point the user might not remember in detail how peculiar the setup actually is - and at the same time did not request git to do anything special. I don't know how far-fetched that is, but it's at least possible. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
