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

331–340 of 390 posts

Re: Gitless: a version control system

#331

Post by rkangel »

rplst8 wrote: post #101
zajd wrote: post #67

Earlier quoted context omitted.

https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background

Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it. It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the…

Software allows a better abstraction of a problem than anything in the mechanical world. Progression in software craftsmanship has shown us that powerful functionality can be hidden behind a simple interface, if sufficient thought and design is put into it.

Our expectations of how we interact with software have risen over the years, and that's a good thing.

Re: Gitless: a version control system

#332

Post by arielb1 »

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:…

`git checkout` is indeed a stupid command, because it has 3 modes:

> git checkout [--detach|-b]

Set HEAD to a new place and sync the working-directory/index to it.

> git checkout

Copy paths from the index to the working directory.

> git checkout

Copy paths from a given commit to the working directory.

This means that "git checkout HEAD file" is different from "git checkout file".

Similarly, `git reset` has 2 modes:

> git reset

Copy paths from a given commits to the index, leaving the cwd unchanged.

> git reset [--soft | --mixed | --hard]

Set *HEAD to a new place, and optionally sync the working directory/index to it.

This is obviously terrible, but changing the names now might be worse.

Re: Gitless: a version control system

#333

Post by Certhas »

zajd wrote: post #277
Certhas wrote: post #263

Earlier quoted context omitted.

It wasn't entirely obvious what you were responding to in my post exactly. That article is satire, but if you don't even want to accept that maybe the git commands are badly named (and besides your one bad example, there are plenty of real examples in the satire) I don't see much point in having a discussion. It being "just a wrapper around git" is an excellent argument that the user interface and usability are probl…

Thank you so much for posting that pdf, that really should be posted somewhere on that site because without the context just throwing out "it's git without a staging area" seems like a pretty poor argument. After reading the whitepaper I would still say that I'm not sure there's much value in the project, that being said they did manage to simplify the "mental model"... although honestly not by much. I'm not sure the…

No problem, BTW, in my mind it's getting rid of the (need to) stash and improved management of untracked files that are the major simplifications, not staging.

In my workflow I also see no cost, but I am happy to accept that that's because we don't have very sophisticated needs.

Re: Gitless: a version control system

#334

Post by Nursie »

ubernostrum wrote: post #291
chowells wrote: post #216

Earlier quoted context omitted.

"Professional" doesn't mean "Poorly designed". It means "designed so that people with lots of domain knowledge and experience with the tool find that it never gets in their way." In that sense, git is a professional tool. If you know everything about it, it doesn't get in your way. The problem is when you don't know everything about it..

In this sense, trivially, every tool is a "professional" tool, since if you just rote-memorize every aspect of it you know how to do everything it can do. The problem with git is the lack of coherence in its default UI. Multiple ways to accomplish the same task, git commands which perform incredibly different functions depending on (invisible) context, inability to decide whether commands or flags should act as the h…

No, trivially, there can be tools that you know inside out which still present roadblocks to perfectly ordinary tasks and be a bad fit for the domain they operate in.

Visual SourceSafe springs to mind here...

Git, by comparison, is very flexible and allows you to do an awful lot, when you've learned it. You can learn SourceSafe inside out and still have it be a total pain in the arse.

Re: Gitless: a version control system

#335

Post by globuous »

copperx wrote: post #293
matt4077 wrote: post #124

Earlier quoted context omitted.

This is very close to the result of the study that was I believe he reason to write gitless: - Most people use git by learning a set of a few commands - A minority actually understands git on a deeper level But both groups form a mental model of how git works, and that model is apparently usually wrong, which results in those cases were you get stuck and just start with a fresh checkout and manually reapplying the ch…

If both groups get the mental model wrong, how can we ever hope to get it right? read the Git source code?

No, but there's a book called "Pro Git" by Scott Chacon and Ben Straub that popped up on HN not too long ago. It does explain git on the lower level without going into the git source code.

This book is over 500 pages, but chapters 1 to 3 will get you up and efficient within 2 hours. Especially chapter 3 (I skipped to it, I kinda knew the basic git commands from "experience"), which goes over branching and how it works. It explains how snapshots are handled and what points to what, which make working with multiple branches locally and remotely a pleasure actually.

It's honestly not to hard to get decent at git. Although I never realized how much of a tool git was until I heard about people writing 500 page long books about it.

Re: Gitless: a version control system

