text editor selection: follow unix defacto standards #356
Labels
No Label
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind
enhancement
kind
feature
kind/proposal
kind
question
kind
refactor
kind/security
kind/testing
kind/translation
priority/critical
priority/high
priority/low
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/has-backport
status/has-pull
status/needs-backport
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/sdk
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/tea#356
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "plgruener/tea:visual_patch"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently,
tea
only supports the $EDITOR env var to open the user's preferred editor (used for reviewing pull requests).Standard *nix practice is, however, to check for $VISUAL first and only then use $EDITOR as fallback.
This is also done by Git itself, see man git-var(1).
(Actually, the order there is $GIT_EDITOR > core.editor > $VISUAL > $EDITOR > vi)
Maybe we also should change the fallback from
vim
tovi
? (The latter is installed by default on many systems, unlike vim.Yes, that would probably be the safer choice.
Should I open a new PR or edit this one?
@plgruener Just add it here :) Thanks!
support $VISUAL, prefer it over $EDITORto text editor selection: follow unix defacto standardsvi
38b6c826a0@plgruener can you "Update" the branch?
Sorry, I didn't know I had to do anything else other than waiting (for the CI checks and then some of you merging the PR).
You mean rebasing it on top of master? I sure can, but then you'd have to review it again, wouldn't you?
Or do you mean the pending review? I don't know how I can un-request that.
No problem just merge current master into this feature branch, there should be a button ? somewhere called "update branch" witch would do the same
38b6c826a0
toe709df6259
I did, but your CI is still failing.
To clarify, this was not a technical question, but one about workflow and principle. What I meant:
as soon as I modify the PR – either by introducing a new commit, back-merging (with potential merge-conflicts) or rebasing – I instantly invalidate the (already approved) reviews, because I could have introduced another, potentially breaking or malicious, change.
So I was just wondering how you handled that.
Lgtm would still count, since the person who wil merge will have a final look anyway