Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh Shit, Git?

ohshitgit.com

Post reply on HN
Print view View original

181–190 of 275 posts

Re: Oh Shit, Git?

#181

Post by zahlman »

lilyball wrote: post #102
lalaithion wrote: post #29

Earlier quoted context omitted.

The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…

The "move a branch" command is `git push .`. Yes, you can push to the current repo. I have a script called git-update-branch which just does some preflight checks and then runs `git push --no-verify . +$branch@{upstream}:$branch` to reset a branch back to its upstream version.

> The "move a branch" command is `git push .`. Yes, you can push to the current repo.

Wouldn't that copy a branch rather than moving it?

Re: Oh Shit, Git?

#183

Post by zahlman »

baobun wrote: post #106
pitaj wrote: post #3

Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…

5. Teaching `git add .` as default to add changes to the staging area is not ideal. Show adding specific files instead has less room for subsequent "oh shit" and better.

Learning about the `-p` option for `git add` was one of two things that revolutionized my Git usage. (The other was figuring out how to write effective commit messages.)

Re: Oh Shit, Git?

#184

Post by zahlman »

WorldMaker wrote: post #125
jimbob45 wrote: post #97

Earlier quoted context omitted.

SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.

Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth. It is its own footgun as well, but with git you can git init any directory you want and have a repo. Other than the learning curve of the not particularly well tuned CLI (and there are all sorts of graphica…

>Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth.

Many years ago, SVN worked fine for me for single-user projects. I just made my own desktop be the server. But I wasn't publishing my code back then (it's not as if I would have have any effective way to tell people about it anyway). Now I have no idea how the equivalent of "pushing to origin" would have worked.

Re: Oh Shit, Git?

#185

Post by zahlman »

tantalor wrote: post #38

I'm not a git user, but stuff like this really drives home the idea that "git commit" is meaningless, the only thing that matters is when your commits are pushed or merged. It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.

>It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.

Do you write a little message about your day every time you go to sleep?

I actually don't, and maybe you don't, but plenty of people do.

I think of the Git revision log as much like that sort of diary, offering the same sorts of advantages. It's more organized than having a separate TODO list document; and it encourages you to describe what you've already done in a clear readable way, too. When you're trying to figure out how far to roll back, it may be useful to understand what you were thinking at the time of the commit. And if something turned out to be the wrong approach, it helps you do the post-mortem.

And, of course: if your unmerged, unpushed work is organized into separate changes that have separate (and labelled goals), and part of that work turns out to be good and part bad, it becomes vastly easier to preserve the good parts.

Re: Oh Shit, Git?

#186

Post by zahlman »

maleldil wrote: post #133
wruza wrote: post #81

Earlier quoted context omitted.

This should be a built-in git unshit Or git add --unshit -f ~HEAD^^ If you’re using git version <= 2.844.

Jujutsu has `jj undo`, but which undoes whatever was your last jj command, regardless of what it was. It makes much more confident to do an operation I'm uncertain of. And if I regret something many actions down the line, you have `jj op log` (a better reflog).

If you `jj undo` a second time, does it redo (undoing the undo), or does it back up another step?

Re: Oh Shit, Git?

#187

Post by krick »

ajross wrote: post #131
pitaj wrote: post #3

Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…

> 1. Always use `git switch` instead of `git checkout` Even harder: always use "git reset --hard". Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done. If you need to m…

At first I was put aback by this, but it actually kinda makes sense. I mean, if people are giving off unwarranted advises about "the right way" here, yeah, you should start with a remote branch, and push all your work ASAP. Especially when you are closing the lid of your laptop to change location.

...Not that I am gonna follow that advice, of course. Same as I'm not gonna use git switch for a task git checkout does perfectly well.

Re: Oh Shit, Git?

#188

Post by teaearlgraycold »

jopicornell wrote: post #130
jaapz wrote: post #118

Earlier quoted context omitted.

Could you motivate why you suggest these? Why is `switch` better than `checkout`? And why not use `reset --hard`?

Not comment OP, but checkout has two very different uses merged into one: restoring files and switching branches. To not break compatibility, git has now switch and restore commands that make commands more readable and understandable. You should avoid reset --hard because it will delete all your uncommited, and you could end up in situations where that's really bad. Using reset --keep will keep uncommited changes, an…

I just do

    git add -A

    git stash

    git reset --hard

    git stash pop

Re: Oh Shit, Git?

#189

Post by krick »

jimbob45 wrote: post #97
phtrivier wrote: post #89

This will feel very weird in April 2025, when we celebrate the 20th anniversary of git. I was there. And at some point I wondered if I should learn git, darcs, or bazaar, to replace SVN or CVS. Or did I try mercurial too ? I wonder if the "GitHub" effect has basically killed the need for a newcomer in the space of VCS. Maybe at some point, the yak is shaved enough ?

SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.

Working with SVN was terribly slow on any decent size codebase.

Re: Oh Shit, Git?

#190

Post by zahlman »

antithesis-nl wrote: post #12
1over137 wrote: post #7

Earlier quoted context omitted.

We’re not all working at $bigcorp with dedicated help teams. Sites like this are great and have helped me many times!

OK, so you've truly screwed up your your personal/small-team repos to the point of requiring poorly-understood command sequences from the Notoriously Reliable Internet more than once? I applaud you for your honesty, but... Really?

I don't understand your surprise or disbelief. I would imagine most devs have been there. As evidence: just look at Stack Overflow, and compare it to what it's apparently intended to look like and how it's supposed to work (as a denizen of meta.stackoverflow.com I am quite familiar with this struggle).
Post reply on HN