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

311–320 of 520 posts

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

#311

Post by agentgt »

erikb wrote: post #289
wyuenho wrote: post #57

Earlier quoted context omitted.

They can certainly provide much better porcelain out of the box. Mercurial is at least as powerful as git, but I always joked that the learning curve between the two is something like, you read the docs for 5 mins and you'll know what the next 50 commands to type into hg. Whereas git, you spend 50 minutes reading the Pro Git book, just so you know what the next 5 commands should be.

Sorry, but you don't know git if you think Mercurial is even coming close. That is not trolling btw. It's really possible not to know what you can do with it if you haven't learned it in depth. The "Git Book" is what you should read. And you read it once, you read it indepth, and then you're done. After that it's also only 5 minutes of googling, but you can do a lot more. At that point you can even program a simplifi…

> Sorry, but you don't know git if you think Mercurial is even coming close.

And you don't know mercurial if you think that.

Both are great and powerful and both have pros/cons.

> The "Git Book" is what you should read. And you read it once, you read it indepth, and then you're done. After that it's also only 5 minutes of googling, but you can do a lot more.

The problem with git on this is it is actually often sort of hard to find "the right" way to do things. This is in large part because of the popularity of git. There is so much content and a good deal disparate (e.g. Stack Overflow).

Mercurial on the other hand has far less content and it is maybe a little more consolidated and thus IMO slightly easier to find.

> At that point you can even program a simplified git if you want.

.... are you sure you are not trolling...

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

#312

Post by lambda »

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…

I'd consider myself an expert on Git, and I use a GUI of sorts for the vast majority of my Git work: Magit in Emacs.

It has many of the advantages that you describe; makes it easier to get an overview of what's going on, makes it easier to stage individual files, folder, lines of code, hunks, etc.

There are a couple of cases in which I need to fall back to the Git command line, but it's not very often, and I do find it substantially improves my life.

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

#313

Post by jordigh »

deathanatos wrote: post #276
legohead wrote: post #240

So I just ran across this one: git diff --staged I added a file and wanted to diff it, and this command helped! However, I made some changes in the file, and when I tried this command a second time, the changes don't show up :\ Only the original file that was added shows up in the diff. Now what? It's not the end of the world of course, as I can just look at the file in my editor, but I usually use diffs as a persona…

There's three "versions" of the code at play, if you will: * the most recent commit * the staged files * the working directory `git commit`, as you might already know, takes "the staged files" and turns it into a commit, making that the latest commit. `git add` adds a snapshot of a file in your working directory to the staged files. The important bit here is that the copy of the file in the staging area is separate f…

> There's three "versions" of the code at play, if you will:

> * the most recent commit

> * the staged files

> * the working directory

This is weird. The staging area is like a commit but not a commit. They're changes that git is aware of and has a record of but not quite a permanent record.

Why not just make it a commit? You can always keep editing commits, or throw them out, or whatever. That's what I do with Mercurial. I write a commit and I keep adding stuff to it if I think it needs more stuff (or less stuff).

Gregory Szorc has a more extensive analysis of the situation in first subsection here: https://gregoryszorc.com/blog/2017/12/11/high-level-problems...

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

#314

Post by erikb »

wyuenho wrote: post #300
erikb wrote: post #289

Earlier quoted context omitted.

Sorry, but you don't know git if you think Mercurial is even coming close. That is not trolling btw. It's really possible not to know what you can do with it if you haven't learned it in depth. The "Git Book" is what you should read. And you read it once, you read it indepth, and then you're done. After that it's also only 5 minutes of googling, but you can do a lot more. At that point you can even program a simplifi…

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

If you've experienced that once consciously, then you can regonize it and you know when you experience it you've hit someting really good in your life that moves you forward.

Sadly it seems you must take that hurdle in anything until a certain age or you will always believe this is impossible and therefore never invest the energy to reach it.

The thing is that this is not possible to achieve with any random software. For instance no matter how much you learn MS Word, you probably won't experience that. But when learning Vim or Emacs there's a chance you get there. Same is with git. And once you've achieved it once consciously, you will always want to be in that state in everything important you do.

That's why the really good stuff only has a few followers, most simply don't get the appeal because they never would invest the energy to get "there" even if they knew exactly how much it would take. But for those who have achieved it there is no going back. You cannot go back from controlling (almost) any bit of your repository to Mercurial.

But that's also why I think for most users something like Mercurial should be The VCS. Most people don't know the reward they are missing, so they don't feel the pain of missing it, and therefore have no logical reason to go through the pain of really learning git.

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

#315

Post by humblebee »

herogreen wrote: post #16

In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.

When I know what file I'm missing a commit from, I usually end up using `git log` instead.

    git log -p --all --first-parent --remotes --reflog --author-date-order -- somefile
I accidently screwed up a rebase and dropped a test file. It managed to get merged as a blank file (always review after rebase!), I noticed a few days later when a PR was passing which I swore would of failed some tests I had written. Since then I couldn't exactly remember when I made the commit to the file, so trying to search through reflog became difficult. The above command makes it pretty easy as it will show you every change made to a file.

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

#316

Post by sirmarksalot »

nerdponx wrote: post #299
swalsh wrote: post #123

Earlier quoted context omitted.

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…

You might want to try Sourcetree if you haven't already. I felt the same way about Git GUIs for a long time, but Sourcetree actually does a good job of getting out of my way, and has a very nice commit history tree viewer to boot.

I've found Sourcetree to be way too slow. My team is currently using the GitFlow model, for various reasons, and that involves switching between branches fairly regularly. It also means that any commit to master involves a lot of steps. From the command line, this isn't a big deal because each of those steps takes a half second or so, but Sourcetree multiplies that by an order of magnitude, and the Sourcetree users are nearing a point of mutiny.

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

#317

Post by rootlocus »

lkrubner wrote: post #281
rootlocus wrote: post #271

Earlier quoted context omitted.

Well, I see you're adding more and more constraints to suit your point of view. First you attacked git by pointing out some flaws that were only just about people not knowing how it worked. Then you gave a more specific example, where actually, it was in the company's best interest to hire a novice developer who didn't have time to learn git, because he was pressured into focusing on whatever the CEO wanted. Then you…

You don't give a reason for this: But please don't teach them SVN Why would you say this? You also say: If the company hires lower skill people, you can just guide choose a branching mode suited for their needs If the company has lower skill people, why not go with the technology that requires less skill? This seems like an obvious step.

Because SVN is painfully slow, bloated and almost nobody uses it anymore. You'd be doing them a disservice by teaching them a technology they most likely won't be able to take with them to their next job.

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

#318

Post by aglionby »

repsak wrote: post #274
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…

I use https://github.com/jonas/tig for interactive staging and git CLI for everything else. Best of both worlds and I don't have to leave the terminal.

+1, not having to use a mouse is great. I also use zsh's inbuilt git aliases [0] which I can't recommend enough -- I've found using git CLI without them a pain now that I'm used to them. These together have me productive and happy.

[0] https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git

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

#319

Post by machiaweliczny »

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…

On mac I can recommend Gitup. It's fast and easy. Also vs code has quite nice git integration. I just use it for making commits though. Everything else is faster from CLI.

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

#320

Post by machiaweliczny »

welly wrote: post #71
emeraldd wrote: post #59

Earlier quoted context omitted.

What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.

If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.

Gitup is free and probably better.
Post reply on HN