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

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Oct 9, 2025, 22:20 UTC
Message-ID: <bf769259-af30-4b13-aa0d-36c244e7502c@app.fastmail.com>
In-Reply-To: <b432f1b9-804d-4249-bc1a-4f3629aff50c@app.fastmail.com>

On Thu, Oct 9, 2025, at 23:31, Julia Evans wrote:

Show 11 quoted lines

> On Wed, Oct 8, 2025, at 5:33 PM, Junio C Hamano wrote:
>>>[snip]
>>> +2. `git pull --rebase` runs `git rebase`
>>
>> This technically does not integrate remote branch into our current
>> branch.  Rather, the commits on our current branch are integrated
>> on top of their history.  That may be worth noting?  I dunno.
>
> At least 2 users who read this also commented that they find the word
> "integrate" using, for perhaps a similar reason. Specifically, one comment
> was "unclear if 'integrate' is a technical/specific term or just generic".

(confusing)

Show 5 quoted lines

>
> My assumption was that the word "integrate" was meant to be a generic
> way to communicate "combine the changes in the two branches in
> some unspecified way", and that's how I was using it. I'm not sure what
> you mean when you say "integrate" (is it "merge"?).

I wonder if “integration” is like “upstream”; frequently used but not really explained? (see gitworkflows(7); one mention in gitglossary(7)).

I think Martin Fowler has the correct (useful) view on branches:[1]

    In thinking about these patterns, I find it useful to develop two
    main categories. One group looks at integration, how multiple
    developers combine their work into a coherent whole. The other looks
    at the path to production, using branching to help manage the route
    from an integrated code base to a product running in production.

Specifically the first category.

Then later:

    Branching is about managing the interplay of isolation and
    integration. Having everyone work on a single shared codebase all
    the time, doesn't work because I can't compile the program if you're
    in the middle of typing a variable name. So at least to some degree,
    we need a notion of a private workspace that I can work on for a
    while. Modern source code controls tools make it easy to branch and
    monitor changes to those branches. At some point however we need to
    integrate. Thinking about branching strategies is really all about
    deciding how and when we integrate.

🔗 1: https://martinfowler.com/articles/branching-patterns.html

The point of *most* branches ought to be this: you need isolation, but you also want to eventually integrate with upstream, the trunk, or whatever else.

• Everyone working on everything at the same time is chaos
• Everyone working on their own thing in isolation forever is
  Balkanization
• Forking a private space to integrate later in a timely manner strikes
  the right balance
• (Then there are the dozens of variations of long-living forks, private
  forks for the changes that you want to make but few others want...)

So I don’t think that

> "combine the changes in the two branches in some unspecified way"

is quite it, because the direction is towards one integration branch, one upstream, one trunk, main branch (not whichever one).

> way to communicate "combine the changes in the two branches in
> some unspecified way", and that's how I was using it. I'm not sure what

... and regarding “unspecified”: I suspect the contention might be distinction between integrating the branchy itself (with those commits) with replaying fresh commits (rebase). But I don’t know.

>
>[snip]