18 ms·

"Nobody really understands git" is the truest part of that. While hyperbolic, it really has a lot of truth. It's always a bit frustrating when working with a t

"Nobody really understands git" is the truest part of that. While hyperbolic, it really has a lot of truth. It's always a bit frustrating when working with a team because everyone understands a different part of git and has slightly different ideas of how things should be done. I still routinely have to explain to others what a rebase is and others have to routinely explain to me what a blob really is. In a team of the most moderate size, teaching and learning git from each other is a regular task. People say git is simple underneath, and if you just learn its internal model, you can ignore its complex default UI. I disagree. Even just learning its internal model leads to surprises all the time, like the blobs that I keep forgetting why aren't they just called files.

mabbo 9y ago
The day I got over what I feel was the end of the steep part of the learning curve, everything made so much sense. Everything became easy to do. I've never been confused or unsure of what was going on in git since. What git needs is a chair lift up that hill. A way to easily get people there. But I have no idea what that would look like. Lots of people try, few do very well at it.
- sammygutierrez 9y ago
  Git Pro's chapter on git internals does a good job of explaining some of the things going on under the hood. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
- johnfn 9y ago
  The whole point about abstractions is you shouldn't need to understand the internals to use them. If the best defense of git is "once you understand the inner workings, it's so clear" then it is by definition a poor abstraction.
  - andrewflnr 9y ago
    Who said it's supposed to be an abstraction? The point, theoretically, of something like Git is that the actual unvarnished model is clear enough that you don't need an abstraction. The problem IMO is that the commands are kind of random and don't map cleanly to the model.
    - AstralStorm 9y ago
      Indeed, the worst offenders are in my opinion checkout, reset and pull. They mix multiple only slightly related commands in one.
      - simik 9y ago
        There are couple projects that try to tackle this problem by providing an alternative CLI (on top of git's own plumbing), like gitless and g2. Haven't used any of them myself, but would be interested in experience of others.
  - specialist 9y ago
    Leaky abstractions is how we get stuff like ORMs.
    - pritambaral 9y ago
      To be fair, most ORMs poorly implement the "leaky" principle. When implemented well, like with SQLAlchemy, the end result is a much nicer ORM. In fact, one of the things in common among the ORMs that have left a bad taste in my mouth is that they all tried to abstract away SQL without leaking enough of it.
      - specialist 9y ago
        I have a different thesis: Picking the ideal interface to abstract is critically important (and very hard). In the case of ORMs, available solutions abstract the schema (tables, rows, fields), the objects, or use templates. My solution abstracted JDBC/ODBC. The only leak in my abstraction was missing metadata, which I was able to plug (with much effort!). My notions for interfaces, modularity, abstractions are mostly informed by the book "Design Rules: The Power of Modularity". http://a.co/hXOGJq1 http://a.co/hXOGJq1
  - naasking 9y ago
    Any interface means you'll build an mental model of the system you're manipulating. How else could you possibly know what you want to do and what commands to issue? So given a mental model is inevitable, seems reasonable that that model should be the actual model.
    - ethbro 9y ago
      > So given a mental model is inevitable, seems reasonable that that model should be the actual model. I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces.
      - flukus 9y ago
        > I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces. How is sql non-leaky? To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc. To debug and improve them you need to look at the query plan which is the database exposing it's inner workings to you. You have to know about the abstractions an sql server sits on as well. Why is it faster if it's on an SSD instead of an HDD? Why does the data dissapear if it's an in memory DB?
        bch 9y ago
        > To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc No, you don’t. As far as I know, the data is stored in discrete little boxes and indexes are a separate stack of sorted little boxes connected to the main boxes by spaghetti. This is the abstraction, it works, and I don’t need to know about btrees, blocksizes, how locks are implemented, or anything else to grok a database.
        webbles 9y ago
        You clearly are not a DBA.
        flukus 9y ago
  - boudin 9y ago
    I disagree with that. The point of an abstraction is to not having to know the implementation. Understanding the principles used behind will always lead to a much better use of your abstraction
    - AlexCoventry 9y ago
      I'd also say an abstraction could be carrying its weight even if it only reduces the amount you have to think about the implementation details when using it.
- jimmy1 9y ago
  This might sound a little out of touch, but am I the only one who doesn't think git is that hard? It is a collection of named pointers and a directed acyclic graph. The internals aren't really important once you have that concept down.
  - banku_brougham 9y ago
    But what about the deal breaker in the article: a way to follow the decendants of a commit.
    - pdfernhout 9y ago
      Took a few seconds with a search engine on "git descendants of a commit": https://stackoverflow.com/questions/27960605/find-all-the-direct-descendants-of-a-given-commit#27962018 https://stackoverflow.com/questions/27960605/find-all-the-di... That said, I do feel some "porcelain" git commands are poorly named and operate inconsistently -- compared to the plumbing of the acyclic graph concepts which is good but limited.
      - e12e 9y ago
        You mean you didn't just read git's easy-to-follow, well-structured man pages or built-in help? /s Half the time, when I know what I want, I both keep forgetting git flags and sub-commands - and struggle to find them in the man pages. Like the fine: git diff --name-only # i list only the files that are changed. But I'm not --list-files.
        OJFord 9y ago
        Diff lists files without --name-only though, so the flag specifies you want _only_ the filenames of those with a diff.
        e12e 9y ago
        True, but it's inconsistent with eg grep.
- iliaznk 9y ago
  Exactly, it was no longer mysterious for me after I had to prepare a written branching procedure for our team starting from how to branch off, commit, rebase to doing resets and working with reflog. While doing that I've thoroughly read the official docs, examined lots of examples, created a local repo with a couple of text files to test various commands. An then it became so clear and simple! Especially the reflog – so powerful! So, my advice is to try to write some instructions for yourself for all the common cases you might run into during your work. It will not only help you realise what you actually need from git, but also will serve as a good cheat-sheet.
- mikez302 9y ago
  This looks like a good chair lift: http://gitless.com/ http://gitless.com/
- TomK32 9y ago
  Like `git help`? I has everything important grouped nicely and hints you to even more subcommands.
- zwischenzug 9y ago
  I wrote a book that tries to :) https://leanpub.com/learngitthehardway https://leanpub.com/learngitthehardway I start with simple examples and work up from there. It's based on training I've conducted at various companies, and avoids talk of Merkle trees or DAG.
