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

61–70 of 520 posts

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

#61

Post by ivix »

jimktrains2 wrote: post #37
anton_gogolev wrote: post #29

Earlier quoted context omitted.

If by "designed" you mean "picking a content-addressable DAG as an underlying data structure", then yes, it is really beautiful. If you mean "provide a sane level of abstraction over said data structure", then hell no!

I think git provides a sane level of abstraction. I don't think it provides the most consistent UI or helpful help, though. Once you move away from "learning git commands" to "learning how git works" and kind of figuring out which parts the commands refer to has helped also. That's still terrible though.

>I don't think it provides the most consistent UI or helpful help, though.

Understatement! Git is one of the most user-hostile tools I've ever seen. And I've used Sendmail.

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

#62

Post by lmm »

m6PeelVLsQ8QawN wrote: post #2

It happens to everyone :) I'd like to contribute my list of git booboos: https://github.com/1337/yesterday-i-learned/blob/master/git....

> I used git in the terminal and the diffs/patches/merges/pull requests don't turn out right

Your answer there is just doing git pull --rebase by hand. I don't like that style at all, but if you must do it surely use the command that's designed for doing it.

> I pushed stupid things onto the remote server

Worth saying you can branch before fixing - that might be a little less intimidating than "access by commit ID"

> I already made my changes in multiple commits, but the repo owner wants me to rebase it to a single commit

Disagree with "you should do it", though that's probably a political question.

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

#63

Post by nobleach »

pc86 wrote: post #36
taoistextremist wrote: post #30

Earlier quoted context omitted.

I'm planning on making a hard push for git on the team I just joined (that isn't using any VCS). This and OP are going in my bookmarks.

I'm genuinely curious how they manage source without any VCS. Is it just a bunch of zip files for old versions? No judgment, nobody is born knowing this stuff, just that I'm surprised to hear this is still out in the wild.

When I started working for the government (2010) it was .backup, .bak, .new, .newNEW, new-JIM, .20100910... all on one guy's workstation. Luckily Gitorious landed within months. (better than nothing)

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

#64

Post by Cthulhu_ »

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 don't trust GUI clients; it's easy to not be able to discern the current status, easy to just commit all changes, some of the clients don't respect the pre-push hook, and I've seen other colleagues who have no clue what they're actually doing end up mixing pull and pull --rebase, somehow managing to make duplicate commits with slightly different contents and not having a clue what's going on.

Don't use clients if you don't even understand the basic git workflows. And those usually don't support the advanced oh shit situations this article is about.

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

#65

Post by taoistextremist »

Cthulhu_ wrote: post #60
taoistextremist wrote: post #30

Earlier quoted context omitted.

I'm planning on making a hard push for git on the team I just joined (that isn't using any VCS). This and OP are going in my bookmarks.

> I'm planning on making a hard push for git on the team I just joined You mean a force push. `git push --force` is one of my favorite commands. I've aliased `git yolo` to `git push --force --no-verify`.

Maybe I ought to also insist I build git from source and scrub any reference to --force from it.

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

#66

Post by vulkoingim »

nikanj wrote: post #31

We pushed large binaries into our git in the past. This was fine-ish as long as Git was hosted inhouse, but now that it's SAASed out, they are a huge pain in the rear. I've browsed through a few git guides, but can't seem to find anything that would let me: 1) Do something like "du -s *|sort -n" for the entire Git history 2) Let me "rm -rf --from-history-too", that would cause the remote repo to actually shrink in si…

Have you tried this:

https://rtyley.github.io/bfg-repo-cleaner/

I've used it in the past, and it's pretty straightforward and does the job well :)

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

#67

Post by teilo »

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…

Most of these have nothing to do with git, but are true of any distributed repository. At that point, your argument becomes: distributed repositories are bad for business.

Then there's this:

> Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion.

What rubbish. The features of subversion are a subset of git, and the git equivalents are easy to learn. For a svn user, there's literally only a single additional command they need to know: git push.

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

#68

Post by mistersquid »

nikanj wrote: post #31

We pushed large binaries into our git in the past. This was fine-ish as long as Git was hosted inhouse, but now that it's SAASed out, they are a huge pain in the rear. I've browsed through a few git guides, but can't seem to find anything that would let me: 1) Do something like "du -s *|sort -n" for the entire Git history 2) Let me "rm -rf --from-history-too", that would cause the remote repo to actually shrink in si…

Early in the history of a repository, I committed some files with sensitive information. The only way to fix this (and similar problems) is to reconstruct the repos starting from the commit just before you committed the unwanted file(s).

I'm a bit of a git naif, there are doubtless better ways to do this. This was mine:

  0. Back up my repo.
  1. Save the entire commit history as patch files.
  2. Use BFG (amazing tool) to scrub all references to the unwanted files [0]
  3. Create new repo from the commit just before unwanted files.
  4. Apply the patches.
  5. Use a custom Perl script to apply the dates in the patch files to the new history. [1]
Technically, your repo will be fully reconstructed at step 4. Also, be advised the patch files themselves may have to be massaged to remove references to the file(s) in question. If the filenames themselves are not unwanted, you can add them to .gitignore for good measure.

Step 5 merely preserves the dates of the original commits. Keep in mind that for this last step, your script will have to work in reverse chronological order as the history will be altered from that point forward.

  [0] https://rtyley.github.io/bfg-repo-cleaner/
  [1] http://eddmann.com/posts/changing-the-timestamp-of-a-previous-git-commit/
EDIT: Swap steps 1 and 2. Add advisement that patch files may require manual alteration. Add hint regarding .gitignore. Title case "Perl".

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

#69

Post by Cthulhu_ »

pmjordan wrote: post #47
nikanj wrote: post #31

We pushed large binaries into our git in the past. This was fine-ish as long as Git was hosted inhouse, but now that it's SAASed out, they are a huge pain in the rear. I've browsed through a few git guides, but can't seem to find anything that would let me: 1) Do something like "du -s *|sort -n" for the entire Git history 2) Let me "rm -rf --from-history-too", that would cause the remote repo to actually shrink in si…

I think you should be able to do something like this with git filter-branch This won't be a terribly fun exercise, and could be very painful if your history contains a lot of merges. (should be easier with the cactus/rebase development model) And of course everyone will have to hard-reset to the new branch. I should mention I'm far from an expert on this. I've only ever used git filter branch on a handful of commits,…

Yeah, filter-branch is the way to go for this. Also to for example extract a folder into a new repository. I've used it in a few cases.

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

#70

Post by rhodysurf »

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…

For the most part using git is like five commands and it is definitely fast to use them from the command line if you have some sort of git understanding
Post reply on HN