4 ms·

Git is certainly the best of the version control systems to date, and I'm happy that it won. Experts have no problems with issues like this. The described fail

Git is certainly the best of the version control systems to date, and I'm happy that it won. Experts have no problems with issues like this. The described failure mode also can occur in any existing version control system --- the user is essentially did cp -f ../mybranch/somefile-new.c somefile.c; hg commit somefile.c The history in mybranch touching somefile.c is now partly useless, since all the patches are already applied. Of course, the branch can still be merged, if the conflicts are resolved --- the conflict resolution is then pretty much doing the above command again.

mtrn 10y ago
> Git is certainly the best of the version control systems to date, and I'm happy that it won. Me too. What I found was that people do not recognize what tool git really is. People do not read the manuals and count on their world knowledge acquired from years of svn or other centralized systems. It's not the best sign, that you have to really dig git to be able to use it properly. But once you understood the core ideas, you can basically derive a lot of the workflows yourself, in a very principled and clear manner. Also: once you get a bit more familiar with the data model, one almost cannot not appreciate its beauty, I believe.
warbiscuit 10y ago
Honestly, I'm in the exact opposite camp - I'm glad mercurial is still alive and kicking, since I've found my experience with it (and tortoisehg) to be superior in a number of ways. Fewer cross platform issues, a much cleaner commandline interface, can hop over to a much more powerful gui if needed -- I generally use it even when I'm interacting with a git repo. That said, I'm far from an expert in git. What do you see as it's advantages? (outside of the larger mindshare, obviously :)
- nine_k 10y ago
  The UI story of Hg is much better than Git's. The conceptual model of Git looks superior, though: it's more general and more orthogonal. I wish some well thought-out front-end to Git became hugely popular and eventually standard. I mean, including the CLI. Git even has a "plumbing mode" to interact with other programs more easily. But doing that is hard work.
  - rekado 10y ago
    Although I'm quite familiar with git on the command line, I'm using git mostly through magit[1] for Emacs. It's a very functional and discoverable user interface. [1]: https://magit.vc/ https://magit.vc/
    - nine_k 10y ago
      Same here! Magit is brilliant. Emacs is a somehow heavyweight frontend for a VCS, though. OTOH it can be considered a GUI client (and comes with a nice built-in editor).
- Sir_Cmpwn 10y ago
  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.

mtrn 10y ago

> Git is certainly the best of the version control systems to date, and I'm happy that it won. Me too. What I found was that people do not recognize what tool git really is. People do not read the manuals and count on their world knowledge acquired from years of svn or other centralized systems. It's not the best sign, that you have to really dig git to be able to use it properly. But once you understood the core ideas, you can basically derive a lot of the workflows yourself, in a very principled and clear manner. Also: once you get a bit more familiar with the data model, one almost cannot not appreciate its beauty, I believe.

warbiscuit 10y ago

Honestly, I'm in the exact opposite camp - I'm glad mercurial is still alive and kicking, since I've found my experience with it (and tortoisehg) to be superior in a number of ways. Fewer cross platform issues, a much cleaner commandline interface, can hop over to a much more powerful gui if needed -- I generally use it even when I'm interacting with a git repo. That said, I'm far from an expert in git. What do you see as it's advantages? (outside of the larger mindshare, obviously :)

nine_k 10y ago
The UI story of Hg is much better than Git's. The conceptual model of Git looks superior, though: it's more general and more orthogonal. I wish some well thought-out front-end to Git became hugely popular and eventually standard. I mean, including the CLI. Git even has a "plumbing mode" to interact with other programs more easily. But doing that is hard work.
- rekado 10y ago
  Although I'm quite familiar with git on the command line, I'm using git mostly through magit[1] for Emacs. It's a very functional and discoverable user interface. [1]: https://magit.vc/ https://magit.vc/
  - nine_k 10y ago
    Same here! Magit is brilliant. Emacs is a somehow heavyweight frontend for a VCS, though. OTOH it can be considered a GUI client (and comes with a nice built-in editor).
Sir_Cmpwn 10y ago
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.