Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

Post reply on HN
Print view View original

491–500 of 520 posts

Re: Oh shit, git: Getting myself out of bad situations

#491

Post by Tomis02 »

rootlocus wrote: post #169
mamon wrote: post #20

The very existence of such guides tells us a lot about how easy to use Git is :)

Well, I think it tells how much time some developers are willing to spend learning the tools they are using.

First of all, using git is not really a choice in many companies (except "choose to use git or choose to find another job"). Because, despite being a terrible tool, "git won". So people like me choose to put the minimum of time in getting familiar with a tool that even some git experts/devs admit is confusing to use (after having used it and being intimately familiar with it for years! or maybe you think they were unwilling to spend enough time learning). More importantly, git (or any DVCS) is NOT work. Lots of technical people seem to have forgotten what purpose versioning control serves (saving your progress as you go) and instead seem to relish in solving git problems that make them feel they're working but add in fact no value whatsoever. That is the core issue. Takes about 10 minutes to get familiar with hg (and then just use a GUI), whereas you have to spend days/weeks reading git docs in order to internalize how it actually works. For what? Just to save some files on a server. I'm sorry, but no.

Re: Oh shit, git: Getting myself out of bad situations

#492

Post by Tomis02 »

erikb wrote: post #314
wyuenho wrote: post #300

Earlier quoted context omitted.

TBH, I've been an hg and git user for about 10 years now, I have only come across simple things that you'd expect to work in git but doesn't. For the longest time, you have to resort to contortions like this[1] so as to not lose commits after reverting a merge and then merge again. [1]: https://github.com/git/git/blob/master/Documentation/howto/r... What can't you do in Mercurial that you can in git these days? BTW,…

I could name a few things, like interactive rebases, but the main thing is not something that can really be explained. Have you ever significantly become strong in some kind of contest, may it be sports, gaming, music or similar? There is this situation where one day you struggle with something and don't see an end, and the next day it finally clicks, and you can do things naturally that one day earlier where not eve…

Long story short, you're using git because it makes you feel smart. Ironically, you even admit it - "therefore have no logical reason to go through the pain of really learning git". Correct, there is no logical reason to deal with a contorted DVCS when there are better alternatives. Your arguments are fully subjective.

Re: Oh shit, git: Getting myself out of bad situations

#493

Post by emodendroket »

craftyguy wrote: post #465
emodendroket wrote: post #446

Earlier quoted context omitted.

The GitHub desktop client is very limited and seems mostly geared toward a lone developer or small team who has never used git before. In this context I think it's a reasonable decision to use a more common verb.

Nope. That does no one any good. Using git verbage would, at the very least, acclimate them to very common terminology used by the rest of the folks they will eventually encounter.

Well, I disagree, because the alternative for many is probably no source control.

Re: Oh shit, git: Getting myself out of bad situations

#494

Post by rkangel »

falcolas wrote: post #53

A git off my lawn moment: Every time I see someone complaining because they have to dive into the reflog to fix their own mistake, all I can hear is "I was operating my table saw without using a push stick and can't understand why I lost a thumb". Friends don't let friends (especially those who don't learn how to use their tools) rewrite shared git history. If you don't understand rebase, amends, etc can do to your (…

This is a place where Mercurial wins out. Hg has the concept of phases that makes it much harder to screw up rewriting history:

https://www.mercurial-scm.org/wiki/Phases

Re: Oh shit, git: Getting myself out of bad situations

#495

Post by lmm »

falsedan wrote: post #361
lmm wrote: post #356

Earlier quoted context omitted.

Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.

It’s a lot of paperwork to avoid a perfectly safe and normal git command.

No it isn't. You'd always want to create a feature branch so that you can PR the fix - it's a change going into master, it should go through the normal change-going-into-master review flow. And you'd always have to run some command to indicate that this was the branch where you wanted to undo what you'd done to master. That the command is called "revert" is a little weird, but it's no more paperwork than any other command would be.

Re: Oh shit, git: Getting myself out of bad situations

#496

Post by falcolas »

rkangel wrote: post #494
falcolas wrote: post #53

A git off my lawn moment: Every time I see someone complaining because they have to dive into the reflog to fix their own mistake, all I can hear is "I was operating my table saw without using a push stick and can't understand why I lost a thumb". Friends don't let friends (especially those who don't learn how to use their tools) rewrite shared git history. If you don't understand rebase, amends, etc can do to your (…

This is a place where Mercurial wins out. Hg has the concept of phases that makes it much harder to screw up rewriting history: https://www.mercurial-scm.org/wiki/Phases

Replacing a table saw with a circular saw (bad analogies abound) doesn't remove the opportunities for losing appendages. Especially for those who don't learn how to use the tools put in front of them.

"It is impossible to make anything foolproof because fools are so ingenious."

Yes, Git is a sharper tool with fewer blade guards than other version control systems, including HG. That sharpness and relative lack of safety mechanisms, however, lets you do things you can't in other systems. The real problem is that folks use these tools without attempting to understand them and cargo-cult onto a workflow which leaves them open to screwing things up.

To continue the "git off my lawn" moment - I've had to use the reflog exactly zero times in the past few years, despite using rebase locally on a fairly frequent basis (and sadly remotely to fix other's bungles as well). This is only because I respect git for its sharp edges, and when it comes time to re-write history with rebase, I work carefully.

Re: Oh shit, git: Getting myself out of bad situations

#497

Post by firemelt »

lwansbrough wrote: post #42

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

What git gui? Git kraken?

Re: Oh shit, git: Getting myself out of bad situations

#498

Post by swalsh »

Yokohiii wrote: post #287
swalsh wrote: post #261

Earlier quoted context omitted.

You're misunderstanding the purpose i'm describing. Imagine 100 commits a day, maybe more. (I worked at a company that averaged 500 or more commits a day to the master branch. There were 1000 developers working in a monorepo). Some code is out in production, and suddenly we realize a specific commit is causing a problem. The idea here is to revert the commit as soon as you can, and then spend your time fixing it. Whe…

That sounds quite chaotic and impossible to keep stable. I wonder who was responsible to find problems and fix the master after messing up?

It was actually quite clean, and the environment was extremely stable. The trick is, every commit was "self-contained". Reverting it would go to another previous stable version. Creating a self-contained commit can be done many ways, and rebase is one common tool used to do it. Another is the use of git merge with --squash and a cherry-pick.

Re: Oh shit, git: Getting myself out of bad situations

#499

Post by swalsh »

drdrey wrote: post #408
swalsh wrote: post #261

Earlier quoted context omitted.

You're misunderstanding the purpose i'm describing. Imagine 100 commits a day, maybe more. (I worked at a company that averaged 500 or more commits a day to the master branch. There were 1000 developers working in a monorepo). Some code is out in production, and suddenly we realize a specific commit is causing a problem. The idea here is to revert the commit as soon as you can, and then spend your time fixing it. Whe…

git revert is exactly the tool for the situation you are describing

Sorry again, you're not understanding my point. Git revert is of course used... but i'm not worried about the mechanics of the revert itself. I'm worried about each revert being a "self-contained" piece. That the project was stable after the revert. That's the bit that was important. A Linear history of commits is the important bit. Not how to do a revert.

Re: Oh shit, git: Getting myself out of bad situations

#500

Post by dilap »

piyush_soni wrote: post #474
dilap wrote: post #450

Earlier quoted context omitted.

It's a really sweet piece of software, and I'm surprised it's not more popular. I'd be curious to hear how it ends up going for ya'll -- you can message me on twitter at @hazememry if you'd like.

I thought it's nice too, and just downloaded it to find out it's Mac only.

Yep :(
Post reply on HN