5 ms·

From my experience, developers who rely on visual interfaces don't understand Git as well as developers who mostly use CLI. When relying on visual interfaces, a

From my experience, developers who rely on visual interfaces don't understand Git as well as developers who mostly use CLI. When relying on visual interfaces, at some point Git stops being the powerful tool it is.

temp453463343 14y ago
There is a correlation. To be able to use the CLI you need to be more comfy with git; but just because it's less intuitive doesn't imply it's a a more powerful tool. Just that the user-base has a higher git-familiarity floor
katbyte 14y ago
You shouldnt generalize. I understand GIT very well and can (and for complex operations beyond the UI) use the CLI. However I generally use UIs because i simply prefer it. I see no need to use the cli for basic commits,pushes and pulls when neither is inherently superior..
- wldlyinaccurate 14y ago
  I know this sounds very condescending and even a little elitist, but usually when people say "I am proficient with a CLI but prefer a GUI" I hear "I have memorised a few commands but I don't understand them, so I prefer a GUI". The reason being that I have genuinely never found a GUI for an application which is simpler or easier to use than a CLI. I'm just curious; you seem to imply that you find basic commands (add, commit, push, pull) easier to perform in a GUI than a CLI. Why is that? What is it about a CLI which isn't simple?
  - spacemanaki 14y ago
    All right, I'll bite, I think it was a little condescending. I consider myself pretty proficient with Git, with maybe above average understanding of the internals and the porcelain. I use the command line for most git operations, but have ended up using `git gui` for a lot of simple and complicated commits, which almost always end up using `add --patch`. My workflow is something like: work on the code use git gui instead of add --patch on the command line use git stash -k on the command line run tests suite Git gui lets you pick individual lines much easier than `add --patch` does, and I find that wanting to have that available at my fingertips means I use it for non--patch adds too. Maybe this is an indication of some other "flaw" in my workflow where I'm generating a lot of changes that I don't want to commit yet, but I think it's common and inevitable when working on legacy code or in maintenance-mode. But even for new projects I use this because I'm usually cleaning up my work via --patch. Another nice alternative to `add --patch` is magit for Emacs which lets you select a region in a diff and add that. I find both of these (git gui and magit) to be much easier and faster to use than `add --patch` on the command line, which has a pretty clever interface given the limitations, but is really far from perfect (split often doesn't work with small hunks, which means you have to open it in an editor. which means Emacs, so I might as well just use magit) I've tried to get colleagues to use a workflow like this, so they stop committing garbage like bad comments and logging. In my experience and humble opinion, your generalization is often enough wrong that I would avoid it. I've met plenty of people who prefer GUIs for this or that task which they could script or shell circles around me. It really all boils down to taste and what you find to work for you. Git's command-line interface is badly enough designed that you shouldn't make anyone feel bad for using something different. (I say this as someone who loves Git very dearly) That said, I DO believe that users who NEW to Git specifically should use the command line a bit while they are learning, since it helps with the vocabulary used everywhere to talk about Git, while some GUIs bury it behind a leaky abstraction.
  - katbyte 14y ago
    You're right, it does. I know where you coming from because i see it often myself, but you should never make assumptions about people because there's always exceptions. Its not that the CLI isn't simple, it's that the GUI is just easier. From your post i think i can safely assume you sit in a CLI all day so it makes sense you would prefer to use it. I spend the majority of my day in windows & IDEs and while i always have a few bash cygwin shells handy its just easier to right click -> commit/push/pull/switch branch/fetch&rebase then to switch context and type it out. Oh and merging, I just find visual diff/merge tools nicer. When i need to actually do anything complicated the CLI is where i go, but generally, i really don't need to. I'll turn it around and ask why, for simple tasks, is the CLI any better than a GUI ignoring personal preferences?
  - wldlyinaccurate 14y ago
    Thanks for the explanations. After reading my comment again I realise that I sounded like a typical Git elitist - sorry about that. I'll turn it around and ask why, for simple tasks, is the CLI any better than a GUI ignoring personal preferences? For me, the main thing is speed: I can type much faster than I can navigate a cursor (tab completion helps). I recognise that some GUIs have keyboard shortcuts to speed things up, but then at some point you're using the keyboard enough to justify using a CLI. The other thing is that I don't find graphical representations of my changes helpful at all. I commit early, commit often, so the output of `git diff` generally doesn't need to be paginated. My feature branches are small so I can merge them without the need to see a commit/branch graph. To be honest it's hard to answer that without ignoring personal preferences because really, that's all it boils down to. I can definitely understand the want to use a GUI when you're doing complex adds or merges. spacemanaki is right in saying that doing this a lot probably indicates a problem with workflow, though.

