p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

Adbot: ADBOT LOVES YOU

# ? May 8, 2024 10:19

Max Facetime: Apr 18, 2009

git is such trash

can you imagine a GFUI for git? exactly

# ? Sep 23, 2012 08:12

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

Win8 Hetro Experie posted:

git is such trash

# ? Sep 23, 2012 08:13

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

het: Nov 14, 2002; A dark black past
is my most valued
possession

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

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

het posted:

I really like using git

this is where i stopped reading and mentally filed you under "idiot"

# ? Sep 23, 2012 08:18

het: Nov 14, 2002; A dark black past
is my most valued
possession

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

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

gabensraum: Sep 16, 2003; LOAD "NICE!",8,1

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

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

het: Nov 14, 2002; A dark black past
is my most valued
possession

rotor posted:

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.

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.

# ? Sep 23, 2012 08:37

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

het: Nov 14, 2002; A dark black past
is my most valued
possession

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.

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

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

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

het: Nov 14, 2002; A dark black past
is my most valued
possession

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.

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.

Well I mean we basically git svn dcommit every time we git commit, but it means we can separate those commits.

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

het: Nov 14, 2002; A dark black past
is my most valued
possession

https://www.youtube.com/watch?v=uB1D9wWxd2w

# ? Sep 23, 2012 09:02

coaxmetal: Oct 21, 2010; I flamed me own dad

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

Max Facetime: Apr 18, 2009

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

het: Nov 14, 2002; A dark black past
is my most valued
possession

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

That sounds like a stupid pain in the rear end though and it really didn't take much effort to figure out the everyday tasks in git, git-svn helped a lot. Also this happens more often than once a year. I'd be willing to entertain the idea that we should be branching more often, but I found that learning how to use git was less complicated than working with our dept to determine standard policy on branching

# ? Sep 23, 2012 09:11

Zombywuf: Mar 29, 2008

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

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

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.

I hate svn so much, I'm actually getting a headache just thinking about it.

pretty glad I switched to git in 2008 and never looked back

# ? Sep 23, 2012 14:49

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

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.

I hate svn so much, I'm actually getting a headache just thinking about it.

perforce

# ? Sep 23, 2012 15:19

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

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

MononcQc: May 29, 2007

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:

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.

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

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

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

Pardot: Jul 25, 2001

Git is the best.

# ? Sep 23, 2012 15:46

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

git from the rear end up

# ? Sep 23, 2012 15:48

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

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.

resolve
This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.

recursive
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mis-merges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.

octopus
This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.

ours
This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the recursive merge strategy.

subtree
This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.

subtree[=path]
This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.

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

Zombywuf: Mar 29, 2008

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:

o
| \
o  |
|  |
|  o
|/ |
|  |
o  |
| \|
|  |
|  o
| /
o

That's trivial in dvcs. Just thinking about merging like that in svn makes me sweat.

So yeah, git is a magical merging engine. (Admittedly I work with mercurial).

# ? Sep 23, 2012 16:05

JawnV6: Jul 4, 2004; So hot ...

Otto Skorzeny posted:

if you bother to learn how to use it

# ? Sep 23, 2012 16:23

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

tef: May 30, 2004; -> some l-system crap ->

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

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

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

tef: May 30, 2004; -> some l-system crap ->

fixed point for lyfe

i too, think floating point is overrated

# ? Sep 23, 2012 17:09

MononcQc: May 29, 2007

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

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

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

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

tef posted:

i too, think floating point is overrated

unironically this

# ? Sep 23, 2012 17:46

Zombywuf: Mar 29, 2008

rotor posted:

yeah, if you're regularly doing these really complex merges git probably has an roi

but most people don't. I sure don't.

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

Adbot: ADBOT LOVES YOU

# ? May 8, 2024 10:19

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

no hard feelins tho

# ? Sep 23, 2012 20:20

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »