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

From: John Keeping <[email-masked]>
Date: Mon, 25 Mar 2013 10:57:32 +0000

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