On Fri, Feb 25, 2022 at 12:29 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Mark Phippard wrote on Fri, Feb 25, 2022 at 10:39:13 -0500: > > On Fri, Feb 25, 2022 at 10:19 AM Daniel Shahaf <d...@daniel.shahaf.name> > > wrote: > > > > > > Nathan Hartman wrote on Thu, 24 Feb 2022 23:44 +00:00: > > > > On Thu, Feb 24, 2022 at 2:33 PM Mark Phippard <markp...@gmail.com> > > > > wrote: > > > >> > > > >> On Thu, Feb 24, 2022 at 10:51 AM Lorenz <loren...@yahoo.com> wrote: > > > >> > > > >> > just discovered, that merging into a RO file succeeds. > > > >> > I my case the file is RO because of a needs-lock property. > > > >> > So when I try to commit I can't. > > > >> > > > > >> > This effect ist at least annoying. > > > >> > There is a reason why the file is read only. > > > >> > > > >> It is interesting both that it was able to do this and also that this > > > >> has never come up before. I am not sure I can wrap my head around what > > > >> I think should even happen here. There is no way you could be expected > > > >> to obtain locks on these files before merging. > > > > > > Why can't we expect that? > > > > I had not considered your proposal to just lock everything before the > > merge. I agree that would be a solution. I cannot predict user > > reaction because it is hard to know what kind of scale we are talking > > about. > > To be clear, I didn't intend that as a "solution"; only as a "first > approximation workaround", as I said there. > > > When I said we could "not expect" what I was getting at is that it > > would require the user to figure out what files the merge was going to > > modify BEFORE they do the merge and lock those files. That does not > > seem reasonable ... again I did not consider the simpler lock > > everything idea. > > Why wouldn't that be reasonable?
Different people have different tolerance levels. For me, this would be too much to ask and I would question what the tool is really even doing for me and look for alternatives. Mark
