git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: git@vger.kernel.org, gitster@pobox.com,
	Ronnie Sahlberg <sahlberg@google.com>
Subject: Re: [PATCH] refs.c: use a stringlist for repack_without_refs
Date: Tue, 18 Nov 2014 15:45:00 -0800	[thread overview]
Message-ID: <20141118234500.GO6527@google.com> (raw)
In-Reply-To: <1416350636-12934-1-git-send-email-sbeller@google.com>

Stefan Beller wrote:

> This patch was heavily inspired by a part of the ref-transactions-rename
> series[1], but people tend to dislike large series and this part is
> relatively easy to take out and unrelated, so I'll send it as a single
> patch.
>
> [1] https://www.mail-archive.com/git@vger.kernel.org/msg60604.html

The above is a useful kind of comment to put below the three-dashes.  It
doesn't explain what the intent behind the patch is, why I should want
this patch when considering whether to upgrade git, or what is going to
break when I consider reverting it as part of fixing something else, so
it doesn't belong in the commit message.

> This patch doesn't intend any functional changes. It is just a refactoring, 
> which replaces a char** array by a stringlist in the function 
> repack_without_refs.

Thanks.  Why, though?  Is it about having something simpler to pass
from builtin/remote.c::remove_branches(), or something else?

> Idea-by: Ronnie Sahlberg <sahlberg@google.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>

Isn't the patch by Ronnie?

Sometimes I send a patch by someone else and make some change that I
don't want them to be blamed for.  Then I keep their sign-off and put
a note in the commit message about the change I made.  See output from

  git log origin/pu --grep='jc:'

for more examples of that.

Some nits below.

> --- a/builtin/remote.c
> +++ b/builtin/remote.c
[...]
> @@ -1325,6 +1319,11 @@ static int prune_remote(const char *remote, int dry_run)
[...]
>  	memset(&states, 0, sizeof(states));
>  	get_remote_ref_states(remote, &states, GET_REF_STATES);
>  
> +	for (i = 0; i < states.stale.nr; i++)
> +		string_list_insert(&delete_refs_list,
> +				   states.stale.items[i].util);
> +
> +
>  	if (states.stale.nr) {

(style) The double blank line looks odd here.

>  		printf_ln(_("Pruning %s"), remote);
>  		printf_ln(_("URL: %s"),
> @@ -1332,24 +1331,17 @@ static int prune_remote(const char *remote, int dry_run)
>  		       ? states.remote->url[0]
>  		       : _("(no URL)"));
>  
> -		delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));

Now that there's no delete_refs array duplicating the string list,
would it make sense to rename delete_refs_list to delete_refs?

As a nice side-effect, that would make the definition of
delete_refs_list and other places it is used appear in the patch.

