16 ms·

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so natura

by dimgl 6y ago

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is.

varispeed 6y ago
People are being told git is complex and then they are confused when it feels easy when they do something. They assume they are doing something wrong.
rusk 6y ago
I’d be inclined to disagree. I found the learning curve to be quite steep. When you’re used to having a centralised VCS hosted for you it can seem a bit of a chore to take on all this extra responsibility. Once you’re on top of it though it’s great I wouldn’t use anything else.
- nemetroid 6y ago
  > When you’re used to having a centralised VCS hosted for you I think this is the crucial part. Git will come off as difficult and strange if you're used to using a centralized VCS, and expect Git to work like it. But that isn't really indicative of Git's own complexity, just its differentness.
  - rusk 6y ago
    But you are free to use Git in the old centralised way. You don’t have to get into workflows and stuff if you don’t want to. The , just as in the purely centralised case you are still reliant on a oracle but that’s okay in most cases.
8draco8 6y ago
The only concept that I can't put into my muscle memory is reverting changes for one file before commit. This is very easy in SVN but for some reason it's not intuitive git (at least for me), why there can't be something like `git revert filename`. Thankfully I have GitKraren that is helping me with things like that.
- rusk 6y ago
  ‘git checkout filename’ is the equivalent of ‘svn revert filename’
  - walty8 6y ago
    Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's really not easy to get started.
    - rusk 6y ago
      There are numerous git <-> svn cheat sheets ... this is literally one of the first things I learned. I’m kind of bewildered by this to be honest ... I don’t know how somebody with a technical qualification could have trouble with this ...
      - oblio 6y ago
        We shouldn't need a cheat sheet. We shouldn't need Linus's brain dump to be able to use a tool. The Git UI directly models the Git internal model and that's just bad design. It's a completely leaky abstraction. I can use git all right but the fact that I need about 20 different commands to do my job, 95% of them with extra parameters and almost all of them with names that don't reflect what I want to do from a functional point of view is utterly dumb. Again, functional! not technical! The UI should reflect end user functionality, not internal technical details.
        rusk 6y ago
knocte 6y ago
I slightly disagree. I think git is simple, but the UX (the way the commands and flags are designed) is really bad so that's why it's perceived as hard.
- byte1918 6y ago
  It's the case with most UNIX CLI tools and if the author's complaints are true, do we then have to change all UNIX CLI tools? Maybe? The reality is we can't and probably don't need to.
tasubotadas 6y ago
Then you have never used Mercurial.
- erik_seaberg 6y ago
  “How do I branch in Mercurial?” seems to have four long answers, and maybe a patch queue makes five? https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m...
  - tasubotadas 6y ago
    hg branch my_feature Simple.
  - viraptor 6y ago
    You could easily write pages about local/remote branches, heads behaviour, etc. in git. Mercurial also gives you an extra option - bookmarks, but you don't have to use them at all. The deeper explanation doesn't mean more complex system.
rjzzleep 6y ago
I don't get that either. There have been people here arguing that svn and mercurial were both easier to use than git. But the moment I could import SVN to git I immediately switched to Git for everything. And Mercurial... I guess it's a matter of preference, but I personally never got the hang of it. And the fact that they had both SVN style continuous IDs AND hashes was deeply confusing to me. The only thing I did find confusing in the beginning was a) the distinction between pull and fetch. b) getting used to the fact that I don't really care about continuous IDs (or hashes for the most part ) and think more about commits relative to where I currently am. In addition to that things such as `git add -p` or `tig` are so much more convenient compared to other VCS CLIs. But even if CLI isn't what you want we're now a couple years beyond having beautiful third party Git GUIs
- jkeat 6y ago
  If anyone is looking for a git GUI, Fork is great https://git-fork.com/ https://git-fork.com/
  - mdpm 6y ago
    Fork is great, I paid for it happily. It's UI makes sense, radiates the right level of information, and you can use the keyboard almost exclusively. Heavily recommended.
ramraj07 6y ago
I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use the terminal for cherry picking. The reason I want to stick to the basics is because of one interesting thing I've noticed: a lot of engineers sincerely believe that they are git experts when they are nowhere close. And until I locked down the GitHub repo with admin privileges, that was a dangerous thing. So I'm trying to work a system where no one in a team where not everyone is truly expert at git only uses the basic commandset from git. One thing I can say again to emphasize - git maybe the simplest Vcs you've used, but it's not a simple tool, and its most definitely not intuitive for everyone. If it is for you, that's great, but maybe there's a lesson here about how not everyone's brains are wired the same.
- zingermc 6y ago
  I've definitely been the victim of my own git hubris. Once, when leaving a job, I decided to copy all of my local WIP branches to the server. I whipped out this fancy --mirror option I had just heard of: git push --mirror $remote Surprise! All branches on the remote repo got wiped. My local refs replaced the refs on the remote. Somehow I found the right commits floating around in the git ether. I was able to recreate the branches, but I had to recreate their names by reading the commit log. Did I mention this happened on my way out the door from a job? In retrospect, I shouldn't have panicked so much -- there were daily backups -- but the sheer terror I felt has made me read the man pages really closely to this day.
  - aulin 6y ago
    this definitely shouldn't happen if shared branches are properly protected against non fastforward pushes
    - mannykannot 6y ago
      ...and if you didn't know that, you shouldn't be using git! To be fair, one should always look up options you are unfamiliar with before using - and Stack Exchange is not an authoritative source. --mirror ...Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end... [my emphasis.] On the other hand, if you are on a system where the behavior can be fundamentally altered by multiple configuration options, this will not necessarily help you much. ...This is the default if the configuration option remote.<remote>.mirror is set.
