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

High-Level Problems with Git and How to Fix Them

gregoryszorc.com

Post reply on HN
Print view View original

281–290 of 294 posts

Re: High-Level Problems with Git and How to Fix Them

#281

Post by fulafel »

acdha wrote: post #248
fulafel wrote: post #212

Earlier quoted context omitted.

Resorting to rebase is a pretty heavy price to pay though.

How so? It's very fast and you can abort if you do it wrong.

Well, the obvious and immediately painful one is the hard-to-recover failure mode when you discover something you rebased wasn't private after all. (Which can happen in many situations, eg github merge button, even without other people involved).

The other is that it destroys history, you change the record of what actually happened to the version that is a plausible simplification in the opinion of git's diff/merge heuristic. You then can't then go back for to look for explanations of bugs or test code changes, which change happened first or whether a fact claimed by a commit message was really true at the time, or where is some change a merge mess-up or considered change.

Rebase also really complicates the mental model of git you have to work with.

I appreciate though, that there are cases where you want to withhold the record of what actually happened and use squash/rebase, it's a type of privacy from others. But simply grouping together commits into one is not a good reason to do it, that's what merge commits are for after all.

Re: High-Level Problems with Git and How to Fix Them

#282

Post by fulafel »

cryptonector wrote: post #264
taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

There's three ways to deal with the git index/staging area: - always commit everything, merge/push that (Mercurial style) - always commit everything, then eventually do a rebase where you merge/split commits into logical units - always git add -e then commit logical units I do mostly the latter, but since I don't usually write code the way I want it in the end before pushing, I almost always have to go back and rebas…

A goal of producing a "nice, clean, logical, and minimal" history, as opposed to preserving history, is very opinionated, as I'm sure you're aware. I think it's not something most people should attempt voluntarily - If you want "nice, clean" waypoints, just diff between the relevant merge commits, and read their commit messages.

Re: High-Level Problems with Git and How to Fix Them

#284

Post by tonfa »

maxxxxx wrote: post #186
spiznnx wrote: post #65

Earlier quoted context omitted.

The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite. While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area a…

Sure. I can get the same result I can get with simple staging with a complicated squash workflow. But why would I do that? I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.

> I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.

I think that's what mercurial tries to solve, it makes manipulating history safe (by tracking the state of the commits, whether they were published or not for example, and always keeping all the history but hiding it after it was rewritten).

Re: High-Level Problems with Git and How to Fix Them

#285

Post by tonfa »

rbehrends wrote: post #180
nhaehnle wrote: post #175

Earlier quoted context omitted.

> I'm honestly not sure why you think you'd even need a GC for `hg commit --amend` or `hg rebase` (or similar operations in other VCSes). Maybe you don't call it GC, but doing a rebase in Git leaves the old, pre-rebase version around. That is a feature: over the years, it has happened to me more than once that I'd missed something when resolving complex conflicts during the rebase. Being able to refer back to the sta…

> If Mercurial throws the old version away unconditionally, that would suck very much indeed. Which is why it isn't done. In core Mercurial, the old revisions are stored in a backup bundle in a separate backup directory. Note that bundles can transparently be used as read-only repositories, so you can view their logs as though they were still part of the parent repo, diff against them, pull from them, etc. With the e…

> I think your dilemma is largely an imaginary one, fretting over a resource (disk space) that is too plentiful to require micromanagement.

I think the need for GC in git is likely also tied to its original resource intensive implementation. Pack files were added to fix that, but then you need to GC the blobs to prevent storage blowup.

Mercurial and most other VCS have delta storage as their base format which avoids this issue.

Re: High-Level Problems with Git and How to Fix Them

#286

Post by zanchey »

rntz wrote: post #260
zanchey wrote: post #189

This article can be summarised as: 1. Cache invalidation 2. Naming of things They seem like straightforward problems.

Could you elaborate for those of you who don't quite understand? I understand the reference, but is there more to this comment than a joke?

Sadly not.

Re: High-Level Problems with Git and How to Fix Them

#287

Post by acdha »

fulafel wrote: post #281
acdha wrote: post #248

Earlier quoted context omitted.

How so? It's very fast and you can abort if you do it wrong.

Well, the obvious and immediately painful one is the hard-to-recover failure mode when you discover something you rebased wasn't private after all. (Which can happen in many situations, eg github merge button, even without other people involved). The other is that it destroys history, you change the record of what actually happened to the version that is a plausible simplification in the opinion of git's diff/merge h…

