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