thdrdt 6y ago
Imho Mercurial is much easier than Git. I have seen team members who lost data with Git but never with Mercurial. I still miss Mercurial. Unfortunately most people moved to Git so I also moved to it.
- hvidgaard 6y ago
  Quite some years ago we switched from git to Mercurial and the amount of VSC mentoring and unfucking the "VCS guys" had do became almost zero. People seriously just got it. Some argued that is was because they had to learn with git, but... since then we've made the switch back to git for other reasons and we've back at wrangling with the tool again. I'd much much rather use Mercurial with Evolve extension - that is really good.
- Mindless2112 6y ago
  There is work being done[1] to make Mercurial work on git repositories. [1] https://www.mercurial-scm.org/wiki/GitExtension https://www.mercurial-scm.org/wiki/GitExtension
- athms 6y ago
  >Unfortunately most people moved to Git so I also moved to it. The Lemming Effect.
Tor3 6y ago
Agreed - I started to use version control back with SCCS somewhen in the early nineties, and RCS, CVS, Subversion, ClearCase, some Microsoft horror with a name I can't recall, and a few others. My conclusion is exactly the same as yours: "Git is the simplest version control system I've ever used." And it also improved my overview over what happens and has happened in the past - I can jump back in for stuff I haven't touched for many years. So I now think of the older version control systems I used over the years as simple "snapshot backup" systems, not real version control. (NB: I've never actively used Mercurial, other than because some projects use it, so I'm not comparing Git and Mercurial, or the other one or two systems with similarities.)
- wazoox 6y ago
  The version control system your subconscious mind recoils in horror from is the dreaded Visual SourceSafe, one of the worst-named product ever.
  - Tor3 6y ago
    That's possibly the one.. I worked for a year on a customer's site, and the source we delivered had to be put into their MS VC every time we delivered it. The major pain was that the namespace was flat.. you couldn't have more than one file in the whole tree called "Makefile" or "ChangeLog", for example.. so we made a transformation tool to make every file name unique before it got pushed into the version control system, and a reverse tool which transformed back when you checked it out, so that one could build the software.
- japgolly 6y ago
  Oh wow, ClearCase. That's a blast from the past that I'd forgotten even existed. CC was the stuff of nightmares.
  - KSteffensen 6y ago
    A blast from the past that some of us still have to use on a daily basis, sadly.
hnlmorg 6y ago
I've used a lot of different version control systems over my many years in the industry and git definitely isn't easy. The basics aren't hard but it's easy to get into a pickle if you need to delve slightly out of common patterns. The git CLI tool isn't great either -- that's probably the hardest part of git.
exDM69 6y ago
Exactly. I like to say that git is a "white box". You need to understand the internals to be able to use it. Contrast this with "black boxes" where you don't have to or even can't understand what's going on. Some would argue that software shouldn't be built that way, but I will respectfully disagree. It's not an end user facing consumer product, it's a tool for professionals. You wouldn't expect anyone to operate a table saw or a milling machine without some understanding of what's inside the machine. I do agree that the git user interface is inconsistent and full of caveats. But as long as you understand it's just a directed acyclic graph of commits, you can dig yourself out of any hole you get into.
- jariel 6y ago
  "You wouldn't expect anyone to operate a table saw" ? Coming from a family of carpenters, I can assure you none of them really know that much at all about the internals of the table saw. Maybe a little bit. The 'black box' analogy is upside down: there are a million artifacts of the computer that you use every day for which you have no understanding. We use encapsulated concepts to be able to leverage much more complexity than we would otherwise. Having to deal with the 'inner workings' of git, is like having to have the instruction set for the chipset your computer is running on handy 'just in case'. Git is very powerful, but very poorly designed from a product perspective, there was no 'strategy' just 'add commands and flags that do this and that'. When products expose considerably more complexity than they need to for most uses cases, it's just bad design. I also have a sneaking suspicion that so many 'git experts' are really just expert within a fairly narrow range of commands/options - because when I start to ask more detailed questions, the answers are never clear. No other product has consistently caused so much confusion, wasted time. Though 95% of my personal interactions are fine, there are just too many times where we have Senior Developers, huddled on someone's machine, trying to solve some arcane problem - this is the 'not very hidden cost' of git. I would say: "Within Git, there is a much smaller and clearer CVS struggling to get out."
  - exDM69 6y ago
    > Coming from a family of carpenters, I can assure you none of them really know that much at all about the internals of the table saw. Maybe a little bit. Every carpenter I know knows how to change the blade, tighten the arbor, check the fence, adjust riving knives, clean away the dust, tension the belts (if applicable) and maybe even change the motor. And there isn't much more to a table saw. Getting back to Git, I agree with your sentiment "Within Git, there is a much smaller and clearer CVS struggling to get out.". Most of us should strive to stay within the set of simple git operations. However, then there's all the other corner cases that are sometimes applicable. Such as clearing away your accidentally published private keys using `git filter-branch`. Most of us will never need this, but it's there for a reason. But if one groks the "DAG of commits" concept behind git, you can understand what filter-branch does and why and how. It's not a very complex concept. Again, I won't defend the inconsistent user interface. It could be better. But even that can be understood when needed by looking at the documentation as long as the concept is clear.
