Editing files on non-branch-heads
Mads Kiilerich
mads at kiilerich.com
Thu Apr 9 00:34:57 UTC 2020
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
More information about the kallithea-general
mailing list