From: Jeff King <peff@peff.net>
To: Chris Rorvick <chris@rorvick.com>
Cc: Junio C Hamano <gitster@pobox.com>, Max Horn <max@quendi.de>,
git@vger.kernel.org, Angelo Borsotti <angelo.borsotti@gmail.com>,
Drew Northup <n1xim.email@gmail.com>,
Michael Haggerty <mhagger@alum.mit.edu>,
Philip Oakley <philipoakley@iee.org>,
Johannes Sixt <j6t@kdbg.org>,
Kacper Kornet <draenog@pld-linux.org>,
Felipe Contreras <felipe.contreras@gmail.com>
Subject: Re: [PATCH v6 0/8] push: update remote tags only with force
Date: Thu, 17 Jan 2013 17:06:38 -0800 [thread overview]
Message-ID: <20130118010638.GA29453@sigill.intra.peff.net> (raw)
In-Reply-To: <CAEUsAPYAL6TD_nzu-YumRK_b-kFy7mNz1VivmSxGeuFYVxVL4g@mail.gmail.com>
On Thu, Jan 17, 2013 at 07:09:16AM -0600, Chris Rorvick wrote:
> I was referring to your concern about rejecting based on type. A push
> causing a reference to move (for example) from a commit to a blob is
> rejected as "already exists" with this patch. You emphatically state
> this is not OK and your solution is to revert back to behavior that
> advises a merge.
>
> Clearly the bug regarding an 'old' unknown to the client should be
> fixed. This is a obvious test case I should have covered and it's
> unfortunate it made it into master. But I don't understand why
> is_forwardable() was misguided (maybe poorly named) nor why
> ref_newer() is a better place to solve the issues it was addressing.
I think that a type-based rule that relies on knowing the type of the
other side will always have to guess in some cases, because we do not
necessarily have that information. However, if instead of the rule being
"blobs on the remote side cannot be replaced", if it becomes "the old
value on the remote side must be referenced by what we replace it with",
that _is_ something we can calculate reliably on the sending side. And
that is logically an extension of the fast-forward rule, which is why I
suggested placing it with ref_newer (but the latter should probably be
extended to not suggest merging if we _know_ it is a non-commit object).
-Peff
next prev parent reply other threads:[~2013-01-18 1:07 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 1:41 [PATCH v6 0/8] push: update remote tags only with force Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 1/8] push: return reject reasons as a bitset Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 2/8] push: add advice for rejected tag reference Chris Rorvick
2012-12-02 10:42 ` Junio C Hamano
2012-12-03 3:27 ` [PATCH 0/2] push: honor advice.* configuration Chris Rorvick
2012-12-03 3:27 ` [PATCH 1/2] push: rename config variable for more general use Chris Rorvick
2012-12-03 3:27 ` [PATCH 2/2] push: allow already-exists advice to be disabled Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 3/8] push: flag updates Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 4/8] push: flag updates that require force Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 5/8] push: require force for refs under refs/tags/ Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 6/8] push: require force for annotated tags Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 7/8] push: clarify rejection of update to non-commit-ish Chris Rorvick
2012-11-30 1:41 ` [PATCH v6 8/8] push: cleanup push rules comment Chris Rorvick
2012-12-02 20:43 ` [PATCH] remote.c: fix grammatical error in comment Chris Rorvick
2012-12-03 18:53 ` [PATCH v6 0/8] push: update remote tags only with force Junio C Hamano
2013-01-16 13:32 ` Max Horn
2013-01-16 16:00 ` Junio C Hamano
2013-01-16 16:01 ` Jeff King
2013-01-16 17:10 ` Junio C Hamano
2013-01-16 17:43 ` Jeff King
2013-01-16 21:02 ` Junio C Hamano
2013-01-17 2:19 ` Chris Rorvick
2013-01-17 3:11 ` Jeff King
2013-01-17 3:42 ` Chris Rorvick
2013-01-16 16:36 ` Junio C Hamano
2013-01-16 16:48 ` Junio C Hamano
2013-01-17 6:20 ` Chris Rorvick
2013-01-17 6:59 ` Junio C Hamano
2013-01-17 13:09 ` Chris Rorvick
2013-01-18 1:06 ` Jeff King [this message]
2013-01-18 3:18 ` Chris Rorvick
2013-01-21 23:40 ` Jeff King
2013-01-21 23:53 ` Junio C Hamano
2013-01-22 4:59 ` Chris Rorvick
2013-01-22 6:44 ` Junio C Hamano
2013-01-22 5:53 ` [PATCH 0/3] Finishing touches to "push" advises Junio C Hamano
2013-01-22 5:53 ` [PATCH 1/3] push: further clean up fields of "struct ref" Junio C Hamano
2013-01-22 5:53 ` [PATCH 2/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE Junio C Hamano
2013-01-22 6:04 ` Junio C Hamano
2013-01-22 5:53 ` [PATCH 3/3] push: further reduce "struct ref" and simplify the logic Junio C Hamano
2013-01-22 6:21 ` Junio C Hamano
2013-01-22 6:30 ` [PATCH 0/3] Finishing touches to "push" advises Junio C Hamano
2013-01-22 6:30 ` [PATCH v2 1/3] push: further clean up fields of "struct ref" Junio C Hamano
2013-01-23 6:43 ` Jeff King
2013-01-22 6:30 ` [PATCH v2 2/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE Junio C Hamano
2013-01-23 6:56 ` Jeff King
2013-01-23 16:28 ` Junio C Hamano
2013-01-24 6:43 ` Jeff King
2013-01-22 6:30 ` [PATCH v2 3/3] push: further simplify the logic to assign rejection status Junio C Hamano
2013-01-22 7:26 ` [PATCH 0/3] Finishing touches to "push" advises Junio C Hamano
2013-01-23 21:55 ` [PATCH v4 " Junio C Hamano
2013-01-23 21:55 ` [PATCH v4 1/3] push: further clean up fields of "struct ref" Junio C Hamano
2013-01-24 22:22 ` Eric Sunshine
2013-01-23 21:55 ` [PATCH v4 2/3] push: further simplify the logic to assign rejection reason Junio C Hamano
2013-01-23 21:55 ` [PATCH v4 3/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE Junio C Hamano
2013-01-24 6:58 ` Jeff King
2013-01-24 17:19 ` Junio C Hamano
2013-01-25 4:31 ` [PATCH v4 0/3] Finishing touches to "push" advises Chris Rorvick
2013-01-25 5:04 ` Junio C Hamano
2013-01-25 5:14 ` Chris Rorvick
2013-01-18 4:36 ` [PATCH v6 0/8] push: update remote tags only with force 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=20130118010638.GA29453@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=angelo.borsotti@gmail.com \
--cc=chris@rorvick.com \
--cc=draenog@pld-linux.org \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=max@quendi.de \
--cc=mhagger@alum.mit.edu \
--cc=n1xim.email@gmail.com \
--cc=philipoakley@iee.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 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.