February 27, at 2: It does most of the things Git does, but tries to do it without hurting beginners. If the command is dangerous, you have to enable it on first. You want to rebase and push those commits again? BitBucket now provides a user interface for doing this. At my last job, I picked Hg for our developers for precisely this reason.
I was very happy with it, and used to think all the Git enthusiasts nuts. However after using it extensively it really is a better expert tool. August 5, at 3: I would argue that the complex set of commands, and even some of the inconsistency, is for the sake of easy extension and integration. I think the set of commands is complex because they act almost as an API for applications to interface with Git, in a way similar to how many standard Unix utilities are useful for programming.
The lack of abstraction leading to complexity is planned, I think, so that applications can have more control over how they interface. However, I think the API-like interface also provides opportunities that would not be available had Git gone with a clean, abstracted interface.
It was more reasonable 20 years ago. These days, we have so many tools and technologies to deal with, that they all must be made as learnable and intuitive as possible. Nowhere in any of the git documentation does it say that it will operate on untracked files other than in the documentation for git add and commands which do an implicit add.
Not every file in the working directory regardless of if it is tracked or not. To say that git stash performed incorrectly is to push your own opinion on what the correct action of stash should be while ignoring the way that git operates. I could see you having written something like the following: Where most of the commands in git operate on a set of tracked files in the working directory, git stash works on the working directory as a whole.
Instead the better action would be trying to learn how git is used as git, why it works for the developers using it, and forming a conclusion afterwards. That said, it does seem like you have in fact given git a try.
August 6, at 5: Check out Mercurial Patch Queues. You seem to have no concept of how difficult it is was to create SVN in a world where there were few good tools, very little OSS, and a much more limited concept of VCS. That SVN succeeded so well at the task you dismiss out of hand is corroborated by its wide and enduring popularity. December 6, at 1: I have no affiliation with Syntevo or their product. This is simply my personal recommendation. Syntevo have genuinely impressed me. Ravi March 28, at 6: Do you learn all engine mechanism when you buy a car?
Car does solve your problem. To make it easy and powerful , you make different interfaces and abstractions can achieve in same commandline. To do it, empty your cup and keep your reasoning reasonable to real world scenarios. I have used mercurial, far easy and does job well than GIT. What I will do with its almighty power, when it takes long to learn. If GIT does not simplify its workflow and commands, other variant will come out of frustration because the community failed to recognize pain.
Keep pointing out the flaws, once people adopt git they tend to forgit how seriously messed up it is, just because it is so much better than what they left. It still could be easier than it is.