51–60 of 92 posts
Earlier quoted context omitted.
For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push). It is a great way to have a clean linear history. But it makes git pull 'illegal' because it does a merge implicitely. That's tipically something I didn't think about the first times I used git.
git pull --rebase doesn't merge implicitly and git config --global pull.rebase true will set that as the default `pull` behavior.
The article rings a lot of bells because I actually do understand how Git works. I'm not so sure it is understandable by someone who is new to git.
The second sentence of the actual tutorial part: "When you create a git repo, using git init". I'm sorry, what is a repository? Some sentences later: "Here is what’s your .git will look like before your first commit:". What is a commit exactly?
I once read another tutorial, which I can't find now. It reads as a story of a group of people exchanging files and in order to avoid administrative mess, eventually end up inventing the core of git, because it solves their problems. I think that tutorial is much better for explaining the concepts of git to beginners.
Edit: I think this is the tutorial i mentioned: http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
Earlier quoted context omitted.
I think most of us do agree. The official documentation is written as though the reader is already intimately familiar with the internals of git. I'm a smart guy, and I've read the official docs numerous times but every single time I failed to come away with a greater understanding than I had before. The commands are not particularly intuitive either. I personally think git is fucking awful. ... but it's the best ver…
I work in video games where everyone uses Perforce. It's not perfect but I think it's vastly superior to Git. I can train someone whose never even heard of source control how to use it in 5 minutes. Git might qualify as best FREE version control system anyone's come up with so far. But best? No, no I don't think so.
Earlier quoted context omitted.
for about six months my git workflow was this: git add -A git commit -am "fixed some stuff" but I've finally found some time to start digging into how to really use it. The issue I have with it is that if you step outside the basics it's so easy to get yourself into a thorn bush and the way that git is explained most places is really not intuitive at all.
Ah yes, the "subversion" method of using git. ... I also do this. :|
Earlier quoted context omitted.
Try using a tool like 'git cola' that allows you to selectively commit soecific lines, instead of just by file. Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story. Use 'gitk --all' to view the tree of changes. get comfortable with using feature…
You can also commit specific lines using `git add -p`
It also highlights whitespace nastiness (ie trailing spaces, missing newline at end of file, inconsistent newline chars, etc).
The CLI is the ideal too for a lot of things. Preparing commits is not one of them.
Earlier quoted context omitted.
I work in video games where everyone uses Perforce. It's not perfect but I think it's vastly superior to Git. I can train someone whose never even heard of source control how to use it in 5 minutes. Git might qualify as best FREE version control system anyone's come up with so far. But best? No, no I don't think so.
Agreed. I've used Perforce for a long time and it just clicked from the start. A lot of people swear by DVCS, but somehow I've always worked on projects where centralized VCS makes more sense. I wonder what the difference is? It can't be just about size, because Google uses centralized and Linux uses distributed, and both seem to be happy...
Open Source will probably never produce a good centralized VCS because it's not a problem that exists for Open Source projects.
The article claims to be aimed a beginners: "There are a lot of posts out there about learning the basic commands of git, this is not one of them. What I’m going to try here is a different approach." The article rings a lot of bells because I actually do understand how Git works. I'm not so sure it is understandable by someone who is new to git. The second sentence of the actual tutorial part: "When you create a git…
How many "Understanding Git" posts have hit #1 on Hacker News? More than a few. How many have hit top 10? Surely dozens. Can we, please, take this as an indicator that Git is too fucking complicated? After the first thousand "Git made easy" blog posts it should have been apparent. Le sigh.
It has _NOTHING_ to do with meeting needs or doing things spectacularly better than other tools. There was version control before git and it worked just fine. I just think some "cool kids" started using it, it developed a certain Caché that made it desirable and that was it: here we are with the most popular version control system in the world with an absolutely shitty, inscrutable interface.
For the vast majority of git "users", this doesn't matter. They use git as little more than filestorage.
The article claims to be aimed a beginners: "There are a lot of posts out there about learning the basic commands of git, this is not one of them. What I’m going to try here is a different approach." The article rings a lot of bells because I actually do understand how Git works. I'm not so sure it is understandable by someone who is new to git. The second sentence of the actual tutorial part: "When you create a git…
THe problem with git is not that it can't do those things, but that it is hard to attain mastery of git commands even if you know what version control is supposed to do.
Earlier quoted context omitted.
for about six months my git workflow was this: git add -A git commit -am "fixed some stuff" but I've finally found some time to start digging into how to really use it. The issue I have with it is that if you step outside the basics it's so easy to get yourself into a thorn bush and the way that git is explained most places is really not intuitive at all.
This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.
* git add -p, git add -i are nicer ways to add files
* git grep
* git reset, revert, and checking out old commits
- these commands I currently find tough to get right
- this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff
Most of this stuff is stuff that I've known about since I started using git but I was afraid to use it because I didn't really know how it worked and didn't want to "mess up". Since the previous comment describes 90% of what I need to do, there wasn't really any point to doing it any differently.
The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off. This leaves the obnoxious necessity to commit for just syncing things instead of for actually finishing a feature. I don't want to do rebasing because I don't want to lose history. This is the main reason I don't think git is currently an ideal solution for me but since I have nothing better I'm stuck with it.
It needs a simple semantic interface and it needs the ability to "sync" in-between commits.