when using tags like v2.1.0, the checkout will put you on a detached HEAD.
If the "tag" is a remote branchname, e.g. origin/master, then the fetch will have made sure that's up-to-date. So this will be ok presumably. You will also be on a detached HEAD.
If the "tag" is a local branchname, e.g. master, then the checkout doesn't update the local branch with remote items. So this is a problem and needs a pull (actually merge)
However, if you're in a detached HEAD, you cannot pull:
$ git checkout origin/master
$ git pull
You are not currently on a branch.
Please specify which branch you want to merge with.
I guess there is no easy way to check in which of the 3 cases we are. Possibly the easiest thing to do is a git pull anyway after the checkout, and cope with the failure.
I suppose this is why the CMake Externalproject* stuff is so complicated for updating git...
@paskino found a problem with our current strategy of using
fetch
,checkout tag
https://github.com/SyneRBI/SyneRBI_VM/blob/7f0749fa1092d50768507b5751a751103550ddce/scripts/UPDATE.sh#L141See https://github.com/SyneRBI/SyneRBI_VM/pull/151#discussion_r407855603
There are 3 cases:
v2.1.0
, the checkout will put you on a detached HEAD.origin/master
, then thefetch
will have made sure that's up-to-date. So this will be ok presumably. You will also be on a detached HEAD.master
, then the checkout doesn't update the local branch with remote items. So this is a problem and needs apull
(actuallymerge
)However, if you're in a detached HEAD, you cannot pull:
I guess there is no easy way to check in which of the 3 cases we are. Possibly the easiest thing to do is a
git pull
anyway after the checkout, and cope with the failure.I suppose this is why the CMake
Externalproject*
stuff is so complicated for updating git...