11 ms·

Git is one of those once-a-decade technologies that's compicated, user un-friendly, takes months to master and is absolutely worth it.

mixmastamyk 7y ago
Why is it worth it? I've been happier with other vcs.
- bransonf 7y ago
  Curious, what do you currently use for version control?
  - coryrc 7y ago
    I'm not that poster, but Mercurial is just as powerful and much easier to use.
    - Pinckney 7y ago
      That's what everyone says, but for me, coming from a rebase heavy git workflow, I've found Mercurial far more difficult to learn. For example, with Mercurial, there's at least four different ways to do a rebase-ish thing: transplant, graft, rebase, and rebase (w/ evolve enabled). It's not obvious which a newbie should pick (rebase+evolve... I think?). Likewise, Mercurial has purge and strip which both delete commits in different ways. Git has multiple ways to do the same thing, but at least it's simple and consistent when you lift the hood. Undoing any sort of rebase-ish operation in Mercurial also seems difficult and janky. It seems to take multiple steps, and involves unbundling some sort of patch file stored underneath your home directory. Whereas in git, you just update a pointer: `git reset --hard $BRANCH@{1}`. Git's reflog is such a fantastic safety net. Doing any sort of history rewriting in Mercurial feels very dangerous, in comparison.
      - quleap 7y ago
        You surely don't know much about Mercurial. "purge" has NOTHING to do with commits. "purge" only removes file not tracked by Mercurial. "graft" replaced "transplant". "graft" copies commits while "rebase" moves commits. These commands all have very clear purposes, unlike those in Git. It's just that you haven't really bothered to spend a few minutes on learning them.
        pjtr 7y ago
        purge is a third-party extension; it removes untracked files as you wrote. But ~purge~ prune is also a command of the evolve extension, that is conceptually similar to strip, as GP wrote.
        quleap 7y ago
        evolve doesn't have a purge command. It has a prune command. purge is not a third party extension. It is distributed along with Mercurial.
        pjtr 7y ago
        You are correct, thanks.
        deleted 7y ago
        [deleted]
      - mixmastamyk 7y ago
        I don’t do any of the things you describe.
      - pjtr 7y ago
        Fortunately "transplant" is just an old extension, so you can just forget entirely about it. "Graft" copies; "Rebase" moves. Alternatively just forget about graft also, and use "rebase --keep" to copy. "Rebase with evolve" is conceptually still rebase. Mercurial has strip (removes changesets from repository, by default stores a backup). Mercurial does not have purge. Evolve has ~purge~ prune (marks changesets as obsolete). Evolve is similar to a git reflog. Evolve stores more contextual information than the reflog, so Mercurial+Evolve it is safer and easier to undo things than in Git+reflog. Mercurial also pushes some of this contextual information, so even collaborative history rewriting is possible in a safe and easy way, unlike git.
