Re: [PATCH 2/4] doc: git-pull: clarify options for integrating remote branch

From: Chris Torek <chris.torek@gmail.com>
Date: Sep 24, 2025, 22:38 UTC
Message-ID: <CAPx1GvfK5ZKUG86n=DR8LeO_STwO5FAkDzzD9t6d9R22KdOySg@mail.gmail.com>
In-Reply-To: <CALnO6CCkWaxZKGseHR7dk20erFPAvGMqO+OYr3Np+y+=1Y34HA@mail.gmail.com>

On Wed, Sep 24, 2025 at 1:23 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:

Show 5 quoted lines

> > +First, `git pull` runs `git fetch` with the same arguments to fetch
>
> Hm. Is it worth saying "similar" rather than "same" since we don't
> pass e.g. `--rebase` to `git fetch`? Or is that detail unimportant in
> this context?

I would suggest "equivalent" or (perhaps better) "appropriate". Perhaps even:

    First, `git pull` runs the equivalent of `git fetch` with the
    arguments needed to fetch necessary branches from
    the remote ...

Definition of these arguments can be deferred (perhaps even indefinitely); but:

Show 5 quoted lines

> > +remote branch(es). Then it integrates the remote branch into the current
> > +branch.
>
> Plural-singular here leaves me wondering how Git decides which of
> multiple fetched branches to integrate.

here we'd need something along the lines of:

    Then it integrates the appropriate remote branch ...

and here we *do* have to define "appropriate".

(Historically the merge step grabbed stuff from FETCH_HEAD, excluding all the "not-for-merge" parts, and I have never dug into what happens now...)

Chris