4 ms·

The fact that you use a Windows-only GUI for Hg is extremely telling. Git is fundamentally a Unix tool that follows Unix design expectations and integrates with

The fact that you use a Windows-only GUI for Hg is extremely telling. Git is fundamentally a Unix tool that follows Unix design expectations and integrates with the Unix ecosystem and expects the user to be a component command line user.

krupan 10y ago
tortoiseHG is not windows only
- Sir_Cmpwn 10y ago
  My mistake. The point remains - users who are more comfortable in a GUI are in a similar boat.
ufo 10y ago
The real reason ther eare few git GUIs is not that git expects advanced users that can use the command line. It is that it is very very hard to create a GUI for git due to the way it is built as a complex web of web of scripts written in C, Shell and Perl. This architecture is the reason why projects such as libgit had to reimplement a lot of core git algorithms. https://libgit2.github.com/ https://libgit2.github.com/ Mercurial, on the other hand is more amenable for extension due to being built our of a bunch of Python modules.
- Sir_Cmpwn 10y ago
  You're half right, but coming from the wrong place. The fact that git is hard to make a GUI for is an intentional design choice in git. It was built to be CLI first and shoehorning a GUI onto it is the wrong way to use git. The correct way is to learn how to be comfortable in a CLI. Git's design with that web of shell and perl and C is totally fine and suited to a CLI-first application.
  - warbiscuit 10y ago
    I think different tasks are (more) suitable to different interfaces. CLIs are great when the space of actions you could perform is large (to nigh uncountable), but the range of subjects is small (the file paths, etc are known). Since you know the subjects, a programming language like `sh` is the most concise way to express a complex action. GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...). Many complex tools like VCSes contain both kinds of situations. I think sometimes a CLI is more appropriate, and sometimes a GUI is, depending on the context. IMO a fully mature VCS should make it as easy to invoke a gui for complex tasks as it is to do them from the command line.
    - Sir_Cmpwn 10y ago
      >GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...). Those examples are not only possible, but easy to do in the CLI for an advanced user. I do that sort of thing every day. I agree that some tasks are better suited to a GUI and some are better suited to a CLI, but your VCS is firmly in the latter camp imo.
      - warbiscuit 10y ago
        As a semi-concrete example, say you have a VCS checkout with 40 edited chunks across 15 files. You want to commit 20 of 40 chunks (spread across 6 of 15 of the files). When you're halfway done, you notice a typo needs correcting in chunk 16, and fix it. You then proceed to commit your selection. From the command prompt, invoking thg and doing that took me about 18 seconds. I'm reasonably good on the command line, but I certainly don't see how to beat that time using just the cli. I think saying it's "easy for an advanced user" is a little loaded, but I'm still interested to know how to do that task faster. And if such a cli process could only be done with git, I'd consider switching.
  - Amezarak 10y ago
    It seems unintuitive to me that manipulating a graph via a GUI should be the wrong way to operate. I find it difficult to imagine this argument would be made if git were not the DVCS of choice. I would say, though, that the ideal GUI for a DVCS has probably not been invented yet.
    - slrz 10y ago
      Right and it's pretty sad, I think. Most contemporary software doesn't even try making use of graphic displays and mouse input to create a more efficient interface for trained professionals, often lacking even the most basic forms of ad-hoc programmability.
