Re: [PATCH] format-patch: print format-patch usage if there are no arguments

From: Stefan Beller <sbeller@google.com>
Date: Jan 13, 2015, 20:00 UTC
Message-ID: <CAGZ79kYJ+XNktc7_C81xz=BfCP4_hrE=pWW5QGJ1kdXKMf4Jjw@mail.gmail.com>
In-Reply-To: <xmqqppaicwww.fsf@gitster.dls.corp.google.com>

On Tue, Jan 13, 2015 at 11:17 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

> Alexander Kuleshov <kuleshovmail@gmail.com> writes:
>
>> 2015-01-14 0:43 GMT+06:00 Junio C Hamano <gitster@pobox.com>:
>>> Why?
>>
>> As some commands does it when they are executed without arguments,
>> like git config, git blame and etc...
>
> For format-patch, I think the current behaviour is more of the lack
> of implementation of the obvious default.  "git blame" does not have
> any obvious default (would there be a single file you would want to
> dig the history when the user does not tell you which one?  No), so
> it proabaly is the right thing to do to error out.
>
> But I would not surprised if those who build on top of others' work
> to wish that "git format-patch" that was invoked without argument on
> a branch created by "git checkout -t -b" to default to format commits
> since the branch forked from @{upstream}, for example.

My initial reaction was to assume HEAD^ if no arguments are given to format-patch. Though after thinking about it, the behavior you're proposing makes more sense.

Another idea would be to take the first commit which is pointed to by another branch as the first commit in the commit range. I am currently thinking about the atomic patch series which I developed on top of origin/mh/reflog-expire and that would be the first branch you find if you just go back in history and look for any branches. Usually that would be the upstream tracking branch though, so this would be an extension to your proposal.

Though I am not sure if this scales. (Who has many branches anyway? ;)