who here uses git?

[purbeast0]

been using git for a while now at work (like a year+) and had come from svn. svn was so easy compared to git, but after using git for this time, i can see why people use git and it's definitely more powerful. it definitely does have a steep learning curve though.

i've been using tortoise git for the most part and had good luck.

that is, until these past few weeks. yesterday was the icing on the cake.

i came into work today with the dreaded horse at my desk, and yesterday i apparently merged dev into a release branch on complete accident. and today checking the git reflog, i still cannot figure out how the hell that happened.

the past few weeks i've had a few mishaps and it's all when using tortoisegit. so today i've decided that i'm going to just use command line only and not use toirtoisegit anymore.

looking at the reflog too, it is pretty interesting to see the commands that tortoisegit actually uses when doing things you think it's doing. the whole rebase process in tortoisegit is actually doing cherrypick commands and not actual rebase.

then "pull" in tortoise is also doing something else - it's doing "pull -v --progress origin: fast-forward" which i had no clue (and don't even know exactly what that means).

but i figure, as much of a headache as it will be to learn, that using command line in general will be better in the long run and i will get a better understanding in general.

 

[cabri]

Each to their own poison (command line vs GUI)

The GUI makes it easier to see what is happening; but as yo have found also easier to screw it up.

Such is with any tool - with power comes responsibility

 

[Cogman]

At work I use svn, for my side projects I use git.

While I like toirtoisesvn, I'm not a huge fan of toirtoisegit . It abstracts away a lot of the git commands and tries to force git into a more svn esq workflow. Git does not have the same workflow as SVN. With SVN it is more natural for big commits, With git it is discouraged. With SVN every commit goes off to the server, with git it is only bundles of commits that go off. With SVN branching is a pain and (in my company) even discouraged. With git branching is a natural and practically required thing to do.

I really like git. My favorite thing about it is using it to track down where bugs are introduced. The git bisecting stuff is awesome! It is more awesome if everyone follows the small commit rule.

 

[paperwastage]

^ you can always use git-svn

http://git-scm.com/docs/git-svn

