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

451–460 of 520 posts

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

#451

Post by iamjaredwalters »

jsmthrowaway wrote: post #369
xaphod wrote: post #364

Earlier quoted context omitted.

This is so wrong. :) With git you exactly do not have to backup your local workspace, because it already is backed up in git. If it is committed, it is safe. You can go back to it. If you messed up your branch, just reset it to something that was good. No need to do manual backups.

No, it isn't, if you're playing with surgical tools that disrupt Git history, which was my point. It's a lot easier to revert to before you started than attempt to abort out of a huge rebase/squash/ugly merge conflict hell/rewrite of history. I'm not saying back up before every commit. I'm saying when `git status` is three pages long, you have 14,000 conflicts, and you're on a detached HEAD God knows where, it's your…

Why not just create a new branch instead of copying your project over to a new dir?

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

#452

Post by compiler-guy »

yes_or_gnome wrote: post #410
compiler-guy wrote: post #285

The fact web pages like this exist, and are popular, and make it to the top of Hacker News is all you need to know about git's ease-of-use and mental model. That Perforce and SVN don't get such things should also tell you something. (Which isn't to hate on git--it's a great tool.)

The SVN and P4 articles exists (just google for "svn mistakes" and "perforce p4 mistakes"), but either 1. nobody is sharing them to HN or 2. they do and nobody cares to vote them up. Unrelated topic (falling cats), same logical fallacy: http://www.radiolab.org/story/102525-vertigo/ (Starting around 14:20)

“Nobody submits them, or nobody cares to vote them up.”

That should tell you something: these articles don’t resonate with the crowd. That should tell you something.

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

#453

Post by gwright »

falcolas wrote: post #431
palunon wrote: post #339

Earlier quoted context omitted.

>If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever. I disagree. I don't have much experience using git with big teams, but at least for small team where a developer usually owns a feature branch, force pushing to the branch to take into account criticism on commits can be helpful. Of course, in that case, feature branches are considered non shared. Git own "next" branch is…

Personal opinion - re-reviewing a pull request when someone has erased all context from your last review of that PR via a rebase and force push is a royal PITA. Especially for changes that span more than a few files. Did they address your concerns? The only way to know is to go back through all of the changes on that feature branch, and hope you don't miss anything. This, in contrast with just reviewing the latest co…

I've taken to making the change as a fixup commit and leaving it in the PR for code review. Then when the changes are approved a quick `git rebase -i --auto-squash` cleans everything up before merging the branch back into `develop`.

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

#454

Post by deathanatos »

jordigh wrote: post #313
deathanatos wrote: post #276

Earlier quoted context omitted.

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

My best guess is that the commit metadata (particularly, message) is missing. You could always have it be "(uncommited, staged changes)" though, and that's probably descriptive enough. (I agree with you on the whole: having the staged data be a commit makes things conceptually much simpler.)

My other guess is that the "index" (the other name for the staging area) is also used for conflicts during merges & rebases, and that somehow plays into the problem of making it an actual commit. (But again, this comes across more as an excuse than a reason: I don't any viable reason why the staged changes can't still be an actual commit, and the merge conflict data just stored as a separate structure.)

That, or the person who added it just didn't think of it, or couldn't do it due to backwards compatibility.

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

#455

Post by outworlder »

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…

"- It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow." "- My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.)"

Do you mean that as "not committed", or "not pushed"?

If you mean not committed, then why is it a good thing? You should be committing often. Then you push after you are satisfied. It is much easier to revert mistakes that way.

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

#456

Post by rhencke »

nothrabannosir wrote: post #442
dasil003 wrote: post #418

Earlier quoted context omitted.

You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made…

> Git is fundamentally better than most of the alternatives No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously. I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, la…

1. Git LFS is not part of Git. It's an unofficial extension, despite the name. I've got my own qualms about Git, but that's like complaining about GitHub's forking model as a reason Git is bad.

2. Microsoft uses Git in single large-scale mono repo form, for - believe it or not - Windows. It clocks in at about 3.5 million files, and a full clone weighs in at 300GB:

https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...

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

#457

Post by hyperpallium »

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…

So... which git GUI are you using?

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

#458

Post by hyperpallium »

dilap wrote: post #187
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…

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model. The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.

I'd thought a programming language, for manipulating data structures, would work well... but when I had a go at it, it wasn't as easy to use as I thought. It's because the typical usage patterns aren't simple.

A gui with drag-and-drop to rebase a graph also seems like it would work well...

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

#459

Post by murukesh_s »

giancarlostoro wrote: post #291
dilap wrote: post #187

Earlier quoted context omitted.

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model. The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.

SourceTree keeps the same language regular git uses. But I highly agree. JetBrains IDEs add their own lingo out of support for multiple version control plugins I'm sure but its confusing and easy to screw up. SourceTree is the one GUI client I want on Linux...

This is one time when we wish source tree was written in electron!

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

#460

Post by yes_or_gnome »

sirmarksalot wrote: post #433
yes_or_gnome wrote: post #392

Earlier quoted context omitted.

Not really an issue with git, but with OSX. In doing some research of git, I wanted to look at the first git repos. Those are torvalds/git.git and torvalds/linux.git. If you clone linux.git on OSX and run `git status`, you'll see this: $ git status --short ## master...origin/master M include/uapi/linux/netfilter/xt_connmark.h M include/uapi/linux/netfilter/xt_dscp.h M include/uapi/linux/netfilter/xt_mark.h M include/…

I disagree here. Case-insensitive file systems have existed for decades, and are part of the development landscape. Any tool that works across multiple machines needs to support them. In this case, I blame Bitbucket, for not providing any way to treat this as a merge conflict.

The tool that doesn't work with case insensitive filenames is OSX.

Edit: To add, how is git supposed to handle two files with the same name -- as is the case -- with a case insensitive file system? You can't have two files with the "same" name.

    git checkout file1
Is entirely different than

    git checkout FILE1
In any other platform ls file1 FILE1 would show two different files, but on OSX, it'll show the same file twice.
Post reply on HN