Re: `--ancestry-path` documentation has wrong graph

From: Han Jiang <jhcarl0814@gmail.com>
Date: Mar 15, 2025, 08:20 UTC
Message-ID: <CANrWfmRpDFuqv+fkCf_p_ggHTrRjD3Vgviqrai_rA7Lu-YFEMA@mail.gmail.com>
In-Reply-To: <CABPp-BHPAEcJibTaiMVE1K7AvYE+TYmOt7=6XUtcZbm7wsWhDQ@mail.gmail.com>

On Sat, Mar 15, 2025 at 6:16 AM Elijah Newren <newren@gmail.com> wrote:

Show 14 quoted lines

>
> On Thu, Mar 13, 2025 at 2:04 PM Han Jiang <jhcarl0814@gmail.com> wrote:
> >
> > Git - git-log Documentation --ancestry-path[=<commit>]
> > https://git-scm.com/docs/git-log#Documentation/git-log.txt---ancestry-pathltcommitgt-1
> >
> > The graph for `--ancestry-path=H D..M` should contain commit C.
>
> Indeed; D..H contains C, and C is an ancestor of H.  I apparently
> overlooked C in that example when writing that documentation.  Would
> you like to submit a patch, or would you like me to do so and record
> you as the reporter?  I'm fine with either, but if you want to give it
> a try, the relevant file is Documentation/rev-list-options.adoc in the
> repository.

Thank you for the clarification! I'd like to try sending a patch. After doing some research on how to make contributions today, I decided to try GitGitGadget way first. But I got some questions that the doc doesn't clearly explain:

[Git - CodingGuidelines
Documentation](https://git-scm.com/docs/CodingGuidelines) says:
For C programs: We use tabs to indent, and interpret tabs as taking up
to 8 spaces.
1. It seems adoc files treats tabs as 8 spaces too, is that true?
(The prepared commit in forked repository is at
https://github.com/jhcarl0814/git/commit/ce568e4a87dff14df4e7104af89be3f12616f5de
. The source diff shows tabs as 4 spaces. The rich diff shows tabs as
8 spaces. When I was editting the number defaults to 8 and is
adjustable in editor options.)

[Git - MyFirstContribution
Documentation](https://git-scm.com/docs/MyFirstContribution) says:
For single-patch contributions, your commit message should already be
meaningful and explain at a high level the purpose (what is happening
and why) of your patch, so you usually do not need any additional
context. In that case, remove the PR description that GitHub
automatically generates from your commit message (your PR description
should be empty).
2. For single-patch contributions, is the pull request title or the
first line of commit message that will become Subject of the email?

[Git - SubmittingPatches
Documentation](https://git-scm.com/docs/SubmittingPatches) says:
It is a common convention to prefix your subject line with [PATCH].
3. Which one of GitGitGadget or the pull request creator is the one
who add "[PATCH]" at the beginning of the title?

[Git - MyFirstContribution
Documentation](https://git-scm.com/docs/MyFirstContribution) says:
Now that your CI is passing and someone has granted you permission to
use GitGitGadget with the `/allow` command, sending out for review is
as simple as commenting on your PR with `/submit`.
4. Who is able to use `/submit` to trigger email sending action? Is it
the pull request creator (when `/allow`ed) or anyone (`/allow`ed)?
5. If `/submit` sends email, then how to cc all relevant people
(including myself) at the moment of `/submit`? Is there a place to
fill in this parameter?
6. Where does `/submit` send the email to, as a brand new post or as a
reply under this post? How to configure?

----

7. How to make Gmail web client default to bottom-posting?