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

241–250 of 390 posts

Re: Gitless: a version control system

#241

Post by erichocean »

recursive wrote: post #211
Mithaldu wrote: post #53

Earlier quoted context omitted.

And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.

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 the index, commit it with a relevant commit message, and then proceed to do a second commit—the one I had expected to do—also with a relevant commit message.

I do this 3-5 times a day, at least.

Re: Gitless: a version control system

#242

Post by [deleted] »

na85 wrote: post #232
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…

I don't like git because I have zero confidence that it won't do something dumb like fail to diff properly requiring me to merge 980 diffs in a single file while it puts the >>>>>>> markers in the wrong places, randomly transposing lines from one part of a file to another for no discernible reason. You know, like happened to me today.

[deleted]

Re: Gitless: a version control system

#243

Post by CJefferson »

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…

Some reasons I don't like git, straight off the top of my head.

* Some commands require remote branch, others require remote/branch. I can never remember which.

* git lets you create branches with names like 'remote/branch', at which point it starts going crazy because when I then write remote/branch, it doesn't know if I mean branch on remote, or the local branch remote/branch.

* When merging / rebasing goes wrong, it can be hard (or impossible) to recover back to the state I started from.

Re: Gitless: a version control system

#244

Post by popmystack »

nkurz wrote: post #231
popmystack wrote: post #217

Earlier quoted context omitted.

You consider his first post to be productive? You must be dreaming. > ajkjk strikes me as someone making reasonable points He is not making any point, so it's weird that you would say that. He hypocritically stated I was coming off as arrogant. Fair game, even though I really don't see how it remotely comes off that way, but you can't exempt yourself from your own criticism in a post that does not constructively furt…

I most definitely will not, as this is a technical discussion. For better or worse, like most discussions, it also has social aspects. Consideration of these aspects may help you better convey your technical points. What's the point? Based on your comment history, you have technical knowledge that others could benefit from, but aren't very successful in getting your point across without being downvoted or flagged. If…

>Consideration of these aspects may help you better convey your technical points.

And yet despite him blatantly confronting me in an aggressive personal manner, you've ignored his original post and decided to focus on my post, all in spite of my attempts to keep the conversation on topic. Most likely because you agree with him. It really removes any credence from his post and other posts echoing him about my original post being "prickly" when you're a complete dick to someone directly. Talk about arrogance.

I can't call a technical concept brain damaged, but aggressively labeling people in a confrontational manner is a-okay. Got it.

>and yet I frequently am baffled by the commands required to get from where I am to where I want to be.

Have an example? Most of the examples I've seen come from a fundamental misunderstanding about what git is doing. Git is rarely in the wrong.

There's a lot of internal plumbing commands that are completely backwards (or just have not been updated to align with the rest of the toolset) but an extremely small majority of people will ever even know about them, let alone have to use them. Especially if you're just starting out with git.

>think attempts to better align git's command line interface with the underlying operations are commendable

Except as presented in the examples I've given, it's doing the exact opposite of this. It's going against the very basic foundation of git. Git is an acyclic graph with each node representing a change delta from its "parent." The very fact that branches suddenly keep track of which specific changesets (tracked or not!) belong to them is completely counter to how the very core of git works.

That's non-sense.

Re: Gitless: a version control system

#245

Post by arjie »

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…

> If all you have is a single commit with no parent, you cannot rebase it.

Well, of course what you want to do here depends. You can squash onto it, edit it, or reorder it. You're commonly going to have conflicts if your first commit created a file and the rest edit it. If you reorder you can't edit a file that doesn't exist yet.

Here are a couple of videos to illustrate:

https://gfycat.com/GrizzledPartialAntelopegroundsquirrel

https://streamable.com/1chg

This wasn't always possible through the UI but it's possible now. If this doesn't do the trick, would you mind sharing what your use case is?

Re: Gitless: a version control system

#246

Post by tadfisher »

nardi wrote: post #160

In this thread, lots of people wanting to demonstrate their deep knowledge of an arcane tool, thus proving the whole point.

Posted this upthread, but here's an apt Linus quote:

> The first Git For Dummies and Git Visual Quickstart books are going to be out in a couple of months, and that is the beginning of the end as far as I’m concerned. Those books mean the end of git expertise and github reputation as reliable indicators of geek status. Once a technology is adopted by the masses the extreme geeks find something more esoteric. Look at what happened to Ruby on Rails. The people stumbling their way through Rails to-do list tutorials have never even heard of DHH.

Re: Gitless: a version control system

#247

Post by __david__ »

Grue3 wrote: post #194
kasey_junk wrote: post #138

Earlier quoted context omitted.

Hg is a very similar model to git but doesn't have the cli problems it does. Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does. But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting…

Hg has a lot of problems. It has bookmarks AND branches (for some reason). To edit your commit history you need to pray to the elder gods and sacrifice a newborn. I consider myself pretty smart and yet my mind went completely blank every time I read about anything related to Mercurial Queues. The default install lacks too many features, you need to enable extensions to do even the most basic stuff, like stashing. Dar…

Darcs is not obviously better than git, and I say that as a person that's used Darcs for many, many years (and who has at least patch in the Darcs codebase).

Darcs main feature is the simplicity of its data model. Just a pile of patches that compose to produce some code. Push and pull them at will. It's very neat.

Darcs used to have the advantage a nice interactive UI, but git pretty much stole it wholesale with all the '-p' options (git add -p, git checkout -p, git reset -p) so it doesn't win there any more.

Darcs also has the massive downside of not being able to hold more than one branch at a time in a directory. Do you want to switch contexts? 'darcs get' to a new directory and start over. On my most active darcs project I have about 50 directories all with random unpushed WIP patches in them. In git that would just be a bunch of stashes, which are much easier to search through.

Nowadays, if I start tweaking a project that is still in Darcs, I'll immediately switch it to git: https://github.com/purcell/darcs-to-git

Re: Gitless: a version control system

#248

Post by oblio »

Grue3 wrote: post #188
sametmax wrote: post #54

Earlier quoted context omitted.

This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the opt…

>What we need is a good UI on top of that. It can solve 99% of those problems. It's called magit.

And then you have 2 problems.

Re: Gitless: a version control system

#249

Post by dahart »

__david__ wrote: post #236
dahart wrote: post #113

Earlier quoted context omitted.

> - stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly. Yes!! Stash has a problem that it's attractive to beginners, and its easier than other commands to hose yourself. It's a separate system for managing changes outside of commits, I don't get it. They could have made shortcuts to branch & commit. Mystifying. > What we need is a good UI on top of that. S…

> Yes!! Stash has a problem that it's attractive to beginners, and its easier than other commands to hose yourself. It's a separate system for managing changes outside of commits, I don't get it. It isn't a separate system "outside of commits". Stashes are literal commits. If you were to write a script that made little WIP commits it would probably end up looking a lot like git-stash (which is literally just a shell…

Sure, except stashes aren't in the reflog, so they are "outside of commits".
Post reply on HN