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

431–440 of 520 posts

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

#431

Post by falcolas »

palunon wrote: post #339
jsmthrowaway wrote: post #298

Earlier quoted context omitted.

Yep. That is the important tip, right here. $ pushd .. $ cp -a my-project my-project-before-I-did-git-surgery $ popd Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up? $ pushd .. $ rm -rf my-project $ cp -a my-project-before-I-did-git-surgery my-project $ popd Undo is a great thing, and it's also important to triple check the entire state of the re…

>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 commit, potentially going back to the rest of the changes with an eye towards the latest commit.

It frankly bugs the piss out of me when people rebase and ask me to review their latest changes - it feels disrespectful of my time.

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

#432

Post by u801e »

dasil003 wrote: post #247
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.

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations…

> The built-in porcelain is stupidly inconsistent and confusing.

That's why I end up using the plumbing commands to do things that porcelain commands don't let me do directly. For example, I'll use git diff along with git apply and recountdiff (from the patchutils package) to stage individual hunks or edit hunks prior to staging.

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

#433

Post by sirmarksalot »

yes_or_gnome wrote: post #392
sirmarksalot wrote: post #381

The absolute worst situation I've gotten into was just the other day, when my team managed to check in two files with the same name, but different capitalization. The server (Bitbucket) is Linux-based, but all the workstations are Mac or PC, so the names collided on everyone's desktops. This prevented anyone from pulling or checking out a different branch, so even after master was fixed, everyone's environment stayed…

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.

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

#434

Post by u801e »

dasil003 wrote: post #206
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.

Say you have 3 sequential lines, but you only want to stage the middle one. You can’t split it into smaller hunks by hitting ‘s’ during ‘git add -p’. I’m sure there’s a way I’m just not familiar with but I just use Sourcetree for this on the rare occasion it occurs.

You can also manually edit the hunk to remove the 2 lines you don't want to stage and use the recountdiff utility to update the hunk header.

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

#435

Post by thomasahle »

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 was in the cli only camp, but I just looked at GitUp and that actually looks really useful!

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

#436

Post by krapp »

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

I use either the GUI on Windows or a set of batch files I wrote to automate basic things.

As long as all you're doing is pull, branch, merge and commit, I don't think it matters.

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

#437

Post by donarb »

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

XCode rolled out a feature that allowed you to do an interactive commit just by click on/off switches. My first use of that feature screwed up the repo by committing the wrong pieces.

No thanks, it’s CLI for me, regardless if the IDE promises git support.

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

#438

Post by donarb »

mikedelfino wrote: post #413
dasil003 wrote: post #247

Earlier quoted context omitted.

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations…

One could also setup aliases for some of the incantations. I personally have `git uncommit` aliased to the proper command line that I never remember.

I use aliases for the most common commands, gs, gd, gb, gco, ga, gc. You can guess what those do.

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

#439

Post by falcolas »

falsedan wrote: post #398
sirmarksalot wrote: post #383

Earlier quoted context omitted.

To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.

That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream. When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pu…

Anytime you normalize a workflow around using unsafe commands, you risk desensitization to those very warning messages you're relying on to save you.

If you have one rebase with a force push a week, people will quickly stop asking "who did the force push", since it has become normal. They'll instead just let the force push come through to their local repo, just to find out that the force push rolled the repo back a year. Now productivity is halted dead until someone goes in and fixes it and makes yet another force push.

The worst part to me is that it makes the repo lossy. The entire purpose of having version control is actively subverted in the name of "clean".

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

#440

Post by sirmarksalot »

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.

The issue isn't with the level of abstraction, but with the side-effect based workflow of some of the more common commands. The most visible of these is unstaging a file.

The syntax is "git reset -- ". What does that do? Well, it tells git not to change the head pointer. Of course, it wasn't going to do that anyway, but as a side effect of not doing anything, it makes a decision about what to do with all the staged files. The default resolution is to unstage everything so that everything that happened between the old head and the new head can go in the stage. When you add the "--", you're telling it to only apply that resolution to the specified files.

So what you're actually telling Git is, "don't do anything, but when you don't do anything, move these files out of the stage so that you have room for all the files that you're not going to stage."

And this is why I used Git for an entire year without actually knowing what "git reset" does.

Post reply on HN