[RFC] push: allow delete one level ref #1465
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adlternative
force-pushed
the
zh/delete-one-level-ref
branch
from
adf375e
to
605b95b
Compare
adlternative
changed the title
|
/submit |
|
Submitted as pull.1465.git.1673951562.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
| @@ -1463,8 +1463,11 @@ static const char *update(struct command *cmd, struct shallow_info *si) | |||
| find_shared_symref(worktrees, "HEAD", name); | |||
There was a problem hiding this comment.
On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):
On Tue, Jan 17 2023, ZheNing Hu via GitGitGadget wrote:
> From: ZheNing Hu <adlternative@gmail.com>
>
> Git will reject the deletion of one level refs e,g. "refs/foo"
> through "git push -d", however, some users want to be able to
> clean up these branches that were created unexpectedly on the
> remote.
>
> Therefore, when updating branches on the server with
> "git receive-pack", by checking whether it is a branch deletion
> operation, it will determine whether to allow the update of
> one level refs. This avoids creating/updating such one level
> branches, but allows them to be deleted.
>
> On the client side, "git push" also does not properly fill in
> the old-oid of one level refs, which causes the server-side
> "git receive-pack" to think that the ref's old-oid has changed
> when deleting one level refs, this causes the push to be rejected.
>
> So the solution is to fix the client to be able to delete
> one level refs by properly filling old-oid.
>
> Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> ---
> builtin/receive-pack.c | 5 ++++-
> connect.c | 2 +-
> t/t5516-fetch-push.sh | 13 +++++++++++++
> 3 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 13ff9fae3ba..ad21877ea1b 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -1463,7 +1463,10 @@ static const char *update(struct command *cmd, struct shallow_info *si)
> find_shared_symref(worktrees, "HEAD", name);
>
> /* only refs/... are allowed */
> - if (!starts_with(name, "refs/") || check_refname_format(name + 5, 0)) {
> + if (!starts_with(name, "refs/") ||
> + check_refname_format(name + 5,
> + is_null_oid(new_oid) ?
> + REFNAME_ALLOW_ONELEVEL : 0)) {
Style nit: We tend to wrap at 79 characters, adn with argument lists you
"keep going" until you hit that limit.
In this case strictly following that rule will lead to funny
indentation, as we'll have to wrap at "is_null_oid(...)" etc.
But even when avoiding that (which seems good in this case) this should
be:
if (!starts_with(name, "refs/") ||
check_refname_format(name + 5, is_null_oid(new_oid) ?
REFNAME_ALLOW_ONELEVEL : 0)) {
> rp_error("refusing to update funny ref '%s' remotely", name);
> ret = "funny refname";
> goto out;
> diff --git a/connect.c b/connect.c
> index 63e59641c0d..b841ae58e03 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -30,7 +30,7 @@ static int check_ref(const char *name, unsigned int flags)
> return 0;
>
> /* REF_NORMAL means that we don't want the magic fake tag refs */
> - if ((flags & REF_NORMAL) && check_refname_format(name, 0))
> + if ((flags & REF_NORMAL) && check_refname_format(name, REFNAME_ALLOW_ONELEVEL))
Here we should wrap after "name,", we end up with a too-long line.
> return 0;
>
> /* REF_HEADS means that we want regular branch heads */
> diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
> index f37861efc40..dec8950a392 100755
> --- a/t/t5516-fetch-push.sh
> +++ b/t/t5516-fetch-push.sh
> @@ -903,6 +903,19 @@ test_expect_success 'push --delete refuses empty string' '
> test_must_fail git push testrepo --delete ""
> '
>
> +test_expect_success 'push --delete onelevel refspecs' '
> + mk_test testrepo heads/main &&
> + (
> + cd testrepo &&
> + git update-ref refs/onelevel refs/heads/main
> + ) &&
Avoid the subshell here with:
git -C update-ref ....
> + git push testrepo --delete refs/onelevel &&
> + (
> + cd testrepo &&
> + test_must_fail git rev-parse --verify refs/onelevel
Ditto.There was a problem hiding this comment.
On the Git mailing list, ZheNing Hu wrote (reply to this):
Ævar Arnfjörð Bjarmason <avarab@gmail.com> 于2023年1月17日周二 21:18写道：
>
>
> On Tue, Jan 17 2023, ZheNing Hu via GitGitGadget wrote:
>
> > From: ZheNing Hu <adlternative@gmail.com>
> >
> > Git will reject the deletion of one level refs e,g. "refs/foo"
> > through "git push -d", however, some users want to be able to
> > clean up these branches that were created unexpectedly on the
> > remote.
> >
> > Therefore, when updating branches on the server with
> > "git receive-pack", by checking whether it is a branch deletion
> > operation, it will determine whether to allow the update of
> > one level refs. This avoids creating/updating such one level
> > branches, but allows them to be deleted.
> >
> > On the client side, "git push" also does not properly fill in
> > the old-oid of one level refs, which causes the server-side
> > "git receive-pack" to think that the ref's old-oid has changed
> > when deleting one level refs, this causes the push to be rejected.
> >
> > So the solution is to fix the client to be able to delete
> > one level refs by properly filling old-oid.
> >
> > Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> > ---
> > builtin/receive-pack.c | 5 ++++-
> > connect.c | 2 +-
> > t/t5516-fetch-push.sh | 13 +++++++++++++
> > 3 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > index 13ff9fae3ba..ad21877ea1b 100644
> > --- a/builtin/receive-pack.c
> > +++ b/builtin/receive-pack.c
> > @@ -1463,7 +1463,10 @@ static const char *update(struct command *cmd, struct shallow_info *si)
> > find_shared_symref(worktrees, "HEAD", name);
> >
> > /* only refs/... are allowed */
> > - if (!starts_with(name, "refs/") || check_refname_format(name + 5, 0)) {
> > + if (!starts_with(name, "refs/") ||
> > + check_refname_format(name + 5,
> > + is_null_oid(new_oid) ?
> > + REFNAME_ALLOW_ONELEVEL : 0)) {
>
> Style nit: We tend to wrap at 79 characters, adn with argument lists you
> "keep going" until you hit that limit.
>
> In this case strictly following that rule will lead to funny
> indentation, as we'll have to wrap at "is_null_oid(...)" etc.
>
> But even when avoiding that (which seems good in this case) this should
> be:
>
> if (!starts_with(name, "refs/") ||
> check_refname_format(name + 5, is_null_oid(new_oid) ?
> REFNAME_ALLOW_ONELEVEL : 0)) {
>
>
Make sense, I'm going to fix the formatting here.
>
> > rp_error("refusing to update funny ref '%s' remotely", name);
> > ret = "funny refname";
> > goto out;
> > diff --git a/connect.c b/connect.c
> > index 63e59641c0d..b841ae58e03 100644
> > --- a/connect.c
> > +++ b/connect.c
> > @@ -30,7 +30,7 @@ static int check_ref(const char *name, unsigned int flags)
> > return 0;
> >
> > /* REF_NORMAL means that we don't want the magic fake tag refs */
> > - if ((flags & REF_NORMAL) && check_refname_format(name, 0))
> > + if ((flags & REF_NORMAL) && check_refname_format(name, REFNAME_ALLOW_ONELEVEL))
>
> Here we should wrap after "name,", we end up with a too-long line.
>
To be honest, sometimes it's hard to notice if the current line is longer
than 79 characters, it's often a matter of intuition. Is there any ci script
that can detect this kind of problem?
> > return 0;
> >
> > /* REF_HEADS means that we want regular branch heads */
> > diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
> > index f37861efc40..dec8950a392 100755
> > --- a/t/t5516-fetch-push.sh
> > +++ b/t/t5516-fetch-push.sh
> > @@ -903,6 +903,19 @@ test_expect_success 'push --delete refuses empty string' '
> > test_must_fail git push testrepo --delete ""
> > '
> >
> > +test_expect_success 'push --delete onelevel refspecs' '
> > + mk_test testrepo heads/main &&
> > + (
> > + cd testrepo &&
> > + git update-ref refs/onelevel refs/heads/main
> > + ) &&
>
> Avoid the subshell here with:
>
> git -C update-ref ....
>
OK.
> > + git push testrepo --delete refs/onelevel &&
> > + (
> > + cd testrepo &&
> > + test_must_fail git rev-parse --verify refs/onelevel
>
> Ditto.
Thanks,
ZheNing Hu
adlternative
force-pushed
the
zh/delete-one-level-ref
branch
from
605b95b
to
966cb49
Compare
|
/submit |
|
Submitted as pull.1465.v2.git.1675529298.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
| @@ -1463,8 +1463,10 @@ static const char *update(struct command *cmd, struct shallow_info *si) | |||
| find_shared_symref(worktrees, "HEAD", name); | |||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 13ff9fae3ba..77088f5ba8d 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -1463,7 +1463,9 @@ static const char *update(struct command *cmd, struct shallow_info *si)
> find_shared_symref(worktrees, "HEAD", name);
>
> /* only refs/... are allowed */
> - if (!starts_with(name, "refs/") || check_refname_format(name + 5, 0)) {
> + if (!starts_with(name, "refs/") ||
> + check_refname_format(name + 5, is_null_oid(new_oid) ?
> + REFNAME_ALLOW_ONELEVEL : 0)) {
I am somehow smelling that this is about "refs/stash" and it may be
a good thing to allow removing a leftover refs/stash remotely. I am
not sure why we need to treat it differently while still blocking
update/modification.
Is it that we are actively discouraging one-level refs like
refs/stash, so removing is fine but once removed we do not allow
creating or updating? It somewhat smells a hard to explain rule to
the users, at least to me.
> diff --git a/connect.c b/connect.c
> index 63e59641c0d..7a396ad72e9 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -30,7 +30,8 @@ static int check_ref(const char *name, unsigned int flags)
> return 0;
>
> /* REF_NORMAL means that we don't want the magic fake tag refs */
> - if ((flags & REF_NORMAL) && check_refname_format(name, 0))
> + if ((flags & REF_NORMAL) && check_refname_format(name,
> + REFNAME_ALLOW_ONELEVEL))
> return 0;
This side of the change does make sense.
Thanks.There was a problem hiding this comment.
On the Git mailing list, ZheNing Hu wrote (reply to this):
Junio C Hamano <gitster@pobox.com> 于2023年2月7日周二 06:13写道：
>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > index 13ff9fae3ba..77088f5ba8d 100644
> > --- a/builtin/receive-pack.c
> > +++ b/builtin/receive-pack.c
> > @@ -1463,7 +1463,9 @@ static const char *update(struct command *cmd, struct shallow_info *si)
> > find_shared_symref(worktrees, "HEAD", name);
> >
> > /* only refs/... are allowed */
> > - if (!starts_with(name, "refs/") || check_refname_format(name + 5, 0)) {
> > + if (!starts_with(name, "refs/") ||
> > + check_refname_format(name + 5, is_null_oid(new_oid) ?
> > + REFNAME_ALLOW_ONELEVEL : 0)) {
>
> I am somehow smelling that this is about "refs/stash" and it may be
> a good thing to allow removing a leftover refs/stash remotely. I am
> not sure why we need to treat it differently while still blocking
> update/modification.
>
> Is it that we are actively discouraging one-level refs like
> refs/stash, so removing is fine but once removed we do not allow
> creating or updating? It somewhat smells a hard to explain rule to
> the users, at least to me.
>
As I mentioned before, the problem we encountered was that
the refs/master created unexpectedly cannot be deleted. Additionally,
some programs only search for references in the command space of
refs/heads/ or refs/tags/, so they may ignore one-level references
such as refs/master. Therefore, generally speaking, it's better not to
let users create/update special one-level references. This can be achieved
directly through git receive-pack or implemented by upper-layer
services in positions such as pre-receive-hook.
Certainly, I can remove the previous section as you requested.
> > diff --git a/connect.c b/connect.c
> > index 63e59641c0d..7a396ad72e9 100644
> > --- a/connect.c
> > +++ b/connect.c
> > @@ -30,7 +30,8 @@ static int check_ref(const char *name, unsigned int flags)
> > return 0;
> >
> > /* REF_NORMAL means that we don't want the magic fake tag refs */
> > - if ((flags & REF_NORMAL) && check_refname_format(name, 0))
> > + if ((flags & REF_NORMAL) && check_refname_format(name,
> > + REFNAME_ALLOW_ONELEVEL))
> > return 0;
>
> This side of the change does make sense.
>
> Thanks.
Thanks.There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
ZheNing Hu <adlternative@gmail.com> writes:
> ... Therefore, generally speaking, it's better not to let users
> create/update special one-level references.
The question was "Is it that we are actively discouraging one-level
refs like refs/stash, so removing is fine but once removed we do not
allow creating or updating?"
You could just have given a single word answer, Yes, then.
> Certainly, I can remove the previous section as you requested.
I didn't request to do anything to the change. I asked you to
explain why you allow only delete without create/update, and without
knowing why, I didn't have enough information to make such a request.
I think "we discourage a single-level refnames so allow deleting one
that may have been created by mistake, but do not allow creation or
deletion as before" does make sense. As long as that is explained
in the proposed log message and in the end-user facing documentation,
I am happy with the new behaviour.
Thanks.There was a problem hiding this comment.
On the Git mailing list, ZheNing Hu wrote (reply to this):
Junio C Hamano <gitster@pobox.com> 于2023年2月25日周六 01:12写道：
>
> ZheNing Hu <adlternative@gmail.com> writes:
>
> > ... Therefore, generally speaking, it's better not to let users
> > create/update special one-level references.
>
> The question was "Is it that we are actively discouraging one-level
> refs like refs/stash, so removing is fine but once removed we do not
> allow creating or updating?"
>
> You could just have given a single word answer, Yes, then.
>
> > Certainly, I can remove the previous section as you requested.
>
> I didn't request to do anything to the change. I asked you to
> explain why you allow only delete without create/update, and without
> knowing why, I didn't have enough information to make such a request.
>
> I think "we discourage a single-level refnames so allow deleting one
> that may have been created by mistake, but do not allow creation or
> deletion as before" does make sense. As long as that is explained
> in the proposed log message and in the end-user facing documentation,
> I am happy with the new behaviour.
>
I understand. I didn't mention the reason for not allowing the
creation/update of one-level refs in the commit message, I will add it later.
> Thanks.
adlternative
force-pushed
the
zh/delete-one-level-ref
branch
5 times, most recently
from
3e47092
to
4dc75f5
Compare
|
/submit |
|
Submitted as pull.1465.v3.git.1677463022.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
| @@ -1464,7 +1464,7 @@ static const char *update(struct command *cmd, struct shallow_info *si) | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: ZheNing Hu <adlternative@gmail.com>
>
> When the user deletes the remote one level branch through
> "git push origin -d refs/foo", remote will return an error:
> "refusing to create funny ref 'refs/foo' remotely", here we
> are not creating "refs/foo" instead wants to delete it, so a
> better error description here would be: "refusing to update
> funny ref 'refs/foo' remotely".
OK, update() works on each ref affected, not just the ones that are
updated, but also created and deleted. The updated wording may
probably be better.
>
> Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> ---
> builtin/receive-pack.c | 2 +-
> t/t5516-fetch-push.sh | 5 +++++
> 2 files changed, 6 insertions(+), 1 deletion(-)
> ...
> +test_expect_success 'push with onelevel ref' '
> + mk_test testrepo heads/main &&
> + test_must_fail git push testrepo HEAD:refs/onelevel
> +'
> +
I am not sure what relevance this new test has to the proposed
update to the message, though.
Thanks.There was a problem hiding this comment.
On the Git mailing list, ZheNing Hu wrote (reply to this):
Junio C Hamano <gitster@pobox.com> 于2023年2月28日周二 00:07写道：
>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: ZheNing Hu <adlternative@gmail.com>
> >
> > When the user deletes the remote one level branch through
> > "git push origin -d refs/foo", remote will return an error:
> > "refusing to create funny ref 'refs/foo' remotely", here we
> > are not creating "refs/foo" instead wants to delete it, so a
> > better error description here would be: "refusing to update
> > funny ref 'refs/foo' remotely".
>
> OK, update() works on each ref affected, not just the ones that are
> updated, but also created and deleted. The updated wording may
> probably be better.
>
>
> >
> > Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> > ---
> > builtin/receive-pack.c | 2 +-
> > t/t5516-fetch-push.sh | 5 +++++
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> > ...
> > +test_expect_success 'push with onelevel ref' '
> > + mk_test testrepo heads/main &&
> > + test_must_fail git push testrepo HEAD:refs/onelevel
> > +'
> > +
>
> I am not sure what relevance this new test has to the proposed
> update to the message, though.
>
Ah, I should have incorporated this part of the test into another
patch test.
> Thanks.
|
This branch is now known as |
|
This patch series was integrated into seen via git@2103e67. |
|
This patch series was integrated into seen via git@3e6fbb4. |
|
This patch series was integrated into seen via git@250b3f2. |
|
This patch series was integrated into seen via git@db50120. |
|
This patch series was integrated into seen via git@3282f42. |
When the user deletes the remote one level branch through "git push origin -d refs/foo", remote will return an error: "refusing to create funny ref 'refs/foo' remotely", here we are not creating "refs/foo" instead wants to delete it, so a better error description here would be: "refusing to update funny ref 'refs/foo' remotely". Signed-off-by: ZheNing Hu <adlternative@gmail.com>
We discourage the creation/update of single-level refs because some upper-layer applications only work in specified reference namespaces, such as "refs/heads/*" or "refs/tags/*", these single-level refnames may not be recognized. However, we still hope users can delete them which have been created by mistake. Therefore, when updating branches on the server with "git receive-pack", by checking whether it is a branch deletion operation, it will determine whether to allow the update of a single-level refs. This avoids creating/updating such single-level refs, but allows them to be deleted. On the client side, "git push" also does not properly fill in the old-oid of single-level refs, which causes the server-side "git receive-pack" to think that the ref's old-oid has changed when deleting single-level refs, this causes the push to be rejected. So the solution is to fix the client to be able to delete single-level refs by properly filling old-oid. Signed-off-by: ZheNing Hu <adlternative@gmail.com>
adlternative
force-pushed
the
zh/delete-one-level-ref
branch
from
4dc75f5
to
022818f
Compare
|
/submit |
|
Submitted as pull.1465.v4.git.1677666029.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
This patch series was integrated into seen via git@196b2f7. |
|
There was a status update in the "New Topics" section about the branch "git push" has been taught to allow deletion of refs with one-level names to help repairing a repository who acquired such a ref by mistake. In general, we don't encourage use of such a ref, and creation or update to such a ref is rejected as before. Comments? source: <pull.1465.v4.git.1677666029.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@f0010c7. |
|
This patch series was integrated into seen via git@e81f1ab. |
|
This patch series was integrated into seen via git@4482992. |
|
This patch series was integrated into seen via git@1000198. |
|
This patch series was integrated into seen via git@d050c1a. |
|
This patch series was integrated into seen via git@1c0de5c. |
|
This patch series was integrated into next via git@f08def5. |
|
There was a status update in the "Cooking" section about the branch "git push" has been taught to allow deletion of refs with one-level names to help repairing a repository who acquired such a ref by mistake. In general, we don't encourage use of such a ref, and creation or update to such a ref is rejected as before. Will cook in 'next'. source: <pull.1465.v4.git.1677666029.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@ad0ba39. |
|
This patch series was integrated into seen via git@3e77fc4. |
|
This patch series was integrated into seen via git@58ce5df. |
|
This patch series was integrated into seen via git@24789a5. |
|
There was a status update in the "Cooking" section about the branch "git push" has been taught to allow deletion of refs with one-level names to help repairing a repository who acquired such a ref by mistake. In general, we don't encourage use of such a ref, and creation or update to such a ref is rejected as before. Will cook in 'next'. source: <pull.1465.v4.git.1677666029.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@744f213. |
|
This patch series was integrated into seen via git@954b602. |
|
There was a status update in the "Cooking" section about the branch "git push" has been taught to allow deletion of refs with one-level names to help repairing a repository who acquired such a ref by mistake. In general, we don't encourage use of such a ref, and creation or update to such a ref is rejected as before. Will merge to 'master'. source: <pull.1465.v4.git.1677666029.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@4a25b91. |
|
This patch series was integrated into master via git@4a25b91. |
|
This patch series was integrated into next via git@4a25b91. |
|
Closed via 4a25b91. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This might be an odd request: allow git push to delete
one level refs like "ref/foo".
Some users on my side often push "refs/for/master"
to the remote for code review, but due to a user's typo,
"refs/master" is pushed to the remote.
Pushing a one level ref like "refs/foo" should not have been
successful, but since my server side directly updated the ref
during the proc-receive-hook phase of git receive-pack,
"refs/foo" was mistakenly left at on the server.
But for some reasons, users cannot delete this special branch
through "git push -d".
First, I executed git update-ref --stdin inside my proc-receive-hook
to delete the branch. As a result, update-ref reported an error:
"cannot lock ref 'refs/foo': reference already exists".
So I tried GIT_TRACKET_PACKET to debug and found that git push
did not seem to pass the correct ref old-oid, which is why update-ref
reported an error.
Tracing it back, the check_ref() in the git push link didn't record
the old-oid for the remote "refs/foo".
At the same time, the server update() process will reject the one
level ref by default and return a "funny refname" error.
It is worth mentioning that since I deleted the branch, the error
message returned here is "refusing to create funny ref 'refs/foo'
remotely", which is also worth fixing.
So this patch series do:
v1.
v2.
v3.
deleted but not created/updated.
v4.
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: Junio C Hamano gitster@pobox.com
cc: Derrick Stolee derrickstolee@github.com
cc: Elijah Newren newren@gmail.com
cc: Michael Haggerty mhagger@alum.mit.edu
cc: Christian Couder christian.couder@gmail.com
cc: Jeff King peff@peff.net