# Another problem with not existing directories 5 messages from 2005-10-31 to 2005-10-31. Participants: Marcel Holtmann, Linus Torvalds, Junio C Hamano. Thread: https://gitlist.dev/t/2282 ## Marcel Holtmann, 2005-10-31 17:20 Subject: Another problem with not existing directories Message-ID: <1130779234.5848.15.camel@blade> URL: https://gitlist.dev/e/1130779234.5848.15.camel%40blade ``` Hi guys, I think there exists another problem with git-unpack-objects if the sub-directory in "objects" doesn't exists. # cg-push master updating 'refs/heads/master' from 581c1b14394aee60aff46ea67d05483261ed6527 to 197c190b0b00689074c03fc3ebcfa114dbed1d73 Packing 37 objects Unpacking 37 objects unable to write sha1 filename ./objects/dc/59cd72edc7bc6169c2c9c073c86483f9318e7c: No such file or directoryfatal: failed to write object fatal: git-unpack-objects exited with error code 128 In this case the directory "objects/dc" doesn't exists. Creating it fixes the problem, but I think they should be created on demand. Regards Marcel ``` ## Linus Torvalds, 2005-10-31 17:35 Subject: Re: Another problem with not existing directories Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0510310929361.27915%40g5.osdl.org In-Reply-To: <1130779234.5848.15.camel@blade> ``` On Mon, 31 Oct 2005, Marcel Holtmann wrote: > > I think there exists another problem with git-unpack-objects if the > sub-directory in "objects" doesn't exists. Are you sure you just don't have an old version of git on the other end? As far as I know, git-unpack-objects will use the bog-standard "write_sha1_file()" which already knows how to create missing subdirectories. This _sounds_ like the other end has two different versions of git, and when you "push" to it, it executes an old version, but then you have a newer version somewhere that created the sparsely-populated object directory in the first place. This happens (for example) if you have installed an older version of git through an rpm (say, the one that comes from Fedora Core: 0.99.8) and you have that in /usr/bin, but then you have a newer version that you've built and installed yourself in your ~/bin/ directory. If you have your PATH being set in your .bashrc, it won't trigger with a non-interactive login, so you'll use the /usr/bin/ version when pushing, but then when you log in interactively to a shell, you'll use the ~/bin one (or the other way around, I'm easily confused by the bash config file rules ;) Linus ``` ## Marcel Holtmann, 2005-10-31 17:46 Subject: Re: Another problem with not existing directories Message-ID: <1130780772.5848.32.camel@blade> URL: https://gitlist.dev/e/1130780772.5848.32.camel%40blade In-Reply-To: ``` Hi Linus, > > I think there exists another problem with git-unpack-objects if the > > sub-directory in "objects" doesn't exists. > > Are you sure you just don't have an old version of git on the other end? this might be possible, but then it is an old git on kernel.org. I never installed any git by myself on it. Regards Marcel ``` ## Junio C Hamano, 2005-10-31 18:43 Subject: Re: Another problem with not existing directories Message-ID: <7vk6ftil38.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vk6ftil38.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <1130780772.5848.32.camel@blade> ``` Marcel Holtmann writes: >> Are you sure you just don't have an old version of git on the other end? > > this might be possible, but then it is an old git on kernel.org. I never > installed any git by myself on it. I just tried this myself; master.kernel.org seems to have 0.99.8f in /usr/bin/, which explains this symptom. ``` ## Marcel Holtmann, 2005-10-31 21:38 Subject: Re: Another problem with not existing directories Message-ID: <1130794710.31561.3.camel@blade> URL: https://gitlist.dev/e/1130794710.31561.3.camel%40blade In-Reply-To: <7vk6ftil38.fsf@assigned-by-dhcp.cox.net> ``` Hi Junio, > >> Are you sure you just don't have an old version of git on the other end? > > > > this might be possible, but then it is an old git on kernel.org. I never > > installed any git by myself on it. > > I just tried this myself; master.kernel.org seems to have > 0.99.8f in /usr/bin/, which explains this symptom. so as soon as kernel.org switches to 0.99.9 everything should be fine again. That's great. Regards Marcel ```