Editing files on non-branch-heads

[Thomas De Schampheleire]

El mié., 8 abr. 2020 a las 17:36, Mads Kiilerich
(<mads at kiilerich.com>) escribió:
>
> 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".

Thanks for clarifying.

>
> 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?

Our use case is to allow it from any revision. We don't mind and
understand that this could create new heads.

>
> 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.

A confirmation question when starting an edit off of a non-head
revision is perfectly acceptable for us.

When a user starts editing on a head but then a new commit on top of
that head is pushed before the user finishes editing, should result in
a similar confirmation question as above, I think, and not necessarily
a refusal to continue. Because I don't think we can differentiate
whether a user 'intentionally' started from a head, or that the
revision they wanted to edit just happens to be a head.

So based on the discussion so far, it seems you would not add a
per-repo setting that states whether multi-heads are allowed, but
rather trust the users with write access to the repo to correctly
understand and respond to the confirmation message to be added.
Correct?

Thanks,
Thomas