However, he and many git users enamored of his style are perfectly willing to be condescending to anyone who points out the problems. Which itself is a problem.
> The UX of hg was more intuitive for users coming from SVN and CVS
I second this. Trying to go from SVN to git left me confused and frustrated, while I found it much easier to switch to hg. Once I had been using hg for a while, I found that I had absorbed enough of the difficult/confusing stuff that switching to git was relatively painless.
hg's command-line interface is far better organized, yes, at least in the sense that it appears to have been organized rather than organically slapped together and papered over with "well it'd make sense if only you understood more about it".
Blaming users for not understanding a bad interface is one of the classic mistakes.
hg's original workflow didn't encourage git style branches at all nor did it have any kind of stage IIRC. They've since been optionally added. Is that workflow in hg more intuitive or is only its far less powerful original workflow more intuitive?
It took me a while make the mental jump from svn style branches to git style and from no stage to having a stage but I'd never want to go back now that I understand them.
This is not about workflow (though I do prefer hg's model of multiple types of branch-like constructs). This is about the command-line interface used to interact with it. Where git overloads commands (the same command can do vastly different things depending on options or context), or cannot make up its mind whether to implement functionality through top-level commands or flags to existing commands, hg is much more consistent in having a set of commands whose names match the operations they perform and are not overloaded with multiple contextual meanings.
I've used both extensively and I think they're virtually identical. Mercurial is a bit nicer because it's written in Python, but git has github going for it.
In my experience, once you get into more complicated commands like rebase, I had to read a lot of docs to get things to work in both systems, so I'd say hg is easier to get started with but they're on par overall in terms of complexity.
As a sidenote, I think the ability to `rebase -i` work branches and squash, edit, and drop changesets is a very useful feature, and it's made very easy in git. Mercurial can rebase branches, but it really doesn't like it...
For simple workflows (and certainly for beginners), hg is far easier to use than git. However when it comes to advanced usage, I personally find git more intuitive and frankly more powerful.
Granted, I learned git first and had been using it for 6 years before using hg.
Search results for "how do I branch in Mercurial" always seem to lead to elaborate tutorials that suggest repo clones or bookmarks or numbered anonymous heads or smuggling diffs outside the commit graph using an extension. If the simple use cases don't include branching, that seems like a big problem for a DVCS.
1. The UI is more consistent ie. the "update" command only does 1 thing updates your working directory to a specified state.
2. It doesn't have a pre-commit staging "index" like Git (or it at least doesn't expose it to the user. So workflow is a bit for straightforward ie. you don't need to constantly "add" files before you commit, it automatically does it for you.
I personally love the staging component of git and would be lost without it. I often write a bunch of code working through a problem, because I think best that way, but it makes for a maintenance chore and a poor commit history, so I stage it into multiple commits when I'm done. This is absolutely trivial in git compared with other programs.
Plus, while the UX of git is not intuitive, especially from SVN, if you want to bypass staging and just use it like SVN, you can "git commit -a". Like svn, if you have new, untracked files, you can "git add -A; git commit". This is also trivial to alias.
"it's complicated": yes,it is. it's a product designed and built for people who deal with complex systems and information models on a daily basis; they're the equivalent of a professional pilot... not your feeble, senile grandmother. You wouldn't buy your feeble senile grandmother a 787, chuck her in with no training and simple expect her to fly to Bali, would you?
"I don't like it and here's a heap of examples which lead me to arrive at my preordained conclusion that it's completely broken": cool, you've found issues. If you can, fix them and share. If you can't or won't... well, there are other tools for doing version control and perhaps another might suit you better. If you have to work with people that use git, I'm sure there's some way you can generate patch sets and still get stuff done.
There are two categories of possible criticisms: the model, and the implementation.
Fixing the implementation means changing code, improving APIs (e.g. local/remote branch delete).
Fixing the model means finding an everything different system. Yes, a graph-based VCS more complicated than a linear one. But it also matches realities of collaborative software development. And reality is complicated.
As you might guess, I'm sympathetic to criticisms of inconsistency or unnecessary effort, but I believe Git (and other DCVS) to have the completely correct idea about collaborative text versioning.
The difference is that to fly 787s you need quick response and muscle memory so all controls have to be available, and you've got to be able to fix errors in-flight.
And even then you don't want to create a joystick which pulls up when pushing forward.
A lot of these complaints seem based on the fact that Git has features SVN doesn't and those features add complexity. Git really isn't that hard to learn. The trick is to take your time. If you try contributing to projects with complicated repos before you have a grasp on all the complexities, then yeah you're gonna have a bad time.
I could write a similar article about how FTP is so much easier to use than SVN and it would be equally silly.
That is not to say that Git isn't inconsistent and the docs are terrible, but there are good tutorials out there. If I were more helpful I'd have a link to one here but I'm on my phone.
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 so I wouldn't have to waste my time explaining the same stuff for the umpteenth time.
If you want a straight-forward mental model that works with git, try Gitless. Note, you will end up learning some new commands that simplify things, and you'll have to re-learn git if you work for someone that wants you to use the nitty-gritty, but every convenience has it's downside, and you just have to weigh that against the immediate benefits.
I'd not downvote your comment but I'd like to point out you have a biased perception. You clearly state you never used anything else and then you say you never felt the need to use anything else.
It's not unlike a programmer who only knows GWBASIC saying they feel no need for recursion because they never wrote any code that relied on it, or named functions, because subroutines can do that. Or a C programmer who thinks class-based inheritance is superfluous syntactic sugar.
I don't mean it as an offense, mind you, but your lack of experience in DVCSs makes your opinion suspect. Spend a month actually working with Bzr or Mercurial and then, having been exposed to different solutions to the same problem, your opinions will be much richer.
My point wasn't that the others weren't good. It was that git has always met all my requirements and I never ran into any issues that made me want to try another solution.
Well, I meant how do we actually make git better? It has become and absolute standard and is not going away anytime soon. Everyone knows it, and there's a huge ecosystem around it (last but not least Github). I actually think there's a lot of benefit to that kind of standardization. Personally, I actually like git, but that doesn't mean it can't or shouldn't be improved. I don't see switching to some relatively obscure alternative (or even to mercurial) as a satisfying solution. Of course, anybody who wants to do it should feel free, but that limits your possibilities for collaboration with the community at large.
It is not hard to use Github with mercurial. I don't have personal experience with gitlab though.
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.
Sure, but what suggestions would actually improve the situation and are feasible, both on a technical level and politically? Is it just a matter of better porcelain?
The fundamental promise of any version control system is this: “Once you put your precious source code in here, it’s safe. You can make any changes you like, and you can always get it back”. Git breaks this promise. Several ways a committer can irrevocably destroy the contents of a repository:
git add . / … / git push -f origin master
git push origin +master
git rebase -i <some commit that has already been
pushed and worked from> / git push
A previous criticism was that you had to know about a set of things including the reflog in order to use git. The reflog is one of several ways to undo the "irrevocable destruction" above. Complaining about both issues feels like double-dipping :)
Also, I suspect that many of the "hosted git" implementations out there prevent this from happening by default. I know that both of the ones I use in my day job (gitlab and bitbucket) do, but I'm not 100% certain it's a default as opposed to something our ops guys did. In any case, far from impossible. EDIT: see boaardwalk's post.
Also, svn won't protect you from `rm -rf /` on the server, while git will, which is pretty cool.
And there are people I've wanted to strangle for telling me: RTFM.
The examples in this article are the crowning example of why their painful death would be well-deserved.
There's this thing about bedside manner that technically adept people need to cultivate, just as doctors do.
Did I mention I despise cold, snotty doctors too?
There's nothing worse than a condescending prick doctor wielding authority against you, when your sick or need medication and just trying to find help. The doctors that do this, know that they can cast a long shadow by dropping hints that they aren't on your side.
It's kind of the same scenario, and I try to remember how I've felt as a patient, when people ask me for help. You can usually grasp what people are really after, when their trying to figure something out, and ask for even a hint in the right direction.
It's the mark of rotten bastard that won't give even the slightest helping hand to someone who's on the same team. Pure evil, when you've helped someone with simple questions, and they sneer at you, given the chance to reciprocate.
Example: This one piece of shit sees a co-worker and I struggling with some retarded group policy problem on a windows machine. My co-worker is slightly clueless, but that's okay because he's not a fucking asshole. POS intervenes, starts driving on clueless co-workers machine, pops open mmc.exe twiddles a setting, and fixes the thing. I need to do the same thing. I ask him, so what was the fix?
Google is your friend.
I have sworn a blood oath to myself that before I die, I must slaughter this man's progeny, and proclaim his seed wiped from the earth, before caving in his skull with a tomahawk, eating his heart raw, and adorning my breech clout with his scalp.
Hey there, in reading your comment I feel like you are trying to make some good points, but you're getting downvoted heavily because of the tone and language you're using. Your language feels really personal and negative, like you decided just to go off on a rant. That's generally discouraged on HN - but there are always exceptions, especially if it's a topic or moment in time when a rant is actually called for.
The best thing in your comment is this sentence:
There's this thing about bedside manner that technically adept people need to cultivate, just as doctors do.
That's a well-put sentence, plus, I feel like you're on to something. I feel the same way, incidentally. I don't think it's productive or collegial to tell someone to "RTFM" or "use Google". If you're struggling with something right in that moment, the best thing to do is show some kindness and empathy and sit down and help. Then, once the problem is resolved, that's the moment where you can "teach a man to fish".
You seem like you have a talent for writing and your vocabulary and prose are quite good - just rework the tone and omit the profanity and you'll see some upvotes.
I have not had this problem recently because moved from Windows to Mac, but at some point about 8 years ago was the way git handled windows line endings was truly maddening.
To this day I never understand how to handle line endings correctly. I mean, when I have issues, I would need to google, and then forget again. Fortunately I don't have to work on windows that much.
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 what are you doing. So you can't directly compare git with something like subversion. And git ≠ github.
Some points are valid: bad and unclear documentation, no "included" workflows, bad command line UI. Author also didn't mention authorship issues, it's a real pain.
One resource I've found pretty useful for understanding git is http://think-like-a-git.net/ (also linked at the end of the article). It basically describes git in terms of a directed acyclic graph, where branches/tags give you starting points into the underlying DAG, and the various commands allow you to perform manipulations on it. Once I started thinking about it this way, it made a lot more sense.
That said, the command line UI really is infuriating - checkout means 3 different things depending on what the argument is, it's never clear to me whether I should be using "origin master" or "origin/master," etc. I'm also not entirely sold on the usefulness of the index, but perhaps that's cause I'm still new to using git.
> You can't just "commit" as in subversion, you must understand what are you doing.
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.
Any recommendations for resources on workflows for GIT?
I mostly write ML code as a single author and there's a lot of experimenting going on, so often I sit at the end of the day and write a commit message along the lines of "dicking around" or "updated some files" and feel like I might as well just sync my stuff with Dropbox and not have to worry about all the GIT commands.
They're naturally recommending the GitLab Flow, but a good approach is to read through it and choose what might work for you. The important thing is to keep in mind that there are countless variables that will likely be different for each team -- team size, release schedule, build process, testing etc -- which mean that each team's flow will be somewhat specific.
And as for commit messages, I have developed a system which helps me write more meaningful messages with just a little bit of discipline: instead of summarising what I did, I try to figure how would I give instructions to someone to do the same. So I have things like "refactor MyBigFunction to individual methods" or "change SomeSetting to use float instead of int" or "implement NewClass".
Author here. Yeah, the lack of authorship (and any kind of user awareness, really) is a pain.
There are so many ways in which Git has simply failed. It was basically an experimental piece of software designed for a hypothetical world which never really eventuated. Truly distributed version control (code shared between different servers) turned out to be a fringe use case, and the vast majority of all collaborative developed source code has a primary repository. So it has all these features built around the edge case, and a lack of features for the primary case (many users, with different levels of trust, contributing to one repo).
It's been discussed on HN before, but gitless[1] is worth checking out. They've taken a structured approach[2] to finding git's most confusing UX "idiosyncrasies" and tried to address them. As a user of regular old git I can't personally speak to how successful they've actually been but it's interesting nonetheless.
Even better - write a chat bot for git hahaha :D make it so it can help you get out of tricky situations and not have search stackoverflow all the time
I started using git as a hobbyst with the help of smartgit. It somehow made me realize what is git all about the 200x better than any tutorial. I use command line too, but things like diffing, adding files etc. it just makes life easier. Seriously you're a masochist if you don t use it. It'd free for personal use!
The thing that gets me every time is the git sub-commands which have multiple orthogonal uses, without so much as a command line flag to differentiate them.
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...
I'm working with a small team that uses CVS and I'm I'm in charge of recommending more modern version control software. I've been learning git since it seems to be the new standard, but after reading this, I don't think we have the time it will take to learn it. Is there another open source vcs that would be a more natural upgrade to CVS?
Specifically for the requirement "Is there another open source vcs that would be a more natural upgrade to CVS": the answer is hands down Subversion for that requirement. If you want distributed or "more modern" but not git, perhaps Mercurial or Bazaar, but they're less prevalent choices.
Thank you! Subversion does seem like a great fit. Mercurial seems like it might be easier to use (Facebook uses their own customized version [1]), but we don't need distributed at this time.
82 comments
[ 4.9 ms ] story [ 151 ms ] threadI second this. Trying to go from SVN to git left me confused and frustrated, while I found it much easier to switch to hg. Once I had been using hg for a while, I found that I had absorbed enough of the difficult/confusing stuff that switching to git was relatively painless.
Blaming users for not understanding a bad interface is one of the classic mistakes.
It took me a while make the mental jump from svn style branches to git style and from no stage to having a stage but I'd never want to go back now that I understand them.
In my experience, once you get into more complicated commands like rebase, I had to read a lot of docs to get things to work in both systems, so I'd say hg is easier to get started with but they're on par overall in terms of complexity.
As a sidenote, I think the ability to `rebase -i` work branches and squash, edit, and drop changesets is a very useful feature, and it's made very easy in git. Mercurial can rebase branches, but it really doesn't like it...
Granted, I learned git first and had been using it for 6 years before using hg.
1. The UI is more consistent ie. the "update" command only does 1 thing updates your working directory to a specified state.
2. It doesn't have a pre-commit staging "index" like Git (or it at least doesn't expose it to the user. So workflow is a bit for straightforward ie. you don't need to constantly "add" files before you commit, it automatically does it for you.
Plus, while the UX of git is not intuitive, especially from SVN, if you want to bypass staging and just use it like SVN, you can "git commit -a". Like svn, if you have new, untracked files, you can "git add -A; git commit". This is also trivial to alias.
"I don't like it and here's a heap of examples which lead me to arrive at my preordained conclusion that it's completely broken": cool, you've found issues. If you can, fix them and share. If you can't or won't... well, there are other tools for doing version control and perhaps another might suit you better. If you have to work with people that use git, I'm sure there's some way you can generate patch sets and still get stuff done.
Fixing the implementation means changing code, improving APIs (e.g. local/remote branch delete).
Fixing the model means finding an everything different system. Yes, a graph-based VCS more complicated than a linear one. But it also matches realities of collaborative software development. And reality is complicated.
As you might guess, I'm sympathetic to criticisms of inconsistency or unnecessary effort, but I believe Git (and other DCVS) to have the completely correct idea about collaborative text versioning.
My problem is implementation.
Which DVCS implementation do you like the most?
And even then you don't want to create a joystick which pulls up when pushing forward.
I could write a similar article about how FTP is so much easier to use than SVN and it would be equally silly.
That is not to say that Git isn't inconsistent and the docs are terrible, but there are good tutorials out there. If I were more helpful I'd have a link to one here but I'm on my phone.
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 so I wouldn't have to waste my time explaining the same stuff for the umpteenth time.
Edit: Thanks to lyall for the links. He posted below. [1]: http://gitless.com/ [2]: https://people.csail.mit.edu/sperezde/oopsla16.pdf
Never felt the need or desire to try anything else.
It's not unlike a programmer who only knows GWBASIC saying they feel no need for recursion because they never wrote any code that relied on it, or named functions, because subroutines can do that. Or a C programmer who thinks class-based inheritance is superfluous syntactic sugar.
I don't mean it as an offense, mind you, but your lack of experience in DVCSs makes your opinion suspect. Spend a month actually working with Bzr or Mercurial and then, having been exposed to different solutions to the same problem, your opinions will be much richer.
I find Fossil way, way more friendly and useful for individual users and teams.
http://fossil-scm.org/
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.
The fundamental promise of any version control system is this: “Once you put your precious source code in here, it’s safe. You can make any changes you like, and you can always get it back”. Git breaks this promise. Several ways a committer can irrevocably destroy the contents of a repository:
That should not be possible.Mandatory XKCD: [1]
[1] https://xkcd.com/1597/
Also, I suspect that many of the "hosted git" implementations out there prevent this from happening by default. I know that both of the ones I use in my day job (gitlab and bitbucket) do, but I'm not 100% certain it's a default as opposed to something our ops guys did. In any case, far from impossible. EDIT: see boaardwalk's post.
Also, svn won't protect you from `rm -rf /` on the server, while git will, which is pretty cool.
The examples in this article are the crowning example of why their painful death would be well-deserved.
There's this thing about bedside manner that technically adept people need to cultivate, just as doctors do.
Did I mention I despise cold, snotty doctors too?
There's nothing worse than a condescending prick doctor wielding authority against you, when your sick or need medication and just trying to find help. The doctors that do this, know that they can cast a long shadow by dropping hints that they aren't on your side.
It's kind of the same scenario, and I try to remember how I've felt as a patient, when people ask me for help. You can usually grasp what people are really after, when their trying to figure something out, and ask for even a hint in the right direction.
It's the mark of rotten bastard that won't give even the slightest helping hand to someone who's on the same team. Pure evil, when you've helped someone with simple questions, and they sneer at you, given the chance to reciprocate.
Example: This one piece of shit sees a co-worker and I struggling with some retarded group policy problem on a windows machine. My co-worker is slightly clueless, but that's okay because he's not a fucking asshole. POS intervenes, starts driving on clueless co-workers machine, pops open mmc.exe twiddles a setting, and fixes the thing. I need to do the same thing. I ask him, so what was the fix?
I have sworn a blood oath to myself that before I die, I must slaughter this man's progeny, and proclaim his seed wiped from the earth, before caving in his skull with a tomahawk, eating his heart raw, and adorning my breech clout with his scalp.The best thing in your comment is this sentence:
There's this thing about bedside manner that technically adept people need to cultivate, just as doctors do.
That's a well-put sentence, plus, I feel like you're on to something. I feel the same way, incidentally. I don't think it's productive or collegial to tell someone to "RTFM" or "use Google". If you're struggling with something right in that moment, the best thing to do is show some kindness and empathy and sit down and help. Then, once the problem is resolved, that's the moment where you can "teach a man to fish".
You seem like you have a talent for writing and your vocabulary and prose are quite good - just rework the tone and omit the profanity and you'll see some upvotes.
To get a "fancy oneline log" output, add the following to your `~/.gitconfig`
then run It's great when rebasing your way out of spaghetti-commitlog situations.I personally have this in my ~/.config/git/config:
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 what are you doing. So you can't directly compare git with something like subversion. And git ≠ github.
Some points are valid: bad and unclear documentation, no "included" workflows, bad command line UI. Author also didn't mention authorship issues, it's a real pain.
That said, the command line UI really is infuriating - checkout means 3 different things depending on what the argument is, it's never clear to me whether I should be using "origin master" or "origin/master," etc. I'm also not entirely sold on the usefulness of the index, but perhaps that's cause I'm still new to using git.
[1] https://github.com/petervanderdoes/gitflow-avh
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.
https://git-man-page-generator.lokaltog.net/
It describes advanced features like `git-govern-origin` and `git-organize-head` [0].
[0]. https://git-man-page-generator.lokaltog.net/#26463b871524ca4...
I mostly write ML code as a single author and there's a lot of experimenting going on, so often I sit at the end of the day and write a commit message along the lines of "dicking around" or "updated some files" and feel like I might as well just sync my stuff with Dropbox and not have to worry about all the GIT commands.
They're naturally recommending the GitLab Flow, but a good approach is to read through it and choose what might work for you. The important thing is to keep in mind that there are countless variables that will likely be different for each team -- team size, release schedule, build process, testing etc -- which mean that each team's flow will be somewhat specific.
And as for commit messages, I have developed a system which helps me write more meaningful messages with just a little bit of discipline: instead of summarising what I did, I try to figure how would I give instructions to someone to do the same. So I have things like "refactor MyBigFunction to individual methods" or "change SomeSetting to use float instead of int" or "implement NewClass".
There are so many ways in which Git has simply failed. It was basically an experimental piece of software designed for a hypothetical world which never really eventuated. Truly distributed version control (code shared between different servers) turned out to be a fringe use case, and the vast majority of all collaborative developed source code has a primary repository. So it has all these features built around the edge case, and a lack of features for the primary case (many users, with different levels of trust, contributing to one repo).
Gitless is pretty cool. http://gitless.com/
[1]: http://gitless.com/
[2]: https://people.csail.mit.edu/sperezde/oopsla16.pdf
www.bitkeeper.org
It could use neural network for this for all I care. Anything but merging lines as if they contained completely meaningless string of characters.
I mean, it already does everything under the sun, so there's a challenge for anyone up for it!
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...
[1] https://changelog.com/posts/facebook-mercurial-git