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

271–280 of 520 posts

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

#271

Post by rootlocus »

lkrubner wrote: post #258
rootlocus wrote: post #211

Earlier quoted context omitted.

> He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. Git is something that you can use on almost any project, with any team, at any company. It's something you need to use if you want to contribute to open source. Aside from your programming language of choice, it's probably the second most useful tool you should be learning as a software developer. You…

* Your attitude is the exact opposite. * You setting your theory against my lived experience. If you want to understand the situation more fully, you can read How To Destroy A Tech Startup In Three Easy Steps: https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09... I did my best to re-create the extent to which decisions were driven by panic and the pressure of time. Please note, every company in the world ha…

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 argued that really, companies can't hire good people, or train them, or use good practices and we should just use the path of least resistance. At the end of the argument, it wasn't really about git.

The issue you have with git, is that untrained developers have a hard time using it. Which brings me back to my original comment. It really doesn't take long to train someone to use git. And you can choose whatever flow you want. That's the beauty of it. If the company hires lower skill people, you can just guide choose a branching mode suited for their needs. They don't even need to use branches. Or just teach them to use an UI. But please don't teach them SVN.

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

#272

Post by nlawalker »

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've become a big fan of Git Extensions. I like that it doesn't try to layer its own agenda over the Git workflow, shows all the console input/output it uses, and warns me when I'm about to do something stupid, but overall I like it for the same 3 reasons that I like most GUIs:

- It's a live dashboard. A GUI gives me live, persistent information organized well on the screen. I appreciate the power of the CLI for accomplishing tasks, but I've never understood how people prefer it when it comes to simply viewing and understanding the state of something. I don't see why I'd want to run a bunch of commands to see stuff scroll by in my format-constrained terminal when I can have a live, all-up view of multiple aspects of a repo all at once, with relevant, context-sensitive commands on whatever I click on.

- It's discoverable. Most of what I've learned about git has been through clicking around in Git Extensions.

- The structure and organization of the UI helps me to understand how git operates. When I open the "Pull" dialog, for example, the way the controls in the UI are grouped and the kinds of controls that are used help me logically understand what "Pull" can do.

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

#273

Post by pivo »

Tobba_ wrote: post #244
aschampion wrote: post #118

Earlier quoted context omitted.

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.

Doesn't really make the interface any less crap; though I've yet to see a GUI that didn't shell out to the command-line interface (which almost always makes them very unreliable).

I believe GitUp directly links to git library and doesn't use a command line shell.

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

#274

Post by repsak »

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.

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

#275

Post by lmm »

jefurii wrote: post #132
lmm wrote: post #43

Earlier quoted context omitted.

Most of the abstraction is fine. The staging area model is a total mess though. The way that staging interacts with other commands (e.g. stash) is constantly surprising.

Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we? I had trouble with Git until I discovered "git add -p". I'll grant that Git could do with a revision of its commands and args.

> Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we?

But when a carpenter stashes and unstashes their things, they don't suddenly find out they're magically planning to do a lot of things that they weren't previously planning to do.

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

#276

Post by deathanatos »

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 from the file in your working directory. So, if after `git add`ing a file you make more changes, you will need to `git add` those subsequent changes if you wish to commit. `git status` will tell you this:

  » git status
  On branch master
  Changes to be committed:
    (use "git reset HEAD ..." to unstage)
  
  	modified:   foo.txt
  
  Changes not staged for commit:
    (use "git add ..." to update what will be committed)
    (use "git checkout -- ..." to discard changes in working directory)
  
  	modified:   foo.txt
"Changes to be committed" is the staged files. "Changes not staged" is stuff that has been modified, but not `git add`'d. You can see here that I've changed foo.txt after git adding it; if I want those changes, I need to git add it again.

I can look at the diffs, too:

  # diff between the last commit, and the staged files
  # (i.e., what will be committed)
  git diff --staged
  # diff between the staged files and the working directory
  # (unstaged changes)
  git diff
  # diff of all changes since the last commit:
  # (stage+working dir, essentially)
  git diff HEAD
That should be all the various combinations.

