Re: [PATCH v14 2/2] checkout: extend --track with a "fetch" mode to refresh start-point

[Ben Knoble <ben.knoble@gmail.com>]

> Le 24 juin 2026 à 19:20, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> Harald Nordgren <haraldnordgren@gmail.com> writes:
> 
>> Ok, let's focus on the need for the feature before talking code:
>> 
>> In an active project, forking from "origin/master" without refreshing
>> first often has consequences: you start work that has already been
>> done, or you build on an old version of the code which causes big
>> conflicts only later when you pull. The fix is simple ...
> 
> The above only argues that contributors should not start work on top
> of a stale codebase without looking at reasonably recent codebase.
> 
> I am not sure if automated fetch immediately before forking to start
> work will be a good fix for that, especially if the fork of a new
> branch is done blindly _without_ looking at what the updated
> upstream contains.
> 
>> ... ("git fetch
>> origin master && git checkout -b topic origin/master"), but it is
>> still a mouthful. Other tools exist because this is annoying enough
>> that people automate it.
> 
> And to actually look at the recent codebase, one would probably need
> 
>    git fetch
>    git log [-p] ..origin -- your-area-of-interest/
>    ... other inspection of the recent changes to refresh your
>    ... understanding of the base code comes here
>    git checkout -b topic origin
> 
> or something like that.  Wouldn't folding the first and the third
> step into one operation encourage omitting the second step?  In a
> sense, having a tool to let people blindly fetch and fork without
> looking at what changed recently (i.e., they had a reason to think
> that what they had was stale, so has a fetch actually resolved that
> staleness?  what new things did the fetch bring in?) may encourage
> a bad workflow.

I think I remain overall ambivalent, but as anecdata: when I’m working on my employer’scode, it is the default (90%+?) for folks to omit step 2 and have the kind of blind fetch + branch that this would facilitate.

I myself do this when I’m reasonably sure the other changes can’t be of interest (common), or when I suspect the change I’m going to start on will conflict with recent changes I haven’t fetched. At other times I’m more interested in step 2, but generally I omit it at work.

Now, as to why: I spend a lot more time reviewing PRs at work (and making sure they merge quickly when they are in the right direction), and so I’m usually fairly confident of what a fetch is going to bring! [I also fetch several times a day to keep up to date locally, to facilitate various maintenance, admin, and archaeology tasks.] Contrast with distributed open source projects, where I might not have fetched for weeks and can’t predict what might fall out (let alone how it might it interact with local WIP).

So « bad workflow » I agree with, but am plenty guilty of :)

To wrap up, I wonder if the convenience of this proposal is especially aimed at folks like my corporate environment (where « build near the tip and integrate quickly » is the norm), but less than useful for those same folks in a different situation?

(OTOH, I suppose I might use something similar when starting a new topic branch from Git’s master branch, since there’s probably no harm in working on a recent copy of master unless I already have older code that needs updated?)

> An obvious complaint against "update and always inspect and
> understand" would be "it would slow us down!", but that is why
> projects encourage forking your topic at a well known release tags,
> not from a random "tip of the tree of the day".
> 
> I think most of the above has already been communicated earlier in
> discussions before we got to v14, but I may be wrong.  Are there any
> new arguments in support of the feature?