All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: Christian Couder <chriscool@tuxfamily.org>, <git@vger.kernel.org>,
	"Philip Oakley" <philipoakley@iee.org>,
	Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH v2 1/5] replace: forbid replacing an object with one of a different type
Date: Wed, 28 Aug 2013 12:32:37 -0700	[thread overview]
Message-ID: <xmqqa9k1a9wq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <878uzmclva.fsf@linux-k42r.v.cablecom.net> (Thomas Rast's message of "Wed, 28 Aug 2013 09:31:21 +0200")

Thomas Rast <trast@inf.ethz.ch> writes:

> Hrm, you're right, that's a flaw in my logic.  You could do the same in
> all other cases too, e.g. replace a tree so that an entry is of a
> different type and at the same time change the type of the object
> itself.  You however have to carefully go through all objects that refer
> to the one that was replaced, and fix the type in all of them.
>
> It still seems an extremely unsafe thing to do with trees...
>  ...
> Should we add a --force flag of some sort to allow the user to do this,
> while keeping the normal safety checks?

As long as we do not forbid such an unusual replacement on the
reading side, we won't break people who are more inventive than we
are (I am not convinced that we know people's workflow well enough
to definitively say that no sane workflow, which benefits from being
able to replace an object with another from a different type,
exists).

Preventing "git replace" wrapper from creating such a replacement by
default will make it harder to do and may reduce mistakes, without
breaking them too much, I think.

  reply	other threads:[~2013-08-28 19:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27 19:48 [PATCH v2 0/5] Check replacement object type and minor updates Christian Couder
2013-08-27 19:48 ` [PATCH v2 1/5] replace: forbid replacing an object with one of a different type Christian Couder
2013-08-27 20:30   ` Junio C Hamano
2013-08-28  7:31     ` Thomas Rast
2013-08-28 19:32       ` Junio C Hamano [this message]
2013-08-29  6:29         ` Christian Couder
2013-08-29 16:04           ` Junio C Hamano
2013-08-30  5:41             ` Christian Couder
2013-08-30 16:52               ` Junio C Hamano
2013-08-27 19:48 ` [PATCH v2 2/5] Documentation/replace: state that objects must be of the same type Christian Couder
2013-08-27 19:48 ` [PATCH v2 3/5] t6050-replace: test that objects are " Christian Couder
2013-08-27 19:48 ` [PATCH v2 4/5] t6050-replace: add test to clean up all the replace refs Christian Couder
2013-08-27 19:48 ` [PATCH v2 5/5] Documentation/replace: add Creating Replacement Objects section Christian Couder

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=xmqqa9k1a9wq.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=philipoakley@iee.org \
    --cc=trast@inf.ethz.ch \
    /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.