|
Gazpacho posted:I think the point is that if the tools are not loving up other people's systems but are loving up yours that points to a particular cause other than the tools. Macports and fink legitimately destroy systems. Homebrew is better, but only because it does less. I do all my development now on 'disposable' vms. Vagrant helps
|
#
?
Apr 17, 2013 17:33
|
|
|
|
| # ? May 14, 2024 07:33 |
|
|
JetsGuy posted:Anyway, after a quick look at the git website, it seems like it's a standalone version control program. Is this true? Is it any good?
|
|
#
?
Apr 17, 2013 17:37
|
|
|
Jethro posted:All your questions can be answered here. Here's a summary: "git is awesome, git is good, please use git like all coders should. mercurial is cool too." 
|
|
#
?
Apr 17, 2013 17:48
|
|
|
I finally got my work to switch to git from CVS and holy loving poo poo I forgot how much I hate CVS. Git is the loving tits. Use it, forever, on everything.  Unfortunately, now I've got like 30 old branches stored in separate folders that would be a pain to move into the new repo.
|
|
#
?
Apr 17, 2013 17:50
|
|
|
the talent deficit posted:Macports and fink legitimately destroy systems. I'm not an expert, but how can Macports screw up a system? My understanding was it stages everything to its own directory structure and builds everything (including most dependencies) from scratch. That seems pretty self-contained. Internet Janitor fucked around with this message at 18:02 on Apr 17, 2013 |
|
#
?
Apr 17, 2013 17:58
|
|
|
PrBacterio posted:I was just going to say. At my place of work we're using SVN, but I've (and only recently, too!) started using Mercurial for all of my private projects that I do at home, and I must say that it really is quite awesome. But the choice (in my case) for Mercurial over git was really quite arbitrary, due to my having it recommended by someone I know; if he had been a git user I'm sure it'd be git I'd be using now for that purpose The cool thing about git, and I don't know if Mercurial has this, is the use of git-svn for if you are stuck in a place that uses SVN. Checkout with git-svn, use git for your normal workflow, and then use git-svn to push the changes back to SVN.
|
|
#
?
Apr 17, 2013 18:00
|
|
|
Internet Janitor posted:I'm not an expert, but how can Macports screw up a system? My understanding was it stages everything to its own directory structure and builds everything (including most dependencies) from scratch. That seems pretty self-contained. Whenever people complain about it (or Homebrew) breaking something it is almost always because they don't really understand PATH and they now have multiple non-compatible versions of libraries or binaries where the macports version won't work with the system version and you start getting obtuse error messages. You can almost always solve this by nuking the folders Homebrew/Macports install to and trying again. Homebrew is a little better about this because it refuses to run as su or perform any operations outside its configured directory. This leads to problems when you have things that only work with one or the other or only with 32/64 bit versions of libraries and suddenly you have to start caring about the multiple libraries you have installed in different places, without any decent tools for dealing with it.
|
|
#
?
Apr 17, 2013 18:24
|
|
|
Microsoft even built support for Git into TFS2012. You can use Git for your source control, but still leverage all of the other TFS features, integrated nicely into the VS UI.
|
|
#
?
Apr 17, 2013 18:37
|
|
|
I apologize. My previous comment was too much like "Linux community support" sperging and not the right approach.
|
|
#
?
Apr 17, 2013 19:20
|
|
|
the talent deficit posted:Macports and fink legitimately destroy systems. Homebrew is better, but only because it does less. I do all my development now on 'disposable' vms. Vagrant helps This. Once you can checkin your project's entire environment config into git along with the source code and can stupidly easily spin up a VM with all your dependencies, it's amazingly liberating. I decided to wipe & reinstall my Mac when I got an SSD and it surprised me how much I really needed to "back up" anymore, really just my photos and music. My development work is all in Github or Bitbucket and I can quickly clone it and be back off to the races with a "vagrant up."
|
|
#
?
Apr 17, 2013 19:29
|
|
|
I clearly don't understand git. Probably because I'm using git-gui, but every time I restore my VM I find it's less hassle to just download a zip of my projects from github and replace the files on my VM (then do a force merge with github before I continue with any changes) than it is to try to get git-gui to do the equivalent of what the GitHub client for Windows & Mac calls "sync" (i.e. fetch the newest versions of everything from github). Obv, I don't understand git because I'm a retard.
|
|
#
?
Apr 17, 2013 19:41
|
|
|
ChickenOfTomorrow posted:I clearly don't understand git. I just use $ git pull --all  I think the problem here might be git-gui.
|
|
#
?
Apr 17, 2013 19:43
|
|
|
ChickenOfTomorrow posted:I clearly don't understand git. Zamujasa posted:I just use $ git pull --all The problem is git-gui. Some developer on it has a stick up their butt and refuses to put git pull into the GUI, which is (as far as I know) what the GitHub client does when you hit sync, instead forcing everyone to use git fetch origin; git merge origin/master, which is the same thing in almost every case but is more philosophically pure or something. Atlassian SourceTree is the best git GUI I've found by far (but is only win/mac, no linux sadly), and git-gui is rather terrible. Edit: the coding horror is programmers. All of us. Arcsech fucked around with this message at 20:04 on Apr 17, 2013 |
|
#
?
Apr 17, 2013 19:55
|
|
|
Arcsech posted:The problem is git-gui. Some developer on it has a stick up their butt and refuses to put git pull into the GUI, which is (as far as I know) what the GitHub client does when you hit sync, instead forcing everyone to use git fetch origin; git merge origin/master, which is the same thing in almost every case but is less philosophically pure or something. Jesus Christ. This sort of crap is why I hate *nix neckbeards.
|
|
#
?
Apr 17, 2013 19:57
|
|
|
And people like me. I always git fetch --all then git rebase origin/master master. On the upside, fetch works great with SourceTree since it updates the entire repo without affecting the checkout, and the rebase makes the commit graph cleaner.
|
|
#
?
Apr 17, 2013 20:21
|
|
|
Doctor w-rw-rw- posted:And people like me. I always git fetch --all then git rebase origin/master master. So, git pull --rebase?
|
|
#
?
Apr 17, 2013 20:51
|
|
|
yaoi prophet posted:So, git pull --rebase? If you have master based on origin/master and you do "git pull" or "git pull --rebase", it doesn't actually update the origin/master ref, which I found confusing.
|
|
#
?
Apr 17, 2013 22:45
|
|
|
Sailor_Spoon posted:Also, git is the best.  (I hate git.)
|
|
#
?
Apr 17, 2013 23:28
|
|
|
Thern posted:The cool thing about git, and I don't know if Mercurial has this, is the use of git-svn for if you are stuck in a place that uses SVN. There's also git-cvs if you're stuck someplace that still hasn't heard of SVN, and git-p4 if you're using Perforce. My new job uses P4, but using git on top of that is officially supported.  I'm actually finding that the combination of git for local development, with p4-backed collaboration tools for code review and annotation, to be better than either VCS on its own.evensevenone posted:branch isn't too bad, except that you have to checkout the branch you just made for some reason. Rebase makes perfect sense to me, and I think at least some of the confusion around reset and checkout (and revert) is because they have the same name as commands in SVN but do different things. That said, it certainly doesn't help that some of them seem to have multiple largely unrelated (from the user's perspective) uses. git reset is used to unstage uncommitted changes from the index and restage changes from a previous commit without touching the working tree and move HEAD around (and optionally adjust the index, working tree, or both to match the new HEAD). git checkout is used to switch branches and switch a commit without a branch and revert files in the working tree to the state they had in a previous commit or in HEAD (and has the same name as a totally unrelated SVN command). git rebase is used not to just graft branches to different points on the commit tree, but also do hardcore interactive history rewriting. Some of these make sense once you know how things work internally, but I'm not convinced all of them do.
|
|
#
?
Apr 17, 2013 23:56
|
|
|
Suspicious Dish posted:If you have master based on origin/master and you do "git pull" or "git pull --rebase", it doesn't actually update the origin/master ref, which I found confusing. Bare git pull does update all remote tracking branches for the remote that you're pulling from. It's git pull origin master that doesn't update the ref.
|
|
#
?
Apr 18, 2013 00:27
|
|
|
Lysidas posted:Bare git pull does update all remote tracking branches for the remote that you're pulling from. It's git pull origin master that doesn't update the ref. Aha, I second guessed myself because I thought what I said was more plausible. I still really don't understand it, but OK.
|
|
#
?
Apr 18, 2013 00:30
|
|
|
Doctor w-rw-rw- posted:And people like me. I always git fetch --all then git rebase origin/master master. I do this too, but mostly because I usually don't want to merge right now but I still want those patches, not because I oppose the philosophical impurity of using git pull or whatever.    
Volmarias fucked around with this message at 00:51 on Apr 18, 2013 |
|
#
?
Apr 18, 2013 00:49
|
|
|
Thanks for mentioning SourceTree; we've been using the default Windows client just ... just because really. And SourceTree is already worlds ahead I think.
|
|
#
?
Apr 18, 2013 01:15
|
|
|
Mercurial is mostly the same as git, especially if you include extensions, and is maybe a little easier to learn. I like it. As for Mac package management systems, after playing with all if them, I really do think MacPorts is the most mature and Brew the least. I like that Fink and MacPorts dump their stuff into special directories that you can remove with rm. Neither can break your system unless you configure them in a really weird and non-default way! For the most part, Macports only breaks itself when Apple updates the OS/Xcode. I don't like how Brew throws stuff into /usr/. Other stuff defaults to the same place.
|
|
#
?
Apr 18, 2013 02:01
|
|
|
I've mostly gotten used to git, but I still have to consult the progit book to remind myself how to do certain things. Mercurial subrepos are a billion times better than git submodules, though. Submodules can go gently caress themselves.
|
|
#
?
Apr 18, 2013 09:41
|
|
|
Doctor w-rw-rw- posted:Checkout is checkout. (though SourceTree makes it a joy to use)
|
|
#
?
Apr 18, 2013 14:07
|
|
|
Sagacity posted:This is precisely why it *is* confusing. Checkout means different things to different people. I'm not saying git can be perfectly usable once you know its quirks, but already there's been a page of discussion about all the various commands and so on. I don't think you can claim it is easy. Yah, I'm a bit baffled by the quote. "The commands literally could not be expressed simpler, in my mind" Really? There's no simpler way to express source control concepts than to have the same command mean "create a new branch" "Switch to a different branch" and "Reset this changed file"? If you have an intimate knowledge of the reflog why they're the same command makes sense, but even then I wouldn't say that checkout is the literally the simplest way they can be expressed.
|
|
#
?
Apr 18, 2013 14:19
|
|
|
Checkout is kind weird and it seems that it's had some random stuff grafted on to it just because it can. If all it did was switch to an existing branch/revision/tag/whatever it would make a lot of sense. But it's got random stuff like the -b flag that causes people to learn "this is how you create a branch", which then makes the whole thing make little sense. It would be much better if git-branch had a -c flag or something that said "Also checkout the branch you just created". The -p flag has a similar issue, really.
|
|
#
?
Apr 18, 2013 14:42
|
|
|
Jabor posted:Checkout is kind weird and it seems that it's had some random stuff grafted on to it just because it can. I was just thinking of it in terms of explaining git to someone who used p4 before the conversation would be roughly: "How do I make a new client-spec? Checkout. Ok, how do I swap from one to another? Checkout. Ok, how do I revert a file? Checkout."
|
|
#
?
Apr 18, 2013 14:47
|
|
|
Hughlander posted:Yah, I'm a bit baffled by the quote. "The commands literally could not be expressed simpler, in my mind" Really? There's no simpler way to express source control concepts than to have the same command mean "create a new branch" "Switch to a different branch" and "Reset this changed file"? If you have an intimate knowledge of the reflog why they're the same command makes sense, but even then I wouldn't say that checkout is the literally the simplest way they can be expressed. But git branch creates a branch. git checkout -b does a git branch then checks out a ref. I create branches with git branch, so according to my usage they are not redundant. Git checkout -b is a shortcut to do two things. One of those things is a checkout, one of those things is a branch. As for "switch to a different branch" and "reset this changed file", those aren't basic operations. Branches are a layer of abstraction on top of Git. Branches are just labels to parts of the DAG, where each node reflects the state of the codebase. The checkout command is a tool to read a node on the DAG and transition the working copy to that state. If you apply it to a file, it applies it to just that file. tl;dr: I don't create branches with git checkout, and both /switching branches/ and /resetting a file/ are the same thing - resetting state to a commit - but different in scope. evensevenone posted:Yeah the real problem is that git commands have no particular relationship to what one would reasonably assume that they do based on their names, or what those commands do on other vcs. evensevenone posted:branch isn't too bad, except that you have to checkout the branch you just made for some reason. [1]http://www.slideshare.net/chacon/getting-git, slide 67 [2]http://mercurial.selenic.com/wiki/GitConcepts - Git's words not mine, but I used hg for quite some time before I switched to git, and I agree EDIT: clarity, spelling Also, are we getting off-topic, or are we agan indulging in the "we are the horror" cycle? Though, frankly, the idea of most people using Git actually cargo-culting based off of some other DVCS instead of learning how it works is a horror. Doctor w-rw-rw- fucked around with this message at 03:05 on Apr 19, 2013 |
|
#
?
Apr 19, 2013 02:54
|
|
|
Welcome to the Unix command line.
|
|
#
?
Apr 19, 2013 03:36
|
|
|
Gazpacho posted:Welcome to the Unix command line. gently caress. You just put that in perspective for me. I'm too young to 
|
|
#
?
Apr 19, 2013 03:42
|
|
|
Doctor w-rw-rw- posted:Also, are we getting off-topic, or are we agan indulging in the "we are the horror" cycle? Though, frankly, the idea of most people using Git actually cargo-culting based off of some other DVCS instead of learning how it works is a horror.
|
|
#
?
Apr 19, 2013 04:14
|
|
|
Plorkyeran posted:I'm amazed by how many developers there are that use git on a daily basis yet don't bother to learn anything at all about it Some of us write PHP, all right
|
|
#
?
Apr 19, 2013 04:40
|
|
|
Doctor w-rw-rw- posted:Mercurial is simpler given a shallow understanding of your tools[2], but Git is intuitive if you actually learn Git rather than understand something else and try to adapt your understanding of Git to that world. This is kind of the opposite of what the word "intuitive" means. Anyway, I like git, I use it both for work and personal projects. My employer's git workflow works really well for us and mixes well with . And I agree with you, to use it you have to understand the underlying data model and what each of the commands does to that underlying model. All I am saying is that the commands have lovely names that give terribly poor indications of what they do, the documentation is pretty bad, and the commands are poorly segregated and have overlapping functionality. If you aren't pretty experienced at git, even if you know exactly what you want to do in terms of the data model, it can be a struggle to figure out what you need to do make that happen. That is entirely symptomatic of a poor interface.
|
|
#
?
Apr 19, 2013 05:59
|
|
|
Doctor w-rw-rw- posted:Though, frankly, the idea of most people using Git actually cargo-culting based off of some other DVCS instead of learning how it works is a horror. The other problem is that it's insidious. Every time I think I finally have a handle on it, it does something that I can't fathom. "OK, I'll just do a pull here and... wait, how can I have a merge conflict in a file that I haven't loving touched?" And if you gently caress something up with git, then God help you. We used to use CVS, and yeah, it's primitive; but if something got trashed at least I could fix it manually if I had to.  Now my work computer is littered with directories called things like "wtf.git", "git.poo poo", and "fuckyougit" because usually it's just easier to clone the repository again and start over than to figure out how to undo whatever just happened because I cast the wrong git spell. Not to mention the commits I have with a comment like "WTF just happened?"Right now I just have a series of commands that I follow that I don't really understand, but that do what I want. Hooray for cargo cult revision control!
|
|
#
?
Apr 19, 2013 06:02
|
|
|
How the gently caress do you gently caress stuff up with git? What the gently caress is wrong with you? I never hosed poo poo up with git. Why? I don't know, maybe it's because I don't rebase? I'm basically a complete git noob, all I know is push, push -u origin branch, pull, commit -am, checkout -b, log -10, and help. You're not going to get a merge conflict in a file you haven't touched unless you're doing something extremely loving stupid. You should either quit computers or bomb your coworkers. (USER WAS PUT ON PROBATION FOR THIS POST)
|
|
#
?
Apr 19, 2013 06:26
|
|
|
Sorry that you don't care enough to learn your tools? Git's pretty good about not throwing away your data even when you screw things up. See eg reflog.
|
|
#
?
Apr 19, 2013 07:03
|
|
|
Unless you do some kind of weird `git reset --hard` or use `git checkout .` (bad idea) it is kinda tough to lose stuff in git. The fact that you can use git stash/git stash apply to save your work is also pretty useful Learning git does take some time. Essentially I learned commands as I needed to figure them out. I still have to look up a lot of things though because its a pain to memorize some of the syntax.
|
|
#
?
Apr 19, 2013 07:43
|
|
|
|
| # ? May 14, 2024 07:33 |
|
|
Progressive JPEG posted:Sorry that you don't care enough to learn your tools? Yeah, I was going to post this. Reflog is great; unless you go into the .git directory and physically mess something up, it's pretty hard to get into a state you can't get out of using reflogs to check out a good state.
|
|
#
?
Apr 19, 2013 12:59
|
|