ajuc 6y ago
The underyling concepts are fine, the problem with git for me is the inconsistent command line interface. Stuff I'm doing less often than once a month I have to check in the manual every time. And it's nothing inherently hard - stuff like removing one change from staging or cleaning up local branch to be exactly like remote. The interface just feels like stuff is arbitrarily assigned to different commands :)
- jobigoud 6y ago
  > stuff like removing one change from staging I click on the file and click on "unstage". I don't know why people insist on using the command line for their dvcs. Is it even possible to selectively unstage or reset only a part of a file without a GUI?
  - ajuc 6y ago
    > I don't know why people insist on using the command line for their dvcs. I use both. More complicated stuff I usually do from the command line because I do them rarely enough, and I change IDEs often enough - that I just don't know how to do them in IDEs. I used git regularly for last 6 years and in that time I've been using eclipse, netbeans, kdevelop, qtcreator, visual studio and intelliJ. And a few fringe IDEs as one-offs. I would have to remember 7 different paths in nested context menus for everything. I believe it's not "unstage" but "rollback" in IntelliJ, but I would have to check that in documentation before I do it anyway. > Is it even possible to selectively unstage or reset only a part of a file without a GUI? Sure - it's even faster than in gui, because you do it with keyboard only. I just can't remember the exact options.
    - jobigoud 6y ago
      You don't have to learn 7 IDEs, I've never used git commands in my IDEs. Just use one git client. And you don't have to remember the menus because they are contextual. Select a portion of text: unstage selected lines, reset selected lines, etc. Select a commit: checkout, create tag, revert, etc. Things that are complicated on the CLI become routine and that changes the way you work.
deleted 6y ago
[deleted]
jariel 6y ago
Git is I think objectively more complicated any other popular VCS, simply due to the fact it has much more in the design model. It's also more powerful. But the tradeoff is ugly within the context of the nature of the UI. Git is like C++, it has a lot of features, the UI is not well thought out and it creates countless corner cases. Git was not designed to focus on the core cases, making things simple. Git is one of the great 'litmus tests' for product design thinkers. People who don't understand why git is problematic (even if they are really good at it) I think would have trouble with product design.
- Macha 6y ago
  Git is more popular because Github used Git and Github was better than google code or sourceforge. Bitbucket got like 80% of the way there but was always a few steps behind. Had bitbucket taken off rather than github (which is much more to do with the web UI and network effects than the underlying VCS), we'd all be using hg now.
  - deleted 6y ago
    [deleted]
  - lixtra 6y ago
    I don’t believe this. If you manage to use the git CLI you’re not put off by bad bitbucket UI. My explanation would be: Git won because it was used for Linux and because it was fastest where it mattered.
  - baxtr 6y ago
    Sounds like Betamax vs. VHS!
jasode 6y ago
>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file format of BLOBs and SHAs, etc. If I were to implement a DVCS, I would inevitably end up reinventing many of the same technical architecture decisions that Linus came up with. But none of that insider knowledge really helps me remember git syntax if I haven't been using it in more than a month. Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes https://stackoverflow.com/questions/tagged/git?tab=Votes The git UI and unintuitive syntax is just too hard for me to remember unless I use it every day. Also to add.. the concept of "git index" as a staging area adds some complexity as well. Yes, there are good reasons for it (1) it lets one craft a specific subset instead of all changed files to commit and (2) it's a performance boost because a Big-O type O(n) loop runs faster when iterating through the staging index (small "n" of dozens) to detect changes instead of looping through the entire source code tree (large "n" of 10,000+ files in a big repo). But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". For a newbie, the extra indirection layer of "staging index" seems superfluous and confusing. That's why some present an alternative porcelain to git that doesn't expose the staging concept: e.g. https://gitless.com/ https://gitless.com/ (To clarify, I'm not recommending Gitless but just giving an example of why some felt motivated to simplify Git's porcelain.)
- nicoburns 6y ago
  Totally agree on the "staging area". I've always thought that the staging area should only activate when you `git add` or otherwise add files to it. If there are no staged files, then git commit should act like git commit -A.
  - whizzter 6y ago
    Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only expecting some other part).
megameter 6y ago
It doesn't matter how easy the concept is if the information it contains is not something I can estimate, and in the case of git all the power is coming from indirection, which is famously inestimable stuff. Can I use git like a simpleton? Absolutely. Can I gracefully recover from errors in its application? Nope, it never happens. It's a chainsaw and I ultimately have to solve the problem by using it like one.
ajuc 6y ago
Imagine SQL databases worked exactly like they do now under the hood, but instead of current SELECT/UPDATE/INSERT/DELETE they used like 15 different commands with at least 4 switches each. So instead of SELECT you'd have FETCH, PULL, CHECKOUT, CLONE, READ, PEEK, and OBSERVE. And each of them could in some cases also modify or even delete the data depending on the switches. Imagine there was no division between DML and DDL - you just have to remember which option switches change the schema in addition to doing some other things. And then people would say "SQL is very simple, just learn relational algebra". That's how I feel about git :) With SQL I know for sure I can't break the database by doing a select. I know I can't change schema by doing a DML. With git I'm pretty sure I can't break anything by doing git status, but other than that all bets are off.
- drran 6y ago
  In distributed databases, with support for merges and conflict resolution, we have these commands. :-/
