Re: [PATCH v2 2/3] t7800: fix tests when difftool uses --no-symlinks
- From
John Keeping <john@keeping.me.uk>
- Date
- Mar 25, 2013, 10:57 UTC
- Message-ID
- <20130325105731.GE2286@serenity.lan>
- In-Reply-To
- <CAJDDKr7Uz44TQ8y2jpjhNadWUCD5Mo=GLdaLLh99eENARQSwcw@mail.gmail.com>
On Sun, Mar 24, 2013 at 02:29:40PM -0700, David Aguilar wrote:
Show 8 quoted lines
> 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?
Show 11 quoted lines
> 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