Thread (1 message) 1 message, 1 author, 2016-06-15

Re: auto packing with simultaneous pushes: "error: Could not stat 'objects/[…]/[…]'"

From: Ivan D Vasin <hidden>
Date: 2016-06-15 22:55:52

On Wed, Jan 23, 2013 at 7:28 PM, Junio C Hamano [off-list ref] wrote:
Ivan D Vasin [off-list ref] writes:
quoted
my suggestion is that an auto pack should lock the repository,
preventing at least other auto packs (and perhaps other operations)
...

``git fsck`` is successful on both of our repos and on the bare repo
to which we pushed.
Successful after you pushed, or before you pushed, or both?
both
I suspect both.

I do not think such a lock is necessary for correctness of the
operation, but running two auto packing sumultaneously is wasteful,
so it would help performance.  But that would produce a larger
problem.  What if your modified auto-packer takes a lock and then
dies without relinquishing the lock?  The repository will never be
repacked after such an event forever?
perhaps the lock could contain the PID of the auto pack process.  if
that PID has gone away, the lock is ignored and replaced with a new
one.

that's what comes to my mind.  of course, there could be other ways to
handle this that i'm not thinking of.

in any case, the error messages, though spurious, are alarming to the
uninformed user.  it looks like Git is saying that there is actual
data loss, where in fact there is none.  if Git doesn't prevent these
messages from appearing (via locking behavior or otherwise), then it
should at least annotate them with a message that describes their
possibly spurious nature and perhaps instructs the user to verify
everything with ``git fsck``.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help