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
refs: preserve the owning refdb when duping reference #4618
Conversation
This fixes a segfault in git_reference_owner on references returned from git_reference__read_head and git_reference_dup ones.
Note that I don't feel confident enough to change the behavior of |
This was introduced in 5b65ac2, and the fix looks easy : grab the refdb from the repo and put it in. That'll allow the comment to be dropped and preserve the "owner" semantics. @pks-t maybe you can say if not having an owner is an oversight or a performance improvement of sorts (the commit message implies the latter) ? Mostly because right now I'm looking at the refdb ownership mechanism and worktrees, and I feel overwhelmed 😉. |
Hm. First thing I notice is that |
Sure it does. The name indicates what it does (reads a |
Umm... are they? The function should be totally safe to call on any reference, disregarding if it is a symbolic one or not. I probably shouldn't argue, because I'm the one who named that function like that :P |
Maybe I'm not understanding - but I'm thinking that you shouldn't call this on any reference except special |
Just for clarification, it's only used to resolve worktree HEADs at the moment, and it seems to be perfectly safe to use as long as you don't really need the reference. The only issue it has is that it doesn't setup the owning refdb pointer correctly when resolving a symbolic reference (as it just parses the file's content), so you need to make sure to resolve a second time (which I just hit that missing refdb case while moving unborn-ness checking in In all, as long as that weirdness is documented, I think it's fine to keep it that way, I just have an extra |
(Also also, that worktree head resolution function return NOTFOUND instead of UNBORN) |
Thanks, @tiennou! |
I'd like to know if that NOTFOUND/UNBORN nuance should be considered a bug/missing feature from the worktree support (note that I have absolutely no idea how worktrees work so this may not even be considered valid) ? From the cursory look I gave the code, |
This fixes a segfault in
git_reference_owner
on references returned fromgit_reference__read_head
andgit_reference_dup
ones.