Ronnie Sahlberg wrote:

> Add a new flag REF_ISPACKONLY that we can use in ref_transaction_delete.
> This flag indicates that the ref does not exist as a loose ref andf only as
> a packed ref. If this is the case we then change the commit code so that
> we skip taking out a lock file and we skip calling delete_ref_loose.

This seems wrong.  Can't someone else create a loose ref which will
shadow the packed ref and break the serializability of updates to this

The above doesn't explain why we want to avoid locking the loose ref,
but I assume it's for the sake of the "git branch -m foo/bar foo"
case.  For that case, wouldn't the following sequence of filesystem
operations work?

        - create $GIT_DIR/refs/heads/foo/bar.lock
        - create $GIT_DIR/refs/heads/foo.lock
        - if $GIT_DIR/refs/heads/foo/bar exists, add the ref to
          packed-refs (using the usual lockfile-update mechanism)
          and unlink $GIT_DIR/refs/heads/foo/bar
        - verify that current foo and foo/bar state are okay.  If
          not, roll back.
        - unlink $GIT_DIR/refs/heads/foo/bar.lock
        - rmdir $GIT_DIR/refs/heads/foo
        - rename $GIT_DIR/refs/heads/foo.lock into place


        - create $GIT_DIR/refs/heads/foo/bar.lock
        - create $GIT_DIR/refs/heads/foo.lock
        - verify state of all relevant refs

        - update packed-refs to remove refs/heads/foo/bar and
          add refs/heads/foo

        - unlink $GIT_DIR/refs/heads/foo/bar
        - unlink $GIT_DIR/refs/heads/foo
        - unlink $GIT_DIR/refs/heads/foo/bar.lock
        - unlink $GIT_DIR/refs/heads/foo.lock

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to