Idiot Proof Git • Hacker News Board

Re: Idiot Proof Git

#271

Post by Arelius » Wed, Nov 09, 2022, 8:31 PM UTC

weaksauce wrote: post #253

Arelius wrote: post #241

Earlier quoted context omitted.

Sure can, for instance a hg-like commit stages system for rebase would prevent a lot of rebase caused issues.

> hg-like commit stages system not familiar with what you're referring to... can you elaborate?

I got the name wrong, it’s phases https://www.mercurial-scm.org/wiki/Phases

In short, every commit can be in one of three phases, secret, draft, and public. Commits transition to public when you push them somewhere someone else might depend on them, and rebase won’t allow you to rebase any public commits.

Commits can of course be manually transitioned back as a “I know what I’m doing step” but this provides a lot of safety for casual rebases.

(Secret just prevents the commit from being accidentally pushed)

Re: Idiot Proof Git

#272

Post by deathanatos » Wed, Nov 09, 2022, 8:39 PM UTC

mmmmmbop wrote: post #125

huimang wrote: post #54

The problem with git is hardly anyone reads the fucking manual. Git is not hard. The UI is inconsistent, but documented. When you just foist commands onto people, you can't be surprised when they fall off the happy path and don't have the mental model to understand how to fix it. There's no such thing as "idiot-proofing" for people who don't RTFM. --force-with-lease as a default is a really bad idea. Copying random a…

If one user uses a tool wrong, the user may be at fault. If many users are using a tool wrong, the tool probably doesn't have great UX. Saying "the tool is great, users just need to RTFM" sounds an awful lot like "you're holding it wrong".

UX can affect incidental complexity, but essential complexity cannot be removed from the problem; this is the same as what some of the sibling comments are getting at.

When I interrogate users who aren't grokking git, it's not really git's UX that's the problem, it's far more fundamental: like not understanding (and thus not being able to conceptualize and visualize) that the commit graph is a DAG. Not understanding what "rebase" is, because they have no concept of what the word "base" means: rebase follows trivially from that understanding, if they had it.

CLI git has these presentations; it can present the commit graph, though oftentimes companies do such a crap jobs of approaching git history that git is left to render spaghetti. UI tools exist, but face the same spaghetti in, spaghetti out. It's like asking your IDE to make bad code less bad. Worse is people actively promulgate broken "methodologies" that result in these spaghetti graphs, such as the ironically named "A Successful Git Branching Model".

Re: Idiot Proof Git

#273

Post by GuB-42 » Wed, Nov 09, 2022, 8:40 PM UTC

kazinator wrote: post #235

GuB-42 wrote: post #215

Earlier quoted context omitted.

There are essentially two approaches: - History is sacred and can't be changed. It typically goes with a merge-based workflow. The good thing is that nothing is lost, what you see is what really happened and you won't make a mess with inappropriate push --force. The downside is that it looks messy since you are going to see every typo and you will have some non functional code in your history. People using that workf…

Projects should rewrite their public history from time to time, for instance to get rid of commits that never should have happened, or move changes between commits, fix commit messages and such. The history should be treated as the perfect object to develop. We should continuously revise how this program should have been developed to its current state, by what sequence of changes.

While I think a rebase workflow where you rewrite the history of feature branches is a reasonable approach, rewriting public history is a big no for me. Maybe it is fine with some version control systems, but certainly not git.

Git is essentially a blockchain, rewriting history is like rolling back a bitcoin transaction, it is impossible without breaking cryptography. Instead, when you rewrite history in git, you actually create a new project to replace the old one. You then have to tell everyone to switch to your "new project", otherwise you will create a lot of confusion and painful merges, if they don't decide to say "fuck you" and keep working with the original history.

Git is decentralized, and to work it needs some consensus, and the consensus is in the history, if you break that, you break the decentralized nature of git. Now, if your don't open your repository to the general public and use git like you would use svn or other centralized systems, it is fine, but don't do that for public repositories.

Re: Idiot Proof Git

#274

Post by s4i » Wed, Nov 09, 2022, 8:43 PM UTC

lelandfe wrote: post #144

stnmtn wrote: post #138

Earlier quoted context omitted.

Agreed. The first and last place I look at when doing a git blame is the PR that the commit was in. That contains all the useful information for me, as well as much-needed context around review comments, discussion, etc that is not able to find in native git.

Pull requests vanish when repos change hands. If you leave unique information in PRs, that information may be lost in the future. This has happened to me at 3 different companies now, where we inherited another company's code base. Keeping commits self-contained is the only way to future proof your explanations.

It would be great if GitHub (not sure about GitLab, Gitea, etc) included the title and the description of the PR (maybe up to a certain character limit) in the merge commit when you merge the PR. This would be at least a minimal level of backup for the PRs but it would also prevent common scenario for me where I need to switch to the browser from `git log` just to remind what the heck this one PR was about again.

Re: Idiot Proof Git

#275

Post by kazinator » Wed, Nov 09, 2022, 8:43 PM UTC

GuB-42 wrote: post #273

kazinator wrote: post #235

Earlier quoted context omitted.

Projects should rewrite their public history from time to time, for instance to get rid of commits that never should have happened, or move changes between commits, fix commit messages and such. The history should be treated as the perfect object to develop. We should continuously revise how this program should have been developed to its current state, by what sequence of changes.

While I think a rebase workflow where you rewrite the history of feature branches is a reasonable approach, rewriting public history is a big no for me. Maybe it is fine with some version control systems, but certainly not git. Git is essentially a blockchain, rewriting history is like rolling back a bitcoin transaction, it is impossible without breaking cryptography. Instead, when you rewrite history in git, you act…

Rewriting public history is completely fine with git.

Upstream says: "master is now this SHA, deal with it".

