git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	git@vger.kernel.org
Subject: Re: [PATCH] fetch: optionally allow disabling FETCH_HEAD update
Date: Mon, 13 Jul 2020 15:08:34 -0400	[thread overview]
Message-ID: <20200713190834.GA77607@syl.lan> (raw)
In-Reply-To: <xmqqft9vnvce.fsf_-_@gitster.c.googlers.com>

On Mon, Jul 13, 2020 at 11:06:09AM -0700, Junio C Hamano wrote:
> If you run fetch but record the result in remote-tracking branches,
> and either if you do nothing with the fetched refs (e.g. you are
> merely mirroring) or if you always work from the remote-tracking
> refs (e.g. you fetch and then merge origin/branchname separately),
> you can get away without having FETCH_HEAD at all.
>
> Teach "git fetch" a command line option "--[no-]write-fetch-head"
> and "fetch.writeFetchHEAD" configuration variable.  Without either,
> the default is to write FETCH_HEAD, and the usual rule that the
> command line option defeats configured default applies.
>
> Note that under "--dry-run" mode, FETCH_HEAD is never written;
> otherwise you'd see list of objects in the file that you do not
> actually have.
>
> Also note that this option is explicitly passed when "git pull"
> internally invokes "git fetch", so that those who configured their
> "git fetch" not to write FETCH_HEAD would not be able to break the
> cooperation between these two commands.  "git pull" must see what
> "git fetch" got recorded in FETCH_HEAD to work correctly.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>     Junio C Hamano <gitster@pobox.com> writes:
>
>     > Johannes Sixt <j6t@kdbg.org> writes:
>     >
>     >> Nah, really??? It's one of the benefits of git-fetch that it writes
>     >> FETCH_HEAD and the primary reason in many cases where I use the command!
>     >> So, either I don't care that FETCH_HEAD is written, or I do use it. IMO,
>     >> not wanting to write FETCH_HEAD is the odd case and would need a
>     >> configuration tweak, not the other way round.
>     >
>     > Yeah, that's even easier to arrange.
>     >
>     > Just the "--[no-]write-fetch-head" command line option and the
>     > fetch.writeFetchHEAD configuration variable are introduced and left
>     > off by default forever.
>
>     Something like this, perhaps.  Obviously I won't be pushing this
>     topic further while in prerelase freeze, but Konstantin or
>     anybody else interested can locally apply the patch to their own
>     copy of Git to test it out.
>
>     Thanks.
>
>  builtin/fetch.c  | 19 ++++++++++++++++---
>  builtin/pull.c   |  3 ++-
>  t/t5510-fetch.sh | 39 +++++++++++++++++++++++++++++++++++++--
>  3 files changed, 55 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 82ac4be8a5..3ccf69753f 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -56,6 +56,7 @@ static int prune_tags = -1; /* unspecified */
>  #define PRUNE_TAGS_BY_DEFAULT 0 /* do we prune tags by default? */
>
>  static int all, append, dry_run, force, keep, multiple, update_head_ok;
> +static int write_fetch_head = 1;
>  static int verbosity, deepen_relative, set_upstream;
>  static int progress = -1;
>  static int enable_auto_gc = 1;
> @@ -118,6 +119,10 @@ static int git_fetch_config(const char *k, const char *v, void *cb)
>  		return 0;
>  	}
>
> +	if (!strcmp(k, "fetch.writefetchhead")) {
> +		write_fetch_head = git_config_bool(k, v);
> +		return 0;
> +	}
>  	return git_default_config(k, v, cb);
>  }
>
> @@ -162,6 +167,8 @@ static struct option builtin_fetch_options[] = {
>  		    PARSE_OPT_OPTARG, option_fetch_parse_recurse_submodules),
>  	OPT_BOOL(0, "dry-run", &dry_run,
>  		 N_("dry run")),
> +	OPT_BOOL(0, "write-fetch-head", &write_fetch_head,
> +		 N_("write fetched references to the FETCH_HEAD file")),
>  	OPT_BOOL('k', "keep", &keep, N_("keep downloaded pack")),
>  	OPT_BOOL('u', "update-head-ok", &update_head_ok,
>  		    N_("allow updating of HEAD ref")),
> @@ -893,7 +900,9 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
>  	const char *what, *kind;
>  	struct ref *rm;
>  	char *url;
> -	const char *filename = dry_run ? "/dev/null" : git_path_fetch_head(the_repository);
> +	const char *filename = (!write_fetch_head
> +				? "/dev/null"
> +				: git_path_fetch_head(the_repository));

Ah, because dry_run ==> !write_fetch_head, so this is an equivalent
translation. Makes sense.

