Re: [PATCH] format-patch: add --mboxrd alias for --pretty=mboxrd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric Wong <e@xxxxxxxxx> writes:

> As I noted in the commit message, I think discussing --pretty=*
> in the context of format-patch would be confusing for users.

Sensible.

>> > +	if (mboxrd)
>> > +		rev.commit_format = CMIT_FMT_MBOXRD;
>> > +
>
> It could be something like this:
>
> 	if (rev.commit_format == CMIT_FMT_MBOXRD && !use_stdout)
> 		warning("mboxrd without --stdout makes no sense\n");
>
> But I'm on the fence about the warning.

Does it really hurt when generating individual files, or does it
naturally degenerate to the same as the plain old mbox, or
something?  If it does not hurt, then let's not clutter the output
with a message that may make the user worried unnecessarily.

Having said all that, if --pretty=mboxrd is usable, do we really
need the --mboxrd short-hand?  If we plan to eventually switch the
default output format to mboxrd (which I am assuming your longer
term vision), wouldn't it be the traditional format that may need a
short-hand when something goes wrong?

This change does not seem to be something we cannot live without,
and as a step in the direction to move all of us to mboxrd, this
feels somewhat a roundabout step.  I wonder if it would be more
direct to

 - declare that we will eventually switch to use mboxrd by default;

 - give a configuration knob to retain the current email as default;

 - do the usual deprecation dance.

After all, between email and mboxrd, the e-mailed patch format is
not something we choose per-invocation basis, is it?

Picking a suitable format per project and setting it in .git/config,
or picking a suitble format for yourself and setting it in
~/.gitconfig, and not having to think about it afterwards may be a
better use of our users' time.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux