Vim did win the war; there's still nothing better.
IBM did win the war, and then shot themselves in the foot with pricing on their new generation (which generation was a pretty radical shift). There's not much chance of git doing that.
Java did win the war; its competitors from the time are largely dying (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). You could argue that Ruby has overtaken it, but again the changes over the last ten years of ruby - and the influence of rails - have been enormous.
I don't think we should stop trying to make a better VCS. But I do think we should accept that Git has won against bzr and hg in their current form; neither of those will displace git without radical changes that they are probably unsuited to make. Most likely the successor to git will be a new program entirely.
I'll just put this here for you:
https://code.google.com/p/vim/source/browse/src/eval.c
Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means. I've switched to emacs with evil, which in my opinion is better than vim in a lot of ways.
> (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last).
Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here. This isn't an argument, it's a prediction, and a stupid one. Nobody will come back to check your comment in 5 or 10 years and call you out on it. This is just the certain kind of asshat thing you can say and not worry about it coming true or not because you're some anonymous commenter making the internet richer with your irresponsible use of a keyboard.
Winning means the user experience, not the code. And sure, I was lazy, it would be more accurate to say vim and emacs won between them (and are still fighting it out).
> Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here.
Do you disagree that a) Objective-C was more or less dead prior to the release of iOS b) almost all people currently using Objective-C are doing so solely because it's the language you can write iOS apps in c) absent huge, radical changes, Objective-C will never threaten Java's popularity the way that post-Java languages (C#, GHC Haskell (very different from the language that was standardized in 1990), Go, Scala) are?
Objective-C is used to build applications for Apple software. It's not a threat to Java, but that doesn't mean Objective-C is dead. Objective-C will be around for a long time to come. It's a modern language that powers all of Apple's most recent technology. They have no reasons to change, and there are no signs that Apple is on the verge of disappearing into the aether.
Vim is shitty software. I like the UI, but the thing is single threaded and everything runs on the UI thread. There's no hope for async, or an event loop, or even a settimeout like feature. The code is full of globals and trying to add new features to the thing is going to result in inexplicable, unfathomable seg faults. Vim uses shitty regular expressions in the UI thread to do syntax highlighting which is why that's slow for big files and why the syntax highlighting breaks.
So the code matters. There will never be powerful IDE like features as long it's this single threaded thing that only ever does anything as a response to user input. Given the state of the code, changing this does not seem ever possible.
Run VIM in a sub-process, and communicate with it through a fake terminal. Basically, quarantine the madness.
For what? A specific niche of web applications?
Least substantiated claim of 2014 so far.
The "GNU/Linux" vs "Linux" discussion is a long one but I'm pretty sure there's (almost?) no GNU in Android.
Android is very different from the GNU/Linux operating system
because it contains very little of GNU. Indeed, just about
the only component in common between Android and
GNU/Linux is Linux, the kernel.
GNU Emacs is much better. It's easier to use and easier to extend.
Haha, good one. Many of vim's predecessors are better even, nvi is far nicer to use than vim is for example.
Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly become quite complicated and in the end it is hard for the user to get a deeper understanding of the system.
The funny aspect of this is, that a lot of people complain about Gits bad user interface. It turns out however that Git is really easy to grasp.
Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn makes it impossible for it ever achieve 20% of git's functionality simply because things are so poorly defined.
After using git for 6 months I understood it better than I did about svn in the previous 5 years. I would prefer a better porcelain, but given that software development is my full time job and that I can use git for all software development regardless of the language, I'm happy to commit a bit of muscle memory to git's idiosyncrasies.
Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch.
git , I believe , is the textbook case of what the opposite of a user friendly UI is. commands have switches which change the command so fundamentally it should be another command. Which noone wants 'cos there are like 140 commands already. switches which across commands do the same thing but are named differently. The same command doing wildly disparate things without any indication of what's happening -- try git checkout file, and guess what the state of file will be. It might from the staging area or it might come HEAD if it wasn't staged. Nuts.
What? Of course you can. I've worked on teams that did it. You are talking total rubbish.
How do I reduce that complexity? I always pull and never fetch, which helps slightly, but only slightly; pull seems to fetch other branches, so it's still possible to have my copy of a branch end up behind my remote-tracking copy of that branch. There's no command analogous to pull for "add and commit and push", so that's always a second step to possibly forget (I don't want to rely on an alias as I work on a number of different machines). Most problematic at the moment is that there's no way to tell the difference between an up-to-date branch and a non-remote-tracking branch, so I sometimes delete branches that I haven't fully pushed, because I forgot to make them remote-tracking, so they didn't show up as behind when I "git status"ed.
I've been on a team that transitioned from SVN to Perforce, the again to Git, keeping the same workflow all the way through.
It isn't the way that I prefer using git, but it works perfectly well.
That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus merges in the history).
If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push, and your team member put out new changes, that is a problem for you to resolve. Workflow wise, this all works the same as it does with any other centralized workflow.
If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.
Sure, but you hit the problem twice as often in git, because you have to do twice as many things.
> If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.
In SVN that doesn't show up as a merge in the history.
Well no, I don't...
If this really is a frequent problem for you, then you might want to consider adding a note to the end of git-commit's output to remind you to push, or even just aliasing git-commit to push by default. I would recommend that you instead learn how to use git, but failing that...
> "In SVN that doesn't show up as a merge in the history."
If you don't want to resolve those situations with a merge, then don't resolve those situations with a merge... Rebasing exists for a reason.
You might like "git pull --rebase"
Git allows you to follow a centralized process perfectly fine. However if you choose to not follow a centralized process, it will not force you to.
I don't track my other developers' feature branches locally unless I need to view them.
Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.
Branching/merging/committing is pretty straightforward. The problem is that some commands seem to be very convoluted. For example, why does reset do four different things depending on whether it's soft or hard or plain? I keep having to Google to find how I can revert my latest commit.
Another thing I have trouble with is obscure failures. Obviously this isn't something I can just learn, but there are times when git fails for a reason I don't understand...
What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?