Idiot Proof Git • Hacker News Board

Re: Idiot Proof Git

#281

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

cnity wrote: post #158

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…

If the employer I worked for started micro-managing the way I use my tools (that affects nobody else) I would consider leaving, honestly. If I rebase on a branch that hadn't been shared with someone else, why does it matter what my boss or team thinks about that approach? Code styles are one thing, what I type into my terminal is another.

When you commit you're sharing with your team and future team. I think it's fair to have a set of agreed guidelines around that. What if you wanted to put all your commit messages as "cnity did it"?

Re: Idiot Proof Git

#282

Post by tkot » Wed, Nov 09, 2022, 9:31 PM UTC

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…

I'd probably suggest --force-with-lease just to be sure ;)

Re: Idiot Proof Git

#283

Post by gardenhedge » Wed, Nov 09, 2022, 9:32 PM UTC

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…

The problem is that it has badly named commands

Re: Idiot Proof Git

#284

Post by wizofaus » Wed, Nov 09, 2022, 9:40 PM 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…

Technically your git history isn't a record of what you did, only what you committed. If I make a bunch of changes locally, commit then realise I need to make a few extra changes before pushing there's really no harm amending the commit. But once pushed, I agree, it should stay as is.

Re: Idiot Proof Git

#285

Post by mixmastamyk » Wed, Nov 09, 2022, 9:48 PM UTC

ajorgensen wrote: post #196

cube2222 wrote: post #169

Earlier quoted context omitted.

This is basically solved by squashing each PR on merge and having a good PR title + description.

But why not do both? I find that nice commit messages make it easier on the review to see whats going on rather than a bunch of wip commits. Then squash all of the commits into a single commit with a nice title and message. The benefits of the squash at the end are, assuming you require tests pass before merge, you have a history of commits all with passing builds which makes bisect possible.

Wouldn't the cleanup work be lost in the squash?

Re: Idiot Proof Git

#286

Post by teo_zero » Wed, Nov 09, 2022, 10:15 PM UTC

Git's interface is like the 'find' UNIX command: it makes complex things possible, but does nothing to make common ones easy. 99% of times I want to find a file in the current directory or below:

  find . -name foo -print

Can you spot the 3 obvious arguments that find shouldn't require me to type?

Similarly, if so many users add -a to their git commands, why is this relegated to such an ugly flag?

Re: Idiot Proof Git

#287

Post by qu4z-2 » Wed, Nov 09, 2022, 10:20 PM UTC

MetaWhirledPeas wrote: post #277

OkayPhysicist wrote: post #213

Earlier quoted context omitted.

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…

I definitely sympathise with the confusing and scary command names! "reset" is the worst in my opinion. Rebase is kind of the natural choice once you understand the data model, but it doesn't necessarily make it more approachable.

`git rebase main` will modify your currently checked out branch to make the commits on that branch now branch off of the current value of main. It won't update main or modify it in any other way, only your current branch. You can equally `git rebase 347ae9` to have them come off a specific commit.

If you know what a tree is (in the general computer science sense, not the git term of art) it's well worth taking a little time to learn the underlying data model in my opinion.

Re: Idiot Proof Git

#288

Post by mibollma » Wed, Nov 09, 2022, 10:22 PM UTC

idop wrote: post #10

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…

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…

I disagree with both of you :). Personally I prefer to squash to one commit per ticket but on a team level I don't care about a consistent way.

I've found that the history rarely doesn't matter at all to me. Finding out who modified a specific code section (git blame) is usually good enough.

Re: Idiot Proof Git

#289

Post by eikenberry » Wed, Nov 09, 2022, 10:22 PM UTC

hinkley wrote: post #34

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…

Telling people not to rebase and having code that was never rebased are two very different things. Have you asked former employees if they rebased when nobody was looking? If you haven’t then you have no reliable data on what happens. When people set ridiculous absolute rules, what develops is an underground of people who don’t follow the rules and in some cases get a thrill from subverting the dystopia.

When I hear 'no-rebasing' I hear 'no-rebasing after you've done a PR'. That's when my code and commits are ready for others. My ongoing commits are often more notes to myself as I find those more useful during the work but make no sense as pushed commit messages where you need to block things off logically. Organizing your commits is not much different than organizing your code into modules. Something that should be done purposefully and with forethought.

Re: Idiot Proof Git

#290

Post by rtepopbe » Wed, Nov 09, 2022, 10:26 PM UTC

idop wrote: post #10

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…

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…

My current thought on this is that the git model (or at least the interface for it) is probably a touch too simple to accommodate all the things people want to use it for. As a result, you get this whole 'clean history' vs 'what really happened' split. And often you can find a few more splits if you dig in a bit deeper into the actual mechanics people prefer.

Generally, bigger picture stuff works best with cleaner histories as they mop up a bunch of unnecessary and distracting details, and neatly package things together. But doing so also means you're getting rid of, well, the details. If you need them later - and some poor bastard always will - you're just screwed.

Unfortunately all we've got are commits, so you're constantly fighting different groups and even different people who value the benefits of different approaches due to their positions, histories, or preferences.

This isn't even a half-baked idea at this point, but at first glance something like a meta-commit which just contains more commits and a message seems like it might be better. The top-level commits could just be the 'clean history' while deeper levels could record more of the as-happened details.