From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: Manzur Mukhitdinov <manzurmm@gmail.com>,
git <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH] replace: fix replacing object with itself
Date: Sun, 16 Nov 2014 10:59:57 -0800 [thread overview]
Message-ID: <xmqqr3x3ynrm.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAP8UFD3dZMmGJp1p=ttVUoUkiwh7oYL3gqgsGZ+D8Bd16FiKjQ@mail.gmail.com> (Christian Couder's message of "Sat, 15 Nov 2014 12:55:11 +0100")
Christian Couder <christian.couder@gmail.com> writes:
>> The patch is not wrong per-se, but I wonder how useful this "do not
>> replace itself but all other forms of loops are not checked at all"
>> would be in practice. If your user did this:
>>
>> git replace A B ;# pretend as if what is in B is in A
>> git replace B C ;# pretend as if what is in C is in B
>> git replace C A ;# pretend as if we have loop
>> git log C
>>
>> she would not be helped with this patch at all, no?
>
> Yeah, but such loops are much less likely mistakes and are more
> difficult to detect, so I think this patch is at least a good first
> step.
More difficult to notice by humans, hence deserves more help from
the tool.
When these two are both mistakes, which one do you think is easier
to notice (thusly unlikely to happen)?
git replace A A
git replace C A
Of course, the former is immediately obvious to the human who is
typing that it is a typo.
The latter would be harder to spot as a mistake as the invoker has
to know that there is an existing "pretend as if what is in A is in
C" aka "replace A C" done earlier in the repository.
And the cost of detecting such a possible "too deep replace chain"
(do not call that a loop---the runtime barfs if you have too deep a
replace chain without any loop) wouldn't be too high. You only need
to look at existing refs/replace/* refs, their contents, and the two
object names that form the proposed new replacement <old,new>.
Even a kludge (read: I am not suggesting that you solve it this way)
like "first install the replacement as proposed, then enumerate all
the replacement refs and their values and try to see if the runtime
check would barf, and if it would, fail the operation and revert the
change" would catch a mistake to cause the repository in trouble.
next prev parent reply other threads:[~2014-11-16 19:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 14:05 [PATCH] replace: fix replacing object with itself Manzur Mukhitdinov
2014-11-14 22:45 ` Junio C Hamano
2014-11-15 11:55 ` Christian Couder
2014-11-16 18:59 ` Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-11-10 23:20 Manzur Mukhitdinov
2014-11-11 3:03 ` Jeff King
2014-11-09 0:05 Manzur Mukhitdinov
2014-11-09 5:58 ` Jeff King
2014-11-09 17:35 ` 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=xmqqr3x3ynrm.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=manzurmm@gmail.com \
--cc=peff@peff.net \
/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.