I want to keep my commit history clean, without needing to spend my time squashing garbage commit automatically made by the IDE.
I understand that theoretically, we have auto-commits every 15min. However I noticed that sometimes the commit is made before that. In any case, I don’t want Anvil to decide when and what commit in my project repository. This is creating a big friction in the team, because the remote branches have sync problems more frequently because of the automatic commits.
I still like the auto-save, but I want to be 100% in control when to commit something (and the message we use). Is it possible?
It used to create many commits, often even empty commits, but now the number of commits is much lower. I sometimes work for hours and have only one commit.
I don’t think it is possible to disable the autocommit, that’s how Anvil works. Every change is immediately committed to the repository, otherwise you couldn’t run it or see the diff in the history panel. Anvil does a good job at figuring out that the next change can be an amend of the latest commit, and does that constantly, every time you edit the app.
When something happens that makes Anvil believe that the last commit shouldn’t be amended, then that commit is preserved for good. For example every interaction with the repository like a push or pull will cause the last commit to stick.
Perhaps you are interacting with the repository in other ways, other than simple editing online on the same branch? Or you have tools that push and pull constantly?
(This is my understanding of how it works based on my experience, and I may be wrong)
I don’t want Anvil do any job trying to figure out when to commit something. We have a process with code reviews and pull requests, and the large amount of the same “Edited SomethingForm” commit message make it very complicated to handle. I use the online editor, as it is almost impossible to work in a separated IDE.
Good commit messages are a best practice in high quality software development teams, as they contains important information about each change in the project, so I would expect that the platform would give me this control, so I decide when to commit something.
Anvil needs to commit any change if you want to execute it. That’s how Anvil works (I think), and I don’t think this will change. They will then do their best to amend the changes, so you don’t see them in the repository, but they have to commit. I agree that sometimes their best is not good enough.
Last month I worked on an app for hours, then I checked the history and there were only 3 commits. I was disappointed that I couldn’t go back and see something I had done earlier. But obviously relying on auto commits to see what I had done earlier is far from best practice!
In the past, when Anvil was really creating too many commits, I used to work with two apps: one for development and one for production, both cloned to my computer. When the development was ready to go to production, I would pull them both, copy the code from dev to prod, commit with a good message and push. So the production app had only my commits. I was never editing the production app from the IDE.
Now I find the automatic commits to be not too bad and I stopped working with two apps. I learned to ignore the automatic commits and only look at the ones with my messages. When I want to look at the diff between two real commits, I clone to my pc, select the two commits in PyCharm and look at the diff between the two branches.
I use the online editor only for the UI, and I try to keep the UI as little as possible.
Some apps do most of the job on the server side, some do it on the client, in both cases I try to decouple UI from logic and develop the logic offline. Easier to debug and test. I create a rough UI, clone, work on the logic, then back online to finish the UI. At this point the UI uses the classes designed to provide anything the UI needs, and the code on the form is just event management and using the classes that already work.
That’s not exactly true. I often work on an app and one of my dependencies in separate tabs, changing things in the dependency without commiting and the changes affect the app instantaneously.
As I said in the FR, Anvil still needs to auto-save things, be allow us to reopen commits or at least change the commit message. This is really needed. I often rush to finish a feature just so that anvil doesn’t auto commit an unfinished code if I stay idle for 15 minutes. That creates A LOT of anxiety.
On a normal Python application, not Anvil, if you pip install the new version of a dependency package used by your repository, you don’t have a new commit on your repository, you have it in the dependency package, but you get the new behavior. Anvil does the same (still speculating here): you edit a dependency, the new commit is pushed to the Anvil infrastructure, and the next time you start any dependent app you get the new behavior.
There is a new commit, but it’s in the dependency app.
The commit message is part of the commit. You can only change by amending the last commit. But if the last commit is deemed unchangeable because used by other repositories that have pulled, then you can’t amend that commit. Changing the message would be just like changing a file.
Yes, but this is exactly what I’m talking.
I think the auto-save/commit is great for all the new devs using anvil or people new to git.
However, the last commit should be able to be ammended or reopened, just like in git.
The best scenario would be to be able to completely disable auto-commit, but if it’s a general problem because of how anvil works, then at least we shoul be able to right-click the last commit and choose to “reopen”, going back to the “Editing” state where any new changes will commit again with the last changes.
Well… try, in your computer, no Anvil here, to create a remote repository, clone it in two different places, commit something in one place and push, pull to the other, go back to the first place, amend the commit and push, go to the second place and pull. You may have a bad surprise.
The fact that a commit is the last one, is not a guarantee that it’s amendable. If that commit has been pulled to other repositories, changing it wouldn’t be nice.
I would love to have an “Edit message” and “Delete commit” items in the history panel. But I’m afraid that they would not play nice with any cloned repository. I am mostly working alone, so I could keep re-cloning the repository every time I rename or delete a commit, but this may not be acceptable in multi-user github-linked repositories.
I understand what you are saying, but I still think a way to fix the version history is needed, or the version history wouldn’t really be useful. So, I’m still waiting for an official response from the anvil team. Hopefully would be a positive one.
I understand with the feeling of this thread, and I agree that the git management could and should be improved, but I also remember when the commits were really too many, there were more empty commits than commits with actual changes, and yet it was already useful. Today the version history has been improved a lot and it’s even more useful.
But I agree that having more control over it would help.
Yes, having an official feedback would be nice, better than us speculating on how it works and how it could be improved. (They may tell us how it works, they are unlikely to tell us how it could be improved, because no serious software company would do that).
