From: Junio C Hamano <gitster@pobox.com>
To: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: [PATCH] Do check_repository_format() early
Date: Mon, 03 Dec 2007 10:07:12 -0800 [thread overview]
Message-ID: <7vtzmzire7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <fcaeb9bf0712030604o2efc90d0m148d3280aaa475a5@mail.gmail.com> (Nguyen Thai Ngoc Duy's message of "Mon, 3 Dec 2007 21:04:12 +0700")
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On Dec 2, 2007 1:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * Similarly, run a few commands in modes that do not require git
>> repository. For example, "git apply --stat" of an existing patch
>> should be viewable no matter where you are (that is just a "better
>> diffstat" mode), so ideally it should not barf only because you
>> happen to be in a repository that is too new for you to understand.
>> I do not know offhand how your patch would handle this situation.
>>
>> Note that making sure the latter works is tricky to do right, for a few
>> reasons.
>>
>> (1) It is not absolutely clear what the right behaviour is. It could
>> be argued that we should just barf saying we found a repository we
>> do not understand, refraining from doing any damange on it [*2*].
>>
>> (2) If we choose not to barf on such a repository, it remains to be
>> decided what "gently" should do --- if it should still treat
>> t/trash/test (which has too new a version) as the found repository,
>> or ignore it and use t/trash (which we can understand) as the found
>> repository. I think it should do the former.
>
> You might have forgotten the third choice: ignore t/trash/test and
> stop searching, instead pretend there is no repository at all (maybe
> with a big warning of unsupported repository).
>
> I agree t/trash should not be touched no matter what. I had enough
> "fun" with nested gitdir already. But if _gently() treats t/trash/test
> as a good repository, mysterious things may happen. Suppose gitdir v2
> supports some crazy refspec that current installed git cannot
> understand. Now you run git-remote on a v2 repository, it would end up
> barfing "invalid refspec" or something instead of "your repository
> version is not supported, upgrade git now". The latter error message
> is much clearer IMHO.
>
> If we are going "t/trash/test is good repo" route, we must make sure
> _gently() callers check repository version (and barf at proper places)
> before actually using it. Doing so makes repo version checking in
> _gently redundant, you need to check it from callers anyway as the
> callers will decide when to barf. Or return *nongit_ok=-1 and let the
> callers check return value so they do not need to run
> check_repository_format_version() again.
>
> Comments?
I think I phrased the above (2) not brilliantly. I meant your "third
choice" is the sane approach. Treat t/trash/test as a found place that
we do not understand, perhaps issue a warning saying that we will
operate in there but the repository version is too new for us to
understand, but still go ahead and operate in there without doing any
repository operation (so the plain git-apply without --index will act as
if it is a GNU patch called to modify files in that directory).
next prev parent reply other threads:[~2007-12-03 18:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-28 16:58 [PATCH] Do check_repository_format() early Nguyễn Thái Ngọc Duy
2007-11-28 17:05 ` Johannes Schindelin
2007-11-28 17:10 ` Nguyen Thai Ngoc Duy
2007-11-28 17:18 ` Johannes Schindelin
2007-11-28 17:24 ` Nguyen Thai Ngoc Duy
2007-11-28 18:11 ` Johannes Schindelin
2007-12-01 2:36 ` Junio C Hamano
2007-12-01 6:50 ` Nguyen Thai Ngoc Duy
2007-12-01 18:58 ` Junio C Hamano
2007-12-03 4:03 ` Nguyen Thai Ngoc Duy
2007-12-03 10:44 ` Johannes Schindelin
2007-12-03 14:04 ` Nguyen Thai Ngoc Duy
2007-12-03 18:07 ` Junio C Hamano [this message]
2007-12-05 13:33 ` Nguyễn Thái Ngọc Duy
2007-12-05 15:39 ` Nguyen Thai Ngoc Duy
2007-12-06 1:18 ` 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=7vtzmzire7.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).