|
It looks like you just do not need it. JIT has just 2 strong points - distributed architecture and conflict resolution. You use "I" and not "we" in the post, so it is unlikely that you can benefit from either. Besides these 2 advantages, GIT still retains its nature of a quick hack. I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
|
|
|
|
|
77465 wrote: You use "I" and not "we" in the post, so it is unlikely that you can benefit from either.
Well, this IS for a project with a couple other devs on it.
77465 wrote: I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
Those are not mutually exclusive. My client is an expert at Git and whenever he explains something, it all makes sense and I "get it", but then when I try to do something at home, it blows up for me. It's a learning curve, and I've read through books and blog posts, but there is still a disconnect between what I do, that I think is doing it right, and what ends up happening. However, my rant was at the fact that I tried to do everything possible to kill my changes and revert back to the remote repository, to absolutely no avail. I ended up deleting the entire folder and re-cloning it. When I read in the documentation that doing a "reset --hard" (or whatever the syntax is) should kill my local changes, and doing a fetch / pull / checkout should get me to the latest version on the remote, and it obviously didn't work because "git status" still returned all the changes I wanted to throw away, then yes, I rapidly come to the conclusion that it's a pile of s***.
Marc
|
|
|
|
|
In a sense, yes, it is that pile. When I started using GIT I created a 3 repository model of the real project and tried commands there first. We also had few developers, but thanks to the lack of coordination and frequent changes in specs and overall project direction GIT payed for itself. I guess that was what a much larger and better organized team would experience.
|
|
|
|
|
From the perspective of someone at the other end of the experience curve, I found Git almost impenetrable - I'm learning French right now (and I'm not a young whipper snapper), Git is harder than an entirely new language as far as I'm concerned.
I would guess that if I broke through that outer shell and was already experienced with VCS concepts then Git would be the best choice - it's an assumption since why else would so many people and companies flock to it? I am guessing that the complexity pays back later when you have lots of contributors, branches etc. and maybe Bazaar, Mercurial etc. aren't so capable at that stage..., I have no idea, but there must be some reason!
However, the most frequent comment I see and which tallies with my own experience, is "If it was my choice I'd use Mercurial".
Mercurial is so much easier to get your head around, hugely helped by TortoiseHg, from total novice to functional in minutes not years.
Small plug, not aimed at your level of knowledge, Choosing a Version Control System - A Beginners Tour of the Options[^]
What I can't work out is why, if so many folk are saying "I'd choose Mercurial", does everyone choose Git?
|
|
|
|
|
I hate TFS, but that's only because I'm a real noob, and because of the way the repo can get so totally out of sync structure wise with your workspace.
|
|
|
|
|
Marc - a couple of suggestions...
- Mercurial is much nicer from a *users* point of view than Git (IMO)
- I found hg init[^] and Version Control by Example[^] very useful for comparing/contrasting how SVN and DVCSs work
And one other datapoint - one of my colleagues, who was just not getting on with SVN, picked up Mercurial in a couple of days, and has had no problems with it - it's just worked...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|