Jeff King p...@peff.net writes:
... The problem there is not already exists but rather
a blob is not something that can fast-forward. Using the existing
REJECT_NONFASTFORWARD is insufficient (because later code will recommend
pull-then-push, which is wrong). So I'd be in favor of creating a
On Mon, Jan 21, 2013 at 5:40 PM, Jeff King p...@peff.net wrote:
On Thu, Jan 17, 2013 at 09:18:50PM -0600, Chris Rorvick wrote:
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote:
However, if instead of the rule being
blobs on the remote side cannot be replaced, if it becomes the
Chris Rorvick ch...@rorvick.com writes:
I agree with everything above. I just don't understand why reverting
the already exists behavior for non-commit-ish objects was a
prerequisite to fixing this.
Because it is a regression. People who did not force such a push
did not get already exists,
On Thu, Jan 17, 2013 at 12:59 AM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote:
It is fine when pushing into refs/tags/ hierarchy. It is *NOT*
OK if the type check does not satisfy
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
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote:
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
Jeff King p...@peff.net writes:
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
Hi there,
I was just working on improving git-remote-helper.txt by documenting how remote
helper can signal error conditions to git. This lead me to notice a (to me)
surprising change in behavior between master and next that I traced back to
this patch series.
Specifically:
On 30.11.2012, at
Max Horn m...@quendi.de writes:
But with next, I get this:
! [rejected]master - master (already exists)
error: failed to push some refs to '/Users/mhorn/Proje...o_orig'
hint: Updates were rejected because the destination reference already exists
hint: in the remote.
This looks
Junio C Hamano gits...@pobox.com writes:
Max Horn m...@quendi.de writes:
But with next, I get this:
! [rejected]master - master (already exists)
error: failed to push some refs to '/Users/mhorn/Proje...o_orig'
hint: Updates were rejected because the destination reference already
On Wed, Jan 16, 2013 at 02:32:03PM +0100, Max Horn wrote:
With git 1.8.1, I get this message:
! [rejected]master - master (non-fast-forward)
[...]
But with next, I get this:
! [rejected]master - master (already exists)
Thanks for the detailed report. I was able to
Max Horn m...@quendi.de writes:
But with next, I get this:
! [rejected]master - master (already exists)
error: failed to push some refs to
'/Users/mhorn/Projekte/foreign/gitifyhg/bugs/git-push-conflict/repo_orig'
hint: Updates were rejected because the destination reference
Jeff King p...@peff.net writes:
I.e., we trigger the !o branch after the parse_object in your example.
Heh, I didn't see this message until now (gmane seems to be lagging
a bit).
I am very tempted to do this.
* Remove unnecessary not_forwardable from struct ref; it is only
used inside
On Wed, Jan 16, 2013 at 09:10:10AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I.e., we trigger the !o branch after the parse_object in your example.
Heh, I didn't see this message until now (gmane seems to be lagging
a bit).
I think it is vger lagging, actually.
I am
Jeff King p...@peff.net writes:
I see what you are saying, but I think the ship has already sailed to
some degree. We already implement the non-fast-forward check everywhere,
and I cannot have a refs/tested hierarchy that pushes arbitrary
commits without regard to their history. If I have
On Wed, Jan 16, 2013 at 11:43 AM, Jeff King p...@peff.net wrote:
I think that is a reasonable rule that could be applied across all parts
of the namespace hierarchy. And it could be applied by the client,
because all you need to know is whether ref-old_sha1 is reachable from
ref-new_sha1.
On Wed, Jan 16, 2013 at 08:19:28PM -0600, Chris Rorvick wrote:
On Wed, Jan 16, 2013 at 11:43 AM, Jeff King p...@peff.net wrote:
I think that is a reasonable rule that could be applied across all parts
of the namespace hierarchy. And it could be applied by the client,
because all you need
On Wed, Jan 16, 2013 at 9:11 PM, Jeff King p...@peff.net wrote:
is_forwardable() did solve a UI issue. Previously all instances where
old is not reachable by new were assumed to be addressable with a
merge. is_forwardable() attempted to determine if the concept of
forwarding made sense given
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote:
It is fine when pushing into refs/tags/ hierarchy. It is *NOT*
OK if the type check does not satisfy this function. In that case,
we do not actually see the existence of the destination as a
problem, but it is reported
Chris Rorvick ch...@rorvick.com writes:
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote:
It is fine when pushing into refs/tags/ hierarchy. It is *NOT*
OK if the type check does not satisfy this function. In that case,
we do not actually see the existence of the
Thanks; will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch series originated in response to the following thread:
http://thread.gmane.org/gmane.comp.version-control.git/208354
I made some adjustments based on Junio's last round of feedback
including a new patch reworking the push rules comment in remote.c.
Also refined some of the log
22 matches
Mail list logo
