Idiot Proof Git • Hacker News Board

Re: Idiot Proof Git

#351

Post by Dylan16807 » Thu, Nov 10, 2022, 3:58 AM UTC

seba_dos1 wrote: post #303

cnity wrote: post #161

Earlier quoted context omitted.

I mentally categorise `commit --amend` right there next to rebase personally. When people debate about rebasing and rewrite of history, I include `--amend`. Maybe I'm unique there though.

--amend is conceptually nothing else than interactive rebase to squash the last two commits together.

Conceptually that's not really a rebase, because you're using the same base.

If you never push the original commit, --amend is the same as staging things repeatedly for safety but only hitting the "commit" button later in the day.

Re: Idiot Proof Git

#352

Post by mixmastamyk » Thu, Nov 10, 2022, 4:12 AM UTC

Dylan16807 wrote: post #349

mixmastamyk wrote: post #254

Earlier quoted context omitted.

Work you didn't do won't be in your branch. There is no rearranging, it is one commit.

> Work you didn't do won't be in your branch. The merge commit will be in the branch. > There is no rearranging, it is one commit. You misread that. They want to be able to rearrange things easily. Having multiple merge commits in the middle gets in the way of that.

The work doesn't show up on a diff, what I was getting at. Merges are from master in this example and already reconciled.

Commits don't matter either, because they are being squashed. Was responding to the grandparent perhaps more than the parent.

Re: Idiot Proof Git

#353

Post by Dylan16807 » Thu, Nov 10, 2022, 4:12 AM UTC

copperx wrote: post #310

jfk13 wrote: post #83

Earlier quoted context omitted.

> almost never ... actually lost code That seems like one of the absolute basics. "Almost" never...? > I just make a backup copy of the directory in case I screw up irrevocably If you really felt you could trust your source control system, that shouldn't be needed, and... > the cases where I've need to use my backup copy ...should be nonexistent.

I agree. If losing code with Git is even a remote possibility, then you're "holding it wrong" indeed.

There are multiple ways to accidentally overwrite or delete a file that wasn't committed yet.

There are also situations where you need to use these commands and you're not ready to commit everything.

The safe way to handle this is generally making a stash commit and immediately applying it, but if you don't know that, or don't think to do that first, the result can be data loss.

Git is very careful about commits but if you never staged something then git can be ruthless.

Re: Idiot Proof Git

#354

Post by rramadass » Thu, Nov 10, 2022, 4:17 AM UTC

throwaw20221107 wrote: post #292

Modern Git workflow is very simple on its own: 1. Your codebase has a `main` branch which is write-protected 2. Devs submit changes to `main` from their own branches using PRs 3. Devs can do whatever the fuck they want on their own branch 4. PRs are merged one at a time 5. When merge happens a dev's PR is squashed into one commit that gets appended to `main` 6. If next dev wants to merge their PR with a conflicting c…

Neat and Simple!

Re: Idiot Proof Git

#355

Post by throwawaylinux » Thu, Nov 10, 2022, 4:19 AM UTC

danpalmer wrote: post #2

Big fan of Git style guides in teams. We had one at Thread. It was common for engineers to come in and find we didn't do rebasing and find it weird, but we took the opinion that history should be exactly what you actually did, not some clean and idealised version of what you wish you had done. There are advantages and disadvantages to this, but having a defined approach was the most important aspect. Also the fact th…

> that history should be exactly what you actually did

That gives you the history of exactly what git commits you made, not exactly what you did and how you went about solving the problem though, right? git describes changes to the source.

It seems like you're getting the worst of both worlds, trying to understand how the source changed is much harder when you have peoples' experiments and draft changes and false starts littering the history. And understanding the approach to problem solving and why decisions were made is pretty unsatisfying by digging through that stuff too really. That seems better kept as documentation and/or in the commit logs.

Re: Idiot Proof Git

#356

Post by est » Thu, Nov 10, 2022, 5:05 AM UTC

IMHO the single most important idiot proof of git should be a universal "undo" command.

- Committed wrong? Undo

- Switched to wrong branch? Undo

- Pushed wrong? Undo

- Merged wrong? Undo

- Wrong reset? Undo

There should be a "idempotent" undo for every action in git. If not, warn the user for possible outcomes.

In this way, we can safely learn git via trial & errors.

Re: Idiot Proof Git

#357

Post by rapind » Thu, Nov 10, 2022, 5:12 AM UTC

est wrote: post #356

IMHO the single most important idiot proof of git should be a universal "undo" command. - Committed wrong? Undo - Switched to wrong branch? Undo - Pushed wrong? Undo - Merged wrong? Undo - Wrong reset? Undo There should be a "idempotent" undo for every action in git. If not, warn the user for possible outcomes. In this way, we can safely learn git via trial & errors.

> In this way, we can safely learn git via trial & errors.

Thinking about this and I realize it could be beneficial in a lot of software. No one RTFMs anymore, and giving them the ability to trial and error makes sense. I know I appreciate it (pushing buttons to see what happens), but I’m not sure how common this approach is in general.

Re: Idiot Proof Git

#358

Post by fortran77 » Thu, Nov 10, 2022, 5:14 AM UTC

I find most attempts to hide how git really works with alternate commands just end up biting when something unexpected happens.

Re: Idiot Proof Git

#359

Post by stephen_g » Thu, Nov 10, 2022, 5:25 AM UTC

est wrote: post #356

IMHO the single most important idiot proof of git should be a universal "undo" command. - Committed wrong? Undo - Switched to wrong branch? Undo - Pushed wrong? Undo - Merged wrong? Undo - Wrong reset? Undo There should be a "idempotent" undo for every action in git. If not, warn the user for possible outcomes. In this way, we can safely learn git via trial & errors.

That's not a bad idea. Pushed wrong is pretty hard to recover from (since you often aren't allowed to rewrite history on the remote), so I don't think there could be an easy 'undo' action for that, but the other ones could potentially be done.

Re: Idiot Proof Git

#360

Post by cdaven » Thu, Nov 10, 2022, 5:27 AM UTC

throwaw20221107 wrote: post #326

yrgulation wrote: post #321

Earlier quoted context omitted.

Mainly agree except the squashing bit. Squashing means lost history, and you cant tell why a specific method or peace of code was written.

I'd argue "why a method exists" should be addressed with naming and javadocs, not in the commit message. Why split the meaning of the code between the code itself and the commit messages? And if it's not possible to document inline, the PR docs or code review comments should address this. Then future onlookers can use `blame` to see the context.

Commit messages should describe the change, not the code. This explains why the code was changed from whatever it was before, but not what the code does.

This can be important information e.g. when troubleshooting bugs, since it could explain the developer's thinking. Like in Chesterton's Fence; why on earth would you do something like this?