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

301–310 of 390 posts

Re: Gitless: a version control system

#301

Post by kazinator »

arjie wrote: post #245
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/GrizzledPartialAntelopegro…

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.

Re: Gitless: a version control system

#302

Post by erichocean »

nickhuh wrote: post #287
hefty wrote: post #281

Earlier quoted context omitted.

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

Atlassian has a nice UI for doing that visually, too. Super easy.

Honestly, people for whom the command line UI is "too difficult" should just use a GUI client. That's the target audience for them.

Re: Gitless: a version control system

#303

Post by kazinator »

twic wrote: post #150
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…

FWIW, Mercurial has this - there's a notional changeset called 'null' whose hash is all zeroes, which is the parent of every changeset which does not have a real parent. As a result, you can rebase a root changset. For example: $ hg init $ echo silver >colour $ hg add colour $ hg commit --message 'First commit' $ hg checkout null 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ echo liquid >stat…

I was thinking exactly the same thing: why doesn't git use an all-zero hash as a special NIL. I think SHA-1 cannot output all zeros as a valid hash.

Re: Gitless: a version control system

#304

Post by fail2fail2ban »

zajd wrote: post #123
fail2fail2ban wrote: post #117

Earlier quoted context omitted.

Your points would be more salient if you could make them without falling back on profanity.

They'd also be more salient if I didn't have to make them 10 times in a thread because everyone feels like their opinion on how "git is too hard" is worth sharing. It gets tiring defending git from the uneducated masses and hearing the same stuff trotted out over and over again that has no value whatsoever.

If that many people are making the point, maybe they have a point.

Re: Gitless: a version control system

#305

Post by bulatb »

maker1138 wrote: post #230

I'm surprised at how many people are responding negatively to software that improves user experience. Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed. The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging…

Using artificially complex, unfriendly tools is a form of honest signaling. [0]

Making tools complex and painful, denying their complexity, and scoffing at the very notion of allowing a non-expert to accomplish what before required esoteric knowledge is the way the tribe of self-styled Real Programmers protects its integrity.

[0] https://en.m.wikipedia.org/wiki/Signalling_theory#Honest_sig...

Re: Gitless: a version control system

#306

Post by wst_ »

k__ wrote: post #193
weberc2 wrote: post #146

Earlier quoted context omitted.

I don't think those commands are remotely sufficient to work with git. You're forgetting about merging, traversing history, branch creation, remotes, grokking the staging area, etc. I'm sure I'm missing a lot as well, because those of us who have worked with git for a long time take these things for granted. And it does frustrate me that it's so complex, because Mercurial shows us it doesn't have to be this way. Unfo…

The commands are enough to get through the first month of using git for your own project. They are certainly not enough to work with Git for your whole career :)

Then they introduce more mess than it's worth. Sooner or later you will have to go back to the original ones and learn anyway.

Re: Gitless: a version control system

#307

Post by fragmede »

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…

Example usage from the article:

    $ gl checkout foo.py
    You have uncommitted changes in foo.py that would be
    overwritten by checkout. Do you wish to continue? (y/N)
    > y
A cheat sheet with those 10 commands are enough to get started, but Git takes a bit to grok properly ( https://xkcd.com/1597/ ). More importantly, it doesn't have to be user hostile. Professional tools in manufacturing are very expensive and last decades. Software lifecycles are shorter and easier and far cheaper to replace.

Re: Gitless: a version control system

#308

Post by vatotemking »

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…

I just use Git GUI. Click click and I'm done. For more complex tasks I open up Git Bash eg. git merge --no-ff which is the equivalent of "gl merge" command in gitless

Re: Gitless: a version control system

#309

Post by okket »

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

It is not a quote by Linus but part of a satirical piece, see:

http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...

Re: Gitless: a version control system

#310

Post by bsder »

mitchty wrote: post #298
bsder wrote: post #257

Earlier quoted context omitted.

> Git is, like many professional tools, something you simply got to learn. Or, you can use a tool that is built for purpose aka doesn't suck ). I don't use a Stanley #55 Plane to trim an edge even though it can. Mercurial, the author notes, doesn't have most of the pitfalls. Yes, everybody persists in using git because "Linus used it".

I persist in using git mostly because it doesn't also mean I need to have python installed everywhere. I recognize this may be a minority reason, but that is a significant one. The rest amount to being able to rebase/reorder my commits. At no point does "linus used it" factor in. What genuine technical points about git besides "doesn't suck" are you espousing as reasons I should switch? Note, my workplace: a: uses gi…

> I persist in using git mostly because it doesn't also mean I need to have python installed everywhere.

That is a perfectly valid objective reason. It surprises me, given that I do embedded development and have yet to be in a position where Python in my toolchain is an issue, but I'm happy to concede it.

> c: follows linux upstream closely (we do kernel stuff)

Then git is your horse, full stop. Even as a Mercurial person, if I was following kernel stuff I'd use git, that's just common sense.

> e: would be nice if hg proponents would stop with the "git users are brain damaged by bad ui" posts, it honestly just makes me roll my eyes and move on, not rethink my position, SHOW ME WHY IT IS BETTER

You do realize that the UI is more than the majority of the tool, right?

People have done what you ask for. Repeatedly. Including the parent post. Git power users have written extensively of the various UI brain damage and the problems it causes for non-power users.

Git people concede the UI sucks and still persist in starting new projects with git. How should that be classified?

> If I were to list out all the cons

Do be cognizant that with the exception of objecting to python, most of your list of cons is: "I've used git and optimized for it so changing is difficult". If Microsoft/Oracle were attempting via network effects to foist such a broken tool on the open source community instead of Linus/github, people would be screaming.

Personally, I can use either now. Also, personally, I now consider Mercurial to be a not-so-secret productivity advantage (well integrated with Windows, no wedged repositories, no wasted time recovering, can explain how to use it to neophytes so executive level people and non-programmers can use it, etc.). I know that my Mercurial teams won't waste 5% of their time fighting their source code system every single week--they won't even think about their source code system.

My beef is that beginners think "Oh, everybody uses git so git is fine so let's use git". And then, once they've made that mistake, now they feel they have to defend it. And that's not cool.

Post reply on HN