Florent Thoumie <flz@xbsd.org> writes:
> I'm having some weird issues with git-push lately (1.4.1 on both ends):
Bear with some basic questions.
- "lately" means this used to work with earlier git on the same
machine with same configurations?
- the three runs seem to be pushing the same ref to the same
repository. Did you want to illustrate that it fails upon
writing out different objects and eventually succeeds?
- what operating system and what filesystem?
- are you working with a shared repository?
Show 15 quoted lines
> : flz@cream:/tinderbox/portstrees/xorg-modular/ports; git push
> updating 'refs/heads/xorg'
> from 6d1e4fce0a22da799175ec8e168dc0767f1131ef
> to 496cbd4c75220c204aac4fd1ef9912e40e0314b2
> Generating pack...
> Done counting 16 objects.
> Result has 11 objects.
> Deltifying 11 objects.
> 100% (11/11) done
> Total 11, written 11 (delta 4), reused 0 (delta 0)
> Unpacking 11 objects
> unpack unpacker exited with error code
> ng refs/heads/xorg n/a (unpacker error)
> unable to write sha1 filename ./objects/2d: Is a directory
> fatal: failed to write object
This message comes from sha1_file.c::move_temp_to_file(). The unpacker wrote the object whose name begins with 2d in a temporary file .git/obj_XXXXXX by calling write_sha1_file(), which in turn calls move_temp_to_file() to move it to its final destination ".git/objects/2d/XXXXXX".
move_temp_to_file() first tries to make a hardlink in .git/objects/2d/ directory, assuming that most of the time you already have it. If it succeeds, then it runs unlink() on the temporary file ".git/obj_XXXXXX". But taht is not what is happening.
link_temp_to_file() function first tries to make a hardlink with link(".git/obj_XXXXXX", ".git/objects/2d/XXXXXX"). This call must be failing for you. Then it tries to create the leading directory ".git/objects/2d", and does adjust_shared_perm and when it fails it returns (but forgets to restore the slash it removed earlier -- a patch to fix this is attached at the end).
This explains why the final filename is truncated at the last slash, hence ./objects/2d in the error message. Also it explains why repeated tries would succeed; the first run creates .git/objects/2d/ directory so the second run will try hardlink and will succeed.
So the next thing to see is why adjust_shared_perm() is failing for you.
Oops.
I think this function is broken at the concept level. This is to work around people's broken umask (when you are working with other people, your umask should not be stronger than 007) and tries to flip group writability bit on.
First of all, if the necessary bits are already on, it is not necessary to run chmod(), but more importantly, if the directory in question was created by somebody else, I do not think this chmod() would succeed even if you are in the same group as the owner (i.e. previous creator) of the directory.
[jc: I am CC'ing Johannes to blame him on commit 457f06d6; git-pickaxe is turning out to be quite handy ;-)
git pickaxe -C -f L246,277 v1.4.1 -- path.c
]
A quick workaround until we sort this out would be:
- make sure all your developers have umask suitable for group
work (i.e. second octal-digit from the right should be zero
to give group members the same rights as you do).
- run "chmod g+w .git/objects/??" in the shared repository.
-- >8 --
diff --git a/sha1_file.c b/sha1_file.c
index e89d24c..5707069 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1400,8 +1400,10 @@ static int link_temp_to_file(const char
if (dir) {
*dir = 0;
mkdir(filename, 0777);
- if (adjust_shared_perm(filename))
+ if (adjust_shared_perm(filename)) {
+ *dir = '/';
return -2;
+ }
*dir = '/';
if (!link(tmpfile, filename))
return 0;
Florent Thoumie
