Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder

PleasureKevin posted:

whats the deal with people not knowing git?

are they old or something? young?

like doesn't every develop need a github repo to get a job? or to even understand programming remotely?

do these people download zip files from github ??

Lmao if you think you know git.

I know how to commit things in git. I know how to not break things terribly. That's knowing git I guess

Adbot
ADBOT LOVES YOU

Symbolic Butt
Mar 22, 2009

(_!_)
Buglord

MALE SHOEGAZE posted:

Lmao if you think you know git.

I know how to commit things in git. I know how to not break things terribly. That's knowing git I guess

same

PleasureKevin
Jan 2, 2011

I've been continuously doing interviews and code challenges and poo poo regardless.

I seemingly have another freelance gig lined up after this one but experience tells me to leave all options open.

I've even done interviews after accepting another offer just for the experience. so definitely stay active.

PleasureKevin
Jan 2, 2011

MALE SHOEGAZE posted:

Lmao if you think you know git.

I know how to commit things in git. I know how to not break things terribly. That's knowing git I guess

um... I can also branch, checkout, merge, set remote, push, pull, view history, add, comment... and that's about it

oh and I've only ever worked by myself with git so it's all a colossal waste of time

Soricidus
Oct 21, 2010
freedom-hating statist shill

~Coxy posted:

2. clearcase is actually pretty good as a source control system as a user, it's just a pain as a sysadmin

lol nope, it's just plain horrible. sry about your stockholm syndrome

PleasingFungus
Oct 10, 2012
idiot asshole bitch who should fuck off

you don't have PMs so here's a thing

Space Whale
Nov 6, 2014

PleasureKevin posted:

um... I can also branch, checkout, merge, set remote, push, pull, view history, add, comment... and that's about it

oh and I've only ever worked by myself with git so it's all a colossal waste of time

You skipped revert and reset.

:mad:

triple sulk
Sep 17, 2014



Luigi Thirty posted:

so here is where i am at. the place that was hiring me for that jr. developer/support janitor thing still hasn't sent me a job offer letter. i asked why last week, they said they needed "final budgetary approval" for it (which they claimed to have received) and i should have it by the end of this week but i still don't have anything. no start date, no salary, nothing. i'm not sure if they're stalling, jerking me around, or are just run by clowns. in the meantime, i got contacted by a recruiter today for a jr. c# developer position with a big financial company located in the same city that i was speaking to last month saying they wanted to bring me in for an interview. i'm not sure what to do!

You'd be using C# which is cool and good, so yes you should do the interview

Blinkz0rz
May 27, 2001

MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

triple sulk posted:

You'd be using C# which is cool and good, so yes you should do the interview

i hate agreeing with sulk but he's right

rotor
Jun 11, 2001

classic case of pineapple derangement syndrome

Luigi Thirty posted:

i got contacted by a recruiter today for a jr. c# developer position with a big financial company located in the same city that i was speaking to last month saying they wanted to bring me in for an interview. i'm not sure what to do!

well youre unemployed so I'd say go for the job interview

PleasureKevin
Jan 2, 2011

i don't think i've used revert lol

also to follow up on what i said about topcoder earlier

topcoder is i guess ironically terribly coded. it's a terrible site that breaks all the time. you can do design challenges there too, and the site is also poorly designed.

the challenge i did went terribly. my submission didn't pass screening and nobody won at all. they got lots of complaints and had to extend the due date and raise the prize like 3 times.

it was an "HTML/CSS" job, but apparently i was supposed to make login actually work somehow, which wasn't mentioned anywhere. i tried to appeal, but the moderator said "you were supposed to use angular", indicating he/she didn't even install the app or read the README or even look in the file system to see it was indeed an angular app.

they are repeating the challenge again, but i don't think i have time to apply or edit my submission. which is too bad because i actually did make some of the features work as a bonus, and built a small node server with API. it was a pixel-perfect recreation of the mock-ups too in pure CSS.

Captain Foo
May 11, 2004

we vibin'
we slidin'
we breathin'
we dyin'

git suicide

my homie dhall
Dec 9, 2010

honey, oh please, it's just a machine
git erdun

comedyblissoption
Mar 15, 2006

cool thing you can do in git w/ rebase -i:

  • be in the middle of working on something
  • you notice you want to refactor X.
  • you can commit your current in progress changes and then refactor X with or without your current in-progress changes
  • put it in the refactoring commit before your changes and make sure all the tests pass w/ the refactoring
  • continue on with your in-progress changes
  • the refactoring is separated out in the commit history from your in-progress changes and is much easier to read