#336

Post by siberianbear »

g0xA52A2A wrote: post #14
chvid wrote: post #7

To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.

Not sure why this appears to be been down voted. Git's command-line interface IS terrible. Certainly not unusable as most of interact with it every day. A somewhat satirical example of this is Steve Losh's Git Koans. http://stevelosh.com/blog/2013/04/git-koans That's not to say I don't think the underlying ideas of how Git works makes sense. I certainly think it's a lot better than RCS, CVS and SVN (never tired Mercu…

I realize that Hacker News generally frowns on "+1" types of comments. But those Koans are really funny. Every single one made me laugh out loud. I remember the pain of git.

I hated git. Every time I used it I wanted to curl up in a soft, warm, dry space... like Perforce or SVN.

Re: Gitless: a version control system

#337

Post by croon »

nine_k wrote: post #271
tree_of_item wrote: post #187

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.

Is an aircraft cockpit a poorly designed ux? It does require a fair bit of learning.

Hell yes. Why does [established practice] have to mean [best practice]?

With all the security concerns and regulation regarding flight, it's easy to imagine how hard it is to move forward and innovate in usability.

I'm not saying upending git for something better would be trivial, but I don't want to constrain my imagination by thinking it's not possible.

If you can coherently explain what you need [git replacement] to do, and explain it simpler than you would explain git itself, then you have an outline of a superior tool.

Re: Gitless: a version control system

#338

Post by croon »

jomamaxx wrote: post #312
redwall_hp wrote: post #290

Earlier quoted context omitted.

Professional means it doesn't sacrifice functionality in favour of making things easy for newbies. This is a philosophy I approve of for all software. Vim is great because it offers power at the expense of having a little bit of a learning curve. A shell gives you unlimited power compare to a stripped down and locked down GUI. GUIs and "UX" are generally antithetical to making a computer do what it does best (automat…

"GUIs and "UX" are generally antithetical to making a computer do what it does best (automate things instead of creating more busywork)." Except for helping the 6 or so billion people in their daily lives, but hey, the iPhone would be 'better' if it just had 'bash'? Read your email lately from bash? Didn't think so!

False equivalence. We wouldn't have billions of users if there were no other agents than users. You can't create an iphone using an iphone.

Re: Gitless: a version control system

#339

Post by matt4077 »

globuous wrote: post #335
copperx wrote: post #293

Earlier quoted context omitted.

If both groups get the mental model wrong, how can we ever hope to get it right? read the Git source code?

No, but there's a book called "Pro Git" by Scott Chacon and Ben Straub that popped up on HN not too long ago. It does explain git on the lower level without going into the git source code. This book is over 500 pages, but chapters 1 to 3 will get you up and efficient within 2 hours. Especially chapter 3 (I skipped to it, I kinda knew the basic git commands from "experience"), which goes over branching and how it work…

I never realized how much of a tool git users were before I knew there are 500 page books about it....

This whole thread is evidence of two opposing viewpoints: "git is too hard" and "git is powerful, professional tool and that requires some effort".

I believe those making the latter point misunderstand the first group (to which I belong): I'm not opposed to putting in some time to learn a tool that's central to my craft.

But git seems to often be complicated not because of the complexity of the underlying problems, but because of choices made in its implementation.

Consider: If you have a decent understand of information theory, you'll be able to use any database system within a short time, even if you never had heard of SQL before. Indeed, with a few years of SQL, you'll quickly understand NoSQL systems as well – coming from Postgres, I was productive in Redis within half an hour.

But no amount of experience with VCSs will allow you dive into git without hitting a brick wall.

Re: Gitless: a version control system

#340

Post by eriknstr »

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…

After having used git for a few years, I identified what commands I use most frequently and have created two-letter aliases for these;

    alias st='git status'        # STatus
    alias dp='git diff'          # Diff Pending
    alias aa='git add .'         # Add All
    alias di='git diff --cached' # DIff
    alias cm='git commit -m'     # CoMmit
    alias pu='git push'          # PUsh
I've added comments above to show you what I think in my head when I type the two-letter alias in question.

I have a few other two-letter aliases for git as well but the ones above cover about 80% of my use I think.

For the remaining 20% I usually type the command out fully even if I have an alias for it, because those less-frequently used commands are harder to remember the aliases for, whereas the aliases that cover the 80%, I have those in my fingers now without having to think about it.

Post reply on HN