isomorphic-git
isomorphic-git copied to clipboard
should not fail with E.PushRejectedNonFastForward if no new commits to push
Probably happening because the remote head is NOT technically a descendent of the local head. It's the same commit.
It should go ahead and allow the push, because IDK, lets you trigger remote hooks or whatever.
Ran into this too. In my sync logic (which runs only in absence of unstaged/uncommitted changes) I just run pull first to catch any actual fast-forward fails, and then simply ignore PushRejectedNonFastForward on subsequent push.
I’d like to add a note to documentation; but the errors page seems to be auto-generated from GitError.
I’d change the message to something like “Push rejected because it was not a simple fast-forward. Use "force: true" to override. Note: an absence of commits to push currently results in this error as well.”, but it seems a bit too long🤔
(In case it’s useful to someone, it looks like the proper way to avoid this issue is to check whether there is something to push beforehand by inspecting listServerRefs())
If it can be useful for others, I solved it like that:
const remoteCommits = await git.log({
fs,
dir: folder,
depth: 1,
ref: `refs/remotes/${remoteName}/${remoteBranch}`,
});
const remoteOid =
remoteCommits && remoteCommits.length ? remoteCommits[0].oid : null;
const localCommits = await git.log({
fs,
dir: folder,
depth: 1,
});
const localOid =
localCommits && localCommits.length ? localCommits[0].oid : null;
if (localOid === remoteOid) {
return;
}
I think it's more efficient to get the SHA-1 object by using git.resolveRef().
const current = await git.resolveRef({ ...this.getRepo(), ref: currentBranch });
const tracking = await git.resolveRef({ ...this.getRepo(), ref: trackingBranch });
return current != tracking;
It turns out that logic is already done in the _push function. All we need to do is add an equality check.
I think this should be a bug since it differs from the behavior of canonical git. I can push as many times as I want with canonical git and it doesn't complain.
I submitted a PR with the proposed fix. See #1625
:tada: This issue has been resolved in version 1.19.2 :tada:
The release is available on:
Your semantic-release bot :package::rocket: