On 4/8/20 4:23 PM, Thomas De Schampheleire wrote:
Hi,
We noticed that the 'Edit' button on the files interface, e.g.
/repo/files/branch/pathtofile.txt
is only clickable if you are viewing the file at the tip revision of a branch.
We would like to be able to edit a file at a non-tip revision, and
would thus like to lift that restriction.
See
https://kallithea-scm.org/repos/kallithea/files/default/kallithea/templates/files/files_source.html#L33
I understand this for single-headed repos, but our review repo is
multi-headed and writable by all developers. Everyone just pushes
their changes for review to that repo.
How do you think we should do it in an acceptable way for upstreaming?
Should it be a per-repository setting whether editing on non-tip is
allowed? Or something else?
First a clarification to make the back story explicit: the official
Mercurial terminology is that repositories have a global "tip" revision,
while branches have "heads". The branch names designates the "tipmost
open branch head" - see "hg help revisions". Currently, files can only
be edited if committing on top of the "tipmost open branch head".
When a local commit operation creates a new branch head on an existing
branch head, Mercurial shows a "created new head" informational warning.
The current Kallithea limitation avoids that and might prevent users
from doing something they didn't intend.
Is your use case to allow edits/branch-offs from any revision, or to
allow edits on top of branch heads that not are tipmost?
I think it would be fine to somehow allow commits on "heads that not are
tipmost" ... and perhaps also any other revision.
I think it would be nice to get some kind of explicit confirmation from
the user if an edit wouldn't be appending on top of the "tipmost head"
but create a new tip that dropped some of the changesets from the
previous head. (I don't know if it should be significantly different for
commits that will branch off a non-head revision or be on top of
"non-tipmost branch head" or on top of closed heads - perhaps not.)
A big warning next to the "edit" button would perhaps be enough. But
perhaps also show it when saving the edit.
Also, we should consider the case where a user intentionally starts
editing on top of "tipmost head", but someone else edits or pushes
before saving. I think that saving that edit should fail on the server
side, instead of silently letting the user do something unintended.
/Mads
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
