git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: Sheikh hamza via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Sheikh hamza <sheikhhamza012@gmail.com>
Subject: Re: [PATCH] bisect: remove root directory restriction for git bisect
Date: Mon, 23 Mar 2020 09:17:57 -0700	[thread overview]
Message-ID: <xmqqpnd359l6.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200322104826.GB2224@szeder.dev> ("SZEDER Gábor"'s message of "Sun, 22 Mar 2020 11:48:26 +0100")

SZEDER Gábor <szeder.dev@gmail.com> writes:

> On Sun, Mar 22, 2020 at 09:15:47AM +0000, Sheikh hamza via GitGitGadget wrote:
>> From: sheikh hamza <sheikhhamza012@gmail.com>
>> 
>>     according to the open issue #486
>
> What issue #486?  Where?  The Git project doesn't use issues.
>
>> the git bisect
>>     command should be able to run from inside any
>>     subdirectory
>
> Why should 'git bisect' be able to run from inside any subdirectory
> (of the working tree, I presume)?
>
> In particular, what happens, if someone starts 'git bisect' from
> within 'subdir/', and 'git bisect' then checks out an old commit,
> where said 'subdir/' didn't exist?  What happens, if the user runs
> 'git bisect run ./script' from within 'subdir/', and that 'subdir/'
> doesn't exist in that old commit?  What happens, if 'subdir' does
> exists in that old commit, but it's a file, not a directory?  What
> happens, if all this is on Windows?

Hmm, I am of two minds.  Most certainly, the bisection would break
when the directory cannot be removed, and if it can be, then $pwd
would become in a weird state and the iteration with the bisect
machinery (be it interactive test before saying "bisect good/bad",
or the command execution during "bisect run") would fail in a
strange and unpredictable ways.

So from that perspective, it does make sense to forbid running "git
bisect" from a subdirectory, and we should probably do so on the
same principle for "git checkout", "git pull" and many other things.

But even then, it would not probably be foolproof.  Another process
that the end-user is not even aware of its execution (e.g. virus
scanners?) may have a file open in the subdirectory on a filesystem
that does not allow directories to be removed while there is an open
file descriptor on a file it contains, and would cause the command
to fail in a similar way.

So it probably is being too draconian to forbid these commands (not
just "git bisect") from being run in a subdirectory for no good
reason (i.e. being strict is not helping us much).  What would help
is to make sure we fail in an understandable way (i.e. "cannot
remove directory /foo/bar/boz, so checkout of version v1.2.3 failed"
is clearly conveyed to the end user, which we may be already doing
in which case that is wonderful).

>> and in the same disscusion "dscho"
>>     gave the directions and those directions lead me
>>     the fix of adding SUBDIRECTORY_OK=Yes on L#34
>>     before sourcing git-sh-setup that made it work as
>>     in git-sh-setup there was a check on SUBDIRECTORY_OK
>>     that prevents it to run in sub directories if it is not
>>     set to "ok" as this file was also sourced in other commands
>>     that are required to only run from root one of such scripts
>>     is git-filter-branch
>
> Please don't indent the commit message and use punctuation to make it
> more readable.

This is a good point.

      parent reply	other threads:[~2020-03-23 16:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-22  9:15 [PATCH] bisect: remove root directory restriction for git bisect Sheikh hamza via GitGitGadget
2020-03-22 10:48 ` SZEDER Gábor
2020-03-22 14:30   ` sheikh hamza
2020-03-22 14:39   ` sheikh hamza
2020-03-22 14:58   ` sheikh hamza
2020-03-23 16:02   ` Johannes Schindelin
2020-03-23 16:17   ` Junio C Hamano [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqpnd359l6.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=sheikhhamza012@gmail.com \
    --cc=szeder.dev@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).