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

241–250 of 275 posts

Re: Oh Shit, Git?

#241

Post by thfuran »

seba_dos1 wrote: post #202
thfuran wrote: post #198

Earlier quoted context omitted.

Couldn't head just detach without any consistency issue?

Theoretically it could, but that would be a rather surprising side effect. You could also check the new revision out and leave HEAD intact. Which one of those outcomes you would expect and why? "error: ref in use by higher layers" makes much more sense to me in this case.

It doesn't seem surprising to me. It probably ought to print ought a warning that head has detached though, like some other commands already do. That error message on the other hand seems very unhelpful. It's lingo that only makes sense if you're neck deep in the plumbing.

Re: Oh Shit, Git?

#242

Post by steveklabnik »

stouset wrote: post #208
hooper wrote: post #180

Earlier quoted context omitted.

One thing I really appreciate is that you can run `jj new master` at _any_ time to drop what you're doing and start a new change. The way jj handles the working copy, conflicts, and visible heads means there's just no need to think about uncommitted changes, unfinished conflict resolution, detached head, etc.. So many things that would get in your way just can't happen.

I haven’t thought about it at all but you’re right. It’s surprising how nice it is that I can enter a repo and `jj new main` without needing to remember any context whatsoever. My post was a pretty naked attempt to showcase how much less convoluted basic operations are in jj vs. git and hopefully drum up some interest. Hopefully someone bites.

`jj new trunk()` is even better than `jj new main`, I just realized, ha!

Re: Oh Shit, Git?

#243

Post by steveklabnik »

zahlman wrote: post #186
maleldil wrote: post #133

Earlier quoted context omitted.

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?

It redos, there's discussion about if and how this should change: https://github.com/jj-vcs/jj/issues/3700

Re: Oh Shit, Git?

#244

Post by stouset »

steveklabnik wrote: post #242
stouset wrote: post #208

Earlier quoted context omitted.

I haven’t thought about it at all but you’re right. It’s surprising how nice it is that I can enter a repo and `jj new main` without needing to remember any context whatsoever. My post was a pretty naked attempt to showcase how much less convoluted basic operations are in jj vs. git and hopefully drum up some interest. Hopefully someone bites.

`jj new trunk()` is even better than `jj new main`, I just realized, ha!

It is! I've fully migrated my repos over to `main` at this point so it's rare I have to think about the difference. You could also make an alias to `jj n` or something to make it even easier.

Re: Oh Shit, Git?

#245

Post by baobun »

recursive wrote: post #157
baobun wrote: post #150

Earlier quoted context omitted.

Is not very compatible with printlog-debugging. I'd rather encourage devs to prod around as they go if it benefits them, which causes grief for either them or reviewers in the end if they've internalized what you just said. Explicitly adding internalizes a personal review process as inherent part of the push process, instead of something you attempt to force on top later. It's better with a collaboration workflow tha…

You can have both. Make sure the whole diff is what you want it to be before invoking `add .`

Sure. I hear the pull-out method is also an effective contraceptive.

Re: Oh Shit, Git?

#246

Post by spokaneplumb »

fragmede wrote: post #120
spokaneplumb wrote: post #91

Earlier quoted context omitted.

I've been using Git for almost 15 years, and have twice built programs/products that use Git internally to achieve certain results (that is, the program/product itself uses Git for things, not just using Git to manage the source code for the program/product) and... sometimes before doing something a little gnarly in Git I'll still just do "cp -R .git ../git-backup" or something like that, so I can replace my entire .…

Reflog is your friend. git break-my-shit git reflog ... output saying where you were before things broke ... grab the good commit sha git reset --hard good_commit_sha_from_reflog

The copy-the-.git-dir trick works for worse issues than can be solved with a single reset --hard. Damn near anything, really, as long as you haven't touched any remotes. It also works if you don't remember/understand how you broke it, where it's broken, or which state you need to try to reset to.

Re: Oh Shit, Git?

#247

Post by nejsjsjsbsb »

Vampiero wrote: post #146
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 seems painfully obvious to me that local and remote commits serve different purposes. Local commits are a way to create checkpoints when everything compiles and works and you can move on to the next step. That way you can stash your changes and go back to a working state when you screw things up. Then, before you push those changes, you reset them and split them into proper commits. That way the history is all nic…

