11–20 of 543 posts
This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better. How I think that will happen is using CRDTs against an AST to remove most merge conflicts.
That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.
This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better. How I think that will happen is using CRDTs against an AST to remove most merge conflicts.
> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.
edit: yep, so long git
check if a given commit is included in a bookmarked release:
sl log -r "a21ccf and ancestor(release_1.9)"> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.
> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.
Meh. If it has mercurial's revsets instead of gitrevisions(7) I'm game, I'll happily give up the staging if I don't need to open that manpage ever again. edit: yep, so long git check if a given commit is included in a bookmarked release: sl log -r "a21ccf and ancestor(release_1.9)"
> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.
AFAICT there are only two workflows involving the staging area: staging partial commits and resolving conflicts. The first case is taken care of by partial commit support, and the second case presumably has its own dedicated mechanism.
What is the argument against having a staging area? The Git staging area is crucial in my mind.
It's also easy to commit / amend part of your work by selecting the lines to include in nice curses interface (--interactive).
Git's major value proposition is that they added moving parts until the system worked great. If you don't want named branches, staging, or any other piece of the ideology, then subversion is a fine choice.
But most folks moved on from svn for reasons