Rant - I hate GIT
-
This is one of the most pathetically complex things I've ever had to work with. It CONSTANTLY gets in the way of actually getting work done - I spend more time f***ing around with pushes and adds and branches and checkouts that I do actually making code changes!!! What a P.O.S. This diagram[^] near the bottom of the post says it all. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#I strongly disagree with you guys. I have working with Git and SVN for quite a while - in different environments and at different companies, and I prefer Git to SVN. At the end of the day - I found that Git is much stronger and you are able to do so much more with it that thing SVN. Yes sure to get to all the nice interesting stuff it takes some understanding - but if you think about it development is the same. If you think you will become a developer with only a bit of understanding of general concepts you are wrong. <-- this is especially to all the Graphic Designer who this that they are developers thanks to WordPress and Drupal :mad: Git is not all that complex and the features (pros) out way the learning curve (cons) I would say. I am not saying that there is something wrong with SVN or that Git is better - it different and its all dependent on what you want to do, and how much you are willing to learn. :doh: This is quite a good blog regarding Git and SVN:[why is git better than subversion]<-- don't judge the blog by the title In the defense of git:[10 things i love about git]
"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live."
-
I'd have to agree though. I prefer Subversion. Once you get a handle on it, it's incredibly simple to use.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Generally I don't need more than a pull to get the code, then commit and push to submit it. I've had a few projects with branches, but I wasn't switching frequently. Maybe I just haven't worked in a large enough project. I'm not sure where my scripts are at the moment though, I fear they may be on my now dead laptop, because that's where I've done most of my Git based work from, but most of them were either just a series of commands I performed routinely (e.g. go to root of git repo, commit all changes, push) with some parameters for branch names, comments, etc. Nothing extremely complicated. I only had a few more complex ones, like one that went back and branched a project I had gotten way ahead on for a class at each commit with a message containing a chapter number (fortunately, I was basically using a template for my commit messages) so I could just checkout the code for that chapter and submit it for grading, and a second to merge back some file adds when I realized I had forgot to add some files to some of the earlier commits rendering many of the older branches uncompilable, but those were one-time scripts that were faster to write than to do manually 20+ times. The second one could probably be modified into a decent merge script if I could find it.
Marc Clifton wrote:
I really have no patience for listening to how "it's my workflow."
I probably could have worded that a bit better, I don't necessarily mean your personal workflow, but also the workflow that's been imposed upon you (similar to the reason why I can't make commits when I would prefer). I don't find myself changing branches often, but our VCS is so messed up that I have to keep a separate local workspace for each branch because switching between them somehow renders the workspace un-buildable, and even simple tasks like merging a change to another branch becomes a real pain. If I had to work in an environment where I was frequently branching and merging on this system I feel that I'd be in the same position, but not at the fault of the VCS system, the problem would be the poorly managed repository (to be honest, no one actually knows how to make it build, everyone just copies a working copy from someone else, checking it out from the repo doesn't work and no one has ever bother to figure out why and fix it...I suspect the reason is buried somewhere in the thousands of build errors that are just ignored).
WHS!
-
This is one of the most pathetically complex things I've ever had to work with. It CONSTANTLY gets in the way of actually getting work done - I spend more time f***ing around with pushes and adds and branches and checkouts that I do actually making code changes!!! What a P.O.S. This diagram[^] near the bottom of the post says it all. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#The problem with Git is that Linus has been quoted in saying something along the lines of "Git isn't a tool [solution], it's a framework." This lead me to believe that you should really have a few scripts set up that do the heavy-lifting for you. SVN is a tool, it does what it is designed for and nothing more: by using SVN you subscribe the workflow imposed by the SVN developers and have no versatility, where Git can be jimmied into basically any workflow. GitHub for Windows also gets rid of a lot of the pain (really, one-click pushing and pulling) - and it isn't only for GitHub repositories[^]. In a similar light, Microsoft have released the GitHub integration for Visual Studio and I assume it will be of the same caliber (read: simplicity) as TFS. I only drop to the CLI when I really need to these days, and haven't needed to in a couple of months: the Windows tooling is great for it, if you know it's there.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
This is one of the most pathetically complex things I've ever had to work with. It CONSTANTLY gets in the way of actually getting work done - I spend more time f***ing around with pushes and adds and branches and checkouts that I do actually making code changes!!! What a P.O.S. This diagram[^] near the bottom of the post says it all. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#The biggest potential problem with version control is when people don't use it frequently. People won't use frequently what isn't easy to understand and use. For that reason, if for no other, Subversion >> GIT. If you're working on your own, or within a team where every single member understands how and loves to use GIT, then all the power to you. But if you have only one member in your team that isn't comfortable with it, you're going to have problems, sooner or later.
-
Sounds more like your workflow is the problem to me. I tend to script any repeated tasks with more than a couple steps, so my workflow generally becomes: get latest code -> make changes -> run script to make commits, pushes, etc. which is basically the same as using anything else. Personally, I wish we used Git or Mercurial here, because our commit process strongly discourages putting partially complete things in the repository, and I'd like to have some of the benefits of version control (especially revert) when I'm working on something larger that has be made as one commit to the repository. I wonder if there's a way to set up Git locally to push to CVS...
There are Git/Mercurial to SVN bridge tools; you could run one of hte former locally and just push your changes to SVN once you have it finished.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Rutvik Dave wrote:
Mercurial was very good,
Never used it, but that's what I've heard too. Then again, that's what I heard about Git. :( Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#Marc Clifton wrote:
Rutvik Dave wrote:
Mercurial was very good,
Never used it, but that's what I've heard too. Then again, that's what I heard about Git. :(
I've used Mercurial for a few personal projects and never had any problems. Before starting I read a bunch of Git vs Hg posts and when the two differed found myself in near universal agreement that Hg worked the way I'd expect it to and Git was designed by a bunch of gits. :-\
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
This is one of the most pathetically complex things I've ever had to work with. It CONSTANTLY gets in the way of actually getting work done - I spend more time f***ing around with pushes and adds and branches and checkouts that I do actually making code changes!!! What a P.O.S. This diagram[^] near the bottom of the post says it all. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#So I'm not alone - thanks for making me feel better about that! Overall I find most source control a pain (and worry), when they should make life easier. Maybe it's a lack of trust on my part, but I still do a time stamped batch file backup of the source irrespective of using a source control (not GIT!) As for GIT, I just find it too complicated - which means it has a low trust rating in my book, if you can't easily understand a system how can you trust it? As one of our engineers said it must have been named after the characteristics of one (or all) of its designers!
-
Nagy Vilmos wrote:
In my case, no, because it's a Ruby on Rails app, and I'm using RubyMine as the editor (pretty slick product) but it's figuring out RM's support of Git without first understanding how to use Git from the command line is not a good idea. Once I get the command line stuff under my belt, then I can poke around RM's GUI support and see what it's doing (it has a nice display of what it's telling Git to do.) Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#You're probably already aware, but justin case: Ruby on Rails vulnerability[^]
-
You're probably already aware, but justin case: Ruby on Rails vulnerability[^]
Rob Grainger wrote:
Yes, thank you. I think CP's Insider News posted about this a couple weeks ago. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
WHS!
-
This is one of the most pathetically complex things I've ever had to work with. It CONSTANTLY gets in the way of actually getting work done - I spend more time f***ing around with pushes and adds and branches and checkouts that I do actually making code changes!!! What a P.O.S. This diagram[^] near the bottom of the post says it all. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#Source Control? We don't need stinkin' source control... ;P Seriously, it's my understanding that git is meant to manage multiple branches easily, probably that's why is overly complex for simpler tasks like working in a one shared source tree.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
lewax00 wrote:
get latest code
which involves checkouts, fetches, and pulls, none of which make any sense to me in my angry state. I want to simply check out the latest version. How hard should that be?
lewax00 wrote:
run script to make commits, pushes, etc.
The fact that you have SCRIPTS to do those things shows how complex they are. Commit to staging area. Push to remote. Rebase, pull, checkout, WTF??? Again, a simple "commit the changes to the repository" would be sufficient, and again, because I'm so angry that every time I try to start some productive work I end up first spending an hour (YES, A F***ING HOUR) fighting Git, I really have no patience for listening to how "it's my workflow." Maybe tomorrow I'll be in a better mood. Care to share your scripts? I might learn something! Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#This just shows that your problem isn't really with git, it's with you lack of knowledge of it. I'd imagine you're kind of a green horn to the technology, and you haven't quite figured out how all of these things actually benefit you, if you take a moment to learn them.
-
What He Said 8)
-
This just shows that your problem isn't really with git, it's with you lack of knowledge of it. I'd imagine you're kind of a green horn to the technology, and you haven't quite figured out how all of these things actually benefit you, if you take a moment to learn them.
kelton5020 wrote:
I'd imagine you're kind of a green horn to the technology, and you haven't quite figured out how all of these things actually benefit you, if you take a moment to learn them.
Oh, I'm certainly green when it comes to Git. As to version control, I've used it since the days of RCS in DOS. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
kelton5020 wrote:
I'd imagine you're kind of a green horn to the technology, and you haven't quite figured out how all of these things actually benefit you, if you take a moment to learn them.
Oh, I'm certainly green when it comes to Git. As to version control, I've used it since the days of RCS in DOS. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogWell if you really have, you wouldn't be complaining about not knowing/understanding the terminology :p
-
Source Control? We don't need stinkin' source control... ;P Seriously, it's my understanding that git is meant to manage multiple branches easily, probably that's why is overly complex for simpler tasks like working in a one shared source tree.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
RafagaX wrote:
it's my understanding that git is meant to manage multiple branches easily, probably that's why is overly complex for simpler tasks like working in a one shared source tree.
Yes, I would agree. I can see where my idea of working with revision control is different. I rarely would branch my SVN tree, and the idea of keeping local a local repository with all of the local branches and changes on my computer (until they are pushed onto the remote repository) I can see as possibly beneficial but overly complex, and frankly, scares me a bit with regards to losing my work due to a disk failure or the complexity of merging my work if I fall too far behind everyone else's branches. However, having read something recently, I am beginning to change the mental picture I have been holding - namely, that there is also a local repository as well as a remote repository. That helps me understand why a commit doesn't actually get seen on the remote server until a push happens. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
This is one of the most pathetically complex things I've ever had to work with. It CONSTANTLY gets in the way of actually getting work done - I spend more time f***ing around with pushes and adds and branches and checkouts that I do actually making code changes!!! What a P.O.S. This diagram[^] near the bottom of the post says it all. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#It looks like you just do not need it. JIT has just 2 strong points - distributed architecture and conflict resolution. You use "I" and not "we" in the post, so it is unlikely that you can benefit from either. Besides these 2 advantages, GIT still retains its nature of a quick hack. I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
-
It looks like you just do not need it. JIT has just 2 strong points - distributed architecture and conflict resolution. You use "I" and not "we" in the post, so it is unlikely that you can benefit from either. Besides these 2 advantages, GIT still retains its nature of a quick hack. I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
77465 wrote:
You use "I" and not "we" in the post, so it is unlikely that you can benefit from either.
Well, this IS for a project with a couple other devs on it.
77465 wrote:
I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
Those are not mutually exclusive. My client is an expert at Git and whenever he explains something, it all makes sense and I "get it", but then when I try to do something at home, it blows up for me. It's a learning curve, and I've read through books and blog posts, but there is still a disconnect between what I do, that I think is doing it right, and what ends up happening. However, my rant was at the fact that I tried to do everything possible to kill my changes and revert back to the remote repository, to absolutely no avail. I ended up deleting the entire folder and re-cloning it. When I read in the documentation that doing a "reset --hard" (or whatever the syntax is) should kill my local changes, and doing a fetch / pull / checkout should get me to the latest version on the remote, and it obviously didn't work because "git status" still returned all the changes I wanted to throw away, then yes, I rapidly come to the conclusion that it's a pile of s***. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
77465 wrote:
You use "I" and not "we" in the post, so it is unlikely that you can benefit from either.
Well, this IS for a project with a couple other devs on it.
77465 wrote:
I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
Those are not mutually exclusive. My client is an expert at Git and whenever he explains something, it all makes sense and I "get it", but then when I try to do something at home, it blows up for me. It's a learning curve, and I've read through books and blog posts, but there is still a disconnect between what I do, that I think is doing it right, and what ends up happening. However, my rant was at the fact that I tried to do everything possible to kill my changes and revert back to the remote repository, to absolutely no avail. I ended up deleting the entire folder and re-cloning it. When I read in the documentation that doing a "reset --hard" (or whatever the syntax is) should kill my local changes, and doing a fetch / pull / checkout should get me to the latest version on the remote, and it obviously didn't work because "git status" still returned all the changes I wanted to throw away, then yes, I rapidly come to the conclusion that it's a pile of s***. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogIn a sense, yes, it is that pile. When I started using GIT I created a 3 repository model of the real project and tried commands there first. We also had few developers, but thanks to the lack of coordination and frequent changes in specs and overall project direction GIT payed for itself. I guess that was what a much larger and better organized team would experience.