user/sven/git.git/path.c, branch v1.5.6.4

Fix backwards-incompatible handling of core.sharedRepository

2008-07-12T03:38:30Z

06cbe85 (Make core.sharedRepository more generic, 2008-04-16) broke the traditional setting of core.sharedRepository to true, which was to make the repository group writable: with umask 022, it would clear the permission bits for 'other'. (umask 002 did not exhibit this behaviour since pre-chmod() check in adjust_shared_perm() fails in that case.) The call to adjust_shared_perm() should only loosen the permission. If the user has umask like 022 or 002 that allow others to read, the resulting files should be made readable and writable by group, without restricting the readability by others. This patch fixes the adjust_shared_perm() mode tweak based on Junio's suggestion and adds the appropriate tests to t/t1301-shared-repo.sh. Cc: Heikki Orsila Signed-off-by: Petr Baudis Signed-off-by: Junio C Hamano

Make git_dir a path relative to work_tree in setup_work_tree()

2008-06-19T23:44:21Z

Once we find the absolute paths for git_dir and work_tree, we can make git_dir a relative path since we know pwd will be work_tree. This should save the kernel some time traversing the path to work_tree all the time if git_dir is inside work_tree. Daniel's patch didn't apply for me as-is, so I recreated it with some differences, and here are the numbers from ten runs each. There is some IO for me - probably due to more-or-less random flushing of the journal - so the variation is bigger than I'd like, but whatever: Before: real 0m8.135s real 0m7.933s real 0m8.080s real 0m7.954s real 0m7.949s real 0m8.112s real 0m7.934s real 0m8.059s real 0m7.979s real 0m8.038s After: real 0m7.685s real 0m7.968s real 0m7.703s real 0m7.850s real 0m7.995s real 0m7.817s real 0m7.963s real 0m7.955s real 0m7.848s real 0m7.969s Now, going by "best of ten" (on the assumption that the longer numbers are all due to IO), I'm saying a 7.933s -> 7.685s reduction, and it does seem to be outside of the noise (ie the "after" case never broke 8s, while the "before" case did so half the time). So looks like about 3% to me. Doing it for a slightly smaller test-case (just the "arch" subdirectory) gets more stable numbers probably due to not filling the journal with metadata updates, so we have: Before: real 0m1.633s real 0m1.633s real 0m1.633s real 0m1.632s real 0m1.632s real 0m1.630s real 0m1.634s real 0m1.631s real 0m1.632s real 0m1.632s After: real 0m1.610s real 0m1.609s real 0m1.610s real 0m1.608s real 0m1.607s real 0m1.610s real 0m1.609s real 0m1.611s real 0m1.608s real 0m1.611s where I'ld just take the averages and say 1.632 vs 1.610, which is just over 1% peformance improvement. So it's not in the noise, but it's not as big as I initially thought and measured. (That said, it obviously depends on how deep the working directory path is too, and whether it is behind NFS or something else that might need to cause more work to look up). Signed-off-by: Junio C Hamano

make_nonrelative_path: Use is_absolute_path()

2008-06-08T17:48:01Z

This helps porting to Windows. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

Use nonrelative paths instead of absolute paths for cloned repositories

2008-06-06T18:23:10Z

Particularly for the "alternates" file, if one will be created, we want a path that doesn't depend on the current directory, but we want to retain any symlinks in the path as given and any in the user's view of the current directory when the path was given. Signed-off-by: Daniel Barkalow Signed-off-by: Junio C Hamano

Make read_in_full() and write_in_full() consistent with xread() and xwrite()

2008-04-30T06:11:57Z

xread() and xwrite() return ssize_t values as their native POSIX counterparts read(2) and write(2). To be consistent, read_in_full() and write_in_full() should also return ssize_t values. Signed-off-by: Junio C Hamano

Make core.sharedRepository more generic

2008-04-17T01:23:54Z

git init --shared=0xxx, where '0xxx' is an octal number, will create a repository with file modes set to '0xxx'. Users with a safe umask value (0077) can use this option to force file modes. For example, '0640' is a group-readable but not group-writable regardless of user's umask value. Values compatible with old Git versions are written as they were before, for compatibility reasons. That is, "1" for "group" and "2" for "everybody". "git config core.sharedRepository 0xxx" is also handled. Signed-off-by: Heikki Orsila Signed-off-by: Junio C Hamano

Do not use GUID on dir in git init --shared=all on FreeBSD

2008-03-05T20:22:26Z

It does not allow changing the bit to a non-root user. This fixes t1301-shared-repo.sh on the platform. Signed-off-by: Alex Riesen Signed-off-by: Junio C Hamano

Fix make_absolute_path() for parameters without a slash

2008-03-02T09:58:31Z

When passing "xyz" to make_absolute_path(), make_absolute_path() erroneously tried to chdir("xyz"), and then append "/xyz". Instead, skip the chdir() completely when no slash was found. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Add is_absolute_path() and make_absolute_path()

2007-08-01T07:38:30Z

This patch adds convenience functions to work with absolute paths. The function is_absolute_path() should help the efforts to integrate the MinGW fork. Note that make_absolute_path() returns a pointer to a static buffer. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

git_mkstemp(): be careful not to overflow the path buffer.

2007-07-26T04:34:53Z

If user's TMPDIR is insanely long, return negative after setting errno to ENAMETOOLONG, pretending that the underlying mkstemp() choked on a temporary file path that is too long. Signed-off-by: Junio C Hamano