Live data from Hacker News

Gitless: a version control system

gitless.com

251–260 of 390 posts

Re: Gitless: a version control system

#251

Earlier quoted context omitted.

I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions. Look: http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support. If…

This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the opt…

>git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags.

I'm curious, how would you redesign git checkout to handle each of those different types of inputs? For me, while it appears cumbersome, understanding that a file is different from a branch and commit head seems to alleviate this problem.

Re: Gitless: a version control system

#252

Earlier quoted context omitted.

I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions. Look: http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support. If…

This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the opt…

>git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags.

I'm curious, how would you redesign git checkout to handle each of those different types of inputs? For me, while it appears cumbersome, understanding that a file is different from a branch and commit head seems to alleviate these problem.

Re: Gitless: a version control system

#253

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…

"dumbed down" only improves the user experience of new users. It hurts power users and is rarely useful to anyone other than newbs.

It can be net gain for infrequently used and rarely mastered tools. Source Control should the 2nd (after editor) most mastered tool of a developer.

Many will assume this is "dumbed down" interface and thus overall bad for source control tool.

Re: Gitless: a version control system

#254
post #212

Earlier quoted context omitted.

> Git is, like many professional tools, something you simply got to learn. No. Why do people think "professional" has to mean "poorly designed"? But then, the rest of your post seems to miss the point of this thing entirely. You go on to say that you basically only need 10 commands...which is pretty much the insight that lead to Gitless in the first place.

Why would someone write a tool for 10 commands?!

No one here did that. What are you talking about?

Re: Gitless: a version control system

#255
post #93

Earlier quoted context omitted.

> With git, I'm forced to either make an extraneous commit... You only need to commit or stash if there are conflicts, and many time there aren't, so you can first try to switch branches without stashing. > The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch I started a big ol thread on stash yesterday, but there are a bunch of s…

The whole advantage of stash, the way I see it, is that you don't need to type out a whole bunch of commands to stick something into another branch and deal with remembering where you put it and what you called it and so on. I started out using secondary branches since that was the intuitive way of doing things, and I had issues with stash before, but after a while I went back to using stash again because it's just s…

Stash for you is fine, you obviously know what you're doing, and you use it carefully. And if you're comfortable with fsck, you really don't have to worry.

OTOH, the alternative workflows are really not that hard, it's really not a ton of commands compared to using stash. The single most common use case I've heard so far is switching branches, and for that you can skip stash the majority of the time, many people don't seem to know that.

Your example was stash during a pull, if you do that, your workflow is:

  $ git stash
  $ git pull
  $ git stash pop
The alternative is:

  $ git commit -am "WIP"
  $ git pull
  $ git reset --soft
Not only is it the same number of commands, and safer, it's also less to remember because you don't have to use the stash subsystem at all. Commit, pull, and reset are commands you have to know regardless, you can't avoid them. Stash isn't one you have to know to use git. Stash is adding to the things you have to remember, or taking up space in your head that could be used to learn flexible ways of making temporary commits & branches.

Re: Gitless: a version control system

#256
post #93

Earlier quoted context omitted.

> With git, I'm forced to either make an extraneous commit... You only need to commit or stash if there are conflicts, and many time there aren't, so you can first try to switch branches without stashing. > The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch I started a big ol thread on stash yesterday, but there are a bunch of s…

I wish git would deprecate stash and replace it with something like this, that doesn't have any magic and just uses the existing branch system. It would generate a new temp branch every time using a counter system, e.g. "stash1" "stash2", so all the temp branches effectively form a stack. The stash popping behaviour can still be supported this way (popping would cherry-pick and delete the highest numbered branch). It…

Yeah, exactly. I don't understand why stash wasn't done this way. They didn't have to circumvent the reflog, it was a choice, and one that bites a lot of people.

Re: Gitless: a version control system

#257
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 is, like many professional tools, something you simply got to learn.

Or, you can use a tool that is built for purpose aka doesn't suck). I don't use a Stanley #55 Plane to trim an edge even though it can.

Mercurial, the author notes, doesn't have most of the pitfalls. Yes, everybody persists in using git because "Linus used it".

Re: Gitless: a version control system

#258
post #198
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 are not doing the same thing. It's two completely different operations.

Re: Gitless: a version control system

#259
post #183

Earlier quoted context omitted.

git UI == git command line in this context. I don't think anyone in this subthread is talking about G UIs.

My apologies - I saw UI and immediately thought of Git's GUI clients. I don't think git's command line needs to be changed, though.

Because it's perfect? Because it's familiar? I'd be curious to know why.

Re: Gitless: a version control system

#260
post #121
post #108

Earlier quoted context omitted.

> Git is, like many professional tools, something you simply got to learn. Nailed it.

Agreed. I'm seeing terms like "elitist" being thrown around below for "git apologists" when it's simply a matter of learning a tool. Not everyone needs all the power of the git CLI and the complications it brings - but when you do need it, it's there to fix the dumb things we all do sometimes. I think if you look deep in the guts of Clearcase for example you will see nastiness that makes git look like the ls command.

No-one is disputing the power of git. People are merely pointing out that it's textual user interface is clunky and inconsistent. Just because it won the DVCS wars doesn't mean the conversation needs to end and we have to accept this is as good as it gets. It won despite it's CLI not because of it.
Post reply on HN