| Summary: | egit does not recognize user-created symbolic-refs | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | R Shapiro <rshapiro> |
| Component: | Core | Assignee: | Project Inbox <egit.core-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | robin.rosenberg, robin |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
R Shapiro
I'd say this is not a bug. C Git doesn't list it as a ref either. It will recognize it only if you name it explicitly and so will JGit, til proven otherwise. The bug is that there are legitimate references which can be used in command-line Git but not in egit, since egit does not support 'explicit naming' of reference: the _only_ way to get at reference in egit is from the lists. So either an explicit-naming feature needs to be added to all the relevant egit commands, just as it is in command-line git, or the reference lists (generated by jgit?) need to include these references, which would seem to make more sense in gui context. None of the git ui's I know of lists symbolic refs that are stored under the .git directory. Not even git-for-each-ref does that. You should not place symbolic refs there. git symbolic-ref is low-level plumbling command so you have a greater responsibility in using it in such a way that the result makes sense. Create these symbolic under refs and you'll be fine. The .git directory is a collection of strange stuff, some well known, others not, so we need to be careful when reading that directory. In other words, we read only those things we think we understand. TODO: If we add an UI to create symbolic refs, make sure they get stored under the refs directory. I agree with Robin here. I also don't see the benefit of complicating the UI of EGit by providing special "you can enter the path of the special ref and we will try to look it up in .git" kind of dialogs. |