[PATCH] Introduce core.keepHardLinks

[PATCH] Introduce core.keepHardLinks

[Johannes Schindelin]

When a tracked file was hard linked, we used to break the hard link
whenever Git writes to that file.  Make that optional.

To keep the implementation simple, mode changes will still break the
hard links.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	With the current revision of the patch, I can set
	keep_hard_links = 1 and the test suite still passes.

	I briefly tried to fix the "mode changes" issue, but replacing
	the "st.st_mode != ce->ce_mode" with "S_ISREG(ce->ce_mode)"
	(and consequently also adding
	 "|| (keep_hard_links && chmod(path, mode)" to create_file()),
	made at least t3400 fail, and then I ran out of my Git time budget.

 Documentation/config.txt |    4 +++
 cache.h                  |    1 +
 config.c                 |    5 ++++
 entry.c                  |    7 ++++-
 environment.c            |    1 +
 t/t0056-hardlinked.sh    |   58 ++++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 74 insertions(+), 2 deletions(-)
 create mode 100644 t/t0056-hardlinked.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 173386e..7bfe431 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -207,6 +207,10 @@ core.symlinks::
 	file. Useful on filesystems like FAT that do not support
 	symbolic links. True by default.
 
+core.keepHardLinks::
+	If true, do not break hard links by deleting and recreating the
+	files.  Off by default.
+
 core.gitProxy::
 	A "proxy command" to execute (as 'command host port') instead
 	of establishing direct connection to the remote server when
diff --git a/cache.h b/cache.h
index c89f2c6..c4bdece 100644
--- a/cache.h
+++ b/cache.h
@@ -479,6 +479,7 @@ enum rebase_setup_type {
 
 extern enum branch_track git_branch_track;
 extern enum rebase_setup_type autorebase;
+extern int keep_hard_links;
 
 #define GIT_REPO_VERSION 0
 extern int repository_format_version;
diff --git a/config.c b/config.c
index 18d305c..35ffdef 100644
--- a/config.c
+++ b/config.c
@@ -490,6 +490,11 @@ static int git_default_core_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.keephardlinks")) {
+		keep_hard_links = git_config_bool(var, value);
+		return 0;
+	}
+
 	/* Add other config variables here and to Documentation/config.txt. */
 	return 0;
 }
diff --git a/entry.c b/entry.c
index aa2ee46..dfddf83 100644
--- a/entry.c
+++ b/entry.c
@@ -82,7 +82,8 @@ static void remove_subtree(const char *path)
 static int create_file(const char *path, unsigned int mode)
 {
 	mode = (mode & 0100) ? 0777 : 0666;
-	return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
+	return open(path, O_WRONLY | O_CREAT |
+			(keep_hard_links ? O_TRUNC : O_EXCL), mode);
 }
 
 static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)
@@ -225,7 +226,9 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
 			if (!state->force)
 				return error("%s is a directory", path);
 			remove_subtree(path);
-		} else if (unlink(path))
+		} else if ((!keep_hard_links || !S_ISREG(st.st_mode) ||
+					st.st_mode != ce->ce_mode) &&
+				unlink(path))
 			return error("unable to unlink old '%s' (%s)", path, strerror(errno));
 	} else if (state->not_new)
 		return 0;
diff --git a/environment.c b/environment.c
index 0693cd9..ef721e0 100644
--- a/environment.c
+++ b/environment.c
@@ -42,6 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
 unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
 enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
 enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+int keep_hard_links = 0;
 
 /* This is set by setup_git_dir_gently() and/or git_default_config() */
 char *git_work_tree_cfg;
diff --git a/t/t0056-hardlinked.sh b/t/t0056-hardlinked.sh
new file mode 100644
index 0000000..934c2bc
--- /dev/null
+++ b/t/t0056-hardlinked.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+
+test_description='read-tree and checkout respect hardlinked files'
+
+. ./test-lib.sh
+
+cat > file << EOF
+1. Nf3 Nf6 2. c4 g6 3. Nc3 Bg7 4. d4 O-O 5. Bf4 d5 6. Qb3 dxc4 7. Qxc4 c6
+8. e4 Nbd7 9. Rd1 Nb6 10. Qc5 Bg4 11. Bg5 Na4 12. Qa3 Nxc3 13. bxc3 Nxe4
+14. Bxe7 Qb6 15. Bc4 Nxc3 16. Bc5 Rfe8+ 17. Kf1 Be6 18. Bxb6 Bxc4+ 19. Kg1 Ne2+
+20. Kf1 Nxd4+ 21. Kg1 Ne2+ 22. Kf1 Nc3+ 23. Kg1 axb6 24. Qb4 Ra4 25. Qxb6 Nxd1
+26. h3 Rxa2 27. Kh2 Nxf2 28. Re1 Rxe1 29. Qd8+ Bf8 30. Nxe1 Bd5 31. Nf3 Ne4
+32. Qb8 b5 33. h4 h5 34. Ne5 Kg7 35. Kg1 Bc5+ 36. Kf1 Ng3+ 37. Ke1 Bb4+
+38. Kd1 Bb3+ 39. Kc1 Ne2+ 40. Kb1 Nc3+
+EOF
+
+ln file link || {
+	say "Could not hard link; skipping test"
+	test_done
+	exit
+}
+
+test_expect_success setup '
+
+	git config core.keepHardLinks true &&
+	test_cmp file link &&
+	cp file old &&
+	git add file &&
+	test_tick &&
+	git commit -m initial &&
+	echo "41. Kc1 Rc2#" >> file &&
+	git add file &&
+	test_tick &&
+	git commit -m 2nd &&
+	test_cmp file link &&
+	! test_cmp file old
+
+'
+
+test_expect_success 'checking a file out does not break the hard link' '
+
+	git checkout HEAD^ -- file &&
+	test_cmp file link &&
+	test_cmp file old
+
+'
+
+test_expect_success 'read-tree -u -m does not break the hard link' '
+
+	git reset --hard &&
+	test_cmp file link &&
+	git read-tree -u -m HEAD^ &&
+	test_cmp file link &&
+	test_cmp file old
+
+'
+
+test_done
-- 
1.6.0.2.749.g0cc32

Re: [PATCH] Introduce core.keepHardLinks

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> When a tracked file was hard linked, we used to break the hard link
> whenever Git writes to that file.  Make that optional.

Why would anyone want to do this?

I cannot fathom why a user wants this much rope to hang themselves
with...

 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 173386e..7bfe431 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -207,6 +207,10 @@ core.symlinks::
>  	file. Useful on filesystems like FAT that do not support
>  	symbolic links. True by default.
>  
> +core.keepHardLinks::
> +	If true, do not break hard links by deleting and recreating the
> +	files.  Off by default.
> +
>  core.gitProxy::
>  	A "proxy command" to execute (as 'command host port') instead
>  	of establishing direct connection to the remote server when

-- 
Shawn.

Re: [PATCH] Introduce core.keepHardLinks

[Junio C Hamano]

Shawn had this queued in pu, but it appears to even fail its own tests on
my machine, when applied on top of 'master'.

I tentatively dropped this from pu.

Re: [PATCH] Introduce core.keepHardLinks

[Johannes Schindelin]

Hi,

On Sun, 12 Oct 2008, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 
> > When a tracked file was hard linked, we used to break the hard link
> > whenever Git writes to that file.  Make that optional.
> 
> Why would anyone want to do this?
> 
> I cannot fathom why a user wants this much rope to hang themselves 
> with...

The question is not so much why anyone want to do this, but _if_.

And the answer is: yes.

Ciao,
Dscho

Re: [PATCH] Introduce core.keepHardLinks

[Johannes Schindelin]

Hi,

On Sun, 12 Oct 2008, Junio C Hamano wrote:

> Shawn had this queued in pu, but it appears to even fail its own tests 
> on my machine, when applied on top of 'master'.

Sorry, I cannot reproduce at all.

I tested this on two machines, i686 and x86_64 (of course, on top of my 
patches to 'next', but now repeated the test with the commit 
cherry-picked to your 5c283eb(Merge branch 'maint')).

It passes.

Ciao,
Dscho

P.S.: I even made "make clean && make -j50 test", just in case  we have 
some dependency issue in the Makefile (happened before).  Still passes.

P.P.S.: It would be nice if you could run the test with -i -v (and maybe 
with sh -x) and post the output.  Thank you very much.

P.P.P.S.: Just for reference: this is what the cherry-picked commit 
format-patches to:

-- snipsnap --
[PATCH] Introduce core.keepHardLinks

When a tracked file was hard linked, we used to break the hard link
whenever Git writes to that file.  Make that optional.

To keep the implementation simple, mode changes will still break the
hard links.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config.txt |    4 +++
 cache.h                  |    1 +
 config.c                 |    5 ++++
 entry.c                  |    7 ++++-
 environment.c            |    1 +
 t/t0056-hardlinked.sh    |   58 ++++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 74 insertions(+), 2 deletions(-)
 create mode 100644 t/t0056-hardlinked.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..aacaeae 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -207,6 +207,10 @@ core.symlinks::
 	file. Useful on filesystems like FAT that do not support
 	symbolic links. True by default.
 
+core.keepHardLinks::
+	If true, do not break hard links by deleting and recreating the
+	files.  Off by default.
+
 core.gitProxy::
 	A "proxy command" to execute (as 'command host port') instead
 	of establishing direct connection to the remote server when
diff --git a/cache.h b/cache.h
index 991544c..d6348a1 100644
--- a/cache.h
+++ b/cache.h
@@ -478,6 +478,7 @@ enum rebase_setup_type {
 
 extern enum branch_track git_branch_track;
 extern enum rebase_setup_type autorebase;
+extern int keep_hard_links;
 
 #define GIT_REPO_VERSION 0
 extern int repository_format_version;
diff --git a/config.c b/config.c
index b8d289d..944e18e 100644
--- a/config.c
+++ b/config.c
@@ -490,6 +490,11 @@ static int git_default_core_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.keephardlinks")) {
+		keep_hard_links = git_config_bool(var, value);
+		return 0;
+	}
+
 	/* Add other config variables here and to Documentation/config.txt. */
 	return 0;
 }
diff --git a/entry.c b/entry.c
index aa2ee46..dfddf83 100644
--- a/entry.c
+++ b/entry.c
@@ -82,7 +82,8 @@ static void remove_subtree(const char *path)
 static int create_file(const char *path, unsigned int mode)
 {
 	mode = (mode & 0100) ? 0777 : 0666;
-	return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
+	return open(path, O_WRONLY | O_CREAT |
+			(keep_hard_links ? O_TRUNC : O_EXCL), mode);
 }
 
 static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)
@@ -225,7 +226,9 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
 			if (!state->force)
 				return error("%s is a directory", path);
 			remove_subtree(path);
-		} else if (unlink(path))
+		} else if ((!keep_hard_links || !S_ISREG(st.st_mode) ||
+					st.st_mode != ce->ce_mode) &&
+				unlink(path))
 			return error("unable to unlink old '%s' (%s)", path, strerror(errno));
 	} else if (state->not_new)
 		return 0;
diff --git a/environment.c b/environment.c
index 0693cd9..ef721e0 100644
--- a/environment.c
+++ b/environment.c
@@ -42,6 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
 unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
 enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
 enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+int keep_hard_links = 0;
 
 /* This is set by setup_git_dir_gently() and/or git_default_config() */
 char *git_work_tree_cfg;