warbiscuit 10y ago
I'd disagree with a number of assumptions in that statement. For one, TortoiseHg isn't windows only. It's a python+qt based application that works uniformly pretty much everywhere. That fact that you made that assumption makes me thing you may not have explored many alternatives. I'd recommend trying out some other VCSes, just to get a broader picture of how they function. I think doing that helps to get a grip on what your specific needs actually are, as well as a better understanding of the tradeoffs for whatever tool you pick. None of them I've seen are 100% superior. Secondly, I love tortoisehg specifically because of the command line. Doing a simple commit with mercurial just takes `hg ci`. Doing a commit using the gui just takes `thg ci`. The latter one pops up a gui for me to stage the commit, and then I'm back in the console again. IMO it's the best of both worlds -- I don't have to get knocked out of the commandline until I need to, and I can trigger whatever gui action explicitly, as part of my existing workflow. There are some things which I think are just fundamentally better with a gui -- whether it's a curses-style "TUI", or proper graphics. Under tortoisehg, if I'm cherry picking for a commit, I can double click to open up a file in meld to make last-minute edits, shelve bits away for later, all kinds of one-off actions which are much more complex from the command line. Not to mention performing complex searches on VCS history. It's a lack of an equivalently powerful cli-controlled gui for git which has kept me using hg as my primary vcs.
- Sir_Cmpwn 10y ago
  You're making a number of assumptions yourself. >For one, TortoiseHg isn't windows only. It's a python+qt based application that works uniformly pretty much everywhere. Yeah, admitted this mistake elsewhere. >That fact that you made that assumption makes me thing you may not have explored many alternatives. I'd recommend trying out some other VCSes, just to get a broader picture of how they function. I think doing that helps to get a grip on what your specific needs actually are, as well as a better understanding of the tradeoffs for whatever tool you pick. None of them I've seen are 100% superior. I have used, in this order, visual source safe, TFS, SVN, Hg, git. >Secondly, I love tortoisehg specifically because of the command line. Doing a simple commit with mercurial just takes `hg ci`. Doing a commit using the gui just takes `thg ci`. The latter one pops up a gui for me to stage the commit, and then I'm back in the console again. Doing a simple commit with git is just git commit. What am I missing here? You could alias it to git ci if you want. >There are some things which I think are just fundamentally better with a gui -- whether it's a curses-style "TUI", or proper graphics. Under tortoisehg, if I'm cherry picking for a commit, I can double click to open up a file in meld to make last-minute edits, shelve bits away for later, all kinds of one-off actions which are much more complex from the command line. Not to mention performing complex searches on VCS history. These aren't more complex on the command line, they're just done differently. They aren't as intuitive as a GUI, where the button is presented to you rather than having to read about a flag in the man pages. But VCS is a tool you use all day every day, it's worth it to learn about it in depth.

krupan 10y ago

tortoiseHG is not windows only

Sir_Cmpwn 10y ago
My mistake. The point remains - users who are more comfortable in a GUI are in a similar boat.

ufo 10y ago

The real reason ther eare few git GUIs is not that git expects advanced users that can use the command line. It is that it is very very hard to create a GUI for git due to the way it is built as a complex web of web of scripts written in C, Shell and Perl. This architecture is the reason why projects such as libgit had to reimplement a lot of core git algorithms. https://libgit2.github.com/ https://libgit2.github.com/ Mercurial, on the other hand is more amenable for extension due to being built our of a bunch of Python modules.

Sir_Cmpwn 10y ago
You're half right, but coming from the wrong place. The fact that git is hard to make a GUI for is an intentional design choice in git. It was built to be CLI first and shoehorning a GUI onto it is the wrong way to use git. The correct way is to learn how to be comfortable in a CLI. Git's design with that web of shell and perl and C is totally fine and suited to a CLI-first application.
- warbiscuit 10y ago
  I think different tasks are (more) suitable to different interfaces. CLIs are great when the space of actions you could perform is large (to nigh uncountable), but the range of subjects is small (the file paths, etc are known). Since you know the subjects, a programming language like `sh` is the most concise way to express a complex action. GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...). Many complex tools like VCSes contain both kinds of situations. I think sometimes a CLI is more appropriate, and sometimes a GUI is, depending on the context. IMO a fully mature VCS should make it as easy to invoke a gui for complex tasks as it is to do them from the command line.
  - Sir_Cmpwn 10y ago
    >GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...). Those examples are not only possible, but easy to do in the CLI for an advanced user. I do that sort of thing every day. I agree that some tasks are better suited to a GUI and some are better suited to a CLI, but your VCS is firmly in the latter camp imo.
    - warbiscuit 10y ago
      As a semi-concrete example, say you have a VCS checkout with 40 edited chunks across 15 files. You want to commit 20 of 40 chunks (spread across 6 of 15 of the files). When you're halfway done, you notice a typo needs correcting in chunk 16, and fix it. You then proceed to commit your selection. From the command prompt, invoking thg and doing that took me about 18 seconds. I'm reasonably good on the command line, but I certainly don't see how to beat that time using just the cli. I think saying it's "easy for an advanced user" is a little loaded, but I'm still interested to know how to do that task faster. And if such a cli process could only be done with git, I'd consider switching.
