8 ms·

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? W

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and today people still just nuke a directory because they can't figure out the arcane arts. I am one of those people, at times. Because it's faster to do so than read heaps of manpages for a situation I may never hit again. Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.

indy 4y ago
I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?
- 8n4vidtmkvmk 4y ago
  hg up --clean i dont know why mercurial doesn't get more love.
  - geenat 4y ago
    It was loved. I blame all the platforms dropping support for it. Github really is git's best PR.
  - javajosh 4y ago
    hg is indeed the better tool. Just as microkernels are the better kernel design. By existing and working (which is no small feat), Linux obliterates both alternatives in the zeitgeist. This is, of course, the great downside to "worse is better".
  - tempest_ 4y ago
    We used hg when I started at my current position. From a developer stand point the experience was better but all the tooling and integrations are git based so we switched.
  - bvrmn 4y ago
    As I remember `hg up` requires network access. What if you break a repo offline?
    - capitainenemo 4y ago
      hg clean ? Actually, wait. hg up doesn't require network access. Maybe you're thinking of hg pull -u or svn up
      - bvrmn 4y ago
        So you should also read the manual to know about. There no such thing as "intuitive" in VCS world. Looks like most of commentators confuse intuitiveness with familiarity. Don't get me wrong I appreciate mercurial devs did a tremendous work to hide DVCS under SVN-like ("simple" hah) interface. But every non-standard thing requires manual reading.
      - bvrmn 4y ago
        > hg up doesn't require network access. So it's like `git checkout` and doesn't cover all breakage cases.
        capitainenemo 4y ago
        Not sure how to answer that, but sure, I can imagine plenty of ways in which a local repo could be screwed up that might require a strip or just a complete fresh pull. "All breakage cases" is pretty broad. My personal reasons for liking mercurial is some pretty amazing tooling (hg absorb, hg fa --deleted, revsets/filesets) combined with a friendly commandline with fairly sensible defaults.
        8n4vidtmkvmk 4y ago
        Dunno what scenario it would fail on. You can also clone a local repo as long as you didn't mangle the .hg dir
  - mbfg 4y ago
    mercurial was pretty nice, and if you have a "beginner developer team", mercurial is probably my recommendation. but how git does branching is just better in a way you just can't get past, once you use it. Luckily it's usually pretty simple to start with hg and move to git at a later date.
    - 8n4vidtmkvmk 4y ago
      Hg branching makes more sense to me. You can update to any changeset and then just start coding and it will naturally branch. If you want something more permanent you can create a named branch. If you can't find your unnamed branches you can bookmark or tag them.
- sophacles 4y ago
  Not as many as svn or cvs for sure. That's part of why it became popular. There was a job title "merge master" - literally there were people who's job was to handle merging in various feature branches. If you didn't have this person you risked days or even weeks of downtime because no one could use the central server without risk of making the situation worse. You would regularly open a file and find your work had been stomped on because one person added a small doc fix in their version of a file and merged it after your work went in, but the vcs didn't really merge, it just overwrote. I'm not saying it can't be better - clearly it can. Just pointing out that one person spending a little time unfucking a branch is massively superior to everyone not being able to work because that same person fucked up everyone's branches.
relyks 4y ago
You and me both. Git's interface has been very hard for me to understand (especially coming from Mercurial). I ended up finding Gitless (https://gitless.com https://gitless.com), a wrapper around Git with a better interface, and loving it. The original author hasn't updated it in a long time, but I've been using a maintained fork that's been pretty sweet: https://github.com/goldstar611/gitless https://github.com/goldstar611/gitless
- bmitc 4y ago
  I came to Git from Perforce and have also had a tough time. Perforce had well-named actions. I was able to learn it quickly and even do custom devops things with its API. For Git, I do the absolute bare minimum in terms of workflow because very little of it is well-designed or makes sense. There's also a lot of snark in its language. I think I was wanting to try to interactively add on the command line, but got out because it was impossible to use without reading a manual and didn't appreciate "what now" and other such things. There are also very few use cases that require its complex distributive model.
