Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitless: a version control system

gitless.com

Post reply on HN
Print view View original

231–240 of 390 posts

Re: Gitless: a version control system

#231

Post by nkurz »

popmystack wrote: post #217
nkurz wrote: post #214

Earlier quoted context omitted.

> Then leave the thread > you're both a hypocrite and a troll > I'm not going to respond to you anymore past this Feedback from the outside: ajkjk strikes me as someone making reasonable points and who is capable of productive discussion. You are coming across as unnecessarily arrogant and prickly, and thus someone with whom it's best to avoid discussion. Maybe you are an extremely fluent but non-native speaker of En…

You consider his first post to be productive? You must be dreaming. > ajkjk strikes me as someone making reasonable points He is not making any point, so it's weird that you would say that. He hypocritically stated I was coming off as arrogant. Fair game, even though I really don't see how it remotely comes off that way, but you can't exempt yourself from your own criticism in a post that does not constructively furt…

I most definitely will not, as this is a technical discussion.

For better or worse, like most discussions, it also has social aspects. Consideration of these aspects may help you better convey your technical points.

What's the point?

Based on your comment history, you have technical knowledge that others could benefit from, but aren't very successful in getting your point across without being downvoted or flagged. If you continue with your current approach, at some point your account will likely be banned. Whether they are exactly accurate or not, I think contemplating ajkjk's criticisms may help provide you insight that will allow you to have better interactions with HN.

The fact that you decided to continue this non-sense is mind-boggling to me.

I am generally a very technical person, I use git frequently and only by the command line interface, I think I mostly understand the underlying operations, and yet I frequently am baffled by the commands required to get from where I am to where I want to be. While I likely can overcome this through study and repetition, I think git would be a more useful tool for others in the future if the user facing command line interface was improved.

Viewed over the longer term (and I say this as someone who approached git through RCS, CVS, and SVN and likes the improvements Git offers) the current interface is not perfect, is not set in stone, and improvements are a good thing. Assumptions that the 'gitless' authors are only doing this because they do not properly understand the internals of git are likely incorrect. While I don't think 'gitless' quite has the right solution, I think attempts to better align git's command line interface with the underlying operations are commendable, not pointless, and decidedly not nonsense.

Re: Gitless: a version control system

#232

Post by na85 »

rplst8 wrote: post #28

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…

I don't like git because I have zero confidence that it won't do something dumb like fail to diff properly requiring me to merge 980 diffs in a single file while it puts the >>>>>>> markers in the wrong places, randomly transposing lines from one part of a file to another for no discernible reason.

You know, like happened to me today.

Re: Gitless: a version control system

#233

Post by Drdrdrq »

lisper wrote: post #228
djur wrote: post #225

Earlier quoted context omitted.

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.

Hg did that - unfortunately GitHub won over BitBucket, thus deciding the fate of Mercurial too.

Re: Gitless: a version control system

#234

Post by __david__ »

sametmax wrote: post #54
tiborsaas wrote: post #21

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…

> - stashing is dangerous. I've seen many students losing work with a stash pop requiring a merge which ended badly.

I've seen this assertion before, I don't understand it. If `stash pop` has conflicts and it gets confusing, you can always just `git reset --hard` and `git stash pop` again. The stash does not disappear if there are conflicts.

The only time you can lose data is if you explicitly `git stash drop`. So don't do that. And even then, the data is sitting in the git repo and can be recovered with `git fsck`. It's really hard to lose data with git.

Re: Gitless: a version control system

#235

Post by gnuvince »

maker1138 wrote: post #230

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…

I think the author address that point in the introduction:

> Experts, who are deeply familiar with the product, have learned its many intricacies, developed complex, customized workflows, and regularly exploit its most elaborate features, are often defensive and resistant to the suggestion that the design has flaws.

Having spent dozens, even hundreds, of hours learning the intricacies of the Git command-line, it must be extremely shocking and insulting when you are told that those efforts were in vain, because the original UI was not very good and an alternative can be grokked by people of varying levels of technical competence with only a fraction of the effort you put into the original thing. I think this is what we're seeing here: people will try and defend their time investment by arguing that a professional would learn the hard thing and not lower himself to easy-to-use tools, that the new UI hides some powerful features that are rarely used, etc.

Re: Gitless: a version control system

#236

Post by __david__ »

dahart wrote: post #113
sametmax wrote: post #54

Earlier quoted context omitted.

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…

> - stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly. Yes!! Stash has a problem that it's attractive to beginners, and its easier than other commands to hose yourself. It's a separate system for managing changes outside of commits, I don't get it. They could have made shortcuts to branch & commit. Mystifying. > What we need is a good UI on top of that. S…

> Yes!! Stash has a problem that it's attractive to beginners, and its easier than other commands to hose yourself. It's a separate system for managing changes outside of commits, I don't get it.

It isn't a separate system "outside of commits". Stashes are literal commits. If you were to write a script that made little WIP commits it would probably end up looking a lot like git-stash (which is literally just a shell script wrapper around other git commands).

Re: Gitless: a version control system

#237

Post by Drdrdrq »

Houshalter wrote: post #186
flusteredbygirl wrote: post #182

Earlier quoted context omitted.

Git's UI will never beat Git's command line. Not even close. It may be easy, but the command line is far more powerful, and way faster. Basic git usage is around 10 simple commands or less, and it's not like it's not well documented.

Command lines have no discoverability though.

Not true - you have Tab, --help and man pages.

Re: Gitless: a version control system

#238

Post by Pxtl »

Pxtl wrote: post #144
douche wrote: post #118

Earlier quoted context omitted.

As far as version-controlling art, I'd lean towards a system where checking a file out locks it from any other concurrent modifications. Unfortunately, trying to merge concurrent changes into an image file, for instance, is just about impossible. It's almost as bad trying to work with MS Office file types - I wish I could get people on my team to use something else that is more VCS friendly, like HTML or Markdown, bu…

My wife is a math teacher and trying to figure out a good workflow for her team has been illuminating. Only the one true desktop Word has a good formula editor, so they have to use that... and only SharePoint provides a good "open and save" workflow. So SharePoint it is. Anything to get them off timeshares.

Ick, fileshares. Autocorrect.

Re: Gitless: a version control system

#239

Post by k__ »

jjoonathan wrote: post #229
strictfp wrote: post #223

Earlier quoted context omitted.

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.

I just stage parts of my changed code before commit. So things I work on are un-staged mkst of the time. Which eliminates the problem, I guess.

Re: Gitless: a version control system

#240

Post by tadfisher »

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 wasn't designed to be used by humans. I can't find the quote, but Torvalds said at one point that intention of Git was to provide a content-addressable graph that more human-friendly tools could build upon for different use cases.

Those 10 commands are the beginning of the iceberg when you actually start using git with teams. Where are `rebase`, `merge`, `branch`, etc? These are all commands I use daily, they are complicated, and it's trivial to shoot yourself in the foot.

The problem is that you can learn those 10 commands and things will work, until they don't, and you as a beginner are now spending hours trawling StackOverflow to figure out how to, say, pull a commit from one branch to another (you might not know that such a process is called "cherry-picking").

It's telling that Torvalds said this more recently about git:

> The first Git For Dummies and Git Visual Quickstart books are going to be out in a couple of months, and that is the beginning of the end as far as I’m concerned. Those books mean the end of git expertise and github reputation as reliable indicators of geek status. Once a technology is adopted by the masses the extreme geeks find something more esoteric. Look at what happened to Ruby on Rails. The people stumbling their way through Rails to-do list tutorials have never even heard of DHH.

Post reply on HN