I have cloned an app to my computer and worked locally on some modules. Twice I tweaked a server module and pushed (the Stuff commits), so my tests could use the updated server callables.
When my tests succeeded, I pushed again, switched from PyCharm to the online Anvil editor and noticed that the last pushed commit is there (good), but the previous commit is highlighted.
What does it mean?
From what I can see (using git knowledge), your master branch (which is linked to the “Production (master)” environment is pointing to the commit “Edited FillA…” and the dev branch (which is linked to the “Development” environment is pointing to the “Test succeed with…” commit, which doesn’t have the contents that the master branch has since the “orange branch” is coming from another ancestor different than the “blue branch”.
It means that your commits locally are on the dev branch, not on the master branch.
dev is shown as the Editing branch, but the dev branch is not the highlighted one.
The first Stuff branch is highlighted.
Perhaps the history correctly updates right after a commit is pushed from another repository (good), but:
Editing branch is not updatedI would expect for it to either:
Editing branch to be cleared, ordev branch to be automatically checked out, with eventual warnings about merge conflictsBut I’m not expert in git, so my expectations could be totally wrong.
When you type anything in any file using the Anvil Editor with the Version Control open a “Editing” branch (Working files) is displayed the same way as “dev” and “master” are displayed. When you type anything, which commit shows the “EDITING” label? The last one or the “Stuff” one?
It should be the last one, since Anvil correctly shows that the dev branch (which is the one checked-out) is one commit ahead than the highlighted commit, than maybe is just a visual bug.
If it’s the “Stuff” one, than definitely there’s a workflow bug in the editor. Try to commit the changes and see if a branching path is created from the “Stuff” commit unrelated to the last commit. Also, try right-clicking in the last commit and see if there’s an option to “reset current branch to this commit” or something like that. This would be a temp solution for now.
Since I don’t understand what’s going on, I go the save way: set Editing branch to master, then back to dev. 
I tried what you suggested: push from my computer and wait for the version history to show my commit, then edit the code.
It was showing the dev branch on the new commit, but kept the old commit highlighted. I guess that means that the code being currently edited is on that commit, so the Editing branch drop down seems to be wrong at this moment.
But as soon as I edited some code, I got this:
I guess when you push code to the branch you are editing online, you should also refresh the browser.
It would be nice if the IDE, which knows about the new code being pushed (it shows the new commit in the history), did warn me rather than keeping the UI inconsistent and showing a warning after the first edit.
This is obviously not a big problem, because the workaround is to do what you would need to do anyway: reload the page, and because there is a clear warning that prevents you from making a mess. But keeping the UI inconsistent and waiting for a problem to happen before straightening things up is not the best behavior.
I think I understand what is happening.
When you check out a branch, what git does is to throw into your working files the correct version of the files from that commit point of view. Then, your edits all go to your working files, unrelated to any other commits that are happening elsewhere.
When you checkout locally, you create a new local branch based and tracked by a remote branch (which is maintained by Anvil). You, then, commit and push your commits on the local branch to the remote branch.
The thing is, when you access the Anvil Web Editor, you also have the working files checked from a specific commit. It’s kind of like when two different people check out the same branch and work independently. Person A would not know the commits from Person B until it fetched the remote. The problem is that when you use the web editor, you are editing directly into the remote branch.
The editor doesn’t know its behind until it tries to save (and commit) your new changes. The Version Control tab is just a print of the git log graphos, is not really the same as the editor.
So, I think they implemented the best way of avoiding conflicts, as you showed.
This is exactly what’s happening! The branch has moved, but you still have an older commit open in the editor. As you have experienced, if you now try to edit that app, you’ll get told you have to reset to the latest position of that branch before you can make new changes on that branch. So it’s always safe, but occasionally tells you that you need to refresh.
Your actions (switch branch, then switch back) were perfectly valid – although double-clicking on the new commit should also do it.
Eventually, what we’d like to do is when someone else updates a branch underneath you (whether by SSH or just in another session), the editor pops that dialog immediately rather than waiting for you to edit something. That way, both what happened and what choices you now have are clear. But that is one of the many features that lost out in the race between “make it better” and “we have something great now, we need to stop polishing and let people start using it!”
I learned the hard way to edit in the IDE, or locally, but never both (at the same time); and to sync the two before switching from one to the other. In fact, I close the App in the IDE before editing locally, just to be safe.
With multiple developers, perhaps one should assign the branch to one developer at a time. Then that developer is responsible for applying the above procedures. And they’re the one who gets tripped up if they fail to follow them.
Just so you know, @p.colbert, that level of precaution is not necessary. Neither git push nor the Editor will let you overwrite changes accidentally. Hopefully the extra visibility in the new Editor makes it clearer what’s happening
It keeps me from getting into situations where I need to call (or become) a Git Guru, just to a) understand what’s going on and b) get myself back into a workable state.
In fairness, I’m still using the old IDE (until the new one stabilizes).
Anything that helps the developer understand and move forward should be applauded. Loudly. Anvil inevitably draws “developers” who may have never seen Python before, much less version control.