Bagas Sanjaya <bagasdotme@xxxxxxxxx> writes:
> Specifying base point (commit hash) can help reviewers and testers
> interested on the patchset. Mention how to record it with `--base`
> option to `format-patch`.
>
> Signed-off-by: Bagas Sanjaya <bagasdotme@xxxxxxxxx>
> ---
> Changes since v3 [1]:
> - rewording (suggested by Glen)
>
> I don't apply Junio's suggestion that use `--base=auto`, because in
> most cases invocations of the option requires full hash of base object
> and AFAIK people just do `git checkout -b` without specifying the
> tracking option (`-t`).
That's actually quite sad, if it were true.
Our home, when we added "end-user/newbie friendly features" to
"checkout" (credit goes to Dscho, IIRC), was actually most new
people would not even have to say "-b" in the simplest tasks
(instead they rely on "git checkout foo" gets turned into "git
checkout -t -b foo origin/foo" by DWIMmery) and the fact that
branch.autoSetupMerge defaulting to 'true' so that they get the @{u}
and --base=auto support without even saying "-t" (as long as they do
not explicitly decline with "--no-track" from the command line, that
is).
> -$ git format-patch --cover-letter -o psuh/ master..psuh
> +$ git show -s --format="%H" master
I said this is not good in my previous response already and told you
to teach merge-base, if we were not to use the --base=auto, didn't I?
The range given to format-patch, i.e. master..psuh, would be the
correct range of commits to format, as long as you didn't rewind the
local master branch.
But that does not mean master would always be the right base, does
it? What if you had a work totally unrelated to the contents of
this tutorial on the 'master' front? The person on the receiving
end may not even know what object it refers to until you pushed your
'master' branch out.