svn does not work very well for this because it encourages munging refactorings and actual functional changes together

this is only important if you care about being able to more easily code review or pick out functional changes in your commit history

comedyblissoption
Mar 15, 2006

svn generally encourages giant commits instead of more granular commits because youre forced to push if you want to save your work as a commit

git allows things like having incremental commits that you can revert back to at any time if you make a mistake and you aren't done w/ your feature yet

svn has some really stupid things like not being able to go back to your functioning working copy w/ in-progress changes before a pull destroys your working copy. sure you can see if there are changes before you pull, but if you resolve any conflicts and pull you can still be in a hosed up state that is more difficult to recover from than if you could just go back to before it was hosed up. some people will copy their entire working directory to another directory before a pull to mitigate this issue

leftist heap
Feb 28, 2013

Fun Shoe
get is really good because of this totally contrived edge i just came up with!! happens once every two years but man when it does you're glad yr usin' git i tell ya what!

comedyblissoption
Mar 15, 2006

this is a use case every time you want to make small incremental changes without being forced to mix your changes w/ everyone else's poo poo yet

svn you just accept your fate and make giant commits that do a whole bunch of poo poo at once and accept that your commit is going to be much harder to read once you do a pull and there are conflicts

comedyblissoption
Mar 15, 2006

this is also a use case if you have a development team size of one

Shaggar
Apr 26, 2006
the fear of commiting something that isn't perfect is absolutely retarded and isn't a reason to have local commits

Shaggar
Apr 26, 2006
also if you have conflicts then you're design is bad and also git will make your conflicts even worse because you will go longer between merges

comedyblissoption
Mar 15, 2006

i think attempting to merge and branch in svn gives you ptsd that you try to avoid it as much as possible

comedyblissoption
Mar 15, 2006

also i agree very frequent merge conflicts means your poo poo is probably all hosed up

that doesnt mean you have to have a horrible solution for resolving merges

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

local commits are for checkpointing when things work, so that when you later discover that something else doesn't work you can figure out where it went wrong. bisecting is love.

comedyblissoption
Mar 15, 2006

in svn you can't push your working changes and then have someone review a logical commit history of 5 different incremental commits before it gets merged into trunk

in svn you have to have someone sit at your box before you push and look at one giant commit or you send them a patch file through e-mail or some process outside of your version control system. you also need to write down what particular commit this was created from, and your commit represented by the patch file is subject to change if there are merge conflicts after the review. in git you can actually push the merge along w/ the 5 incremental commits for review without actually pushing it to trunk yet

alternatively, you could use svn's horrible branching model and push 5 incremental commits to this branch and then have someone review it

but svn's branch merging is so bad the general recommended practice is to not branch

it's obnoxious to get back the history of that branch in svn after you delete it

comedyblissoption fucked around with this message at 00:36 on Jan 18, 2015

rotor
Jun 11, 2001

classic case of pineapple derangement syndrome

Shaggar posted:

the fear of commiting something that isn't perfect is absolutely retarded and isn't a reason to have local commits

hobbesmaster
Jan 28, 2008

but being able to have version control while programming on an airplane is pretty cool

I understand programming on transpacific flights is a terrible edge case

rotor
Jun 11, 2001

classic case of pineapple derangement syndrome

comedyblissoption posted:

svn generally encourages giant commits instead of more granular commits because youre forced to push if you want to save your work as a commit

no, thats just you being retarded. commit when you want to commit.

quote:

git allows things like having incremental commits that you can revert back to at any time if you make a mistake and you aren't done w/ your feature yet

svn has this too!

quote:

svn has some really stupid things like not being able to go back to your functioning working copy w/ in-progress changes before a pull destroys your working copy.

???

rotor
Jun 11, 2001

classic case of pineapple derangement syndrome

hobbesmaster posted:

but being able to have version control while programming on an airplane is pretty cool

you can do this with svn too, file:// repos have been a thing since version whatever

rotor
Jun 11, 2001

classic case of pineapple derangement syndrome

comedyblissoption posted:

in svn you can't push your working changes and then have someone review a logical commit history of 5 different incremental commits before it gets merged into trunk

in svn you have to have someone sit at your box before you push and look at one giant commit or you send them a patch file through e-mail or some process outside of your version control system. you also need to write down what particular commit this was created from, and your commit represented by the patch file is subject to change if there are merge conflicts after the review. in git you can actually push the merge along w/ the 5 incremental commits for review without actually pushing it to trunk yet

alternatively, you could use svn's horrible branching model and push 5 incremental commits to this branch and then have someone review it

but svn's branch merging is so bad the general recommended practice is to not branch

it's obnoxious to get back the history of that branch in svn after you delete it

im not even gonna point by point this poo poo any more because its manifestly obvious that you have no idea how subversion works

rotor
Jun 11, 2001

classic case of pineapple derangement syndrome
the cool thing about ignorance is that people are so eager to share it.

Seaside Loafer
Feb 7, 2012

Waiting for a train, I needed a shit. You won't bee-lieve what happened next

In you lots opinion's are there any emerging development languages/techniques that are 'cutting edge' (and actually good) and actually being used irl.

The sort of thing that is accessible enough to learn on your own with a months study then stick on your cv and apply for jobs for. Id like to have a bash at being ahead of the curve for a change.

tef
May 30, 2004

-> some l-system crap ->

PleasingFungus posted:

you don't have PMs so here's a thing

:keke:

Bloody
Mar 3, 2013

Seaside Loafer posted:

In you lots opinion's are there any emerging development languages/techniques that are 'cutting edge' (and actually good) and actually being used irl.

The sort of thing that is accessible enough to learn on your own with a months study then stick on your cv and apply for jobs for. Id like to have a bash at being ahead of the curve for a change.

c#

Seaside Loafer
Feb 7, 2012

Waiting for a train, I needed a shit. You won't bee-lieve what happened next

done that, lots

e: ive heard whispers of some new natural language stuff but dunno what to look for, but im after something monetisable

Seaside Loafer fucked around with this message at 01:04 on Jan 18, 2015

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
Serious question, how does code review (real code review, the kind where you have someone review and sign off on it before the code actually gets added to trunk) work with svn?

With git you have a branch with your proposed change and your reviewer looks at that and pulls it to the master repo if they think it's good. But it sounds like actually using svn branches is discouraged over on that side of things?

hobbesmaster
Jan 28, 2008

Jabor posted:

Serious question, how does code review (real code review, the kind where you have someone review and sign off on it before the code actually gets added to trunk) work with svn?

With git you have a branch with your proposed change and your reviewer looks at that and pulls it to the master repo if they think it's good. But it sounds like actually using svn branches is discouraged over on that side of things?

you seriously can't think of any other workflow? you do code reviews any way you want, but you can do it that way in svn too. got, or really hg for me just has shinier tools and free hosting

comedyblissoption
Mar 15, 2006

In SVN this can happen:
  • make some changes and get something working
  • you want to commit, so you pull
  • the pull automagically pulls in a bunch of changes. you may have resolved merge conflicts. you may have looked before you jumped. doesn't matter fuckery can happen regardless
  • suddenly a bunch of poo poo is broken and you want to go back to when it was working for whatever reason
In SVN, unless you copied your working directory to somewhere else before the pull, your poo poo is all hosed up and you have to do a bunch of manual fuckery to try to revert back to your good state before the pull

In git this is trivial and you just reset to before the merge

In git you can easily flip back to your good working state and your in-progress merge and also share this with other people

comedyblissoption fucked around with this message at 01:18 on Jan 18, 2015

comedyblissoption
Mar 15, 2006

Jabor posted:

Serious question, how does code review (real code review, the kind where you have someone review and sign off on it before the code actually gets added to trunk) work with svn?

With git you have a branch with your proposed change and your reviewer looks at that and pulls it to the master repo if they think it's good. But it sounds like actually using svn branches is discouraged over on that side of things?
  • You send a giant patch file annotated with the commit that the patch file applies to
  • You use a branch which people recommend you avoid in SVN for good reason
  • Have someone look over your shoulder and say looks good before you push
  • You push and have someone review the code after it's already been merged to the trunk
All of those options are inferior to the idiomatic ways you might review in git

comedyblissoption fucked around with this message at 01:19 on Jan 18, 2015

rotor
Jun 11, 2001

classic case of pineapple derangement syndrome

comedyblissoption posted:

  • You use a branch which people recommend you avoid in SVN for good reason

maybe stop listening to the recommendations of idiots, that's my advice

code review in svn works in exactly the same way that gitlabs does. You put your poo poo on a branch and have someone do a code review, then you merge it. But at some point, idiots like comedybitchoption who have no idea how svn works started saying that branching was super hard in svn, and for some reason people listened to them.

Adbot
ADBOT LOVES YOU

SplitDestiny
Sep 25, 2004
Branching and merging still kinda sucks in svn even though it's much better since like 2009 or so.

Seriously though local branches and commits are a good thing why is this seriously being argued against.

  • Locked thread