Gitless: a version control system • Hacker News Board

Re: Gitless: a version control system

#221

Post by StavrosK » Sun, Oct 02, 2016, 7:37 PM UTC

pjc50 wrote: post #210

lbotos wrote: post #208

Earlier quoted context omitted.

What I'm saying is, Gitless is cool, BUT beginners are always looking for ways to cheat the effort. My point is, this is a great tool if you understand git, and want to use a shim, but for beginners, going straight to the shim is not good. >If it does everything Git does, but more easily, it is strictly superior. In the abstract I agree, but if an junior dev goes "oh, I just use gitless because it's easier" and DOESN…

cheat the effort I'm always suspicious of arguments like this, because they have a Luddite quality to them. Isn't sending email versus handwritten postal mail "cheating the effort" of communication? git is a lot of effort to learn because its command line is inconsistent and it is frequently unclear what it has done, why and how to recover from it. It is worth asking if this is really necessary. If a system has a hig…

This is spot on, thank you. The git porcelain is very inconsistent between commands, and that really muddies the view of the underlying model. I would argue that a cleaner porcelain would lead to more easily building a mental model of the data structures.

Re: Gitless: a version control system

#222

Post by bluejekyll » Sun, Oct 02, 2016, 7:41 PM UTC

arielb1 wrote: post #127

bluejekyll wrote: post #42

Earlier quoted context omitted.

I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous. UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands. Quick examples: 'git reset' vs. 'git revert' and sometime 'git checkout' 'git checkout' vs.…

How are `git reset` and `git revert` related? How are `git fetch` and `git cherrypick` related?

In my mind you use many of those commands to perform actions in the repo or locally which are related.

For example: 'git reset HEAD~1' is something I use often, it is vaguely like 'git revert '. Therefore I see them as providing similar functions semantically, but not literally.

'git fetch' and 'git cherrypick' are again similar in my mind where one is pulling changes from a remote, while the other pulls a set of changes from one branch into another locally. This is not as good an example though, but I do think they have slightly overlapping concepts.

Re: Gitless: a version control system

#223

Post by strictfp » Sun, Oct 02, 2016, 7:42 PM UTC

jjoonathan wrote: post #220

lisper wrote: post #198

Earlier quoted context omitted.

git checkout // throw away all changes since the last commit (one file) git reset --hard // throw away all changes since the last commit (all files) This is a perfect illustration of why git needs a better UI. Two different commands to do exactly the same thing, with the only difference being that one is for one file and the other is for many files? If you tried to design a hard-to-use UI you could hardly do better t…

But they don't do "exactly the same thing, with the only difference being..." unless you ignore the index, which is one of the extremely powerful abstractions that sets git apart. Sure, git could expose a simplified lowest-common-denominator interface that plasters over its differences, but the same interface would (and gitless does) plaster over its strengths and encourage people not to learn them. I agree with TFA:…

They don't do the same thing implementation wise, but they do the same thing ux wise. This difference causes all discussions like the above: it seems as if some people like ux "plaster", while others like bare-metal tools.

Re: Gitless: a version control system

#224

Post by [deleted] » Sun, Oct 02, 2016, 7:43 PM UTC

nicky0 wrote: post #147

KKKKkkkk1 wrote: post #112

Earlier quoted context omitted.

As a tangent, I think calling git a distributed system is misleading. Git is primarily a history manager for a local directory tree that has commands to sync with remote machines. Having to type stuff like git remote add mothership ssh://foo@bar.baz git push mothership in order to sync is not what I usually associate with a distributed system. The word distributed conjures something that's more like dropbox, where th…

"Distributed" means something other than what you think it does. Dropbox is not a distributed system. In fact it is a good example of a centralised system.

[deleted]

Re: Gitless: a version control system

#225

Post by djur » Sun, Oct 02, 2016, 7:44 PM UTC

lisper wrote: post #198

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

git checkout // throw away all changes since the last commit (one file) git reset --hard // throw away all changes since the last commit (all files) This is a perfect illustration of why git needs a better UI. Two different commands to do exactly the same thing, with the only difference being that one is for one file and the other is for many files? If you tried to design a hard-to-use UI you could hardly do better t…

