git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Diane Gasselin <diane.gasselin@ensimag.imag.fr>
Cc: git@vger.kernel.org, "Axel Bonnet" <axel.bonnet@ensimag.imag.fr>,
	"Clément Poulain" <clement.poulain@ensimag.imag.fr>
Subject: Re: [RFC/ PATCH 2/5] unpack_trees: group errors by type
Date: Wed, 09 Jun 2010 09:50:20 -0700	[thread overview]
Message-ID: <7v39wwp2ur.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: 1276087446-25112-4-git-send-email-diane.gasselin@ensimag.imag.fr

Diane Gasselin <diane.gasselin@ensimag.imag.fr> writes:

> +/*
> + * Store error messages in an array, each case
> + * corresponding to a error message type
> + */
> +typedef enum {
> +	would_overwrite,
> +	not_uptodate_file,
> +	not_uptodate_dir,
> +	would_lose_untracked,
> +	would_lose_untracked_removed,
> +	sparse_not_uptodate_file
> +} unpack_trees_error;
> +#define NB_UNPACK_TREES_ERROR 6
> +struct rejected_files *unpack_rejects[NB_UNPACK_TREES_ERROR];

You folks seem to like global variables a lot...  Isn't there a struct
passed throughout the callchain in unpack_trees that you can attach this
information to?

Also "rejected_files" is not as technically correct (there are symlinks)
as "rejected_paths".

Style: we don't encourage "typedef enum { ... } unpack_trees_error";
instead we tend to just say "enum unpack_trees_error" both in the
definition and in the use.

> +	if (!porcelain) {
> +		error(msg,file,action);
> +		return -1;
> +	}

Style:
	if (!porcelain)
        	return error(msg, file, action);

> +static void free_rejected_files(unpack_trees_error e)
> +{
> +	while(unpack_rejects[e]->list) {

Style:
	while (unpack_rejects[e]->list) {

> +static void display_error_msgs()
> +{
> +	int i;
> +	int hasPorcelain = 0;

Style: we don't encourage camelCase.

Whichever way spelled, "has porcelain?" is puzzling.

Is this about "are we issuing error messages as a Porcelain program, or
are we a plumbing without noisy error messages?"  Or is this about "have
we said anything in the loop, and if so finish the message with
'Aborting'"?  If the former, I would name it after "we are Porcelain";
if the latter, I would name it after "we said something".

> +	for (i=0; i<NB_UNPACK_TREES_ERROR; i++) {

Style:

	for (i = 0; i < NB_UNPACK_TREES_ERROR; i++) {

> +		if (unpack_rejects[i] && unpack_rejects[i]->list) {
> +			hasPorcelain = 1;
> +			struct rejected_files_list *f = unpack_rejects[i]->list;
> +			char *action = unpack_rejects[i]->action;
> +			char *file = malloc(unpack_rejects[i]->size+1);
> +			*file = '\0';
> +			while (f) {
> +				strcat(file,"\t");
> +				strcat(file,f->file);
> +				strcat(file,"\n");
> +				f = f->next;
> +			}
> +			error(unpack_rejects[i]->msg,file,action);
> +			free_rejected_files(i);

It feels wrong to malloc() inside the loop (and without freeing, which is
worse).  At least the code should use strbuf to do something like:

	struct strbuf indented = STRBUF_INIT;
	for (f = unpack_rejects[i]->list; f; f = f->next)
                strbuf_addf(&indented, "\t%s\n", f->file);
	error(..., indented.buf, action);
        strbuf_release(&indented);

  parent reply	other threads:[~2010-06-09 16:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 12:44 [RFC/ PATCH 0/5] unpack_trees: nicer error messages Diane Gasselin
2010-06-09 12:44 ` Diane Gasselin
2010-06-09 12:44   ` [RFC/ PATCH 1/5] tree-walk: do not stop when an error is detected Diane Gasselin
2010-06-09 12:44     ` [RFC/ PATCH 2/5] unpack_trees: group errors by type Diane Gasselin
2010-06-09 12:44       ` [RFC/ PATCH 3/5] unpack_trees_options: update porcelain messages Diane Gasselin
2010-06-09 12:44         ` [RFC/ PATCH 4/5] t3030: update porcelain expected message Diane Gasselin
2010-06-09 12:44           ` [RFC/ PATCH 5/5] t7609: test merge and checkout error messages Diane Gasselin
2010-06-09 20:47             ` Matthieu Moy
2010-06-09 21:10               ` Diane Gasselin
2010-06-09 21:31                 ` Matthieu Moy
2010-06-09 16:51           ` [RFC/ PATCH 4/5] t3030: update porcelain expected message Junio C Hamano
2010-06-09 20:40           ` Matthieu Moy
2010-06-10  1:59             ` Jeff King
2010-06-10  7:47               ` Diane Gasselin
2010-06-09 13:19       ` [RFC/ PATCH 2/5] unpack_trees: group errors by type Diane Gasselin
2010-06-09 16:50       ` Junio C Hamano [this message]
2010-06-10  9:21         ` Diane Gasselin
2010-06-09 20:59       ` Matthieu Moy
2010-06-09 16:49     ` [RFC/ PATCH 1/5] tree-walk: do not stop when an error is detected Junio C Hamano
2010-06-09 17:18       ` Diane Gasselin
2010-06-09 20:54         ` Matthieu Moy

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=7v39wwp2ur.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=axel.bonnet@ensimag.imag.fr \
    --cc=clement.poulain@ensimag.imag.fr \
    --cc=diane.gasselin@ensimag.imag.fr \
    --cc=git@vger.kernel.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.
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).