- 1 - I made `bootstrap` a clean branch-creation step from `BASE_TAG`, separated fetch and sync into explicit compare/release-target/custom actions, added `UPSTREAM_RELEASE_TARGET_REF`, and updated the built-in help so the recommended workflow matches the current menu structure.
- 2 - I hardened recovery so rollback, restore-point, restore-snapshot, restore-stash, and restore-deletion correctly preserve or clean script-managed refs, maintenance branches, state files, backup branches, and snapshots, including rollback from the original entry branch after a bootstrap-created maintenance branch, cleanup of legacy restore-point leftovers, and removal of the paired `backup/maint-*` Git Graph marker when a saved snapshot is deleted.
- 3 - I finalized the interactive UX by keeping a self-updating runtime copy in `/tmp`, persisting the last-used settings in `/tmp/.maintain-custom-release.env`, and reorganizing the menu into `Manual Backups >`, `Fetch upstreams >`, `Sync >`, `Rollback >`, and `Restore >` submenus, including `Delete Restore >` with numbered stash and snapshot selection, with numbered selections, `b`/`B` or `Enter` for Back, correct return-to-parent behavior from every submenu, and `0` for Exit.
- 1 - I made `bootstrap` a clean branch-creation step from `BASE_TAG`, separated fetch and sync into explicit compare/release-target/custom actions, added `UPSTREAM_RELEASE_TARGET_REF`, and updated the built-in help so the recommended workflow matches the current menu structure.
- 2 - I hardened recovery so rollback, restore-point, restore-snapshot, and restore-stash correctly preserve or clean script-managed refs, maintenance branches, state files, backup branches, and snapshots, including rollback from the original entry branch after a bootstrap-created maintenance branch and cleanup of legacy restore-point leftovers.
- 3 - I finalized the interactive UX by keeping a self-updating runtime copy in `/tmp`, persisting the last-used settings in `/tmp/.maintain-custom-release.env`, and reorganizing the menu into `Backups >`, `Fetch upstreams >`, `Sync >`, `Rollback >`, and `Restore >` submenus with numbered selections, `b`/`B` or `Enter` for Back, and `0` for Exit.
- Added a persistent `/tmp/.maintain-custom-release.env` settings file so the last used configuration survives script restarts.
- Moved `bootstrap` ahead of the explicit fetch actions in the interactive menu, removed automatic fetching from `bootstrap` and `plan`, and split both the fetch and sync flows into separate compare-branch and release-target actions while clarifying that custom commits are cherry-picked from oldest to newest.
Added - Added an interactive custom-release maintenance helper for stable patch lines.
Added - Added a dedicated safe upstream import helper based on `cherry-pick`.
Added - Added an interactive custom-release maintenance helper for stable patch lines.
Added - Added a dedicated safe upstream import helper based on cherry-pick.
Added - Added an interactive custom-release maintenance helper for stable patch lines.
- 5 - I improved conflict reporting so package.json conflicts show the upstream scripts block, the conflicting commit side, and the current branch working-tree side, and the final dry-run summary now includes the total conflict-step count, the local commits that conflicted, and the unique conflicted files.
- 1 - I renamed the updater to `.update-gitea.sh`, documented its purpose and ordered usage steps, and added an interactive menu plus direct commands for `sync`, `dry-run`, `fetch`, `backup`, `status`, `list-backups`, `rollback`, `restore-stash`, and `clean-dry-run`.
- 2 - I hardened real update actions so they verify repository state, enforce or offer safety backups before modifying the branch, stash tracked and untracked local changes, record sync state inside `.git`, and support rollback to the exact saved starting commit or to a selected backup branch while preserving recoverability of local changes.
- 3 - I implemented a reusable dry-run workspace under `.git/.update-gitea-dry-run`, added cleanup for both that workspace and legacy temporary dry-run directories, and made dry-run collect and report all detected rebase conflict steps without modifying the real repository.
- 4 - I improved conflict reporting so package.json conflicts show the upstream scripts block, the conflicting commit side, and the current branch working-tree side, and the final dry-run summary now includes the total conflict-step count, the local commits that conflicted, and the unique conflicted files.
- 1 - I added an explicit installer checkbox for importing sensitive secrets from `app.ini` in `templates/install.tmpl`.
- 2 - I extended the installer form, submit pipeline, and final config writer so the optional import reuses `LFS_JWT_SECRET`, `INTERNAL_TOKEN`, and `oauth2.JWT_SECRET` from the uploaded `app.ini` instead of generating new values, including a submit-time fallback that re-reads the uploaded file if the checkbox was enabled after the first auto-import.
- 3 - I finalized secret resolution for both direct values and `LFS_JWT_SECRET_URI` / `INTERNAL_TOKEN_URI` / `JWT_SECRET_URI` file-based references, and added regression coverage for direct imports, URI-based imports, the real `POST /import_app_ini` flow, and the persisted `app.ini` output.
- 1 - I updated `routers/install/install.go` so `BrandingUseSharedAssets` starts as enabled on the install form, making `Use the same logo files for favicon assets` checked by default.
- 1 - I added an `Import Existing Configuration` section at the top of `templates/install.tmpl` with an `app.ini` upload control that imports automatically as soon as a file is selected, without a separate `Load app.ini` button.
- 2 - I kept the dedicated installer route `POST /import_app_ini` in `routers/install/routes.go`, but the page now posts to it via `fetch` and applies the imported values back into the existing form with `DOMParser`, so the browser is not visibly navigated to `/import_app_ini` and the page scripts are not re-executed.
- 3 - In `routers/install/install.go`, I factored the installer defaults into reusable helpers, added `app.ini` upload parsing with size/error handling, and mapped the imported config into the existing install form fields for database, general server paths, mailer, registration, OpenID, security, and admin policy settings.
- 4 - I added installer locale strings in both `options/locale/locale_en-US.json` and `options/locale/locale_ro-RO.json` for the new import UI, success message, and import errors, and the success flash now auto-dismisses after 5 seconds.
- 5 - I added regression coverage in `routers/install/routes_test.go` for the new upload control and the config-to-form mapping behavior.
- 1 - I wrapped the forced-change password field in `templates/user/auth/change_passwd_inner.tmpl` with the shared `js-password-toggle-group`, reusing the existing eye-toggle logic and show/hide labels.
- 2 - I wired the confirm-password field into the existing toggle sync behavior so revealing the new password hides the confirm field and keeps it synchronized like the other password-update forms.
- 1 - I extended `POST /user/sign_up` in `routers/web/auth/auth.go` for existing active local accounts created by an admin when `username` and `email` match, while explicitly leaving pending admin invitations on their existing flow.
- 2 - If password is correct, the user is now authenticated into that existing account; when `MustChangePassword` is enabled, the flow redirects directly to `/user/settings/change_password`, otherwise it follows the normal post-auth redirect.
- 3 - If password is incorrect, the flow now redirects to `/user/forgot_password?email=<email>` and shows a warning to use account recovery plus check Spam/Junk.
- 4 - I added the locale key `auth.admin_notify_recover_password_spam_hint` in both `options/locale/locale_en-US.json` and `options/locale/locale_ro-RO.json`.
- 5 - I added regression tests in `routers/web/auth/auth_test.go` for normal sign-in, forced change-password redirect, wrong-password recovery redirect, and a guard that the admin-invitation flow still redirects to `/user/invitation`.
- 1 - I finalized the installer `Branding` section with optional uploads for `logo.svg`, `logo.png`, `loading.png`, `favicon.svg`, and `favicon.png`, including clear format/size guidance plus a shared-assets checkbox for using one SVG and one PNG upload for both logo and favicon.
- 2 - I implemented backend validation and persistence for all branding uploads in `routers/install/install.go` (expected type checks, 1 MB limit, square PNG with minimum 64x64) and save accepted overrides under `custom/public/assets/img/`.
- 3 - I completed the runtime behavior so uploaded branding files override built-in assets through layered serving, `logo.svg` is mirrored to `gitea.svg` for legacy lookups, post-install progress prefers a custom `loading.png`, and the shared-assets mode hides favicon fields while relabeling logo fields to `Logo & Favicon SVG/PNG`.
- 4 - I manually updated Romanian locale wording for the final branding texts and labels.
petru