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
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 dunno. I guess anybody who really cares can run "git symbolic-ref
origin/HEAD" themselves to get that information.
-Peff
