|
if you can get over torvald's arrogance he starts a discussion about the problems that branching is trying to solve in git: https://www.youtube.com/watch?v=4XpnKHJAok8&feature=player_detailpage#t=1326
|
#
?
Jun 14, 2015 17:44
|
|
|
|
| # ? May 17, 2024 16:24 |
|
|
Jsor posted:In addition, I find it's generally best to take a policy of always rebasing before merging, because I find it makes histories much less confusing, but that's contentious and a lot of people disagree. There's very little in git that has a 'right way' to do things; if you want to talk coding horrors, just read the endless deluge of awful, awful blog posts about people who say 'always do this' about some git feature. 'Never rebase' / 'always rebase'. Depends entirely on your workflow and requirements what is the best action to take. One of the rules we can generally adopt is 'no changing public history' but if I'm the only developer on a branch? Yeah I'll break that rule. Not that I *want* to, but we're only human and sometimes we gently caress things up. There's always, always a way to fix things without changing public history, but sometimes it's just easier to do so if you know no-one else has actually touched the branch/repo yet. tl;dr: only u can ever know what is best for yr repo
|
|
#
?
Jun 14, 2015 17:46
|
|
|
Voted Worst Mom posted:git is good because branches are cheap as hell and this is a good feature for a time machine to have. but that doesn't matter when the merges are colossal clusterfucks
|
|
#
?
Jun 14, 2015 17:46
|
|
|
Also I don't think there's something intrinsic or fundamental to centralized version control systems that make merging a difficult process. I think you could prioritize making that a painless enough process to make it part of a normal workflow. It's just that there hasn't been as much emphasis on making that good as in a DVCS, because in a DVCS it's a necessary requirement.
|
|
#
?
Jun 14, 2015 17:53
|
|
|
Bognar posted:Same, I try to avoid merge commits as much as possible, ideally everything I push would be a fast-forward. Luckily this is simple in a lot of cases by just changing git pull to automatically rebase instead of merge, then for merging feature branches just use rebase before merge.
|
|
#
?
Jun 14, 2015 18:03
|
|
|
o.m. 94 posted:One of the rules we can generally adopt is 'no changing public history' Even that's not particularly universal, depending on what you consider public history. In a typical branch -> develop -> review -> fix -> review -> merge setup you'll find workflows that rewrite the branch history after each fix session: it's a decent chunk of what the fixup, interactive rebase and autosquash features are intended for. In that sort of workflow only mainline branches will be free from history rewrites, while shared work branches are rewritten all the time. Which can have benefits in terms of overview and keeping commits atomic, which may or may not be worth it depending on team preferences, tool support and so on. Having worked with that sort of workflow I'd say that if there's a horror I have encountered it's that the tool support tends to be crap. I'm a wuss who likes GUIs so I use SourceTree for most operations, but doing an interactive rebase with fixup commits present will currently make it hang. We also use GitHub, but not for code reviews in some projects, because its review interface doesn't preserve review history if the PR branch has its commit history rewritten. We also have next to no organizational consistency about this sort of thing, which is no doubt nice if you're a project lead and can make sure you get work in a comfortable way, but less nice if you're tasked with integrating a component into several products and have a half-dozen different CVS workflows, code styles and so on to track. 
|
|
#
?
Jun 14, 2015 19:07
|
|
|
comedyblissoption posted:The hashcode of a commit depending upon prior commits is explicitly a security measure and also to make it easier to detect persistence/disk errors. Security is also why author and other meta fields for a commit are part of the commit hashcode. The fact that the hashcode of the commit depends on prior commits isn't even the only reason why doing this is difficult; even if we removed that from consideration, the fact remains that in git a commit reflects the state of the repository, not a change in the state of the repository (it is based on the current contents of all files, not the diff). So identifying that two different commit hashes represent the same logical change requires actually performing a diff from an ancestor on each of them and then comparing that diff, which as noted above is fragile to begin with, and is actually made possible by the fact that a commit contains a reference to its parent. Security aside, the fact that commits contain references to their parents and that commits are content addressable means the commit hashes must depend on the parent commit, otherwise the hashcode would no longer uniquely identify a commit.
|
|
#
?
Jun 14, 2015 20:26
|
|
|
Education horror the third. I'm now taking Intro to Algorithms. The lecturer assumed we would all have taken discrete math, but all the students work at my employer and our employer doesn't let us take discrete math. None of us have done proofs since high school, much less come up with and proven loop invariants. The lecturer is a grad student, whose first language is German, and he is really struggling to explain any of this without resorting to lots of math symbols we also don't know. I just finished the first homework but I have no way of knowing how confident I should be in my proofs. They used very "unconventional" implementations of the algorithms we're proving, so I couldn't compare my work to existing proofs to get an idea. But there's hope! We can do a programming challenge on SPOJ for extra credit. Up to 5 points per assignment. Except instead of changing the score to up to 25/20 (the base is 20/20), instead it becomes 25/25, so the improvement you can get is almost insignificant and they just throw away the programming thing if it would hurt your score. I didn't think I'd be looking back on Operating Systems fondly already, but I'm legit worried because usually I program myself out of the hole I dig with my homework scores, but that's not possible here. The real horror is that the budget cuts that Scott Walker keeps inflicting on UW means that most undergrad CS students are having their whole degrees taught by grad students with almost no faculty supervision and a huge language barrier in many cases. UW's rankings are going to plummet if this keeps up.
|
|
#
?
Jun 15, 2015 03:13
|
|
|
How come your employer won't allow you to take discrete maths, if it's a prerequisite for algorithms? That sounds really shortsighted considering how related the two are.
|
|
#
?
Jun 15, 2015 04:40
|
|
|
apseudonym posted:Why should reflog info be pushed? Do you want to see twenty commits resulting from git commit --amend? Why? When should they get gc'd away since you're suddenly sharing a lot of garbage commits. Oi vey; I must not be explaining myself very well. I understand git's internal structure in detail. I understand why the hashes must change when you rebase. I am not proposing that those "garbage" commits actually be pushed. Just the 1..N old -> new hash map. I want git to keep a hash record of when history was rewritten and who rewrote it. That would solve just about everything that currently makes force pushing unexpectedly dangerous; instead of suddenly claiming there are 27 upstream and 28 downstream changes, git could tell me "a.rear end in a top hat rebased c0fb3482 onto e0958cd9". In this hypothetical scheme unless there was a rebase or force push on a branch that was already checked out or committed to by others, git would work exactly like it does today. No confusion, no visible changes, no polluted logs.
|
|
#
?
Jun 15, 2015 07:22
|
|
|
Joda posted:How come your employer won't allow you to take discrete maths, if it's a prerequisite for algorithms? That sounds really shortsighted considering how related the two are. They have a specific "curriculum" for employees who want to transfer to software development and won't pay for classes outside that. They also won't approve you to leave work to attend classes not on that curriculum. I don't believe they consulted anyone from the University when designing this curriculum, and the CEO has a Master's in math and is nearly 80 so I think she just has no clue that people can get into/enjoy programming without being huge math geniuses. My work is a bizarre little bubble of parallel reality a lot of the time. We're also destroying all of our competitors, so it's dreadfully unlikely that anyone's going to reexamine any of the more whacky choices any time soon.
|
|
#
?
Jun 15, 2015 08:41
|
|
|
Ender.uNF posted:I want git to keep a hash record of when history was rewritten and who rewrote it. https://mercurial.selenic.com/wiki/ChangesetEvolution Mercurial is getting more relevant development these days.
|
|
#
?
Jun 15, 2015 08:45
|
|
|
Hammerite posted:It looks as though the codebase would end up in exactly the same state either way? Of course we do quick fixes of stuff in the middle of doing other things. I don't follow why you would think we don't. You avoided answering concretely so it's impossible to tell what your actual workflow is (and whether "not using branches" is a sign of badness). if you try to push while someone else has already added stuff to the master, you'll fail. How do you resolve it? You typically either rebase the local branch (see, using branches already) or merge it. If you have a half-finished feature that won't compile, and you need to fix another part of the code, what do you do exactly? There's a bunch of ways to solve this, some horrors, some involving branches, some involving other features. 2 programmers need to work together on the same feature which involves changes throughout the tree. What do you do?
|
|
#
?
Jun 15, 2015 08:52
|
|
|
Skuto posted:You avoided answering concretely so it's impossible to tell what your actual workflow is (and whether "not using branches" is a sign of badness). Sorry, I didn't deliberately set out to be cryptic. quote:if you try to push while someone else has already added stuff to the master, you'll fail. How do you resolve it? You typically either rebase the local branch (see, using branches already) or merge it. I always do a get before submitting changes. If there are any conflicts then they have to be worked out before submitting. Generally that is straightforward. Sometimes if two people are working on the same file there might be more resolving to do than is ideal. Often if that happens it is a good sign that the file in question may benefit from refactoring (the class might have too many responsibilities or whatever). I don't think Perforce has a concept of a "local branch". There is the depot which has files with version history, and that can have branches, but I don't deal with it - I just develop on the trunk - so I don't know how it works. On my machine there is my workspace. Some of my files may differ from files in the depot; those will be the files I am working on. There is no granular history of changes to the files on my machine; just the fact of the differences that exist with the latest set of files in the depot. quote:If you have a half-finished feature that won't compile, and you need to fix another part of the code, what do you do exactly? There's a bunch of ways to solve this, some horrors, some involving branches, some involving other features. If it's another part of the code then it's in a different set of files, presumably. I would set up separate changesets for the half-finished feature and the other issue. I would shelve the files in the changeset relating to the half-finished feature. I would work on the other issue and after submitting the changes for that issue, unshelve the shelved files. If there are files common to both issues it would be a bit more of a bother. quote:2 programmers need to work together on the same feature which involves changes throughout the tree. What do you do? I don't know what you mean by "the tree" here. If two people need to work on the same feature then they will talk to each other and plan out what work will be done. What happens aside from that is really going to vary on a case by case basis.
|
|
#
?
Jun 15, 2015 10:26
|
|
|
The fundamental difference that a DVCS has is that your local "working copy" is effectively just another repository, with its own branches etc.. This is actually really useful for iterating on code - you can create a commit at a stable point (even though it's not yet submit-worthy), try it out, and easily roll back to your stable point if it's not working out. Or you can look through your history of commits to narrow down what part of your change broke something. And so on. Once you have fast and easy local branching, it becomes natural to use local branches for scenarios that require special features in other version control systems. Changesets and shelving, for example, become redundant with git - you just have a separate branch for your bugfix than for the major feature you're working on, and you can easily switch between any of your branches.
|
|
#
?
Jun 15, 2015 10:44
|
|
|
Jabor posted:Once you have fast and easy local branching, it becomes natural to use local branches for scenarios that require special features in other version control systems. Changesets and shelving, for example, become redundant with git - you just have a separate branch for your bugfix than for the major feature you're working on, and you can easily switch between any of your branches. Right, this is one of the points I was getting to. The example with shelve/stash for example. It's a fine alternative to using branches, but in the end you are using a simplified version of them. If you then need to start doing complicated things to work around those limitations (hence the possible "git is complicated"), it's a horror and you should have used branches in the first place. quote:I don't know what you mean by "the tree" here. If two people need to work on the same feature then they will talk to each other and plan out what work will be done. What happens aside from that is really going to vary on a case by case basis. Throughout all the source files or for example >1 component. Of course you need to plan out the development, but if 2 people are making changes to multiple files and need to share their work, but don't expose the rest of the developers to the new bugs they're introducing, that's a classical use case for branches, which is why I brought this up. If your approach to this kind of thing doesn't involve branches I'd find that peculiar.
|
|
#
?
Jun 15, 2015 11:05
|
|
|
Skuto posted:Right, this is one of the points I was getting to. The example with shelve/stash for example. It's a fine alternative to using branches, but in the end you are using a simplified version of them. If you then need to start doing complicated things to work around those limitations (hence the possible "git is complicated"), it's a horror and you should have used branches in the first place. It seems like you haven't yet picked up that he is not using git? You are talking as if he is, and is using it weirdly. He just said git seems complicated, presumably based on discussion here, not his own experience
|
|
#
?
Jun 15, 2015 14:48
|
|
|
Yeah, I thought he was and was then left wondering where the talk of Perforce and a depot suddenly came from. Perforce's branching is pretty decent (and p4merge is excellent) so you'd still use branches there for the stereotypical second example I talked about (2 devs on a feature). One you get why that is useful, then hopefully the idea of having lightweight local branches makes more sense for switching between things you're working on.
|
|
#
?
Jun 15, 2015 15:22
|
|
|
All this talk of vcs reminds me. The company I work for decided in 2012-2013 to stand up an SVN system for all our projects. Worse, there were several people who were pushing for CVS. As for using a DVCS, I helped stand up a test system to show off git, gerrit, and several other nice things we could do. We were told no, the guys just stood up SVN and that it would be several years before considering a change. HFX fucked around with this message at 20:18 on Jun 17, 2015 |
|
#
?
Jun 17, 2015 20:15
|
|
|
HFX posted:All this talk of vcs reminds me. The company I work for decided in 2012-2013 to stand up an SVN system for all our projects. Worse, there were several people who were pushing for CVS. Pushing DVCS on a team that's not interested in using a DVCS is a good way to make that team miserable. I see it all the time from companies where someone in management starts cargo culting and forces a switch to Git, when everyone is perfectly happy and productive using SVN or some other CVCS. Then everyone tries to use a DVCS like a CVCS and it sucks really badly.
|
|
#
?
Jun 17, 2015 21:10
|
|
|
HFX posted:All this talk of vcs reminds me. The company I work for decided in 2012-2013 to stand up an SVN system for all our projects. Worse, there were several people who were pushing for CVS. This is a sad, but common tale of woe. I understand the most satisfactory, immediate outcome is to use git's support for non-git remote version control systems, so you can keep the benefits locally, of being able to cheaply switch between feature branches and be able to rebase local changes for cleaner history. The most satisfactory outcome is use of git locally spreading through the development teams, until there's enough buy-in to use it as the server too.
|
|
#
?
Jun 17, 2015 23:09
|
|
only
|
Ithaqua posted:Pushing DVCS on a team that's not interested in using a DVCS is a good way to make that team miserable. I see it all the time from companies where someone in management starts cargo culting and forces a switch to Git, when everyone is perfectly happy and productive using SVN or some other CVCS. Then everyone tries to use a DVCS like a CVCS and it sucks really badly. I worked at a company where all of the server admins (who managed the code repositories) wanted to swtich to Git, and all of the programmers wanted to stick with SVN. The Boss (I forget her middle management title) asked the server admins why they cared seeing as how they never committed any code, and the server admins said something to the effect of "Git is cool." We stayed with SVN. My next job used Git and I've come to appreciate it, but the cargo cult is annoying. One of my co-workers told me that I should read a 300 page book about Git so that I could get the most out of it. gently caress that poo poo.
|
|
#
?
Jun 17, 2015 23:26
|
|
loinburger posted:My next job used Git and I've come to appreciate it, but the cargo cult is annoying. https://en.wikipedia.org/wiki/Cargo_cult
|
|
|
#
?
Jun 18, 2015 05:25
|
|
|
https://en.wikipedia.org/wiki/Cargo_cult_programming
|
|
#
?
Jun 18, 2015 05:45
|
|
|
What you described seems to be the opposite of cargo cult. You were talking about someone who was ridiculously well informed about the application and how to use it, and not someone who emulates design patterns without knowing their purpose.
|
|
#
?
Jun 18, 2015 05:52
|
|
|
Me and the other programmers used about a half dozen Git commands, and things were working fine. We hired this new guy who wanted all of us to use ALL of the commands all of the time, just because - no value added, just "Git is cool." If he'd been well informed about the program and not just a fan boy then he'd have suggested we add a few more commands to our repertoire and deprecate a few others, nothing more (at least not right away).
loinburger fucked around with this message at 05:59 on Jun 18, 2015 |
|
#
?
Jun 18, 2015 05:57
|
|
|
TheresaJayne posted:What made me laugh was "at midnight dec 31st 1999 any plane in the air will suddenly turn off , and baby incubators and heart lung machines will stop working because they will think its 1900 and they didnt exist then so cannot continue to work" You say that, but Dad was in charge of testing Y2K preparedness for IBM fabs. He completely bricked some ridiculously expensive equipment by setting the date forward - it simply wouldn't boot again. Didn't see him a whole lot that week, as he was coordinating with the vendor to get a fix created and tested so they could roll it out everywhere. I think the bricked unit ended up needing a board replacement to turn back on (with corrected firmware on it) but it's been nearly 20 years and I don't remember exactly. I mean, they found it before the entire line died, and got a fix before the rollover, but Y2K wasn't just a matter of some incorrect reports. Everyone thinks it wasn't a big deal, but a whole lot of people worked their asses off to make sure it wasn't. ErIog posted:The tragedy of Y2K is that it was handled too well, and so people erroneously assumed it hadn't ever been a real problem. A pound of prevention is wasted effort. 
|
|
#
?
Jun 18, 2015 08:59
|
|
|
Harik posted:You say that, but Dad was in charge of testing Y2K preparedness for IBM fabs. He completely bricked some ridiculously expensive equipment by setting the date forward - it simply wouldn't boot again. Didn't see him a whole lot that week, as he was coordinating with the vendor to get a fix created and tested so they could roll it out everywhere. I think the bricked unit ended up needing a board replacement to turn back on (with corrected firmware on it) but it's been nearly 20 years and I don't remember exactly. It was more that some people believed that as soon as the clock read 1900 the system would believe that it hadn't been invented and would therefore stop.
|
|
#
?
Jun 18, 2015 09:03
|
|
|
TheresaJayne posted:It was more that some people believed that as soon as the clock read 1900 the system would believe that it hadn't been invented and would therefore stop. No one thought this.
|
|
#
?
Jun 18, 2015 13:11
|
|
|
comedyblissoption posted:if you can get over torvald's arrogance he starts a discussion about the problems that branching is trying to solve in git: Holy lord, Linux Torvalds is insufferable
|
|
#
?
Jun 18, 2015 13:23
|
|
|
Slash posted:No one thought this. Have you met non-technical people? LeftistMuslimObama posted:Education horror the third. I'm now taking Intro to Algorithms. The lecturer assumed we would all have taken discrete math, but all the students work at my employer and our employer doesn't let us take discrete math. "Do this thing that requires a solid foundation of how to do proper logical proofs. Don't worry about being able to do proper logical proofs though we don't want to pay for that." I recommend finding an explanation of Proof by Induction that you can wrap your head around and then memorize that poo poo. Finally, I'm sure this isn't a "horror" per se, but it's certainly triggering me. code:
|
|
#
?
Jun 18, 2015 14:19
|
|
|
ChickenWing posted:Have you met non-technical people? Perhaps unsurprisingly, most non-technical people were more interested in whether their grandmother's life support system was going to stop working than whether it was going to "believe that it hadn't been invented".
|
|
#
?
Jun 18, 2015 14:28
|
|
|
Dr. Stab posted:What you described seems to be the opposite of cargo cult. You were talking about someone who was ridiculously well informed about the application and how to use it, and not someone who emulates design patterns without knowing their purpose. How were the sysadmins in the story well informed?
|
|
#
?
Jun 18, 2015 14:43
|
|
|
ChickenWing posted:
I see a fair amount of null != value checks in Microsoft's .NET Reference Source (e.g. StringBuilder.cs) and it always slightly bugs me.
|
|
#
?
Jun 18, 2015 15:02
|
|
|
ChickenWing posted:Have you met non-technical people? 
|
|
#
?
Jun 18, 2015 15:30
|
|
|
Any language that lets you accidentally use = instead of == without at least a warning is a bad language.
|
|
#
?
Jun 18, 2015 15:39
|
|
|
Manslaughter posted:Any language that lets you accidentally use = instead of == without at least a warning is a bad language. It's a feature of the compiler, not of the language. "accept".equals([redacted]) doesn't even look odd but then again I regularly write python where stuff like "".join(list) is normal.
|
|
#
?
Jun 18, 2015 16:07
|
|
|
"accept".equals([redacted]) also stops potential NullPointerExceptions
|
|
#
?
Jun 18, 2015 16:13
|
|
|
Hughlander posted:How were the sysadmins in the story well informed? That was in the previous paragraph where he was talking about his old job. "Cargo Cult" was being used to refer to the person who felt that you should read a 300 page book to get the most out of git.
|
|
#
?
Jun 18, 2015 16:18
|
|
|
|
| # ? May 17, 2024 16:24 |
|
|
ChickenWing posted:variable goes on the left aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa It's called Yoda notation.
|
|
#
?
Jun 18, 2015 17:03
|
|
