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?