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

361–370 of 390 posts

Re: Gitless: a version control system

#361

Post by dasil003 »

skoczymroczny wrote: post #353
bsder wrote: post #264

Earlier quoted context omitted.

> Version control is arguably confusing for beginners NO IT IS NOT . That kind of thinking is broken. Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works. As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with som…

For me the problems are always merge conflicts. Don't know why, in SVN I wasn't afraid of merge conflicts, I just opened a GUI, clicked on some arrows, picked the parts I want and parts I don't want, save and done. In Git, even with gui tools, I often end up with a mess of .BASE, .LOCAL, .REMOTE files, then I can't merge it all properly, and even if I do it asks me to commit the changes again and it's a mess, so I ju…

If you think merging in svn is easier than git then you haven't seen the pathological cases of svn merges. The problem is svn has no concept of a repo root or branches, it only has directories, so sooner or later things get very very broken.

Re: Gitless: a version control system

#362

Post by IshKebab »

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

I think it's a little different from that actually. That's normally about the merits of ongoing financial investment, but I get your analogy and there should be a name for it because you see it all the time from compsci types.

How about "sunk knowledge fallacy" or something like that?

Re: Gitless: a version control system

#363

Post by dahart »

lmm wrote: post #360
dahart wrote: post #354

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. > why doesn't "-" work fo…

> 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 to stash & pop.

If you're just not the gambling type, here's one way to avoid branch ping-pong. I'm sure there are others.

  $ git checkout -b Z
  $ git commit -a "config changes"
  $ git checkout Y
  $ git cherry-pick Z
  $ git branch -D Z
I admit that's a tiny bit more work than with stash, in this case, but it's safer than stash, that's why I prefer it and advocate it. It is demonstrably harder to screw up if bad things happen in the middle. This workflow is also more general - you can use it if you have commits in X already. Stash doesn't help you there.

I've personally witnessed too many stash accidents. BUT, if you are comfortable with using fsck if anything goes wrong, you really have no reason to consider my opinion at all.

I'm painting a picture that is more anti-stash than I actually am. My main safety concern with stash is how it's implemented, not how easy it is. The git authors could have used something like the above commands under the hood to implement stash, but they chose to circumvent the reflog for reasons I don't know, and that choice leads to frequent accidents. Git is supposed to be your safety net, not something that gets you into trouble.

That said, a lot of people seem to think stash is many times easier than the alternative, and I think if you really look at the alternatives fairly, using commits is most of the time not more difficult than stash, and occasionally one or two extra commands. It's just not that hard to avoid stash, and there are significant benefits.

Re: Gitless: a version control system

#364

Post by paulmd »

rficcaglia wrote: post #314
nine_k wrote: post #271

Earlier quoted context omitted.

Is an aircraft cockpit a poorly designed ux? It does require a fair bit of learning.

yes. and that's why as new planes are being produced, both commercial and small planes, they are replacing the older cockpits with fully electronic modern cockpit controls (with non-electronic secondary controls for power failure use) many NTSB studies show that even master pilots with thousands of hours of training and flight time make (often fatal) mistakes due to confusion in understanding the cockpit readings

There's a standard tech-nerd bias that assumes that technology will always save us, but just throwing electronics at the problem doesn't necessarily solve anything.

For example, the Army found that using glass cockpits doubled or quadrupled the accident rates in UH-60 and OH-58 aircraft respectively, increased it by ~30% in the AH-64, and reduced it by ~40% in the CH-47.

http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=ht...

http://www.usaarl.army.mil/TechReports/2001-12.PDF

A five-year NTSB study found that although glass cockpits had twice the incidence rate of fatal accidents. The study concluded that glass cockpits do not show a safety benefit. This remains the position of the NTSB.

http://www.ntsb.gov/safety/safety-studies/Documents/SS1001.p...

http://www.ntsb.gov/news/events/Documents/2010_Glass_Cockpit...

http://www.ntsb.gov/safety/safety-recs/recletters/A-10-036-0...

The reality is that simpler is sometimes better. Mechanical instruments each do one thing and they do it well. Vacuum-driven systems are simple and extremely reliable. You cannot fly a 100% glass cockpit, period.

What glass cockpits really do well is information integration. That makes it easier to surface relevant information for the pilot but it also means that pilots have to handle more complex systems that are throwing more information at them, and yet also may not be throwing the right information at them.

This is an inherently one-way street, the reason we have the instruments we do is because they're relevant, you can't go hiding relevant information from the pilot. As such, NASA recgonizes that glass cockpits and cockpit automation impose a higher cognitive load on pilots. It's very simple and straightforward to interact with a traditional cockpit, but with a more advanced cockpit you also need to have a correct mental model of what's happening in the background, otherwise "cognitive mismatch" will result.

Just like any other abstraction - it's nice when they work but all abstractions are "leaky" to some degree or other and you need to know how it works and be able to route around the problem to fix the cases where it fails.

The long and short here is that experience and frequent training are the key factors in aviation safety and glass cockpits actually increase the requirements in this area. They're nice when they work but they certainly are no panacea.

http://human-factors.arc.nasa.gov/flightcognition/research/s...

https://www.thinkmind.org/download.php?articleid=achi_2012_1...

Re: Gitless: a version control system

#365

Post by dahart »

collinmanderson wrote: post #347
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…

