Fix issue preventing import.git from syncing due to divergent branches

[ptodev]

PR Description

Consider this situation:

• import.git is configured to use branch A.
• Alloy is then stopped, and its new configuration is configured to use branch B.
• If branches A and B are divergent, import.git will fail to switch to branch B because it's going to try to pull A into B.

The user will get a "failed to update repository \"git@github.com:org/repo.git\": non-fast-forward update" error.

I suppose the same thing could also happen if a force push is done to the branch Alloy is monitoring.

Since Alloy is only reading from the repo, but not writing, there is no point in trying to do a pull. It's much easier to just do a fetch and checkout.

PR Checklist

• CHANGELOG.md updated
• Documentation added
• Tests updated
• Config converters updated

[mattdurham]

I think this was my original approach but it had issues with switching branches and accessing HEAD. Hence the test failing.

[ptodev]

I think this was my original approach but it had issues with switching branches and accessing HEAD. Hence the test failing.

@mattdurham Thank you, I had a look at the Agent PR which introduced pull just now. I think the default value for "revision" shouldn't be something like "HEAD". HEAD refers to the tip of the current branch. But what is the current branch in import.git? :) There is no config attribute to set it, so I'm not sure how it gets chosen. Maybe the remote tells it what the default branch is.

I think we should simply not allow values such as "HEAD", "FETCH_HEAD", etc to be the "revision". I updated my PR accordingly - would you like to take a look please? If you agree with it, I can update the docs and I'll also list it as a breaking change in the changelog.

If a user is able to set "revision" to something like "HEAD", "FETCH_HEAD" etc, then they'd be relying on some internal quirk of how import.git works, which wouldn't be correct.

[mattdurham]

HEAD isn't a quirk of import.git but fundamental feature for git. That being said I am not against saying you cant use the pointer style aliases and instead have to use a non alias value.

[mattdurham]

LGTM, its a breaking change but if this cleans this up totally fine and once the tests pass.