The g+s bit on directories to make group ownership inherited is a
SysVism --- BSD and most of its descendants do not need it since they
do the sane thing by default without g+s. In fact, on some
filesystems (but not all --- tmpfs works this way but UFS does not),
the kernel of FreeBSD does not even allow non-root users to set setgid
bit on directories and produces errors when one tries:
$ git init --shared dir
fatal: Could not make /tmp/dir/.git/refs writable by group
Since the setgid bit would only mean "do what you were going to do
already", it's better to avoid setting it. Accordingly, ever since
v1.5.5-rc0~59^2 (Do not use GUID on dir in git init --share=all on
FreeBSD, 2008-03-05), git on true FreeBSD has done exactly that. Set
DIR_HAS_BSD_GROUP_SEMANTICS in the makefile for GNU/kFreeBSD, too, so
machines that use glibc with the kernel of FreeBSD get the same fix.
This fixes t0001-init.sh and t1301-shared-repo.sh on GNU/kFreeBSD
when running tests with --root pointing to a directory that uses
tmpfs.
Signed-off-by: Jonathan Nieder <redacted>
---
Sorry to have taken so long to send this one out. Anyway, it seems
to me like the right thing to do. Petr, what do you think?
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8d6d4515..924749ed 100644
--- a/Makefile
+++ b/Makefile
@@ -820,6 +820,7 @@ ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
NO_MKSTEMPS = YesPlease
HAVE_PATHS_H = YesPlease
+ DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
endif
ifeq ($(uname_S),UnixWare)
CC = cc
--
1.7.7.rc1
Jonathan Nieder wrote:
Since the setgid bit would only mean "do what you were going to do
already", it's better to avoid setting it. Accordingly, ever since
v1.5.5-rc0~59^2 (Do not use GUID on dir in git init --share=all on
FreeBSD, 2008-03-05), git on true FreeBSD has done exactly that. Set
DIR_HAS_BSD_GROUP_SEMANTICS in the makefile for GNU/kFreeBSD, too, so
machines that use glibc with the kernel of FreeBSD get the same fix.
[...]
Sorry to have taken so long to send this one out. Anyway, it seems
to me like the right thing to do. Petr, what do you think?
fwiw:
Acked-by: Petr Salinger <redacted>
Thanks for looking it over.
(people cc-ed: your input would be welcome on [*] below. See commit
81a24b52, "Do not use GUID on dir in git init --shared=all on FreeBSD"
for context)
Hi Junio,
From Documentation/RelNotes/1.7.7.1.txt:
* On some BSD systems, adding +s bit on directories is detrimental
(it is not necessary on BSD to begin with). The installation
procedure has been updated to take this into account.
I assume this is referring to 0b20dd8f (Makefile: do not set setgid
bit on directories on GNU/kFreeBSD, 2011-10-03), which admittedly
does have a subject line that suggests it would be about that (sorry
about that). The change was actually about "git init -s" which sets
the setgid bit on SysV-style systems to allow shared access to a
repository (and can provoke errors on BSD-style systems, depending on
how permissive the filesystem in use wants to be).
More to the point, the patch was just taking a fix that arrived for
FreeBSD in v1.5.5 days and making it also apply to machines using an
(obscure) GNU userland/FreeBSD kernel mixture.
By the way, maybe other BSD-style ports (NetBSD, OpenBSD) should be
setting DIR_HAS_BSD_GROUP_SEMANTICS to get this fix, too[*]? Then the
release notes could look something like this:
Signed-off-by: Jonathan Nieder <redacted>
---
Documentation/RelNotes/1.7.7.1.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git i/Documentation/RelNotes/1.7.7.1.txt w/Documentation/RelNotes/1.7.7.1.txt
index fecfac8a..e3c29ff0 100644
--- i/Documentation/RelNotes/1.7.7.1.txt
+++ w/Documentation/RelNotes/1.7.7.1.txt
@@ -5,8 +5,9 @@ Fixes since v1.7.7
------------------
* On some BSD systems, adding +s bit on directories is detrimental
- (it is not necessary on BSD to begin with). The installation
- procedure has been updated to take this into account.
+ (it is not necessary on BSD to begin with). "git init --shared"
+ has been updated to take this into account without extra makefile
+ settings on platforms the Makefile knows about.
* After incorrectly written third-party tools store a tag object in
HEAD, git diagnosed it as a repository corruption and refused to--