git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Amate Yolande <yolandeamate@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Adds configuration options for some commonly used command-line options (GSOC micro-project)
Date: Wed, 04 Mar 2015 17:11:38 -0800	[thread overview]
Message-ID: <xmqqvbig5jud.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAFAMDXbY6szmQ-gLB0_j2cYRVHCsJfszw2XU16eb6i5NJPX_pQ@mail.gmail.com> (Amate Yolande's message of "Thu, 5 Mar 2015 00:59:48 +0100")

Amate Yolande <yolandeamate@gmail.com> writes:

> 	This is a patch for my work on one of the micro projects, as I intend
> to apply for the Google Summer of Code 2015 under the Git community.
> This patch gives the user the oppotunity to specify configuration
> options for some commonly used command-line options for exampel:
> 	git config defopt.am 'am -3'
> ---

Check Documentaiton/SubmittingPatches again?  It would be beneficial
to use the output of "git log --no-merges" for recent history to see
the recommended style of log messages while studying it.

>  Makefile |    1 +
>  defopt.c |   24 ++++++++++++++++++++++++
>  git.c    |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Docs and tests?

> +static int handle_defopt(int *argcp, const char ***argv)
> +{	
> +	int envchanged = 0, ret = 0, saved_errno = errno;

What is the point of having a local envchanged here, receiving the
info from handle_options() only to discard?

> +	subdir = setup_git_directory_gently(&unused_nongit);
> + ...
> +	if (subdir && chdir(subdir))
> +		die_errno("Cannot change to '%s'", subdir);

Why do you need to do this chdir() here?  Wouldn't the caller of the
codepath after the callsite you added the call to this function go
to the top-level as necessary already?

> +	errno = saved_errno;
> +
> +}
> +
> +
>  static int handle_alias(int *argcp, const char ***argv)
>  {
>  	int envchanged = 0, ret = 0, saved_errno = errno;
> @@ -517,6 +570,9 @@ static void handle_builtin(int argc, const char **argv)
>  		argv[1] = argv[0];
>  		argv[0] = cmd = "help";
>  	}
> +	
> +	if(is_builtin(cmd) && argc == 1)
> +		handle_defopt(&argc, &argv);

You used "am -3" as an example, but is "am" a built-in?

Even if it were, being able to say "git am" (no arguments) and
getting that rewritten to "git am -3", only when there is no other
arguments, is not all that useful, as a typical workflow with "am"
is to save a series of patches in a mailbox file (e.g. I would save
the message I am responding to in ./+ay-defopt.mbox) and then feed
that as an argument (e.g. "git am ./+ay-defopt.mbox").

A lazier version of me (but not me who is typing this message) might
appreciate it if "git am ./+ay-defopt.mbox" gets rewritten to "git
am -3 ./+ay-defopt.mbox" by setting "git config am.threeway yes"
once, while having an option to countermand that per invocation, by
saying "git am --no-3way ./+ay-defopt.mbox".

I think what I am saying is that an ultra-generic solution like the
patch I am commenting on implements is way too simple to be useful.

With today's code, our users can do this once:

    git config alias.am3 "am -3"

and then "git am3 ./+ay-defopt.mbox" would behave as if they typed
"git am -3 ./+ay-defopt.mbox", which would already be one step more
useful than this "only when there is no argument" design.

I think the problem with this patch ultimately came from a poor
phrasing of the Micro suggestion, which said something like "find
some common command options and add configuration".  It was meant to
allow many different people to do many different things (i.e. one
person does am.threeway and am.threeway only), not an invitation to
design something that is generic that covers all these command
options in one go.

So, perhaps limit the scope of Micro to a single command with a few
commonly desired configured options and try again?

Thanks.

      reply	other threads:[~2015-03-05  1:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 23:59 [PATCH] Adds configuration options for some commonly used command-line options (GSOC micro-project) Amate Yolande
2015-03-05  1:11 ` Junio C Hamano [this message]

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=xmqqvbig5jud.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=yolandeamate@gmail.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).