f1notformula1 9y ago
> everyone understands a different part of git and has slightly different ideas of how things should be done This was a big problem that bugged me too, so for every team I've worked with I've created a few scripts for the team's most common version control operations. Most devs, including me, are pretty lazy so they'd all rather run this script than go to Stack Overflow to figure out git arcania. This helps standardize conventions too: Feature branches/linear DAGs/topic branches/dev branches/prod branches/whatever weird thing a team does they all just do that using the script so it's standardized.
amerkhalid 9y ago
I am not a git expert or anything, but I have helped resolve weird git issues for my teammates usually using a lot of Google and StackOverflow. I just know 5 basic commands; pull, push, commit, branch, and merge. Never ran into any issues. People who run into issues are usually editing git log or doing something fancy with “advanced” commands. I have a feeling that these people get into trouble with git cause they issue commands without really knowing what those commands do or even what they want to achieve.
- flatline 9y ago
  Start working in a repo with submodules and you suddenly have to understand a lot more and can get into trouble with no idea how you did it.
  - relics443 9y ago
    I'm comfortable with most advanced git stuff. I don't touch submodules.
    - _pmf_ 9y ago
      > I don't touch submodules. What's the alternative? Managing all dependencies by an external dependency manager does not exactly reduce complexity (if you're not within a closed ecosystem like Java + Maven that has a mature, de-facto standard dependency manager; npm might count, too). It's absolutely not feasible for C++ projects; all projects that do this have horrible hacks upon hacks to fetch and mangle data and usually require gratuitous "make clean"s to untangle.
      - buserror 9y ago
        I use git sub-trees. Actually I love the thing. They give you a 'linear' history, and allow you to merge/pull/push into their original tree, keeping the history (if you require it).
        9y ago
irrational 9y ago
The number 1 reason my team has not moved from Subversion to Git is we can't decide what branching model to use. Use flow, don't use flow, use this model, use that model, no, only a moron would use that model, use this one instead. Rebase, don't rebase, etc. No doubt people will say that it all depends on the project/team/environment/etc., but nobody ever says "If your project/team/environment/etc. look like this, then use this model." So we keep on using Subversion and figure that someday we will run across information that convinces us that it is the one true branching model.
- MsMowz 9y ago
  It really, really doesn't matter. That's one great thing about a distributed SCM.
- whatshisface 9y ago
  Why not replicate whatever you are doing in Subversion in Git? You'll still be able to take advantage of the better merging algorithms, while maintaining whatever political momentum seems to be driving the team's decisions.
- naasking 9y ago
  I have another solution: just switch to mercurial. I switched some big projects to mercurial from svn many years ago. Migration was painless, tooling was similar but better, the interface is simpler than git, and haven't regretted it once.
  - buvanshak 9y ago
    I have converted all my mercurial repos to git and I have forgotten all mercurial now. It helps me feel less pain when I am forced to work in Git....
  - prepend 9y ago
    This is the path I took for a few projects years ago when Google Code didn’t support git. Switched to mercurial from svn and workflow was painless for the team. Interestingly, we slowly started adopting more distributed techniques like developer merges being common. With svn, I think I was the only one who could merge and it would be rare and added product risk. Then after about a year of mercurial we switched to git and our brains had adapted. Our team was small, 5-10 people. Somewhat relatedly, in 2002, I worked in a large team of 75 people or so with a large codebase of a few hundred thousand lines of active dev. It used Rational ClearCase had “big merges” that happened once or twice a release with thousands of files requiring reconciliation. There was a team who did this so it was annoying to dev in, but largely I didn’t care. Company went through layoffs and the team was down to one. He quit, the company couldn’t merge, so couldn’t release new software versions. There was a big crisis so they went to the architects and pulled a few out of dev work. It turns out I was the one who could figure it out and dumb enough to admit it. That sucked. It took a few weeks to sort out and modify our dev process to make merges easy and common. But it was not fun. Upside is we ended up not having any “non-programmer” op/configuration management people since the layed off/quit team were ClearCase users, who didn’t code. Moral- don’t let people know you can do hard, mundane tasks.
specialist 9y ago
“rebase” is just “pull before push”, right? While I have no opinion on git, I can’t abide by all the precious chaotic mutant misuse, like git-flow. I’d happily accept a subset of primitives, if only to disallow bad ideas. Kinda like Git vs SVN, C/C++ vs Java, flamethrower vs peanut butter.
- joesb 9y ago
  "rebase" is not just "pull before push", though. It's pull then rewrite all your personal commits to be based on the latest tip from that pull.
- fulafel 9y ago
  Rebase is a controversial history altering operation and makes it easy to paint yourself into a corner and get weird error messages or wrong results. Its very different from pull/merge.
  - y2kenny 9y ago
    History altering is only controversial on things that are published. There is nothing wrong with reordering, combining or splitting your local commits to give more clarity to what you are doing. Keeping this in mine will give you the freedom to commit frequently. This confusion happens because many popular SCMs historically have the "commit" and "push" operation in a single step. Git keep them separate.
    - fulafel 9y ago
      There is no tracking by git on what is published, so it's easy to make the mistake of rebasing things that are published and shared by others. Then you will have a bad time later when you try to sync with others, possibly days later.
      - y2kenny 9y ago
        Um... git kind of does with remote tracking branches. You can also make it very obvious by your workflow? If you use local feature branches (which you should for juggling between development tasks, etc.), what you are working on vs what's upstreamed should be pretty clear. Sounds like you are not using local branches. Not using local branch is another confusion caused by the perspective of historical/traditional SCMs (people thinking branches are the domain of a centralized server and are outside of their control.)
deleted 9y ago
[deleted]
cup-of-tea 9y ago
Indeed. When the article said "younger developers only know git" I immediately thought, no, they don't know anything. These people don't even know what a DAG is. Git was made for people who know these concepts. I've tried explaining git to people and they just don't understand. They just don't. What's annoying is that git is just expected knowledge these days and having a github account is enough to claim it. There's not a good way to sell the fact that you're a bit more into it than that. I've even said to git "experts" that branches should really be called refs and their eyes glaze over. It's difficult for me to understand what git is in their heads.
- y4mi 9y ago
  Why would you call branches ref's? They don't point to specific files or commits. I know you can target commits through them - which utilizes the ref syntax... But they're still not really referencing anything directly. They're completely arbitrary and are just a feature to improve gits workflow.
  - friend-monoid 9y ago
    But they are also called symbolic refs in git terminology...
    - y4mi 9y ago
      That term makes sense. But just as you wouldn't call a symlink to a zip archive a zip file itself, you also shouldn't call a branch a ref.
      - cup-of-tea 9y ago
        So would you rather say a branch is a commit?
        y4mi 9y ago
        A branch is a pointer or symlink if you will.
sathishvj 9y ago
Is there any really good tutorial on git that teaches the internal model? Ideally, it would illustrate each command and show the before and after of the internal objects.
- busrf 9y ago
  https://learngitbranching.js.org/ https://learngitbranching.js.org/ is the best guide I've seen. It shows you the complete commit graph and all refs on that graph, and updates the graph when you type in commands. It covers and displays workflows involving remotes as well. If you don't want the tutorial, you can go straight to the sandbox here: https://learngitbranching.js.org/?NODEMO https://learngitbranching.js.org/?NODEMO
gaius 9y ago
Git is the solution to the problem of doing distributed development on the Linux kernel. People who aren’t doing that, I wonder if they’re entirely clear in their own minds why they use it. I’m certainly not... other than that it’s just the default choice these days, the path of least resistance...
collyw 9y ago
What I find ironic is that github is massively popular as a central way to use a distributed version control system. The distributed nature only adds to the complexity and I am sure it is only used by a fraction of git users.
- yawaramin 9y ago
  Yes...? What's surprising about using a central repo to collaborate? There needs to be a single source of truth for a coherent project, otherwise you're just going to have chaos. The distributed nature of git led to the simple and secure contribution model of everyone working on their own repos and not needing to give write access to anyone else. This pretty directly led to an explosion of open source software.
emmelaich 9y ago
Nobody understands SVN or CVS either. I discovered this supporting SVN servers for whole bunch of developers.
muxator 9y ago
I always found the mercurial ui super easy. The error messages are clearer, it is multiplatform, all the advanced functionalities are there, a nice graphic interface exists. I really do not understand why git won, apart from github.

mabbo 9y ago

The day I got over what I feel was the end of the steep part of the learning curve, everything made so much sense. Everything became easy to do. I've never been confused or unsure of what was going on in git since. What git needs is a chair lift up that hill. A way to easily get people there. But I have no idea what that would look like. Lots of people try, few do very well at it.

sammygutierrez 9y ago
Git Pro's chapter on git internals does a good job of explaining some of the things going on under the hood. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
johnfn 9y ago
The whole point about abstractions is you shouldn't need to understand the internals to use them. If the best defense of git is "once you understand the inner workings, it's so clear" then it is by definition a poor abstraction.
- andrewflnr 9y ago
  Who said it's supposed to be an abstraction? The point, theoretically, of something like Git is that the actual unvarnished model is clear enough that you don't need an abstraction. The problem IMO is that the commands are kind of random and don't map cleanly to the model.
  - AstralStorm 9y ago
    Indeed, the worst offenders are in my opinion checkout, reset and pull. They mix multiple only slightly related commands in one.
    - simik 9y ago
      There are couple projects that try to tackle this problem by providing an alternative CLI (on top of git's own plumbing), like gitless and g2. Haven't used any of them myself, but would be interested in experience of others.
- specialist 9y ago
  Leaky abstractions is how we get stuff like ORMs.
  - pritambaral 9y ago
    To be fair, most ORMs poorly implement the "leaky" principle. When implemented well, like with SQLAlchemy, the end result is a much nicer ORM. In fact, one of the things in common among the ORMs that have left a bad taste in my mouth is that they all tried to abstract away SQL without leaking enough of it.
    - specialist 9y ago
      I have a different thesis: Picking the ideal interface to abstract is critically important (and very hard). In the case of ORMs, available solutions abstract the schema (tables, rows, fields), the objects, or use templates. My solution abstracted JDBC/ODBC. The only leak in my abstraction was missing metadata, which I was able to plug (with much effort!). My notions for interfaces, modularity, abstractions are mostly informed by the book "Design Rules: The Power of Modularity". http://a.co/hXOGJq1 http://a.co/hXOGJq1
- naasking 9y ago
  Any interface means you'll build an mental model of the system you're manipulating. How else could you possibly know what you want to do and what commands to issue? So given a mental model is inevitable, seems reasonable that that model should be the actual model.
  - ethbro 9y ago
    > So given a mental model is inevitable, seems reasonable that that model should be the actual model. I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces.
    - flukus 9y ago
      > I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces. How is sql non-leaky? To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc. To debug and improve them you need to look at the query plan which is the database exposing it's inner workings to you. You have to know about the abstractions an sql server sits on as well. Why is it faster if it's on an SSD instead of an HDD? Why does the data dissapear if it's an in memory DB?
      - bch 9y ago
        > To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc No, you don’t. As far as I know, the data is stored in discrete little boxes and indexes are a separate stack of sorted little boxes connected to the main boxes by spaghetti. This is the abstraction, it works, and I don’t need to know about btrees, blocksizes, how locks are implemented, or anything else to grok a database.
        webbles 9y ago
        You clearly are not a DBA.
        flukus 9y ago
- boudin 9y ago
  I disagree with that. The point of an abstraction is to not having to know the implementation. Understanding the principles used behind will always lead to a much better use of your abstraction
  - AlexCoventry 9y ago
    I'd also say an abstraction could be carrying its weight even if it only reduces the amount you have to think about the implementation details when using it.
jimmy1 9y ago
This might sound a little out of touch, but am I the only one who doesn't think git is that hard? It is a collection of named pointers and a directed acyclic graph. The internals aren't really important once you have that concept down.
- banku_brougham 9y ago
  But what about the deal breaker in the article: a way to follow the decendants of a commit.
  - pdfernhout 9y ago
    Took a few seconds with a search engine on "git descendants of a commit": https://stackoverflow.com/questions/27960605/find-all-the-direct-descendants-of-a-given-commit#27962018 https://stackoverflow.com/questions/27960605/find-all-the-di... That said, I do feel some "porcelain" git commands are poorly named and operate inconsistently -- compared to the plumbing of the acyclic graph concepts which is good but limited.
    - e12e 9y ago
      You mean you didn't just read git's easy-to-follow, well-structured man pages or built-in help? /s Half the time, when I know what I want, I both keep forgetting git flags and sub-commands - and struggle to find them in the man pages. Like the fine: git diff --name-only # i list only the files that are changed. But I'm not --list-files.
      - OJFord 9y ago
        Diff lists files without --name-only though, so the flag specifies you want _only_ the filenames of those with a diff.
        e12e 9y ago
        True, but it's inconsistent with eg grep.
iliaznk 9y ago
Exactly, it was no longer mysterious for me after I had to prepare a written branching procedure for our team starting from how to branch off, commit, rebase to doing resets and working with reflog. While doing that I've thoroughly read the official docs, examined lots of examples, created a local repo with a couple of text files to test various commands. An then it became so clear and simple! Especially the reflog – so powerful! So, my advice is to try to write some instructions for yourself for all the common cases you might run into during your work. It will not only help you realise what you actually need from git, but also will serve as a good cheat-sheet.
mikez302 9y ago
This looks like a good chair lift: http://gitless.com/ http://gitless.com/
TomK32 9y ago
Like `git help`? I has everything important grouped nicely and hints you to even more subcommands.
zwischenzug 9y ago
I wrote a book that tries to :) https://leanpub.com/learngitthehardway https://leanpub.com/learngitthehardway I start with simple examples and work up from there. It's based on training I've conducted at various companies, and avoids talk of Merkle trees or DAG.

f1notformula1 9y ago

> everyone understands a different part of git and has slightly different ideas of how things should be done This was a big problem that bugged me too, so for every team I've worked with I've created a few scripts for the team's most common version control operations. Most devs, including me, are pretty lazy so they'd all rather run this script than go to Stack Overflow to figure out git arcania. This helps standardize conventions too: Feature branches/linear DAGs/topic branches/dev branches/prod branches/whatever weird thing a team does they all just do that using the script so it's standardized.

amerkhalid 9y ago

I am not a git expert or anything, but I have helped resolve weird git issues for my teammates usually using a lot of Google and StackOverflow. I just know 5 basic commands; pull, push, commit, branch, and merge. Never ran into any issues. People who run into issues are usually editing git log or doing something fancy with “advanced” commands. I have a feeling that these people get into trouble with git cause they issue commands without really knowing what those commands do or even what they want to achieve.

flatline 9y ago
Start working in a repo with submodules and you suddenly have to understand a lot more and can get into trouble with no idea how you did it.
- relics443 9y ago
  I'm comfortable with most advanced git stuff. I don't touch submodules.
  - _pmf_ 9y ago
    > I don't touch submodules. What's the alternative? Managing all dependencies by an external dependency manager does not exactly reduce complexity (if you're not within a closed ecosystem like Java + Maven that has a mature, de-facto standard dependency manager; npm might count, too). It's absolutely not feasible for C++ projects; all projects that do this have horrible hacks upon hacks to fetch and mangle data and usually require gratuitous "make clean"s to untangle.
    - buserror 9y ago
      I use git sub-trees. Actually I love the thing. They give you a 'linear' history, and allow you to merge/pull/push into their original tree, keeping the history (if you require it).
      - 9y ago

irrational 9y ago

The number 1 reason my team has not moved from Subversion to Git is we can't decide what branching model to use. Use flow, don't use flow, use this model, use that model, no, only a moron would use that model, use this one instead. Rebase, don't rebase, etc. No doubt people will say that it all depends on the project/team/environment/etc., but nobody ever says "If your project/team/environment/etc. look like this, then use this model." So we keep on using Subversion and figure that someday we will run across information that convinces us that it is the one true branching model.

MsMowz 9y ago
It really, really doesn't matter. That's one great thing about a distributed SCM.
whatshisface 9y ago
Why not replicate whatever you are doing in Subversion in Git? You'll still be able to take advantage of the better merging algorithms, while maintaining whatever political momentum seems to be driving the team's decisions.
naasking 9y ago
I have another solution: just switch to mercurial. I switched some big projects to mercurial from svn many years ago. Migration was painless, tooling was similar but better, the interface is simpler than git, and haven't regretted it once.
- buvanshak 9y ago
  I have converted all my mercurial repos to git and I have forgotten all mercurial now. It helps me feel less pain when I am forced to work in Git....
- prepend 9y ago
  This is the path I took for a few projects years ago when Google Code didn’t support git. Switched to mercurial from svn and workflow was painless for the team. Interestingly, we slowly started adopting more distributed techniques like developer merges being common. With svn, I think I was the only one who could merge and it would be rare and added product risk. Then after about a year of mercurial we switched to git and our brains had adapted. Our team was small, 5-10 people. Somewhat relatedly, in 2002, I worked in a large team of 75 people or so with a large codebase of a few hundred thousand lines of active dev. It used Rational ClearCase had “big merges” that happened once or twice a release with thousands of files requiring reconciliation. There was a team who did this so it was annoying to dev in, but largely I didn’t care. Company went through layoffs and the team was down to one. He quit, the company couldn’t merge, so couldn’t release new software versions. There was a big crisis so they went to the architects and pulled a few out of dev work. It turns out I was the one who could figure it out and dumb enough to admit it. That sucked. It took a few weeks to sort out and modify our dev process to make merges easy and common. But it was not fun. Upside is we ended up not having any “non-programmer” op/configuration management people since the layed off/quit team were ClearCase users, who didn’t code. Moral- don’t let people know you can do hard, mundane tasks.

specialist 9y ago

“rebase” is just “pull before push”, right? While I have no opinion on git, I can’t abide by all the precious chaotic mutant misuse, like git-flow. I’d happily accept a subset of primitives, if only to disallow bad ideas. Kinda like Git vs SVN, C/C++ vs Java, flamethrower vs peanut butter.

joesb 9y ago
"rebase" is not just "pull before push", though. It's pull then rewrite all your personal commits to be based on the latest tip from that pull.
fulafel 9y ago
Rebase is a controversial history altering operation and makes it easy to paint yourself into a corner and get weird error messages or wrong results. Its very different from pull/merge.
- y2kenny 9y ago
  History altering is only controversial on things that are published. There is nothing wrong with reordering, combining or splitting your local commits to give more clarity to what you are doing. Keeping this in mine will give you the freedom to commit frequently. This confusion happens because many popular SCMs historically have the "commit" and "push" operation in a single step. Git keep them separate.
  - fulafel 9y ago
    There is no tracking by git on what is published, so it's easy to make the mistake of rebasing things that are published and shared by others. Then you will have a bad time later when you try to sync with others, possibly days later.
    - y2kenny 9y ago
      Um... git kind of does with remote tracking branches. You can also make it very obvious by your workflow? If you use local feature branches (which you should for juggling between development tasks, etc.), what you are working on vs what's upstreamed should be pretty clear. Sounds like you are not using local branches. Not using local branch is another confusion caused by the perspective of historical/traditional SCMs (people thinking branches are the domain of a centralized server and are outside of their control.)

deleted 9y ago

[deleted]

cup-of-tea 9y ago

Indeed. When the article said "younger developers only know git" I immediately thought, no, they don't know anything. These people don't even know what a DAG is. Git was made for people who know these concepts. I've tried explaining git to people and they just don't understand. They just don't. What's annoying is that git is just expected knowledge these days and having a github account is enough to claim it. There's not a good way to sell the fact that you're a bit more into it than that. I've even said to git "experts" that branches should really be called refs and their eyes glaze over. It's difficult for me to understand what git is in their heads.

y4mi 9y ago
Why would you call branches ref's? They don't point to specific files or commits. I know you can target commits through them - which utilizes the ref syntax... But they're still not really referencing anything directly. They're completely arbitrary and are just a feature to improve gits workflow.
- friend-monoid 9y ago
  But they are also called symbolic refs in git terminology...
  - y4mi 9y ago
    That term makes sense. But just as you wouldn't call a symlink to a zip archive a zip file itself, you also shouldn't call a branch a ref.
    - cup-of-tea 9y ago
      So would you rather say a branch is a commit?
      - y4mi 9y ago
        A branch is a pointer or symlink if you will.

sathishvj 9y ago

Is there any really good tutorial on git that teaches the internal model? Ideally, it would illustrate each command and show the before and after of the internal objects.

busrf 9y ago
https://learngitbranching.js.org/ https://learngitbranching.js.org/ is the best guide I've seen. It shows you the complete commit graph and all refs on that graph, and updates the graph when you type in commands. It covers and displays workflows involving remotes as well. If you don't want the tutorial, you can go straight to the sandbox here: https://learngitbranching.js.org/?NODEMO https://learngitbranching.js.org/?NODEMO

gaius 9y ago

Git is the solution to the problem of doing distributed development on the Linux kernel. People who aren’t doing that, I wonder if they’re entirely clear in their own minds why they use it. I’m certainly not... other than that it’s just the default choice these days, the path of least resistance...

collyw 9y ago

What I find ironic is that github is massively popular as a central way to use a distributed version control system. The distributed nature only adds to the complexity and I am sure it is only used by a fraction of git users.

yawaramin 9y ago
Yes...? What's surprising about using a central repo to collaborate? There needs to be a single source of truth for a coherent project, otherwise you're just going to have chaos. The distributed nature of git led to the simple and secure contribution model of everyone working on their own repos and not needing to give write access to anyone else. This pretty directly led to an explosion of open source software.

emmelaich 9y ago

Nobody understands SVN or CVS either. I discovered this supporting SVN servers for whole bunch of developers.

muxator 9y ago

I always found the mercurial ui super easy. The error messages are clearer, it is multiplatform, all the advanced functionalities are there, a nice graphic interface exists. I really do not understand why git won, apart from github.