They do different things, anyway. `git checkout ` will restore files from the _index_, which means it actually discards changes since the last `git add`. It can also be used on the entire tree as `git checkout .`. (As an aside, I think that the different branch vs. tree behaviors for `git checkout` are the biggest UX wart in git.)

`git reset --hard` discards the index _and_ any unindexed changes. You can think of it as essentially `git reset` (which discards the index) followed by a `git checkout .`

I think a lot of the murkiness of git's usability comes from the fact that many commands have collected convenience flags that replicate the behavior of other commands. The rest comes from the fact that `git checkout` and `git reset` can affect any or all of 1) the contents of the working directory 2) the contents of the index 3) the contents of repository metadata like branch tips and HEAD, and you pretty much just have to learn what does what.

Re: Gitless: a version control system

#226

Post by djur » Sun, Oct 02, 2016, 7:45 PM UTC

strictfp wrote: post #223

jjoonathan wrote: post #220

Earlier quoted context omitted.

But they don't do "exactly the same thing, with the only difference being..." unless you ignore the index, which is one of the extremely powerful abstractions that sets git apart. Sure, git could expose a simplified lowest-common-denominator interface that plasters over its differences, but the same interface would (and gitless does) plaster over its strengths and encourage people not to learn them. I agree with TFA:…

They don't do the same thing implementation wise, but they do the same thing ux wise. This difference causes all discussions like the above: it seems as if some people like ux "plaster", while others like bare-metal tools.

They only do the same thing if you haven't previously used `git add`. If you have, `git checkout` will use the contents of the index, not the contents of the last commit.

Re: Gitless: a version control system

#227

Post by admax88q » Sun, Oct 02, 2016, 8:00 PM UTC

ITT: People trying to justify all the time they spent becoming experts on git's esoteric interface.

Re: Gitless: a version control system

#228

Post by lisper » Sun, Oct 02, 2016, 8:05 PM UTC

djur wrote: post #225

lisper wrote: post #198

Earlier quoted context omitted.

git checkout // throw away all changes since the last commit (one file) git reset --hard // throw away all changes since the last commit (all files) This is a perfect illustration of why git needs a better UI. Two different commands to do exactly the same thing, with the only difference being that one is for one file and the other is for many files? If you tried to design a hard-to-use UI you could hardly do better t…

They do different things, anyway. `git checkout ` will restore files from the _index_, which means it actually discards changes since the last `git add`. It can also be used on the entire tree as `git checkout .`. (As an aside, I think that the different branch vs. tree behaviors for `git checkout` are the biggest UX wart in git.) `git reset --hard` discards the index _and_ any unindexed changes. You can think of it…

Yes, all this is exactly my point. It is nearly impossible to explain the current git UI in a way that isn't embarrassing at best and wrong at worst. And then it's nearly impossible to remember. The number of things you actually want to do 90% of the time is small, so I think there is value in designing a veneer that makes that 90% easy to explain and remember.

Re: Gitless: a version control system

#229

Post by jjoonathan » Sun, Oct 02, 2016, 8:07 PM UTC

strictfp wrote: post #223

jjoonathan wrote: post #220

Earlier quoted context omitted.

But they don't do "exactly the same thing, with the only difference being..." unless you ignore the index, which is one of the extremely powerful abstractions that sets git apart. Sure, git could expose a simplified lowest-common-denominator interface that plasters over its differences, but the same interface would (and gitless does) plaster over its strengths and encourage people not to learn them. I agree with TFA:…

They don't do the same thing implementation wise, but they do the same thing ux wise. This difference causes all discussions like the above: it seems as if some people like ux "plaster", while others like bare-metal tools.

They do the same thing ux wise if and only if your mental model has no notion of a staging area.

Re: Gitless: a version control system

#230

Post by maker1138 » Sun, Oct 02, 2016, 8:10 PM UTC

I'm surprised at how many people are responding negatively to software that improves user experience.

Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed.

The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging functionality if you like, and use gitless for most other commands. I think it is a win.