From: Kristoffer Haugsbakk Date: Thu, 15 Jan 2026 15:50:17 GMT Subject: Re: [PATCH v3 2/2] shallow: handling fetch relative-deepen Message-ID: <11b951ab-b624-4ab8-b7b1-fe41a40c9d0e@app.fastmail.com> In-Reply-To: On Sat, Jan 10, 2026, at 06:13, Samo Pogačnik via GitGitGadget wrote: > When a shallowed repository gets deepened beyond the beginning of a > merged branch, we may end up with some shallows that are hidden behind > the reachable shallow commits. Added test 'fetching deepen beyond > merged branch' exposes that behaviour. > > An example showing the problem based on added test: >[snip] > --- > Note that second shallow commit 61ba98be443fd51c542eb66585a1f6d7e15fcdae > is not reachable. > > On the other hand, it seems that equivalent absolute depth driven > fetches result in all the correct shallows. That led to this proposal, > which unifies absolute and relative deepening in a way that the same > get_shallow_commits() call is used in both cases. The difference is > only that depth is adapted for relative deepening by measuring > equivalent depth of current local shallow commits in the current remote > repo. Thus a new function get_shallows_depth() has been added and the > function get_reachable_list() became redundant / removed. > > Same example showing the corrected second step: >[snip] > > The get_shallows_depth() function also shares the logic of the > get_shallow_commits() function, but it focuses on counting depth of > each existing shallow commit. The minimum result is stored as > 'data->deepen_relative', which is set not to be zero for relative > deepening anyway. That way we can allways summ 'data->deepen_relative' s/allways summ/always sum/ ? > and 'depth' values, because 'data->deepen_relative' is always 0 in > absolute deepening. > > Signed-off-by: Samo Pogačnik > --- >[snip]