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

Idiot Proof Git

softwaredoug.com

Post reply on HN
Print view View original

431–435 of 435 posts

Re: Idiot Proof Git

#431

Post by Shorel »

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…

For me, there should be a balance between the detail of history and the usefulness of the information.

For the changes I do, not only I rebase them all in a single commit, I don't even merge branches. I cherry-pick my changeset. Clean commits, clean history.

Whatever I do before a push is my business and no one's else.

For anyone else changes, that's it, anyone who is not me: history is untouchable. No rebases, no squash, whatever it is already pushed, must stay as it is.

When I do a pull: git stash, git pull --rebase, git stash pop

I encourage everyone to clean their commits before a push. A clean history is a good history.

Re: Idiot Proof Git

#432

Post by ernestns »

krinchan wrote: post #183
dec0dedab0de wrote: post #78

Earlier quoted context omitted.

When I say "the evolution of the product" I really mean "the "evolution of the code". When a small feature branch with 5 commits - four of which say "wip" and the last one says "added color support" - gets merged as is, and all relevant information is held hostage by whatever Git platform the company is using this week and not inside the repository itself, the log is not useful to me regardless of any strategy. Yes,…

git add .; and git commit --amend --no-edit; git push origin --force Rarely, I have to do pipeline work on repositories. You'd normally see twenty "Fix Jankins Issue" commits on the main branch because of some nonsense that only happens when you deploy UAT or whatever. Once I learned this little gem, this is also how I manage my feature branches mostly. But also my employer's fleet of laptops has been aging and I've…

You can combine

  git add .; git commit --amend --no-edit;
with the `-a` option

  git -a --amend --no-edit;

Re: Idiot Proof Git

#433

Post by throwaw20221107 »

veilrap wrote: post #425
throwaw20221107 wrote: post #298

Earlier quoted context omitted.

The only reason people lose code is because 1. they didn't read this one diagram: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-... 2. And then they run `reset --hard`

I'm mostly with you, except, `git reset --hard` is relatively easy to recover from. `git reflog` generally can fix most `git reset --hard` commands. On the other hand. `git checkout .` with unstaged changes tends to be the most common way I've seen people lose code via git.

That's fair. Both overwrite (edit: seemingly overwrite) (un)staged changes. But `checkout` requires less hyphens.

I feel like all of this would be resolved if my boy Linus had renamed `git add` to `git stage` or `git prepare` or something more clear.

Or added some warning, like "all this stuff you haven't committed yet; it's not managed by `git` so don't try to overwrite it all using `git` until you've committed some of it."

Re: Idiot Proof Git

#434

Post by throwaw20221107 »

throwaw20221107 wrote: post #433
veilrap wrote: post #425

Earlier quoted context omitted.

I'm mostly with you, except, `git reset --hard` is relatively easy to recover from. `git reflog` generally can fix most `git reset --hard` commands. On the other hand. `git checkout .` with unstaged changes tends to be the most common way I've seen people lose code via git.

That's fair. Both overwrite (edit: seemingly overwrite) (un)staged changes. But `checkout` requires less hyphens. I feel like all of this would be resolved if my boy Linus had renamed `git add` to `git stage` or `git prepare` or something more clear. Or added some warning, like "all this stuff you haven't committed yet; it's not managed by `git` so don't try to overwrite it all using `git` until you've committed some…

This is another argument why "not squashing is bad"; because it discourages people from committing.

Re: Idiot Proof Git

#435

Post by t43562 »

lelandfe wrote: post #200
t43562 wrote: post #180

Earlier quoted context omitted.

IMO one should maintain a CHANGES.md file with whatever you would be putting in the PR description in it. There's no specific need to squash commits to do this as long as you create it just before you create the PR. Even the odd bugfix or review comment after that is no big deal.

I don't see the advantage of doing this over ensuring the commits stay atomic, and I see several disadvantages. Namely, git conflicts will happen constantly; and the file size will graduate from unwieldy to unusable over time. One repo I work on has >45,000 PRs merged. Good luck even opening that file. This approach also poses risk: people will forget to add to it.

If a file is too big you rename it to changes.2022.md. People forget everything but you do reviews to check that presumably. with merge conflicts - if those become a problem for your project you can be more sophisticated. In one case we put all our unreleased change descriptions into a directory and generate CHANGES.md as part of the release. For any PR merge however, you can see a detailed description of what was merged.
Post reply on HN