Why is Git so complicated?
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
I did not enjoy git one bit, in the beginning. Today I would kill you if you took it away. You will fail if you try to use it with the "same old" mindset. So a lot of old concepts and habits will have to die. Local branches for instance are no big deal. You create a local branch in a nanosecond. In CVS/SVN I never did it because it took forever. When working on a feature, that usually was one big commit. Today I typically create a branch for a feature or a bug fix. I commit once or twice to my local branch, publish if for review. We use github for review but there are many tools. People suggest improvements. I do the improvements. And then, after old and new unit tests have passed, I can merge. The nice thing, for me, with a branch for a feature, even a partial feature, is the review process. Everything on master has been well vetted. Another thing with a local branch is that if it is a bigger feature, of lets say a dozen commits, it is a nice way of saving and keeping track of my own work. Also if I push my branch, I have a backup and do not have to worry about my hard disk. Another thing, I always used a graphical plugin for SVN operations. With git I always use the command line, except for looking at diffs
... such stuff as dreams are made on
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
E.g. the screenshot here: [Git: Using topic branches and interactive rebasing effectively | Mozilla Web Development](https://blog.mozilla.org/webdev/2011/11/21/git-using-topic-branches-and-interactive-rebasing-effectively/)
... such stuff as dreams are made on
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
AndyStephens wrote:
compared with the likes of TFS or SVN
Here the mistake : you are comparing apples and bananas. Distributed version control is a different concept from centralized version control. Of course, DVC can also be set up and used as CVC, but that's not the primary goal, and could even end up to be counter-productive, sort of what you are experiencing right now. I also have to fight the "Git is the new Svn" mentality in my company ; git is not meant to be an upgrade of SVN or TCS. If you are looking for something to read, I recommend Eric Sink's approach of source control, you can check his website here[^]. The distributed concept is briefly, but sufficiently explained to get the idea.
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
I REALLY don't like Git. Subversion is much better in my opinion. :doh: But to be honest, I prefer REAL version control[^]! :rolleyes:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain -
I REALLY don't like Git. Subversion is much better in my opinion. :doh: But to be honest, I prefer REAL version control[^]! :rolleyes:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark TwainHow did you access my company servers? I'm kidding, we don't use folders... we use zip files
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
Because Linus Torvalds created it? ;)
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
It's not so much that git is complicated, it's that Microsoft have a knack for making things simple and intuitive. It's like going from Entity Framework to nHibernate, or any other similar examples. Of course people will get their fanboy hats on and try to defend or justify the complexity. The thing that annoys me most with git is having to google how to do things that really should be able to do with intuition alone, like google how to discard your working copy and get it back to the remote version and you'll find a hundred threads on SO, all with different archaic commands to type in various combinations, and every command has someone relying saying "don't do it like that".
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
These are the most used git commands that I use (using TortoiseGIT): push, pull, commit, merge, check-out, create branch. Once you know them well, there's no need to learn all others.
I'd rather be phishing!
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
All you ever need to know about GIT[^] Although, coming from TFS to GIT, as I did many moons ago, the Atlassian GIT tutorial was worth its weight in gold - really good and simple to follow Local branches are great - just remember to rebase regularly so they don't get stale (rebase essentially crops your commits out of your branch, then puts any commits from the source branch into is, then puts your commits back on top of the updates....means you don't have huge merge problems when you integrate back into source)
C# has already designed away most of the tedium of C++.
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
It's not intuitive, but not all that complicated. It's a different mindset. For me, the best thing about Git is that it is a more "universal" system. It may be a little weaker in some ways at working with source code, but I can version anything with git. I put design docs, models, etc. in my project and it handles them just fine. With extensions like GitHub, I do collaborative design through pull requests.
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
I used TortoiseSVN before moving to git. It's weird and a bit nonsensical at first but it has reasons. Basically everything revolves around branching and merging[^]. Once those make sense everything else starts to fall into place. Another[^] good article that might help. Patch branching to resolve conflicts will inevitably be useful to you at some point :thumbsup: EDIT: To answer your question: The main reason you branch every new feature is to allow flexibility. For example, say you're coding a new feature. You get a call, "OMG, YOU NEED TO HOTFIX THIS PRODUCTION BUG ASAP, THINGS ARE BLOWING UP!!!" You can easily branch a hotfix, test it, and merge it to production. Your feature branch has had no impact on production yet. Now you go back to your feature branch, finish it, test it, then merge it into production. Easy. And yes, the hotfix is still there because git uses a 3-way merge (source, destination, ancestor). As long as the code the hotfix changed wasn't also changed in your feature branch, you won't have any issues. If it was you can use the patch branching technique to choose which code to keep.
-
As a long-time user of TFS I decided to see what all the fuss was about with Git, so I've been having a play over the last couple of days. I'm using VS2017 and its built-in Git/Team Explorer by the way. All I can say is: come back TFS all is forgiven, and pray that MS have no plans to ditch it in favour of Git. While Git may be fine for those who have never used a VCS before, and don't know any better, compared with the likes of TFS or SVN, Git is a great lumbering, over-complicated, pedantic, jump-through-hoops mound of a system. An aid to productivity it ain't. [It seems I'm not alone in these opinions either]. My main gripe is the additional "tiers", particularly the local repository (and the "index", although I have still yet to get my head around that one). It feels like I can't do anything without first committing to the local repo, whether it's switching to a different branch, comparing files, merging branches, etc. It just seems to be an unnecessary extra step, and if you forget to commit before (say) switching to a different branch then I can imagine a whole world of pain erupting. Comparing a local file with what's on the server isn't straightforward either. It appears that I must first do a "fetch" in order to access the server-based history in order to compare with my local copy (even this is convoluted, but MS takes some of the blame on this one for their clunky UI). Performing any action in Git feels like it involves at least three steps. Admittedly I don't really "get" the idea of local branches. I believe many devs create a branch for each feature or bug fix, but I don't understand why (if someone could enlighten me). It just seems to be something else to have to keep track of where you are, and to potentially go wrong. I don't think our organisation will be moving away from TFS any time soon - there would be mutiny in the office. Rant over.
I've gone through the same hassle, moving from SVN to Git. Now I really wouldn't want to go back! Branching and merging in Git is so much easier and faster. Everything is local, which means you can mess around, create some branches, do your thing, before finally merging and sending it back to the server. You just have to flip a mental switch. Don't think of Git as a different SVN, think of it as something completely different with the same goal of collaborating and keeping a code history. One tip, don't use Git using Visual Studio. I use SourceTree instead and it makes working with Git a whole lot easier. VS is somehow missing some basic Git functionality...
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
It's not so much that git is complicated, it's that Microsoft have a knack for making things simple and intuitive. It's like going from Entity Framework to nHibernate, or any other similar examples. Of course people will get their fanboy hats on and try to defend or justify the complexity. The thing that annoys me most with git is having to google how to do things that really should be able to do with intuition alone, like google how to discard your working copy and get it back to the remote version and you'll find a hundred threads on SO, all with different archaic commands to type in various combinations, and every command has someone relying saying "don't do it like that".
F-ES Sitecore wrote:
It's not so much that git is complicated, it's that Microsoft have a knack for making things simple and intuitive
:wtf: Oh, how I'd love to say just how much you're wrong here. Unfortunately I can't. The more I look on the other side of the fence, the worse it looks.
