Re: Editing files on non-branch-heads
On 4/8/20 7:26 PM, Thomas De Schampheleire wrote: 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. Sure. Showing the warning and allowing the user to confirm would be a good way to move on from a first refusal to edit in an unexpected way. 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. It should be trivial to differentiate if the edit form has a visible or hidden flag indicating "appending on tip-most head", "appending a non-tip-most head and making it tip-most", or "known to introduce additional 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? People with write access will be able to push new branches and heads anyway. My main concern is to make sure the UI nudge towards the simple non-lossy "append-only on tip-most head". /Mads ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: Editing files on non-branch-heads
El mié., 8 abr. 2020 a las 17:36, Mads Kiilerich () 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 ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: Editing files on non-branch-heads
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
