All of lore.kernel.org
 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 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.