All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Commands requiring a work tree must not run in GIT_DIR
Date: Wed, 24 Jan 2007 03:44:10 -0800	[thread overview]
Message-ID: <7vodoohcol.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: Pine.LNX.4.63.0701231312170.22628@wbgn013.biozentrum.uni-wuerzburg.de

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> This patch helps when you accidentally run something like git-clean
> in the git directory instead of the work tree.

I think "require_work_tree" reflects what we are trying to do
much better than NOT_BARE.  So maybe we should rename NOT_BARE
to REQUIRE_WORK_TREE.

Existing check function is_bare_repository() is sometimes used
to see if it is a bare repository regardless of where you are
(e.g. refs.c::log_ref_write()), so that function can stay as is,
but the combined check below (you seem to have a few instances
in your patch) can be made into a function require_work_tree().

> diff --git a/git.c b/git.c
> index 5133a07..2027d1c 100644
> --- a/git.c
> +++ b/git.c
> @@ -302,8 +302,9 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
>  			prefix = setup_git_directory();
>  		if (p->option & USE_PAGER)
>  			setup_pager();
> -		if ((p->option & NOT_BARE) && is_bare_repository())
> -			die("%s cannot be used in a bare git directory", cmd);
> +		if ((p->option & NOT_BARE) &&
> +				(is_bare_repository() || is_inside_git_dir()))
> +			die("%s must be run in a work tree", cmd);
>  		trace_argv_printf(argv, argc, "trace: built-in: git");
>  
>  		exit(p->fn(argc, argv, prefix));

Similar to the "conditionally require working tree" you did to
ls-files, "apply --index" and perhaps "apply --cached" (but this
is "perhaps" --- you _could_ have an index in a bare repository,
although it is debatable if there is a valid use case for it),
grep (grep_cache() but perhaps !cached for the same reason),
"read-tree -u", "rerere", "update-index" (except --index-info
and friends that feed object names directly without using
working tree), should require working tree.

On the script front, bisect should require working tree, but I
do not think anybody is stupid enough to start bisecting in a
bare repository ;-)

  reply	other threads:[~2007-01-24 11:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-19  1:04 git ls-files -o under .git/ prints all repository files Yasushi SHOJI
2007-01-19  6:47 ` Junio C Hamano
2007-01-19  7:27   ` Andy Parkins
2007-01-19  8:32     ` Junio C Hamano
2007-01-19  9:04       ` Andy Parkins
2007-01-19  7:41   ` Yasushi SHOJI
2007-01-19  7:51   ` Simon 'corecode' Schubert
2007-01-19  7:57     ` Alex Riesen
2007-01-19  8:07       ` Simon 'corecode' Schubert
2007-01-19  8:32         ` Alex Riesen
2007-01-19  9:04           ` Simon 'corecode' Schubert
2007-01-19  9:33             ` Alex Riesen
2007-01-19 10:10               ` Simon 'corecode' Schubert
2007-01-19 10:38                 ` Alex Riesen
2007-01-19 12:19                   ` Simon 'corecode' Schubert
2007-01-19 13:30       ` Andreas Ericsson
2007-01-19 13:46         ` Matthias Kestenholz
2007-01-19 15:00           ` Johannes Schindelin
2007-01-19 19:03             ` Junio C Hamano
2007-01-23 11:12               ` Yasushi SHOJI
2007-01-23 12:30                 ` [PATCH] Commands requiring a work tree must not run in GIT_DIR Johannes Schindelin
2007-01-24 11:44                   ` Junio C Hamano [this message]
2007-01-24 14:14                     ` Johannes Schindelin
2007-01-24 22:51                       ` Junio C Hamano
2007-01-19  8:02   ` git ls-files -o under .git/ prints all repository files Alex Riesen
2007-01-19  8:01 ` Alex Riesen

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=7vodoohcol.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /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.