git: fix scm switch when going back to older revision

[rhubert]

If gitCommitOnBranch is active and commit and branch are configured in the recipe changing the commit back to a older one did not update the sources back to the configured version. Instead the remained on the current version.

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.06% 🎉

Comparison is base (d8326d7) 88.24% compared to head (8243c29) 88.31%.

❗ Current head 8243c29 differs from pull request most recent head a08c442. Consider uploading reports for the commit a08c442 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #531      +/-   ##
==========================================
+ Coverage   88.24%   88.31%   +0.06%     
==========================================
  Files          46       46              
  Lines       14501    14494       -7     
==========================================
+ Hits        12797    12800       +3     
+ Misses       1704     1694      -10     

Files Changed	Coverage Δ
pym/bob/scm/git.py	94.17% <100.00%> (+1.67%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jkloetzke]

I think the goal should be to remove git merge --ff-only and replace it by git reset --mixed $commit/$tag. The problem is that we must make sure that no commit of the user is lost. Whenever any remote branch holds the current commit (after switching to the branch) then we're safe. I think calling git branch --remotes --contains HEAD (before git reset) and verify that it produced some output before should be sufficient...

[rhubert]

I think git reset --mixed is wrong as it would leave all changes uncommitted in the workspace.

If there are 3 commits:

- A - B - C  (HEAD)

git reset --mixed B would leave Cs-changes in the workspace (uncommitted).

I think we need to distinguish between moving forward and backwards in history.
Moving forwards git reset --mixed or keep git merge --ff-only should work.

Going backwards use git reset --hard if git status --porcelain returns nothing and C is on any other local or a remote branch. Otherwise move to attic.

[jkloetzke]

Right, my bad. Obviously I was not reading the manpage carefully enough. 🙈 But git reset --hard does feel too dangerous. What about git reset --keep? It moves the branch forward and backwards while aborting the operation if a file has changes that needs to be updated. In this case Bob will move the repository into the attic as expected. OTOH unrelated files do not prohibit updates. Sounds safe to me.

But as already said, we have to make sure that the old commit is not lost. Maybe git branch --remotes --contains HEAD is a bit too pessimistic. The user might have another local branch. My current idea is to run git branch -a --format='%(refname:lstrip=2)' --contains HEAD and remove the current branch name from the list. Thoughts?

[jkloetzke]

Thanks for bearing with me. :)