From: "Shawn O. Pearce" <spearce@spearce•org>
To: Junio C Hamano <gitster@pobox•com>
Cc: Daniel Barkalow <barkalow@iabervon•org>,
Andy Parkins <andyparkins@gmail•com>,
Git Mailing List <git@vger•kernel.org>
Subject: Re: bug: update hook failure doesn't prevent local deletion of a branch
Date: Fri, 27 Jul 2007 00:26:06 -0400 [thread overview]
Message-ID: <20070727042606.GE20052@spearce.org> (raw)
In-Reply-To: <7vk5sm5vrd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox•com> wrote:
> Andy Parkins <andyparkins@gmail•com> writes:
> > Summary: when using git-push to delete a remote branch, and that deletion is
> > disallowed by the update hook, the local tracking branch _is_ deleted.
>
> Yes, a few months ago with b516968f, "send-pack" started to
> pretend that it turned around and fetched immediately after it
> attempted to push.
>
> There are two problems with it. One is this exact problem Andy
> reported.
...
> I think this is correctable without major changes.
> If the remote end refused to update only one of the refs, and
> send-pack as a whole fails, we could refrain from updating
> anything local.
Reasonable. Probably pretty simple too.
> But another more fundamental issue is that post-update hook on
> the receiving end could do anything it pleases (for example, it
> could try to rebase what was pushed), and at the protocol level
> there is no way to say "you tried to push this SHA-1 but we
> replaced it with this other SHA-1 instead".
You keep raising this argument against the "git-push updates local
refs" feature. Its not just the post-update hook that could alter
the ref. Another user could just push behind you (and I mean right
behind you) and either force an update, delete the ref entirely, or
just fast-forward it. (Its entirely possible that the other user
does have the commit you just pushed, because you had previously
supplied it to them.) So its actually possible for the ref to have
changed again before you even see the successful update message on
your console.
I don't think it really matters. Based on the output you see from
git-push on screen you have good reason to believe that the ref
you just pushed to is now at the commit SHA-1 displayed. For that
reason alone I think it is correct to update the corresponding
tracking branch, because an immediate git-fetch just wastes the
user's time and will (usually) fetch the SHA-1 just pushed.
We should make our repository state reflect the user's internal
mental view of what just happened, especially here, because the
user's mental view is probably correct.
--
Shawn.
next prev parent reply other threads:[~2007-07-27 4:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-25 11:50 bug: update hook failure doesn't prevent local deletion of a branch Andy Parkins
2007-07-27 4:13 ` Junio C Hamano
2007-07-27 4:26 ` Shawn O. Pearce [this message]
2007-07-27 5:00 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070727042606.GE20052@spearce.org \
--to=spearce@spearce$(echo .)org \
--cc=andyparkins@gmail$(echo .)com \
--cc=barkalow@iabervon$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox