5 ms·

That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more er

That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".

beermonster 5y ago
Is it? Or is it just a tool that requires a different mindset so those coming to it from another regular distro? If the latter, then I’m not sure it’s something they will see as a problem but more its very ethos.
- rgoulter 5y ago
  Maybe an apt comparison is git. It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Git still more/less requires you to have a good understanding of what's going on in order to be comfortable using it. But, since use of git is now widespread, it's less of an issue. And the git CLI has seen some UX improvements. Nix is very weird. I'm sure there are some ways its UX could be nicer; but to some extent, doing things in a strict/pure way is always going to have friction if the tools/environments don't easily support that.
  - eitland 5y ago
    > It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the cli.) 2. and to just stick to the basics. (And when you need to help someone else who didn't, take it carefully even if that means you don't look like a wizard.) In fact even working on the command line feels easier once I had worked in a good gui for a while. Don't believe experts who claim that you need to study vim and stick to the git cli to "get it". But of course: if cli is your thing, use it, just stop writing blog posts that claiming it is the only true way.
    - carlmr 5y ago
      Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.
      - copperx 5y ago
        Magit is the most recommended one. But it comes with an Emacs dependency.
      - KronisLV 5y ago
        Here are some recommendations: SourceTree: https://www.sourcetreeapp.com/ https://www.sourcetreeapp.com/ Windows and Mac. Free. Feels sluggish, but is also really dependable, the graph view is lovely and it covers most of the common things that you want to do - also, staging/discarding chunks or even individual lines of code is lovely. Oh, and the Git LFS integration, and creating patches is also really easy. And it gives you the underlying Git commands it uses, in case you care about that. GitKraken: https://www.gitkraken.com/ https://www.gitkraken.com/ Windows, Mac and Linux. May need commercial license. Feels like a step up from SourceTree, but i find that using this for commercial needs is a no go. If that's not an issue, however, it has a good UI, is nice to work with and just generally doesn't have anything i'd object to. IIRC it saved my hide years back by letting me do a ctrl+z for a repo after accidentally forcing to the wrong remote, so that i could fix what i had done (memory might fail me, was years ago), just generally feels intuitive like that. Git Cola: https://git-cola.github.io/ https://git-cola.github.io/ Windows, Mac and Linux. Free and open source. Perhaps one of the more basic interfaces, but as far as free software goes, it does what it sets out to do, and does it well. I use this on Linux, whenever i want to have that visual feedback about the state of the repo/staging area or just don't feel like using the CLI. TortoiseGit: https://tortoisegit.org/ https://tortoisegit.org/ Windows only. Free. Recommending this just because you mentioned TortoiseSVN. If you just want a similar workflow, this is perhaps your best option. Honestly, there is definitely some merit to having a nice file system integration, i rather enjoyed that with SVN. Whatever your IDE has built in: look at your IDE On any platform that your IDE runs on. Same licensing as your IDE. Some people just shop around for an IDE that they enjoy and then just use whatever VCS workflows that they provide. I'd say that VS Code with some plugins is really nice, though others swear by JetBrains' IDEs, whereas others are fine with even just NetBeans or Eclipse (Java example, you can replace that with Visual Studio or whatever). If you're working within a particular stack/IDE, that's not too bad of an idea. The CLI: https://git-scm.com/ https://git-scm.com/ Windows, Mac and Linux. Free and open source. You'll probably want to know a bit of the CLI anyways, just in case. Personally, i'm still way too used to using a GUI since dealing with branches and change sets just feels like something that's more easy when visual, but the CLI has occasionally helped me out nonetheless. Actually, here's a useful list of some of the Git GUIs: https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis For example, did you know that there are some simple GUI tools already built in, git-gui and gitk?
  - pjmlp 5y ago
    I avoid most git usability issues by using it as SVN. When something goes wrong I just bork the whole repo and clone it again, then manually merge the last set of saved changes.
    - tomcam 5y ago
      Thank you! Me too. I can finally come out of the closet.
      - pjmlp 5y ago
        I has been a long journey since I started with RCS back in 1998, but given that git now is everywhere, the least I deal with its complexity the better. In some bad days I even miss Clearcase.
    - carlmr 5y ago
      Since learning about reset --hard, I need about 80% less of that.
      - clem 5y ago
        "git reflog" has also been a blessing in getting out of scrapes.
  - 112233 5y ago
    > It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Easier? Who needs that? Soon then you will have common unlearned folk and peasants trying to use git. </snark> They had the super obtuse git reset, that was four different things bolted together, so they fixed it by adding git restore, that does slightly different things, but you still need both...
- amarshall 5y ago
  The latter. As a (bad) analogy: it’s a bit like learning Haskell. If you’ve only ever worked in strictly-evaluated, imperative languages, it’s not gonna be easy to learn. Nevertheless, Haskell predates e.g. Go by two decades. Nix (and Haskell) has its warts, and undoubtedly a new system would avoid them (compatibility needs make some changes very challenging), but the fundamental difficulty remains because it is fundamentally different and solving a truly difficult problem set.
KronisLV 5y ago
> That is extremely concerning, then, that it is so difficult to use after all that time. > I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years". I feel much the same way about wanting to run something like FreeBSD and having it just work, as opposed to running into weirdness because of the driver situation, with which GNU/Linux seems to be getting better at (even though you sometimes are forced to install proprietary ones for optimal experience, should get better in the next decade). So, might have to wait for a bunch more years, or just pick something else, like OpenBSD, or just run in a set of constraints for having a really predictable and well supported hardware configuration, which isn't always possible. Alas, my off brand Polish netbook will just have to wait before i can (hopefully) run BSD on it comfortably. Well, short of making the missing pieces of puzzle myself, for which i'd probably also need a decade or so of systems level development experience, as opposed to just web dev and occasionally dabbling in lower level stuff to mediocre success. Of course, by then the netbook itself might not be relevant, so who knows. I also feel much the same way about GNU/Hurd - a project that is conceptually interesting, but isn't yet quite stable, even though apparently you can get Debian for it: https://www.gnu.org/software/hurd/ https://www.gnu.org/software/hurd/ Now, i don't have almost any experience with it, apart from reading about it, but some people tried figuring out when it could be released based on the bug reports and how quickly they were being addressed, and the number that they came up with was around 2070 or so. In summary, there are probably projects out there, for which their age isn't necessarily related to how usable they are, whereas other pieces of software will have never truly achieved that stability in the first place. Not all old software is good (edit: at least not for certain use cases). Of course, there are exceptions, for example, you can look at Apache2/httpd: it is regarded as old and dated for the most part, however just recently an update was released, which added mod_md. It now lets you get Let's Encrypt certificates without external tools (like Certbot), in some ways setting it ahead of Nginx: https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html Not all old software is always boring. Same for Docker and any other tools. If developers use tool A for use case X, instead of tool B, then maybe there are some very good reasons for this widespread usage? That's also probably the answer to this debate - regardless of their conceptual/technical benefits, the usability will probably decide which tool will win in the long term.
- 5y ago

That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".

beermonster 5y ago

Is it? Or is it just a tool that requires a different mindset so those coming to it from another regular distro? If the latter, then I’m not sure it’s something they will see as a problem but more its very ethos.

rgoulter 5y ago
Maybe an apt comparison is git. It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Git still more/less requires you to have a good understanding of what's going on in order to be comfortable using it. But, since use of git is now widespread, it's less of an issue. And the git CLI has seen some UX improvements. Nix is very weird. I'm sure there are some ways its UX could be nicer; but to some extent, doing things in a strict/pure way is always going to have friction if the tools/environments don't easily support that.
- eitland 5y ago
  > It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the cli.) 2. and to just stick to the basics. (And when you need to help someone else who didn't, take it carefully even if that means you don't look like a wizard.) In fact even working on the command line feels easier once I had worked in a good gui for a while. Don't believe experts who claim that you need to study vim and stick to the git cli to "get it". But of course: if cli is your thing, use it, just stop writing blog posts that claiming it is the only true way.
  - carlmr 5y ago
    Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.
    - copperx 5y ago
      Magit is the most recommended one. But it comes with an Emacs dependency.
    - KronisLV 5y ago
      Here are some recommendations: SourceTree: https://www.sourcetreeapp.com/ https://www.sourcetreeapp.com/ Windows and Mac. Free. Feels sluggish, but is also really dependable, the graph view is lovely and it covers most of the common things that you want to do - also, staging/discarding chunks or even individual lines of code is lovely. Oh, and the Git LFS integration, and creating patches is also really easy. And it gives you the underlying Git commands it uses, in case you care about that. GitKraken: https://www.gitkraken.com/ https://www.gitkraken.com/ Windows, Mac and Linux. May need commercial license. Feels like a step up from SourceTree, but i find that using this for commercial needs is a no go. If that's not an issue, however, it has a good UI, is nice to work with and just generally doesn't have anything i'd object to. IIRC it saved my hide years back by letting me do a ctrl+z for a repo after accidentally forcing to the wrong remote, so that i could fix what i had done (memory might fail me, was years ago), just generally feels intuitive like that. Git Cola: https://git-cola.github.io/ https://git-cola.github.io/ Windows, Mac and Linux. Free and open source. Perhaps one of the more basic interfaces, but as far as free software goes, it does what it sets out to do, and does it well. I use this on Linux, whenever i want to have that visual feedback about the state of the repo/staging area or just don't feel like using the CLI. TortoiseGit: https://tortoisegit.org/ https://tortoisegit.org/ Windows only. Free. Recommending this just because you mentioned TortoiseSVN. If you just want a similar workflow, this is perhaps your best option. Honestly, there is definitely some merit to having a nice file system integration, i rather enjoyed that with SVN. Whatever your IDE has built in: look at your IDE On any platform that your IDE runs on. Same licensing as your IDE. Some people just shop around for an IDE that they enjoy and then just use whatever VCS workflows that they provide. I'd say that VS Code with some plugins is really nice, though others swear by JetBrains' IDEs, whereas others are fine with even just NetBeans or Eclipse (Java example, you can replace that with Visual Studio or whatever). If you're working within a particular stack/IDE, that's not too bad of an idea. The CLI: https://git-scm.com/ https://git-scm.com/ Windows, Mac and Linux. Free and open source. You'll probably want to know a bit of the CLI anyways, just in case. Personally, i'm still way too used to using a GUI since dealing with branches and change sets just feels like something that's more easy when visual, but the CLI has occasionally helped me out nonetheless. Actually, here's a useful list of some of the Git GUIs: https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis For example, did you know that there are some simple GUI tools already built in, git-gui and gitk?
- pjmlp 5y ago
  I avoid most git usability issues by using it as SVN. When something goes wrong I just bork the whole repo and clone it again, then manually merge the last set of saved changes.
  - tomcam 5y ago
    Thank you! Me too. I can finally come out of the closet.
    - pjmlp 5y ago
      I has been a long journey since I started with RCS back in 1998, but given that git now is everywhere, the least I deal with its complexity the better. In some bad days I even miss Clearcase.
  - carlmr 5y ago
    Since learning about reset --hard, I need about 80% less of that.
    - clem 5y ago
      "git reflog" has also been a blessing in getting out of scrapes.
- 112233 5y ago
  > It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Easier? Who needs that? Soon then you will have common unlearned folk and peasants trying to use git. </snark> They had the super obtuse git reset, that was four different things bolted together, so they fixed it by adding git restore, that does slightly different things, but you still need both...
amarshall 5y ago
The latter. As a (bad) analogy: it’s a bit like learning Haskell. If you’ve only ever worked in strictly-evaluated, imperative languages, it’s not gonna be easy to learn. Nevertheless, Haskell predates e.g. Go by two decades. Nix (and Haskell) has its warts, and undoubtedly a new system would avoid them (compatibility needs make some changes very challenging), but the fundamental difficulty remains because it is fundamentally different and solving a truly difficult problem set.

KronisLV 5y ago

> That is extremely concerning, then, that it is so difficult to use after all that time. > I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years". I feel much the same way about wanting to run something like FreeBSD and having it just work, as opposed to running into weirdness because of the driver situation, with which GNU/Linux seems to be getting better at (even though you sometimes are forced to install proprietary ones for optimal experience, should get better in the next decade). So, might have to wait for a bunch more years, or just pick something else, like OpenBSD, or just run in a set of constraints for having a really predictable and well supported hardware configuration, which isn't always possible. Alas, my off brand Polish netbook will just have to wait before i can (hopefully) run BSD on it comfortably. Well, short of making the missing pieces of puzzle myself, for which i'd probably also need a decade or so of systems level development experience, as opposed to just web dev and occasionally dabbling in lower level stuff to mediocre success. Of course, by then the netbook itself might not be relevant, so who knows. I also feel much the same way about GNU/Hurd - a project that is conceptually interesting, but isn't yet quite stable, even though apparently you can get Debian for it: https://www.gnu.org/software/hurd/ https://www.gnu.org/software/hurd/ Now, i don't have almost any experience with it, apart from reading about it, but some people tried figuring out when it could be released based on the bug reports and how quickly they were being addressed, and the number that they came up with was around 2070 or so. In summary, there are probably projects out there, for which their age isn't necessarily related to how usable they are, whereas other pieces of software will have never truly achieved that stability in the first place. Not all old software is good (edit: at least not for certain use cases). Of course, there are exceptions, for example, you can look at Apache2/httpd: it is regarded as old and dated for the most part, however just recently an update was released, which added mod_md. It now lets you get Let's Encrypt certificates without external tools (like Certbot), in some ways setting it ahead of Nginx: https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html Not all old software is always boring. Same for Docker and any other tools. If developers use tool A for use case X, instead of tool B, then maybe there are some very good reasons for this widespread usage? That's also probably the answer to this debate - regardless of their conceptual/technical benefits, the usability will probably decide which tool will win in the long term.

5y ago