From: Junio C Hamano <gitster@pobox.com>
To: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: git@vger.kernel.org, Glen Choo <chooglen@google.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v3] Documentation: specify base point when generating MyFirstContribution patchset
Date: Mon, 18 Oct 2021 10:09:46 -0700 [thread overview]
Message-ID: <xmqqzgr6w97p.fsf@gitster.g> (raw)
In-Reply-To: <20211018124106.542050-1-bagasdotme@gmail.com> (Bagas Sanjaya's message of "Mon, 18 Oct 2021 19:41:06 +0700")
Bagas Sanjaya <bagasdotme@gmail.com> 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@gmail.com>
> ---
> 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.
next prev parent reply other threads:[~2021-10-18 17:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 12:41 [PATCH v3] Documentation: specify base point when generating MyFirstContribution patchset Bagas Sanjaya
2021-10-18 17:09 ` Junio C Hamano [this message]
2021-10-18 17:32 ` Glen Choo
2021-10-18 20:08 ` Re* " Junio C Hamano
2021-10-19 4:36 ` Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzgr6w97p.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=bagasdotme@gmail.com \
--cc=chooglen@google.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.