Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git_reference_cmp returns 0 for *distinct* symbolic references to the same target #6337

Open
nasso opened this issue Jun 30, 2022 · 1 comment · May be fixed by #6346
Open

git_reference_cmp returns 0 for *distinct* symbolic references to the same target #6337

nasso opened this issue Jun 30, 2022 · 1 comment · May be fixed by #6346

Comments

@nasso
Copy link

nasso commented Jun 30, 2022

I don't know if this is the intended behaviour, but...

Reproduction steps

Setup the repo with normal git:

git init
echo a > a.txt
git add a.txt
git commit -m "add a"

git symbolic-ref refs/foo refs/heads/master
git symbolic-ref refs/bar refs/heads/master

Compare the references with libgit2:

git_repository *repo;

// open repository somehow, details don't matter here

git_reference *foo;
git_reference *bar;

git_reference_lookup(&foo, repo, "refs/foo");
git_reference_lookup(&bar, repo, "refs/bar");

printf("%d\n", git_reference_cmp(foo, bar));

I am using the library from Rust using git2-rs, apologies if this isn't the exact C code to do it!
It is a relatively simple thing to do though, so I should've got it right I think.

Expected behavior

git_reference_cmp returns a non-zero value (it doesn't matter what, but could be the same as strcmp("refs/foo", "refs/bar")).

Actual behavior

git_reference_cmp returns zero, suggesting that the two references are actually the same.

Version of libgit2 (release number or SHA1)

libgit2 1.4

Operating system(s) tested

Windows 10

@ethomson
Copy link
Member

ethomson commented Jul 8, 2022

Right. Well, I'm surprised by this, but apparently git_reference_cmp ignores the reference name and only compares the type and the target. This isn't the behavior that I would have expected.

I think that this is one of those things that was implemented incorrectly, but done so a decade ago and would be a breaking change. I think that we should fix this, but when we do breaking changes ahead of our 2.0.

@ethomson ethomson linked a pull request Jul 8, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants