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

261–270 of 490 posts

Re: Git undo: We can do better

#261

Post by Vinnl »

cerved wrote: post #242
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…

Git checkout branch means change the entire working tree to the reflect the state of the branch and git checkout file, checkout the state of that file in HEAD. Both commands to the same thing, change the state of your working tree to reflect a point checked into version control. It sounds like you are unaware of git switch branch and git switch -c new-branch

Just a tip: when teaching people, the readable alias is easier to remember and understand, i.e.

    git switch --create new-branch

Re: Git undo: We can do better

#262

Post by swisspol »

dilap wrote: post #94
gldnspud wrote: post #77

While GitUp is a GUI app, and only available for macOS, I think it's worth noting that it has some great undo/redo capabilities built in. From what I understand, some of them were more feasible to develop because they implemented their own plumbing (GitUpKit), instead of relying on the official git plumbing. https://gitup.co/

GitUp is such a great app & fantastic UI design, but the author gave up on it at maybe 80% of functionality, and I think for that reason (among perhaps others), it never really caught on. (It's open source and there are still occasional commits, but it doesn't seem to be really actively worked.) Nevertheless my main daily driver, along w/ the command line. It's undo capabilities, best-in-class visualization of the ti…

Hey I didn't gave up on it at 80% functionality ;) It had 100% for my needs and it's been rock stable since then - I still use it daily!

But yes, I wasn't really worth actively maintaining it as it was feature complete and I didn't intend to build a business out of it.

Re: Git undo: We can do better

#263

Post by MereInterest »

lanstin wrote: post #228
MereInterest wrote: post #211

Earlier quoted context omitted.

> that identical changes in two branches are not actually a conflict I think this is part of a downside of rebase-centric workflows, since it encourages making multiple branches with identical changes, but no shared history. At some point I want to read more pros/cons on different workflows. My current thinking is that rebase-only sacrifices far too much on the altar of a clean-but-inaccurate commit history, but I do…

I think if you run into this a lot, git revere will be helpful: https://www.git-scm.com/book/en/v2/Git-Tools-Rerere If you have a lot of long-lived branches that don't merge and get deleted you have a whole different world of pain from normal git usage, and need some resources designed as SCM experts to manage this stuff. But really short lived branches that deliver net steps forward are the way to live. I hate branc…

Ooh, rerere looks really nice. I have a few cases where I've needed to repeatedly rebase long-lived branches. (Feature branch A depends on feature branch B, but some small aspects of feature branch B are still under discussion. Feature branch B needs to be occasionally rebased onto main to avoid conflicts, after which branch A needs to be rebased onto B again.). Something that I try to avoid, but that sometimes happens anyways.

Can you explain what you mean by git merge breaking bisect? I've never run into that problem at all. And sure, it might bounce between the branches as you bisect, it still identifies the commit that introduced a bug. The only issue is if one of the commits on the branch fails to compile/test, which is poor commit hygiene, but can be excluded from the bisect.

I still need to do more research, but I think I'd lean toward having a merge workflow, but with no fast-forward commits. That leaves a clean history on main with --first-parent, but still leaves the details available in the branches as needed.

Re: Git undo: We can do better

#264

Post by snackematician »

vzaliva wrote: post #257

May I have it in Magit, please?

Magit's wip-mode seems similar in some respects: https://magit.vc/manual/magit/Wip-Modes.html

I haven't tried it, but have been meaning to look into it. Would be curious to hear experiences of anyone who's tried it, and how it compares to the OP.

Re: Git undo: We can do better

#265

Post by stickfigure »

sam_lowry_ wrote: post #255
stickfigure wrote: post #223

Earlier quoted context omitted.

I've actually worked on git internals and I'm in the same boat. As part of a security-related project some years ago, my team and I hacked jgit to use SHA256, which required changing the length of pretty much every on-disk data structure. Sadly, there was (probably still is) no HASH_LEN constant, just a lot of magic offsets strewn throughout the code. I had to compare lengths against the git spec at every step. And y…

What a pointless project! U hope you were paid well, at least.

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.

Re: Git undo: We can do better

#267

Post by MereInterest »

Zarel wrote: post #248
MereInterest wrote: post #203

Earlier quoted context omitted.

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.

`--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.

Re: Git undo: We can do better

#268

Post by sngz »

eric4smith wrote: post #12

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…

this is why i was so sad when mercurial support ended. I loved using mercurial it just works and it was so intuitive. My firm last year switched all projects over to github and it's been a pain, I learned it no problem but still have to google the occasional thing, but I spend most of my time fixing other people messing up the repo.

Re: Git undo: We can do better

#269

Post by leafmeal »

yarg wrote: post #220
alkonaut wrote: post #181

I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the elegance and consistency of an early php draft that went through a document shredder. Git has a nice elegant layer underneath though. The DAG of commits is a very nice model, covered in a layer of terrible commands, and a few rather unnatural abstractions like t…

There's a limitation to the DAG model that has bothered me for a long time. I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch. I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances. (And I know this would create some new fun and ga…

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.

Re: Git undo: We can do better

#270

Post by smichel17 »

klyrs wrote: post #141
lugged wrote: post #116

Earlier quoted context omitted.

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.

[misunderstanding removed]

In a thread about common sources of confusion, I think it would be more helpful to leave the misunderstanding so others might learn from it. Ie, edit to add "this is a misunderstanding" to the top, not replace it entirely.
Post reply on HN