All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Guillaume Pagès" <guillaume.pages@ensimag.grenoble-inp.fr>
Cc: git@vger.kernel.org,
	Remi Galan <remi.galan-alfonso@ensimag.grenoble-inp.fr>,
	Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>,
	Louis-Alexandre Stuber 
	<louis--alexandre.stuber@ensimag.grenoble-inp.fr>,
	Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH 3/4] status: give more information during rebase -i
Date: Mon, 08 Jun 2015 15:11:20 -0700	[thread overview]
Message-ID: <xmqq7frd97g7.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1433775308-5451-1-git-send-email-guillaume.pages@ensimag.grenoble-inp.fr> ("Guillaume Pagès"'s message of "Mon, 8 Jun 2015 16:55:07 +0200")

Guillaume Pagès  <guillaume.pages@ensimag.grenoble-inp.fr> writes:

> git status gives more information during rebase -i, about the list of
> command that are done during the rebase. It displays the two last
> commands executed and the two next lines to be executed. It also gives
> hints to find the whole files in .git directory.
> ---

Without 1/4 and 2/4 in the same thread, it is hard to guess what you
wanted to do with these two patches.  Remember, reviewers review not
just your patches but those from many others.

I would in the meantime assume these are replacement patches for the
ones in

  http://thread.gmane.org/gmane.comp.version-control.git/270743/focus=270744

> diff --git a/wt-status.c b/wt-status.c
> index c83eca5..7f88470 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1026,12 +1026,73 @@ static int split_commit_in_progress(struct wt_status *s)
>  	return split_in_progress;
>  }
>  
> +static void show_rebase_information(struct wt_status *s,
> +				    struct wt_status_state *state,
> +				    const char *color)
> +{
> +	if (state->rebase_interactive_in_progress) {
> +		int i, begin;
> +		int lines_to_show_nr = 2;

"lines_to_show = 2" or "nr_lines_to_show = 2" would be easier to read.

> +
> +		struct strbuf buf = STRBUF_INIT;
> +		struct string_list have_done = STRING_LIST_INIT_DUP;
> +		struct string_list yet_to_do = STRING_LIST_INIT_DUP;
> +
> +		strbuf_read_file(&buf, git_path("rebase-merge/done"), 0);
> +		stripspace(&buf, 1);
> +		have_done.nr = string_list_split(&have_done, buf.buf, '\n', -1);
> +		string_list_remove_empty_items(&have_done, 1);
> +		strbuf_release(&buf);
> +
> +		strbuf_read_file(&buf, git_path("rebase-merge/git-rebase-todo"), 0);
> +		stripspace(&buf, 1);
> +		string_list_split(&yet_to_do, buf.buf, '\n', -1);
> +		string_list_remove_empty_items(&yet_to_do, 1);
> +		strbuf_release(&buf);
> +
> +		if (have_done.nr == 0)
> +			status_printf_ln(s, color, _("No commands done."));

Do the users even need to be told that, I wonder?

> +		else{

Style:	"else {"

> +			status_printf_ln(s, color,
> +				Q_("Last command done (%d command done):",
> +					"Last commands done (%d commands done):",
> +					have_done.nr),
> +				have_done.nr);
> +			begin = (have_done.nr > lines_to_show_nr) ? have_done.nr-lines_to_show_nr : 0;
> +			for (i = begin; i < have_done.nr; i++) {
> +				status_printf_ln(s, color, "   %s", have_done.items[i].string);
> +			}

Hmm, perhaps fold lines like this (and you do not need "begin")?

			for (i = (lines_to_show_nr < have_done.nr)
                             ? have_done.nr - lines_to_show_nr : 0;
                             i < have_done.nr;
                             i++)
				status_printf_ln(...);

> +			if (have_done.nr > lines_to_show_nr && s->hints)
> +			   status_printf_ln(s, color,
> +				_("  (see more in file %s)"), git_path("rebase-merge/done"));

That's a nice touch ;-)

> +		}
> +		if (yet_to_do.nr == 0)
> +			status_printf_ln(s, color,
> +					 _("No commands remaining."));

This I can see why we may want to say it.

> +		else{
> +
> +			status_printf_ln(s, color,
> +				Q_("Next command to do (%d remaining command):",
> +					"Next commands to do (%d remaining commands):",
> +					yet_to_do.nr),
> +				yet_to_do.nr);
> +			for (i = 0; i < lines_to_show_nr && i < yet_to_do.nr; i++) {
> +				status_printf_ln(s, color, "   %s", yet_to_do.items[i].string);
> +			}
> +			if (s->hints)
> +			   status_printf_ln(s, color,
> +				_("  (use \"git rebase --edit-todo\" to view and edit)"));
> +		}

Make sure you do not leak memory used by two string lists here...

> +	}
> +}
> +
>  static void show_rebase_in_progress(struct wt_status *s,
>  				struct wt_status_state *state,
>  				const char *color)
>  {
>  	struct stat st;
>  
> +	show_rebase_information(s, state, color);
>  	if (has_unmerged(s) || state->rebase_in_progress || !stat(git_path("MERGE_MSG"), &st)) {
>  		if (state->branch)
>  			status_printf_ln(s, color,

  parent reply	other threads:[~2015-06-08 22:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 14:55 [PATCH 3/4] status: give more information during rebase -i Guillaume Pagès
2015-06-08 14:55 ` [PATCH 4/4] status: add new tests for status " Guillaume Pagès
2015-06-08 16:17 ` [PATCH 3/4] status: give more information " Matthieu Moy
2015-06-08 22:11 ` Junio C Hamano [this message]
2015-06-09  8:57   ` Guillaume Pages
  -- strict thread matches above, loose matches on Subject: below --
2015-06-09 14:42 [PATCH 1/4] status: factor two rebase-related messages together Guillaume Pagès
2015-06-09 14:42 ` [PATCH 3/4] status: give more information during rebase -i Guillaume Pagès
2015-06-03 22:00 [PATCH 1/4] status: factor two rebase-related messages together Guillaume Pagès
2015-06-03 22:00 ` [PATCH 3/4] status: give more information during rebase -i Guillaume Pagès
2015-06-04  8:06   ` Matthieu Moy
2015-06-04 17:19     ` Junio C Hamano
2015-06-05 16:35       ` Guillaume Pages
2015-06-05 17:11         ` Junio C Hamano

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=xmqq7frd97g7.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=antoine.delaite@ensimag.grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=guillaume.pages@ensimag.grenoble-inp.fr \
    --cc=louis--alexandre.stuber@ensimag.grenoble-inp.fr \
    --cc=remi.galan-alfonso@ensimag.grenoble-inp.fr \
    --cc=remi.lespinet@ensimag.grenoble-inp.fr \
    /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.