diff --git a/t/t0056-hardlinked.sh b/t/t0056-hardlinked.sh
new file mode 100644
index 0000000..934c2bc
--- /dev/null
+++ b/t/t0056-hardlinked.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+
+test_description='read-tree and checkout respect hardlinked files'
+
+. ./test-lib.sh
+
+cat > file << EOF
+1. Nf3 Nf6 2. c4 g6 3. Nc3 Bg7 4. d4 O-O 5. Bf4 d5 6. Qb3 dxc4 7. Qxc4 c6
+8. e4 Nbd7 9. Rd1 Nb6 10. Qc5 Bg4 11. Bg5 Na4 12. Qa3 Nxc3 13. bxc3 Nxe4
+14. Bxe7 Qb6 15. Bc4 Nxc3 16. Bc5 Rfe8+ 17. Kf1 Be6 18. Bxb6 Bxc4+ 19. Kg1 Ne2+
+20. Kf1 Nxd4+ 21. Kg1 Ne2+ 22. Kf1 Nc3+ 23. Kg1 axb6 24. Qb4 Ra4 25. Qxb6 Nxd1
+26. h3 Rxa2 27. Kh2 Nxf2 28. Re1 Rxe1 29. Qd8+ Bf8 30. Nxe1 Bd5 31. Nf3 Ne4
+32. Qb8 b5 33. h4 h5 34. Ne5 Kg7 35. Kg1 Bc5+ 36. Kf1 Ng3+ 37. Ke1 Bb4+
+38. Kd1 Bb3+ 39. Kc1 Ne2+ 40. Kb1 Nc3+
+EOF
+
+ln file link || {
+	say "Could not hard link; skipping test"
+	test_done
+	exit
+}
+
+test_expect_success setup '
+
+	git config core.keepHardLinks true &&
+	test_cmp file link &&
+	cp file old &&
+	git add file &&
+	test_tick &&
+	git commit -m initial &&
+	echo "41. Kc1 Rc2#" >> file &&
+	git add file &&
+	test_tick &&
+	git commit -m 2nd &&
+	test_cmp file link &&
+	! test_cmp file old
+
+'
+
+test_expect_success 'checking a file out does not break the hard link' '
+
+	git checkout HEAD^ -- file &&
+	test_cmp file link &&
+	test_cmp file old
+
+'
+
+test_expect_success 'read-tree -u -m does not break the hard link' '
+
+	git reset --hard &&
+	test_cmp file link &&
+	git read-tree -u -m HEAD^ &&
+	test_cmp file link &&
+	test_cmp file old
+
+'
+
+test_done
-- 
1.6.0.2.749.g0cc32

Re: [PATCH] Introduce core.keepHardLinks

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> I cannot fathom why a user wants this much rope to hang themselves 
>> with...
>
> The question is not so much why anyone want to do this, but _if_.

Sorry, I think the question should be _why_.

You can gain a sympathetic "Ah, that is sensible, and 'this much rope to
hang themselves with' comment was unwarranted" only by answering that
question.

Re: [PATCH] Introduce core.keepHardLinks

[Johannes Schindelin]

Hi,

On Mon, 13 Oct 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> I cannot fathom why a user wants this much rope to hang themselves 
> >> with...
> >
> > The question is not so much why anyone want to do this, but _if_.
> 
> Sorry, I think the question should be _why_.
> 
> You can gain a sympathetic "Ah, that is sensible, and 'this much rope to 
> hang themselves with' comment was unwarranted" only by answering that 
> question.

Okay, here are a couple of reasons:

- all the editors that this guy tested keep the hard links, so it was 
  kinda hard to understand why Git insists on behaving differently,

- if the user asked for hard links, it is not Git's place to question that 
  decision,

- and in that user's scenario a certain file has to be shared between 
  different projects that are all version-controlled with Git, but in 
  different teams and with different servers they connect to.  So no, you 
  cannot even make a submodule of it, because the guys involved do not 
  share any repository/server access.  Besides, submodules are not 
  user-friendly enough yet.

Oh, and come to think of it, this could solve the old issue of "I want to 
track only a few files in my $HOME/".

Anyway, I think that breaking hard links is not a nice habit of Git (after 
all, from the user's point of view the file is not created, but 
modified!), and I would have expected others to need a lot less arguments 
to see it that way, too.