Merge Conflicts. I think a lot of tutorials spend a lot of time teaching you the index/staging (a non-trivial concept that beginners don't need) but don't teach you how to survive merge conflicts and other common tricky situations which beginners are likely to run into if they're collaborating. Your list is all you need...until you try to `git pull` and it says > Cannot pull with rebase: You have unstaged changes. Yo…

> Basically, I'd add `git stash` to your collaborative list. You can't `git pull` without it.

Of course you can! Git stash is not necessary for any workflow, it's pure convenience.

Best practice is not to pull with unstaged changes. If you want to, then:

  $ git commit -am "WIP"
  $ git pull --rebase
Easier than stashing! But this does mean you're going to need to rebase -i later before you push.

Stash is dangerous for beginners, I don't recommend learning it first. From the stash man page:

"If you mistakenly drop or clear stashes, they cannot be recovered through the normal safety mechanisms." https://git-scm.com/docs/git-stash

Re: Gitless: a version control system

#366

Post by collinmanderson »

dahart wrote: post #365
collinmanderson wrote: post #347

Earlier quoted context omitted.

Merge Conflicts. I think a lot of tutorials spend a lot of time teaching you the index/staging (a non-trivial concept that beginners don't need) but don't teach you how to survive merge conflicts and other common tricky situations which beginners are likely to run into if they're collaborating. Your list is all you need...until you try to `git pull` and it says > Cannot pull with rebase: You have unstaged changes. Yo…

> Basically, I'd add `git stash` to your collaborative list. You can't `git pull` without it. Of course you can! Git stash is not necessary for any workflow, it's pure convenience. Best practice is not to pull with unstaged changes. If you want to, then: $ git commit -am "WIP" $ git pull --rebase Easier than stashing! But this does mean you're going to need to rebase -i later before you push. Stash is dangerous for b…

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.

Re: Gitless: a version control system

#367

Post by dahart »

collinmanderson wrote: post #366
dahart wrote: post #365

Earlier quoted context omitted.

> Basically, I'd add `git stash` to your collaborative list. You can't `git pull` without it. Of course you can! Git stash is not necessary for any workflow, it's pure convenience. Best practice is not to pull with unstaged changes. If you want to, then: $ git commit -am "WIP" $ git pull --rebase Easier than stashing! But this does mean you're going to need to rebase -i later before you push. Stash is dangerous for b…

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 your changes and have problems either forgetting what you're doing, or with merge conflicts, or with being in the wrong branch. All of these cases have more undo options with commits. In the worst case, you still have the safety net of the reflog with commit. With stashes, your only safety net is hunting for dangling blobs using fsck.

Previous threads: https://news.ycombinator.com/item?id=12613062 https://news.ycombinator.com/item?id=12622414

Re: Gitless: a version control system

#368

Post by mitchty »

bsder wrote: post #310
mitchty wrote: post #298

Earlier quoted context omitted.

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

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

Admittedly its weak but I've used it to run things like git on some really small systems. I'd rather not have to try to get python running on something like an AVR. But to each their own. Not sure what embedded development is meaning here exactly but no matter.

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

I'm looking more for what advantage hg itself gives me, less about how much git sucks which is at this point beating a dead horse.

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

Indeed, but that just points to after 8-9 years of using git, minor gains in using hg just don't seem as warranted. To date most of what I have seen with hg hasn't shown me what I will gain from switching will be greater than moving. Perhaps thats due to not having to use hg constantly but with things like magit I really don't notice the git ui a lot unless I choose to drop into the command line.

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

For my work I've no real need to integrate with windows, not sure what wedged repositories is referring to. Recovering is vague but as a worst case the reflog has always been an emergency fixer. I've not really experienced this to be honest and I'm basically the go to guy for git with my team.

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

Thats fine, but a bit different than the original statement of Linus uses it therefore we must. It is more git is widely used, ignoring it or not knowing how to at least basically use it isn't a tenable position imo. But to each their own.

Re: Gitless: a version control system

#369

Post by dahart »

mikegerwitz wrote: post #175
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…

> stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly. `pop` will no longer drop the stash if there is an error applying it; it did in the past. There is a point where it is worth having at least one person on a team study the internals of Git vs. struggling with it constantly and possibly losing work---it will save time, energy, and work in the long run. I…

This is a great post! I have only one minor point:

> In the stash case, `git reflog` would immediately allow you to recover the lost stash.

Stashes don't go in the reflog, you cannot recover them with git reflog, so you're automatically in the 'deep shit' category if you lose them. Hence the statement that stashes are dangerous.

You do still have the safety net of fsck, and knowing that it's possible matters, as you point out. But, my experience with people who mess up stashes has been that fsck is so intimidating they'd rather re-create their changes. Silly, but true.

Re: Gitless: a version control system

#370

Post by mikegerwitz »

dahart wrote: post #369
mikegerwitz wrote: post #175

Earlier quoted context omitted.

> stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly. `pop` will no longer drop the stash if there is an error applying it; it did in the past. There is a point where it is worth having at least one person on a team study the internals of Git vs. struggling with it constantly and possibly losing work---it will save time, energy, and work in the long run. I…

This is a great post! I have only one minor point: > In the stash case, `git reflog` would immediately allow you to recover the lost stash. Stashes don't go in the reflog, you cannot recover them with git reflog, so you're automatically in the 'deep shit' category if you lose them. Hence the statement that stashes are dangerous. You do still have the safety net of fsck, and knowing that it's possible matters, as you…

> Stashes don't go in the reflog

You can see them with `git reflog --all`.

Post reply on HN