Elijah Newren <newren@xxxxxxxxx> writes: >> Since we will always write out a new tree object in addition to the blob >> (and if the blob did not exist in the database yet, we can be certain >> that the tree object did not exist yet), the merge will _still_ fail at >> that point, but it does unnecessary work by continuing after the blob >> could not be written. > > I don't think this is quite true. I've had a number of users come to > me with "messed up git repositories" where I eventually discover that > users just randomly add "sudo" to some of their commands because when > things don't work, sometimes "sudo" fixes it. That means they've > created stuff in their .git directory which may be owned by root, > perhaps even some of the .git/objects/XX directories. However, they > may have other .git/objects/XX directories owned by their normal user. > > If just some .git/objects/XX directories are owned by root and not > others, then it may be when users run git commands as themselves that > some things can be written to the object database but not others. In > particular, it could be that writing blob objects fail, but writing a > tree object which references those blobs succeeds. It is a good example scenario that argues even more strongly for this change. We may know the correct object contents and name for the top-level tree and even manage to write it out, after computing all the blobs and the trees contained within, some of which we may know the object name but have failed to write out. Letting such a breakage unnoticed would be, eh, bad. > Patch looks good to me, though. Yup, thanks for a review.