- thrwyoilarticle 6y ago
  Imagine if SQL databases had reflog.
  - tremon 6y ago
    https://en.wikipedia.org/wiki/Temporal_database https://en.wikipedia.org/wiki/Temporal_database
    - yencabulator 6y ago
      You're still imagining a centralized solution with a single source of truth and less power than Git. Git history is a directed acyclic graph, not a single linear timeline.
      - refset 6y ago
        "less power" definitely depends on what you value when comparing Git against real databases, e.g. https://stackoverflow.com/questions/984707/what-are-the-file-limits-in-git-number-and-size https://stackoverflow.com/questions/984707/what-are-the-file... There is at least one database that exists which does support a Git-like DAG for transaction-time temporality: https://terminusdb.com/ https://terminusdb.com/ It should also be pointed out that "temporal databases" usually offer a lot more besides a linear transaction-time history. Although I've not seen anything that offers a DAG for valid-time histories yet :)
3np 6y ago
It's years ago, but I recall as a rookie I found mercurial way more approachable and easy to grok. Still distributed and a similar model to git, but considerably more approachable CLI interface and manpages.
jkoudys 6y ago
Git's hard when you see googling for syntax as a failure in the system. If you see getting SO answers as working as designed, it's quite easy. The main learning curve is just the idea of everything being branched, which is an increasingly common concept in many spaces.
rmtech 6y ago
A lot of people don't truly understand operating systems and yet they manage to use Windows. You are setting a very low bar.
unishark 6y ago
I've always found linear algebra to be far simpler than any other advanced mathematics. It's basically just a lot of book-keeping and consequences from that. Yet I know smart people who failed it multiple times and had to change majors to avoid it. That makes me pause before dismissing people who complain about it. The article has a better way to assess difficulty, based on how easy it is to teach other how to use it.
hakre 6y ago
"Truly understood" is close to a holy church I guess. However it's perhaps really that too many people are thinking they need to use git because their church says so and then have to deal with the self chosen authority.
deleted 6y ago
[deleted]
sumtechguy 6y ago
Having used a few of these version controls over the years each one has its kind of 'core' strength. Most of them evolved next to each other and borrowed the shorthand of each other and copied each others API/GUI/CLI (mostly), and the shorthand of a physical library. git on the other hand stands alone in its interface. in many source controls 'checkout' for example means I get exclusive control of this file on this branch. Where as in git it does not mean that at all. That is where much of the misunderstanding comes in for git. The commands are kind of the same names but do very different things.
simiones 6y ago
I think there are many aspects of Git that are obscure/error-prone regardless of how well you understand its implementation. For example, the concepts of "ours" and "theirs" when looking at changes depends on the current operation mode (rebase vs merge). Merging is unsafe-by-default, because it auto-merges even if both branches have modifications to the same file, and there is no guarantee that the resulting file is correct. There are numerous ways to collaborate on a git repo, with vastly different performance/usability implications, none of which is obvious when you start up (merging remote into local, rebasing local onto remote, squashing local commits; patches vs pushes). Not to mention that, for teams that work with a centralized remote repo, the whole concept of local tracking branches adds mental overhead for nothing, and extra work every time you want to push a change to a remote branch. You have to first pull, even if your changes and the remote ones don't touch the same files. Which of course means that, if you had a dirty worktree, you actually need to run 3 commands - one to stash your changes, one to pull, the actual push, and now an unstash.
ozim 6y ago
Mental model to use SVN for example was quite simplified. No connection to the server no committing - no confusion about local vs remote. Branching only on the server, merging totally useless - no branches, no merging, no conflicts. Want to have your local development versioned - zipfile + date time. I would never go back to that, but from people complains some might want to.
kristopolous 6y ago
Do you really think the .. and ... notations semantic differences between git-log and git-diff are reasonable? I personally think if a..b in git log shows me a set of commits then a..b in git diff should show me the code contained within those commits, the patch files that would generate from them. I guess this is a foolish expectation?
kazinator 6y ago
This sort of developer blindness once you have learned something is why we need user interface people as a whole separate discipline. The "concept" of resetting? "git reset" does different things in one command: there is no one concept. It can discard your staged changes and working tree so that your workspace looks like your head. It can move your head ref while doing that. It can move your head without changing the working tree. It can interactively stage the changes to another commit (e.g. to selectively revert).
justnotworthit 6y ago
You've tried darcs? "patch theory", no branches, simple interface. https://en.wikipedia.org/wiki/Darcs#Model https://en.wikipedia.org/wiki/Darcs#Model http://darcs.net/QuickStart http://darcs.net/QuickStart http://darcs.net/ http://darcs.net/ https://darcsbook.acmelabs.space/ https://darcsbook.acmelabs.space/

