> On Dec 23, 2021, at 10:39 AM, John Cai <jcai@xxxxxxxxxx> wrote: > > 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. While I think this would make name-rev more consistent, I’d be interested in hearing what others think about changing the behavior of this command. This would have the potential of breaking scripts that rely on the current behavior. Since I’m a bit new, I’m wondering how we generally handle these cases? > > >> 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 >
