[jebblue]

I have tried to get git, some people say one project per repo (which seems crazy but I did it), many projects are ok, you do need a main master repo, you don't need one, then there's the half dozen commands where with SVN it's one.

Now the most valuable thing to me in source control, history, I'm supposed to keep clean? That's like a sacred cow, you _don't_ mess with history.

>> That's fairly straightforward, no?

No _Linus_ it isn't. Git is hard to get right. If it wasn't for EGit I'd be lost. I tried Canonical's bzr and it is more understandable for ordinary humans.

All that aside I really like Linux. :)

[klj613--]

Best way to learn git is in the command line (get away from any GUI). And then play with repositories to see what the commands actually do.

"Don't mess with history"? I don't have to commit to my commits as long as my commits ain't public.

Rewriting history is a lie? Well, if you want to keep everything you do in history, maybe commit on each keystroke? That's insane.

Don't commit unless your ready to commit? Then that be hard to keep track of. Come time to commit you've got 50+ files modified good luck at doing decent commit messages.

[jebblue]

>> Best way to learn git is in the command line (get away from any GUI).

I've used a lot of source control systems and the best always have a GUI and so guess what? I want a GUI unless the CLI for such system is inherently intuitive which if you read my comments I do not think git is intuitive at all.

>> I don't have to commit to my commits as long as my commits ain't public.

Huh?!?! I don't get that, it like makes no sense to me whatsoever. Why do you think I should even try to comprehend it?

>> Don't commit unless your ready to commit?

Are you suggesting I said or asked that??? Are you advising me? Seriously what?

>> Then that be hard to keep track of. Come time to commit you've got 50+ files modified good luck at doing decent commit messages.

Huh? I'm sorry is that English because it doesn't even make sense at all to me? Is it 50 lines changed all clearly related? Is it 50 totally different changes?

[klj613--]

Personally I think its better using the CLI for git.

I commit very often however I rewrite the commits. In other words, I mess with my history and it is a good thing (My commits ain't final, in other words... "I do not commit to my commits").

In SVN I try not to commit too often because I do not want to commit (publish) changes which I may not want to keep.

With git I commit very often in stages. Then I can remove them or change them at a later stage. If I do not do this I will end up with a load of files (e.g. 50+) which has been modified and either I commit them all in one (bad) go or try and separate out each step I've taken the past 12 hours and do decent commit messages (good).

Of course you could commit very often, create new commits to fix errors you've done in recent commits (rather than rewriting history). You could also merge master into feature-x everyday (rather than rebasing), but then you'd have history which looks like chaos and hard to follow.

-

Honestly, when I started git I was lost (first VCS I learnt). Until one day I figured out how simple git is to use.