by dimgl 6y ago

varispeed 6y ago

People are being told git is complex and then they are confused when it feels easy when they do something. They assume they are doing something wrong.

rusk 6y ago

I’d be inclined to disagree. I found the learning curve to be quite steep. When you’re used to having a centralised VCS hosted for you it can seem a bit of a chore to take on all this extra responsibility. Once you’re on top of it though it’s great I wouldn’t use anything else.

nemetroid 6y ago
> When you’re used to having a centralised VCS hosted for you I think this is the crucial part. Git will come off as difficult and strange if you're used to using a centralized VCS, and expect Git to work like it. But that isn't really indicative of Git's own complexity, just its differentness.
- rusk 6y ago
  But you are free to use Git in the old centralised way. You don’t have to get into workflows and stuff if you don’t want to. The , just as in the purely centralised case you are still reliant on a oracle but that’s okay in most cases.

8draco8 6y ago

The only concept that I can't put into my muscle memory is reverting changes for one file before commit. This is very easy in SVN but for some reason it's not intuitive git (at least for me), why there can't be something like `git revert filename`. Thankfully I have GitKraren that is helping me with things like that.

rusk 6y ago
‘git checkout filename’ is the equivalent of ‘svn revert filename’
- walty8 6y ago
  Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's really not easy to get started.
  - rusk 6y ago
    There are numerous git <-> svn cheat sheets ... this is literally one of the first things I learned. I’m kind of bewildered by this to be honest ... I don’t know how somebody with a technical qualification could have trouble with this ...
    - oblio 6y ago
      We shouldn't need a cheat sheet. We shouldn't need Linus's brain dump to be able to use a tool. The Git UI directly models the Git internal model and that's just bad design. It's a completely leaky abstraction. I can use git all right but the fact that I need about 20 different commands to do my job, 95% of them with extra parameters and almost all of them with names that don't reflect what I want to do from a functional point of view is utterly dumb. Again, functional! not technical! The UI should reflect end user functionality, not internal technical details.
      - rusk 6y ago

knocte 6y ago

I slightly disagree. I think git is simple, but the UX (the way the commands and flags are designed) is really bad so that's why it's perceived as hard.

byte1918 6y ago
It's the case with most UNIX CLI tools and if the author's complaints are true, do we then have to change all UNIX CLI tools? Maybe? The reality is we can't and probably don't need to.

tasubotadas 6y ago

Then you have never used Mercurial.

erik_seaberg 6y ago
“How do I branch in Mercurial?” seems to have four long answers, and maybe a patch queue makes five? https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m...
- tasubotadas 6y ago
  hg branch my_feature Simple.
- viraptor 6y ago
  You could easily write pages about local/remote branches, heads behaviour, etc. in git. Mercurial also gives you an extra option - bookmarks, but you don't have to use them at all. The deeper explanation doesn't mean more complex system.

rjzzleep 6y ago

I don't get that either. There have been people here arguing that svn and mercurial were both easier to use than git. But the moment I could import SVN to git I immediately switched to Git for everything. And Mercurial... I guess it's a matter of preference, but I personally never got the hang of it. And the fact that they had both SVN style continuous IDs AND hashes was deeply confusing to me. The only thing I did find confusing in the beginning was a) the distinction between pull and fetch. b) getting used to the fact that I don't really care about continuous IDs (or hashes for the most part ) and think more about commits relative to where I currently am. In addition to that things such as `git add -p` or `tig` are so much more convenient compared to other VCS CLIs. But even if CLI isn't what you want we're now a couple years beyond having beautiful third party Git GUIs

jkeat 6y ago
If anyone is looking for a git GUI, Fork is great https://git-fork.com/ https://git-fork.com/
- mdpm 6y ago
  Fork is great, I paid for it happily. It's UI makes sense, radiates the right level of information, and you can use the keyboard almost exclusively. Heavily recommended.

ramraj07 6y ago

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use the terminal for cherry picking. The reason I want to stick to the basics is because of one interesting thing I've noticed: a lot of engineers sincerely believe that they are git experts when they are nowhere close. And until I locked down the GitHub repo with admin privileges, that was a dangerous thing. So I'm trying to work a system where no one in a team where not everyone is truly expert at git only uses the basic commandset from git. One thing I can say again to emphasize - git maybe the simplest Vcs you've used, but it's not a simple tool, and its most definitely not intuitive for everyone. If it is for you, that's great, but maybe there's a lesson here about how not everyone's brains are wired the same.

zingermc 6y ago
I've definitely been the victim of my own git hubris. Once, when leaving a job, I decided to copy all of my local WIP branches to the server. I whipped out this fancy --mirror option I had just heard of: git push --mirror $remote Surprise! All branches on the remote repo got wiped. My local refs replaced the refs on the remote. Somehow I found the right commits floating around in the git ether. I was able to recreate the branches, but I had to recreate their names by reading the commit log. Did I mention this happened on my way out the door from a job? In retrospect, I shouldn't have panicked so much -- there were daily backups -- but the sheer terror I felt has made me read the man pages really closely to this day.
- aulin 6y ago
  this definitely shouldn't happen if shared branches are properly protected against non fastforward pushes
  - mannykannot 6y ago
    ...and if you didn't know that, you shouldn't be using git! To be fair, one should always look up options you are unfamiliar with before using - and Stack Exchange is not an authoritative source. --mirror ...Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end... [my emphasis.] On the other hand, if you are on a system where the behavior can be fundamentally altered by multiple configuration options, this will not necessarily help you much. ...This is the default if the configuration option remote.<remote>.mirror is set.

