From: Ben Knoble Date: Thu, 25 Jun 2026 01:17:05 GMT Subject: Re: [PATCH v14 2/2] checkout: extend --track with a "fetch" mode to refresh start-point Message-ID: <43C04FB5-7FE5-4535-A79A-C35449EB38C0@gmail.com> In-Reply-To: > Le 24 juin 2026 à 19:20, Junio C Hamano a écrit : > > Harald Nordgren 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?