51–60 of 83 posts
A thought: if you think you can make git better, why not just write a DSL (domain specific language) on top of it? I mean, it already does everything under the sun, so there's a challenge for anyone up for it!
Considering that svn is a half implemented VCS where everything is a branch but merging is a royal PITA I'll take Git's warts.
Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to understand some basic concepts. And some points about the article. Git is a framework actually, you need some workflow to use it in a team. So git requires a lot of discipline from all team members. You can't just "commit" as in subversion, you must understand…
I'm not anywhere near an expert with git, but I'm proficient enough to use it effectively with my normal workflow. I like git, but admittedly the bar was set really low by subversion. This article raises some valid points, though. One that resonates most with me is that git exposes its entire model. I really wish there was a git-lite that just had the few basic commands that junior developers can grok and not fuck up…
Edit: Thanks to lyall for the links. He posted below. [1]: http://gitless.com/ [2]: https://people.csail.mit.edu/sperezde/oopsla16.pdf
Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to understand some basic concepts. And some points about the article. Git is a framework actually, you need some workflow to use it in a team. So git requires a lot of discipline from all team members. You can't just "commit" as in subversion, you must understand…
Further I'd argue the subversion "just commit" model is potentially toxic to the quality of the codebase and SCM logs. It makes the act of sharing code with others overly casual. Users therefore often don't become proficient in the proper use of SCMs in general. They write poor commit messages, or may not have a clear understanding of changes introduced by their commit (this goes double for IDE-integrated SCM plugins that I've generally found to have poor UI and lack good affordances for grokking what's happening at any point).
The stage -> commit -> push (often to feature branch) provides multiple checkpoints to find issues in your code before it makes it into master/trunk. While staging (especially if you're using a GUI) you have a chance to view the changes being staged. After committing and before pushing, if you find something else that you missed, you can quickly amend your commit without much harm done. The pull request mechanism added by Github provides an additional code review step for a final sanity check and also allows you to run tests on branches before allowing merges (contrasted with the common practice of allowing everyone trunk privileges in SVN, often with a post-commit code review). Rebasing is a an act of final resort for cleaning up your work before everyone else is burdened with the job of grokking and maintaining it for the remaining lifetime of the system.
EDIT: Some of these practices are possible to replicate in SVN (eg. do an svn diff and really review the changes before committing) but there's no chance of amending commits, private or features branches are less frequently adopted and rebasing is equivalent to FTL travel and immortality from an SVN viewpoint.
git reset abc # unstage file `abc`
git reset xyz # switch to commit `xyz`
git checkout mybranch # switch to branch `mybranch`
git checkout myfile # remove any local changes to `myfile` since the last commit
Maybe this would work great in a typed language where I might have `reset(File x)` and `reset(Commit x)` with different signatures... but for a CLI where everything is stringly-typed? Not so fun.
Also, god knows what happens here if there's a branch name with the same name as a file...
Earlier quoted context omitted.
Honestly, use mercurial.
Maybe if GitHub/GitLab allowed me, I'd do so. Even SVN, honestly.
Why would you prefer SVN over git? I find git to be infinitely better than SVN. DVCS is a pretty good paradigm and the biggest (valid) complaint I have seen about git is that several of the commands such `git checkout` have multiple meanings which isn't a big enough deal to lose DVCS.