thdrdt 6y ago

Imho Mercurial is much easier than Git. I have seen team members who lost data with Git but never with Mercurial. I still miss Mercurial. Unfortunately most people moved to Git so I also moved to it.

hvidgaard 6y ago
Quite some years ago we switched from git to Mercurial and the amount of VSC mentoring and unfucking the "VCS guys" had do became almost zero. People seriously just got it. Some argued that is was because they had to learn with git, but... since then we've made the switch back to git for other reasons and we've back at wrangling with the tool again. I'd much much rather use Mercurial with Evolve extension - that is really good.
Mindless2112 6y ago
There is work being done[1] to make Mercurial work on git repositories. [1] https://www.mercurial-scm.org/wiki/GitExtension https://www.mercurial-scm.org/wiki/GitExtension
athms 6y ago
>Unfortunately most people moved to Git so I also moved to it. The Lemming Effect.

Tor3 6y ago

Agreed - I started to use version control back with SCCS somewhen in the early nineties, and RCS, CVS, Subversion, ClearCase, some Microsoft horror with a name I can't recall, and a few others. My conclusion is exactly the same as yours: "Git is the simplest version control system I've ever used." And it also improved my overview over what happens and has happened in the past - I can jump back in for stuff I haven't touched for many years. So I now think of the older version control systems I used over the years as simple "snapshot backup" systems, not real version control. (NB: I've never actively used Mercurial, other than because some projects use it, so I'm not comparing Git and Mercurial, or the other one or two systems with similarities.)

wazoox 6y ago
The version control system your subconscious mind recoils in horror from is the dreaded Visual SourceSafe, one of the worst-named product ever.
- Tor3 6y ago
  That's possibly the one.. I worked for a year on a customer's site, and the source we delivered had to be put into their MS VC every time we delivered it. The major pain was that the namespace was flat.. you couldn't have more than one file in the whole tree called "Makefile" or "ChangeLog", for example.. so we made a transformation tool to make every file name unique before it got pushed into the version control system, and a reverse tool which transformed back when you checked it out, so that one could build the software.
japgolly 6y ago
Oh wow, ClearCase. That's a blast from the past that I'd forgotten even existed. CC was the stuff of nightmares.
- KSteffensen 6y ago
  A blast from the past that some of us still have to use on a daily basis, sadly.

hnlmorg 6y ago

I've used a lot of different version control systems over my many years in the industry and git definitely isn't easy. The basics aren't hard but it's easy to get into a pickle if you need to delve slightly out of common patterns. The git CLI tool isn't great either -- that's probably the hardest part of git.

exDM69 6y ago

Exactly. I like to say that git is a "white box". You need to understand the internals to be able to use it. Contrast this with "black boxes" where you don't have to or even can't understand what's going on. Some would argue that software shouldn't be built that way, but I will respectfully disagree. It's not an end user facing consumer product, it's a tool for professionals. You wouldn't expect anyone to operate a table saw or a milling machine without some understanding of what's inside the machine. I do agree that the git user interface is inconsistent and full of caveats. But as long as you understand it's just a directed acyclic graph of commits, you can dig yourself out of any hole you get into.

jariel 6y ago
"You wouldn't expect anyone to operate a table saw" ? Coming from a family of carpenters, I can assure you none of them really know that much at all about the internals of the table saw. Maybe a little bit. The 'black box' analogy is upside down: there are a million artifacts of the computer that you use every day for which you have no understanding. We use encapsulated concepts to be able to leverage much more complexity than we would otherwise. Having to deal with the 'inner workings' of git, is like having to have the instruction set for the chipset your computer is running on handy 'just in case'. Git is very powerful, but very poorly designed from a product perspective, there was no 'strategy' just 'add commands and flags that do this and that'. When products expose considerably more complexity than they need to for most uses cases, it's just bad design. I also have a sneaking suspicion that so many 'git experts' are really just expert within a fairly narrow range of commands/options - because when I start to ask more detailed questions, the answers are never clear. No other product has consistently caused so much confusion, wasted time. Though 95% of my personal interactions are fine, there are just too many times where we have Senior Developers, huddled on someone's machine, trying to solve some arcane problem - this is the 'not very hidden cost' of git. I would say: "Within Git, there is a much smaller and clearer CVS struggling to get out."
- exDM69 6y ago
  > Coming from a family of carpenters, I can assure you none of them really know that much at all about the internals of the table saw. Maybe a little bit. Every carpenter I know knows how to change the blade, tighten the arbor, check the fence, adjust riving knives, clean away the dust, tension the belts (if applicable) and maybe even change the motor. And there isn't much more to a table saw. Getting back to Git, I agree with your sentiment "Within Git, there is a much smaller and clearer CVS struggling to get out.". Most of us should strive to stay within the set of simple git operations. However, then there's all the other corner cases that are sometimes applicable. Such as clearing away your accidentally published private keys using `git filter-branch`. Most of us will never need this, but it's there for a reason. But if one groks the "DAG of commits" concept behind git, you can understand what filter-branch does and why and how. It's not a very complex concept. Again, I won't defend the inconsistent user interface. It could be better. But even that can be understood when needed by looking at the documentation as long as the concept is clear.

