|
Boris Galerkin posted:On the subject of gitlab, does anyone have any experience with setting up a doxygen branch to host the doxygen generated files? We have no documentation in our code right now and my supervisor doesn't really believe in it (we're a research group comprised of non-programmers other than me and my supervisor thinks it's a good exercise for all his phd students to figure out what the gently caress poo poo like "eocs = 0.9887342" comes from or even means). I'm doing a rewrite of the entire code we use (changing backend libraries) and I figured gently caress it, I'm going to document everything the way god intended and grabbed Doxygen, but it's not really feasible to track the doxygen generated folder since everything changes so much. Not gitlab specific advice... Treat the output docs as a build artifact, doesn't need to be in source control. Have some job on CI or a schedule or whatever run that builds and publishes docs to a static site anyone can browse.
|
#
?
Aug 16, 2016 12:11
|
|
|
|
| # ? May 12, 2024 17:50 |
|
|
Gounads posted:Not gitlab specific advice... Treat the output docs as a build artifact, doesn't need to be in source control. Have some job on CI or a schedule or whatever run that builds and publishes docs to a static site anyone can browse. On a related note, we've had great luck with using a CI task to build docs and publish to a gh-pages branch. By policy we prevent anything other than the CI job from touching that branch. This gives us the advantage of tracking changes to docs along with tagged releases which is pretty helpful when putting together formal changelogs and also lets us host docs on github pages.
|
|
#
?
Aug 16, 2016 14:18
|
|
|
I'm coming up on my senior year, currently working an internship at a company who doesn't use any sort of VC, and have for the most part never actually used it myself. They've recently decided to extend out my contract to keep me around working on a pretty large project and I'm starting to feel like learning to use VC is about to be mandatory for the success of this project. Of course since no one here uses it I don't have any options currently available on my workstation so I'm going to have to go through management and IT to get it installed. They're usually cool with me introducing new stuff into the work place as long as I can justify it and sort of show them how to use it. This is a team of engineers who have been working primarily with fortran and smalltalk for the last 30 years and can't understand why anyone would bother migrating to anything else -- who balked at me when I suggested we at least attempt to start implementing jQuery on their barebones apache/cgi webserver that hosts the majority of their data visualizations after the 100th time someone inside the company asked for a table with floating headers because html tables that span 100 rows get confusing when you start to scroll down and to the right. That being said since I have to consider stuff like licensing and ease of teaching them what I'm doing, is there a particular platform I should choose to give myself the least amount of headaches? The alternative at this point is refactoring the code base of and implementing a new UI for a program that is about 30k lines of code with no version control and I feel like that will eventually be the largest headache of all.
|
|
#
?
Aug 17, 2016 15:42
|
|
|
I only really have a good amount of experience with TFVC/TFS and git, but good christ, no VC? How do they propagate code changes currently? The least you could do, if nothing else, is start your own local git repo to track changes. It's free and fairly simple if you're comfortable with the command line. And if you like how it works, you can set up a server to mirror what you already have done and get people working from it. Also it's relatively simple to do automation work with git+shell scripting. As far as getting other people on board, it might be best to find something that somewhat matches your current workflow and the skill/enthusiasm level of the team. Git is fairly flexible, but a lot of people have trouble with it because of the CLI and myriad of terminology and options. I introduced git to the team comprised of mostly older engineers that I work with and it has been pretty painful to get them to really work with it and understand how useful it can be, but we also use TFVC for the more active part of our codebase - a lot of the devs just want to check in their code easily, and even though all of our systems are Linux-based, most still want to use a GUI tool that integrates with Eclipse (which git has, but drat if any of them learn to use it on their own). TFS or another centralized vcs would probably be simpler as an intro to version control. TFS is not free but also has the benefit of being an "enterprise solution" which might make management types happy if they're into buying stuff. Despite the confusion of people surrounding git though, it would still be my first recommendation, assuming you don't have any super large files that you want to track.
|
|
#
?
Aug 17, 2016 16:55
|
|
|
Git's terminal UI is unbelievably awful, and it's probably not a great choice for introducing version control to people who have zero experience with anything of the kind. Even the various GUIs aren't too much help, especially if you gently caress up anything involving a rebase. I'd look into Mercurial (which has a pretty nice intro guide starting from "I've never used VCS before" levels). The CLI is much, much more intuitive than git, and there's no history editing (by default) so it's harder to shoot yourself in the foot. Whatever you choose, spend some time learning it yourself first (including forcing merge conflicts and practicing resolving them!) so you can help people out before you introduce it to your team. Git does have advantages though - there's a lot more resources and tooling around it. It's what basically everybody uses, so it's easy to find help and training resources. Literally anything will be an improvement over what you have now, so don't sweat it too much.
|
|
#
?
Aug 17, 2016 17:48
|
|
|
A large technical organization that writes a lot of code that doesn't use version control ityool 2016 should raise a lot of red flags. The red flags are enormous enough to consider if you really want to continue working there and not seek employment elsewhere. If you seriously have to argue with coworkers and management to make a case for it and there are a bunch of people that have been working there for years before you and they're still not using version control, you really have to question the organization's technical leadership. If you decide to use git and you use windows, I would recommend using the sourcetree git gui client. The other gui alternative is git extensions. You'll still need some familiarity with the CLI for stuff the gui doesn't do. comedyblissoption fucked around with this message at 04:39 on Aug 18, 2016 |
|
#
?
Aug 18, 2016 04:26
|
|
|
Also don't feel bad about not really knowing much about version control. I didn't really know much about it in college, but it was easy to pick up after. However, you should know that sane, modern professional software development uses source control and anyone who contests otherwise is incompetent or ignorant.
|
|
#
?
Aug 18, 2016 07:27
|
|
|
comedyblissoption posted:However, you should know that sane, modern professional software development uses source control and anyone who contests otherwise is incompetent or ignorant. It's crazy this even needs to be said, but yeah. 100%.
|
|
#
?
Aug 18, 2016 14:33
|
|
|
My nemesis guy is dead set against source control and always tells me that at IBM nobody ever used it when he worked there in the mid-2000s and anyone who did use it was an idiot. "If you think you know better than IBM, why don't you go work there and then you can talk to me about how to properly do software development"
|
|
#
?
Aug 18, 2016 14:55
|
|
|
Data Graham posted:My nemesis guy is dead set against source control and always tells me that at IBM nobody ever used it when he worked there in the mid-2000s and anyone who did use it was an idiot. "If you think you know better than IBM, why don't you go work there and then you can talk to me about how to properly do software development" I'm sorry that you work at a company who would hire that guy.
|
|
#
?
Aug 18, 2016 15:05
|
|
|
Joke's on me because it's my own company (and his)  It's my cross to bear though, he leaves all the dev to me; he just owns the infrastructure and deployment process and refuses to let anyone tell him how to do it. I just have to adapt to whatever will make him least mad
|
|
#
?
Aug 18, 2016 15:10
|
|
|
If you think you know better than IBM, why would you go work there? e: sorry, condolences taqueso fucked around with this message at 15:27 on Aug 18, 2016 |
|
#
?
Aug 18, 2016 15:23
|
|
|
Arcsech posted:and there's no history editing (by default) Except for branch pointers or doing something really horrible with the plumbing commands, git does not have history editing either
|
|
#
?
Aug 18, 2016 19:46
|
|
|
Series DD Funding posted:Except for branch pointers or doing something really horrible with the plumbing commands, git does not have history editing either Are you counting git replace as plumbing then?
|
|
#
?
Aug 18, 2016 19:48
|
|
only
|
If IBM knows so much about software development, why have they had all those huge layoffs.
|
|
#
?
Aug 18, 2016 19:55
|
|
|
Series DD Funding posted:Except for branch pointers or doing something really horrible with the plumbing commands, git does not have history editing either Isn't history-editing basically what things like rebase, cherry-pick, and hell, amend are? Or are we on a definition of "history editing" I'm not cognizant of
|
|
#
?
Aug 18, 2016 20:14
|
|
|
Ciaphas posted:Isn't history-editing basically what things like rebase, cherry-pick, and hell, amend are? Or are we on a definition of "history editing" I'm not cognizant of Series DD Funding is arguing that since git commits are immutable, merely changing what history a branch pointer refers to is not "editing the history" of that branch, in defiance of how everyone else, including git's official documentation, uses the term. In practice, cherry-pick is not history editing (it creates a new commit based on an existing commit somewhere else), but rebase, amend, and filter-branch all are, and come with the same warnings around editing history that has already been pushed to public repos.
|
|
#
?
Aug 18, 2016 20:19
|
|
|
Ciaphas posted:Isn't history-editing basically what things like rebase, cherry-pick, and hell, amend are? Or are we on a definition of "history editing" I'm not cognizant of Rebase etc. create a new history and point the branch to that, but the old one is still there.
|
|
#
?
Aug 18, 2016 20:19
|
|
|
Data Graham posted:My nemesis guy is dead set against source control and always tells me that at IBM nobody ever used it when he worked there in the mid-2000s and anyone who did use it was an idiot. "If you think you know better than IBM, why don't you go work there and then you can talk to me about how to properly do software development" And yet IBM purchased Rational ClearCase in 2003 Tho I suppose you could make the argument that you'd have to be an idiot to use it
|
|
#
?
Aug 18, 2016 20:19
|
|
|
Plorkyeran posted:Rebase etc. create a new history and point the branch to that, but the old one is still there. Ah, ok, didn't occur to me they were speaking in that sense. (e: and fair enough about cherry-pick, it's early and i wasn't thinking) also i used clearcase for 8 years here and only just got our org to move off of it onto something else, it is now my trigger word Ciaphas fucked around with this message at 20:38 on Aug 18, 2016 |
|
#
?
Aug 18, 2016 20:34
|
|
|
ToxicFrog posted:Series DD Funding is arguing that since git commits are immutable, merely changing what history a branch pointer refers to is not "editing the history" of that branch, in defiance of how everyone else, including git's official documentation, uses the term. I don't know what the git docs say but the difference is more than just semantic. Knowing that "rewritten" commits still exist makes it easier to do complex branch edits.
|
|
#
?
Aug 18, 2016 22:57
|
|
|
Series DD Funding posted:I don't know what the git docs say but the difference is more than just semantic. Knowing that "rewritten" commits still exist makes it easier to do complex branch edits. Yeah, you can get the original back, which is great. But my original point was that if you don't know what you're doing (see: team that has never used any form of version control), unfucking a bad rebase is not the easiest thing ever, and even if you do know what you're doing, the commands are kind of arcane. Better to just use a simpler tool that won't let them shoot themselves in the foot (as easily), given the state of the team in question.
|
|
#
?
Aug 18, 2016 23:10
|
|
|
Arcsech posted:Yeah, you can get the original back, which is great. But my original point was that if you don't know what you're doing (see: team that has never used any form of version control), unfucking a bad rebase is not the easiest thing ever, and even if you do know what you're doing, the commands are kind of arcane. Better to just use a simpler tool that won't let them shoot themselves in the foot (as easily), given the state of the team in question. Though it's comforting to know that worst-case you can unfuck things without any commands at all. Open the reflog in a text editor, find the ID from before you broke it, copy into branch file.
|
|
#
?
Aug 19, 2016 06:03
|
|
|
comedyblissoption posted:A large technical organization that writes a lot of code that doesn't use version control ityool 2016 should raise a lot of red flags. The red flags are enormous enough to consider if you really want to continue working there and not seek employment elsewhere. If you seriously have to argue with coworkers and management to make a case for it and there are a bunch of people that have been working there for years before you and they're still not using version control, you really have to question the organization's technical leadership. This is the R&D department of a particular alloy manufacturing company who's pride and joy is talking about the fact that most of our running equipment was built in the 1800's. We have an entire IT/BA department, but due to the fact that R&D feels like they need to option of making instant changes to all of their personally maintained code and databases a sort of schism occurred about a decade ago and the result is that IT basically said 'do whatever the gently caress you want just don't come to us for support on anything period.' R&D has no CS majors in the department so everything has basically been hacked together with the occasional contractor hire who they rely on less and less because 'they always come in and write code we can't understand and therefore can't maintain.' Their method of VC is a folder called backup that they obviously just copy old version into when they remember. There are red flags all over the place and I'm not planning on staying full time when/if they offer me the contract after I graduate. I took the extension on the internship simply because the alternative was working some work study job at school and I recognize that even if the work environment is not at all conducive to developing proper SE skills, the fact that I'm heading up a project of this scale almost entirely autonomously as a non-graduated intern is obviously going to be a learning opportunity/resume material that would be pretty dumb for me to pass over. Other noteable things that make me cry: A ton of their internal products revolve around web based data visualization linked to multiple databases. They refuse to use any tech stack other than cgi/python and after looking into MVC development considered it to be entirely pointless when they can just copy paste code to another .py file despite the fact that almost everything they do could simply be ported into a model-view format and save countless hours of having to manually propagate changes to 20 different html/py files every time an internal change request comes in. All of their databases don't use foreign keys or indexes at all because they, again, don't see the point of making things 'overly complicated' when they always just have the option of making another table and then writing a python script that will query the existing tables and repopulate the new ones for each new product they put out and then just run that script as a background service every 2 minutes. It's extremely common for them to need to add columns so shutting down entire tables, and then repopulating millions of table rows is a regular occurrence. Speaking of databases, they generate thousands of rows an hour on some of their tables, have no data center, and refuse to use AWS or similar services and of course have no plan for future expansion. The plus side? I'm a junior year intern with a ridiculous amount of autonomous authority about how I implement my projects and regularly look poo poo hot when doing extremely simple tasks, and I'm treated like a human being/full fledged member of the team rather than a coffee bitch so as long as I can keep producing through my contract I know for sure I'll leave here with great recommendations and a lot to talk about at my next interview.
|
|
#
?
Aug 19, 2016 08:52
|
|
|
Ah yes, I love databases where the data is baked into the schema. "Another customer? Well, we only have columns that make sense for this customer. No problem, just add more columns! dumbasscorp_client_id int not null ..."
|
|
#
?
Aug 19, 2016 12:31
|
|
|
Data Graham posted:My nemesis guy is dead set against source control and always tells me that at IBM nobody ever used it when he worked there in the mid-2000s and anyone who did use it was an idiot. "If you think you know better than IBM, why don't you go work there and then you can talk to me about how to properly do software development" Ask if he's ever heard of the IBM product https://en.wikipedia.org/wiki/Rational_ClearCase They're so dead set against it they own their own! EDIT: Beaten drat it!
|
|
#
?
Aug 19, 2016 16:55
|
|
|
To be fair if my choices were clearcase or nothing I'd... well, I'd choose clearcase but I'd think about it for a long time, I promise that much
|
|
#
?
Aug 19, 2016 18:41
|
|
|
Data Graham posted:My nemesis guy is dead set against source control and always tells me that at IBM nobody ever used it when he worked there in the mid-2000s and anyone who did use it was an idiot. "If you think you know better than IBM, why don't you go work there and then you can talk to me about how to properly do software development" i worked at ibm in the mid-2000s and i can assure you they had been using source control (or "change management" and "version control" were the internal terms) for decades before..
|
|
#
?
Aug 21, 2016 12:17
|
|
|
Gul Banana posted:i worked at ibm in the mid-2000s and i can assure you they had been using source control (or "change management" and "version control" were the internal terms) for decades before.. Moreover, IBM is a source control system vendor. It sells multiple source control products that compete with each other (e.g. Clearcase, Synergy, Team Concert, ClearQuest. )
|
|
#
?
Aug 21, 2016 14:50
|
|
|
Gul Banana posted:i worked at ibm in the mid-2000s and i can assure you they had been using source control (or "change management" and "version control" were the internal terms) for decades before.. Your words are like balm to my soul.
|
|
#
?
Aug 22, 2016 05:12
|
|
|
I have a very stupid newbie question. In my software engineering class, we are doing a project which is our first introduction to version control as a class. I am somewhat familiar with git and github, but I still screw stuff up constantly. The assignment is simple: everyone in the class will add a file containing 2 printf functions, and then add lines calling those functions to a file, and update the Makefile. It's a disaster, because most of these people have never used git or github at all before and everyone is just constantly breaking everything. These were the instructions: (pull master and branch it) 1. Result conflicts ? Then fix them 2. Does is build OK? [sic] 3. Merge your branch into master 4. Does is build OK? 5. YES: Commit and Push 6. NO: Resolve issues, Commit and Push master 7. Switch to your branch and Push So I got my branch done, pulled a fresh master, merged, fixed all the conflicts, and repushed it. It all seemed to work great. I didn't break master. So I'm on step 7, and I git checkout <mybranch> git push origin <mybranch> and I get ! [rejected] <mybranch>-> <mybranch>(non-fast-forward) error: failed to push some refs to '<url>' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Uh. So i screwed up, and didn't pull before fixing everything on my branch... I did work on this project yesterday and probably pushed up a broken version of my branch, without worrying about it because it was on my branch so it wasn't going to mess anyone else up. Now I don't know how to fix this. I mean, I can mess around with it, but I'm sure the idea is that my branch shouldn't end up ahead of master once I've merged it and it's done. Any idea what a good way to resolve this is?
|
|
#
?
Aug 30, 2016 00:08
|
|
|
Just git pull, like it suggests? That's normally no problem, just means someone else has checked something into master while you were working on it. Happens more often than not.
|
|
#
?
Aug 30, 2016 00:12
|
|
|
There's nothing wrong with your branch being ahead of master, unless you're like gonna get an F on the assignment for that or something. Worst case you can just pull your branch, resolve conflicts, then start the list over from 1 if you really want the last commit on your branch to be before your last (merge) commit on master.
|
|
#
?
Aug 30, 2016 00:14
|
|
|
Data Graham posted:Just git pull, like it suggests? It reads more like somehow Snak's origin/yourbranch got ahead of his local yourbranch, rather than master. Dunno how that happened, assuming no one else is supposed to be touching it.
|
|
#
?
Aug 30, 2016 00:16
|
|
|
Yeah I don't know. I just pulled and fixed it. Now I'm submitting my log files, and they are each like 47 pages, not sure they should be that long. But whatever. Thanks for the help, guys. I just hope the professor manages to get people to actually use version control for the rest of the class. This is like the 5th time I've "learned" how to use git, and I've never gotten a group to actually use it on a project. I think people's first experience with version control being this giant clusterfuck that they don't understand and feel like they have no control over is not conducive to them seeing why it's an important tool to use.
|
|
#
?
Aug 30, 2016 00:34
|
|
|
It would actually be pretty neat if every new developer could be subjected to some kind of scenario where it's made really really blindingly obvious how good a thing source control is and how much productivity/safety value you get for a teensy bit of extra effort that you'd probably welcome anyway as a way to punctuate and bookmark your work. Like maybe if programming classes made you have to pretend to have to simultaneously a) develop a major new feature and b) roll out a bug fix to production, and then c) go back to work on the new feature but incorporate the bug fix from b) into it And that's just with one person working on it; the twist could be that the bug fix is being done by someone else and you have to import it.
|
|
#
?
Aug 30, 2016 02:04
|
|
|
Looking for work flow suggestions... I deliver a project to a client as a private github repository. They clone the repository and make their own middling-to-significant changes to the project. Later I'm hired to come in and do some feature additions or whatever. My tendency is to just always deliver my feature changes on my own master and then they have to figure out how to merge those changes with their own changes. Of course this is as much about the contract and setting expectations, but for the purposes of this thread I'm wondering about the git side of it. What's the best/fairest/easiest/most-standard way to handle this workflow?
|
|
#
?
Aug 30, 2016 22:25
|
|
|
That sounds like a reasonable approach. Just try to keep it to one or a few commits so if they enter conflict hell it's not as bad.
|
|
#
?
Aug 30, 2016 23:03
|
|
|
So I'm still getting the hang of this... When my local copy of master gets behind the remote, it seems like that's when it's better to rebase my local to the remote, rather than merge them. Does that seem correct? Because most of my changes are on my local feature branch. When my local feature branch is working, I push it to my remote feature branch. Then I want to sync up my local master with remote master, merge my local feature into my local master, then push to the remote master. Rebasing my local master to the remote master seems cleaner and simpler than pulling (merging). Is this right?
|
|
#
?
Sep 1, 2016 22:59
|
|
|
|
| # ? May 12, 2024 17:50 |
|
|
Pretty much. The golden rule with rebases is to never ever ever rebase (or otherwise modify history) anything you've shared out. It's fine for pulling. In fact, there's a command line argument and a config option to make git pull do a rebase instead of a merge. Easy enough to do manually, though, via git fetch <remote> then, if your local branch is checked out, git rebase <remote>/<branch>
|
|
#
?
Sep 1, 2016 23:11
|
|