|
im having to translate someone elses build script because we moved from svn to git and it's a huge loving pain in the rear end because: 1) its a build script and build scripts are always terrible 2) git is awful in lots of different ways and somehow this build manages to showcase most of them! 3) its someone ELSES build script for a product i've literally never worked on 4) i didnt want to move to git in the first place, so this is a lot like being shot in the head and having to bury yourself in a grave you dug before they shot you.
|
# ? Sep 23, 2012 07:59 |
|
|
# ? May 9, 2024 01:04 |
|
git is such trash can you imagine a GFUI for git? exactly
|
# ? Sep 23, 2012 08:12 |
|
Win8 Hetro Experie posted:git is such trash
|
# ? Sep 23, 2012 08:13 |
|
git is great if you're contributing to a project and you have some tiny little anemic pipe you have to commit through because you're poor or live in some horrible little back-alley of a country. and that's about the only decent use case.
|
# ? Sep 23, 2012 08:14 |
|
I really like using git commit -p to selectively commit stuff when I've made a few changes that should logically be separated (esp when one set isn't ready for commit yet)
|
# ? Sep 23, 2012 08:17 |
|
het posted:I really like using git this is where i stopped reading and mentally filed you under "idiot"
|
# ? Sep 23, 2012 08:18 |
|
Would you have preferred it if I put quotes around "git commit -p"? I have issues with git but I have issues w/ svn too
|
# ? Sep 23, 2012 08:19 |
|
no but for reals, here are some nice things about git: *easily shelving changes *conflicts by change, not by file * ... uhh ... everything else that's neat about it has necessary consequences that i dont feel are worth it. the entire idea of both local and remote repos is wrongheaded imo.
|
# ? Sep 23, 2012 08:24 |
|
i like being able to check in my stuff at the end of the day even though it's in a broken state just so that i have it in source control and backed up etcetera but not affect anyone else, since i won't sync it until i'm happy with it. i know all source control has ways of doing this kind of thing but the git way just kind of makes sense to me. visual studio tools are pretty lacking for it though, i just use tortoisegit.
|
# ? Sep 23, 2012 08:29 |
|
deep square leg posted:i like being able to check in my stuff at the end of the day even though it's in a broken state just so that i have it in source control and backed up etcetera but not affect anyone else, since i won't sync it until i'm happy with it. you should always be working on a dev branch until the feature/fix is complete so the workflow here is literaly identical in git as svn.
|
# ? Sep 23, 2012 08:31 |
|
rotor posted:no but for reals, here are some nice things about git:
|
# ? Sep 23, 2012 08:37 |
|
het posted:I think there are some changes that aren't minimal but for which creating an actual branch is more effort than necessary. so the appropriate solution to this problem of "ugh creating and switching to a branch is hard" is to have a plurality of repositories.
|
# ? Sep 23, 2012 08:41 |
|
rotor posted:so the appropriate solution to this problem of "ugh creating and switching to a branch is hard" is to have a plurality of repositories. edit: also I should mention that our use of git is through git-svn, though we're talking about moving the backing repository from svn to git
|
# ? Sep 23, 2012 08:45 |
|
het posted:I feel like an Android user but for my uses at work (which involve a small number of developers whose work is fairly compartentalized) it fits my needs... this is the situation for which git is least appropriate - a small team of geographically close devs who dont have a lot of merge issues. use whatever tool you like, im not gonna tell you how to run your poo poo. but i'm rollin my eyes over here, i tell you what.
|
# ? Sep 23, 2012 08:47 |
|
rotor posted:this is the situation for which git is least appropriate - a small team of geographically close devs who dont have a lot of merge issues. I mean I realize that's basically using git for a fairly minor feature advantage but I don't feel like we've really had any problems thus far from using git.
|
# ? Sep 23, 2012 08:52 |
|
https://www.youtube.com/watch?v=uB1D9wWxd2w
|
# ? Sep 23, 2012 09:02 |
|
rotor I don't really understand your whole anti-git agenda. I'm not a huge git fan or anything, but like, it seems to work pretty good.
|
# ? Sep 23, 2012 09:06 |
|
het posted:I think the idea of local and remote repos isn't intrinsically wrongheaded insofar as it gives you the opportunity to branch without officially branching. I mean maybe you think that's wrongheaded, but I think there are some changes that aren't minimal but for which creating an actual branch is more effort than necessary. local branches (I hesitate to deem them repos) are fine, as long as they live inside your primary IDE. for example, eclipse has file history that goes back at least 1 month or so. for the once a year occurrence when one wants to commit just some of the changes, a copy of the source folder followed by reverting the changes one doesn't want to commit right now, then copy-pasting and re-synchronizing the source folder back in is lot less mental than trying to figure out git
|
# ? Sep 23, 2012 09:07 |
|
Win8 Hetro Experie posted:for the once a year occurrence when one wants to commit just some of the changes, a copy of the source folder followed by reverting the changes one doesn't want to commit right now, then copy-pasting and re-synchronizing the source folder back in is lot less mental than trying to figure out git
|
# ? Sep 23, 2012 09:11 |
|
rotor posted:you should always be working on a dev branch until the feature/fix is complete so the workflow here is literaly identical in git as svn. The git workflow doesn't have the 10 minute pauses while you commit that you get in svn, nor the hour long merge sessions which lead you to plotting the death of all the first born sons of your local area. It also doesn't lead to having to have a meeting because 2 people tried to merge their dev branches at once. I hate svn so much, I'm actually getting a headache just thinking about it.
|
# ? Sep 23, 2012 12:01 |
|
Zombywuf posted:The git workflow doesn't have the 10 minute pauses while you commit that you get in svn, nor the hour long merge sessions which lead you to plotting the death of all the first born sons of your local area. It also doesn't lead to having to have a meeting because 2 people tried to merge their dev branches at once.
|
# ? Sep 23, 2012 14:49 |
|
Zombywuf posted:The git workflow doesn't have the 10 minute pauses while you commit that you get in svn, nor the hour long merge sessions which lead you to plotting the death of all the first born sons of your local area. It also doesn't lead to having to have a meeting because 2 people tried to merge their dev branches at once. perforce
|
# ? Sep 23, 2012 15:19 |
|
git is not some magical merging engine. it does have the advantage of per-line instead of per-file conflicts, but if you have actual conflicts (the hard to resolve kind) fit is no different from svn.
|
# ? Sep 23, 2012 15:31 |
|
rotor posted:git is not some magical merging engine. it does have the advantage of per-line instead of per-file conflicts, but if you have actual conflicts (the hard to resolve kind) fit is no different from svn. the advantage with git is that you don't have to worry about somebody else merging against trunk at the same time "but you should use branches and not trunk" git makes branches easier and better than just copying the entire tree all over again
|
# ? Sep 23, 2012 15:37 |
|
rotor posted:im having to translate someone elses build script because we moved from svn to git and it's a huge loving pain in the rear end because: Git has piece of poo poo abstractions. I spent a couple of years hating it really hard because git fans swore up and down that it was great and usable, and it never was (same as Linux on the Desktop). I only got to find git usable after reading Git from the bottom up (PDF), which basically says 'screw the fake abstractions' and tells you how git does things for real. After that it becomes somewhat usable and you start seeing the advantages.
|
# ? Sep 23, 2012 15:38 |
|
MononcQc posted:I only got to find git usable after reading Git from the bottom up (PDF), which basically says 'screw the fake abstractions' and tells you how git does things for real. After that it becomes somewhat usable and you start seeing the advantages. samw
|
# ? Sep 23, 2012 15:42 |
|
Git is the best.
|
# ? Sep 23, 2012 15:46 |
|
git from the rear end up
|
# ? Sep 23, 2012 15:48 |
|
LVI. On whether git is a magical merging engine? Objection 1: rotor posted:git is not some magical merging engine. it does have the advantage of per-line instead of per-file conflicts, but if you have actual conflicts (the hard to resolve kind) fit is no different from svn. Sed contra: man git-merge posted:The merge mechanism (git-merge and git-pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X<option> arguments to git-merge and/or git-pull. I answer that: while git is not magic, its merge capabilities can indeed make some apparently hard merge conflicts go away if you bother to learn how to use it.
|
# ? Sep 23, 2012 15:53 |
|
rotor posted:git is not some magical merging engine. it does have the advantage of per-line instead of per-file conflicts, but if you have actual conflicts (the hard to resolve kind) fit is no different from svn. What it does have, as all dvcs has, is the ability to know what changes have been merged already. SVN is amazing at bringing up false conflicts when two changes have made the same change to piece of metadata you've never heard of. Look at this merge graph: code:
So yeah, git is a magical merging engine. (Admittedly I work with mercurial).
|
# ? Sep 23, 2012 16:05 |
|
Otto Skorzeny posted:if you bother to learn how to use it
|
# ? Sep 23, 2012 16:23 |
|
yeah, if you're regularly doing these really complex merges git probably has an roi but most people don't. I sure don't.
|
# ? Sep 23, 2012 16:34 |
|
they're not complex merges in anything but svn and earlier. I just pull, hack, commit, push. I find it less effort than svn has ever been in practice. and i've found it mostly less painful , and occasionally it's saved my butt. it isn't a magic thing, or a crazily complex thing. I haven't really learned git/hg much beyond how I used svn. (that said, i converted repo from hg to git the other day by doing hg push git@.... and it worked) git was written for situations where you can't give out the commit bit, but it is really about letting people commit code and merge code, without having to do both at the same time. which is kinda neat
|
# ? Sep 23, 2012 17:03 |
|
rotor posted:but most people don't. I sure don't. most people don't need an fpu. i sure don't.
|
# ? Sep 23, 2012 17:06 |
|
fixed point for lyfe i too, think floating point is overrated
|
# ? Sep 23, 2012 17:09 |
|
I mostly got into git so people would shut the hell up when I told them I didn't want to use git for my projects. Also work. Path of least resistance and all.
|
# ? Sep 23, 2012 17:17 |
|
Otto Skorzeny posted:most people don't need an fpu. i sure don't. I agree, one tool is all you really need, it just has to be sufficiently complex and powerful.
|
# ? Sep 23, 2012 17:18 |
|
tef posted:i too, think floating point is overrated unironically this
|
# ? Sep 23, 2012 17:46 |
|
rotor posted:yeah, if you're regularly doing these really complex merges git probably has an roi That ain't really complex. That's just 2 people collaborating. Some of our merge graphs look horrific but I only notice them after I look at the logs. I'm curious to see what the merge graphs of big teams look like.
|
# ? Sep 23, 2012 18:32 |
|
|
# ? May 9, 2024 01:04 |
|
no hard feelins tho
|
# ? Sep 23, 2012 20:20 |