I am not sure if this is intended as a feature or if it is a bug.
Repositories R1 and R2 both have a subrepo S with shared code, so things look like this:
├── R1
│ ├── README.md
│ ├── S
│ │ ├── .gitrepo
│ │ └── shared.sh <-- echo 'Hello from shared code'
│ └── r1.c
├── R2
│ ├── README.md
│ ├── S
│ │ ├── .gitrepo
│ │ └── shared.sh <-- echo 'Hello from shared code'
│ └── r2.c
└── S
└── shared.sh <-- echo 'Hello from shared code'
Someone in R1 modifies shared.sh, commits and pushes (to R1 only), so now things look like this:
├── R1
│ ├── README.md
│ ├── S
│ │ ├── .gitrepo
│ │ └── shared.sh <-- echo 'Hello from R1'
│ └── r1.c
├── R2
│ ├── README.md
│ ├── S
│ │ ├── .gitrepo
│ │ └── shared.sh <-- echo 'Hello from shared code'
│ └── r2.c
└── S
└── shared.sh <-- echo 'Hello from shared code'
All the repos (R1, R2 and S) say they are up to date, and git subrepo status does not seem any different in R1 and R2, it shows the same upstream ref and pulled commit... which is already not quite what I'd expect... no warning about changes whatsoever... but lets keep going...
Somehow, someone realises that there was a mess up with the shared code in R1, and tries to force pull the subrepo to get the original shared code:
.../R1$ git subrepo pull S --force
Subrepo 'S' pulled from 'git@github....' (main).
However, this does not recover shared.sh! It still has echo 'Hello from R1'.
I tried cleaning and fetching, but nothing seems to work... the only workaround is to delete the subrepo, and add it again...
Is this the intended functionality? could there be a git subrepo reset or similar command to revert local changes? Could there at least be a warning about differences between the upstream subrepo and the local files?
Note: if there is a new commit on S force pulling will reset things, the bug is only for when the remote and local subrepo are in theory on the same commit...
I am not sure if this is intended as a feature or if it is a bug.
Repositories R1 and R2 both have a subrepo S with shared code, so things look like this:
Someone in
R1
modifiesshared.sh
, commits and pushes (to R1 only), so now things look like this:All the repos (
R1
,R2
andS
) say they are up to date, andgit subrepo status
does not seem any different inR1
andR2
, it shows the same upstream ref and pulled commit... which is already not quite what I'd expect... no warning about changes whatsoever... but lets keep going... Somehow, someone realises that there was a mess up with the shared code inR1
, and tries to force pull the subrepo to get the original shared code:However, this does not recover
shared.sh
! It still hasecho 'Hello from R1'
.I tried cleaning and fetching, but nothing seems to work... the only workaround is to delete the subrepo, and add it again... Is this the intended functionality? could there be a
git subrepo reset
or similar command to revert local changes? Could there at least be a warning about differences between the upstream subrepo and the local files?Note: if there is a new commit on
S
force pulling will reset things, the bug is only for when the remote and local subrepo are in theory on the same commit...