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

211–220 of 520 posts

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

#211

Post by rootlocus »

lkrubner wrote: post #179
rootlocus wrote: post #58

Earlier quoted context omitted.

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

" Instead of blaming the tools, you (and your team) should probably learn how to use them. " From the essay: -------------------- And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t…

> 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're telling me a developer was too busy learning "other technologies", and in 6 months he couldn't be bothered (or was too afraid) to spend one or two hours going through a simple course about git? By that argument, he probably couldn't be bothered to learn how separate concerns into classes or how to use refactoring or write tests. What other things didn't he have time for? Unwillingness to learn is not an excuse.

> he never really learned how to use Git, because it was a low priority, for both him and our CEO.

I think it was more of a lower priority for your CEO than Sital. Learning git was something that benefited him more than it benefited the company.

I still have issues with your attitude, because it can be applied to anything useful in software development, but management might take issue with. Writing tests? Who needs them? The CEO doesn't care so they're low priority. Refactoring? Waste of time. Management wants shiny features not code quality. Developers have tried really hard to convince management that some overhead is needed to keep the quality high and maintenance easy. Your attitude is the exact opposite.

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

#212

Post by YoyoyoPCP »

theptip wrote: post #197
reificator wrote: post #164

Earlier quoted context omitted.

> committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

`git add -p` adds by the hunk, which is a unit of quantization bigger than a line. E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk". (Waiting for someone to chime in with how to split a hunk and change my life).

You use the 'e' option which allows you to edit the hunk. Remove the minus sign or the entire line with a '+'

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

#213

Post by dasil003 »

PuffinBlue wrote: post #178
dasil003 wrote: post #151

Earlier quoted context omitted.

You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks. I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split. However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don…

> One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level. Sorry if I'm being think, but how do you do that? Are you talking about Gblame?

Yes, Gblame then in the blame pane ‘o’ to open the commit, then in the commit pane navigate to a file name and ‘o’ to open the old file, then rinse and repeat. You can trace line history across files this way.

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

#215

Post by leggomylibro »

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

Reminds me of a time I saw a funny Makefile mistake. SRCS contained both .cpp and .c files, and someone copied a recipe that only replaced .c ones.

Then they used the resulting variable in 'make clean'. That was more of an, 'oh shit, git pull' sort of thing though.

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

#216

Post by lkrubner »

rootlocus wrote: post #189
vijucat wrote: post #158

Earlier quoted context omitted.

Great list. You'll face a predictable backlash by git fanatics, but the fact remains that git's surface area / complexity is way beyond the needs or wants of non-technical users. This is another good rebuttal to the supposed shortcomings of svn which make git necessary: https://svnvsgit.com/ You're right about the joy that end users feel when they learn TortoiseSVN and are able to put what they see as "infinite undo"…

Almost everything on that list is wrong, but if I point something out (because I actually learned how it works), I'm just a predictable git fanatic? How is that different from burying your head in the sand?

because I actually learned how it works

The argument is focused on those who can not learn how it works. See some of the other excerpts from the essay that are in this thread.

Also, it's important to note that everything on that list is something that actually happened. Be careful about comparing your advanced skills to people with less skill than you.

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

#217

Post by lfrb »

theptip wrote: post #197
reificator wrote: post #164

Earlier quoted context omitted.

> committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

`git add -p` adds by the hunk, which is a unit of quantization bigger than a line. E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk". (Waiting for someone to chime in with how to split a hunk and change my life).

You can use 's' to split a hunk but it would indeed not work if you want to split two consecutive lines.

You can also use 'e' option to edit the hunk to e.g. remove one of the added line.

Nothing as easy as clicking a line in a GUI though.

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

#218

Post by deragent »

theptip wrote: post #197
reificator wrote: post #164

Earlier quoted context omitted.

> committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

`git add -p` adds by the hunk, which is a unit of quantization bigger than a line. E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk". (Waiting for someone to chime in with how to split a hunk and change my life).

Within 'git add -p' when you get to the hunk that you want to edit (split down to single lines), press 'e'. This will open an editor (vim in my case) which lets you edit the diff manually.

In there you can remove added lines (prefixed by '+') by removing them, and re-adding removed lines (prefixed by '-') by replacing the '-' with a space ' '.

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

#219

Post by dilap »

aldanor wrote: post #195
dilap wrote: post #192

Earlier quoted context omitted.

Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

Well. That depends :) I don't develop in Emacs and use it solely for hosting Magit, in a separate window. So it's kind of a GUI I guess; more so than a CLI anyway. > It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.) Don't remember a single of case of it feeling too slow in the last few years, whether on linux/mac... (maybe it just got better over time though…

interesting. i'm on mac; i'll have to give it another try. also we might just have different ideas of "too slow"; for common operations, anything more than instant is basically too slow. :-)

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

#220

Post by falcolas »

swalsh wrote: post #129
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 (…

rebase can be dangerous, but so productive. I think it's important to teach new devs how to properly use it. Especially if you're working in a continuous deployment environment, where you may need to quickly revert something.

Reverting something does not require a rebase. It requires an aptly named command "git revert". Additionally, in the event that a deployed feature needs to be reverted, any halfway decent change management policy will want a history of what you reverted and why; a git revert commit can show both very cleanly.

And, frankly, since all rebase does is re-write history, I fail to see how it's inherently productive, especially in the context of re-writing the history of previously shared commits. Yes, it is capable of cleaning up and reducing the number of commits you have to read through when looking at history, but that's such a rare event that optimizing for it (especially by normalizing dangerous commands like `git push -f`) seems, well, premature.

Post reply on HN