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
IDEA-157915: Fix symbolic-ref in HEAD #2 #429
base: master
Are you sure you want to change the base?
IDEA-157915: Fix symbolic-ref in HEAD #2 #429
Conversation
@klikh Here is a fix for problem with packed-refs. Example: |
OK, it seems that the problem is a bit more complex than it seemed at first. I think we have to decide on the UI first, and then make an implementation so that it matches the UI we agree on. Here are my thoughts on this:
What do you think about 2, and what other use cases there are? |
Hm. Have you rebased the pull request? I don't see neither code comments, nor the pull request discussion. Or are they hidden somewhere inside github UI? |
I didn't manage to reopen old PR. Either I am github newbie, or github thinks that reopening merged PR is strange, or both of them. So I created a new PR. |
Ah, my bad. I thought that you've opened a new PR, but didn't find it because I didn't look in closed PRs. Here it is for reference: #424 |
Regarding usecases, as I understand there are quite few symlink usecases:
All the other time git works with normal physical branches. |
It seems that to solve these issues, instead of treating symrefs as normal branches and resolving them while reading the repository, we'll have to introduce a special conception for them, e.g. something like Btw, could you please share your use cases: why do you use links at all, instead of operating the real branches? AFAIK they are not an official feature of Git: back in 2011 Junio said that only the |
Well... we have quite a long names of branches. I want to have alias |
So do you mind trying the approach with separate class for symbolic refs?
It is
Since we see that there is no official support of symbolic refs, following git client looks less necessary. On the other hand, the approach with braces looks nice. Just in reverse order: "stable (master)". IMHO it would be weird to see "Current branch: master" after checking out "stable", wouldn't it? In addition to that, if we display master (or even "master (stable)"), it would be unclear why there is "master" in Git | Branches popup. |
Yes, I'll probably try to do something about this
Well, it a good point =) I've just written first to come in mind. What is the case of multi-repository? 2 modules from different folders in one project? git repo inside other git repo? |
Both, and anything else you can imagine. For example, full intellij-community project consists of 3 repositories nested one into another: this one + /android + /tools-base. We have users with dozens of repositories (usually, some web frameworks with many small repositories for each of web site modules). And we even have users with mixed VCS projects having e.g. a Git repository, a Hg repository and an SVN repository in a single project. However, this case is not related to the original issue: here we care only about multiple Git repositories. Repositories are registered in In IDEA some operations are synchronous for all repositories by default (Update Project, Push, Commit), some have no sync support yet (e.g. Git | Pull, Git | Stash). Branches can operate synchronously or individually depending on the value of |
@klikh Push is being performed to actual remote, pull also works. If this is OK, I will continue with some tests for it |
Please add tests at least for the following cases:
You may use either |
@@ -28,7 +28,7 @@ | |||
|
|||
public static final TObjectHashingStrategy<String> BRANCH_NAME_HASHING_STRATEGY = FilePathHashingStrategy.create(); | |||
|
|||
@NotNull protected final String myName; | |||
@NotNull private final String myName; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is good to encapsulate the name, but I'd prefer it to be made in a separate commit, since it doesn't directly apply to the symbolic-ref feature.
private static Map<String, Hash> getResolvedHashes(@NotNull Map<String, String> data) { | ||
Map<String, Hash> resolved = ContainerUtil.newHashMap(); | ||
private static Map<String, RefInfo> getResolvedHashes(@NotNull Map<String, String> data) { | ||
Map<String, RefInfo> resolved = ContainerUtil.newHashMap(); | ||
for (Map.Entry<String, String> entry : data.entrySet()) { | ||
String refName = entry.getKey(); | ||
Hash hash = parseHash(entry.getValue()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a problem of this PR (since the problem already exists), mentioning here just for reference (mostly for myself): this method is potentially buggy, since it will treat a branch name matching [a-zA-Z0-9]
as a hash.
@illabefat So is this feature is still actual for you? |
08f2151
to
d1f830e
Compare
No description provided.