>  	for (i = 0; i < states.stale.nr; i++) {
>  		const char *refname = states.stale.items[i].util;

(optional) this could be

	for_each_string_list_item(ref, &delete_refs_list) {
		const char *refname = ref->string;
		...

which saves the reader from having to remember what states.stale.items
means.

[...]
> +++ b/refs.c
[...]
> @@ -2639,23 +2639,23 @@ int repack_without_refs(struct string_list *without, struct strbuf *err)
[...]
> -	int i, ret, removed = 0;
> +	int count, ret, removed = 0;
>  
>  	assert(err);
>  
> -	/* Look for a packed ref */

The old code has comments marking sections of the function:

	/* Look for a packed ref */
	/* Avoid processing if we have nothing to do */
	/* Remove refnames from the cache */
	/* Remove any other accumulated cruft */
	/* Write what remains */

Is dropping this comment intended?

> -	for (i = 0; i < n; i++)
> -		if (get_packed_ref(refnames[i]))
> -			break;
> +	count = 0;
> +	for_each_string_list_item(ref_to_delete, without)
> +		if (get_packed_ref(ref_to_delete->string))
> +			count++;

The old code breaks out early as soon as it finds a ref to delete.
Can we do similar?

E.g.

	for (i = 0; i < without->nr; i++)
		if (get_packed_ref(without->items[i].string))
			break;

(not about this patch) Is refs_to_delete leaked?

[...]
> @@ -3738,10 +3738,11 @@ static int ref_update_reject_duplicates(struct ref_update **updates, int n,
>  int ref_transaction_commit(struct ref_transaction *transaction,
>  			   struct strbuf *err)
>  {
> -	int ret = 0, delnum = 0, i;
> -	const char **delnames;
> +	int ret = 0, i;
>  	int n = transaction->nr;
>  	struct ref_update **updates = transaction->updates;
> +	struct string_list refs_to_delete = STRING_LIST_INIT_DUP;

The old code doesn't xstrdup the list items, so _NODUP should work
fine (and be slightly more efficient).

[...]
> @@ -3815,16 +3813,17 @@ int ref_transaction_commit(struct ref_transaction *transaction,
>  			}
>  
>  			if (!(update->flags & REF_ISPRUNING))
> -				delnames[delnum++] = update->lock->ref_name;
> +				string_list_insert(&refs_to_delete,
> +						   update->lock->ref_name);

string_list_append would be analagous to the old code.

[....]
> --- a/refs.h
> +++ b/refs.h
> @@ -163,8 +163,7 @@ extern void rollback_packed_refs(void);
>   */
>  int pack_refs(unsigned int flags);
>  
> -extern int repack_without_refs(const char **refnames, int n,
> -			       struct strbuf *err);
> +extern int repack_without_refs(struct string_list *without, struct strbuf *err);

A comment could mention whether the ref list needs to be sorted.  (It
doesn't, right?)

Thanks and hope that helps,
Jonathan

  parent reply	other threads:[~2014-11-18 23:45 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-18 22:43 [PATCH] refs.c: use a stringlist for repack_without_refs Stefan Beller
2014-11-18 23:06 ` Junio C Hamano
2014-11-18 23:39   ` Junio C Hamano
2014-11-18 23:45 ` Jonathan Nieder [this message]
2014-11-19  0:28   ` Stefan Beller
2014-11-19  1:08   ` Stefan Beller
2014-11-19 18:00     ` Junio C Hamano
2014-11-19 18:50       ` Stefan Beller
2014-11-19 20:44         ` Jonathan Nieder
2014-11-19 21:54           ` Stefan Beller
2014-11-19 21:59             ` [PATCH v4] " Stefan Beller
2014-11-20  2:15               ` Jonathan Nieder
2014-11-20 16:47                 ` Junio C Hamano
2014-11-20 18:04                 ` [PATCH v5 1/1] " Stefan Beller
2014-11-20 18:10                   ` [PATCH] refs.c: repack_without_refs may be called without error string buffer Stefan Beller
2014-11-20 18:15                     ` Ronnie Sahlberg
2014-11-20 18:35                     ` Jonathan Nieder
2014-11-20 18:36                       ` Ronnie Sahlberg
2014-11-20 18:56                         ` Stefan Beller
2014-11-20 18:29                   ` [PATCH v5 1/1] refs.c: use a stringlist for repack_without_refs Jonathan Nieder
2014-11-20 18:37                   ` Jonathan Nieder
2014-11-20 19:01                   ` Junio C Hamano
2014-11-20 19:05                     ` Stefan Beller
2014-11-20 20:07                       ` [PATCH v6] refs.c: use a string_list " Stefan Beller
2014-11-20 20:36                         ` Jonathan Nieder
2014-11-21 14:09         ` [PATCH 0/6] repack_without_refs(): convert to string_list Michael Haggerty
2014-11-21 14:09           ` [PATCH 1/6] prune_remote(): exit early if there are no stale references Michael Haggerty
2014-11-22 21:07             ` Jonathan Nieder
2014-11-21 14:09           ` [PATCH 2/6] prune_remote(): initialize both delete_refs lists in a single loop Michael Haggerty
2014-11-21 14:09           ` [PATCH 3/6] prune_remote(): sort delete_refs_list references en masse Michael Haggerty
2014-11-21 16:44             ` Junio C Hamano
2014-11-25  7:21               ` Michael Haggerty
2014-11-25  8:04                 ` Michael Haggerty
2014-11-22 21:08             ` Jonathan Nieder
2014-11-21 14:09           ` [PATCH 4/6] repack_without_refs(): make the refnames argument a string_list Michael Haggerty
2014-11-22 21:17             ` Jonathan Nieder
2014-11-25  7:42               ` Michael Haggerty
2014-11-21 14:09           ` [PATCH 5/6] prune_remote(): rename local variable Michael Haggerty
2014-11-22 21:18             ` Jonathan Nieder
2014-11-21 14:09           ` [PATCH 6/6] prune_remote(): iterate using for_each_string_list_item() Michael Haggerty
2014-11-22 21:19             ` Jonathan Nieder
2014-11-21 14:25           ` [PATCH 0/6] repack_without_refs(): convert to string_list Michael Haggerty
2014-11-21 18:00             ` Junio C Hamano
2014-11-21 19:57               ` Stefan Beller
2014-11-25  0:28               ` Our cumbersome mailing list workflow (was: Re: [PATCH 0/6] repack_without_refs(): convert to string_list) Michael Haggerty
2014-11-27 17:46                 ` Our cumbersome mailing list workflow Torsten Bögershausen
2014-11-27 18:24                   ` Matthieu Moy
2014-11-28 12:09                     ` Philip Oakley
2014-11-27 22:53                   ` Eric Wong
2014-11-28 15:34                     ` Michael Haggerty
2014-11-28 16:24                       ` brian m. carlson
2014-12-01  2:46                       ` Junio C Hamano
2014-12-03  2:20                         ` Stefan Beller
2014-12-03  3:53                           ` Jonathan Nieder
2014-12-03 17:18                             ` Junio C Hamano
2014-12-03 17:28                           ` Torsten Bögershausen
2014-11-28 14:31                   ` Michael Haggerty
2014-11-28 15:42                     ` Marc Branchaud
2014-11-28 21:39                       ` Damien Robert
2014-12-03 23:57                 ` Philip Oakley
2014-12-04  2:03                   ` Stefan Beller

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=20141118234500.GO6527@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sahlberg@google.com \
    --cc=sbeller@google.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.
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).