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

281–290 of 390 posts

Re: Gitless: a version control system

#281

Post by hefty »

erichocean wrote: post #241
recursive wrote: post #211

Earlier quoted context omitted.

I've been using git for a few years, and often wished I could eliminate the staging area. It's an extra step for every commit, and creates extra complexity for no benefit I've been able to see. I haven't seen a practical example of a use case that's improved by having separate add and commit. By your statement, I also completely misunderstand git. That's entirely possible, but if git is so hard to understand that dai…

> I haven't seen a practical example of a use case that's improved by having separate add and commit. Well, I frequently see random things to fix while I'm working on a problem. When I 'm ready to commit, I run `git status` and notice there's a file that's been modified that's unrelated to what I'm trying to commit. A quick `git diff` later and I see what I did: fixed an unrelated issues. So I add that one file to th…

>there's a file that's been modified that's unrelated to what I'm trying to commit

What if those unrelated changes are in the same file as a bunch of related changes that you've already made? Do you undo all the changes you've made in that file apart from the random bug fix and then commit, or leave them intact resulting in that bug fix commit containing changes that are unrelated to the fix?

Re: Gitless: a version control system

#282

Post by kazinator »

al2o3cr wrote: post #178
kazinator wrote: post #92

Git needs the parent pointer equivalent of NIL. Whenever I start a blank new repo nowadays, I do a git commit --allow-empty -m "NIL" See, many git operations require a parent reference! For instance if you want to interactively rebase the top commit, it's actually "git rebase -i HEAD^": rebase back to (but excluding) HEAD's parent. The equivalent "git rebase -i HEAD~1" means the same thing: that ~1 actually spans two…

Git needs the parent pointer equivalent of NIL. Whenever I start a blank new repo nowadays, I do a Sounds like you've already got one...

Only in a repo I started myself, not cloned from anywhere.

Re: Gitless: a version control system

#283

Post by projektir »

dahart wrote: post #255
projektir wrote: post #201

Earlier quoted context omitted.

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

I don't know if I really know what I'm doing... feel free to correct me if something feels off.

I'm not following your alternative. Did you mean "git pull --rebase"? Because this will result in there being a WIP commit in the middle. I try to pretty much never do pulls like this, I'm in the "rebase everything to smithereens camp".

I don't want accidental merges. I do not want to have to rebase because I got a commit in the middle and it's named funny. And what I also don't want is having to deal with merge conflicts in the rebase or merge in case incoming changes don't like the changes in the WIP commit.

It's a lot cleaner to just not have the stuff in there at all, pull, and put it back on top. (like the stack that stash presents)

Yes, I am that lazy.

This is not really the way I used to do it. An example is just an example, the situations are many. Maybe I want to pull. Maybe I need to rebase my stuff. Maybe I need to switch to another branch to show something to a coworker.

I'd have to make a special branch, commit to it, and then grab the commit hash and cherry-pick that whenever I needed it. Because I would need it in all sorts of different situations. So part of the issue was keeping track of the hash. But the bigger problem was how much work I'd needed to do if I ever needed to bring those changes up to speed again. With stash, I get a merge conflict and I resolve it, and that's my new stash again, I don't even have to do anything. With a commit or cherry-pick, I have to undo it, fix it, commit it, and now manage a new hash.

I find stash easier to manage in my head specifically because it's a separate thing on the side so it doesn't get mixed up with all my other branching. It's very little headspace at this point, and mostly a decision tree in the form of:

- is the staging area empty and I want to start doing work? stash pop;

- is the staging area currently holding my stash changes and I want to do some things with git? stash.

Re: Gitless: a version control system

#284

Post by cies »

austinjp wrote: post #267
gnuvince wrote: post #235

Earlier quoted context omitted.

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…

Indeed. Also known as "sunk cost fallacy".

> "sunk cost fallacy"

I like to spot those, did not see this one though, but indeed, sunk cost fallacy it is. Well spotted :)

Re: Gitless: a version control system

#285

Post by cies »

zajd wrote: post #97
philjohn wrote: post #86

Earlier quoted context omitted.

You shouldn't have to learn how the data structures of the tool work beneath the surface to successfully know how to use a tool.

You don't have to. The difference with git is that it's even possible.

Why wouldn't it be possible with Gitless to learn the data structure?

Re: Gitless: a version control system

#286

Post by dahart »

projektir wrote: post #283
dahart wrote: post #255

Earlier quoted context omitted.

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

I don't know if I really know what I'm doing... feel free to correct me if something feels off. I'm not following your alternative. Did you mean "git pull --rebase"? Because this will result in there being a WIP commit in the middle. I try to pretty much never do pulls like this, I'm in the "rebase everything to smithereens camp". I don't want accidental merges. I do not want to have to rebase because I got a commit…

> 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 safety net than if you stash.

I totally understand that stash feels easier, a lot of people agree with you. But I don't think it's true once you dig down and learn how to not use stash. And stash is more dangerous when something unexpected happens.

Re: Gitless: a version control system

#287

Post by nickhuh »

hefty wrote: post #281
erichocean wrote: post #241

Earlier quoted context omitted.

> I haven't seen a practical example of a use case that's improved by having separate add and commit. Well, I frequently see random things to fix while I'm working on a problem. When I 'm ready to commit, I run `git status` and notice there's a file that's been modified that's unrelated to what I'm trying to commit. A quick `git diff` later and I see what I did: fixed an unrelated issues. So I add that one file to th…

>there's a file that's been modified that's unrelated to what I'm trying to commit What if those unrelated changes are in the same file as a bunch of related changes that you've already made? Do you undo all the changes you've made in that file apart from the random bug fix and then commit, or leave them intact resulting in that bug fix commit containing changes that are unrelated to the fix?

In that case you'd want to use "git add -p" which allows you to pick only parts of a file to stage for a commit. It can be crucial in crafting a really solid project / commit history.

For even more complex cases you could use "git add -i"; however, that command can be tricky to work with and I find it's usually not to helpful to get that far into the weeds.

Re: Gitless: a version control system

#288

Post by projektir »

dahart wrote: post #286
projektir wrote: post #283

Earlier quoted context omitted.

I don't know if I really know what I'm doing... feel free to correct me if something feels off. I'm not following your alternative. Did you mean "git pull --rebase"? Because this will result in there being a WIP commit in the middle. I try to pretty much never do pulls like this, I'm in the "rebase everything to smithereens camp". I don't want accidental merges. I do not want to have to rebase because I got a commit…

> 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, what do I do?

Re: Gitless: a version control system

#289

Post by ern »

k__ wrote: post #168
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,…

It's like with IDEs. Eclipse has stuff like workspaces with multiple projects and others have simply projects. What to do with these workspaces? Same goes with Git. Simple VCS have central repositories and a working copy. Git has multiple repositories and every one of them can have a working copy. Other VCS don't have a stage, you simply commit your changes directly into your repository. It's not only that these tool…

I may have misunderstood you, but you do realize that Mercurial is also a DVCS like git, right?

Re: Gitless: a version control system

#290

Post by redwall_hp »

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.

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 (automate things instead of creating more busywork).

Post reply on HN