Re: [PATCH v2 2/3] t7800: fix tests when difftool uses --no-symlinks

On Sun, Mar 24, 2013 at 02:29:40PM -0700, David Aguilar wrote:

This makes me wonder whether the modifiable mode should be made
more explicit, either in the documentation or via a flag.

Imagine if --dir-diff also honored --edit and --no-edit flags.

Right now --edit is the default.  If we had foreseen these various
edge cases and unintended copy-backs then we may have initially
chosen --no-edit as the default, but that's not really my point.

I view --symlinks as the default, which avoids most of this pain ;-)
I guess we're talking about three different "working tree files" modes
here: symlink, copy-copyback and copy-readonly.

I wonder if anyone uses --no-symlinks when they are not forced to by
their operating system?  What is the use case if they do?

What I'm thinking is that it might be good for the tool to
learn --edit/--no-edit so that the symlink/copy-back heuristic
can be documented alongside that option.  Users can then know
what to expect when using this mode.  --no-edit would also be
faster since it can avoid all these extra steps.

It could also learn "difftool.dirDiffEditable" to control the
default, which would eliminate the pain in needing to supply
the flag on every invocation.

What do you think about officially supporting a read-only mode?

How would that interoperate with symlink mode?  Should --no-edit imply
--no-symlinks or does the --[no-]edit option only have an effect if
--no-symlinks is in effect?

I don't think this is the first time this idea has been suggested, so
that's some indicator that it's a good idea.  I'm not sure about
--edit/--no-edit for this though.  The behaviour isn't really similar to
the way that option works with git-commit, git-merge, etc.  I don't have
a better suggestion at the moment though.


John