git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <johannes.schindelin@gmx.de>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
	Brandon Williams <bmwill@google.com>
Subject: [PATCH v4 0/6] Avoid problem where git_dir is set after alias expansion
Date: Wed, 14 Jun 2017 13:35:22 +0200 (CEST)	[thread overview]
Message-ID: <cover.1497440104.git.johannes.schindelin@gmx.de> (raw)

When expanding an alias in a subdirectory, we setup the git_dir
(gently), read the config, and then restore the "env" (e.g. the current
working directory) so that the command specified by the alias can run
correctly.

What we failed to reset was the git_dir, meaning that in the most common
case, it was now pointing to a .git/ directory *in the subdirectory*.

This problem was identified in the GVFS fork, where a pre-command hook
was introduced to allow pre-fetching missing blobs.

An early quick fix in the GVFS fork simply built on top of the
save_env_before_alias() hack, introducing another hack that saves the
git_dir and restores it after an alias is expanded:

	https://github.com/Microsoft/git/commit/2d859ba3b

That is very hacky, though, and it is much better (although much more
involved, too) to fix this "properly", i.e. by replacing the ugly
save/restore logic by simply using the early config code path.

However, aliases are strange beasts.

When an alias refers to a single Git command (originally the sole
intention of aliases), the current working directory is restored to what
it had been before expanding the alias.

But when an alias starts with an exclamation point, i.e. referring to a
command-line to be interpreted by the shell, the current working
directory is no longer in the subdirectory but instead in the worktree's
top-level directory.

This is even true for worktrees added by `git worktree add`.

But when we are inside the .git/ directory, the current working
directory is *restored* to the subdirectory inside the .git/ directory.

In short, the rules (what is the expected current working directory after
expanding an alias and before actually running it) are a bit complicated.

This patch series does *not* address the problem identified by Brandon
Williams where the early config machinery fails to look into the
*commondir* in worktrees added by `git worktree add`. My hope is that
Brandon is okay with applying this patch series before his config patch
series.

Changes since v3:

- avoided the strbuf in alias_lookup() by using skip_prefix() and !strcmp()
  instead.

- fixed tyop ("read" instead of "reading", causing Junio to stumble) in the
  commit message of 6/6.


Johannes Schindelin (6):
  discover_git_directory(): avoid setting invalid git_dir
  config: report correct line number upon error
  help: use early config when autocorrecting aliases
  t1308: relax the test verifying that empty alias values are disallowed
  t7006: demonstrate a problem with aliases in subdirectories
  Use the early config machinery to expand aliases

 alias.c                | 29 +++++++++++++++++++-------
 config.c               |  3 ++-
 git.c                  | 55 ++++----------------------------------------------
 help.c                 |  2 +-
 setup.c                |  1 +
 t/t1300-repo-config.sh |  6 ++++++
 t/t1308-config-set.sh  |  4 +++-
 t/t7006-pager.sh       | 11 ++++++++++
 8 files changed, 50 insertions(+), 61 deletions(-)


base-commit: 02a2850ad58eff6de70eb2dc5f96345c463857ac
Published-As: https://github.com/dscho/git/releases/tag/alias-early-config-v4
Fetch-It-Via: git fetch https://github.com/dscho/git alias-early-config-v4

Interdiff vs v3:
 diff --git a/alias.c b/alias.c
 index 6bdc9363037..5df052ae4c4 100644
 --- a/alias.c
 +++ b/alias.c
 @@ -2,15 +2,16 @@
  
  struct config_alias_data
  {
 -	struct strbuf key;
 +	const char *alias;
  	char *v;
  };
  
  static int config_alias_cb(const char *key, const char *value, void *d)
  {
  	struct config_alias_data *data = d;
 +	const char *p;
  
 -	if (!strcmp(key, data->key.buf))
 +	if (skip_prefix(key, "alias.", &p) && !strcmp(p, data->alias))
  		return git_config_string((const char **)&data->v, key, value);
  
  	return 0;
 @@ -18,12 +19,9 @@ static int config_alias_cb(const char *key, const char *value, void *d)
  
  char *alias_lookup(const char *alias)
  {
 -	struct config_alias_data data = { STRBUF_INIT, NULL };
 +	struct config_alias_data data = { alias, NULL };
  
 -	strbuf_addf(&data.key, "alias.%s", alias);
 -	if (git_config_key_is_valid(data.key.buf))
 -		read_early_config(config_alias_cb, &data);
 -	strbuf_release(&data.key);
 +	read_early_config(config_alias_cb, &data);
  
  	return data.v;
  }
-- 
2.13.1.windows.1.1.ga36e14b3aaa


             reply	other threads:[~2017-06-14 11:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-14 11:35 Johannes Schindelin [this message]
2017-06-14 11:35 ` [PATCH v4 1/6] discover_git_directory(): avoid setting invalid git_dir Johannes Schindelin
2017-06-14 11:35 ` [PATCH v4 2/6] config: report correct line number upon error Johannes Schindelin
2017-06-14 11:35 ` [PATCH v4 3/6] help: use early config when autocorrecting aliases Johannes Schindelin
2017-06-14 11:35 ` [PATCH v4 4/6] t1308: relax the test verifying that empty alias values are disallowed Johannes Schindelin
2017-06-14 11:35 ` [PATCH v4 5/6] t7006: demonstrate a problem with aliases in subdirectories Johannes Schindelin
2017-06-14 11:36 ` [PATCH v4 6/6] Use the early config machinery to expand aliases Johannes Schindelin
2017-06-15 19:36   ` Junio C Hamano
2017-06-15 19:44     ` Johannes Schindelin
2017-06-15  6:37 ` [PATCH v4 0/6] Avoid problem where git_dir is set after alias expansion Jeff King

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=cover.1497440104.git.johannes.schindelin@gmx.de \
    --to=johannes.schindelin@gmx.de \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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).