 |

|
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
|
|
|
|

|
I'd have to agree though. I prefer Subversion. Once you get a handle on it, it's incredibly simple to use.
|
|
|
|

|
I love it personally. Don't get me wrong, I'm quite fond of Subversion as well but Git, Mercurial and Bazaar just fit so much better with the way I work.
Eagles may soar, but weasels don't get sucked into jet engines
|
|
|
|

|
I think you've just saved me at least a week with that post. I'm looking for a place to host a project and for a VCS. The stuff I was reading recommended GIT. I won't be following it up any further. I've used SVN and its survivable as a team member but I dread having to manage it.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|

|
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...
|
|
|
|

|
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
|
|
|
|

|
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).
|
|
|
|
|

|
...Windows Home Server? Sorry, you lost me on that one...
|
|
|
|
|

|
(If I understand correctly)
IMO, there should be a more in GIT to skip the local repository and work on the global one, thus turning GIT into SubVersion.
I'm using SubVersion now, and would like to have a local repository instead of having to create branches and stuff like that.
Nihil obstat
|
|
|
|

|
Yeah, each step requires multiple commands; I'm not sure if I should like that.
My typical workflow, when working on the main branch:
hacka hacka hacka
because that's part of our job, too.
git gui
Sort the mess I coded into easily digestable commits. UI sucks, but does the job.
(at command line, this would be git add, git commit)
alternatively / if this is not good enough:
git rebase -i pub/master
to reorder, clean up and combine commits.
git fetch pub
to get all changes from the other guys.
git rebase pub/master
Put my pending changes on top of the other guys changes
gitk
Look at the commits the other guys made, just to get an idea what they are on.
git push peterchen master
backup current state to remote repo (often involving -f)
ph mk
Build the code. If it compiles, it's good to go!
git push pub master
Push my changes to the main repo
Sometimes, curse at whoever made a push pub master in the meantime
repeat the recent steps since fetch, omitting all the quality checks to get the code pushed and pray that I didn't break the pub repo
The data model takes a bit to wrap your head around. git stores revisions, but most commands actually move around changes between revisions. Branches and tags act like "pins", everything that is not directly or indirectly pinned gets garbage collected.
I have a local "temp" branch that I use for intermediates I want to save before messing around. (you could use git stash, but it's only good if you are 101% sure it will be short-lived).
Larger independent developments go on a branch. master is merged into that dev branch from time to time, when the code is good to go, dev branch is merged into master.
That's it. peterchens 5 minutes of git.
|
|
|
|

|
Thanks, that is helpful!
Marc
|
|
|
|

|
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
|
|
|
|

|
Well if you really have, you wouldn't be complaining about not knowing/understanding the terminology :p
|
|
|
|

|
The fact that you even have "repeated tasks with more than a couple steps" is WTF-worthy in something which is supposed to make your life easier. In SVN you have one-click (or one-command) 'update' and 'commit' for the most common tasks. If you can't do that in GIT without scripting then it is objectively worse for the 99% case.
|
|
|
|

|
I meant that as a general statement, not as Git specific. I script anything and everything I can. For example, since I find myself working with Base64 encoded files often, I now have scripts on my path to encode and decode Base64, a set for strings and a set for files (I could combine them, but that would be more work than having 2 sets honestly). As far as Git goes, the only common task I've encountered with more than one step is commit+push, but not every commit needs a push.
|
|
|
|

|
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
|
|
|
|

|
I have never tried GIT, but I was using Mercurial, until recently I switched over to TFS Online.
Mercurial was very good, I really liked it (I had even setup a Linux server for HTTP push/pull, with my own customized theme). but then TFS was free, hosted and I can setup builds to directly deploy to windows azure (MS just rolled out GIT support also).
|
|
|
|

|
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
|
|
|
|

|
I've just tried the TFS Online and it's incredibly simple. Free for up to 5 users, and very, very easy to set up. Connecting to it from inside Visual Studio was a piece of cake s well. All in all, I'm very pleased with it.
|
|
|
|

|
Maybe there is hope after all. I can definitely manage TFS however is there a Unix/Linux client?
...
Yes google says there is, even an Eclipse plugin, I'm saved from the clutches of GIT and the travails of SVN, Hallelulia
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|

|
Pete O'Hanlon wrote: I've just tried the TFS Online and it's incredibly simple.
I use SVN for my own projects and one of my clients used SVN, which I find incredibly easy to use. A new client is using Git, and they love it. I'm trying to see the inner beauty, but right now, Git looks like a wrinkled, fat, ugly w**** with sallow alcoholic skin and cigarette stained teeth.
Marc
|
|
|
|

|
Marc Clifton wrote: Git looks like a wrinkled, fat, ugly w**** with sallow alcoholic skin and cigarette stained teeth
Listen you, I don't know GIT but you leave my mother out of it!
I use TFS at work and I think it is a PITA, I can understand your horror after seeing that diagram!
Never underestimate the power of human stupidity
RAH
|
|
|
|

|
Marc Clifton wrote: I'm trying to see the inner beauty, but right now, Git looks like a wrinkled,
fat, ugly w**** with sallow alcoholic skin and cigarette stained teeth.
Beer googles which is presumably how most of the advocates operate.
|
|
|
|

|
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
|
|
|
|

|
Well take heart. Some of us are still using VSS 6.0.
Until starting this gig I didn't even know VS2010 would work with that.
|
|
|
|

|
We went from VSS to TFS a few years ago, marginally more complex but much better integration and control.
Never underestimate the power of human stupidity
RAH
|
|
|
|

|
Mecurial is my favorite DVCS. I use RhodeCode for my Source Control manager, and Jenkins for my build server.
Bob Dole The internet is a great way to get on the net.
 2.0.82.7292 SP6a
|
|
|
|

|
I've used various different systems and still think svn is the best, all things considered. Some of gits merging functionality is very nice, but it still feels half baked at and times and deliberately complicated.
|
|
|
|

|
As much as I would like to disagree, I can't really. There's just too much work babysitting it. SVN is pretty much invisible, and I like it that way.
|
|
|
|

|
Yikes. Glad I don't have to use that. Subversion is bad enough and I'm supposed to start using TFS last year .
Oh, how I long for the blissful (*) days of CMS[^].
* Well, no, we weren't writing in BLISS.
|
|
|
|

|
Learning curve: Two miles through the snow, uphill, both ways.
But then: enlightment.
I was lucky, had someone to hold my hand, still took me some weeks of daily use to get used to it.
It is a pinnacle of "developers aren't users" software, so yeah, I see you pain. Yet I do not want to miss the workflow anymore I can have with git. All attempts to plaster a decent UI on top of it somehow make it worse, though.
|
|
|
|

|
peterchen wrote: I was lucky, had someone to hold my hand,
Fortunately, I do to, but I work at home and my client works at home, and we don't live in the same home, so often enough I have to figure things out on my own. Worse thing is, I thought I had it under control, but then discovered something yesterday that I couldn't work around.
My solution? Deleted the whole project and re-cloned it from the remote. Maybe that's what I'll just do as s.o.p, hahaha.
Marc
|
|
|
|

|
Good news Marc, there is help[^].
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|

|
Nagy Vilmos wrote: Good news Marc, there is help[^].
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
|
|
|
|
|
|

|
I now work with a guy who is completely confused about how to use SVN...Constantly complaining about how someone else used to manage making commits for his source code.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|

|
S Douglas wrote: Constantly complaining about how someone else used to manage making commits for his source code.
Wow. How dificult is right-click on a folder and select Commit? Well, if you're using Tortoise SVN.
Marc
|
|
|
|

|
Marc Clifton wrote: if you're using Tortoise SVN.
Yea, we are and it is that easy...
I am beginning to believe he just wants something to complain about.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|

|
It was created to solve a specific task in a specific context.
And then everyone wanted to use it for everything and rationalized the usage due to the perceived acceptance.
|
|
|
|
|

|
Amrykid wrote: *cough* SmartGit[^] *cough*
OK, that looks really useful. Much appreciated!!!
Marc
|
|
|
|

|
Amrykid wrote: *cough* SmartGit[^] *cough*
By the way, I want to thank you for pointing out SmartGit - that has made life a LOT easier, and my client is very impressed with the application as well!
Marc
|
|
|
|

|
No problem, I've been using it for years and I just wanted to share such a wonderful application.
|
|
|
|

|
Git and SVN solve different problems. You should use the one most suited to your current project/needs. SVN is a centralized whereas Git is a distributed. With SVN, you have a local working copy and with Git you have a local repository. It is for this reason it may seem that Git is overly complex. If you want to fork a repo and add features that will be different from the projects original goals then Git might just work best for you. If you want a group of individuals contributing to a common code base then SVN will be your best bet.
|
|
|
|

|
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
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.
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."
|
|
|
|

|
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)
|
|
|
|
 |