git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pang Yan Han <pangyanhan@gmail.com>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Jeff King <peff@peff.net>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
Date: Sun, 25 Sep 2011 17:48:22 +0800	[thread overview]
Message-ID: <20110925094822.GA1702@myhost> (raw)
In-Reply-To: <CAMK1S_hadzaqixaW3Fx81pf=hVsvAMpVvVGqVtZ8ncfUsie_9w@mail.gmail.com>

On Sun, Sep 25, 2011 at 01:28:31PM +0530, Sitaram Chamarty wrote:
> On Sun, Sep 25, 2011 at 10:36 AM, Pang Yan Han <pangyanhan@gmail.com> wrote:
> > Hi list,
> >
> > Currently, receive-pack runs the pre-receive, update, post-receive and
> > post-update hooks during a push to delete corrupt or non-existent refs, eg:
> >
> >        git push origin :refs/heads/foo
> >
> > where refs/heads/foo is missing from the remote origin.
> >
> > The issue is reported here [1]
> 
> I did not report an issue.  I asked if this was expected and could be
> relied upon.  I'm actually happy with the current behaviour because it
> solves a problem very neatly for me, but before documenting it I
> wanted to make sure it would not one day disappear.
> 
> > This is a patch series which teaches receive-pack not to run update hook for
> > corrupt or non existent refs during a push.
> >
> > Patch 1/2 isn't really relevant to the topic. It's just something I stumbled
> > across while reading the code. It removes a redundant assignment in the is_url
> > function.
> >
> > Patch 2/2 teaches receive-pack not to run update hook for corrupt or non
> > existent refs. In summary, I reordered the statements in the update function
> > so that the update hook is not run for corrupt / non existent refs.
> >
> > Perhaps this isn't a good enough solution since the pre-receive, post-receive
> > and post-update hooks are still run. Also the tests aren't exactly good looking.
> 
> It doesn't make sense to disable only the update hook.  And although I
> did not come right out and say it, it is the post-update that I care
> about.  If that still runs, my "issue" still exists.

Um I'm rather new to Git and the reason why I didn't reply this initially was
because I didn't know what to reply. Sorry but you sound rather aggressive and
I was really taken aback by this.

I've taken a look at the code again and here's another approach which will
result in heavier changes to builtin/receive-pack and may possibly work:

Check through the list of refs to be updated before even executing the
pre receive hook. Ensure that there is at least one "valid" ref update.
Essentially this is kind of like "dry running" the update function.

One way to do it is to shift the bulk of work determining valid and invalid
ref updates from the update function to a separate function.
We maintain 2 lists, one to store valid refs to be updated and another to
store non-existent/corrupt refs which will be deleted. Specifically, we will
be storing 'struct command'.

The update function can be cut down to these parts:
- determining namespaced_name
- lock_any_ref_for_update
- write_ref_sha1

The pre receive hook will only be executed if the list containing valid ref
pushes is non-empty. Same goes for the post receive and post update hooks.

What do you think of this approach (if it's even correct)?

> 
> > Any advice is highly appreciated. Thanks!
> >
> > [1] http://thread.gmane.org/gmane.comp.version-control.git/181942
> >
> > Pang Yan Han (2):
> >  is_url: Remove redundant assignment
> >  receive-pack: Don't run update hook for corrupt or nonexistent ref
> >
> >  builtin/receive-pack.c |   50 +++++++++++++++++++++++++++--------------------
> >  t/t5516-fetch-push.sh  |   33 +++++++++++++++++++++++++++++++
> >  url.c                  |    1 -
> >  3 files changed, 62 insertions(+), 22 deletions(-)
> >
> > --
> > 1.7.7.rc3.2.g29f2e6
> >
> >
> 
> 
> 
> -- 
> Sitaram

  reply	other threads:[~2011-09-25  9:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-25  5:06 [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref Pang Yan Han
2011-09-25  5:06 ` [PATCH/RFC 1/2] is_url: Remove redundant assignment Pang Yan Han
2011-09-25  9:26   ` Tay Ray Chuan
2011-09-26 16:52     ` Junio C Hamano
2011-09-26 21:32       ` Jeff King
2011-09-25  5:06 ` [PATCH/RFC 2/2] receive-pack: Don't run update hook for corrupt or nonexistent ref Pang Yan Han
2011-09-25 17:37   ` [PATCH/RFCv2 2/2] run post-receive and post-update hooks with empty stdin/no args for invalid ref deletion Pang Yan Han
2011-09-25  7:58 ` [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref Sitaram Chamarty
2011-09-25  9:48   ` Pang Yan Han [this message]
2011-09-25 12:05     ` Sitaram Chamarty
2011-09-26 23:23       ` Junio C Hamano
2011-09-26 23:44         ` Sitaram Chamarty
2011-09-26 23:49           ` Junio C Hamano
2011-09-27  0:04             ` Junio C Hamano
2011-09-27  9:02               ` Pang Yan Han
2011-09-27 16:56                 ` Junio C Hamano
2011-09-27 22:55                   ` Pang Yan Han
2011-09-27  0:05             ` Sitaram Chamarty

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=20110925094822.GA1702@myhost \
    --to=pangyanhan@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=sitaramc@gmail.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).