jacebrowning / jacebrowning/gitman
Using install and `--fetch`, gitman does not reset local branch to the remote version
- Dominant language
- Python
- Stars
- 225
- Forks
- 36
- Avg merge
- 15h 47m
- Merged PRs (30d)
- 8
Description
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`.
```yaml
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:
```shell
$ git remote set-url origin
$ 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`?).
Contributor guide
Research direction
Start at the install command's handling of --fetch and --force, then reproduce the example with a rewritten remote my-branch. Trace the checkout behavior shown in the issue and verify that the local branch follows the configured remote branch after installation; also check whether the same behavior applies to gitman update.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, python
- Domain
- cli, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100