4 ms·

I think my main problem with git (though I use it) is that things that should be simple are mind numbing hard. At 2:00am when I working, having to read pages an

I think my main problem with git (though I use it) is that things that should be simple are mind numbing hard. At 2:00am when I working, having to read pages and pages to decide if git pull is the right thing is just painful. I never felt that type of pain with SVN, it more or less just maps to directories. To each his own I wish there was the right way to use git in 50 words or less. If I need to read a book to correctly use it ... grrrrrrr.

thrush 12y ago
Some people like git pull, but I prefer git fetch. This gets all's the history from the remote repo without applying any changes. Then you can run something like 'git rebase -i origin/master' which is where I think git can really shine. There is an excellent link out there that explains git in layman's terms. I think it's called git for hackers or something of the sort. It's much easier than the docs in my opinion.
- SDGT 12y ago
  Best practices are to not use pull unless you certainly know you should. Things should be fetched then merged with two separate commands.
  - gizmo686 12y ago
    Pulling is equivelent to doing a fetch then a merge. Unless you plan on doing something between the two steps (like inspecting FETCH_HEAD yourself), then there is no advantage to not simply pulling. Of course, if (like thrush) you do not plan on doing a merge, then you will need to do the fetch manually and do what you do want to do. Although, git pull does have a --rebase option, but I am not sure if you can pass the -i flag to it. Having taught people how to use git, I found that it is easier to not show them the pull command until they are used to doing fetch && merge.
- mitchty 12y ago
  Can just git pull --rebase too instead of fetch/rebase.
clintonb 12y ago
What!? The scenario you described doesn't make much sense. Why would you need to read pages to determine if git pull is the correct command to use?
- georgemcbay 12y ago
  Partly because the terminology tends to be slightly different than other source code control systems use. Also partly because if you do any research on git usage patterns you will find like 6 totally different ways you can use git to do roughly what you used to do in svn, and any one of the options you choose of those will have pages and pages of blog posts explaining why doing it that way is stupid and wrong and you should really do it in this other of the 6 ways, with no real authoritative explanation of when you should use which pattern. The end result is a situation where you have to learn a lot about how git works internally to actually have an idea if how you are using it makes sense or not in relation to your project. git isn't nearly opinionated enough for simple usage patterns, IMO. I like the flexibility it offers but it would be nice for new adopters if it were more hidden and there was a more obvious "happy n00b path" to take when first starting with it for the majority of projects that don't have the sort of distributed development challenges that the linux kernel does. Note: I'm not the OP and I'm really comfortable with git now, but I've been where OP is and totally understand.
jerf 12y ago
"I never felt that type of pain with SVN, it more or less just maps to directories." Ironically, that's one of my major fatal objections to SVN, the way it casually encourages developers to have a code checkout that doesn't actually exist in the source repo, as you check out various versions in various subdirectories without even thinking about it if you aren't careful. Back in my SVN days I lost track of how many times it worked on somebody else's box and not on mine, because one or the other of us (or both!) had a checkout that didn't actually represent any particular revision. "Well, don't do that then!" Of course not, but A: I can still be bitten by other developers doing it and B: SVN really, really affords this. By accident, sure, but it is afforded nonetheless. In fact in a lot of ways SVN vs. Git reminds me of static vs. dynamic typing... many of the "easier" things that SVN does are also wrong, and many of the things that people are objecting to about git are actually the underlying model being correct, and refusing to be wrong. I don't mean the UI, which is sort of dodgy, sure, but the underlying model. (Git submodules are sort of that way... in many ways, the difficulties in using them are reflective of the fact that correctly embedding one source code repo in another is actually fundamentally hard, and anything that makes it easy is probably just glossing over some fundamental problems. It is probably possible to make it easier, but if it has been made easy, one should immediately be very suspicious.)

thrush 12y ago

Some people like git pull, but I prefer git fetch. This gets all's the history from the remote repo without applying any changes. Then you can run something like 'git rebase -i origin/master' which is where I think git can really shine. There is an excellent link out there that explains git in layman's terms. I think it's called git for hackers or something of the sort. It's much easier than the docs in my opinion.

SDGT 12y ago
Best practices are to not use pull unless you certainly know you should. Things should be fetched then merged with two separate commands.
- gizmo686 12y ago
  Pulling is equivelent to doing a fetch then a merge. Unless you plan on doing something between the two steps (like inspecting FETCH_HEAD yourself), then there is no advantage to not simply pulling. Of course, if (like thrush) you do not plan on doing a merge, then you will need to do the fetch manually and do what you do want to do. Although, git pull does have a --rebase option, but I am not sure if you can pass the -i flag to it. Having taught people how to use git, I found that it is easier to not show them the pull command until they are used to doing fetch && merge.
mitchty 12y ago
Can just git pull --rebase too instead of fetch/rebase.

clintonb 12y ago

What!? The scenario you described doesn't make much sense. Why would you need to read pages to determine if git pull is the correct command to use?

georgemcbay 12y ago
Partly because the terminology tends to be slightly different than other source code control systems use. Also partly because if you do any research on git usage patterns you will find like 6 totally different ways you can use git to do roughly what you used to do in svn, and any one of the options you choose of those will have pages and pages of blog posts explaining why doing it that way is stupid and wrong and you should really do it in this other of the 6 ways, with no real authoritative explanation of when you should use which pattern. The end result is a situation where you have to learn a lot about how git works internally to actually have an idea if how you are using it makes sense or not in relation to your project. git isn't nearly opinionated enough for simple usage patterns, IMO. I like the flexibility it offers but it would be nice for new adopters if it were more hidden and there was a more obvious "happy n00b path" to take when first starting with it for the majority of projects that don't have the sort of distributed development challenges that the linux kernel does. Note: I'm not the OP and I'm really comfortable with git now, but I've been where OP is and totally understand.

jerf 12y ago

"I never felt that type of pain with SVN, it more or less just maps to directories." Ironically, that's one of my major fatal objections to SVN, the way it casually encourages developers to have a code checkout that doesn't actually exist in the source repo, as you check out various versions in various subdirectories without even thinking about it if you aren't careful. Back in my SVN days I lost track of how many times it worked on somebody else's box and not on mine, because one or the other of us (or both!) had a checkout that didn't actually represent any particular revision. "Well, don't do that then!" Of course not, but A: I can still be bitten by other developers doing it and B: SVN really, really affords this. By accident, sure, but it is afforded nonetheless. In fact in a lot of ways SVN vs. Git reminds me of static vs. dynamic typing... many of the "easier" things that SVN does are also wrong, and many of the things that people are objecting to about git are actually the underlying model being correct, and refusing to be wrong. I don't mean the UI, which is sort of dodgy, sure, but the underlying model. (Git submodules are sort of that way... in many ways, the difficulties in using them are reflective of the fact that correctly embedding one source code repo in another is actually fundamentally hard, and anything that makes it easy is probably just glossing over some fundamental problems. It is probably possible to make it easier, but if it has been made easy, one should immediately be very suspicious.)