parasti 4y ago
Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Because Git is really just a brilliantly simple data structure manipulated by dozens of ad-hoc commands.
- LtWorf 4y ago
  How to waste a week without learning anything useful about actually using git :D At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.
- bilekas 4y ago
  > You can't learn Git by using its commands. From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools. Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.
  - parasti 4y ago
    > Once you know what is happening, even those crazy states you can find yourself in really are not that hard. I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?
    - bilekas 4y ago
      > But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense. You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.
CannisterFlux 4y ago
I find few of my fellow coworker devs know about or use gitk, and it is an awesome tool for visualizing where all the branch madness is. A lot of things that require good command-line git knowledge are a few mouse clicks or a menu option away with gitk. Undoing a merge for example (a classic "oh no, I pulled on the wrong branch and now it's all fucked up"), I've no idea how you'd do that with the command line, but in gitk it's just right click the parent commit and choose "reset the branch here".
midenginedcoupe 4y ago
Absolutely. I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits. I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same. I don't want to have to spend time understanding how my editor handles lines in memory in order to use it, why should I have to spend time understanding how my revision control system treats revisions? Tech is hard enough without having to sink time in to unnecessarily complicated tools that can bite you in the bum really hard.
- maccard 4y ago
  > I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same. The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.
  - midenginedcoupe 4y ago
    Well that's a different argument. The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(
    - sgbeal 4y ago
      > But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :( cough Fossil cough
      - mirodin 4y ago
        Amen to that. I love Fossil for its simplicity and batteries included model. No external ticketing, wiki and documentation to manually keep in sync. Plus everything inside a single SQLite file makes everything easier.
josteink 4y ago
> Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. It's a tool aimed at technical people, which at the time it was launched offered features and technical possibilities which was unmatched by most other popular source-control systems at the time. I remember going from Microsoft's Team Foundation Version Control to Git, and everything just felt miles more flexible and capable. Especially branching was enormously limited with Microsoft's offer, while Git literally allowed me to merge anything I wanted, across any base, and usually end up where I wanted to be. In short: Git solved real world problems in a way which more than compensated for its somewhat clunky UX.
knighthack 4y ago
I've never understood this sentiment. We're now in 2022. When working on Linux, especially on desktop versions, most people don't need to use the terminal, ever. You could if you want to, but you don't have to. Similarly, for most things you don't ever have to touch Git on the command line. There are tons of great interfaces overlaying Git - e.g. Sublime Merge, which can visualize what you're doing, and makes Git significantly "nicer to use". You can still descend into the command line, but for whatever you've described above, you don't have to, and you don't have read manpages for common use cases. Your problem with Git is not an insurmountable issue - it's about finding the right tool to use Git with, and which is the way moving forward anyway. Consider ffmpeg. It's extremely powerful, and about as arcane as git, and you'd needs just as many manpages or Google searches to understand it. Yet most people just use software that overlays all the magical conversions that ffmpeg enables - and no one has to see or blame ffmpeg per se. The scenario should be similar with Git, I hazard.
globular-toast 4y ago
> Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Did you see what came before? Git isn't popular because of its UI, it's popular despite its UI. It's considered worth it because of its distributed model and speed. Having said that, I've used magit pretty much from the start and can't understand people who don't switch to a better UI eventually. I don't think a command line UI works well for it at all.
jansan 4y ago
and marvel at how it ever became popular. You obviously have not used the alternatives that were available before Git. After CVS and Subversion, Git was just a breeze of fresh air. But UX still has a lot of room for improvement.
andyjohnson0 4y ago
I agree. I use git on a daily basis, and I think I'm converging on some intermediate level of understanding, but I constantly find it difficult to use. I go backwards and forwards between wondering whether (after three decades as a developer) my brain is just too used to the SVN approach of centralised repositories and branches-are-directories -- and at the other extreme thinking that there is something unbalanced(?) about its abstractions and power. For very large projects (eg Linux-scale or Windows-scale) I can totally see why it is the best versioning solution. But most software isn't like that: it's relatively small teams maintaining a legacy codebase and making fairly incremental enhancements. I struggle with what git brings to that vs the cognitive overhead of using it. I've recently migrated a moderately large codebase from TFS to GitHub. A large part of what drove that was co-workers who were reluctant to use TFS - I suspect that they found it old-fashioned, and that kind of bothers me, even though git is clearly the future and TFS clearly isn't. I like diversity of tools, and tools that don't force me to think too hard about things that should be easy. The knowledge that git could turn into a foot-gun just when I most need to get things done, doesn't help. <edit> After some consideration, I think what I'd like is a tool that gives me a simple SVN-style UX over a real git repo, with the option to drop down into actual git of necessary, and so that colleagues can use only git if they prefer. Github desktop partly achieves this, as does Visual Studio's git integration, but it's not quite what I want.</edit> (Not a git hater. I've had a github account for over a decade and choose to use it a lot for personal projects. But mostly just simple, sequential check-ins over time.)
- dasil003 4y ago
  This take is surprising to me as I spent a decade using cvs/svn and at the end of that I didn’t really understand how it worked well enough to have any confidence branching and merging. Switching to git was a steep learning curve but made so much more conceptual sense that in a few months I was very confident in branching and merging and with a couple years had a deep and intuitive understanding of rebasing. Git allows me to edit my work before I push it, committing early and often to help my local development, then editing and packaging into atomic and well-documented commits that will make sense years down the line without wading through the irrelevant hiccups that were part of the short-term development cycle. I won’t defend the git porcelain because it is incredibly baroque, but because it’s backed by a robust a simple data model underneath I see that as more of a rote memorization challenge than a fundamental flaw. This is far preferable to svn which conflates repos, directories, branches and tags, resulting in the possibility of nonsensical operations and unresolvable merge situations.
dale_glass 4y ago
Let me try! > Even a simple merge/rebase leaves one confused. Which should I use? Merge merges two branches. You fork a branch off master, work on stuff until it's done, then merge it back into master. After that the branch can go away. Rebase is for rewriting history. To get rid of the 20 embarrassing commits where you tweaked stuff at random hoping to get it to work, or to redo a bunch of changes in a more coherent and easier to review way. It can be used to transplant work from one branch to another. It also can be used to keep up with the changes in the branch you forked off from. > What is incoming? Why does incoming change as you progress? Not quite sure what you mean, could you provide more details? > I didn't change anything (on purpose) but Git won't let me change branches. Probably because changing branches would lose your current work. It can happen either mid-rebase, or because you modified a file that would be overwritten by a branch change. > How do I just unfuck what I did and go back to a branch? You can abort a rebase with `git rebase --abort`. This loses progress. > Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use. I agree the UI leaves a lot to be desired. But the main thing is that you need to understand what it is that you want to accomplish first, especially in the merge/rebase question.
sophacles 4y ago
> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then they ever were in those old systems - I've never spent more than an hour dealing with the results of git issues, but I've lost literal weeks to a single svn mishap. Why did git win over other dvcs systems? 2 main reasons I see: 1. Linux uses it - literally, that means its the "cool one" 2. Linux uses it - and that means the people developing it work similar to the kernel, they are willing to try a lot of different ways to acheive the task resulting in both some amazing cool stuff and a lot of cruft left hanging out for various compatability and "accidentally super important structurally" reasons.
- jerf 4y ago
  There's a lesson here, too. To unseat git, you need to not just be slightly better than it; you need to have a big use case for many people and be radically better than it in that particular use case. You even can be worse than git in some others as long as you have that radical improvement to build on. Being merely better isn't enough; see mercurial. The use case actually has to be important to people in real life, too, not just be something that sounds cool or people might say is important but they don't actually exert any effort towards implementing; see fossil. The problem is that it's not clear what that will be. It wasn't hard to tell branch merging was a huge weak spot of SVN even if you were close enough to it to not see the forest for the trees. What is git's weak spot? People might jump up to say "interface!" but the reality is, no, it's not; again see mercurial. Talk is cheap and complaints are cheaper but the reality is the community is not switching en masse because of that. Large binary files is certainly a weak spot and I understand there are some commercial solutions for that that edge out git, but that's not going to edge out git in general because the pain isn't enough for most projects, and while git-lfs isn't necessarily the slickest solution ever it's good enough for programming projects. Submodules are awful but it's not clear to me that there is enough pain there to make people switch even if you made that slick as can be. (Plus, if something did start eating git's lunch because of that, there are improvements git can make that would blunt the impact. Git's fundamental model means submodules are always going to be weird but it doesn't have to be as bad as it is. I think backwards compatibility prevents git from fixing the problems but if something was really a threat it could overcome that and they'd be improved.) I expect to still be using git for many many years yet.
Aozora7 4y ago
I find git reasonably understandable as long as you are using a GUI. When you have a GUI, every action you take provides you visual feedback, so it's way easier to understand the purposes of merges, rebeases, stashes, and resets. My understanding of git workflow greatly improved thanks to it.
- c7DJTLrn 4y ago
  On the contrary, I've met plenty of people who struggle along with a GUI because they don't want to learn the CLI. They mash fetch and pull rhymthically hoping it will do what they want with no clue what it's really doing underneath. Eventually, they give up, nuke the repo and reclone it. Most CLI users I've met are at least competent at using git.
  - Aozora7 4y ago
    I have the opposite experience, the CLI users I see pretty much never use anything besides commit, push and pull, while GUI users tend to use more advanced commands since they can actually see what they do.
- IshKebab 4y ago
  I completely agree. A GUI also lets you avoid the terrible CLI. Plus the commit graph is a visual thing. It makes sense to view it in a GUI. Definitely the best way to learn.
arein3 4y ago
Use sourcetree (older versions) or smartigit(similar ui to sourcetree) if you are on linux Makes life a lot easier
- swozey 4y ago
  I love gitkraken when I'm stumped
bvrmn 4y ago
Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't see any hurdles to allocate one evening and read https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/. It gives a model that you can apply to other distributed VCS and may be make you a better engineer.
- quietbritishjim 4y ago
  Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if something went wrong - then I could strip the originals when the dust settled). Hg is so easy to use that you can feel really confident manipulating the commit graph, in a way you normally wouldn't risk in git. It helps that Mercurial has a really nice cross platform GUI: TortoiseHg. Version control is one of those things that really benefits from a GUI because you're manipulating small elements complex object - the commit graph. Using the command line is bit like using ed to edit a text file (i.e. with commands like "insert xyz between lines 12 and 13").
  - troyvit 4y ago
    Yeah Mercurial seems like what git should have been but never will be.
  - AvImd 4y ago
    Is there any option to have this "private commits" feature in git? I just realized it's exactly what I wanted so many times. I've tried the assume-unchanged hack but it's too brittle.
SassyGrapefruit 4y ago
I think git is wonderfully elegant and simple. I wish more people would take the time to sit down and understand it. It only takes maybe an hour or two. >Even a simple merge/rebase leaves one confused. I've never had this problem. Git always works exactly as its designed for me.
- stonekyx 4y ago
  Exactly. Git felt totally intuitive to me when I started using it as a teenager (with no background on SVN et al. of course), and most colleagues I've met so far also rarely had troubles using it. The latter is probably because I intentionally chose to work for companies that use Git though.
coryrc 4y ago
http://learngitbranching.js.org http://learngitbranching.js.org is all anyone needs to use git effectively. Though even knowing, Mercurial is still a better experience, but not by enough.
tommyage 4y ago
Maybe you should try a proven front-end in order. Maybe you are kind of a visual learner.

indy 4y ago

I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?

8n4vidtmkvmk 4y ago
hg up --clean i dont know why mercurial doesn't get more love.
- geenat 4y ago
  It was loved. I blame all the platforms dropping support for it. Github really is git's best PR.
- javajosh 4y ago
  hg is indeed the better tool. Just as microkernels are the better kernel design. By existing and working (which is no small feat), Linux obliterates both alternatives in the zeitgeist. This is, of course, the great downside to "worse is better".
- tempest_ 4y ago
  We used hg when I started at my current position. From a developer stand point the experience was better but all the tooling and integrations are git based so we switched.
- bvrmn 4y ago
  As I remember `hg up` requires network access. What if you break a repo offline?
  - capitainenemo 4y ago
    hg clean ? Actually, wait. hg up doesn't require network access. Maybe you're thinking of hg pull -u or svn up
    - bvrmn 4y ago
      So you should also read the manual to know about. There no such thing as "intuitive" in VCS world. Looks like most of commentators confuse intuitiveness with familiarity. Don't get me wrong I appreciate mercurial devs did a tremendous work to hide DVCS under SVN-like ("simple" hah) interface. But every non-standard thing requires manual reading.
    - bvrmn 4y ago
      > hg up doesn't require network access. So it's like `git checkout` and doesn't cover all breakage cases.
      - capitainenemo 4y ago
        Not sure how to answer that, but sure, I can imagine plenty of ways in which a local repo could be screwed up that might require a strip or just a complete fresh pull. "All breakage cases" is pretty broad. My personal reasons for liking mercurial is some pretty amazing tooling (hg absorb, hg fa --deleted, revsets/filesets) combined with a friendly commandline with fairly sensible defaults.
      - 8n4vidtmkvmk 4y ago
        Dunno what scenario it would fail on. You can also clone a local repo as long as you didn't mangle the .hg dir
- mbfg 4y ago
  mercurial was pretty nice, and if you have a "beginner developer team", mercurial is probably my recommendation. but how git does branching is just better in a way you just can't get past, once you use it. Luckily it's usually pretty simple to start with hg and move to git at a later date.
  - 8n4vidtmkvmk 4y ago
    Hg branching makes more sense to me. You can update to any changeset and then just start coding and it will naturally branch. If you want something more permanent you can create a named branch. If you can't find your unnamed branches you can bookmark or tag them.
sophacles 4y ago
Not as many as svn or cvs for sure. That's part of why it became popular. There was a job title "merge master" - literally there were people who's job was to handle merging in various feature branches. If you didn't have this person you risked days or even weeks of downtime because no one could use the central server without risk of making the situation worse. You would regularly open a file and find your work had been stomped on because one person added a small doc fix in their version of a file and merged it after your work went in, but the vcs didn't really merge, it just overwrote. I'm not saying it can't be better - clearly it can. Just pointing out that one person spending a little time unfucking a branch is massively superior to everyone not being able to work because that same person fucked up everyone's branches.

relyks 4y ago

You and me both. Git's interface has been very hard for me to understand (especially coming from Mercurial). I ended up finding Gitless (https://gitless.com https://gitless.com), a wrapper around Git with a better interface, and loving it. The original author hasn't updated it in a long time, but I've been using a maintained fork that's been pretty sweet: https://github.com/goldstar611/gitless https://github.com/goldstar611/gitless

bmitc 4y ago
I came to Git from Perforce and have also had a tough time. Perforce had well-named actions. I was able to learn it quickly and even do custom devops things with its API. For Git, I do the absolute bare minimum in terms of workflow because very little of it is well-designed or makes sense. There's also a lot of snark in its language. I think I was wanting to try to interactively add on the command line, but got out because it was impossible to use without reading a manual and didn't appreciate "what now" and other such things. There are also very few use cases that require its complex distributive model.

parasti 4y ago

Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Because Git is really just a brilliantly simple data structure manipulated by dozens of ad-hoc commands.

LtWorf 4y ago
How to waste a week without learning anything useful about actually using git :D At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.
bilekas 4y ago
> You can't learn Git by using its commands. From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools. Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.
- parasti 4y ago
  > Once you know what is happening, even those crazy states you can find yourself in really are not that hard. I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?
  - bilekas 4y ago
    > But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense. You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.

CannisterFlux 4y ago

I find few of my fellow coworker devs know about or use gitk, and it is an awesome tool for visualizing where all the branch madness is. A lot of things that require good command-line git knowledge are a few mouse clicks or a menu option away with gitk. Undoing a merge for example (a classic "oh no, I pulled on the wrong branch and now it's all fucked up"), I've no idea how you'd do that with the command line, but in gitk it's just right click the parent commit and choose "reset the branch here".

midenginedcoupe 4y ago

Absolutely. I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits. I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same. I don't want to have to spend time understanding how my editor handles lines in memory in order to use it, why should I have to spend time understanding how my revision control system treats revisions? Tech is hard enough without having to sink time in to unnecessarily complicated tools that can bite you in the bum really hard.

maccard 4y ago
> I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same. The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.
- midenginedcoupe 4y ago
  Well that's a different argument. The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(
  - sgbeal 4y ago
    > But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :( cough Fossil cough
    - mirodin 4y ago
      Amen to that. I love Fossil for its simplicity and batteries included model. No external ticketing, wiki and documentation to manually keep in sync. Plus everything inside a single SQLite file makes everything easier.

josteink 4y ago

> Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. It's a tool aimed at technical people, which at the time it was launched offered features and technical possibilities which was unmatched by most other popular source-control systems at the time. I remember going from Microsoft's Team Foundation Version Control to Git, and everything just felt miles more flexible and capable. Especially branching was enormously limited with Microsoft's offer, while Git literally allowed me to merge anything I wanted, across any base, and usually end up where I wanted to be. In short: Git solved real world problems in a way which more than compensated for its somewhat clunky UX.

knighthack 4y ago

I've never understood this sentiment. We're now in 2022. When working on Linux, especially on desktop versions, most people don't need to use the terminal, ever. You could if you want to, but you don't have to. Similarly, for most things you don't ever have to touch Git on the command line. There are tons of great interfaces overlaying Git - e.g. Sublime Merge, which can visualize what you're doing, and makes Git significantly "nicer to use". You can still descend into the command line, but for whatever you've described above, you don't have to, and you don't have read manpages for common use cases. Your problem with Git is not an insurmountable issue - it's about finding the right tool to use Git with, and which is the way moving forward anyway. Consider ffmpeg. It's extremely powerful, and about as arcane as git, and you'd needs just as many manpages or Google searches to understand it. Yet most people just use software that overlays all the magical conversions that ffmpeg enables - and no one has to see or blame ffmpeg per se. The scenario should be similar with Git, I hazard.

globular-toast 4y ago

> Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Did you see what came before? Git isn't popular because of its UI, it's popular despite its UI. It's considered worth it because of its distributed model and speed. Having said that, I've used magit pretty much from the start and can't understand people who don't switch to a better UI eventually. I don't think a command line UI works well for it at all.

jansan 4y ago

and marvel at how it ever became popular. You obviously have not used the alternatives that were available before Git. After CVS and Subversion, Git was just a breeze of fresh air. But UX still has a lot of room for improvement.

andyjohnson0 4y ago

I agree. I use git on a daily basis, and I think I'm converging on some intermediate level of understanding, but I constantly find it difficult to use. I go backwards and forwards between wondering whether (after three decades as a developer) my brain is just too used to the SVN approach of centralised repositories and branches-are-directories -- and at the other extreme thinking that there is something unbalanced(?) about its abstractions and power. For very large projects (eg Linux-scale or Windows-scale) I can totally see why it is the best versioning solution. But most software isn't like that: it's relatively small teams maintaining a legacy codebase and making fairly incremental enhancements. I struggle with what git brings to that vs the cognitive overhead of using it. I've recently migrated a moderately large codebase from TFS to GitHub. A large part of what drove that was co-workers who were reluctant to use TFS - I suspect that they found it old-fashioned, and that kind of bothers me, even though git is clearly the future and TFS clearly isn't. I like diversity of tools, and tools that don't force me to think too hard about things that should be easy. The knowledge that git could turn into a foot-gun just when I most need to get things done, doesn't help. <edit> After some consideration, I think what I'd like is a tool that gives me a simple SVN-style UX over a real git repo, with the option to drop down into actual git of necessary, and so that colleagues can use only git if they prefer. Github desktop partly achieves this, as does Visual Studio's git integration, but it's not quite what I want.</edit> (Not a git hater. I've had a github account for over a decade and choose to use it a lot for personal projects. But mostly just simple, sequential check-ins over time.)

dasil003 4y ago
This take is surprising to me as I spent a decade using cvs/svn and at the end of that I didn’t really understand how it worked well enough to have any confidence branching and merging. Switching to git was a steep learning curve but made so much more conceptual sense that in a few months I was very confident in branching and merging and with a couple years had a deep and intuitive understanding of rebasing. Git allows me to edit my work before I push it, committing early and often to help my local development, then editing and packaging into atomic and well-documented commits that will make sense years down the line without wading through the irrelevant hiccups that were part of the short-term development cycle. I won’t defend the git porcelain because it is incredibly baroque, but because it’s backed by a robust a simple data model underneath I see that as more of a rote memorization challenge than a fundamental flaw. This is far preferable to svn which conflates repos, directories, branches and tags, resulting in the possibility of nonsensical operations and unresolvable merge situations.

dale_glass 4y ago

Let me try! > Even a simple merge/rebase leaves one confused. Which should I use? Merge merges two branches. You fork a branch off master, work on stuff until it's done, then merge it back into master. After that the branch can go away. Rebase is for rewriting history. To get rid of the 20 embarrassing commits where you tweaked stuff at random hoping to get it to work, or to redo a bunch of changes in a more coherent and easier to review way. It can be used to transplant work from one branch to another. It also can be used to keep up with the changes in the branch you forked off from. > What is incoming? Why does incoming change as you progress? Not quite sure what you mean, could you provide more details? > I didn't change anything (on purpose) but Git won't let me change branches. Probably because changing branches would lose your current work. It can happen either mid-rebase, or because you modified a file that would be overwritten by a branch change. > How do I just unfuck what I did and go back to a branch? You can abort a rebase with `git rebase --abort`. This loses progress. > Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use. I agree the UI leaves a lot to be desired. But the main thing is that you need to understand what it is that you want to accomplish first, especially in the merge/rebase question.

sophacles 4y ago

> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then they ever were in those old systems - I've never spent more than an hour dealing with the results of git issues, but I've lost literal weeks to a single svn mishap. Why did git win over other dvcs systems? 2 main reasons I see: 1. Linux uses it - literally, that means its the "cool one" 2. Linux uses it - and that means the people developing it work similar to the kernel, they are willing to try a lot of different ways to acheive the task resulting in both some amazing cool stuff and a lot of cruft left hanging out for various compatability and "accidentally super important structurally" reasons.

jerf 4y ago
There's a lesson here, too. To unseat git, you need to not just be slightly better than it; you need to have a big use case for many people and be radically better than it in that particular use case. You even can be worse than git in some others as long as you have that radical improvement to build on. Being merely better isn't enough; see mercurial. The use case actually has to be important to people in real life, too, not just be something that sounds cool or people might say is important but they don't actually exert any effort towards implementing; see fossil. The problem is that it's not clear what that will be. It wasn't hard to tell branch merging was a huge weak spot of SVN even if you were close enough to it to not see the forest for the trees. What is git's weak spot? People might jump up to say "interface!" but the reality is, no, it's not; again see mercurial. Talk is cheap and complaints are cheaper but the reality is the community is not switching en masse because of that. Large binary files is certainly a weak spot and I understand there are some commercial solutions for that that edge out git, but that's not going to edge out git in general because the pain isn't enough for most projects, and while git-lfs isn't necessarily the slickest solution ever it's good enough for programming projects. Submodules are awful but it's not clear to me that there is enough pain there to make people switch even if you made that slick as can be. (Plus, if something did start eating git's lunch because of that, there are improvements git can make that would blunt the impact. Git's fundamental model means submodules are always going to be weird but it doesn't have to be as bad as it is. I think backwards compatibility prevents git from fixing the problems but if something was really a threat it could overcome that and they'd be improved.) I expect to still be using git for many many years yet.

Aozora7 4y ago

I find git reasonably understandable as long as you are using a GUI. When you have a GUI, every action you take provides you visual feedback, so it's way easier to understand the purposes of merges, rebeases, stashes, and resets. My understanding of git workflow greatly improved thanks to it.

c7DJTLrn 4y ago
On the contrary, I've met plenty of people who struggle along with a GUI because they don't want to learn the CLI. They mash fetch and pull rhymthically hoping it will do what they want with no clue what it's really doing underneath. Eventually, they give up, nuke the repo and reclone it. Most CLI users I've met are at least competent at using git.
- Aozora7 4y ago
  I have the opposite experience, the CLI users I see pretty much never use anything besides commit, push and pull, while GUI users tend to use more advanced commands since they can actually see what they do.
IshKebab 4y ago
I completely agree. A GUI also lets you avoid the terrible CLI. Plus the commit graph is a visual thing. It makes sense to view it in a GUI. Definitely the best way to learn.

arein3 4y ago

Use sourcetree (older versions) or smartigit(similar ui to sourcetree) if you are on linux Makes life a lot easier

swozey 4y ago
I love gitkraken when I'm stumped

bvrmn 4y ago

Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't see any hurdles to allocate one evening and read https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/. It gives a model that you can apply to other distributed VCS and may be make you a better engineer.

quietbritishjim 4y ago
Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if something went wrong - then I could strip the originals when the dust settled). Hg is so easy to use that you can feel really confident manipulating the commit graph, in a way you normally wouldn't risk in git. It helps that Mercurial has a really nice cross platform GUI: TortoiseHg. Version control is one of those things that really benefits from a GUI because you're manipulating small elements complex object - the commit graph. Using the command line is bit like using ed to edit a text file (i.e. with commands like "insert xyz between lines 12 and 13").
- troyvit 4y ago
  Yeah Mercurial seems like what git should have been but never will be.
- AvImd 4y ago
  Is there any option to have this "private commits" feature in git? I just realized it's exactly what I wanted so many times. I've tried the assume-unchanged hack but it's too brittle.

SassyGrapefruit 4y ago

I think git is wonderfully elegant and simple. I wish more people would take the time to sit down and understand it. It only takes maybe an hour or two. >Even a simple merge/rebase leaves one confused. I've never had this problem. Git always works exactly as its designed for me.

stonekyx 4y ago
Exactly. Git felt totally intuitive to me when I started using it as a teenager (with no background on SVN et al. of course), and most colleagues I've met so far also rarely had troubles using it. The latter is probably because I intentionally chose to work for companies that use Git though.

coryrc 4y ago

http://learngitbranching.js.org http://learngitbranching.js.org is all anyone needs to use git effectively. Though even knowing, Mercurial is still a better experience, but not by enough.

tommyage 4y ago

Maybe you should try a proven front-end in order. Maybe you are kind of a visual learner.