Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git Is Simpler Than You Think

nfarina.com

Post reply on HN
Print view View original

101–110 of 122 posts

Re: Git Is Simpler Than You Think

#101

Post by eridius »

Timothee wrote: post #93
fr0sty wrote: post #79

Earlier quoted context omitted.

That is overly verbose. Try this: git checkout -b changes_on_their_own_branch git commit -a You can always create a new branch at HEAD (where you are currently) and switch to it without having to stash. On the other hand, stashing may be required if you wanted your branch to start elsewhere: git checkout -b changes_branch start_point

But doesn't git stop you from switching to another branch when there are uncommitted changes?

Git only prevents switching branches if the act of switching branches would modify the files you have uncommitted changes to. In the case of fr0sty's suggestion, the new branch cannot have any changes because it's being created from the current HEAD. But even if you're switching to a pre-existing branch, it may still work depending on what files git will need to touch.

In other words, no harm in trying the `git checkout other_branch` first, and only stashing if that fails.

Re: Git Is Simpler Than You Think

#102

Post by geeksam »

masnick wrote: post #3

Thanks -- great article. This is the most readable and straight-forward explanation of git's internals that I've seen (and I've read a bunch of articles/books/etc. looking for resources to help others learn git). I'd also recommend The Git Parable ( http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... ) for anyone who hasn't read it. Different focus, but also helpful for understanding git's philosophy.

I've struggled with helping others learn git as well; you can see some of my thinking at (http://think-like-a-git.heroku.com/#1) and (http://confreaks.net/videos/612-cascadiaruby2011-think-like-...). Currently working on a longish standalone website for those who (like me) can't stand to slow down enough to sit through an entire 20-minute video. ;>

Re: Git Is Simpler Than You Think

#103

Post by geeksam »

jasonkostempski wrote: post #12
wccrawford wrote: post #2

No, actually, it's not. And that post proves it. You can do some things to make it easier on yourself (and others) but it's not simple. You find out how un-simple it is when you hit one of those magical corner cases. Don't get me wrong, I love Git. I far prefer it over SVN and CVS. But it's not simple.

Well, to be fair, the title is not 'Git Is Simple'. I'm just starting to really use Git and after reading this it seems a little simpler to me. Personally, I think Git is relatively simple as far as version control systems go, it's forgetting 5 years worth of knowledge of SVN and the nice visual tools that support it that is hard.

I make daily use of GitX for visualizing the state of a repo, and it's got a pretty nice UI for building commits as well. (It's Mac-only, though.) Apparently there are several forks that have added new functionality on top of the version I use, but I'm comfortable enough at the command line now that I haven't bothered checking any of them out.

Re: Git Is Simpler Than You Think

#104

Post by fr0sty »

MetaMan wrote: post #94
projectileboy wrote: post #58

Although I love Git, this whole thread exemplifies the way in which Git horribly fails my one success measure for good tools: you don't talk about them very much.

Totally agree. We switched from SVN to Mercurial around 6 months ago and I have to say I am annoyed that I have to spend so much time messing around with the tool rather than coding.

You can say the same with almost any non-trivial development tool. Vim, emacs, Eclipse, VisualStudio, etc all require time spent "messing around with the tool rather than coding.

Another fallacy is that "writing code" is the only "useful" thing one can do. Creating clean logical history and good commit messages (or other documentation) does not invole writing code, but that doesn't mean it is not important.

Re: Git Is Simpler Than You Think

#105

Post by dongsheng »

oacgnol wrote: post #75

Git is very powerful and I do like it more than SVN, but I felt like I had more trouble switching to it from SVN than if I had learned git from a clean slate. Switching my mindset from SVN-style centralized repos to decentralized git was the hardest part, as certain things in SVN didn't translate to git. Git is simple, but switching is not.

There true, it's hard to transform the concept in SVN/CVS to git world.

I remember when I was migrating from CVS to git, it's ok to understand cvs update is git fetch & git merge now, committing is the same, additionally I need to push the commits to share with co-workers. The hardest part to understand rebasing and branch management. But it worth to learn all these concepts, it make version control more flexible. It's pretty cool to use git reset and git push -f to modify the commits history (make sure you know what you are doing).

Re: Git Is Simpler Than You Think

#106

Post by dave1010uk »

ekidd wrote: post #26

If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…

I really don't like "git commit -a". I've seen people new to git add every file in the project directory without checking what files are there. This includes merge conflicts, SQL dumps and random backups.

If you do a "git status" immediately before then "git commit -a" can be a slight time saver; though It's better to use "git add -u", which stages all files that are in the repo and ignores any new files. Personally, I like adding files either 1 or 2 at a time or even with "git add -p".

While I'm at it, lots of people seem to have poor (single line) commit messages, stemming from the use of "git commit -m". Whilst this is OK on some occasions, commit messages are often better thought of as an email with a subject and a body.

(Yes, I know sometimes a single line commit is all you need and you can write multi-line commits directly on your shell but some people don't know this and it limits their ability to write a good commit message.)

Feel better getting that out my system. Now I need to tell my co-workers.

Re: Git Is Simpler Than You Think

#109

Post by donaq »

dave1010uk wrote: post #106
ekidd wrote: post #26

If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…

I really don't like "git commit -a". I've seen people new to git add every file in the project directory without checking what files are there. This includes merge conflicts, SQL dumps and random backups. If you do a "git status" immediately before then "git commit -a" can be a slight time saver; though It's better to use "git add -u", which stages all files that are in the repo and ignores any new files. Personally,…

"git commit -a" actually does not add every file in the directory. It only adds those that are already in the repo.

Re: Git Is Simpler Than You Think

#110

Post by dave1010uk »

donaq wrote: post #109
dave1010uk wrote: post #106

Earlier quoted context omitted.

I really don't like "git commit -a". I've seen people new to git add every file in the project directory without checking what files are there. This includes merge conflicts, SQL dumps and random backups. If you do a "git status" immediately before then "git commit -a" can be a slight time saver; though It's better to use "git add -u", which stages all files that are in the repo and ignores any new files. Personally,…

"git commit -a" actually does not add every file in the directory. It only adds those that are already in the repo.

That's embarrassing. I meant "git add -A" or "git add .". I guess "git add -a" or "git commit -a" isn't so bad but I still think care should be taken when adding files to the index, especially with newcomers to git, who pick up habbits from tutorials like this.
Post reply on HN