7 ms·

It's honestly crazy how much time we as a community of software developers spend thinking about Git. We spend time training new engineers how to use it, we spen

It's honestly crazy how much time we as a community of software developers spend thinking about Git. We spend time training new engineers how to use it, we spend time researching how to un-wedge ourselves when we run into problems, we spend time standardizing preferred workflows and giving feedback when someone doesn't follow them, and we seem to spend time debating the proper branching workflows within each team or company once every couple years. When all those costs are added up, I felt more productive using svn. I can't be the only one. Ultimately I think the problem is that Git solves too many problems - it provides a very general data structure that can be used in a lot of different ways, but the tooling itself is mostly agnostic to how you want to use that data structure. Teams can define preferred workflows on top of that, but the tooling itself doesn't enforce the workflow, or provide any specific affordances that help you properly comply with the workflow. Instead, every developer is supposed to keep the workflow in their head, and make judgement decisions every time they interact with it. The cost of this is huge. We're sorely in need of opinionated tooling that sits above Git's data structures and makes real-world workflows simple to follow correctly, and difficult to mess up.

jaredklewis 7y ago
As with programming languages or anything else, this would come with lots of trade-offs. Whether it is programs like Photoshop and Excel or programming languages like C and JS, general purpose tools have a lot of appeal: learn the once, use it for anything. Of course there is the opposite as well: niche tools that solve a specific problem in an opinionated way, like photo filter apps, Elm, R, etc...They have a lot of appeal too because they are better suited to the task at hand, but have limited use outside their specific domain. But the most popular and widespread tools are always from the former group. R is great, but there are always going to be more python repos on github than R repos. If git was opinionated, it would serve a smaller niche better, but other niches worse, so it wouldn't be the industry standard it is today. For better or worse, I've observed that powerful with footguns is always more popular than more limited options .
cryptonector 7y ago
Eh? Branches and tags are just symbolic names for commits, and commits define the entire content of the filesystem for a codebase at that commit. That's almost all you need to know. Get that down path and you're on your way to being a Git power user. If you can't handle that, then maybe you can't handle programming either. The last thing we need is more opinionated version control tooling. We've tried it (e.g., Mercurial), and it has failed in the market. But if you want opinionated version control tooling, well, there it is for you to use.
honkycat 7y ago
I have had the same thought. It is laborious to use and people struggle with it. 99% of the behavior it implements people do not use. Git is not the correct level of abstraction.
- kohtatsu 7y ago
  Here is an exhaustive (~99.5%) list of the git commands I use: git init git clone git clone --recursive git remote add git checkout git branch git merge --no-ff git add git add -p git rm git reset git commit [-a] [-m] git commit -p git commit --amend git submodule add git push git push -u git pull git log git show git status git update-index --assume-unchanged (aliased to ignore) git update-index --no-assume-unchanged (aliased to unignore) The 1 in 200 is probably a git rebase -i. If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.
  - linuxftw 7y ago
    I always recommend to people to not use 'git pull' as it's probably not what you really want.
    - 3JPLW 7y ago
      What do I want? It sure seems to do exactly what I need in the case where I'm on my local `master` and it's exactly the state of `origin/master` but a day or two behind.
      - linuxftw 7y ago
        What is it you're doing on your local master? It's only going to lead to a mess if you're developing on master locally and trying to do merges from upstream.
        3JPLW 7y ago
        Absolutely no development. I use it as my starting point for feature branches, as well as subsequent rebases and merges on them. And I use it to build and run the current master.
PaulStatezny 7y ago
> It's honestly crazy how much time we as a community of software developers spend thinking about Git. It's funny, I can't remember the last time I had to give serious thought about how to use git. Sure, there's a learning curve. When I was just starting out, I didn't get it all right away. But it's been years since I've thought much about branching strategies and stuff. And I don't get myself into "terrible messes" that take hard thought to get out of. Not saying you're 100% wrong. But it doesn't line up with my experience.
- andrewstuart2 7y ago
  What rings truer to me is that it's crazy how often building a tool or process, etc, eventually turns into people being able to make careers of just that thing because of all the spins and metaprocesses people will throw on top of or into it. Git springs to mind for one, but (capital A) Agile definitely wins the championship.
  - james_s_tayler 7y ago
    Most teams or companies I've worked in have a git guru but it's far from all they do. It's the occasional stop by at that person's every so often for help with something that is outside the absolute basics.
  - projektfu 7y ago
    Sometimes it’s just that by taking enough out, it becomes unclear and complicated. I “taught” eXtreme Programming to two of my own teams by showing them the book. Worked like a charm. I also participated in several “Agile” installs that failed despite training, meetings, demonstrations, etc. All because removing the “customer is in charge and developer is allowed to get the job done as they see fit” component made it complicated.
- kochthesecond 7y ago
  I am with you on this. Its been years since I had an issue with git, and branching strategies are not that hard. In smaller teams most solution that show up are also usable. I would argue git is actually a fantastic tool that gives immense value year after year for no cost compared to any other alternative. There is a learning curve though.
flohofwoe 7y ago
Exactly, that something as trivial and obvious as version control costs so much mental overhead is completely bizarre. Sure, SVN doesn't have as many features as git, and merging sucks, but it offers the most important features of version control (recording "who has done what, when", and undoing changes). Teaching SVN usage to a non-techie takes literally a few minutes (especially with an intuitive UI like TortoiseSVN), and it's very hard to break something.
- james_s_tayler 7y ago
  And that's why everyone still uses SVN and git is this obscure minor player that's relatively unheard of.
  - flohofwoe 7y ago
    Whether it's specifically SVN doesn't matter really, the point is that no other version control system in history required so much mental effort to be "learned" like git. And the worst thing is that new people who don't know anything else than git think that this is normal. What's happening under the hood is mostly fine (mostly, because git completely breaks down with large binary files, and solutions like git lfs don't help much with this problem). What's really bad is the git "frontend", that there's no obvious standard workflow, instead there's a thousand ways to do the same thing. That's great if you have a lot of time for tinkering and meddling with the tools layer, but not when you simply need to get shit done. The version control system should essentially 'disappear' and never require attention.
    - james_s_tayler 7y ago
      I started on SVN. Had a stint using TFS. Eventually wound up in git. I vastly prefer git. We had simpler, easier to operate version control tools. Git traded off some of that simplicity for other benefits the community at large seems to value enough to have migrated away from the simpler tools. I'm skeptical the "git is too complicated for newbies" cry is truly a turning point in tech cycle where we see the folly of our ways and begin to decry the current flavor of the month at the new anti-pattern after enough real-world experience has been accumulated to show us the error of our ways. I think it's just "I don't like the way this makes me feel".
zeofig 7y ago
I think git is pretty good. However there are a lot of random/bad blog posts giving supposedly expert advice about how to use it.
crazypython 7y ago
People need to learn Git. Git has a "click" moment. Git "clicked" for me a few weeks after I began using GitUp, an FOSS Mac app. It visualizes Git, and doing advanced Git is easy from within there, and only committing some lines of code is easy from within it. Visualizing Git is really helpful. A branch is a name that points to a git commit. Every git commit has a parent, so a branch also has all its parents. You have a current commit, known as HEAD, and you have a current branch. Merge is when you make a commit that "fuses" two commits, leaving both in the repository. It is ugly. Rebasing is when you reapply the diverging commits of a branch onto the commits of another branch. You give it a new base." This is important: Branches are names for commits. I have two active branches currently, "floating-plugins" and "master." "floating-plugins" is where I'm working on a plugin system and inter-plugin communication. I made the logging system log a stack trace for warnings. When I did and tested this change, I quickly select the lines of code that bring about this change through a GUI, type in a short message, and commit. Suddenly, I need to implement a feature on "master." As I'm implementing it, I realize I also need the log-stack-trace-on-warn feature in master. So I rebase with floating-plugins, and now, I have that feature on master. In another scenario, I might have had to reorder the commits on floating-plugins so I could safely rebase to just the commits I wanted on master. In yet a different scenario, a cherry-pick might have been appropriate. The unifying theme of all this is that you need to be able to visualize Git. Git won't fix people who do not test in a disciplined way. That's a social problem. Git let's me do a hotfix on a beta testing server while having other code on my current laptop, and then merge the changes together with a rebase.
- jariel 7y ago
  "So I rebase with floating-plugins, and now, I have that feature on master." Didn't you just break the golden rule of Git which is to never rebase onto a public branch?
  - earthboundkid 7y ago
    “Rebase” is a bad name for what should be called “edit history”. Never edit the existing history of master. Always do edit the history of other branches to merge them into master.
geerlingguy 7y ago
Do you remember the hellish experience that was SVN, or CVS?
- projektfu 7y ago
  I liked CVS with continuous integration. It was problematic if you strayed from the trunk for too long. But one of the big reasons for SVN was to handle directories and version them properly.
  - syncsynchalt 7y ago
    Lack of consolidated commit logs is reason enough to condemn CVS. Yes, scripts existed which attempted to simulate one but it's not the same.
    - projektfu 7y ago
      Yes, that was a nice feature of Perforce.
globular-toast 7y ago
Instead of opinionated tooling you can just have an opinionated lead developer who tells his team how to use git. I'm the git expert at my work and my team spend no time thinking about git any more. New starters understand how we use git on the first day and after that we all understand what's going on.
- pantulis 7y ago
  This. Git is a glorious tool, but such tremendous power implies a lot of complexity and a lot of different ways that you can work with it. You can have 10 engineers and find they have 10 different opinions and everything ends in ego fightings. The best way is to have an owner of this, make the team understand the governance issues being resolved with the flow and disagree and commit (pun intended ;)

jaredklewis 7y ago

As with programming languages or anything else, this would come with lots of trade-offs. Whether it is programs like Photoshop and Excel or programming languages like C and JS, general purpose tools have a lot of appeal: learn the once, use it for anything. Of course there is the opposite as well: niche tools that solve a specific problem in an opinionated way, like photo filter apps, Elm, R, etc...They have a lot of appeal too because they are better suited to the task at hand, but have limited use outside their specific domain. But the most popular and widespread tools are always from the former group. R is great, but there are always going to be more python repos on github than R repos. If git was opinionated, it would serve a smaller niche better, but other niches worse, so it wouldn't be the industry standard it is today. For better or worse, I've observed that powerful with footguns is always more popular than more limited options .

cryptonector 7y ago

Eh? Branches and tags are just symbolic names for commits, and commits define the entire content of the filesystem for a codebase at that commit. That's almost all you need to know. Get that down path and you're on your way to being a Git power user. If you can't handle that, then maybe you can't handle programming either. The last thing we need is more opinionated version control tooling. We've tried it (e.g., Mercurial), and it has failed in the market. But if you want opinionated version control tooling, well, there it is for you to use.

honkycat 7y ago

I have had the same thought. It is laborious to use and people struggle with it. 99% of the behavior it implements people do not use. Git is not the correct level of abstraction.

kohtatsu 7y ago
Here is an exhaustive (~99.5%) list of the git commands I use: git init git clone git clone --recursive git remote add git checkout git branch git merge --no-ff git add git add -p git rm git reset git commit [-a] [-m] git commit -p git commit --amend git submodule add git push git push -u git pull git log git show git status git update-index --assume-unchanged (aliased to ignore) git update-index --no-assume-unchanged (aliased to unignore) The 1 in 200 is probably a git rebase -i. If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.
- linuxftw 7y ago
  I always recommend to people to not use 'git pull' as it's probably not what you really want.
  - 3JPLW 7y ago
    What do I want? It sure seems to do exactly what I need in the case where I'm on my local `master` and it's exactly the state of `origin/master` but a day or two behind.
    - linuxftw 7y ago
      What is it you're doing on your local master? It's only going to lead to a mess if you're developing on master locally and trying to do merges from upstream.
      - 3JPLW 7y ago
        Absolutely no development. I use it as my starting point for feature branches, as well as subsequent rebases and merges on them. And I use it to build and run the current master.

PaulStatezny 7y ago

> It's honestly crazy how much time we as a community of software developers spend thinking about Git. It's funny, I can't remember the last time I had to give serious thought about how to use git. Sure, there's a learning curve. When I was just starting out, I didn't get it all right away. But it's been years since I've thought much about branching strategies and stuff. And I don't get myself into "terrible messes" that take hard thought to get out of. Not saying you're 100% wrong. But it doesn't line up with my experience.

andrewstuart2 7y ago
What rings truer to me is that it's crazy how often building a tool or process, etc, eventually turns into people being able to make careers of just that thing because of all the spins and metaprocesses people will throw on top of or into it. Git springs to mind for one, but (capital A) Agile definitely wins the championship.
- james_s_tayler 7y ago
  Most teams or companies I've worked in have a git guru but it's far from all they do. It's the occasional stop by at that person's every so often for help with something that is outside the absolute basics.
- projektfu 7y ago
  Sometimes it’s just that by taking enough out, it becomes unclear and complicated. I “taught” eXtreme Programming to two of my own teams by showing them the book. Worked like a charm. I also participated in several “Agile” installs that failed despite training, meetings, demonstrations, etc. All because removing the “customer is in charge and developer is allowed to get the job done as they see fit” component made it complicated.
kochthesecond 7y ago
I am with you on this. Its been years since I had an issue with git, and branching strategies are not that hard. In smaller teams most solution that show up are also usable. I would argue git is actually a fantastic tool that gives immense value year after year for no cost compared to any other alternative. There is a learning curve though.

flohofwoe 7y ago

Exactly, that something as trivial and obvious as version control costs so much mental overhead is completely bizarre. Sure, SVN doesn't have as many features as git, and merging sucks, but it offers the most important features of version control (recording "who has done what, when", and undoing changes). Teaching SVN usage to a non-techie takes literally a few minutes (especially with an intuitive UI like TortoiseSVN), and it's very hard to break something.

james_s_tayler 7y ago
And that's why everyone still uses SVN and git is this obscure minor player that's relatively unheard of.
- flohofwoe 7y ago
  Whether it's specifically SVN doesn't matter really, the point is that no other version control system in history required so much mental effort to be "learned" like git. And the worst thing is that new people who don't know anything else than git think that this is normal. What's happening under the hood is mostly fine (mostly, because git completely breaks down with large binary files, and solutions like git lfs don't help much with this problem). What's really bad is the git "frontend", that there's no obvious standard workflow, instead there's a thousand ways to do the same thing. That's great if you have a lot of time for tinkering and meddling with the tools layer, but not when you simply need to get shit done. The version control system should essentially 'disappear' and never require attention.
  - james_s_tayler 7y ago
    I started on SVN. Had a stint using TFS. Eventually wound up in git. I vastly prefer git. We had simpler, easier to operate version control tools. Git traded off some of that simplicity for other benefits the community at large seems to value enough to have migrated away from the simpler tools. I'm skeptical the "git is too complicated for newbies" cry is truly a turning point in tech cycle where we see the folly of our ways and begin to decry the current flavor of the month at the new anti-pattern after enough real-world experience has been accumulated to show us the error of our ways. I think it's just "I don't like the way this makes me feel".

zeofig 7y ago

I think git is pretty good. However there are a lot of random/bad blog posts giving supposedly expert advice about how to use it.

crazypython 7y ago

People need to learn Git. Git has a "click" moment. Git "clicked" for me a few weeks after I began using GitUp, an FOSS Mac app. It visualizes Git, and doing advanced Git is easy from within there, and only committing some lines of code is easy from within it. Visualizing Git is really helpful. A branch is a name that points to a git commit. Every git commit has a parent, so a branch also has all its parents. You have a current commit, known as HEAD, and you have a current branch. Merge is when you make a commit that "fuses" two commits, leaving both in the repository. It is ugly. Rebasing is when you reapply the diverging commits of a branch onto the commits of another branch. You give it a new base." This is important: Branches are names for commits. I have two active branches currently, "floating-plugins" and "master." "floating-plugins" is where I'm working on a plugin system and inter-plugin communication. I made the logging system log a stack trace for warnings. When I did and tested this change, I quickly select the lines of code that bring about this change through a GUI, type in a short message, and commit. Suddenly, I need to implement a feature on "master." As I'm implementing it, I realize I also need the log-stack-trace-on-warn feature in master. So I rebase with floating-plugins, and now, I have that feature on master. In another scenario, I might have had to reorder the commits on floating-plugins so I could safely rebase to just the commits I wanted on master. In yet a different scenario, a cherry-pick might have been appropriate. The unifying theme of all this is that you need to be able to visualize Git. Git won't fix people who do not test in a disciplined way. That's a social problem. Git let's me do a hotfix on a beta testing server while having other code on my current laptop, and then merge the changes together with a rebase.

jariel 7y ago
"So I rebase with floating-plugins, and now, I have that feature on master." Didn't you just break the golden rule of Git which is to never rebase onto a public branch?
- earthboundkid 7y ago
  “Rebase” is a bad name for what should be called “edit history”. Never edit the existing history of master. Always do edit the history of other branches to merge them into master.

geerlingguy 7y ago

Do you remember the hellish experience that was SVN, or CVS?

projektfu 7y ago
I liked CVS with continuous integration. It was problematic if you strayed from the trunk for too long. But one of the big reasons for SVN was to handle directories and version them properly.
- syncsynchalt 7y ago
  Lack of consolidated commit logs is reason enough to condemn CVS. Yes, scripts existed which attempted to simulate one but it's not the same.
  - projektfu 7y ago
    Yes, that was a nice feature of Perforce.

globular-toast 7y ago

Instead of opinionated tooling you can just have an opinionated lead developer who tells his team how to use git. I'm the git expert at my work and my team spend no time thinking about git any more. New starters understand how we use git on the first day and after that we all understand what's going on.

pantulis 7y ago
This. Git is a glorious tool, but such tremendous power implies a lot of complexity and a lot of different ways that you can work with it. You can have 10 engineers and find they have 10 different opinions and everything ends in ego fightings. The best way is to have an owner of this, make the team understand the governance issues being resolved with the flow and disagree and commit (pun intended ;)