I have no pride. I push my dumb commits that chronical my weird journey full of sub-junior mistakes to get to the final state.

Re: Oh Shit, Git?

#248

Post by seba_dos1 »

Certhas wrote: post #212
seba_dos1 wrote: post #202

Earlier quoted context omitted.

Theoretically it could, but that would be a rather surprising side effect. You could also check the new revision out and leave HEAD intact. Which one of those outcomes you would expect and why? "error: ref in use by higher layers" makes much more sense to me in this case.

If you buy the "git is just a tree of commits and pointers" mental model it's absolutely not a surprising side effect but would be the logical thing to expect. I moved a pointer to a commit around, why would that change where HEAD is pointed. Turns out it's a tree of commits and pointers to within that tree and a master pointer that come in two versions: pointing towards the pointers or pointing towards the tree. And…

> I moved a pointer to a commit around, why would that change where HEAD is pointed.

...because HEAD points to what's checked out. This pointer does not just exist and hang around, it has its semantics. Not understanding that reveals flaws in your mental model.

Besides, the side affect you find "not surprising" here is... rewriting HEAD to change what it points to. Then you ask "why would that change where HEAD is pointed". Sounds like you may be confused. Are you forgetting that a ref may point not just to a commit, but also to another ref? This is the whole idea behind branches after all, having HEAD point to a ref is exactly what makes branches semantically different from tags - if you don't understand it then no wonder you're confused.

(protip: if you find git's "pointers to pointers" confusing, perhaps because in C a "pointer" and "pointer to pointer" are separate types that make multiple dereferencing steps explicit, think of them as symlinks instead and it should become clearer - that's in fact how symrefs used to be implemented in the past)

When a pointer is in use by higher layers, a good UI will prevent you from making direct changes underneath it unless you force it or go low-level enough for it to not matter. The only sin of git I can see here is that `git` command provides you both high-level and low-level interfaces to manipulate the data structure you're working on with no clear distinction for the user.

Re: Oh Shit, Git?

#249

Post by seba_dos1 »

thfuran wrote: post #241
seba_dos1 wrote: post #202

Earlier quoted context omitted.

Theoretically it could, but that would be a rather surprising side effect. You could also check the new revision out and leave HEAD intact. Which one of those outcomes you would expect and why? "error: ref in use by higher layers" makes much more sense to me in this case.

It doesn't seem surprising to me. It probably ought to print ought a warning that head has detached though, like some other commands already do. That error message on the other hand seems very unhelpful. It's lingo that only makes sense if you're neck deep in the plumbing.

There's no such message there, it was a description of a situation written by me and it doesn't even actually match the git's lingo. Should have made it clearer I guess.

It is surprising. You wanted to edit the value of `main` ref, yet suddenly you now edited `HEAD` too without meaning it. Bailing out and letting you actually decide whether you want to do it or not is the correct thing to do for a high-level command like `git branch` (alternatively it could ask you what to do interactively). If you don't want such safeguards and you know what you're doing, use `git update-ref` which will happily let you break whatever you want.

Re: Oh Shit, Git?

#250

Post by seba_dos1 »

Certhas wrote: post #211
seba_dos1 wrote: post #196

Earlier quoted context omitted.

> but not if it's checked out ...and for a good reason that should be apparent to anyone who understands git's model (HEAD points to a ref in this case, so if you suddenly change what that ref points to without updating the working tree you create an inconsistency). You can do that manually of course (with `git update-ref` or even a text editor), but then you get to clean up the mess yourself.

To me that looks like git is leaking implementation details left and right. So much for "a branch is simply a pointer to a commit"...

Do you react the same way when an OS prevents you from writing to a file with an exclusive lock placed on it? So much for "a file is simply a collection of data stored as a single object"...

If a git repo was purely a collection of meaningless pointers and graph nodes, git would be a graph manipulation utility, not a version control system. The fact that some of those pointers have a meaning is what makes it useful and it doesn't contradict the fact that what you're working on is still just a bunch of pointers and nodes.

Post reply on HN