Show 39 quoted lines
> 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?)
Ben Knoble <ben.knoble@gmail.com>