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

321–330 of 490 posts

Re: Git undo: We can do better

#321

Post by Nullabillity »

handrous wrote: post #69
dheera wrote: post #60

Earlier quoted context omitted.

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"?

> 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"? This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a p…

For the sake of your coworkers (and your future self), please don't lie just to make your history look pretty.

Re: Git undo: We can do better

#322

Post by pjc50 »

MereInterest wrote: post #203
urxvtcd wrote: post #135

Earlier quoted context omitted.

> And if I push without first pulling I think I know git well, but you got me confused. I've never heard of pushes causing merges. Surely you are talking about pulls, right?

Maybe somebody who has a habit of using --force when pushing. A major downside of rebase-centric workflows is that it teaches you to ignore the safety rails when pushing, or when deleting branches.

Wait, what? I've probably been using Gerrit too long but why do you ever need force in a rebase workflow?

Re: Git undo: We can do better

#323

Post by ufo »

rjmunro wrote: post #201
thewebcount wrote: post #128

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certa…

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…

By the way, I recommend using `push --force-with-lease `instead of `push --force`. This way it doesn't destroy the remote changes if someone else pushed while you weren't looking.

Re: Git undo: We can do better

#324

Post by pjc50 »

lugged wrote: post #116
dheera wrote: post #60

Earlier quoted context omitted.

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"?

Git init inits a git repo. Git submodule runs commands on submodules. What is hard about this UX? And it's not punishing you, its doing what you asked, to pull into a non matching head, how does it know you're not using git in the intended and distributed way? Btw, just quit the editor without saving, it aborts.

The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master.

Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.

Re: Git undo: We can do better

#325

Post by unknown_error »

cerved wrote: post #310
AlexSW wrote: post #282

Earlier quoted context omitted.

Agreed. I consider myself pretty competent at git (consistently helping out the rest of my team of ~15 people with it) and even then I've shot myself in the foot using `git checkout --` instead of `git reset` before to unstage a file, and lost all of my work on it. Really felt that should have given a warning.

use git stash instead to unstage changes not committed to the index and you'll never lose anything ever again

The point is that you shouldn't have to learn everything by brutal trial and error, losing hours of work each time you try to learn a new operation and make a small mistake.

It's the same reason consumer operating systems have a trash can and undo features. Just railing on people with "you should've known better" doesn't really help.

Re: Git undo: We can do better

#326

Post by sixstringtheory »

pjettter wrote: post #176
prisonality wrote: post #164

Earlier quoted context omitted.

> Git should store the commands that "did" the operations on a repo. is `git reflog` not enough for your use case ?

No, I mean more like an audit trail. Not like `blame` either. What I typed on the command line to get into a new state.

What about `history | grep “^git”?

Edit to add: the downside is that it only works in the current terminal session. To workaround that for myself, I have a fish shell post exec function that records the last command run, plus a bunch of metadata, to a log file.

Re: Git undo: We can do better

#327

Post by stormbrew »

pjc50 wrote: post #320
nicoburns wrote: post #231

Earlier quoted context omitted.

I tend to default to `git pull --rebase`.

I have this configured as default everywhere and strongly believe that merge-pulls are always wrong. The first place I used git we were learning together (i.e. nobody knew what a sensible workflow was) and people would push their local merge commits back to master. It was horrible.

`git config merge.ff=only` is really helpful for enforcing this. It makes you have to say what you want for any non-trivial update of a ref through pull or merge.

Re: Git undo: We can do better

#328

Post by simonelnahas »

unknown_error wrote: post #317
stickfigure wrote: post #265

Earlier quoted context omitted.

I was. But it wasn't quite as pointless as it sounds - the tool was a sort of tripwire-like system, with changes shipped to an append-only log, that itself was checkpointed in an early blockchain-ish structure. The threat model was "nation state actor" so the client wouldn't accept SHA1. It was actually a pretty cool system. I don't think it was ever sold though.

Man, I thought zero days and secret backdoors were bad enough. Now we have to worry about manufactured hash collisions in all our repos' files dating back forever?

That seems like an overkill. Couldn't you combine the hash together with the date to obtain uniqueness?

Re: Git undo: We can do better

#329

Post by mixmastamyk »

ivanbakel wrote: post #165
zabzonk wrote: post #97

Earlier quoted context omitted.

Actually, one of the reasons I preferred hg to git is that Windows explorer GUI integration back then was far superior to gits, which was buggy as hell.

This doesn't seem relevant to the comment you're replying to. Bitbucket's web UI sucks, which is why it didn't have the effect on Mercurial that Github had on git. Having used Bitbucket and GitHub, I think GH is much nicer - both in the sense of basic stuff like page loads being faster, and in terms of features. And since it's the main tool that everyone on the development team spends their time on for communication…

Also, remember to compare the sites ten years ago rather than today.

Re: Git undo: We can do better

#330

Post by xorcist »

usr1106 wrote: post #183
fierro wrote: post #146

Earlier quoted context omitted.

can you explain the `git pull origin master` thing one more time here?

I don't think using `git pull` is a particular good way of working. A pull is a fetch and merge or a rebase combined. If it's difficult to keep your mental model of some system up to date, I doubt that doing bigger steps at once makes things easier. So 1. run `git fetch` 2. if the textual output does not tell you what has happened, run `gitk -all` 3. Decide what to do. Rebase, merge, whatever. Of course if you know e…

This is literally the first advice I give when teaching people git. The first months of use, just run the two commands separate. Many mistakes are avoided that way.
Post reply on HN