git.vger.kernel.org archive mirror
 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 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).