Notes on Repo Updates

[vladmandic]

This is to document current update process as well as to solicit feedback

if you'd like it changed, I'm open to it, but please read through notes first

When updating any github repo, there are two possible way:

1. git pull
2. git pull --autostash --rebase

If you do webui --upgrade, it performs couple of checks, but at the end its pull with rebase.
If you want to do a manual git pull that is totally fine, then you don't need to use --upgrade flag at all.

Any file marked for exclusion in .gitignore work the same for both ways.
So if something is listed there, it wont be touched by update.
This includes all models, configuration files, user installed extensions, etc.

Behavior of git pull:

• If any existing file is modified or deleted, it will fail
• If any new file is added, it is ignored

Behavior of git pull with rebase:

• If any file is modified/deleted/added, it will be reset

Why did I choose pull with rebase as default?

• If a normal user modifies a file by mistake, his future git pull would fail otherwise.
  For example, even something as simple as editing webui.bat instead of creating webui-user.bat (which is on ignore list)
  would cause pull to fail
  Advanced users can always run manual git operations, so this improves general quality-of-life for normal users
  I've already seen large number of users opening issues with "my git pull failed" and I don't want to end up with thousands of ignored issues simply because user is not aware of how git works (nor he should be)
• If a misbehaving extension (intentionally or unintentionally) modifies files in core repo.
  For example, several extensions basically copy their code from /extensions to /scripts which is a folder for core scripts only and should never be touched by a script.
  I've already seen several such extensions. And since they modify files in core repo, they cannot even be uninstalled.
  Deleting them from /extensions doesn't help as they've already performed modifications.
  Running pull with rebase ensures that repo is always returned to known good state

But...There are bad sides to this as well:

• If a user adds a file/folder to repo folder and that file/folder is NOT in ignore list, it will also be reset on update.

So....What is the desired behavior?

• Ignore bad situations and never touch files?
• Leave behavior as-is?
• Leave behavior (mostly) as-is, but add more files/folders to ignore list?

[TKS4]

I like your take, by far the safest in terms of people editing things going off of older ideas from the 1111 UI. Would suck to keep git pulling as told, only to never realize a certain file isn't updating and causing all these sorts of problems. If people are willy nilly changing things, then they should be ready to at least do some research; provided that information like this is added to the main page, as I myself wasn't aware this was how things were working, though I'm fine since I don't really touch much of anything, and am versed with basics like .gitignore's functionality.

So yeah I say keep it like this, and keep this information available on the front page and/or the wiki (so people giving advice for people's problems, can also refer to others to this bit of information).

[Tillerz]

That! It always needs to update its own stuff to prevent people wondering why stuff is breaking. If people lose things like a script, they will find out pretty early, and learn from it (but you fixed that one usecase already, so all good).

[MoreColors123]

However this turns out: I modified some parameters in my ui-config.json, so if I update with rebase, I'll lose those right? What can I do about that? Sorry, not a dev.
I adjusted some params in that file just this week in order to save some clicks when starting up the repo.

Thanks for your work!

[vladmandic]

@MoreColors123 no, like i said, any standard configuration files (and quite a few else) will NOT be reset.
that includes ui-config.json

[lzardy]

It is hard to decide for everyone if there should be a single behavior. Ideally we would let you choose on first install to select an update method, or with a launch.py parameter. Such as "Update with reset? Y/N" and --reset.

[vladmandic]

Ideally we would let you choose on first install

and you'd end up at the start line as most users won't know what they're answering without printing half a page of explaination.

i'm all for giving user options - if we have answers when something bad happens.
for example, i can add --update (which would do pull only) in addition to --upgrade (which does pull with rebase)
but who would answer all the issues with "why is my update not working"?
and how would you avoid scenarios where badly behaving extension copies itself to /scripts so you cannot disable it or uninstall it even if its not working (i'll give you example of a popular one - Latent Diffusion)

interactive prompt is not an option as most users use this via shortcuts.

[lzardy]

Ideally we would let you choose on first install

and you'd end up at the start line as most users won't know what they're answering without printing half a page of explaination.

i'm all for giving user options - if we have answers when something bad happens. for example, i can add --update (which would do pull only) in addition to --upgrade (which does pull with rebase) but who would answer all the issues with "why is my update not working"? and how would you avoid scenarios where badly behaving extension copies itself to /scripts so you cannot disable it or uninstall it even if its not working (i'll give you example of a popular one - Latent Diffusion)

interactive prompt is not an option as most users use this via shortcuts.

It seems then that the situation is an experience blockage. The prompt request is out of question.
A command option would be the safe bet. However like you say there may be new user problems.
Correct me if I am wrong, but if you git pull separately, then launch, will dependencies update automatically?
The final option to get rid of new people using a risky command option is to just let people update manually like above.
In this way we do not assume responsibility, only pseudo-support the manual update.

[vladmandic]

Correct me if I am wrong, but if you git pull separately, then launch, will dependencies update automatically?

doing manual git pull is safe. my launcher scans dependencies as well as file timestamps and triggers installation as needed. you actually see line in console log saying "Verifying requirements"
if no changes are detected to dependencies or extensions, you'll see "No changes detected: Quick launch active"

[xedis]

Initially I was jumping back and forth between this fork and main a111, switching venv's etc. I haven't jumped back in over a week however. You are a machine man, a machine who has shown a great deal of patience with the masses flocking here.

I have to thank you for your choice of methodology, when I was updating on the main branch, my UI was constantly being altered and it was pretty triggering. Over here, it happens rarely, usually the result of a feature being moved around, which is fine in my book.

Once, twice, things broke but this is too be expected and isn't much different from my OS :P
Each of those times, by the time I was done confirming it was a bug in the app and not my system, it was fixed.

I vote leave as is, each person can add files to .gitignore as they make modifications or changes. If they are confident enough to make those changes, they should be able to add the file to the .gitignore list. I guess only issues arise if core functionality is being modified but if that's the case they should have their own fork as it is no?

I'm on board with whatever though 💯

[vladmandic]

Once, twice, things broke but this is too be expected and isn't much different from my OS

More than once or twice, but i'm still in run-before-walk mode. Once repo stabilizes (and its getting close to that), I'll move to dev/master approach and update master periodically instead with every commit going straight to master. its already being used for some larger feature branches, but goal is to use that concept across the board.