Actively developing downstreams can easily rebase their stuff (if any) across non-fastforward changes, and life goes on.

For a pure consumer of a repo, it makes no difference.

There is only the cultural idea that it's a no-no, not a technical idea.

Re: Idiot Proof Git

#276

Post by stevage » Wed, Nov 09, 2022, 8:58 PM UTC

For me this is another painful reminder of what git could have been. Imagine if it had been this ergonomic from the start. Everyone would have the same set of commands. Whereas if you adopt these aliases you can't easily discuss any git related issue with someone who doesn't use them.

Re: Idiot Proof Git

#277

Post by MetaWhirledPeas » Wed, Nov 09, 2022, 8:58 PM UTC

OkayPhysicist wrote: post #213

MetaWhirledPeas wrote: post #140

Earlier quoted context omitted.

Now you've piqued my interest.

Not the person you replied to, but what a rebase is is taking a series of commits you made to one place, and replaying them on top of another commit. So you make your PR, then branch off of that commit, and continue doing the normal edit-commit workflow on that new branch. Then, when you the PR gets merged, you git rebase -i (master/main/whatever branch your PR was being pulled into). You'll be presented with all you…

This is an excellent explanation, thank you.

Still, I have questions. When I have topic checked out then run "git rebase -i main" does it first do fetch (or whatever) to make sure main's latest commit history is represented? Or is it up to me to do that first?

The rebase concept is sound, but the semantics are a bit daunting.

  git rebase -i main

This sounds like an operation is being performed on main. Terrifying! And "rebase" is a scary word choice regardless. Perhaps you remember when you were new to Git and can relate.

I may give rebase a try at some point, to see if perhaps it might speed me up. The vast library of Git commands is a bit much for me though. It's like using an aircraft cockpit to control the television!

Re: Idiot Proof Git

#278

Post by GuB-42 » Wed, Nov 09, 2022, 9:04 PM UTC

__blockcipher__ wrote: post #232

GuB-42 wrote: post #215

Earlier quoted context omitted.

There are essentially two approaches: - History is sacred and can't be changed. It typically goes with a merge-based workflow. The good thing is that nothing is lost, what you see is what really happened and you won't make a mess with inappropriate push --force. The downside is that it looks messy since you are going to see every typo and you will have some non functional code in your history. People using that workf…

It's ironic that the "history is sacred" crowd contains the people least likely to actually look at and use the git history to aid their contextual understanding of the codebase . Why do I say that? Well, because once you've come across a useless typo commit for the 12th time, you start to very quickly see how such commits needlessly bloat the history and make it far harder to understand (and make things like git bla…

That's why when you use a "history is sacred" approach, you typically have several branches and use merge commits, not rebase.

When you look at the master branches you will mostly see merge commits, all the mess will be on the side, for example in feature branches. Merge commits can be clean, and when you are blaming, you will see the merge commit, not the dozen of typo commits. If you do "git log --first-parent" you will not even see the messy commits, but they will be there if you need them.

Re: Idiot Proof Git

#279

Post by dbt00 » Wed, Nov 09, 2022, 9:14 PM UTC

Shacklz wrote: post #142

idop wrote: post #10

Earlier quoted context omitted.

Obviously what works for you works for you, but I respectfully disagree with everything you said. The "history should be exactly what you did" argument - which many people make - is really funny to me because a pull/merge-only strategy only preserves the _wrong_ history. As a tech lead, for example, I absolutely do not care one bit about the date of a commit, or when the developer started working on it, or what was t…

> And a linear history makes this much easier to analyze and understand, reducing cognitive load considerably. This, so much this! And the price you pay for it is a slightly more difficult "insert". We started to enforce linear history in one of our bigger repositories (about 100 devs) about two years back; the first months were quite the ride (I had to do plenty of support-sessions to recover 'lost' changes). But th…

You can, 99.9% of the time, emulate linear history with first parent history, which is a post-hoc tooling choice that doesn't remove context.

Developers shouldn't try to merge branches with wip/wip/wip/wip histories either, that's just garbage. Commit messages are documentation, fix your documentation before you publish.

Re: Idiot Proof Git

#280

Post by bornfreddy » Wed, Nov 09, 2022, 9:30 PM UTC

hinkley wrote: post #43

idop wrote: post #10

Earlier quoted context omitted.

Obviously what works for you works for you, but I respectfully disagree with everything you said. The "history should be exactly what you did" argument - which many people make - is really funny to me because a pull/merge-only strategy only preserves the _wrong_ history. As a tech lead, for example, I absolutely do not care one bit about the date of a commit, or when the developer started working on it, or what was t…

Usually my strategy, but it breaks down if you have someone who is bad enough at merge conflict resolution. We had one guy Steve who was upset that he was not as in charge as he wants to be, but he was doing a few things that break my trust so we are keeping him on a shorter leash than he likes. His code and ideas are okay but not great. He’s picking on this guy Mark, who sat next to me, to make himself look more val…

I don't know either Steve, Mark or you, of course - but this sounds like a broken dynamic where boss's preference of one person (sitting next to Mark, probably mentoring him) pushes another, Steve, to show his fighting side.

Yes, Steve should have kept things honest. But being the boss, you need to be careful not to pick favorites and to treat everybody in a similar fashion. People are very touchy about how they are treated within the "tribe".

Also, if you identified the issues both of them are bad at, are you all solving them? Being "terrible at merges"... how does that even work? Isn't that kind of an important skill? As their boss, their know-how is your responsability too, are you solving it?

Sorry if I have misjudged the situation, I obviously don't know it first-hand, so you will need to see for yourself if the above is true. There were just too many red flags (for me) in your comment to let it pass... And the reason I see them is that I have misjudged colleagues in the past, and wish I had known better then. Ah well.