I find that a lot of newcomers find the staging area weird, and usually ask some variant of "why would I not want to commit all of the files I've changed?" The staging area, used effectively, can really help you break out things into logical chunks of changes that can then be adequately described with a message in a commit. This can help others later: if your change is a bug fix, and someone wants to cherry-pick it to production, they might not want your new feature, or your lint fixes: they want a minimally risky fix. To that end, the stage/working dir separation acts as a sieve of sorts, letting the stuff that's "ready to go" get filtered out into a commit.

I want to mention the extremely useful `git add -p`: this command will interactively prompt you, hunk by hunk, for whether or not you want to stage that hunk. It will even let you edit the hunks prior to staging. So, for example, if I run across a spelling error, or a minor bug, I can very quickly add it (and just it) to the stage w/ `git add -p`, and then commit it, even if there are other modifications, even in the same file.

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

#277

Post by lkrubner »

rootlocus wrote: post #58
lkrubner wrote: post #21

I've said this before, but the business leadership, and tech leadership, need to think carefully about whether or not they need all of the power of Git. This sums up my concerns: ----------------------- Here are some minor failure modes I’ve seen with Git: 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) 2. data is erased for good because someone makes a mista…

> 2. data is erased for good because someone makes a mistake while using rebase No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them. And rebasing generates new commits, leaving the old ones exactly how they were. If somebody lost a commit after a rebase, and nobod…

About this:

"No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them."

It is frustrating that you continue to take your advanced skills for granted. It is frustrating that you can not see what should be an obvious fact: that your skills are above average and therefore it is a mathematical fact that most people have less skill than you, and their lack of skill is a real world business situation that needs to be dealt with realistically. And more so, for the rest of your career your skills will continue to develop, so the gap between you and the average will continue to grow, and therefore the damage that you can do will continue to grow, if you fail to recognize that you are above average.

I can assure that I've seen data lost forever because of "git rebase". It doesn't matter that someone with your skills could have saved the situation. You were not there, therefore your skills don't matter! It is very important that you see this, or you will never be able to give accurate advice to business leaders.

If the leadership of a company decided to hire people with a skill level of x, then they should not also use a technology that requires a skill level of x + 1. You can reasonably tell them "For what you are trying to do, you should hire people with a skill level of x + 1." That is exactly what I did in the situation that I describe here:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

But sometimes the business leadership will disagree with you. They may have terrible reasons, but if you can not get them to change their minds, then you need to deal with the consequences of their bad decisions. At which point it makes sense to advocate for a technology that only requires a skill level of x.

[ EDIT TO ADD ]

I'll point out that you are demonstrating a classic case of the Dunning–Kruger effect. In particular:

"the miscalibration of the highly competent stems from an error about others."

That is, you have above average IQ and skill, therefore you perceive things to be easy, which are in fact not easy for the average.

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

You are an elite programmer. Try to avoid acting like the kind elite programmer that I criticized in "Business productivity has been undermined by the hubris and power-grabbing of elite computer programmers".

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

#278

Post by satish-setty »

trevor-e wrote: post #196

I think Git would be way more approachable if things were named better. A key part of Git is whether a file is untracked/unstaged/staged, yet the terminology around this is very confusing. Why aren't commands simply `git stage`, `git unstage`, `git add` (to track files), `git remove` (to untrack), `git undo`, etc? Not to mention the overloaded command names like `git checkout`, how is `git checkout -- someFile` intui…

This is precisely one reason I like Mercurial over Git. Hg has commands which are more meaningful than those of git.

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

#279

Post by nerdface »

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…

Yes, this is another one that confuses developers. When you 'git add' a file, it's added to the staging area as it was at that time. If you make subsequent modifications after you've staged it, those are unstaged changes. And you can diff between them. So despite git add'ing a new file, you still have to 'git add' afterwards if you make changes to it.

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

#280

Post by pretentiousPear »

flowardnut wrote: post #111
AlexCoventry wrote: post #81

Earlier quoted context omitted.

On the other hand, doing it is the only way you're going to learn. Just do it in a safe environment, with a snapshot of the repository.

practicing safe version control is better than abstinence

I see what you did there...
Post reply on HN