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

281–290 of 490 posts

Re: Git undo: We can do better

#281

Post by yarg »

leafmeal wrote: post #269
yarg wrote: post #220

Earlier quoted context omitted.

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.

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?

Re: Git undo: We can do better

#282

Post by AlexSW »

dorian-marchal wrote: post #279
cerved wrote: post #224

Earlier quoted context omitted.

Commits are immutable, itś incredibly hard to destroy data that has been committed. Even if they become loose objects, Git is very conservative when it comes to deleted that. If you have uncommitted data, git will refuse to do lots of operations. The default is always to not delete changes, even if resetting a branch. Contrast that with TFVC which tries its best to nuke everything within it's reach (that is not under…

Unfortunately, it is still very easy to lose data, e.g. by trying to undo a temporary commit with `git reset --hard HEAD^` (note the --hard option) before committing your changes.

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.

Re: Git undo: We can do better

#283

Post by dilap »

swisspol wrote: post #262
dilap wrote: post #94

Earlier quoted context omitted.

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.

Yes, I also use it daily, so thanks for making an amazing tool!

100% vs 80% is of course going to be subjective, but the missing 20% in my opinion is built-in merging and a built-in repo browser. When I've tried to advocate GitUp to my coworkers, those are the two things that keep them going back to SourceTree or Fork.

(Also, on our (admittedly, pretty large) repos, it's not quite rock-solid; staging can be unusably slow (requiring fallback to the command line), switching to the commit view from the map view can be slow, and making lots of changes to the working tree will crash GitUp.)

Still, a brilliant piece of software, and I am suprised that (1) it didn't find a larger audience and (2) that it wasn't more influential on clients that came after, like Sublime Merge.

Re: Git undo: We can do better

#284

Post by lawn »

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…

This is the one thing I took with me from The Design of Everyday Things: usability design matters, and it matters a lot.

Re: Git undo: We can do better

#286

Post by MetaWhirledPeas »

jonathanberger wrote: post #219

Git is one of those bizarre products that has remained a leader in its category for almost a decade while being extremely difficult to use, even for experts. Another one of these products is Apache. Why is this? At least from my naive point of view I would expect these extremely user-hostile products to have been overtaken but more user-friendly alternatives. I know the best products don't always win, but when they d…

It has remained popular because it feels like the correct approach in almost every situation, despite having a difficult, obtuse UI. After spending years with Microsoft's centralized version control and then switching to Git it's like a breath of fresh air.

Granted, I almost never use the Git command line and always favor a 3rd party GUI. For users who are a tad confused I think this is the right approach. And to me that's what makes Git a winner: the core software is powerful enough to do everything that needs to be done, and you can pick whatever UI you're comfortable with. No one is forcing you to use Git's built-in UI.

That said I think even the high-level Git concepts have naming that confuses new users. "Pull request" annoyed me for a long time. Yes I technically understood why they chose that term, but practically speaking it just seemed pointlessly misleading.

Re: Git undo: We can do better

#288

Post by anoncake »

handrous wrote: post #32
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…

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…

Maybe for low-level, somewhat rare tasks the ideal Git porcelain would be a GUI that just exposes the data model directly.

Re: Git undo: We can do better

#289

Post by mikepurvis »

stormbrew wrote: post #105
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…

definitely agree, and I'm in the same boat. I don't even think the data model of git is that hard to grok at all, it's mostly that commands are very unclear on what they operate on and in particular people get really tripped up about how many levels of state there are (stage, working tree, local branches, remote refs) that they have to interact with. Like, I've had to explain a lot of times why you `git pull origin m…

What's wrong with `git push -f`? When I'm working on a branch that's been previously pushed with `-u`, it's pretty normal to force push it, particularly if you're amending or reordering commits in response to review feedback, or rebasing due to conflicts in preparation to merge.

Re: Git undo: We can do better

#290

Post by Leherenn »

OhNoMyqueen wrote: post #70

The most painful mistakes beginers endure with git are irrevocable code removal from the current working directory because of bad usage of `git clean`, `git reset` (or `git merge` if you're brutish enough). This problem cannot be solved by using git, because git doesn't have any reference to such code.

A bit less painful, in the sense that you probably won't lose work, but still quite a headscratcher is line endings issues. Not amount of `git checkout .` or `git reset --hard` will help, and you just have massive diffs with no obvious change. I recloned the repo quite a few times in my younger days over this, and I still have to think deeply to be sure to use the correct configuration.
Post reply on HN