Re: [take 2] git send-email updates

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 12, 2008, 00:14 UTC
Message-ID: <7vk5b9x0kj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081111221351.GE10073@artemis.corp>

Pierre Habouzit <madcoder@debian.org> writes:

> Oh you mean that if one use --no-format-patch you don't wan't _any_
> option to be passed to format-patch?

The option name --no-format-patch sounded like "I do not want you to act as a frontend, ever", i.e. if you type master..next by mistake on the command line, the command would barf when the option is given. Not even "pass to format-patch", but "do not run format-patch to begin with".

It is not a big deal especially for interactive use (and that is why I said "somewhat" unfortunate).

Show 11 quoted lines

> If we're really doing this, then maybe we want a 5-state kind of option:
>   1 disallow any file name ;
>   2 if conflict, chose the revision ;
>   3 barf if any conflict arises (default) ;
>   4 if conflict chose the file ;
>   5 disallow any kind of revision argument.
>
> My proposal implements 2 as --format-patch, 3 as default, and 4 as
> --no-format-patch. You propose basically (5) for --no-format-patch
> instead, well I say this makes sense, but it's somehow "sad" not to have
> (1) too in that case.

Actually, "send-email --format-patch master..fixes Documentation/" may be a useful command to send out only documentation fixes. For such a usage, Documentation/ should not be taken as a maildir. If we would want to support such usage (and I'd say why not), a token can fall into one (or two) of three categories:

    - can it be a rev?

    - is it a tracked path (either blob or a leading dir)?

    - is it a file/dir that is not tracked?

The first two would be format-patch candidate. The last one is the traditional mail source. Because the latter two are disjoint set, and because it does not matter if you have a tracked file 'master' and a branch 'master' in your repo (either will be passed to format-patch anyway), the actual disambiguity is reduced, but it still is different from what you have in your patch, I suspect.

As to options, how about doing this:

    --no-format-patch means never ever run format-patch, behave exactly as
    before;

    --format-patch means what you have in your patch.  guess and favor 
    format-patch parameter when ambiguous;

    without either option, guess and favor mbox/maildir but still run
    format-patch if remaining parameters and options need to
    (e.g. "send-email my-cover-letter origin/master..master" will find
    my-cover-letter which is not tracked and take it as mbox, and grab
    patches from commits between origin/master..master, and send all of
    them).