phil294
Feature request: Quick copy commit subject/hash/tag
Hopefully there can be a way to quickly copy the commit subjects, hashes, tag names, etc. This would be handy for searching or when reusing / referencing / sharing commit info. Perhaps a copy icon next to the commit subject/hash on the list that only shows up when hovering over them. Or maybe some options in the context menu like Copy... >Subject / Hash / Tag etc. Thank you!
hmm I can see how that could be helpful
Perhaps a copy icon next to the commit subject/hash on the list that only shows up when hovering over them.
sure but then you'd need said icon next to all elements on hover: author name, hash, subject, date. And branches, stashes, where an additional icon would be hard to squeeze in.
I'm thinking perhaps really adding a new context action "Copy..." to all things (commit, commits, branches, tags, stashes) might be an idea, and clicking that shows a popup with various options for what you want to copy (hash, author name, name if it's a branch, origin, full name/origin, and so on). And when you're in a commit details pane, pressing CTRL+C will also open up this dialog.
perhaps this would be ... too much thoughh
If using icons, it would probably be fine to add them only for the most commonly used elements such as subject, hash. I've seen other extensions do this and it looks good and convenient.
If using the context menu, then it can be added for any suitable elements. I personally prefer a quicker and lighter way, better with one~two steps, like directly in the menu/submenu rather than right-click>Click Copy...>popup>select the copy option>(maybe have to close the popup afterwards). See Git Graph, right click on tags it shows Copy Tag, right click on branch it shows Copy Branch, right click on commit it shows Copy Subject/Hash, etc. This way seems more flexible and WYSIWYG. Or, it would also be nice to simply put all the options into one submenu.
I think the context menu does not necessarily need icons. I think it's better to have no icons instead of misleading ones.
Speaking of the context menu, I think it is better to use the VS Code "native" menu than the current menu which is limited in the view.
(This is not a really bothersome issue, since it's mentioned it would be nice if there could be any improvement about it!)
For example, I am placing git log graph in the bottom panel and it takes up very little height. When I right-click, the context menu only expands down and gets truncated by the panel height, so I will need to scroll up and down to see the full menu.
If using the VS Code menu, then it can automatically expand up or down depending on the clicking position, and can be shown above and beyond the panel.
For this copy feature, It would also be good for putting various copy options into one submenu, so it just needs two clicks: right click > hover Copy... > click on the option that needs to be copied. Like:
I've added a copy hash entry to the context menu (not yet released) for now.
I think the context menu does not necessarily need icons. I think it's better to have no icons instead of misleading ones.
@hansu Are any of the current ones misleading to you? If not, do you really think they should go? Or perhaps be disable-able? As a last resort, with the custom CSS option they can already be hidden out.
Speaking of the context menu, I think it is better to use the VS Code "native" menu than the current menu which is limited in the view.
@Amanoki I don't think this is possible because the extension lives inside a "web view" which is basically a normal web page, entirely separated from the outside world including styles etc. There is communication with the backend via message parsing though.
It's definitely a problem however that when you right click too far down, the menu is half hidden. The menu needs to be improved so that it opens upwards instead in this case, like common contexts menu always do in these situations.
I've added a copy hash entry to the context menu (not yet released) for now.
:+1:
I think the context menu does not necessarily need icons. I think it's better to have no icons instead of misleading ones.
@hansu Are any of the current ones misleading to you? If not, do you really think they should go? Or perhaps be disable-able? As a last resort, with the custom CSS option they can already be hidden out.
They are much better and almost not misleading. I didn't remember exactly how they looked before. I know it's difficult to find icons for functions that are very specific and end up in similar icons :upside_down_face: .
As a last resort, with the custom CSS option they can already be hidden out.
Is there any documentation of the classes or elements which can be modified by css? Or just look in the code in web/src/views ?
All styles can be modified - you need to toggle the VSCode developer tools by its command and use the inspector element picker to find the right spot and target its class/id/whatever directly.
In this case, it'd be .context-menu-wrapper i:before { content: ''; }.
You could also look into web/src/, yes, but since the Vue compiler does a lot of magic it's probably always easier to use the inspector instead. In the case of context menu icons, it's even more difficult because there is no template for it, the html is generated dynamically inside the context directive's code
Thanks!
I played a bit around and found that it looks good to me if the active branch is filled with the same color as the line instead of white:
What do you think? (Sorry a bit off topic)
I think that could work, would have to try a few different colors though.
But is it really an improvement over the white fill color? (black in light theme) I haven't had any issue with it so far and like the fact that "HEAD" is generally always a white/-ish color: The bubbles' filling, the line's shadow (should be bit darker though), the (HEAD) or HEAD branch. Somewhat contrary to that is the coloring of origins, stashes and tags which is also white, which doesn't fit the narrative.
But is it really an improvement over the white fill color?
IMHO yes. Especially with the a light theme.
But still a great improvement that the active branch is emphasized from the other branches :-).
However, I discovered a little design bug in light theme. The branch name background shouldn't be black in this case, right?:
Two other things regarding the color come into my mind looking at this:
- The color of the branch which is merged with message "merge remote-tracking..." should not be the same as the master branch.
- Can you change the color-order (or make it configurable)? red-orange-blue-cyan gives not a good contrast. Maybe just take the colors from Git Graph?
Sorry to spam this issue full with unrelated annotations :innocent:
The branch colors are currently calculated based on the hash of the branch names. The list of colors from which is chosen is hard coded. There's been an issue somewhere recently to maybe change that somewhere, make it configurable, change it to same colors from left to right all the time etc
The color of the branch which is merged with message "merge remote-tracking..." should not be the same as the master branch.
the problem here is that both the target and the source branch are called "master", thus leading to identical branch colors! Maybe a solution can be to have the origin / remote be part of the color determination logic, except for when the origin is the "default origin" which is determined as the origin behind main or master. Would have to try this out. The amount of red branches tends to be bad indeed.
There's been an issue somewhere recently to maybe change that somewhere, make it configurable, change it to same colors from left to right all the time etc
:+1:
the problem here is that both the target and the source branch are called "master"
Oh yes you are right. Seems that I didn't look thoroughly enough. I think in this case it's okay to have the same colors =)
All styles can be modified - you need to toggle the VSCode developer tools by its command and use the inspector element picker to find the right spot and target its class/id/whatever directly.
In this case, it'd be
.context-menu-wrapper i:before { content: ''; }.
Can you add that somehow to the documentation/README.md? I think it would be helpful for all users who want to change the CSS.