Since I felt like none of the other git related topics fit without me hijacking them, please excuse me starting another one...
I've been testing the git implementation in PowerBuilder 2017 R2 for internal use, but have come across a number of issues we hope to see resolved by the time we use it:
Pull is not working after IDE restart:
This one is a bit strange and possibly related to initialization problems.
After the project is loaded executing a pull is not possible unless a push is performed (Git client error: Generic error..).
At this point there are no new commits on the local checkout and the push either fails (new commits on remote results in "Git client error: Reference was not fast-forwardable..") or "succeeds" (no new commits on remote). Afterwards the pull works (mostly, see next point) fine.
This one is a bit strange and possibly related to initialization problems.
After the project is loaded executing a pull is not possible unless a push is performed (Git client error: Generic error..).
At this point there are no new commits on the local checkout and the push either fails (new commits on remote results in "Git client error: Reference was not fast-forwardable..") or "succeeds" (no new commits on remote). Afterwards the pull works (mostly, see next point) fine.
Pull always starts a merge:
This error shows itself in two possible ways, let's start with the "no new commits" scenario.
If there are no changes upstream the local checkout will enter the merge state, but while the ui says everything is fine the repository enters an unfinished merge state between HEAD and HEAD. When a new changeset is committed, it will be associated with the merge potentially hiding that an actual change happened due to the way the development history is rearranged (visually an observer might expect a merge operation without major code changes when in fact this is a commit incorrectly marked as merge).
If there are changes upstream which could be fast forwarded the implementation forces a merge commit. This might be fine for a single developer mostly using this to preserve his change history, but in a multi-developer scenario, this will result in a large amount of unnecessary changes (expect at least one per day per developer) rearranging the history in unexpected ways which in a worst case scenario requires manual merges with an external tool to resolve the base and source commit.
This error shows itself in two possible ways, let's start with the "no new commits" scenario.
If there are no changes upstream the local checkout will enter the merge state, but while the ui says everything is fine the repository enters an unfinished merge state between HEAD and HEAD. When a new changeset is committed, it will be associated with the merge potentially hiding that an actual change happened due to the way the development history is rearranged (visually an observer might expect a merge operation without major code changes when in fact this is a commit incorrectly marked as merge).
If there are changes upstream which could be fast forwarded the implementation forces a merge commit. This might be fine for a single developer mostly using this to preserve his change history, but in a multi-developer scenario, this will result in a large amount of unnecessary changes (expect at least one per day per developer) rearranging the history in unexpected ways which in a worst case scenario requires manual merges with an external tool to resolve the base and source commit.
This can both be worked around by executing the pull and then manually resetting the tree to HEAD^ (or HEAD for the unfinished merge), but you can expect people to forget this easily and this is nothing a novice version control user should be expected to know and/or do.
Only in case a merge is required one should appear in the commit history. While I personally would prefer to rebase local changes before committing, there is no immediate need for PowerBuilder to do this automatically.
Another minor grievance related to merging is the commit message which differs from upstream git default. It would be nice if it a variant of "Merge branch ''" instead of the static "remote pull commit" as it would be closer to the upstream message and stand out less.
Another minor grievance related to merging is the commit message which differs from upstream git default. It would be nice if it a variant of "Merge branch '
How strange an apparent single developer development graph can look can be seen in multiple of the "AppeonTest" repositories on github, e.g. https://github.com/AppeonTest/pbexamples/network
The final minor issue thus far is that PowerBuilder appears to keep some file references active, meaning a "git gc" on a workspace opened in PowerBuilder might fail since pack files and the respective indexes can't be modified.
Since one can assume the next time git gc is run there is a new PowerBuilder instance running, the effect is minimal as long as external tools handle this correctly or this behavior should be fixed on their end.
This happens for regular as well as for "pull" commits. Changing to a git enabled workspace in an existing PowerBuilder instance shows similar behavior and changing to another workspace releases the resources.
Since one can assume the next time git gc is run there is a new PowerBuilder instance running, the effect is minimal as long as external tools handle this correctly or this behavior should be fixed on their end.
This happens for regular as well as for "pull" commits. Changing to a git enabled workspace in an existing PowerBuilder instance shows similar behavior and changing to another workspace releases the resources.
Regards
Moritz
