I've just amended a commit and force-pushed it, this is what I got in the flux log:
ts=2017-08-09T15:59:15Z caller=loop.go:47 component=sync-loop operation=pull err="git pull --ff-only [email protected]:errordeveloper/istio-gitops.git master: fatal: Not possible to fast-forward, aborting."
It sounds like we would face the same issue in any other case of history being re-written, most notably a rebase.
As a user, I'd like flux to trust whatever I've pushed to the repo, I'd be okay with it doing something like git fetch <upstream> && git reset --hard <upstream>/<branch>.
As a user, I'd like flux to trust whatever I've pushed to the repo,
Yes that seems a fair principle. Ultimately we are syncing with some files in a directory -- the fact they have a chequered history is irrelevant.
I would be a little worried about how other bits of the system behave in the case of rewritten git commits, so I'd want to look into where assumptions are made. But it's not this bug's fault that people rewrite git history :)
I think I just stepped into the same bug after force-pushing a rebased branch:
ts=2020-05-29T20:51:23.72285586Z caller=loop.go:133 component=sync-loop event=refreshed url=https://@.../varac/... branch=varac HEAD=6c45cd95974ce4f61f27dd316885534750eb9ae3
ts=2020-05-29T20:51:24.006651359Z caller=loop.go:107 component=sync-loop err="fatal: Invalid revision range ef372acd585c5850a5c8de6291957b7fc6bc9d3e..6c45cd95974ce4f61f27dd316885534750eb9ae3, full output:\n fatal: Invalid revision range ef372acd585c5850a5c8de6291957b7fc6bc9d3e..6c45cd95974ce4f61f27dd316885534750eb9ae3\n"
Please make flux be able to deal with rewritten git history.
Until then, how would I manually recover from this ?
Btw, this happend with flux 1.19.0
just happened to me as well; _sigh_...
Most helpful comment
I think I just stepped into the same bug after force-pushing a rebased branch:
Please make flux be able to deal with rewritten git history.
Until then, how would I manually recover from this ?