Elijah Newren [off-list ref] writes:
quoted
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.