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

201–210 of 390 posts

Re: Gitless: a version control system

#201

Post by projektir »

dahart wrote: post #93
whack wrote: post #30

Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is…

> 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 so much faster to stash my config differences, do all the necessary merges or pulls or switches, and then just stash pop. A large part of the advantage is that stash is a bit orthogonal to the usual workflow, so it goes in a specially defined place in my brain vs being yet another branch, especially if I already have work/dev/backup branches for other purposes.

I agree that I wouldn't recommend using the stash to beginners, though, it does really odd things at times if you are not clean with it. First time I used stash, I lost all my code and nobody could figure out how to get it back. :P

But that the thing - I never stash crucial code, just things like settings that are special to me and not other developers, so they'll probably never be pushed.

Re: Gitless: a version control system

#202

Post by nbevans »

masklinn wrote: post #172
nbevans wrote: post #167

Earlier quoted context omitted.

I meant more from the perspective that it wraps a more friendly CLI on top of a DAG of commits. Didn't mean that it's 1:1 copying Mercurial :)

Well then it's copying more or less any DVCS which is not git, git(1) is the least friendly DVCS CLI I know of.

Indeed.

Re: Gitless: a version control system

#203

Post by projektir »

nicky0 wrote: post #151
vesak wrote: post #148

Earlier quoted context omitted.

I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?

It's central to git. 'git add' puts changes in the staging area. Then 'git commit' commits the staged changes. The staging area is also known as the 'index' and the 'cache'. (Git has a consistency-of-naming problem.)

> (Git has a consistency-of-naming problem.)

I wonder how many git usability issues could be solved just by addressing this and this alone.

Re: Gitless: a version control system

#204

Post by chungy »

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…

Then use `git checkout -f` if it so pleases you. There's more than one way to skin a cat.

Re: Gitless: a version control system

#205

Post by loup-vaillant »

cm3 wrote: post #103
loup-vaillant wrote: post #90

Earlier quoted context omitted.

Ah, such a misnomer: you don't cherry pick a commit , you cherry pick the patch that lies between the selected commit and its parent. It may feel like nitpicking, but it's quite important when trying to understand the differences and commonalities between various version control systems.

Yes, and it's why running git-am on the isolated commit can fail whereas cherry-picking does a proper merge and is more likely to apply cleanly.

> running git-am on the isolated commit

Huh? That command just turns the working copy into a commit, and mark it as the unique descendent as the commit currently pointed to by HEAD. Worst case, you just created another branch (happens if HEAD happens to point to something other than the last commit of an existing branch).

You wouldn't happen to try and save the state of one branch in the working copy, then using that working copy to update another branch, right? That's just asking for trouble: done naively, it'd cancel all changes made in that another branch.

If you know anyone who did this kind of mistake, do them a favour and explain the difference between a commit and a patch.

Re: Gitless: a version control system

#206

Post by projektir »

I don't know if this is not wholly rational, but over time, I became more and more cautious of using any tool for git that wasn't the pure git command line itself. I don't like how the command line was designed, but at least I know what's going on. With other tools (the latest culprit is Visual Studio sync), I often have a reaction of: "You did WHAT?"

Re: Gitless: a version control system

#207

Post by ender7 »

chungy wrote: post #204
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…

Then use `git checkout -f` if it so pleases you. There's more than one way to skin a cat.

To be honest, this comment is more evidence of a problem than anything else.

Re: Gitless: a version control system

#208

Post by lbotos »

StavrosK wrote: post #171
lbotos wrote: post #163

Earlier quoted context omitted.

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important." If this was some new novel way to version that wasn't just pretty git,…

I don't understand this rationale. Are you saying that Git's UI is perfect, and there's no improving it? It's not, and gitless does, indeed, improve on it. We should be celebrating better UIs over important tools, not saying "I made great effort to learn it, therefore learning it with less effort is inferior". No. If it does everything Git does, but more easily, it is strictly superior.

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'T understand git, it's a problem. That's my point.

Re: Gitless: a version control system

#209

Post by cm3 »

loup-vaillant wrote: post #205
cm3 wrote: post #103

Earlier quoted context omitted.

Yes, and it's why running git-am on the isolated commit can fail whereas cherry-picking does a proper merge and is more likely to apply cleanly.

> running git-am on the isolated commit Huh? That command just turns the working copy into a commit, and mark it as the unique descendent as the commit currently pointed to by HEAD. Worst case, you just created another branch (happens if HEAD happens to point to something other than the last commit of an existing branch). You wouldn't happen to try and save the state of one branch in the working copy, then using that…

I mean when you get a .patch file and git-am that doesn't provide the same associated info (or environment) for git to resolve a merge.

Re: Gitless: a version control system

#210

Post by pjc50 »

lbotos wrote: post #208
StavrosK wrote: post #171

Earlier quoted context omitted.

I don't understand this rationale. Are you saying that Git's UI is perfect, and there's no improving it? It's not, and gitless does, indeed, improve on it. We should be celebrating better UIs over important tools, not saying "I made great effort to learn it, therefore learning it with less effort is inferior". No. If it does everything Git does, but more easily, it is strictly superior.

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 high percentage of beginners pressing the wrong button and losing time and effort as a result, maybe someone should move the buttons?

Post reply on HN