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

311–320 of 390 posts

Re: Gitless: a version control system

#311

Post by aidenn0 »

tadfisher wrote: post #240
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…

Here's one quote from Torvalds to that effect:

http://www.gelato.unsw.edu.au/archives/git/0504/0873.html

Re: Gitless: a version control system

#312

Post by jomamaxx »

redwall_hp wrote: post #290
nine_k wrote: post #271

Earlier quoted context omitted.

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

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!

Re: Gitless: a version control system

#313

Post by dahart »

projektir wrote: post #288
dahart wrote: post #286

Earlier quoted context omitted.

> Did you mean "git pull --rebase"? Yes. > Because this will result in there being a WIP commit in the middle No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. Doing a commit+pull+reset will always work exactly as easily as stashing. It's no less clean to commit & later reset than it is to stash & later pop. The difference is that if you commit you have a bigger…

> No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. I was talking about the non-rebase version. You didn't address the rest of my post: there are other cases. This will work for that particular case, but it's not a general-purpose solution. If I have branch X with config changes, and coworker wants me to switch to branch Y but I still want my config changes, wha…

Stash is not a general purpose solution. You don't ever need to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality.

What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, staged changes, unstaged changes, and you need to branch 3 commits ago instead? Stash doesn't help with either of those, and the workflow I'm advocating - just use commits and branches for temporary work - does.

Stash really only helps you if you don't like to commit often, and you spend most of your time with unstaged changes in your working tree. Nothing wrong with that, if that's how you like to work, but I think if you spend some time getting used to committing more frequently you may find it much more flexible and much safer and more forgiving than trying to keep everything straight in the working tree alone.

If you have uncommitted changes in X, and you want in Y instead, then you can:

  $ git checkout Y
  $ git commit -am "config changes"
If you get merge conflicts, or if you want to keep the change in X too, you can:

  $ git commit -am "config changes"
  $ git checkout Y
  $ git cherry-pick X
The first case is fewer steps than stash, the second is just as easy as stash.

Popping a stash and cherry-picking a commit have the same process if there's a merge conflict, except that with a commit, you have undo capability if you merge incorrectly, and you have a safety net if you get lost or screw up in the middle of the resolution. With stash, you're stuck with a bad merge, and if you lose your stash -- and it happens -- you have to hunt for it by searching for dangling blobs.

You made a big deal out of having to create and remember and lookup hashes, and I don't see that as being an issue at all, and it's not a problem in my experience. You're comparing this to stash, after all, and stash only works on uncommitted changes, so there is never a case where you'll need a hash, because the stash equivalent is always at the tip of the branch, you can always use the branch name instead of a hash.

Re: Gitless: a version control system

#314

Post by rficcaglia »

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.

yes. and that's why as new planes are being produced, both commercial and small planes, they are replacing the older cockpits with fully electronic modern cockpit controls (with non-electronic secondary controls for power failure use)

many NTSB studies show that even master pilots with thousands of hours of training and flight time make (often fatal) mistakes due to confusion in understanding the cockpit readings

Re: Gitless: a version control system

#315

Post by dahart »

afro88 wrote: post #268
dahart wrote: 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…

> You only need to commit or stash if there are conflicts Unless you're wanting to take a look at the other branch clean, then you have to stash or do the extraneous commit. Most of the time I change branches to check someone else's work, or compare something that isn't working to develop/master. The stash/commit dance is a regular annoyance for me

This is true, you have to stash or commit, if you want to go to another clean branch.

But, your code is going to be committed & rebased later in your own branch anyway, right? If you commit some partial changes & later come back, make some more commits, and rebase/squash before pushing, you haven't done anything extra you wouldn't have done anyway.

By stashing, going away, then coming back, popping, working, committing, rebasing & pushing, you've added extra steps to the general case by involving stash, and you've added an extra failure point. If you commit instead, your changes are already there when you come back, and they stay associated with your branch while you're gone. It's harder to forget what you were doing, and it's much harder to lose your work accidentally if you commit.

I've witnessed the exact scenario you describe go bad several times when people go code review or test someone else's code, and the forget what they were doing. Sometimes people will stash again while working in someone else's branch, making it hard to keep track of which stash is which. That can lead to accidentally dropping stashes, or to popping the wrong stash.

Try only using 'git commit -am "WIP"' as a git stash replacement for a while and see if it really is any harder than stashing. To uncommit a WIP commit (which is always optional -- you could wait until you rebase -i) just 'git reset --soft HEAD^'.

Re: Gitless: a version control system

#316

Post by stevenhuang »

lisper wrote: post #280
popmystack wrote: post #258

Earlier quoted context omitted.

They are not doing the same thing. It's two completely different operations.

You'll have to take that up with /u/k__.

How so? You're the one proposing they do the same thing when they fundamentally do not. To posit so is less of git's "ux problem" and more of just needing to grok git.

I share your concerns for consistent tooling, but the idea of becoming proficient in something without putting in the effort is not reality.

Re: Gitless: a version control system

#318

Post by jcranmer »

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…

My first experience with a VCS was using Mercurial, about a decade ago. In that time, I've only had at most three or four instances where I so borked the repository that I had to destroy it and start again. This includes the time when I didn't know anything about VCS and was liable to foot-gun myself. I probably first used Git about 5, 6 years ago, and, despite using it at a much reduced frequency (virtually all my git usage is via hg-git nowadays), I've easily had a dozen times where it was easier to blow away a repository than fix it.

Obviously, heavy prior experience with Mercurial does color one's views about UX, but the experience with Git that I have had--and that I have seen many others concur with--is that the UX makes it way too easy to get you in states that you don't know what to do. But that's not the biggest flaw with Git. The biggest flaw is the community: when you don't know what to do, and you start trying to find the answer, instead of being told "this is how you fix it," you instead get a lecture on the full internals of Git, and why the crazy incantation should be really obvious to any user. Is it any surprise that one would find it easier to blow away the directory and recreate the five-line build system fix whose merge conflict caused the mess in the first place?

Your comment is a picture-perfect of this community hostility that I see with Git that I don't see with other VCS. There definitely seems to be a sentiment that there is One True Way™ to do things, and if you're not doing it like that, you are wrong. I care to disagree: a VCS is a tool--it should support my workflow, not dictate it. I find that the community around Mercurial is much more in agreement with the philosophy I hold, and unsurprisingly, I've generally found Mercurial to be superior than Git.

Re: Gitless: a version control system

#319

Post by lisper »

stevenhuang wrote: post #316
lisper wrote: post #280

Earlier quoted context omitted.

You'll have to take that up with /u/k__.

How so? You're the one proposing they do the same thing when they fundamentally do not. To posit so is less of git's "ux problem" and more of just needing to grok git. I share your concerns for consistent tooling, but the idea of becoming proficient in something without putting in the effort is not reality.

> How so?

Because he's the one who said that they do the same thing.

Re: Gitless: a version control system

#320

Post by friendzis »

shinymark wrote: post #296
Drdrdrq wrote: post #233

Earlier quoted context omitted.

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

I find Mercurial so much easier to use than Git. Many of the concepts are similar but the hg interface feels much easier to learn and use.

At $dayjob we have a mixed bag of hg and git. I found that while git makes great distinction between local and remote (and working directory), hg is more similar to centralized VCSes. Any other remote action than "sync local with remote" requires Blak Magick Mumbojumbo™. Some "common" (as seen by original authors. Local throwaway branch is not such) tasks are sure easier than git, but stepping out of the beaten path becomes cryptic. Git, on the other hand, is of average difficulty for most of the tasks. Your mileage may vary.
Post reply on HN