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

381–390 of 390 posts

Re: Gitless: a version control system

#381

Post by projektir »

dahart wrote: post #377
projektir wrote: post #374

Earlier quoted context omitted.

I didn't call it a general purpose solution in that context, nor did I call it a general purpose solution for everything. I am saying that I needed a general purpose solution for a situation that occurs often in many variants. For my situation, without stash, that was creating a commit and cherry-picking it places. Stash makes that case a lot easier to manage. I don't use stash for cases where it doesn't make sense.…

> You're the one making a big deal out of something, honestly, and you do not seem to be reading my posts very carefully because you're still making a lot of incorrect assumptions. I'm sorry you feel like I wasn't listening to you. I was, and I read all your posts. You're absolutely right, I have made a big deal out of it. Despite the long discussion, I think we're in nearly full agreement, and FWIW, thank you for en…

Well, I said at the very beginning:

> 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.

I don't know if that wasn't very clear.

Nothing wrong with opinions, there's a reason we share them, and I agree that stash could have probably been implemented a better way underneath. I have been recommended to use stash by another developer without any sort of warning, and with the implication that it's really safe and easy to use, which is rather funny in retrospect. Git's documentation page doesn't really talk about the dangers, either.

> Peace!

Indeed!

Re: Gitless: a version control system

#382

Post by perilunar »

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.

A rather ironic question, given the history of ergonomics and human factors research in aviation.

Re: Gitless: a version control system

#383

Post by lmm »

dahart wrote: post #363
lmm wrote: post #360

Earlier quoted context omitted.

> Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows. I accidentally made cha…

> "git checkout -" switches to the previous branch. OH, that's very nice, I want that. Guess I need to upgrade my git. Okay, that invalidates my entire previous post. Sorry! ;) So, if you made changes on X but wanted them on Y... The thing about the "git checkout Y" is that there's no harm in trying, and it'll work most of the time. If it does work, you only have to commit, and you're done in less time than it takes…

What's the way that one screws up with stash that doesn't happen with other approaches? I don't think I've seen stash accidents, though most of my colleagues don't seem to use stash much. If an attempt to pop conflicts, can't you just abort it?

Re: Gitless: a version control system

#384

Post by croon »

jomamaxx wrote: post #376
croon wrote: post #338

Earlier quoted context omitted.

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.

"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." It's not a false equivalence at all. The necessity of lower-level technology in the creation of higher-level technology does not imply that the lower-level technology is somehow 'better' or 'superior'. You are using a UX right now to read and respond to this. It's crazy to posi…

Well, first off: I didn't claim that "UXs are inferior", whatever that means. Every interface is a UX. I assume from context you're talking about polished GUI:s.

GUI:s are superior for the specific (limited) use cases they are designed for, inherently since they were designed to excel at those use cases. They are however less optimal when you want to diverge from those use cases and create something new. This is where malleability/modability comes in, and where CLI:s, bash, scripting, programming comes in, and you can't use limited-scope apps for that.

All tools are best at what they were designed for, I agree with you there. I'm however not sure how I in your mind was wrong before. The two are intrinsically bound, but it's undeniable that apps can't exist without tools, but tools sure can exist without apps.

Re: Gitless: a version control system

#385

Post by kazinator »

arjie wrote: post #327
kazinator wrote: post #301

Earlier quoted context omitted.

The use case is that when I'm making a new repo, I want to be able to do: git rebase -i ^ git reset --patch ^ git checkout --patch ^ I can do all this if the first commit is actually the second and the first is a dummy empty one.

I meant, "what are you setting out to do?" as in "I'm trying to reorder commits" not "I'm trying to `git rebase -i commit`" (the ultimate aim, rather than the path you choose). My instinct is that you can get where you want to go fairly easily with the `git rebase -i --root` I mentioned earlier.

If you plant a NIL commit in your repo before doing anything else, and tag it as NIL, then absolutely all git commands that take a ref (including ones you don't even know yet) will Just Work without any special arguments or modifications for the root case. You don't need to memorize yet more special cases for yet one more corner case in git.

In existing old repos or other people's repos that do not have NIL, I don't need it, because I won't be rewriting their history (let alone all of it back from the empty state!)

It's handy, when a repo is brand new, to be able to massage the newly created master branch using the same workflows that are rehearsed daily, rather than special cases.

Re: Gitless: a version control system

#386

Post by collinmanderson »

dahart wrote: post #367
collinmanderson wrote: post #366

Earlier quoted context omitted.

Sure, but my guess is it's just as easy to shoot yourself in the foot with rebase -i. Beginners are still going to have a hard time recovering mistakes with rebase -i, even if it's theoretically possible to recover. Plus, now you need to use `git diff origin` rather than `git diff` to see your changes.

> Sure, but my guess is it's just as easy to shoot yourself in the foot with rebase -i. No. rebase -i goes in the reflog. stashes don't. The rebase man page does not have the same safety warning that the stash man page does. I have personally witnessed a lot of stash accidents, and not many rebase accidents. With a rebase, if you have a bad merge conflict, you can abort. With a stash you can't. If you've committed yo…

I mean it's just as easy to make a mistake in the first place with rebase -i. Even though one is theoretically possible to recover with rebase -i, it's going to be very hard to recover for a beginner. (You need to know the reflog command, etc.)

Re: Gitless: a version control system

#387

Post by cestith »

copperx wrote: post #295
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 I agree with you, but although CLIs are explicitly automatable, they are almost never are because most operations are one time deals. If you have evet set up a Linux server I think you'll understand what I mean. The CLI is also a usability nightmare with no discoverability.

I use configuration management tools to set up multiple nearly identical Linux servers with nearly identical configurations. It's totally repeatable. Look into Ansible, Chef, Puppet, or SaltStack.

Re: Gitless: a version control system

#388

Post by king_phil »

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!

Not with bash but with less :-P

Re: Gitless: a version control system

#389

Post by yawaramin »

norswap wrote: post #329
yawaramin wrote: post #294

Earlier quoted context omitted.

> I think git's concepts are simple and worth learning For what purpose? The reason for using a VCS is to get your job done. If gitless does that, why should I need to learn the concepts of a content-addressable graph storage and traversal format?

For instance, git has a notion of staging area (the index) where you collect the changes that go into a commit. In gitless, all changes to tracked files are committed. The index goes a long way towards making nice commits that can be understood by other team members, pass tests, etc. Similarly, the stash that allows you to save your uncommitted changes before switching branches is also quite worthwhile.

For all intents and purposes, gitless has an index too. It lets you specify upto hunk-level granularity what you want to include in (and exclude from) each commit.

Re: Gitless: a version control system

#390

Post by develop7 »

eridius wrote: post #379
influx wrote: post #355

Earlier quoted context omitted.

It also was designed for a use case that almost no one actually does which is distributed version control. Most people use it like a svn with better branching and merging.

Everybody who's ever forked a project on GitHub is using it as distributed version control, and that's a lot of people, so I don't know why you say almost no one actually does distributed version control.

I'm quite certain most of these are sure they are using github and see no difference between it and Git; and "version control" term gives them headaches in same way as "currying" or "first-class function".
Post reply on HN