From: Jonathan Nieder <jrnieder@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Christian Couder <chriscool@tuxfamily.org>,
Daniel Barkalow <barkalow@iabervon.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 2/8] revert: Make "commit" and "me" local variables
Date: Wed, 11 May 2011 05:37:04 -0500 [thread overview]
Message-ID: <20110511103704.GB2676@elie> (raw)
In-Reply-To: <1305100822-20470-3-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Currently, "commit" and "me" are global static variables. Since we
> want to develop the functionality to either pick/ revert individual
> commits atomically later in the series, make them local variables.
I suppose the idea is that the current commit and whether we are
cherry-picking or reverting is not global state and should be allowed
to differ between threads, or that for easier debugging we would like
to narrow their scope.
How does this relate to the sequencer series? Maybe the idea is that
they are explicit parameters in the functions that will be exposed
rather than that they are local variables?
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> The variable "me" is nowhere as fundamental as "commit" -- it's
> simply a string derived from a more fundamental "action".
That suggests to me that "action" should probably be made local at the
same time. On second thought, it looks like this commit is doing two
unrelated things ---
- simplifying the state that has to be kept by computing "me"
from "action" on the fly
- narrowing the scope of "commit" and passing it around explicitly
and would be clearer as two separate commits.
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
[...]
> @@ -51,7 +49,7 @@ static size_t xopts_nr, xopts_alloc;
>
> #define GIT_REFLOG_ACTION "GIT_REFLOG_ACTION"
>
> -static char *get_encoding(const char *message);
> +static char *get_encoding(struct commit *commit, const char *message);
If the die is converted to an assert or die("BUG: ...") without
specifying which commit then this first parameter is not needed.
> static const char * const *revert_or_cherry_pick_usage(void)
> {
> @@ -116,7 +114,8 @@ struct commit_message {
> const char *message;
> };
>
> -static int get_message(const char *raw_message, struct commit_message *out)
> +static int get_message(struct commit *commit, const char *raw_message,
> + struct commit_message *out)
Likewise.
[...]
> @@ -187,7 +186,8 @@ static char *get_encoding(const char *message)
> return NULL;
> }
>
> -static void add_message_to_msg(struct strbuf *msgbuf, const char *message)
> +static void add_message_to_msg(struct commit *commit, struct strbuf *msgbuf,
> + const char *message)
Perhaps the new parameter could be "const char *fallback" and the
caller call sha1_to_hex unconditionally? (Yes, it sounds like wasted
computation, but it might be worth the clarity.)
> @@ -200,7 +200,7 @@ static void add_message_to_msg(struct strbuf *msgbuf, const char *message)
> strbuf_addstr(msgbuf, p);
> }
>
> -static int write_cherry_pick_head(void)
> +static int write_cherry_pick_head(struct commit *commit)
Ah, it might not be wasted computation. This could take
commit_sha1_hex as parameter so it only needs to be computed once.
> @@ -319,6 +319,7 @@ static int do_recursive_merge(struct commit *base, struct commit *next,
> int clean, index_fd;
> const char **xopt;
> static struct lock_file index_lock;
> + const char *me = (action == REVERT ? "revert" : "cherry-pick");
Style: I find this clearer without the parentheses (but feel free to
ignore).
[...]
> @@ -402,6 +403,7 @@ static int do_pick_commit(void)
> struct commit_message msg = { NULL, NULL, NULL, NULL, NULL };
> char *defmsg = NULL;
> struct strbuf msgbuf = STRBUF_INIT;
> + const char *me = (action == REVERT ? "revert" : "cherry-pick");
> int res;
>
> if (no_commit) {
> @@ -458,9 +460,10 @@ static int do_pick_commit(void)
> /* TRANSLATORS: The first %s will be "revert" or
> "cherry-pick", the second %s a SHA1 */
> return error(_("%s: cannot parse parent commit %s"),
> - me, sha1_to_hex(parent->object.sha1));
> + action == REVERT ? "revert" : "cherry-pick",
> + sha1_to_hex(parent->object.sha1));
I think one of the computations of "me" is left over.
> @@ -562,10 +565,13 @@ static int prepare_revs(struct rev_info *revs)
> return 0;
> }
>
> -static int read_and_refresh_cache(const char *me)
> +static int read_and_refresh_cache(void)
Since you seem to be moving towards having fewer statics and more
explicit parameters, I think this part is a step backwards. Maybe it
should take "action" as a parameter instead.
> @@ -583,10 +589,12 @@ static int read_and_refresh_cache(const char *me)
> static int revert_or_cherry_pick(int argc, const char **argv)
> {
> struct rev_info revs;
> + struct commit *commit;
> + const char *me;
> int res;
>
> git_config(git_default_config, NULL);
> - me = action == REVERT ? "revert" : "cherry-pick";
> + me = (action == REVERT ? "revert" : "cherry-pick");
Why?
> setenv(GIT_REFLOG_ACTION, me, 0);
> parse_args(argc, argv);
>
Sorry, mostly nitpicks. Still, hope that helps.
Regards,
Jonathan
next prev parent reply other threads:[~2011-05-11 16:07 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 8:00 [PATCH 0/8] Sequencer Foundations Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 1/8] revert: Improve error handling by cascading errors upwards Ramkumar Ramachandra
2011-05-11 9:59 ` Jonathan Nieder
2011-05-13 10:30 ` Ramkumar Ramachandra
2011-05-19 10:39 ` Ramkumar Ramachandra
[not found] ` <20110519091831.GA28723@ramkum.desktop.amazon.com>
2011-05-19 18:03 ` Jonathan Nieder
2011-05-20 6:39 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 2/8] revert: Make "commit" and "me" local variables Ramkumar Ramachandra
2011-05-11 10:37 ` Jonathan Nieder [this message]
2011-05-13 10:02 ` Ramkumar Ramachandra
2011-05-13 21:40 ` Daniel Barkalow
2011-05-11 8:00 ` [PATCH 3/8] revert: Introduce a struct to parse command-line options into Ramkumar Ramachandra
2011-05-11 11:24 ` Jonathan Nieder
2011-05-13 9:32 ` Ramkumar Ramachandra
2011-05-13 10:07 ` Jonathan Nieder
2011-05-13 10:22 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 4/8] revert: Separate cmdline argument handling from the functional code Ramkumar Ramachandra
2011-05-11 11:49 ` Jonathan Nieder
2011-05-13 9:09 ` Ramkumar Ramachandra
2011-05-13 9:35 ` Ramkumar Ramachandra
2011-05-13 9:44 ` Jonathan Nieder
2011-05-11 8:00 ` [PATCH 5/8] revert: Catch incompatible command-line options early Ramkumar Ramachandra
2011-05-11 12:06 ` Jonathan Nieder
2011-05-13 10:07 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 6/8] revert: Introduce head, todo, done files to persist state Ramkumar Ramachandra
2011-05-11 12:47 ` Jonathan Nieder
2011-05-13 10:21 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 7/8] revert: Implement parsing --continue, --abort and --skip Ramkumar Ramachandra
2011-05-11 12:59 ` Jonathan Nieder
2011-05-13 9:16 ` Ramkumar Ramachandra
2011-05-13 9:40 ` Jonathan Nieder
2011-05-11 8:00 ` [PATCH 8/8] revert: Implement --abort processing Ramkumar Ramachandra
2011-05-11 13:14 ` [PATCH 0/8] Sequencer Foundations Jonathan Nieder
2011-05-12 8:19 ` Christian Couder
2011-05-12 8:41 ` Jonathan Nieder
2011-05-12 11:44 ` Jonathan Nieder
2011-05-13 9:11 ` Christian Couder
2011-05-13 10:37 ` Jonathan Nieder
2011-05-16 4:14 ` Christian Couder
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=20110511103704.GB2676@elie \
--to=jrnieder@gmail.com \
--cc=artagnon@gmail.com \
--cc=barkalow@iabervon.org \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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).