5 ms·

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 p

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.
- warbiscuit 10y ago
  > Doing a simple commit with git is just git commit. What am I missing here? ... > ... These aren't more complex on the command line, they're just done differently. The process I outlined was a series of steps which were all part of what I'd consider an average commit (not necessarily "simple"). Invoking `thg ci` I could cherry pick lines, edit files as I'm reviewing the diffs, shelve away others, all within seconds, without shifting context. There isn't a single "flag" to read about which makes typing all those commands out necessarily faster. Simple commits, I will frequently just do `hg ci` and be done. But if I'm doing a bunch of manipulation, I have click the hunks I want, commit, merge and push, all in much fewer seconds than it would be possible to type the equivalent set of commands. I consider the overall job "tell the computer what I want, as efficiently as possible". For some specific tasks, a mouse just is a better method than a keyboard. I think it's good for complex multi-purpose tools to offer multiple UIs, allowing the user to get work done using the most efficient method tailored to their specific task at hand. That said, I think having them based on the CLI, and using it to trigger a gui, is a far superior meta flow than having a gui trigger a cli just never seems to work out.
  - neandrake 10y ago
    I just recently discovered `hg ci -i` which is a TUI for selecting which changes/hunks to include in the commit. I think it used to be a separate extension but now is part of the main hg distribution. I've tried to use it more now for scenarios where I happened to make multiple modifications to a file while working on a fix/feature and want them in separate commits.

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.

warbiscuit 10y ago
> Doing a simple commit with git is just git commit. What am I missing here? ... > ... These aren't more complex on the command line, they're just done differently. The process I outlined was a series of steps which were all part of what I'd consider an average commit (not necessarily "simple"). Invoking `thg ci` I could cherry pick lines, edit files as I'm reviewing the diffs, shelve away others, all within seconds, without shifting context. There isn't a single "flag" to read about which makes typing all those commands out necessarily faster. Simple commits, I will frequently just do `hg ci` and be done. But if I'm doing a bunch of manipulation, I have click the hunks I want, commit, merge and push, all in much fewer seconds than it would be possible to type the equivalent set of commands. I consider the overall job "tell the computer what I want, as efficiently as possible". For some specific tasks, a mouse just is a better method than a keyboard. I think it's good for complex multi-purpose tools to offer multiple UIs, allowing the user to get work done using the most efficient method tailored to their specific task at hand. That said, I think having them based on the CLI, and using it to trigger a gui, is a far superior meta flow than having a gui trigger a cli just never seems to work out.
- neandrake 10y ago
  I just recently discovered `hg ci -i` which is a TUI for selecting which changes/hunks to include in the commit. I think it used to be a separate extension but now is part of the main hg distribution. I've tried to use it more now for scenarios where I happened to make multiple modifications to a file while working on a fix/feature and want them in separate commits.