Live data from Hacker News

Idiot Proof Git

softwaredoug.com

61–70 of 435 posts

Re: Idiot Proof Git

#61
post #50
post #18

--force-with-lease can be a footgun. It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. It doesn't always work, particularly if you have a tool which continuously fetches remote, like an IDE configured to do so such as VSCode. In that case, you will have fetched the other person's changes, and --force-with-lease will happily blow-away anything on remote that might not be…

Yes, but it's still better than --force under most circumstances.

The implication with anything with '--force' in it, is you shouldn't be doing it without talking to someone first.

Absolutely does not belong in automatic anything, anywhere.

Re: Idiot Proof Git

#62

Rebase should never be used. Or, if it is used, it should be treated as a dangerous thing to do that’s well outside the norm. Most of the arguments in favor of rebase are by people fanatical about having a git history organized just so. It’s not worth the headache and effort. PRs are a better unit of work than commits in practice. Configure GitHub or whatever you use to squash merge only and you’ll be good. Since mov…

...here we go again.

Re: Idiot Proof Git

#63
Pretty cool idea.

Something I really want is a version of `git amend` that takes a commit hash, so I can amend my changes to any commit, not just the last one without having to start an interactive rebase.

Re: Idiot Proof Git

#64
post #40

Earlier quoted context omitted.

Oof, thanks for that warning. So it will blow away changes you haven’t merged (only fetched)? I guess git can’t tell the he difference between “not merged yet” and “don’t want to merge, please destroy”

If you don't want to blow away changes you haven't merged, you shouldn't be doing force at all?

Well, the article presents a seemingly nice workflow that lets you handle local rebases. I was considering it.

However, we use vscode, and I rather like auto fetch. But apparently this workflow would destroy something auto fetched that I might not have even noticed.

Re: Idiot Proof Git

#65
post #39
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…

I advocate for rebasing, but I discourage using a linear history. The two may seem to contradict one another but they are distinct (enough) that I felt it worth mentioning. When a developer pushes, it makes sense for them to rebase first because they are shipping those commits at the time of the push. But, depending on your git workflow, when merging to main, I prefer a merge commit so I can see the tree of activitie…

That's fine of course. Personally, I prefer to make things as easy as possible to understand at that unspecified but probable future date when a customer opens a SEV1 and I have to consult with the log, among other things. Make it idiot proof later, when time is _really_ of the essence, rather than now, when you're being artificially pressured to deliver that story for the sprint review in two hours.

Re: Idiot Proof Git

#66
post #5

How is push origin HEAD --force-with-lease different from normal git push? Can someone please explain this to me?

It's not really, but there are a couple minor differences in practice. First, it assumes the name of your upstream repository is "origin" which is fine in most cases as that is what `git clone` defaults to naming the remote. Second, using `HEAD` always pushes your current checked our branch to your remote with a remote branch of the same name. It's a neat trick to skip the "`git push` -> you need to set your upstream…

If git ever got a redesign from scratch, they should make -f be --force-with-lease, and make -F be --force[-with-prejudice].

Re: Idiot Proof Git

#67

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…

> history should be exactly what you actually did, not some clean and idealised version of what you wish you had done.

This is a false premise. There is a product (and its various versions), and the team that develops it. Both have a claim to a meaningful definition of "history". What you are arguing is that the 'history of developer' is more fundamental than a less noisy 'history of the product development'.

Does it really matter (and need we record it for posterity) if developer x used n commits to post n incremental changes to a well defined software unit of the product?

It seems a comprise position of (1) no history rewrites before code review, followed by (2) post code review cleansing squash before merge would satisfy all concerns and history records have also served their purpose.

. A developer's timeline is relevant to her team lead, not the product manager.

Re: Idiot Proof Git

#68

I guess this will come off kinda... douchey? But I just don't find Git to be that hard. I know there's a lot of complexity there, but I find that 95% of the time I'm just git add -p or git add . and then committing. Every once in a while I'll do a rebase, and that's the most complex part of Git that I use with any frequency. I remember when I first was introduced to Git I found it confusing, so I'm sympathetic to new…

The UI is inconsistent and unintuitive.

I won't disagree with that, but idk. Once you understand the basic operations everything weird is a Google away.

I'll admit that Git is the only VCS I've spent any time with, so maybe I just don't know how much better it could be. But I've almost never had an issue with Git where I actually lost code. And anytime I'm doing something dangerous, I just make a backup copy of the directory in case I screw up irrevocably. But even if I'm doing something nasty, the reflog is there, and the cases where I've need to use my backup copy are very few and far between.

Re: Idiot Proof Git

#69
post #18

--force-with-lease can be a footgun. It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. It doesn't always work, particularly if you have a tool which continuously fetches remote, like an IDE configured to do so such as VSCode. In that case, you will have fetched the other person's changes, and --force-with-lease will happily blow-away anything on remote that might not be…

From https://git-scm.com/docs/git-push

A general note on safety: supplying this option without an expected value, i.e. as --force-with-lease or --force-with-lease= interacts very badly with anything that implicitly runs git fetch on the remote to be pushed to in the background, e.g. git fetch origin on your repository in a cronjob.

The protection it offers over --force is ensuring that subsequent changes your work wasn’t based on aren’t clobbered, but this is trivially defeated if some background process is updating refs in the background. We don’t have anything except the remote tracking info to go by as a heuristic for refs you’re expected to have seen & are willing to clobber.

If your editor or some other system is running git fetch in the background for you a way to mitigate this is to simply set up another remote:

    git remote add origin-push $(git config remote.origin.url)
    git fetch origin-push
Now when the background process runs git fetch origin the references on origin-push won’t be updated, and thus commands like:

   git push --force-with-lease origin-push
Will fail unless you manually run git fetch origin-push. This method is of course entirely defeated by something that runs git fetch --all, in that case you’d need to either disable it or do something more tedious like:

    git fetch              # update 'master' from remote
    git tag base master    # mark our base point
    git rebase -i master   # rewrite some commits
    git push --force-with-lease=master:base master:master
I.e. create a base tag for versions of the upstream code that you’ve seen and are willing to overwrite, then rewrite history, and finally force push changes to master if the remote version is still at base, regardless of what your local remotes/origin/master has been updated to in the background.

Alternatively, specifying --force-if-includes as an ancillary option along with --force-with-lease[=] (i.e., without saying what exact commit the ref on the remote side must be pointing at, or which refs on the remote side are being protected) at the time of "push" will verify if updates from the remote-tracking refs that may have been implicitly updated in the background are integrated locally before allowing a forced update.

Re: Idiot Proof Git

#70
post #61
post #50

Earlier quoted context omitted.

Yes, but it's still better than --force under most circumstances.

The implication with anything with '--force' in it, is you shouldn't be doing it without talking to someone first. Absolutely does not belong in automatic anything, anywhere.

Oh, obviously you need to know what you are doing.

I mostly use --force-with-lease to push something to my own branches. No need to talk to anyone.

Force pushing to other people's branches without asking is just rude.

Post reply on HN