Hello! I love shotcut and used it for several personal projects. Today I encountered a crash. I didn’t worry too much as I save frequently, but then I noticed I had made a big mistake before my last save, and that mistake was unrecoverable.
Later I checked the mlt file and noticed it’s a well-formatted XML. Great, like previously mentioned How I use git to save my work in ShotCut I can use git to manage my project. But for non-programmers, they are not supposed to learn git for using shotcut reliably.
My question is do you consider it a good idea to have built-in git integration? Something like what PyCharm and VSCode provide, but only focus on a smaller subset of git functionalities. So that whenever user saves, it automatically commits.
I don’t think this is a good idea, the shortcut aims to be simple for the user and doesn’t pass sensitive data anywhere. Integration with git implies registration on this site, which means that these are unnecessary actions for the user, you will have to create a complex system of authorization and integration. The free git plan is always public, that is, all your projects will see the entire Internet in public access, are you sure that you want this? You can make private pages on git only on a paid basis, you are unlikely to be willing to pay for a tariff if you have chosen a free video editor.
I think he means only using it locally, like instead of saving to a regular file, each save is a “commit” so you can see the entire save tree at any point. This is an interesting idea, it would avoid saving as “v2”, “v3” local versions but I suspect it could be rather complicated to implement and show it easily to the average user.
Btw, git is the name of the technology that does the work of versioning. Github is just one of the many sites that does fancy stuff online and provides hosting for git projects. It is by far the most known one so many people make this confusion.
Thanks for the explanation! Yes, I mean local-only.
To satisfy average users, I think we can hide/avoid lots of git’s complexity like branch, stage, stash, etc. Only provide a linear timeline of commits (similar to git reflog), even if a user checkouts a previous commit and starts working on that (which internally creates a new branch).
This is only an immature idea. I’d look into what libgit2 provides and see if I can get my hands dirty on shotcut source code. I have much open source dev experience but never played with Qt.
I have thought about it but rejected it. Git is good for text content and our XML is text, but it not good for normal users to read. Git is good for coders because they can understand difference views and see what will happen with merges. So, those kinds of features are not generally so useful, and for those who can already can do it. The other hurdle is asking for a comment for each new commit, which is bothersome. The counter argument is to automate with a date and time stamp or incrementing number.
I have always advocated that people take advantage of the periodic backup system in their OS, which can already do this form of time-based versioning. Why reinvent that with something that is probably going to be inferior? Also, it is more generally useful beyond Shotcut. Windows has file history, macOS has Time Machine, and GNOME has Deja Dup Backups (duplicity). Some of these can be configured to run hourly, which ought to be good if not perfect.
Integrating git doesn’t necessarily ask users to read anything related to git diff, or perform merge/rebase operations. Users don’t need to know git itself or its existence at all. Git message should be optional in case user does want to log something. All versioning functionalities needed is a timestamp-text pair, so if git is too heavy for it, an sqlite may also fit (though I guess it takes more space for saving history without optimization).
The problems with OS backup system are:
- They are not always enabled by default. It’s too frustrated for users to encounter a crash without expectation. If we can provide better versioning, why teach users lesson by crash and let them use other tools?
- An external hard drive for backup is not free.
- Periodic backup is not as good as save-on-demand. OS doesn’t know my checkpoint, but I do.
Integrating an existing tool that does what is expected is not reinventing wheel. I understand as an OSS there’s no warranty, but I still believe there are more things we can do to relieve the pain of crash for users.
sqlite sounds much more interesting. Less heavy, fewer dependencies, easier to maintain and package cross-platform, more customizable, more transparent to external tools, and it can hold extra path information or hashes for verification as users switch between projects (or crashes).
A database file becomes locked by the application and prevents being able to use it from multiple instances of the app. Git is directory-oriented making it less than suitable not to mention hidden files and directories making it harder for users to manage.
Fair points, just brainstorming. Perhaps the easiest thing might be tweaking the current auto-save feature to use a special filename format:
<HashOfMltProjectFullPath>.<DateTimeStamp>.mlt
On crash recovery or revert request, the list of files matching the hash can be shown as recovery targets.
On Shotcut startup, any file with a modification date older than 30 days could be deleted.
Or, a Backups folder could be part of the project management feature like a per-project proxy folder, and manual file saving would trigger a backup file to be written to that directory.
I have no horse in this race. I have my own backup system already. Just trying to help if someone else finds this feature useful.
Is directory-oriented a bad idea, given the stab files generated by shotcut are already saved in the same directory with the mlt file? If users are used to and accept *.bigsh0t360motion and 1.stab, why they won’t accept .git? Even they delete the .git, that only means history is lost, which is exactly current situation, no worse.
Using git is best with txt files where the line numbering matter like a source code file, .xml is a tree structure where branches is not ordred, so a diff can be very large even if only a single parameter has been changes and can make it very hard to see what is changed.
Auto save is good for crash situation, where the user forgot to save changes for a long period of time, but a user make some changes and save it to the same project file you are out of luck. The best way for solve that is to have a workflow where you save to a new project file when you come to a new step in your workflow, so you can go back to your last good state of your project. The question is always, what kind of backup solution should each application implement or should the users use a system backup solution, so save data in x generations,
IMO this is the most straightforward solution, keep a rolling number of backups (I’d go with 3) every 10 minutes on the clock in the same folder as the original, no need to overcomplicate with git and complete history every save.
1 Like
I don’t think it make sense for users to compare between commits either, nor do I want it to be implemented. What I propose is just
- Whenever save, automatically commits the current mlt file, with an optional commit message.
- Provide a dialog with a list of timestamp for user to switch to. Internally, it checkouts the corresponding commit.
About the large diff, yes it is bigger than it should be, but it’s still smaller than saving the whole mlt file every time. In my current project, I have 17 commits, each builds on a previous one incrementally. The mlt file of the first commit is 160K. The last is 234K. The .git folder takes 588K. Let’s estimate what it takes to have all 17 mlt files saved independently: (160K + 234K)/2*17 = 3349K.
I think the discussion got too much into details without taking into account implementation complexity:
- one option has to include git, implement the versioning considering different OS and corner cases like multiple .mlts in the same folder, permissions, or external changes to the file, an interface to choose/checkout a version etc
- the other one simply rename the current file to append timestamp, create a new file with original name + check if there are too many files already saved
Agree, no need to use git for having the last x generations of the project save, it is just saving a copy in a backup directory somewhere, when the user save the project.
The problem is how it should work, then the user save or on a schedule (once an hour ?) or when the user select a backup to be made.
It is a about the workflow of a user, some users save all the time and ex. 5 gen will only a short periode and will not help you if you messed something up 2 hours ago.
schedule ex. ( 1 hour) will not help you if delete something by mistake and saved it 10 min ago.
So it sometimes better for the user to have a workflow to save there own backup at good points in there workflow and it don’t need any changes i shotcut, just use save as and add a postfix like _01 to your filename and increase the number of each “backup” point
1 Like
This topic was automatically closed after 90 days. New replies are no longer allowed.