- Amezarak 10y ago
  It seems unintuitive to me that manipulating a graph via a GUI should be the wrong way to operate. I find it difficult to imagine this argument would be made if git were not the DVCS of choice. I would say, though, that the ideal GUI for a DVCS has probably not been invented yet.
  - slrz 10y ago
    Right and it's pretty sad, I think. Most contemporary software doesn't even try making use of graphic displays and mouse input to create a more efficient interface for trained professionals, often lacking even the most basic forms of ad-hoc programmability.

warbiscuit 10y ago

I'd disagree with a number of assumptions in that statement. For one, TortoiseHg isn't windows only. It's a python+qt based application that works uniformly pretty much everywhere. That fact that you made that assumption makes me thing you may not have explored many alternatives. I'd recommend trying out some other VCSes, just to get a broader picture of how they function. I think doing that helps to get a grip on what your specific needs actually are, as well as a better understanding of the tradeoffs for whatever tool you pick. None of them I've seen are 100% superior. Secondly, I love tortoisehg specifically because of the command line. Doing a simple commit with mercurial just takes `hg ci`. Doing a commit using the gui just takes `thg ci`. The latter one pops up a gui for me to stage the commit, and then I'm back in the console again. IMO it's the best of both worlds -- I don't have to get knocked out of the commandline until I need to, and I can trigger whatever gui action explicitly, as part of my existing workflow. There are some things which I think are just fundamentally better with a gui -- whether it's a curses-style "TUI", or proper graphics. Under tortoisehg, if I'm cherry picking for a commit, I can double click to open up a file in meld to make last-minute edits, shelve bits away for later, all kinds of one-off actions which are much more complex from the command line. Not to mention performing complex searches on VCS history. It's a lack of an equivalently powerful cli-controlled gui for git which has kept me using hg as my primary vcs.

Sir_Cmpwn 10y ago
You're making a number of assumptions yourself. >For one, TortoiseHg isn't windows only. It's a python+qt based application that works uniformly pretty much everywhere. Yeah, admitted this mistake elsewhere. >That fact that you made that assumption makes me thing you may not have explored many alternatives. I'd recommend trying out some other VCSes, just to get a broader picture of how they function. I think doing that helps to get a grip on what your specific needs actually are, as well as a better understanding of the tradeoffs for whatever tool you pick. None of them I've seen are 100% superior. I have used, in this order, visual source safe, TFS, SVN, Hg, git. >Secondly, I love tortoisehg specifically because of the command line. Doing a simple commit with mercurial just takes `hg ci`. Doing a commit using the gui just takes `thg ci`. The latter one pops up a gui for me to stage the commit, and then I'm back in the console again. Doing a simple commit with git is just git commit. What am I missing here? You could alias it to git ci if you want. >There are some things which I think are just fundamentally better with a gui -- whether it's a curses-style "TUI", or proper graphics. Under tortoisehg, if I'm cherry picking for a commit, I can double click to open up a file in meld to make last-minute edits, shelve bits away for later, all kinds of one-off actions which are much more complex from the command line. Not to mention performing complex searches on VCS history. These aren't more complex on the command line, they're just done differently. They aren't as intuitive as a GUI, where the button is presented to you rather than having to read about a flag in the man pages. But VCS is a tool you use all day every day, it's worth it to learn about it in depth.