jacebrowning/gitman

Using install and `--fetch`, gitman does not reset local branch to the remote version

fuhrmannb opened this issue · 2 comments

Gitman version used: v2.3.2
Python version: v3.9.4

If we already used gitman install to clone a repo, then we perform a change in a branch on the remote git repository, the next gitman install command will not integrate the new changes of the remote branch if the history has been rewritten.

Considering this example with my-repo using a custom branch my-branch.

sources:
- name: my-repo
  type: git
  repo: my-repo-url.git
  rev: my-branch

Let's imagine that the upstream version of my-branch has changed and the commits and/or history have been rewritten:

* 38d601ff (HEAD -> my-branch) My previous commit in my-branch
| * 8831558b (origin/my-branch) My new commit in my-branch
|/  
*   308afa45 (origin/master, origin/HEAD) Last master commit

In that case, gitman install --fetch --force will not reset local branch my-branch with the content of the remote branch.

The output of gitman is the following:

  $ git remote set-url origin <origin-url>
  $ git fetch --tags --force --prune origin my-branch
  From my-repo-url
  * branch              my-branch -> FETCH_HEAD
  $ git checkout --force my-branch

We can see that the local branch is not rebased/reset on the remote branch (there is no for instance git reset --hard origin/my-branch).

IMHO, gitman should always follow the remote version of the branch with the information specified in gitman.yml. Or, at least, having an option to specify this behavior.

Note: my comment may also be applicable on other commands (maybe gitman update?).

Yeah, this seems like an appropriate change.

I have a similar issue with local commits that has not been pushed to origin. Running gitman update and gitman update --force will not update the branch nor report any error message.

I might be willing to do the work but how should it work?

gitman update/install should issue an error?
gitman update/install --force should just get reset --hard resulting in git running gc at some point then loosing the local commit?
In the case of rewritten history there is no issue with git reset --hard.

Or should this be two different issues?