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
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 [off-list ref] 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
On Dec 23, 2021, at 10:39 AM, John Cai [off-list ref] 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?
quoted
On Dec 22, 2021, at 2:05 AM, Erik Cervin Edin [off-list ref] 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
On Fri, Dec 24, 2021 at 7:09 AM John Cai [off-list ref] wrote:
This would have the potential of breaking scripts that rely on the current behavior.
Presumably, using --no-undefined scripts rely on presumed behavior
that doesn't exist.
Similarly, using --name-only should expect to return a symbolic name
While it's possible, I think it's rare that this would break scripts
in an unacceptable way.
On Fri, Dec 24, 2021 at 7:09 AM John Cai [off-list ref] wrote:
Since I’m a bit new, I’m wondering how we generally handle these cases?
I'm also new so I can't really comment on this :)
Though I believe the git suite in general is quite adamant on
backwards compatibility