git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
	"Git List" <git@vger.kernel.org>,
	"Daniel Barkalow" <barkalow@iabervon.org>,
	"Ramkumar Ramachandra" <artagnon@gmail.com>,
	"Dmitry Ivankov" <divanorama@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Eric Herman" <eric@freesa.org>,
	"Fernando Vezzosi" <buccia@repnz.net>
Subject: Re: [PATCH 3/3] fast-export: output reset command for commandline revs
Date: Sun, 6 Nov 2011 00:01:26 -0500	[thread overview]
Message-ID: <20111106050126.GO27272@elie.hsd1.il.comcast.net> (raw)
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>

Sverre Rabbelier wrote:

> When a revision is specified on the commandline we explicitly output
> a 'reset' command for it if it was not handled already. This allows
> for example the remote-helper protocol to use fast-export to create
> branches that point to a commit that has already been exported.
>
> Initial-patch-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>

Thanks.  I'd suggest squashing in the test from patch 1/3 for easy
reference (since each patch makes the other easier to understand).

> ---
>   The if statement dealing with tag_of_filtered_mode is not as
>   elegant as either me or Dscho would have liked, but we couldn't
>   find a better way to determine if a ref is a tag at this point
>   in the code.
>
>   Additionally, the elem->whence != REV_CMD_RIGHT case should really
>   check if REV_CMD_RIGHT_REF, but as this is not provided by the
>   ref_info structure this is left as is. A result of this is that
>   incorrect input will result in incorrect output, rather than an
>   error message. That is: `git fast-export a..<sha1>` will
>   incorrectly generate a `reset <sha1>` statement in the fast-export
>   stream.
>
>   The dwim_ref bit is a double work (it has already been done by the
>   caller of this function), but I decided it would be more work to
>   pass this information along than to recompute it for the few
>   commandline refs that were relevant.

These details seem like good details for the commit message, so the
next puzzled person looking at the code can see what behavior is
deliberate and what are the incidental side-effects.

The "git fast-export a..$(git rev-parse HEAD^{commit})" case sounds
worth a test.

> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -18,6 +18,8 @@
>  #include "parse-options.h"
>  #include "quote.h"
> 
> +#define REF_HANDLED (ALL_REV_FLAGS + 1)

Could TMP_MARK be used for this?

