101–105 of 105 posts
Earlier quoted context omitted.
> Would you kindly post your superior git CLI? Or at least the outline of it? You are literally replying to a comment that describes a possible better CLI for git...
I suspect it was added in an edit in response to this comment. Dad is downvoted!
Earlier quoted context omitted.
git has a very clear, concise and stable interface if you understand how git works. it's designed this way, intentionally. people should stop complaining about it and either learn how to use it, switch to another tool or just write their own interface
It's not possible to switch to another tool unless you only ever work on code that you wrote, and never need to collaborate with anyone else.
Earlier quoted context omitted.
git is FUCKING HARD due to its tons of poorly designed misfeatures. The index/cache/staging area is the worst of them. If git wants to make any progress towards actual usability, this mess needs to be untangled with prejudice. Other tools have none of this overly stateful bullshit. When I want a file to be included in the next commit, I don't want a silent, implicit copy to be whisked away into some interal storage t…
tl;dr; a monkey is given a hammer and is baffled by utility. rofl. git is perfectly usable. proven by the hundreds of thousands of people using it daily. most of your 'complaints' here are not actually how git works in reality, and are just user error due to not bothering to learn the tool. 1. git never destroys your work inside a repository unless you told it to. 2. git doesn't 'whisk' things away implicitly. you co…
1. a) git's garbage collector runs without asking first. b) git's UI is so bad that users regularly end up in a state where they effectively asked git to destroy data without realizing it. It's often too implicit.
2. Ever modified a file between git add and git commit? Did these extra changes get committed? Some graphical clients try to hide aspects like this.
3. Unlike SVN, hg etc. git has superfluous extra state with complicated rules. The fact that the cache/index/staging area is inconsistently named three different things just illustrates how byzantine these rules are. And they can be done away with completely.
4. A rose by another name wouldn't smell as sweet - our senses of taste and smell are easily influenced by our other observations about an object. Human perception is weird. In the same vein, bad naming of features invites more usage errors.
Earlier quoted context omitted.
I find that a good introduction. “ All operations on a repository involve adding commits and/or manipulating the name resolution table. ” It may be simplified, but that statement alone, taken in context, is worth its weight in gold.
Thanks! It's simplified, but really, not that much.
"a bag of "commits" identified by a cryptographic hash value and which organize into trees via parent commit references in each commit"
Say what?