Junio C Hamano <gitster@xxxxxxxxx> writes:
> A bit safer way to organize might be to first create a list of the
> refs to be removed in-core, update packed-refs without these refs to
> be removed, and then finally remove the loose ones, but I haven't
> thought things through.
Perhaps a removal of remote can go in this order to be resistant
against an abort-in-the-middle.
* update packed-refs without the refs that came from the remote.
- when interrupted before the new temporary file is renamed to
the final, it would be a no-op.
- when interrupted after the rename, only some refs that came
from the remote may disappear.
* remove the loose refs that came from the remote.
* finally, remove the configuration related to the remote.
This order would let you interrupt "remote rm" without leaving the
repository in a broken state. Before the final state, it may appear
that you have some but not all remote-tracking refs from the remote
in your repository, but you would not have any ref that point at an
obsolete object. Running "remote rm" again, once it finishes, will
give you the desired result.
A longer-term goal might be to have ref-transaction infrastructure
clever enough to coalesce the "repack-without-these-refs" requests
into one automatically without forcing the callers you are fixing
care about these things, though. And such a transaction semantics
may have to also cover the updating of configuration files.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html