4 ms·

meh. I'm starting to hate using GUIs reaching out for the mouse is almost as irritating as clicking it. Since my hands are already on the keyboard, I may as wel

by gibbitz 10y ago

meh. I'm starting to hate using GUIs reaching out for the mouse is almost as irritating as clicking it. Since my hands are already on the keyboard, I may as well type... Maybe that's why this is unimplemented. Maybe I'm not alone.

Ajedi32 10y ago
The way I see it, the git DAG is fundamentally a graphical data structure, so it makes perfect sense to be able to manipulate it using a graphical interface. The only problem is there aren't really any UIs that take full advantage of git's nature as a DAG yet (at least, AFAIK). While I've yet to find a git GUI which approaches the same level of functionality the git CLI possesses, I think something like the UI proposed here might be good enough to finally get me to switch.
ursus_bonum 10y ago
This. By the time you get good enough at Git to make a reasonable GUI, you don't need/want it anymore.
hosh 10y ago
I do feel this way. I use mosh+tmux+emacs and do everything on the command line. My MBP is a very egregious machine that lets me use it as a very social, very smart terminal connecting into a cloud server. If my team adopts this tool, I probably would opt-out. However, my thinking and feeling about this has also been shifting in the past year. I've been slowly accepting more leadership functions where I work. My sense of myself as the heroic developer is eroding. I, as a single person, do not scale as well as a team. I'm learning about neurodiversity, how to be inclusive, what its advantages are. I'm learning about architecture in a different way -- understanding it as the empty space where best practices will naturally arise. So a lot of things are shifting in that, a year ago, I would not only feel this way about the tool, I would dismiss it as well. Now, I'm thinking of how this would benefit the team. Being the person on my team called in to perform git black magic, I've watched different people struggle with git. Having used git a lot, many of the basic git operations are practiced to the point of effortlessness. I don't really think much about the basics, and as such, I can compose those basics in higher-level operations. Many of the people on my team have not gotten to that point yet. By simplifying unnecessary concepts, someone would be able to use that version control to express higher level things. This proposed design covers many of the pain points. This includes writing it as a web backend (gitup will not work for our team and our tooling). I think it also enables collaboration I'd like my team to have (auto syncing branches for the whole team? hell yeah), but right now, is not doing so because git is too hard to use. I'm thinking of "empty space" here: I think this tooling shapes the empty space such that, the "best practice" is also "least effort", so people will naturally do the right things when it comes to version control and sharing code. For that, I'd support its use. Maybe not enough for me to give it up on my own workflow, but even that might change. I hope the author will develop this tool. The design is thoughtful and brilliant. Our team can sure use it.
notgood 10y ago
GUI doesn't mean it has to be handled by mouse, good GUIs (for devs) support keyboard-only input, e.g. ctrl+b shows a branch selection list. The graphical part can be used only for better understanding of state and history of the repo.
Mandatum 10y ago
> Maybe I'm not alone Come on, you're on HN afterall. I personally work a lot better with git when using a GUI. It's faster for me to click-click-click the files I want to include in my commit, type up my message in a box and hit commit than it is to stop and think about adding each file and the syntax I need to use when commiting and should I push as well for this project? On top of that, the client interface I have is in-built diff that makes it easy to navigate files and folders for differences with colour-coded boxes and icons to quickly tell what it is I'm doing in this commit. That's not to say I don't understand the value of CLI tools and I don't love some of them a lot more than any GUI counterpart, but different tools call for different ways of use. And for me and git - git CLI is only for headless boxes, automated tools and servers I'm working on.

by gibbitz 10y ago

Ajedi32 10y ago

The way I see it, the git DAG is fundamentally a graphical data structure, so it makes perfect sense to be able to manipulate it using a graphical interface. The only problem is there aren't really any UIs that take full advantage of git's nature as a DAG yet (at least, AFAIK). While I've yet to find a git GUI which approaches the same level of functionality the git CLI possesses, I think something like the UI proposed here might be good enough to finally get me to switch.

ursus_bonum 10y ago

This. By the time you get good enough at Git to make a reasonable GUI, you don't need/want it anymore.

hosh 10y ago

I do feel this way. I use mosh+tmux+emacs and do everything on the command line. My MBP is a very egregious machine that lets me use it as a very social, very smart terminal connecting into a cloud server. If my team adopts this tool, I probably would opt-out. However, my thinking and feeling about this has also been shifting in the past year. I've been slowly accepting more leadership functions where I work. My sense of myself as the heroic developer is eroding. I, as a single person, do not scale as well as a team. I'm learning about neurodiversity, how to be inclusive, what its advantages are. I'm learning about architecture in a different way -- understanding it as the empty space where best practices will naturally arise. So a lot of things are shifting in that, a year ago, I would not only feel this way about the tool, I would dismiss it as well. Now, I'm thinking of how this would benefit the team. Being the person on my team called in to perform git black magic, I've watched different people struggle with git. Having used git a lot, many of the basic git operations are practiced to the point of effortlessness. I don't really think much about the basics, and as such, I can compose those basics in higher-level operations. Many of the people on my team have not gotten to that point yet. By simplifying unnecessary concepts, someone would be able to use that version control to express higher level things. This proposed design covers many of the pain points. This includes writing it as a web backend (gitup will not work for our team and our tooling). I think it also enables collaboration I'd like my team to have (auto syncing branches for the whole team? hell yeah), but right now, is not doing so because git is too hard to use. I'm thinking of "empty space" here: I think this tooling shapes the empty space such that, the "best practice" is also "least effort", so people will naturally do the right things when it comes to version control and sharing code. For that, I'd support its use. Maybe not enough for me to give it up on my own workflow, but even that might change. I hope the author will develop this tool. The design is thoughtful and brilliant. Our team can sure use it.

notgood 10y ago

GUI doesn't mean it has to be handled by mouse, good GUIs (for devs) support keyboard-only input, e.g. ctrl+b shows a branch selection list. The graphical part can be used only for better understanding of state and history of the repo.

Mandatum 10y ago

> Maybe I'm not alone Come on, you're on HN afterall. I personally work a lot better with git when using a GUI. It's faster for me to click-click-click the files I want to include in my commit, type up my message in a box and hit commit than it is to stop and think about adding each file and the syntax I need to use when commiting and should I push as well for this project? On top of that, the client interface I have is in-built diff that makes it easy to navigate files and folders for differences with colour-coded boxes and icons to quickly tell what it is I'm doing in this commit. That's not to say I don't understand the value of CLI tools and I don't love some of them a lot more than any GUI counterpart, but different tools call for different ways of use. And for me and git - git CLI is only for headless boxes, automated tools and servers I'm working on.