Re: [PATCH] builtin-commit: add --cached to operate only on index

From: Alex Riesen <raa.lkml@gmail.com>
Date: Nov 27, 2007, 12:57 UTC
Message-ID: <81b0412b0711270457i1d0a05a2nc2715f1918f26f31@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0711271115300.27959@racer.site>

On 27/11/2007, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> [commenting on the patch is a little cumbersome when the mailer does not
> quote it for you...]

Yes, I'm sorry. But being at work I'm extremely lucky to have access to even gmail (it was blocked for almost a month as a virus source. Of course it is a virus source! It is a damn mailbox!)

Show 10 quoted lines

> On Tue, 27 Nov 2007, Alex Riesen wrote:
>
> @@ -550,6 +557,8 @@ static int parse_and_validate_options(int argc, const char *argv[])
>                         free(enc);
>         }
>
> +       if (all)
> +               cached_only = 0;
>
> My reply> I would rather add another !!cached_only to the existing if().

I'm... Not sure. I'm using it like this:

   $ alias gci='git commit --cached'
   $ gci

So sometimes I actually want to override --cached, and just so happens it is always --all case, which seem to be in line with proposals to make --all default commit behavior.

Show 9 quoted lines

> @@ -678,7 +688,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>         }
>
>         if (!prepare_log_message(index_file, prefix) && !in_merge) {
> -               run_status(stdout, index_file, prefix);
> +               if (!cached_only)
> +                       run_status(stdout, index_file, prefix);
>
> My reply> Would it not make more sense to avoid run_status() when no_edit?

Will try it out this evening at home. I suspect you're right :)