|
The cherry on top for me is two people there had used git before, but NEVER DID ANY VERSIONING WITH IT AT ALL, and only one had actually done a merge. loving everyone flips their poo poo about actually doing version control in git. I cannot fathom this, even though I see it everywhere I look. Is "why does revert make new commit I thought it go back" why?JewKiller 3000 posted:every time i see one of those talks, it just further reinforces my belief that git is for people who really like version control
|
# ? Jan 15, 2015 05:12 |
|
|
# ? May 27, 2024 04:15 |
|
whats the deal with people spending a bunch of time with git rebasing stuff to get nice looking commits? what;s the point, it seems like a lot of effort to obfuscate stuff in a clever way
|
# ? Jan 15, 2015 05:28 |
|
they want to rewrite their commit history before pushing it, to
|
# ? Jan 15, 2015 05:31 |
|
JewKiller 3000 posted:they want to rewrite their commit history before pushing it, to
|
# ? Jan 15, 2015 05:32 |
|
JewKiller 3000 posted:every time i see one of those talks, it just further reinforces my belief that git is for people who really like version control and want to dedicate a few hours per week to it. makes sense if you're linus, but most developers don't want (and shouldn't need) to know git details beyond "here's a translation chart for the subversion command set, go nuts! btw branching works now" branching always worked in svn. if you have a tool that will automatically merge things line-by-line then svn starts to be the same as git except with weird history issues in corner cases, and a far more normal command set, workflow and mental model. fart simpson posted:whats the deal with people spending a bunch of time with git rebasing stuff to get nice looking commits? what;s the point, it seems like a lot of effort to obfuscate stuff in a clever way I sat through an hour long brown bag of some insufferable nerd talking about how to craft your commits so the version history ~tells the story of your software~
|
# ? Jan 15, 2015 05:41 |
|
Notorious b.s.d. posted:if you need a very specific artifact, you have an artifact repository containing every artifact you have ever built sometimes its ok to have binaries in your version control. A specific jdk is a great example of a binary that is completely reasonable to commit, because now your build scripts are self-contained and don't have to do some hosed up curl thing out to the oracle website to get the jdk they need - they just check out the right version and whoosh
|
# ? Jan 15, 2015 05:43 |
|
this doesn't even touch the issue that oracle is under no compulsion to continue to publicly host every jdk version ever
|
# ? Jan 15, 2015 05:46 |
|
fart simpson posted:what if i call it version control instead of source control, then can i check my binaries in? hobbesmaster posted:what if the artifacts are binaries this is what artifact repositories are for put source in the source repo put artifacts in the artifact store
|
# ? Jan 15, 2015 05:47 |
|
rotor posted:sometimes its ok to have binaries in your version control. A specific jdk is a great example of a binary that is completely reasonable to commit, because now your build scripts are self-contained and don't have to do some hosed up curl thing out to the oracle website to get the jdk they need - they just check out the right version and whoosh or i could get rpms from oracle and put them in package repositories where they can be managed as versioned binaries, as intended by oracle nah that would be too easy
|
# ? Jan 15, 2015 05:47 |
|
JewKiller 3000 posted:every time i see one of those talks, it just further reinforces my belief that git is for people who really like version control and want to dedicate a few hours per week to it. makes sense if you're linus, but most developers don't want (and shouldn't need) to know git details beyond "here's a translation chart for the subversion command set, go nuts! btw branching works now" even if you only use git as a straight-up svn replacement, it's still better because it's distributed committing locally and then moving commits from client to server is just a better model. even if you end up with a workflow that looks a lot like svn it makes your life easier.
|
# ? Jan 15, 2015 05:49 |
|
Notorious b.s.d. posted:or i could get rpms from oracle and put them in package repositories where they can be managed as versioned binaries, as intended by oracle i dont really understand the big fussy distinction between keeping a local rpm repo and keeping a local svn repo with rpms in them but idk man whatever, as long as you bring all your dependencies in-house I'm cool.
|
# ? Jan 15, 2015 05:49 |
|
Notorious b.s.d. posted:even if you only use git as a straight-up svn replacement, it's still better because it's distributed nope. quote:committing locally and then moving commits from client to server is just a better model. uh-uh quote:even if you end up with a workflow that looks a lot like svn it makes your life easier. disagree
|
# ? Jan 15, 2015 05:50 |
|
rotor posted:look at me i'm old and reject change
|
# ? Jan 15, 2015 05:54 |
|
b0lt posted:look at me I'm a dumbass who just does what Linus does without any consideration to why he does it
|
# ? Jan 15, 2015 06:05 |
|
Notorious b.s.d. posted:even if you only use git as a straight-up svn replacement, it's still better because it's distributed i don't really care to evangelize git but this is the explanation that makes the most sense to me, so it's the one i use say you check out a copy of some developer's svn repo, and you make some changes to be more needs-suiting. you want to commit these changes, because version control is good right? but you don't have commit privs and the developer isn't around to give them to you (or won't), now what smart guy?
|
# ? Jan 15, 2015 06:08 |
|
Use SVN, use git, use mercurial, use whatever as long as you use some revision control that isn't this piece of poo poo we use for some stuff at work: http://www.truebluesoftware.com/
|
# ? Jan 15, 2015 06:10 |
|
yeah git is great for that but I don't really do that very often and I suspect that outside open source development it's very uncommon
|
# ? Jan 15, 2015 06:10 |
|
rotor posted:sometimes its ok to have binaries in your version control. A specific jdk is a great example of a binary that is completely reasonable to commit, because now your build scripts are self-contained and don't have to do some hosed up curl thing out to the oracle website to get the jdk they need - they just check out the right version and whoosh ask me about a maven build dying today because apache stopped hosting ojbdc6_g.jar or whatever, christ, loving java
|
# ? Jan 15, 2015 06:10 |
|
inside a LAN working on commercial software local commits are just busywork to make people think there Implementing Best Practices
|
# ? Jan 15, 2015 06:12 |
|
Space Whale posted:At a job I've been at a week and a day I did a hour long presentation on intro to git, since our architect decided to move to git and he's 4 hours away, and I'm the guy in the office teaching people the verbs and work flows and helping set poo poo up and fixing merges. Either that, or I just jabbered on for a loving hour and used that d3 visualization tool to lure people into the pit of hell. why not both?
|
# ? Jan 15, 2015 06:12 |
|
Notorious b.s.d. posted:or i could get rpms from oracle and put them in package repositories where they can be managed as versioned binaries, as intended by oracle you can't keep binaries in version control! you need to set up a repository of binary versions, that's what you have to do rotor, God, everyone knows that!!
|
# ? Jan 15, 2015 06:14 |
|
rotor posted:you can't keep binaries in version control! you need to set up a repository of binary versions, that's what you have to do rotor, God, everyone knows that!! the artifact store strictly requires semantic versioning revision control just tracks commits Ignoring the software design (diffing, efficient storage of blobs) these categories are still really different
|
# ? Jan 15, 2015 06:18 |
|
please explain the meaningful difference between the two in the context of "I need a particular jdk to build this revision of my product"
|
# ? Jan 15, 2015 06:24 |
|
i was typing up a carepost but then i realised it doesnt really matter.
|
# ? Jan 15, 2015 06:25 |
|
store your artifacts for the love of god but idgaf how u do it
|
# ? Jan 15, 2015 06:26 |
|
bobbilljim posted:store your artifacts for the love of god but idgaf how u do it
|
# ? Jan 15, 2015 06:27 |
|
what version control do i use if my workflow looks like this: check out the latest version from master write some code merge with any changes that might've happened in master in the meantime check in my code in visual studio with tfs it was very simple but i feel like git gives you a bunch of things to gently caress yourself up with. But I have only used the shittiest janky diff tools when merging with git. I'm not sure how to step my game up/improve my software development experience. I need to be able to at least use git with a minimum level of competence even if I use something else for my own projects. It's too common.
|
# ? Jan 15, 2015 06:41 |
|
So while the grownups are fighting I want to remind everyone that almost everyone I know in person who uses git freaks the gently caress out about actually using it for version control by doing any kind of rollback. What the gently caress is wrong with people? What's wrong with git that most people merge and branch and do their magical cargo cult poo poo in the CLI or use sourcetree, but everyone just flips out about actually doing a rollback?
|
# ? Jan 15, 2015 06:45 |
|
fleshweasel posted:what version control do i use if my workflow looks like this: Just pull master onto your branch? Or just pull your local master and merge that into your local branch and the keep truckin'? I guess you can rebase if you really want to get Linus points.
|
# ? Jan 15, 2015 06:48 |
|
Space Whale posted:So while the grownups are fighting I want to remind everyone that almost everyone I know in person who uses git freaks the gently caress out about actually using it for version control by doing any kind of rollback. i use git and i always kinda figured being able to do a rollback was kinda the point of using a vcs in the first place
|
# ? Jan 15, 2015 06:49 |
|
Stringent posted:i use git and i always kinda figured being able to do a rollback was kinda the point of using a vcs in the first place Well, yeah. Can you? Did it have a terrible learning curve? Do other people you know have difficulty with reverts? I don't mean how stupid reverting merges can be, I mean just a straight a-b-c' I want to go back to a with a revert commit so a-b-c-d' where d is the new HEAD and it's the state that a used to be kind of thing.
|
# ? Jan 15, 2015 06:51 |
|
Space Whale posted:Well, yeah. Can you? Did it have a terrible learning curve? Do other people you know have difficulty with reverts? had no idea it was a problem
|
# ? Jan 15, 2015 06:54 |
|
Stringent posted:had no idea it was a problem It is here. OTOH I live in farty fart ding dong town.
|
# ? Jan 15, 2015 06:54 |
|
*tussles rotors hair and pats him on the back of the head*
|
# ? Jan 15, 2015 06:59 |
|
rotor posted:please explain the meaningful difference between the two in the context of "I need a particular jdk to build this revision of my product" if you use git to store binaries by default it will transfer all the binaries you've ever stored each time somebody clones the repo
|
# ? Jan 15, 2015 07:03 |
|
there's no real consensus on whether late or early binding for building packages is really what you want in a corporate environment. when you're small you probably aren't worried about this, but when you get big enough (hundreds of developers) you're going to have to decide which you want
|
# ? Jan 15, 2015 07:06 |
|
it's true that sunspots could cause scheduling changes and expose a memory barrier error in your compiler or whatever. I've been responsible for software shipped to roughly a billion people, and have never to my knowledge encountered a situation where the clock speed of the system on which the software was built caused a difference in the result. nor have I found a case in which the presence or absence of a MIDI controller was relevant to the reproducibility of builds. I have routinely had build servers selected at random from sets which I knew full well contained hard drives from different manufacturers, or were installed with their primary axis aligned with different prevailing winds. you may find that you have more stringent reproducibility requirements than I did, or than Microsoft does. if so, you will want to do more than save mere toolchain elements, not argue against that meager start. if you want to verify that things are reproducible then there are many fine hash algorithms to assist you -- if you trust the hash implementation to work when the network card is in another PCI slot.
|
# ? Jan 15, 2015 07:12 |
|
Subjunctive posted:I've been responsible for software shipped to roughly a billion browsers, and have never to my knowledge encountered a situation where anything important happened
|
# ? Jan 15, 2015 07:16 |
|
Brain Candy posted:if you use git to store binaries by default it will transfer all the binaries you've ever stored each time somebody clones the repo who wants to play the "guess what rotor will say" game?
|
# ? Jan 15, 2015 07:20 |
|
|
# ? May 27, 2024 04:15 |
|
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 ??
|
# ? Jan 15, 2015 07:21 |