It seems like this bug can be generalized to “git name-rev --stdin” does not work with --no-undefined nor --name-only The --name-only case seems clear to me that we should fix it. It’s misleading to return the sha instead of “undefined” for a rev without a symbolic name, as a sha could be a symbolic name. I think we can also make the argument that --no-undefined should also die in --stdin mode when given a rev without any symbolic names. > On Dec 22, 2021, at 2:05 AM, Erik Cervin Edin <erik@xxxxxxxxxxx> wrote: > > Hey all! > > I ran into a situation that I think may be a bug > using git name-rev for detached heads. > > Steps to reproduce: > Create a detached head > git checkout --detached > git commit --allow-empty -m foo > > Expected results: > My understanding is that > git name-rev $(git rev-list -1 HEAD) > git rev-list -1 HEAD | git name-rev --stdin > should yield the same result. > > As well as combining with other flags > like --name-only / --no-undefined > > Actual results: > Where this fails as expected > git name-rev --no-undefined $(git rev-list HEAD) > this just prints the SHA wo failing > git rev-list -1 HEAD | git name-rev --stdin --no-undefined > > "name-only" is also affected > git rev-list -1 HEAD | git name-rev --stdin --name-only > returns the SHA and not the name > > Tested on > git version 2.34.1.windows.1 > -- > Erik Cervin-Edin