company still uses svn in backend, but you can use git on your local machine.... you get some benefits of git (cheap local branching, able to stage/divide your work into smaller git commits, before you push your final git changes to the company's svn)

// I've used svn, git, perforce at work before, and always use the git-svn or git-p4 to convert everything into my own git repo. there are a few cases where you can't use git (eg large-binary blob repository like game design), but i think git is able to handle most of the other cases

 

[dave_the_nerd]

Use git here. Mostly we just support the CLI. Some people use GUIs, but they're on their own.

It works. I don't have anything to complain about I guess.

 

[Cogman]

^ you can always use git-svn

http://git-scm.com/docs/git-svn

company still uses svn in backend, but you can use git on your local machine.... you get some benefits of git (cheap local branching, able to stage/divide your work into smaller git commits, before you push your final git changes to the company's svn)

// I've used svn, git, perforce at work before, and always use the git-svn or git-p4 to convert everything into my own git repo. there are a few cases where you can't use git (eg large-binary blob repository like game design), but i think git is able to handle most of the other cases

I used it for a while but I kept running into corruption and slowness issues on windows. Our company did SVN wrong and has every single project under one SVN root the result is that it takes FOREVER to hook up to build the git repo, (we have something like 60000 revisions at this point). It was literally an overnight process that my sysops guys would often kill leaving me to restart it.

 

[paperwastage]

I used it for a while but I kept running into corruption and slowness issues on windows. Our company did SVN wrong and has every single project under one SVN root the result is that it takes FOREVER to hook up to build the git repo, (we have something like 60000 revisions at this point). It was literally an overnight process that my sysops guys would often kill leaving me to restart it.

well, you don't have to import the whole svn history... just do the past 3k and only trunk branch, you should have enough info for most of your work (can always go back to svn for very old changes). main purpose (for you) would be getting git for it's "offline small commit" benefit

http://trac.parrot.org/parrot/wiki/git-svn-tutorial

git svn clone -s -r 40000:HEAD https://svn.parrot.org/parrot # choose some recent-ish commit

think the last time I used it, the company's svn had 52k revisions, I only imported 3k revisions

 

[brianmanahan]

i use git for personal projects and i wish i could use it at work too

RTC is a monster

 

[Cogman]

well, you don't have to import the whole svn history... just do the past 3k and only trunk branch, you should have enough info for most of your work (can always go back to svn for very old changes). main purpose (for you) would be getting git for it's "offline small commit" benefit

http://trac.parrot.org/parrot/wiki/git-svn-tutorial



think the last time I used it, the company's svn had 52k revisions, I only imported 3k revisions

I missed a 0 on the revisions. We are at 600k revisions now (dear god...). Many of those revisions happened from build tools which interact with svn to do magical things.

The problem I have is that I like and use the revision history heavily, and that my project is a relatively old one (it starts at around revision 20k). Today, our team is sparse and the project huge. 3k revisions wouldn't be nearly enough, 10k revisions wouldn't even cut it really. I would need around 100k revisions for it to be semi-useful and workable.

 

[purbeast0]

the worst one i ever used was the one at my first job. i just didn't know any better. we used perforce. and it's crazy how expensive it is to use, especially with things like git out there.

i really like using git locally as well. i am trying to get git installed on my little website hosting i have just so i can push to a remote server and have backups that aren't in my possession.

 

[Ken g6]

At work I use svn, for my side projects I use git.

Me too. For one thing at work, though, I used "bzr" ("Bazaar"). Slowest. Version. Control. System. Ever. Git is written in C++, so it's fast. Bzr is written in Python.

 

[Red Squirrel]

I've always just used rsync, any reason to use SVN/Git? I'm kind of looking into it, especially for a project where more than one person works on. Currently any new script revisions are sent to me, I put in dev, compile to make sure it works, then rsync to test and then eventually prod after testing phase. But with SVN I imagine I could just give access to everyone coding and they can update at will? What if two people work on same code does it actually merge or warn or do something? I'd probably still use rsync to move from dev to test and test to prod though, but dev would be the official repository.

 

[purbeast0]

git keeps local copies of the repositories so you will each have your own repository of the same code base, then when you are done making changes, you push to the repo where the master resides. it really is a different mindset than svn and traditional vcs control systems. and it definitely takes some getting used to, because you will be trying to do things in git the same way you did in other vcs, but the thing is, you aren't supposed to do it that way.

i'm still trying to wrap my head around how it all works because we have many branches at work and are constantly making new branches and merging them.

for my own personal projects i don't have a remote repo that i push to, i just do it all locally, which makes things a little easier because i don't have to worry about having to resolve my changes with other people's changes on a repo.

 

[Crusty]

I've always just used rsync, any reason to use SVN/Git? I'm kind of looking into it, especially for a project where more than one person works on. Currently any new script revisions are sent to me, I put in dev, compile to make sure it works, then rsync to test and then eventually prod after testing phase. But with SVN I imagine I could just give access to everyone coding and they can update at will? What if two people work on same code does it actually merge or warn or do something? I'd probably still use rsync to move from dev to test and test to prod though, but dev would be the official repository.

rsync? Are you some kind of masochist?

Do you at least use patch files from your developers or do you just overwrite files every time someone wants to commit code?

I don't see how you could work on more than one specific task at a time with that workflow, the bookkeeping must be a nightmare. How do you know who broke something, or when the breakage was introduced? Especially so if you don't catch the bug during your 'test' phase.

 

[Crusty]

the worst one i ever used was the one at my first job. i just didn't know any better. we used perforce. and it's crazy how expensive it is to use, especially with things like git out there.

i really like using git locally as well. i am trying to get git installed on my little website hosting i have just so i can push to a remote server and have backups that aren't in my possession.

There's really not much you need to do. If you can ssh to the machine you can push a git repository to it(assuming git tools are installed on the machine).

 

[Crusty]

For those of you new to Git I would highly recommend going through http://pcottle.github.io/learnGitBranching/ to learn about branching. Even after using git for over a year in my daily workflow I learned so much from those tutorials.

 

[Cogman]

I've always just used rsync, any reason to use SVN/Git? I'm kind of looking into it, especially for a project where more than one person works on. Currently any new script revisions are sent to me, I put in dev, compile to make sure it works, then rsync to test and then eventually prod after testing phase. But with SVN I imagine I could just give access to everyone coding and they can update at will? What if two people work on same code does it actually merge or warn or do something? I'd probably still use rsync to move from dev to test and test to prod though, but dev would be the official repository.

Yeesh! This is crazy!

You could even keep the exact same workflow and still benefit from using Git/SVN/Mercurial. You wouldn't have to give anyone access to the repo if you didn't want to.

The thing that is great about revision control systems is that going backwards is a piece of cake and finding the reasons for things are written the way they are also really simple. These systems keep track of the change and a short message describing what the change is supposed to do.

Beyond that, they do manage merges and merge conflicts. If two people edit the same region of code, these systems will tell whoever pushed to the server second that "Hey, things were updated, you need to go fix it".

Git, in particular, is nice because it adds a ton of redundancy to the code writing process. Everyone that has cloned the repo has everything that has been put in the repo since the beginning of the repo. This means if the server hosting the repo dies, it becomes a simple matter of figuring out who had the latest and uploading it to the server. You can also do all sorts of fun things with tags/branches/etc in git. It becomes very natural to write new features in separate branches that are merged back into master when the feature is complete, effectively separating out the work for a developer who has his figures in multiple projects.

You can add a whole lot of goodies to these systems as well. Things like running unit tests, building the code, running a code formatter/style enforcer, whatever. You can do these things every time someone pushes something to the remote server.

Imagine how much of your own time you could save if you weren't the code compiler, patcher, and merge conflict enforcer. These systems are a must for any code development.

 

[master_shake_]

i do.

i'm always telling kids to "git off my lawn!"

 

[beginner99]

If you have the choice and want to switch from svn I would chose mercurial. it's much friendlier than git, IMHO. Note that you also get free repos online on bitbucket, which is pretty similar to github. And the 2 can pretty easily be converted to each other.

 

[Sgraffite]

My last job used SVN, this job uses Git. Bitbucket lets you make free private repos for personal/small business use whereas Github forces repos to be public.

 

[pauldun170]

i use git for personal projects and i wish i could use it at work too

RTC is a monster

Been using RTC for years now.Pretty much manage the who lifecycle through it.
Works well enough for us.

 

[brianmanahan]

Been using RTC for years now.Pretty much manage the who lifecycle through it.
Works well enough for us.

yeah i like to give it grief, but it's actually not TOO bad. it has caused me grief and screwed up my workspace once or twice, but compared to clearcase it is a gift from god :biggrin:

 

[Red Squirrel]

rsync? Are you some kind of masochist?

Do you at least use patch files from your developers or do you just overwrite files every time someone wants to commit code?

I don't see how you could work on more than one specific task at a time with that workflow, the bookkeeping must be a nightmare. How do you know who broke something, or when the breakage was introduced? Especially so if you don't catch the bug during your 'test' phase.

Honestly it's kinda a mess. Sometimes we even exchange code through Facebook chat. D: Used to use MSN till they shut it down but equally as bad. I wrote a program that basically goes through each script and counts the lines of code and generates a header and if the file changed it puts the name of the last person that modified it but there's not really any tracking beyond that. Before we give each other code we run the program, normally, sometimes... lol It also puts the path in the header, as the application will look in a "new scripts" folder and then copy any files to the path that's in the header but recently that part broke and files were ending up in the wrong place.

Git does indeed sound like it could make the workflow much better. We're only 2 on the project right now and we tend not to update stuff often but still a pain at times as we have to manually keep each other's distros updated.

So yeah, definitely going to look into using Git or SVN. Something that has been on the back of my mind for a while.

 

[purbeast0]

yeah if you are writing code and don't have any kind of version control, you are really hurting yourself. it is just easier to go back to stuff if you mess things up and see how code evolved if you need to. it sounds like you don't even have backups of files lol. vcs makes all of that stuff a piece of cake.

 

[IHateMyJob2004]

Git Extensions!