Re: [BUG] Possible bug in `remote set-url --add --push`

[Sascha Cunz]

Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:
> Jardel Weyrich  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  (first URL if no  is given) to
> >> . If  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
> >>  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  is used for pushes only. It is optional and defaults to
   .
(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 v3 1/3] git-submodule add: Add -r/--record option

[Sascha Cunz]

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: [PATCH] Completion must sort before using uniq

[Sascha Cunz]

> 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: upload-pack is slow with lots of refs

[Sascha Cunz]

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

[Sascha Cunz]

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 -m"Update 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

[Sascha Cunz]

Am Sonntag, 23. September 2012, 19:34:23 schrieb Ralf Thielow:
> On Sun, Sep 23, 2012 at 5:41 PM, Sascha Cunz  
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 
> Signed-off-by: Ralf Thielow 
> 
> 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

Re: Message from 'git-rebase'; German translation

[Sascha Cunz]

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

[Sascha Cunz]

Am Sonntag, 23. September 2012, 17:04:15 schrieb Ralf Thielow:
> On Sat, Sep 22, 2012 at 11:57 PM, Sascha Cunz  
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

Message from 'git-rebase'; German translation

[Sascha Cunz]

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?

[Sascha Cunz]

[..]
>  - 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

Re: [RFC/PATCH] Use work tree to determine if it supports symlinks

[Sascha Cunz]

On Friday, July 27, 2012 03:58:49 PM you wrote:
> Sascha Cunz  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

Re: [RFC/PATCH] Use work tree to determine if it supports symlinks

[Sascha Cunz]

On Friday, July 27, 2012 02:55:49 PM you wrote:
> Sascha Cunz  writes:
> > From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001
> > From: Sascha Cunz 
> > 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

[RFC/PATCH] Use work tree to determine if it supports symlinks

[Sascha Cunz]

>From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001
From: Sascha Cunz 
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 
---
 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