finolex1 7y ago
It only takes a couple of hours to start being productive while using it though. All the commands you need to know are add, commit, push, pull, branch and checkout. Perhaps add log and reset to that list if you make errors.
karmakaze 7y ago
Git shouldn't take months to master if you can understand it conceptually rather than by use-cases. If instead of trying to learn commands to affect the working directory, staged files, or history, you learn how git organizes historical tree of commit hashes, then base what each operation does, it becomes much clearer. It's similar to trying to learn strings of shell pipe commands to get things done rather than realizing that there's pieces of work that each command can do. One tip is to use (even very temporary) branches rather than `stash`es unless it's absolutely short lived. And if you ever get lost, `reflog` is your friend. For me, I had trouble first using `git` after experience with `cvs` and `subversion`. At some point, everything clicked because I inferred its internal model.
- DaiPlusPlus 7y ago
  git’s problem to newcomers - even people without any prior experience with diff-paradigm systems like SVN and TFS - is the idea of a commit representing a snapshot of a file system is difficult to comprehend because it feels so crazy and impractical (especially as CS101 makes a huge deal about computational complexity). The fact that git internally is actually quite efficient is buried in heavy articles about git’s plumbing. Oh, and the fact that a ‘git checkout’ is an unrelated concept to ‘svn checkout’ - and how SVN branches are “spatial” compared to git’s “parallel-universes” model is also a source of confusion. If I could go back in time to 2005 (in addition to getting in super early on bitcoin) I’d beg Linus to not reuse SVN terminology. Personally I’d go with “git switch” instead of checkout, and “timeline” or “line” for short instead of “branch”. The fact that git branches are not 1-connected graph routes is enough reason not to call them “branches”. I’d also convince him to include a “gitd” mode that would automatically fetch from upstream and automatically add commits when it detects file-move/rename changes. (I understand why git doesn’t have an exact “rename” op, but tooling today still isn’t good enough to detect rename-then-edit or rename-then-split operations without an intermediate rename-only commit. My dream “gitd” would also make auto-commits every 30 seconds just to give me a powerful filesystem undo feature. If you had hours of work that resulted in new files before you staged them and you accidentally did a hard reset then you’re sol - and this has happened to me already :/
  - 7y ago

mixmastamyk 7y ago

Why is it worth it? I've been happier with other vcs.

bransonf 7y ago
Curious, what do you currently use for version control?
- coryrc 7y ago
  I'm not that poster, but Mercurial is just as powerful and much easier to use.
  - Pinckney 7y ago
    That's what everyone says, but for me, coming from a rebase heavy git workflow, I've found Mercurial far more difficult to learn. For example, with Mercurial, there's at least four different ways to do a rebase-ish thing: transplant, graft, rebase, and rebase (w/ evolve enabled). It's not obvious which a newbie should pick (rebase+evolve... I think?). Likewise, Mercurial has purge and strip which both delete commits in different ways. Git has multiple ways to do the same thing, but at least it's simple and consistent when you lift the hood. Undoing any sort of rebase-ish operation in Mercurial also seems difficult and janky. It seems to take multiple steps, and involves unbundling some sort of patch file stored underneath your home directory. Whereas in git, you just update a pointer: `git reset --hard $BRANCH@{1}`. Git's reflog is such a fantastic safety net. Doing any sort of history rewriting in Mercurial feels very dangerous, in comparison.
    - quleap 7y ago
      You surely don't know much about Mercurial. "purge" has NOTHING to do with commits. "purge" only removes file not tracked by Mercurial. "graft" replaced "transplant". "graft" copies commits while "rebase" moves commits. These commands all have very clear purposes, unlike those in Git. It's just that you haven't really bothered to spend a few minutes on learning them.
      - pjtr 7y ago
        purge is a third-party extension; it removes untracked files as you wrote. But ~purge~ prune is also a command of the evolve extension, that is conceptually similar to strip, as GP wrote.
        quleap 7y ago
        evolve doesn't have a purge command. It has a prune command. purge is not a third party extension. It is distributed along with Mercurial.
        pjtr 7y ago
        You are correct, thanks.
      - deleted 7y ago
        [deleted]
    - mixmastamyk 7y ago
      I don’t do any of the things you describe.
    - pjtr 7y ago
      Fortunately "transplant" is just an old extension, so you can just forget entirely about it. "Graft" copies; "Rebase" moves. Alternatively just forget about graft also, and use "rebase --keep" to copy. "Rebase with evolve" is conceptually still rebase. Mercurial has strip (removes changesets from repository, by default stores a backup). Mercurial does not have purge. Evolve has ~purge~ prune (marks changesets as obsolete). Evolve is similar to a git reflog. Evolve stores more contextual information than the reflog, so Mercurial+Evolve it is safer and easier to undo things than in Git+reflog. Mercurial also pushes some of this contextual information, so even collaborative history rewriting is possible in a safe and easy way, unlike git.

finolex1 7y ago

It only takes a couple of hours to start being productive while using it though. All the commands you need to know are add, commit, push, pull, branch and checkout. Perhaps add log and reset to that list if you make errors.

karmakaze 7y ago

Git shouldn't take months to master if you can understand it conceptually rather than by use-cases. If instead of trying to learn commands to affect the working directory, staged files, or history, you learn how git organizes historical tree of commit hashes, then base what each operation does, it becomes much clearer. It's similar to trying to learn strings of shell pipe commands to get things done rather than realizing that there's pieces of work that each command can do. One tip is to use (even very temporary) branches rather than `stash`es unless it's absolutely short lived. And if you ever get lost, `reflog` is your friend. For me, I had trouble first using `git` after experience with `cvs` and `subversion`. At some point, everything clicked because I inferred its internal model.

DaiPlusPlus 7y ago
git’s problem to newcomers - even people without any prior experience with diff-paradigm systems like SVN and TFS - is the idea of a commit representing a snapshot of a file system is difficult to comprehend because it feels so crazy and impractical (especially as CS101 makes a huge deal about computational complexity). The fact that git internally is actually quite efficient is buried in heavy articles about git’s plumbing. Oh, and the fact that a ‘git checkout’ is an unrelated concept to ‘svn checkout’ - and how SVN branches are “spatial” compared to git’s “parallel-universes” model is also a source of confusion. If I could go back in time to 2005 (in addition to getting in super early on bitcoin) I’d beg Linus to not reuse SVN terminology. Personally I’d go with “git switch” instead of checkout, and “timeline” or “line” for short instead of “branch”. The fact that git branches are not 1-connected graph routes is enough reason not to call them “branches”. I’d also convince him to include a “gitd” mode that would automatically fetch from upstream and automatically add commits when it detects file-move/rename changes. (I understand why git doesn’t have an exact “rename” op, but tooling today still isn’t good enough to detect rename-then-edit or rename-then-split operations without an intermediate rename-only commit. My dream “gitd” would also make auto-commits every 30 seconds just to give me a powerful filesystem undo feature. If you had hours of work that resulted in new files before you staged them and you accidentally did a hard reset then you’re sol - and this has happened to me already :/
- 7y ago