> Well, the obvious and immediately painful one is the hard-to-recover failure mode when you discover something you rebased wasn't private after all.

How is this hard to recover? You have full control of both copies, the system protects you against data loss, and you can easily pick one of the two, rebase one against the other, etc. to recover.

> Which can happen in many situations, eg github merge button, even without other people involved

This is the real problem and it's DVCS agnostic. If you make a bunch of changes to the same code without staying current, a human is going to have to reconcile it. If you follow recommended practice and update your local changes against the shared upstream regularly, this is a far more manageable problem — and that's true for every version control system in existence.

> The other is that it destroys history, you change the record of what actually happened to the version that is a plausible simplification in the opinion of git's diff/merge heuristic.

More correctly, you change it to the version as presented by the human who made the decision to rebase. If someone chooses to remove important context you can have problems but that's the same category of social problem you'd have with someone who uses poor commit messages, makes commits which are incomplete, etc.

> Rebase also really complicates the mental model of git you have to work with.

I find the opposite to be true. Most of the people I've taught seem to quickly grasp the idea that a rebase is simply taking your set of changes and moving them to apply against the current shared consensus rather than that state when you started, whereas merges cause regular confusion during code review or conflicts when people are asked to reason about changes someone else made.

Re: High-Level Problems with Git and How to Fix Them

#288

Post by davvolun »

jhanschoo wrote: post #135
qznc wrote: post #116

Earlier quoted context omitted.

> In a decade of using Mercurial > I never really used git all that much Does not sound like a fair comparison ;)

It's a valid comparison for his point that Mercurial is much more reliable for his workflows than git.

A decade's worth of experience vs beginner-level experience could explain the issue. Not saying it does, just that it could.

Re: High-Level Problems with Git and How to Fix Them

#289

Post by mschaef »

theptip wrote: post #258
mschaef wrote: post #240

Earlier quoted context omitted.

> I'm not shy about recursively copying the entire repository on disk Agreed. > Also, once you understand how to pull things out of the reflog, That, and I'll also dump a git log of the last couple dozen commits into an editor buffer so that I can hang onto the commit ids. Until a GC cycle occurs, you don't lose the commits even if they aren't reachable through normal paths.

`git reflog` gives you the historical list of SHAs that you've pointed HEAD at; even if you destroy your branch with a rebase, you can still see what commit your branch pointed to before you started the operation.

Yeah... I just find the printed log output a bit easier to read (at least for the few times I need to do this sort of thing). '@' syntax falls into that same basic category - powerful, the better solution, but nothing I use enough to bother mastering.

Re: High-Level Problems with Git and How to Fix Them

#290

Post by tomxor »

rbehrends wrote: post #173
tomxor wrote: post #158

Earlier quoted context omitted.

I'd like to think I know git pretty well... I understand the internals, i've written cli tools that utilise all the plumbing commands, I understand the different types of objects merkel trees, and various form of references. Yet, once when I had a power failure by chance the second I fired the commit trigger... I was pretty hopeless at trying to clear up the mess of objects it exploded everywhere, I couldn't be bothe…

I very much doubt that this is a Git issue, but suspect that it is instead a file system/OS/hardware issue. The problem is that operating systems generally offer only very limited guarantees about the atomicity of the bits actually being physically stored on a device (at least guarantees that can be used with reasonable efficiency). It should not normally be a problem, but a power failure just at the wrong time seems…

It is a git issue... File system atomicity is not the issue: Creating a commit is a process of creating a whole collection of blobs and trees and ultimately a commit tree object, this is fundamentally the way git works. There are many external reasons it could fail half way through creating that tree of objects (objects are files) and that has nothing to do with atomicity of those external factors.

This type of incident is not irrecoverable, but it will hella-waste-your-fucking-time (FYI I really like git, but it's far from infallible)... Try it out and you will have a fun time following the trail of dangling objects.

My point is not that git is fundamentally flawed (fundamentally it's extremely resilient and elegant), but merely that "commit" being a porcelain command should provide a simple way to recover from arbitrary failure without having to dive deeply into the internals and plumbing commands (it's another CLI UI failure)... I knew what was wrong but it was such a pain to reconcile that I resorted to re-cloning, imagine what a confusing mess it would appear to a regular user.

Post reply on HN