Ciao,
Dscho

Re: [PATCH] Introduce core.keepHardLinks

[Stephan Beyer]

Hi,

Johannes Schindelin wrote:
> and I would have expected others to need a lot less arguments 
> to see it that way, too.

Despite the fact that I've never used hardlinks in a git repository, I
would have expected git to keep them.  So I'm one of the "others" who
thinks this config option is just sane (and should perhaps even be
enabled by default, if it does not break stuff on file systems that do
not have a hardlink feature... but ok)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [PATCH] Introduce core.keepHardLinks

[Shawn O. Pearce]

Stephan Beyer <s-beyer@gmx.net> wrote:
> Johannes Schindelin wrote:
> > and I would have expected others to need a lot less arguments 
> > to see it that way, too.
> 
> Despite the fact that I've never used hardlinks in a git repository, I
> would have expected git to keep them.  So I'm one of the "others" who
> thinks this config option is just sane (and should perhaps even be
> enabled by default, if it does not break stuff on file systems that do
> not have a hardlink feature... but ok)

My problem is many users do "cp -rl a b" to clone a->b and hardlink
the working directory.  They expect "cd b && git checkout foo" to
then only unlink the paths that differ.  Updating the original inode
would break repository a.

Its a change in behavior, to some of our oldest users.  So it can't
really be on by default.

-- 
Shawn.

Re: [PATCH] Introduce core.keepHardLinks

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> - all the editors that this guy tested keep the hard links, so it was 
>   kinda hard to understand why Git insists on behaving differently,
>
> - if the user asked for hard links, it is not Git's place to question that 
>   decision,

These are non-arguments, when you are asked to give rationale for adding
capability to "ask for hard links" to begin with.

IOW, the question was why git should support tracked contents being
hardlinked to something else.

[jc: Sorry for dropping Shawn from CC: list.  pobox.com seems to complain
on his address for some reason.  Here are msmtp log for an identical
message with and without him on the recipient list.

Oct 13 10:23:57 host=sasl.smtp.pobox.com tls=on auth=on user=junio@pobox.com from=junio@pobox.com recipients=Johannes.Schindelin@gmx.de,barkalow@iabervon.org,git@vger.kernel.org,spearce@spearce.org,gitster@pobox.com smtpstatus=451 smtpmsg='451 4.3.5 Server configuration problem' errormsg='recipient address spearce@spearce.org not accepted by the server' exitcode=EX_DATAERR
Oct 13 10:31:26 host=sasl.smtp.pobox.com tls=on auth=on user=junio@pobox.com from=junio@pobox.com recipients=Johannes.Schindelin@gmx.de,barkalow@iabervon.org,git@vger.kernel.org,gitster@pobox.com mailsize=2283 exitcode=EX_OK
]

Re: [PATCH] Introduce core.keepHardLinks

[Johannes Schindelin]

Hi,

On Mon, 13 Oct 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > - all the editors that this guy tested keep the hard links, so it was 
> >   kinda hard to understand why Git insists on behaving differently,
> >
> > - if the user asked for hard links, it is not Git's place to question 
> >   that decision,
> 
> These are non-arguments,

Actually, they are arguments.

The thing is: these editors do what they do for a reason.  Which is 
exactly the second reason.

When a user makes hard links, it is not just for fun and bullocks.  It is 
not for copy-on-write either, that's not what hard links are supposed to 
do.  It is for cases when you need the _same_ information in two places.

I am not that big a user of hard links myself, but when I do, I know 
exactly what I am doing.  And with my patch and that config variable set 
to true, Git will not interfer with that.

Ciao,
Dscho

Re: [PATCH] Introduce core.keepHardLinks

[Johannes Schindelin]

Hi,

On Mon, 13 Oct 2008, Shawn O. Pearce wrote:

