Editing files on non-branch-heads

[Mads Kiilerich]

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