All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bojun Chen <bojun.cbj@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Chen Bojun" <bojun.cbj@alibaba-inc.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Jiang Xin" <zhiyou.jx@alibaba-inc.com>,
	"Teng Long" <dyroneteng@gmail.com>
Subject: Re: [PATCH v2] receive-pack: purge temporary data if no command is ready to run
Date: Sat, 5 Feb 2022 15:17:32 +0800	[thread overview]
Message-ID: <CADuS7AoAbtbC3RKrXR=SGvfs7C-n57Y9zkaGne_XrfyJh46zXg@mail.gmail.com> (raw)
In-Reply-To: <xmqqczk6b3pt.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> 于2022年2月2日周三 06:51写道:
>
> Chen BoJun <bojun.cbj@gmail.com> writes:
>
> > From: Chen Bojun <bojun.cbj@alibaba-inc.com>
> >
> > When pushing a hidden ref, e.g.:
> >
> >     $ git push origin HEAD:refs/hidden/foo
> >
> > "receive-pack" will reject our request with an error message like this:
> >
> >     ! [remote rejected] HEAD -> refs/hidden/foo (deny updating a hidden ref)
> >
> > The remote side ("git-receive-pack") will not create the hidden ref as
> > expected, but the pack file sent by "git-send-pack" is left inside the
> > remote repository. I.e. the quarantine directory is not purged as it
> > should be.
>
> I was puzzled by the reference to "pushing a hidden ref" at the
> beginning of the proposed log message, as it wasn't quite clear that
> it was merely an easy-to-reproduce recipe to fall into such a
> situation where all ref updates are rejected.
>

Thanks for the suggestion. Do I have to rewrite this commit message on the v3?

> But the code change makes the function leave before the object
> migration out of the quarantine when no ref updates are done for any
> reason, andit makes perfect sense.  The title reflects it very well.
>
> > Add a checkpoint before calling "tmp_objdir_migrate()" and after calling
> > the "pre-receive" hook to purge that temporary data in the quarantine
> > area when there is no command ready to run.
>
> OK.
>
> I wondered how this should interact with the "proc_receive_ref"
> stuff, but existing code makes proc_receive_ref ignored when
> pre-receive rejects, so doing the same would be OK.
>
> > index 9f4a0b816c..a0b193ab3f 100644
> > --- a/builtin/receive-pack.c
> > +++ b/builtin/receive-pack.c
> > @@ -1971,6 +1971,15 @@ static void execute_commands(struct command *commands,
> >               return;
> >       }
>
> With the new logic, "return;" we see above becomes unnecessary.  I
> wonder if it is a good idea to keep it or remove it.
>
> > +     /*
> > +      * If there is no command ready to run, should return directly to destroy
> > +      * temporary data in the quarantine area.
> > +      */
> > +     for (cmd = commands; cmd && cmd->error_string; cmd = cmd->next)
> > +             ; /* nothing */
> > +     if (!cmd)
> > +             return;
> > +
> >       /*
> >        * Now we'll start writing out refs, which means the objects need
> >        * to be in their final positions so that other processes can see them.
> > diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
> > index 2f04cf9a1c..da70c45857 100755
> > --- a/t/t5516-fetch-push.sh
> > +++ b/t/t5516-fetch-push.sh
> > @@ -1809,4 +1809,12 @@ test_expect_success 'refuse fetch to current branch of bare repository worktree'
> >       git -C bare.git fetch -u .. HEAD:wt
> >  '
> >
> > +test_expect_success 'refuse to push a hidden ref, and make sure do not pollute the repository' '
> > +     mk_empty testrepo &&
> > +     git -C testrepo config receive.hiderefs refs/hidden &&
> > +     git -C testrepo config receive.unpackLimit 1 &&
> > +     test_must_fail git push testrepo HEAD:refs/hidden/foo &&
> > +     test_dir_is_empty testrepo/.git/objects/pack
> > +'
> > +
> >  test_done

Thanks for your thorough comments. It's really helpful.

  parent reply	other threads:[~2022-02-05  7:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24  1:26 [PATCH] receive-pack: purge temporary data if no command is ready to run BoJun via GitGitGadget
2022-01-24 15:17 ` Ævar Arnfjörð Bjarmason
2022-01-25 16:34   ` Lertz Chen
2022-01-24 23:32 ` Junio C Hamano
2022-01-25 16:49   ` Bojun Chen
2022-01-25  0:22 ` Jiang Xin
2022-01-29  6:35 ` [PATCH v2] " Chen BoJun
2022-02-01 22:51   ` Junio C Hamano
2022-02-01 23:27     ` Junio C Hamano
2022-02-05  7:17     ` Bojun Chen [this message]
2022-02-05  8:04       ` Junio C Hamano
2022-02-07  3:36       ` Jiang Xin
2022-02-07  8:02         ` Bojun Chen
2022-02-04  1:17   ` Junio C Hamano
2022-02-05  7:19     ` Bojun Chen
2022-02-05  8:02       ` Junio C Hamano
2022-02-07  7:57 ` [PATCH v3 0/1] " Chen BoJun
2022-02-07  7:57   ` [PATCH v3 1/1] receive-pack: " Chen BoJun

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='CADuS7AoAbtbC3RKrXR=SGvfs7C-n57Y9zkaGne_XrfyJh46zXg@mail.gmail.com' \
    --to=bojun.cbj@gmail.com \
    --cc=avarab@gmail.com \
    --cc=bojun.cbj@alibaba-inc.com \
    --cc=dyroneteng@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=zhiyou.jx@alibaba-inc.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.