FR/Suggestion: Mark the working copy files as read-only in the filesystem

[ilyagr]

This causes Meld to not allow editing of the working copy pane, which makes sense since those edits are lost.

This makes the dir somewhat harder to remove; https://docs.python.org/3.11/library/shutil.html#rmtree-example might work.

BTW, it might be fine to never allow editing of the working copy with git-meld-index, as the user can just edit the working copy and many other tools allow for doing that while seeing the diff with the index.

[jjlee]

:((( did this cause you to lose any edits?

I'm sure past-me knew about this, but present day me doesn't like it at all and sees it as more bug than feature request.

Thinking through options:

• Read-only: good solid solution but I fear heavyweight and perhaps difficult to make portable even across linux distributions, let alone mac and windows (I've no idea whether git-meld-index works on Windows, but I imagine it wouldn't be too hard to make work, and pretty sure I've run it at work on a mac). Correct me if I'm wrong!

• Obviously an option is just to support updates to the working tree - but to be honest from the feature point of view I don't see myself putting in the work to check that's solid in edge cases, since the majority of the time I'm only interested in editing the index. If somebody else implemented it and did a decent job on adding tests for that I'd be happy to see that though!

• Have you investigated whether meld provides any explicit way to make the left hand side non-editable? I guess it doesn't though, and it would be meld-specific -- at the moment git-meld-index doesn't need to know how to run meld direct: it runs a git command instead which also lets it run tools other than meld. Still I'm not sure anybody uses git-meld-index without meld, so this would probably be a good change if meld supported it.

• Maybe easiest: On meld exit I could compare the updated temp file on the left hand side with the original working tree file, and if there are any differences arrange for the temporary files to stick around somehow and alert the user on the command line to what happened. A hack but one that won't cause any new users to be surprised and lose changes! Do you think that would have saved you lost edits?

[ilyagr]

No, I didn't lose anything, no worries, and thanks for the concern! 😀

I suggested this because that's what https://github.com/martinvonz/jj use this trick. Seems to work OK, even on Mac and Windows; I don't remember whether there were platform-dependent issues (but it uses the Rust library as opposed to Python's).

At a glance, I didn't see a relevant option in meld --help. Potentially, it could be a nice feature for them to add.

The last option is also an option, I agree. I'm not sure it's easier, though.

[ilyagr]

One minor problem the read-only trick does have is if you use Meld's UI to copy entire files. (In one direction, the file will be lost; in the other -- it will be unexpectedly readonly) However, I think people do this rarely, and it will make sense to people if they are used to one of the sides being read-only.

[jjlee]

Ah, you're suggesting changing write access permission on the source files! I heard "read-only" and thought of read-only mount.

That works I see, nice idea, thanks I'll certainly do that

[jjlee]

it will be unexpectedly readonly

I think git only tracks executable permissions not unix-style read/write permissions, so I don't think this is a problem for staging, unless I misunderstand you?