ajuc 6y ago

The underyling concepts are fine, the problem with git for me is the inconsistent command line interface. Stuff I'm doing less often than once a month I have to check in the manual every time. And it's nothing inherently hard - stuff like removing one change from staging or cleaning up local branch to be exactly like remote. The interface just feels like stuff is arbitrarily assigned to different commands :)

jobigoud 6y ago
> stuff like removing one change from staging I click on the file and click on "unstage". I don't know why people insist on using the command line for their dvcs. Is it even possible to selectively unstage or reset only a part of a file without a GUI?
- ajuc 6y ago
  > I don't know why people insist on using the command line for their dvcs. I use both. More complicated stuff I usually do from the command line because I do them rarely enough, and I change IDEs often enough - that I just don't know how to do them in IDEs. I used git regularly for last 6 years and in that time I've been using eclipse, netbeans, kdevelop, qtcreator, visual studio and intelliJ. And a few fringe IDEs as one-offs. I would have to remember 7 different paths in nested context menus for everything. I believe it's not "unstage" but "rollback" in IntelliJ, but I would have to check that in documentation before I do it anyway. > Is it even possible to selectively unstage or reset only a part of a file without a GUI? Sure - it's even faster than in gui, because you do it with keyboard only. I just can't remember the exact options.
  - jobigoud 6y ago
    You don't have to learn 7 IDEs, I've never used git commands in my IDEs. Just use one git client. And you don't have to remember the menus because they are contextual. Select a portion of text: unstage selected lines, reset selected lines, etc. Select a commit: checkout, create tag, revert, etc. Things that are complicated on the CLI become routine and that changes the way you work.

deleted 6y ago

[deleted]

jariel 6y ago

Git is I think objectively more complicated any other popular VCS, simply due to the fact it has much more in the design model. It's also more powerful. But the tradeoff is ugly within the context of the nature of the UI. Git is like C++, it has a lot of features, the UI is not well thought out and it creates countless corner cases. Git was not designed to focus on the core cases, making things simple. Git is one of the great 'litmus tests' for product design thinkers. People who don't understand why git is problematic (even if they are really good at it) I think would have trouble with product design.

Macha 6y ago
Git is more popular because Github used Git and Github was better than google code or sourceforge. Bitbucket got like 80% of the way there but was always a few steps behind. Had bitbucket taken off rather than github (which is much more to do with the web UI and network effects than the underlying VCS), we'd all be using hg now.
- deleted 6y ago
  [deleted]
- lixtra 6y ago
  I don’t believe this. If you manage to use the git CLI you’re not put off by bad bitbucket UI. My explanation would be: Git won because it was used for Linux and because it was fastest where it mattered.
- baxtr 6y ago
  Sounds like Betamax vs. VHS!

jasode 6y ago

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file format of BLOBs and SHAs, etc. If I were to implement a DVCS, I would inevitably end up reinventing many of the same technical architecture decisions that Linus came up with. But none of that insider knowledge really helps me remember git syntax if I haven't been using it in more than a month. Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes https://stackoverflow.com/questions/tagged/git?tab=Votes The git UI and unintuitive syntax is just too hard for me to remember unless I use it every day. Also to add.. the concept of "git index" as a staging area adds some complexity as well. Yes, there are good reasons for it (1) it lets one craft a specific subset instead of all changed files to commit and (2) it's a performance boost because a Big-O type O(n) loop runs faster when iterating through the staging index (small "n" of dozens) to detect changes instead of looping through the entire source code tree (large "n" of 10,000+ files in a big repo). But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". For a newbie, the extra indirection layer of "staging index" seems superfluous and confusing. That's why some present an alternative porcelain to git that doesn't expose the staging concept: e.g. https://gitless.com/ https://gitless.com/ (To clarify, I'm not recommending Gitless but just giving an example of why some felt motivated to simplify Git's porcelain.)

nicoburns 6y ago
Totally agree on the "staging area". I've always thought that the staging area should only activate when you `git add` or otherwise add files to it. If there are no staged files, then git commit should act like git commit -A.
- whizzter 6y ago
  Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only expecting some other part).

megameter 6y ago

It doesn't matter how easy the concept is if the information it contains is not something I can estimate, and in the case of git all the power is coming from indirection, which is famously inestimable stuff. Can I use git like a simpleton? Absolutely. Can I gracefully recover from errors in its application? Nope, it never happens. It's a chainsaw and I ultimately have to solve the problem by using it like one.

ajuc 6y ago

