This proposal aims to simplify the development workflow and improve the user experience in the CLT UI by:
- Ensuring users their changes are safe
- Eliminating confusion / bugs around PR creation and committing
- Enabling full undo/redo (
cmd-z / shift-cmd-z) across all files using Git history
- Laying the groundwork for open-sourcing / productizing the UI by removing hardcoded repository logic
Commit & Push Flow
As soon as there is a local change, we commit it to the current branch and push it using --force (to avoid conflicts).
Commit message format:
Updated <file name> [skip ci]
[skip ci] will skip github workflows CI. We don't want it to happen on each microcommit.
“Create PR” Flow
The “Create PR” button becomes just a link to:
https://github.com/manticoresoftware/manticoresearch/compare/<branch name>?expand=1
Branch Selection UX
- Uses Tom Select or smth similar
- All branches are known in advance (no need to fetch them "as you type")
- Shows a hint like "branch-name" to make it clear what's required
- As the user types, it auto-completes existing branches or allows adding a new one
- Pressing Enter confirms the selection
- The branch name stays visible in the input field
- No extra buttons needed
- A GitHub icon on the right opens the branch on GitHub when clicked
Safe Branching Rules
We never allow commits directly to master or main.
If a user tries to save changes to those branches, show a message like:
Create or select a branch first.
Undo / Redo
- Ctrl-z, Ctrl-y, CMD-z, CMD-SHIFT-z triggers undo/redo
- Undo/redo works via Git: we simply checkout the previous or next commit and refresh the page (best if we can scroll to the changed command and highlight it)
- Saving a new change onto an older commit reverts all changes made in the newer commits, adds the new change and makes another commit. Thus, the history remains intact.
Outcome
If implemented, this proposal would:
- Streamline the commit and PR workflows
- Make user actions easily reversible and more predictable
- Prevent accidental changes to protected branches
- Support eventual open-sourcing/productizing the project
FAQ
Q: What if a user already created a PR and is still working on a test? How can they trigger CI?
A: They'll need to do a rebase eventually. That's the right moment. A push --force after rebase will trigger CI.
In most cases though, triggering CI isn't necessary as tests can be run directly in the CLT UI. That's what it's for.
Q: After a remote rebase, how does the branch in CLT UI get updated?
A: We monitor the remote branch. If we detect a newer commit there than in the current one, we update the local branch accordingly.
This proposal aims to simplify the development workflow and improve the user experience in the CLT UI by:
cmd-z/shift-cmd-z) across all files using Git historyCommit & Push Flow
As soon as there is a local change, we commit it to the current branch and push it using
--force(to avoid conflicts).Commit message format:
[skip ci]will skip github workflows CI. We don't want it to happen on each microcommit.“Create PR” Flow
The “Create PR” button becomes just a link to:
https://github.com/manticoresoftware/manticoresearch/compare/<branch name>?expand=1Branch Selection UX
Safe Branching Rules
We never allow commits directly to
masterormain.If a user tries to save changes to those branches, show a message like:
Undo / Redo
Outcome
If implemented, this proposal would:
FAQ
Q: What if a user already created a PR and is still working on a test? How can they trigger CI?
A: They'll need to do a rebase eventually. That's the right moment. A
push --forceafter rebase will trigger CI.In most cases though, triggering CI isn't necessary as tests can be run directly in the CLT UI. That's what it's for.
Q: After a remote rebase, how does the branch in CLT UI get updated?
A: We monitor the remote branch. If we detect a newer commit there than in the current one, we update the local branch accordingly.