On 6/23/2025 4:11 PM, Phil Hord wrote: > On Wed, Jun 18, 2025 at 8:37 PM Jeff King <peff@xxxxxxxx> wrote: >> On Wed, Jun 18, 2025 at 04:15:03PM -0700, Jacob Keller wrote: >>> On 6/18/2025 2:08 PM, Phil Hord wrote: >>>> My patch fixes this for fetch, but it affects the command's output > order. >>>> Currently the results look like this: >>>> >>>> - [deleted] (none) -> origin/bar >>>> (origin/bar has become dangling) >>>> - [deleted] (none) -> origin/baz >>>> - [deleted] (none) -> origin/foo >>>> (origin/foo has become dangling) >>>> - [deleted] (none) -> origin/frotz >>>> >>>> After my change, the order will change so the danglers are reported > at the end. >>>> >>>> - [deleted] (none) -> origin/bar >>>> - [deleted] (none) -> origin/baz >>>> - [deleted] (none) -> origin/foo >>>> - [deleted] (none) -> origin/frotz >>>> (origin/bar has become dangling) >>>> (origin/foo has become dangling) >>> >>> Personally, I like the later output. I have no idea why anyone would be >>> specifically scripting something that depends on the ordering being such >>> that dangling messages are printed immediately. >> >> I think the original ordering tells you which deletion caused the ref to >> become dangling. Phil's example is a little confusing here: >> >> - [deleted] (none) -> origin/bar >> (origin/bar has become dangling) >> >> because the name is the same in both cases. A more likely output is that >> origin/HEAD becomes dangling (since it's the only symref Git ever >> automatically points at a tracking ref). E.g., in this: >> >> git init repo >> cd repo >> >> git commit --allow-empty -m foo >> git branch some >> git branch other >> git branch branches >> >> git clone . child >> cur=$(git symbolic-ref --short HEAD) >> git checkout some >> git branch -d other branches $cur >> >> cd child >> git fetch --prune > > Thanks for the helpful demo and clarification of the real output. > >> The final fetch output looks like: >> >> - [deleted] (none) -> origin/branches >> - [deleted] (none) -> origin/main >> (refs/remotes/origin/HEAD has become dangling) >> - [deleted] (none) -> origin/other >> >> and we can see that the deletion of "main" is what caused the dangling. >> >> That said, I'm not sure I care that much. I didn't even know we had this >> dangling message, and it's been around for over 15 years! >> >> If we did want to preserve the ordering, it could be done by taking two >> passes (the first to create a reverse map of deletions to danglers, and >> then the second to print each ref). >> >> Alternatively, the dangling message could just mention where it the >> now-dangling symref points at, something like: >> >> - [deleted] (none) -> origin/branches >> - [deleted] (none) -> origin/main >> - [deleted] (none) -> origin/other >> (refs/remotes/origin/HEAD points to the now-deleted origin/main) > > I have a new patch that produces this: > > + git fetch --prune --dry-run > From /tmp/repo/. > - [deleted] (none) -> origin/branches > - [deleted] (none) -> origin/master > - [deleted] (none) -> origin/other > origin/HEAD will become dangling after origin/master is deleted > It is a bit weird that this says "will become dangling after <ref> is deleted" because the deletion already happened.