Imagine SQL databases worked exactly like they do now under the hood, but instead of current SELECT/UPDATE/INSERT/DELETE they used like 15 different commands with at least 4 switches each. So instead of SELECT you'd have FETCH, PULL, CHECKOUT, CLONE, READ, PEEK, and OBSERVE. And each of them could in some cases also modify or even delete the data depending on the switches. Imagine there was no division between DML and DDL - you just have to remember which option switches change the schema in addition to doing some other things. And then people would say "SQL is very simple, just learn relational algebra". That's how I feel about git :) With SQL I know for sure I can't break the database by doing a select. I know I can't change schema by doing a DML. With git I'm pretty sure I can't break anything by doing git status, but other than that all bets are off.

drran 6y ago
In distributed databases, with support for merges and conflict resolution, we have these commands. :-/
thrwyoilarticle 6y ago
Imagine if SQL databases had reflog.
- tremon 6y ago
  https://en.wikipedia.org/wiki/Temporal_database https://en.wikipedia.org/wiki/Temporal_database
  - yencabulator 6y ago
    You're still imagining a centralized solution with a single source of truth and less power than Git. Git history is a directed acyclic graph, not a single linear timeline.
    - refset 6y ago
      "less power" definitely depends on what you value when comparing Git against real databases, e.g. https://stackoverflow.com/questions/984707/what-are-the-file-limits-in-git-number-and-size https://stackoverflow.com/questions/984707/what-are-the-file... There is at least one database that exists which does support a Git-like DAG for transaction-time temporality: https://terminusdb.com/ https://terminusdb.com/ It should also be pointed out that "temporal databases" usually offer a lot more besides a linear transaction-time history. Although I've not seen anything that offers a DAG for valid-time histories yet :)

3np 6y ago

It's years ago, but I recall as a rookie I found mercurial way more approachable and easy to grok. Still distributed and a similar model to git, but considerably more approachable CLI interface and manpages.

jkoudys 6y ago

Git's hard when you see googling for syntax as a failure in the system. If you see getting SO answers as working as designed, it's quite easy. The main learning curve is just the idea of everything being branched, which is an increasingly common concept in many spaces.

rmtech 6y ago

A lot of people don't truly understand operating systems and yet they manage to use Windows. You are setting a very low bar.

unishark 6y ago

I've always found linear algebra to be far simpler than any other advanced mathematics. It's basically just a lot of book-keeping and consequences from that. Yet I know smart people who failed it multiple times and had to change majors to avoid it. That makes me pause before dismissing people who complain about it. The article has a better way to assess difficulty, based on how easy it is to teach other how to use it.

hakre 6y ago

"Truly understood" is close to a holy church I guess. However it's perhaps really that too many people are thinking they need to use git because their church says so and then have to deal with the self chosen authority.

deleted 6y ago

[deleted]

sumtechguy 6y ago

Having used a few of these version controls over the years each one has its kind of 'core' strength. Most of them evolved next to each other and borrowed the shorthand of each other and copied each others API/GUI/CLI (mostly), and the shorthand of a physical library. git on the other hand stands alone in its interface. in many source controls 'checkout' for example means I get exclusive control of this file on this branch. Where as in git it does not mean that at all. That is where much of the misunderstanding comes in for git. The commands are kind of the same names but do very different things.

simiones 6y ago

I think there are many aspects of Git that are obscure/error-prone regardless of how well you understand its implementation. For example, the concepts of "ours" and "theirs" when looking at changes depends on the current operation mode (rebase vs merge). Merging is unsafe-by-default, because it auto-merges even if both branches have modifications to the same file, and there is no guarantee that the resulting file is correct. There are numerous ways to collaborate on a git repo, with vastly different performance/usability implications, none of which is obvious when you start up (merging remote into local, rebasing local onto remote, squashing local commits; patches vs pushes). Not to mention that, for teams that work with a centralized remote repo, the whole concept of local tracking branches adds mental overhead for nothing, and extra work every time you want to push a change to a remote branch. You have to first pull, even if your changes and the remote ones don't touch the same files. Which of course means that, if you had a dirty worktree, you actually need to run 3 commands - one to stash your changes, one to pull, the actual push, and now an unstash.

ozim 6y ago

Mental model to use SVN for example was quite simplified. No connection to the server no committing - no confusion about local vs remote. Branching only on the server, merging totally useless - no branches, no merging, no conflicts. Want to have your local development versioned - zipfile + date time. I would never go back to that, but from people complains some might want to.

kristopolous 6y ago

Do you really think the .. and ... notations semantic differences between git-log and git-diff are reasonable? I personally think if a..b in git log shows me a set of commits then a..b in git diff should show me the code contained within those commits, the patch files that would generate from them. I guess this is a foolish expectation?

kazinator 6y ago

This sort of developer blindness once you have learned something is why we need user interface people as a whole separate discipline. The "concept" of resetting? "git reset" does different things in one command: there is no one concept. It can discard your staged changes and working tree so that your workspace looks like your head. It can move your head ref while doing that. It can move your head without changing the working tree. It can interactively stage the changes to another commit (e.g. to selectively revert).

justnotworthit 6y ago

You've tried darcs? "patch theory", no branches, simple interface. https://en.wikipedia.org/wiki/Darcs#Model https://en.wikipedia.org/wiki/Darcs#Model http://darcs.net/QuickStart http://darcs.net/QuickStart http://darcs.net/ http://darcs.net/ https://darcsbook.acmelabs.space/ https://darcsbook.acmelabs.space/