Le 24 juin 2026 à 19:20, Junio C Hamano [off-list ref] a écrit :

Harald Nordgren [off-list ref] writes:

quoted

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.

quoted

... ("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?