git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Pratik Karki <predatoramigo@gmail.com>
Cc: git@vger.kernel.org, christian.couder@gmail.com,
	Johannes.Schindelin@gmx.de, sbeller@google.com,
	alban.gruin@gmail.com
Subject: Re: [PATCH v2 4/4] builtin/rebase: support running "git rebase <upstream>"
Date: Tue, 03 Jul 2018 14:42:33 -0700	[thread overview]
Message-ID: <xmqqfu10nghi.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180702091509.15950-5-predatoramigo@gmail.com> (Pratik Karki's message of "Mon, 2 Jul 2018 15:00:09 +0545")

Pratik Karki <predatoramigo@gmail.com> writes:

> +static struct commit *peel_committish(const char *name)
> +{
> +	struct object *obj;
> +	struct object_id oid;

It by itself is not a big enough deal to warrant a reroll, but
please make it a habit to leave a blank line between the
declarations and the first statement (i.e. here), to help readers.

> +	if (get_oid(name, &oid))
> +		return NULL;
> +	obj = parse_object(&oid);
> +	return (struct commit *)peel_to_type(name, 0, obj, OBJ_COMMIT);
> +}
> +

> +{
> +	const char *argv[] = { NULL, NULL };
> +	struct strbuf script_snippet = STRBUF_INIT;
> +	struct argv_array env = ARGV_ARRAY_INIT;
> +	int status;
> +	const char *backend, *backend_func;
> +
> +	argv_array_pushf(&env, "upstream_name=%s", opts->upstream_name);
> +	argv_array_pushf(&env, "GIT_DIR=%s", absolute_path(get_git_dir()));
> +	argv_array_pushf(&env, "upstream=%s",
> +				oid_to_hex(&opts->upstream->object.oid));
> +	argv_array_pushf(&env, "orig_head=%s", oid_to_hex(&opts->orig_head));
> +	argv_array_pushf(&env, "onto=%s",
> +				oid_to_hex(&opts->onto->object.oid));
> +	argv_array_pushf(&env, "onto_name=%s", opts->onto_name);
> +	argv_array_pushf(&env, "revisions=%s", opts->revisions);
> +
> +	switch (opts->type) {
> +		case REBASE_AM:
> +			backend = "git-rebase--am";
> +			backend_func = "git_rebase__am";
> +			break;
> +		case REBASE_INTERACTIVE:
> +			backend = "git-rebase--interactive";
> +			backend_func = "git_rebase__interactive";
> +			break;
> +		case REBASE_MERGE:
> +			backend = "git-rebase--merge";
> +			backend_func = "git_rebase__merge";
> +			break;
> +		case REBASE_PRESERVE_MERGES:
> +			backend = "git-rebase--preserve-merges";
> +			backend_func = "git_rebase__preserve_merges";
> +			break;
> +		default:
> +			BUG("Unhandled rebase type %d", opts->type);
> +			break;

De-dent these lines so that case/default and switch all sit on the
same column, and the body of each case arm is indented one level
deeper than the case labels.

> +	}
> +
> +	strbuf_addf(&script_snippet,
> +		    ". git-rebase--common && . %s && %s",
> +		    backend, backend_func);
> +	argv[0] = script_snippet.buf;
> +
> +	status = run_command_v_opt_cd_env(argv, RUN_USING_SHELL, NULL,
> +					  env.argv);

Hmph.  These shell variables that tell rebase backend scriptlets
what rebase frontend figured out about the request and current state
used to be just plain shell variables that are not exported.  Now
they are exported and visible even to subprocesses these scriptlets
spawn.  That does not sound safe at all, especially GIT_DIR being
among these variables (git-sh-setup sets GIT_DIR but does not export
it and that has been very much deliberate).

You should actually be able to avoid exporthing them by building
these variable assignment into script_snippet (you need to quote the
values properly, using quote.c::sq_quote_buf() etc.), I think, and
that would be a more faithful-to-the-original safe covnersion.

Thanks for a pleasant read.  This step smells more like WIP, but I
can see it is already moving in the right direction.  The previous
ones (except for the issues I noticed and sent responses separately)
looked more-or-less good, too.



  reply	other threads:[~2018-07-03 21:42 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28  7:46 [GSoC] [PATCH 0/5] rebase: rewrite rebase in C Pratik Karki
2018-06-28  7:46 ` [PATCH 1/5] Start TODO-rebase.sh Pratik Karki
2018-06-28  9:17   ` Pratik Karki
2018-06-28  7:46 ` [PATCH 2/5] rebase: start implementing it as a builtin Pratik Karki
2018-06-28  8:08   ` Christian Couder
2018-06-28 18:49   ` Stefan Beller
2018-06-28  7:46 ` [PATCH 3/5] rebase: refactor common shell functions into their own file Pratik Karki
2018-06-28  8:02   ` Christian Couder
2018-06-28 19:17   ` Stefan Beller
2018-06-28  7:46 ` [PATCH 4/5] sequencer: refactor the code to detach HEAD to checkout.c Pratik Karki
2018-06-28  8:14   ` Christian Couder
2018-06-28 21:19   ` Stefan Beller
2018-06-28  7:46 ` [PATCH 5/5] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-06-28 21:58   ` Stefan Beller
2018-07-02  9:15 ` [GSoC] [PATCH v2 0/4] rebase: rewrite rebase in C Pratik Karki
2018-07-02  9:15   ` [PATCH v2 1/4] rebase: start implementing it as a builtin Pratik Karki
2018-07-03 21:09     ` Junio C Hamano
2018-07-02  9:15   ` [PATCH v2 2/4] rebase: refactor common shell functions into their own file Pratik Karki
2018-07-03 21:13     ` Junio C Hamano
2018-07-02  9:15   ` [PATCH v2 3/4] sequencer: refactor the code to detach HEAD to checkout.c Pratik Karki
2018-07-03 21:26     ` Junio C Hamano
2018-07-02  9:15   ` [PATCH v2 4/4] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-07-03 21:42     ` Junio C Hamano [this message]
2018-07-06 12:08 ` [GSoC] [PATCH v3 0/4] rebase: rewrite rebase in C Pratik Karki
2018-07-06 12:08   ` [PATCH v3 1/4] rebase: start implementing it as a builtin Pratik Karki
2018-07-06 21:09     ` Junio C Hamano
2018-07-06 12:08   ` [PATCH v3 2/4] rebase: refactor common shell functions into their own file Pratik Karki
2018-07-06 12:36     ` Johannes Schindelin
2018-07-06 12:08   ` [PATCH v3 3/4] sequencer: refactor the code to detach HEAD to checkout.c Pratik Karki
2018-07-06 12:08   ` [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-07-06 21:30     ` Junio C Hamano
2018-07-07  6:45     ` Christian Couder
2018-07-07 11:59       ` Johannes Schindelin
2018-07-07 16:24       ` Junio C Hamano
2018-07-17 21:49     ` Beat Bolli
2018-07-17 21:55       ` Beat Bolli
2018-07-08 18:01 ` [GSoC] [PATCH v4 0/4] rebase: rewrite rebase in C Pratik Karki
2018-07-08 18:01   ` [PATCH v4 1/4] rebase: start implementing it as a builtin Pratik Karki
2018-07-09  7:59     ` Andrei Rybak
2018-07-09  8:36       ` Eric Sunshine
2018-07-09 17:18         ` Pratik Karki
2018-07-22  9:14     ` Duy Nguyen
2018-07-08 18:01   ` [PATCH v4 2/4] rebase: refactor common shell functions into their own file Pratik Karki
2018-07-08 18:01   ` [PATCH v4 3/4] sequencer: refactor the code to detach HEAD to checkout.c Pratik Karki
2018-07-08 21:31     ` Johannes Schindelin
2018-07-09 17:23       ` Pratik Karki
2018-07-09 16:42     ` Junio C Hamano
2018-07-09 17:20       ` Pratik Karki
2018-07-08 18:01   ` [PATCH v4 4/4] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-07-08 21:44     ` Johannes Schindelin
2018-07-08 21:14   ` [GSoC] [PATCH v4 0/4] rebase: rewrite rebase in C Johannes Schindelin
2018-07-30 16:29   ` [GSoC] [PATCH v5 0/3] " Pratik Karki
2018-07-30 16:29     ` [PATCH v5 1/3] rebase: start implementing it as a builtin Pratik Karki
2018-07-30 16:29     ` [PATCH v5 2/3] rebase: refactor common shell functions into their own file Pratik Karki
2018-07-30 16:29     ` [PATCH v5 3/3] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-08-01  0:17     ` [GSoC] [PATCH v5 0/3] rebase: rewrite rebase in C Pratik Karki
2018-08-06 19:31     ` [GSoC] [PATCH v6 " Pratik Karki
2018-08-06 19:31       ` [GSoC] [PATCH v6 1/3] rebase: start implementing it as a builtin Pratik Karki
2018-08-06 19:31       ` [GSoC] [PATCH v6 2/3] rebase: refactor common shell functions into their own file Pratik Karki
2018-08-06 19:31       ` [GSoC] [PATCH v6 3/3] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-08-16 21:43         ` 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

  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=xmqqfu10nghi.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=alban.gruin@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=predatoramigo@gmail.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.
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).