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

Git undo: We can do better

blog.waleedkhan.name

Post reply on HN
Print view View original

411–420 of 490 posts

Re: Git undo: We can do better

#411

Post by cerved »

glandium wrote: post #315
cerved wrote: post #302

Earlier quoted context omitted.

That's why it's a flag. You could do git reset HEAD^ && git stash instead Also, git reset ---hard HEAD^ deletes nothing. The commit HEAD was pointing is not deleted. You have to work really hard to delete that commit accidentally

It does delete whatever uncommitted changes you had.

true, if they are modifications and deletes but not additions

it'd be trivial to modify that behavior to refuse to continue in such a case if you want double seatbelts

also, if the changes were staged they were recorded in the database and remain there

Re: Git undo: We can do better

#412

Post by [deleted] »

npteljes wrote: post #207
rjmunro wrote: post #201

Earlier quoted context omitted.

There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine. But `git checkout filename` means "undo changes to the file". What? That's totally insane. `git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you u…

And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.

[deleted]

Re: Git undo: We can do better

#413

Post by urxvtcd »

MereInterest wrote: post #267
Zarel wrote: post #248

Earlier quoted context omitted.

`--force-with-lease` would fix this problem (it needs an alias). Also, `--force` wouldn't cause a merge commit; it would overwrite the remote changes. The only theory that makes sense is that this person doesn't know how to `pull --rebase`, but the order of `push` vs `pull` wouldn't change the presence of merge commits, so I'm still confused.

Ooh, --force-with-lease looks like a nice feature, especially for updating github PRs that aren't yet merged. I still wouldn't want to use it where anybody else has a copy of the changes, since that's where you need a merge commit to avoid breaking somebody else's repo, but that gives me a safer option than a blind --force.

Just remember that --force-with-lease only protects you from overriding commits you have not yet fetched.

Re: Git undo: We can do better

#414

Post by cerved »

dec0dedab0de wrote: post #45
pizza234 wrote: post #37

Earlier quoted context omitted.

Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.

I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.

it's very easy from the CLI. Much easier than from GUIs actually

  git diff
  git diff --staged
  git restore --staged --partial
  git commit
you can also add commit hooks to reject changes like conflict markers

Re: Git undo: We can do better

#415

Post by cerved »

fiddlerwoaroof wrote: post #100
dec0dedab0de wrote: post #45

Earlier quoted context omitted.

I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.

There’s a really easy way to check the diff before committing on the command-line: git commit -v Displays a diff at the bottom of the editor that pops up to write a commit message.

you can also set

  git config commit.verbose true
to always have this behavior

Re: Git undo: We can do better

#416

Post by cerved »

tailspin2019 wrote: post #314
cerved wrote: post #232

Earlier quoted context omitted.

It's a handful of commands, very well documented with tons of SO questions that is one search away if you can figure it out yourself. It's something I use all day, every day. I'd say it's worthwhile to learn if your daily job involves working under source control

Yes I agree. If you’re going to use git (whether by choice or force) it is 100% worth learning the small set of commands required to undo a screwup without needing to reclone. Recloning to me is a bit like tearing your house down and rebuilding it just because you painted your living room the wrong colour (in most cases!)

at least if you are a carpenter

Re: Git undo: We can do better

#417

Post by jacobmischka »

dheera wrote: post #60
handrous wrote: post #32

Earlier quoted context omitted.

I know (or, at least, have known ) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the com…

Yes. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands. And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?

I usually use `git pull -r` to rebase upstream changes

Re: Git undo: We can do better

#418

Post by cerved »

secondcoming wrote: post #306
kahkeng wrote: post #222

Earlier quoted context omitted.

I find it pretty useful to use the `--patch` or `-p` option (also a mnemonic for "prompt") to various commands: `git add -p`: prompt which hunks should be added to staging `git checkout -p`: prompt which unstaged hunks should be thrown away `git checkout HEAD^ -p`: prompt which hunks from HEAD should be discarded `git reset -p`: prompt which currently-staged hunks should be unstaged `git reset HEAD^ -p`: prompt which…

hunk?

noun

1. a large piece of something, especially food, cut or broken off a larger piece.

Re: Git undo: We can do better

#419

Post by leafmeal »

yarg wrote: post #281
leafmeal wrote: post #269

Earlier quoted context omitted.

So like a branch that automatically rebases on another branch? I think the issue with this is the inevitable conflicts and race-conditions. While nice in theory, often you need manual control to sort things out.

Not quite - branches get ancestors. A new repository starts with an empty branch. A DAG gets layered on top. I mentioned conflicts, but can you explain where race conditions would arise?

I guess I was imagining a conflict as the result of a race condition. Two concurrent changes are made where if they were ordered, there would be no conflict.

Re: Git undo: We can do better

#420

Post by atulatul »

pjmlp wrote: post #399
somethingor wrote: post #241

Earlier quoted context omitted.

TortoiseGit exists too and is fantastic IMO: https://tortoisegit.org/

Indeed, it makes using git so much less painfull. There are days where I daydream of Clearcase when dealing with git.

Early in my career- when I got evil twin error- I was conditioned not to daydream of clearcase ever. :)
Post reply on HN