>  	int want_status;
>  	int summary_width = transport_summary_width(ref_map);
>
> @@ -1327,7 +1336,7 @@ static int do_fetch(struct transport *transport,
>  	}
>
>  	/* if not appending, truncate FETCH_HEAD */
> -	if (!append && !dry_run) {
> +	if (!append && write_fetch_head) {
>  		retcode = truncate_fetch_head();
>  		if (retcode)
>  			goto cleanup;
> @@ -1594,7 +1603,7 @@ static int fetch_multiple(struct string_list *list, int max_children)
>  	int i, result = 0;
>  	struct argv_array argv = ARGV_ARRAY_INIT;
>
> -	if (!append && !dry_run) {
> +	if (!append && write_fetch_head) {
>  		int errcode = truncate_fetch_head();
>  		if (errcode)
>  			return errcode;
> @@ -1795,6 +1804,10 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
>  	if (depth || deepen_since || deepen_not.nr)
>  		deepen = 1;
>
> +	/* FETCH_HEAD never gets updated in --dry-run mode */
> +	if (dry_run)
> +		write_fetch_head = 0;
> +
>  	if (all) {
>  		if (argc == 1)
>  			die(_("fetch --all does not take a repository argument"));
> diff --git a/builtin/pull.c b/builtin/pull.c
> index 8159c5d7c9..e988d92b53 100644
> --- a/builtin/pull.c
> +++ b/builtin/pull.c
> @@ -527,7 +527,8 @@ static int run_fetch(const char *repo, const char **refspecs)
>  	struct argv_array args = ARGV_ARRAY_INIT;
>  	int ret;
>
> -	argv_array_pushl(&args, "fetch", "--update-head-ok", NULL);
> +	argv_array_pushl(&args, "fetch", "--update-head-ok",
> +			 "--write-fetch-head", NULL);

...and here we pass '--write-fetch-head' explicitly, because we don't
want a user who has set 'fetch.writeFetchHead' to 'false' to suddenly
have their 'git pull's stop working. Makes sense.

>
>  	/* Shared options */
>  	argv_push_verbosity(&args);
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index a66dbe0bde..3052c2d8d5 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -539,13 +539,48 @@ test_expect_success 'fetch into the current branch with --update-head-ok' '
>
>  '
>
> -test_expect_success 'fetch --dry-run' '
> -
> +test_expect_success 'fetch --dry-run does not touch FETCH_HEAD' '
>  	rm -f .git/FETCH_HEAD &&
>  	git fetch --dry-run . &&
>  	! test -f .git/FETCH_HEAD
>  '
>
> +test_expect_success '--no-write-fetch-head does not touch FETCH_HEAD' '
> +	rm -f .git/FETCH_HEAD &&
> +	git fetch --no-write-fetch-head . &&
> +	! test -f .git/FETCH_HEAD
> +'
> +
> +test_expect_success '--write-fetch-head gets defeated by --dry-run' '
> +	rm -f .git/FETCH_HEAD &&
> +	git fetch --dry-run --write-fetch-head . &&
> +	! test -f .git/FETCH_HEAD
> +'
> +
> +test_expect_success 'fetch.writeFetchHEAD and FETCH_HEAD' '
> +	rm -f .git/FETCH_HEAD &&
> +	git -c fetch.writeFetchHEAD=no fetch . &&
> +	! test -f .git/FETCH_HEAD
> +'
> +
> +test_expect_success 'fetch.writeFetchHEAD gets defeated by --dry-run' '
> +	rm -f .git/FETCH_HEAD &&
> +	git -c fetch.writeFetchHEAD=yes fetch --dry-run . &&
> +	! test -f .git/FETCH_HEAD
> +'
> +
> +test_expect_success 'fetch.writeFetchHEAD and --no-write-fetch-head' '
> +	rm -f .git/FETCH_HEAD &&
> +	git -c fetch.writeFetchHEAD=yes fetch --no-write-fetch-head . &&
> +	! test -f .git/FETCH_HEAD
> +'
> +
> +test_expect_success 'fetch.writeFetchHEAD and --write-fetch-head' '
> +	rm -f .git/FETCH_HEAD &&
> +	git -c fetch.writeFetchHEAD=no fetch --write-fetch-head . &&
> +	test -f .git/FETCH_HEAD
> +'
> +
>  test_expect_success "should be able to fetch with duplicate refspecs" '
>  	mkdir dups &&
>  	(

Test coverage all looks good, thanks for working on this. I don't think
there's anything left, so this would be great after 2.28 is released.

  Reviewed-by: Taylor Blau <me@ttaylorr.com>

> --
> 2.28.0-rc0
>

Thanks,
Taylor

  reply	other threads:[~2020-07-13 19:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-11 20:48 FETCH_HEAD files and mirrored repos Konstantin Ryabitsev
2020-07-11 21:07 ` Junio C Hamano
2020-07-11 21:19   ` Konstantin Ryabitsev
2020-07-12 17:33     ` Junio C Hamano
2020-07-12 20:25       ` Konstantin Ryabitsev
2020-07-12 20:52         ` Junio C Hamano
2020-07-12 21:54           ` Konstantin Ryabitsev
2020-07-13 17:09           ` Johannes Sixt
2020-07-13 17:13             ` Junio C Hamano
2020-07-13 18:06               ` [PATCH] fetch: optionally allow disabling FETCH_HEAD update Junio C Hamano
2020-07-13 19:08                 ` Taylor Blau [this message]
2020-07-13 19:45                   ` Junio C Hamano
2020-07-13 20:00               ` FETCH_HEAD files and mirrored repos Konstantin Ryabitsev
2020-07-13 20:04                 ` Junio C Hamano
2020-07-13 20:22                   ` Jeff King
2020-07-13 20:34                     ` Konstantin Ryabitsev
2020-07-13 20:50                       ` Jeff King
2020-07-13 20:43                     ` Johannes Sixt
2020-07-14  4:11             ` Jonathan Nieder

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=20200713190834.GA77607@syl.lan \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=konstantin@linuxfoundation.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 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).