git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Brandon Williams <bmwill@google.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 1/9] discover_git_directory(): avoid setting invalid git_dir
Date: Thu, 8 Jun 2017 12:00:56 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1.1706081143010.171564@virtualbox> (raw)
In-Reply-To: <20170607174529.GB110638@google.com>

Hi Brandon,

On Wed, 7 Jun 2017, Brandon Williams wrote:

> On 06/07, Johannes Schindelin wrote:
>
> > diff --git a/setup.c b/setup.c
> > index e3f7699a902..2435186e448 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -982,6 +982,7 @@ const char *discover_git_directory(struct strbuf *gitdir)
> >  		warning("ignoring git dir '%s': %s",
> >  			gitdir->buf + gitdir_offset, err.buf);
> >  		strbuf_release(&err);
> > +		strbuf_setlen(gitdir, gitdir_offset);
> >  		return NULL;
> 
> There is another part of this function that returns NULL (which isn't
> shown by this diff) after performing 'setup_git_dir_gently_1', do we
> need to worry about anything that 'setup_git_dir_gently_1' has
> potentially appended to 'gitdir' upon 'setup_git_dir_gently_1' failing?

The setup_git_dir_gently_1() function used to set the git_dir variable
directly in case of success, and leave it unchanged in case of error. My
work to allow an early config did not change that, with the exception that
it is the gitdir parameter that is changed instead of git_dir.

In other words: that `return NULL` is safe, as it returns due to an error
reported by the setup_git_directory_gently_1() function (meaning that the
gitdir strbuf has not been touched).

I amended the commit message accordingly, and force-pushed the result.
Meaning: v2 will have that change.

Ciao,
Dscho

  reply	other threads:[~2017-06-08 10:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-07 16:06 [PATCH 0/9] Avoid problem where git_dir is set after alias expansion Johannes Schindelin
2017-06-07 16:06 ` [PATCH 1/9] discover_git_directory(): avoid setting invalid git_dir Johannes Schindelin
2017-06-07 17:45   ` Brandon Williams
2017-06-08 10:00     ` Johannes Schindelin [this message]
2017-06-07 16:06 ` [PATCH 2/9] config: report correct line number upon error Johannes Schindelin
2017-06-09 17:01   ` Junio C Hamano
2017-06-07 16:06 ` [PATCH 3/9] help: use early config when autocorrecting aliases Johannes Schindelin
2017-06-07 17:51   ` Brandon Williams
2017-06-08 10:02     ` Johannes Schindelin
2017-06-09 17:05   ` Junio C Hamano
2017-06-07 16:06 ` [PATCH 4/9] read_early_config(): optionally return the worktree's top-level directory Johannes Schindelin
2017-06-07 18:13   ` Brandon Williams
2017-06-08 10:20     ` Johannes Schindelin
2017-06-08 14:46       ` Brandon Williams
2017-06-08 15:30         ` Johannes Schindelin
2017-06-08 16:32           ` Brandon Williams
2017-06-08 18:52             ` Johannes Schindelin
2017-06-08 18:54               ` Brandon Williams
2017-06-07 16:06 ` [PATCH 5/9] t1308: relax the test verifying that empty alias values are disallowed Johannes Schindelin
2017-06-07 18:15   ` Brandon Williams
2017-06-08 10:22     ` Johannes Schindelin
2017-06-08 14:47       ` Brandon Williams
2017-06-10  1:28   ` Junio C Hamano
2017-06-07 16:06 ` [PATCH 6/9] t7006: demonstrate a problem with aliases in subdirectories Johannes Schindelin
2017-06-07 16:06 ` [PATCH 7/9] alias_lookup(): optionally return top-level directory Johannes Schindelin
2017-06-07 16:07 ` [PATCH 8/9] Use the early config machinery to expand aliases Johannes Schindelin
2017-06-07 18:26   ` Brandon Williams
2017-06-08 10:25     ` Johannes Schindelin
2017-06-08 14:51       ` Brandon Williams
2017-06-10  1:33   ` Junio C Hamano
2017-06-07 16:09 ` [PATCH 0/9] Avoid problem where git_dir is set after alias expansion Johannes Schindelin
2017-06-07 18:30 ` Brandon Williams
2017-06-08 10:27   ` Johannes Schindelin
2017-06-08 16:33     ` Brandon Williams

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