> Stephan Beyer <s-beyer@gmx.net> wrote:
> > Johannes Schindelin wrote:
> > > and I would have expected others to need a lot less arguments 
> > > to see it that way, too.
> > 
> > Despite the fact that I've never used hardlinks in a git repository, I 
> > would have expected git to keep them.  So I'm one of the "others" who 
> > thinks this config option is just sane (and should perhaps even be 
> > enabled by default, if it does not break stuff on file systems that do 
> > not have a hardlink feature... but ok)
> 
> My problem is many users do "cp -rl a b" to clone a->b and hardlink the 
> working directory.  They expect "cd b && git checkout foo" to then only 
> unlink the paths that differ.  Updating the original inode would break 
> repository a.
> 
> Its a change in behavior, to some of our oldest users.  So it can't 
> really be on by default.

Which is the reason why my commit is not titled "Make Git respect hard 
links by default", but "Introduce core.keepHardLinks".  I also hate people 
who try to break my setup.

Which scenario (breaking someone's setup) was exactly what triggered this 
patch.

Ciao,
Dscho

Re: [PATCH] Introduce core.keepHardLinks

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Mon, 13 Oct 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > - all the editors that this guy tested keep the hard links, so it was 
>> >   kinda hard to understand why Git insists on behaving differently,
>> >
>> > - if the user asked for hard links, it is not Git's place to question 
>> >   that decision,
>> 
>> These are non-arguments,
>
> Actually, they are arguments.
>
> The thing is: these editors do what they do for a reason.  Which is 
> exactly the second reason.
>
> When a user makes hard links, it is not just for fun and bullocks.  It is 
> not for copy-on-write either, that's not what hard links are supposed to 
> do.  It is for cases when you need the _same_ information in two places.
>
> I am not that big a user of hard links myself, but when I do, I know 
> exactly what I am doing.  And with my patch and that config variable set 
> to true, Git will not interfer with that.

Ok, such a possible benefit should be described and defended better then.
I only thought of the scenario Shawn has brought up, which is a downside
of using this option without any conceivable upside, when I read your
patch and your rationale you repeated in a few messages that followed.

You could have said something like "The users may want to have a checkout,
and keep the same contents always appear elsewhere i.e. 'installing by
hardlinking'.  In such a setup, editing the source with an editor
configured not to break hardlinks would still work fine, but git-checkout
will unconditionally break such links, which is undesirable.  Such a setup
would want a configuration variable like this."

"It is not for fun and bullocks" is not a description any clearer than
what you kept repeating, but if you stated it like the above, then I would
not have had trouble understanding what you wanted to say.

The documentation update needs to warn about the Shawn's scenario.  I also
do not know what this should do when you have two tracked paths with
identical contents hardlinked to each other.  Because we do not track
hardlinks, I _think_ breaking links would be the right thing to do for
such paths regardless of this configuration variable.

It also raises another question.  Don't you want this to be an attribute
for paths, not all-or-nothing configuration per repository?

Re: [PATCH] Introduce core.keepHardLinks

[Johannes Schindelin]

Hi,

On Mon, 13 Oct 2008, Junio C Hamano wrote:

> You could have said something like "The users may want to have a 
> checkout, and keep the same contents always appear elsewhere i.e. 
> 'installing by hardlinking'.  In such a setup, editing the source with 
> an editor configured not to break hardlinks would still work fine, but 
> git-checkout will unconditionally break such links, which is 
> undesirable.  Such a setup would want a configuration variable like 
> this."

Sounds very nice.  Sorry for being grumpy, and not being able to come up 
with such a beautiful description.

> The documentation update needs to warn about the Shawn's scenario.  I also
> do not know what this should do when you have two tracked paths with
> identical contents hardlinked to each other.

When the user does that, it's the user's wish.  I'd not let Git play cute 
games with that.

> It also raises another question.  Don't you want this to be an attribute 
> for paths, not all-or-nothing configuration per repository?

I'd rather not have it as an attribute, because it is not so much about 
file types that should show this behavior.  It is more like an option that 
I fully expect to be set in $HOME/.gitconfig.

Ciao,
Dscho