temp453463343 14y ago

There is a correlation. To be able to use the CLI you need to be more comfy with git; but just because it's less intuitive doesn't imply it's a a more powerful tool. Just that the user-base has a higher git-familiarity floor

katbyte 14y ago

You shouldnt generalize. I understand GIT very well and can (and for complex operations beyond the UI) use the CLI. However I generally use UIs because i simply prefer it. I see no need to use the cli for basic commits,pushes and pulls when neither is inherently superior..

wldlyinaccurate 14y ago
I know this sounds very condescending and even a little elitist, but usually when people say "I am proficient with a CLI but prefer a GUI" I hear "I have memorised a few commands but I don't understand them, so I prefer a GUI". The reason being that I have genuinely never found a GUI for an application which is simpler or easier to use than a CLI. I'm just curious; you seem to imply that you find basic commands (add, commit, push, pull) easier to perform in a GUI than a CLI. Why is that? What is it about a CLI which isn't simple?
- spacemanaki 14y ago
  All right, I'll bite, I think it was a little condescending. I consider myself pretty proficient with Git, with maybe above average understanding of the internals and the porcelain. I use the command line for most git operations, but have ended up using `git gui` for a lot of simple and complicated commits, which almost always end up using `add --patch`. My workflow is something like: work on the code use git gui instead of add --patch on the command line use git stash -k on the command line run tests suite Git gui lets you pick individual lines much easier than `add --patch` does, and I find that wanting to have that available at my fingertips means I use it for non--patch adds too. Maybe this is an indication of some other "flaw" in my workflow where I'm generating a lot of changes that I don't want to commit yet, but I think it's common and inevitable when working on legacy code or in maintenance-mode. But even for new projects I use this because I'm usually cleaning up my work via --patch. Another nice alternative to `add --patch` is magit for Emacs which lets you select a region in a diff and add that. I find both of these (git gui and magit) to be much easier and faster to use than `add --patch` on the command line, which has a pretty clever interface given the limitations, but is really far from perfect (split often doesn't work with small hunks, which means you have to open it in an editor. which means Emacs, so I might as well just use magit) I've tried to get colleagues to use a workflow like this, so they stop committing garbage like bad comments and logging. In my experience and humble opinion, your generalization is often enough wrong that I would avoid it. I've met plenty of people who prefer GUIs for this or that task which they could script or shell circles around me. It really all boils down to taste and what you find to work for you. Git's command-line interface is badly enough designed that you shouldn't make anyone feel bad for using something different. (I say this as someone who loves Git very dearly) That said, I DO believe that users who NEW to Git specifically should use the command line a bit while they are learning, since it helps with the vocabulary used everywhere to talk about Git, while some GUIs bury it behind a leaky abstraction.
- katbyte 14y ago
  You're right, it does. I know where you coming from because i see it often myself, but you should never make assumptions about people because there's always exceptions. Its not that the CLI isn't simple, it's that the GUI is just easier. From your post i think i can safely assume you sit in a CLI all day so it makes sense you would prefer to use it. I spend the majority of my day in windows & IDEs and while i always have a few bash cygwin shells handy its just easier to right click -> commit/push/pull/switch branch/fetch&rebase then to switch context and type it out. Oh and merging, I just find visual diff/merge tools nicer. When i need to actually do anything complicated the CLI is where i go, but generally, i really don't need to. I'll turn it around and ask why, for simple tasks, is the CLI any better than a GUI ignoring personal preferences?
- wldlyinaccurate 14y ago
  Thanks for the explanations. After reading my comment again I realise that I sounded like a typical Git elitist - sorry about that. I'll turn it around and ask why, for simple tasks, is the CLI any better than a GUI ignoring personal preferences? For me, the main thing is speed: I can type much faster than I can navigate a cursor (tab completion helps). I recognise that some GUIs have keyboard shortcuts to speed things up, but then at some point you're using the keyboard enough to justify using a CLI. The other thing is that I don't find graphical representations of my changes helpful at all. I commit early, commit often, so the output of `git diff` generally doesn't need to be paginated. My feature branches are small so I can merge them without the need to see a commit/branch graph. To be honest it's hard to answer that without ignoring personal preferences because really, that's all it boils down to. I can definitely understand the want to use a GUI when you're doing complex adds or merges. spacemanaki is right in saying that doing this a lot probably indicates a problem with workflow, though.