All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Shumaker <lukeshu@lukeshu.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Luke Shumaker <lukeshu@lukeshu.com>,
	git@vger.kernel.org, Luke Shumaker <lukeshu@datawire.io>,
	Elijah Newren <newren@gmail.com>, Jeff King <peff@peff.net>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC PATCH] fast-export, fast-import: Let tags specify an internal name
Date: Wed, 21 Apr 2021 10:34:28 -0600	[thread overview]
Message-ID: <87k0ov38bv.wl-lukeshu@lukeshu.com> (raw)
In-Reply-To: <8735vk3vyq.fsf@evledraar.gmail.com>

On Wed, 21 Apr 2021 02:03:57 -0600,
Ævar Arnfjörð Bjarmason wrote:
> On Tue, Apr 20 2021, Luke Shumaker wrote:
> 
> > -static void handle_tag(const char *name, struct tag *tag)
> > +static void handle_tag(const char *refname, struct tag *tag)
> >  {
> >  	unsigned long size;
> >  	enum object_type type;
> >  	char *buf;
> > -	const char *tagger, *tagger_end, *message;
> > +	const char *refbasename;
> > +	const char *tagname, *tagname_end, *tagger, *tagger_end, *message;
> 
> Let's put the new "*tagname, *tagname_end" on its own line, the current
> convention is to not conflate unrelated variable declarations on the
> same line (as e.g. the existing "message" and "tagger" does.

Ack.

> >  	size_t message_size = 0;
> >  	struct object *tagged;
> >  	int tagged_mark;
> > @@ -800,6 +801,11 @@ static void handle_tag(const char *name, struct tag *tag)
> >  		message += 2;
> >  		message_size = strlen(message);
> >  	}
> > +	tagname = memmem(buf, message ? message - buf : size, "\ntag ", 5);
> > +	if (!tagname)
> > +		die("malformed tag %s", oid_to_hex(&tag->object.oid));
> > +	tagname += 5;
> > +	tagname_end = strchrnul(tagname, '\n');
> 
> So it's no longer possible to export a reporitory with a missing "tag"
> entry in a tag? Maybe OK, but we have an escape hatch for it with fsck,
> we don't need one here?
> 
> In any case a test for it would be good to have.

I hadn't realized that it was possible for a tag object to be missing
the "tag" entry, I will fix that.

I don't think it's worth adding an option to fast-import to make it
possible to create such an object, but fast-export should be able to
handle it (and emit it in the stream such that fast-import would
create it with the "tag" entry").

Yes, the whole patch needs tests.

> > @@ -884,14 +890,19 @@ static void handle_tag(const char *name, struct tag *tag)
> >  
> >  	if (tagged->type == OBJ_TAG) {
> >  		printf("reset %s\nfrom %s\n\n",
> > -		       name, oid_to_hex(&null_oid));
> > +		       refname, oid_to_hex(&null_oid));
> >  	}
> > -	skip_prefix(name, "refs/tags/", &name);
> > -	printf("tag %s\n", name);
> > +	refbasename = refname;
> > +	skip_prefix(refbasename, "refs/tags/", &refbasename);
> > +	printf("tag %s\n", refbasename);
> >  	if (mark_tags) {
> >  		mark_next_object(&tag->object);
> >  		printf("mark :%"PRIu32"\n", last_idnum);
> >  	}
> > +	if ((size_t)(tagname_end - tagname) != strlen(refbasename) ||
> 
> Would be more readable IMO to have a temporary variable for that
> "tagname_end - tagname", then just cast that and use it here.
> 
> > +	    strncmp(tagname, refbasename, (size_t)(tagname_end - tagname)))
> 
> and here.

Ack.

> > @@ -2803,6 +2803,13 @@ static void parse_new_tag(const char *arg)
> >  	read_next_command();
> >  	parse_mark();
> >  
> > +	/* name ... */
> > +	if (skip_prefix(command_buf.buf, "name ", &v)) {
> > +		name = strdupa(v);
> > +		read_next_command();
> > +	} else
> > +		name = NULL;
> > +
> 
> Skip this whole (stylistically incorrect, should have {}) and just
> initialize it to NULL when you declare the variable?

In my defense, the guideline has always been to match the local style,
and in fast-import.c this is done without {} 8 times and with {} 3
times :)

-- 
Happy hacking,
~ Luke Shumaker

  reply	other threads:[~2021-04-21 16:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20 19:05 [RFC PATCH] fast-export, fast-import: Let tags specify an internal name Luke Shumaker
2021-04-20 21:40 ` Junio C Hamano
2021-04-21  8:18   ` Ævar Arnfjörð Bjarmason
2021-04-21 16:17     ` Luke Shumaker
2021-04-21 16:59     ` Junio C Hamano
2021-04-21 18:34     ` Elijah Newren
2021-04-21 18:48       ` Luke Shumaker
2021-04-21 19:24         ` Elijah Newren
2021-04-22  8:41       ` Ævar Arnfjörð Bjarmason
2021-04-21 18:41   ` Elijah Newren
2021-04-21 18:54     ` Junio C Hamano
2021-04-21 19:32       ` Elijah Newren
2021-04-22  8:54         ` Ævar Arnfjörð Bjarmason
2021-04-22 19:37           ` Elijah Newren
2021-04-21  8:03 ` Ævar Arnfjörð Bjarmason
2021-04-21 16:34   ` Luke Shumaker [this message]
2021-04-21 17:26     ` Luke Shumaker
2021-04-21 18:26     ` Elijah Newren
2021-04-21 17:48   ` Junio C Hamano
2021-04-23 16:47 ` Luke Shumaker

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=87k0ov38bv.wl-lukeshu@lukeshu.com \
    --to=lukeshu@lukeshu.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=lukeshu@datawire.io \
    --cc=newren@gmail.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 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.