[...]
> @@ -541,10 +543,34 @@ static void handle_reset(const char *name, struct object *object)
>  		       sha1_to_hex(object->sha1));
>  }
>  
> -static void handle_tags_and_duplicates(struct string_list *extra_refs)
> +static void handle_tags_and_duplicates(struct rev_info *revs, struct string_list *extra_refs)
>  {
>  	int i;
>  
> +	/* even if no commits were exported, we need to export the ref */
> +	for (i = 0; i < revs->cmdline.nr; i++) {

Might be clearer in a new function.

> +		struct rev_cmdline_entry *elem = &revs->cmdline.rev[i];
> +
> +		if (elem->flags & UNINTERESTING)
> +			continue;
> +
> +		if (elem->whence != REV_CMD_REV && elem->whence != REV_CMD_RIGHT)
> +			continue;

Oh, neat.

> +
> +		char *full_name;

declaration-after-statement

> +		dwim_ref(elem->name, strlen(elem->name), elem->item->sha1, &full_name);
> +
> +		if (!prefixcmp(full_name, "refs/tags/") &&

What happens if dwim_ref fails, perhaps because a ref was deleted in
the meantime?

> +			(tag_of_filtered_mode != REWRITE ||
> +			!get_object_mark(elem->item)))
> +			continue;

Style nit: this would be easier to read if the "if" condition doesn't
line up with the code below it:

		if (!prefixcmp(full_name, "refs/tags/")) {
			if (tag_of_filtered_mode != REWRITE ||
			    !get_object_mark(elem->item))
				continue;
		}

If tag_of_filtered_mode == ABORT, we are going to die() soon, right?
So this seems to be about tag_of_filtered_mode == DROP --- makes
sense.

When does the !get_object_mark() case come up?

> +
> +		if (!(elem->flags & REF_HANDLED)) {
> +			handle_reset(full_name, elem->item);
> +			elem->flags |= REF_HANDLED;
> +		}

Just curious: is the REF_HANDLED handling actually needed?  What
would happen if fast-export included the redundant resets?

> +	}
[...]
> --- a/t/t9350-fast-export.sh
> +++ b/t/t9350-fast-export.sh
> @@ -446,7 +446,7 @@ from $(git rev-parse master)
>  
>  EOF
>  
> -test_expect_failure 'refs are updated even if no commits need to be exported' '
> +test_expect_success 'refs are updated even if no commits need to be exported' '
>  	git fast-export master..master > actual &&
>  	test_cmp expected actual
>  '

Thanks for a pleasant read.

  reply	other threads:[~2011-11-06  5:02 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-05 23:23 [PATCH 0/3] fast-export fixes Sverre Rabbelier
2011-11-05 23:23 ` [PATCH 1/3] t9350: point out that refs are not updated correctly Sverre Rabbelier
2011-11-06  4:31   ` Jonathan Nieder
2011-11-06 19:38     ` Sverre Rabbelier
2011-11-07  9:32       ` Jonathan Nieder
2012-10-24 17:52   ` Felipe Contreras
2012-10-24 18:08     ` Jonathan Nieder
2012-10-24 19:09       ` Felipe Contreras
2012-10-24 19:11         ` Jonathan Nieder
2012-10-25  4:19           ` Felipe Contreras
2012-10-25  4:27             ` Jonathan Nieder
2012-10-25  5:18               ` Felipe Contreras
2012-10-25  5:28                 ` Jonathan Nieder
2012-10-25  5:39                   ` Sverre Rabbelier
2012-10-25  5:50                     ` Felipe Contreras
2012-10-25  6:07                       ` Sverre Rabbelier
2012-10-25  6:19                         ` Felipe Contreras
2012-10-25  7:06                           ` Sverre Rabbelier
2012-10-25  7:34                             ` Jonathan Nieder
2012-10-25  7:43                               ` Sverre Rabbelier
2012-10-25  7:48                                 ` Jonathan Nieder
2012-10-25  7:50                                   ` Sverre Rabbelier
2012-10-25 13:33                                     ` Felipe Contreras
2012-10-25  5:40                   ` Felipe Contreras
2012-10-25  5:53                     ` Jonathan Nieder
2012-10-25  6:39                       ` Felipe Contreras
2012-10-25  7:18                         ` Jonathan Nieder
2012-10-25 16:43                           ` Felipe Contreras
2012-10-24 21:41     ` Johannes Schindelin
2012-10-25  5:13       ` Felipe Contreras
2011-11-05 23:23 ` [PATCH 2/3] fast-export: do not refer to non-existing marks Sverre Rabbelier
2011-11-06  4:45   ` Jonathan Nieder
2011-11-06 19:40     ` Sverre Rabbelier
2019-01-29 19:41       ` Johannes Schindelin
2011-11-05 23:23 ` [PATCH 3/3] fast-export: output reset command for commandline revs Sverre Rabbelier
2011-11-06  5:01   ` Jonathan Nieder [this message]
2011-11-06 19:48     ` Sverre Rabbelier
2011-11-07  8:58       ` Jonathan Nieder
2011-11-07  5:52   ` Junio C Hamano
2011-11-07  5:53   ` Junio C Hamano
2011-11-30 16:56   ` Thomas Rast
2012-10-24 18:02   ` Felipe Contreras

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=20111106050126.GO27272@elie.hsd1.il.comcast.net \
    --to=jrnieder@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=artagnon@gmail.com \
    --cc=avarab@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=buccia@repnz.net \
    --cc=divanorama@gmail.com \
    --cc=eric@freesa.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=srabbelier@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).