From: John Keeping <john@keeping.me.uk>
To: David Aguilar <davvid@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Johannes Sixt <j.sixt@viscovery.net>,
Sitaram Chamarty <sitaramc@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH v2 2/3] t7800: fix tests when difftool uses --no-symlinks
Date: Mon, 25 Mar 2013 10:57:32 +0000 [thread overview]
Message-ID: <20130325105731.GE2286@serenity.lan> (raw)
In-Reply-To: <CAJDDKr7Uz44TQ8y2jpjhNadWUCD5Mo=GLdaLLh99eENARQSwcw@mail.gmail.com>
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
next prev parent reply other threads:[~2013-03-25 10:58 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-21 4:03 [PATCH v3 1/4] difftool: silence uninitialized variable warning David Aguilar
2013-02-21 4:03 ` [PATCH 2/4] t7800: update copyright notice David Aguilar
2013-02-21 4:03 ` [PATCH v3 3/4] t7800: modernize tests David Aguilar
2013-02-21 4:03 ` [PATCH v3 4/4] t7800: "defaults" is no longer a builtin tool name David Aguilar
2013-02-21 4:55 ` Junio C Hamano
2013-02-21 5:00 ` Junio C Hamano
2013-02-21 23:31 ` David Aguilar
2013-03-20 9:48 ` [PATCH v3 3/4] t7800: modernize tests Johannes Sixt
2013-03-20 22:59 ` David Aguilar
2013-03-21 7:41 ` Johannes Sixt
2013-03-22 7:13 ` Johannes Sixt
2013-03-22 10:00 ` John Keeping
2013-03-22 11:14 ` Johannes Sixt
2013-03-22 11:53 ` John Keeping
2013-03-22 19:36 ` [PATCH 0/3] Improve difftool --dir-diff tests John Keeping
2013-03-22 19:36 ` [PATCH 1/3] t7800: don't hide grep output John Keeping
2013-03-22 22:32 ` Johannes Sixt
2013-03-22 22:45 ` Junio C Hamano
2013-03-22 19:36 ` [PATCH 2/3] t7800: fix tests when difftool uses --no-symlinks John Keeping
2013-03-22 22:27 ` Johannes Sixt
2013-03-22 22:53 ` Junio C Hamano
2013-03-22 23:05 ` John Keeping
2013-03-23 3:24 ` David Aguilar
2013-03-22 19:36 ` [PATCH 3/3] t7800: run --dir-diff tests with and without symlinks John Keeping
2013-03-22 21:05 ` [PATCH 3/3 v2] " John Keeping
2013-03-23 13:31 ` [PATCH v2 0/3] difftool --dir-diff test improvements John Keeping
2013-03-23 13:31 ` [PATCH v2 1/3] t7800: don't hide grep output John Keeping
2013-03-23 13:31 ` [PATCH v2 2/3] t7800: fix tests when difftool uses --no-symlinks John Keeping
2013-03-24 5:19 ` Junio C Hamano
2013-03-24 12:36 ` John Keeping
2013-03-24 13:31 ` Matt McClure
2013-03-24 15:15 ` John Keeping
2013-03-25 7:41 ` Johannes Sixt
2013-03-25 10:42 ` John Keeping
2013-03-25 21:44 ` [PATCH v2] difftool: don't overwrite modified files John Keeping
2013-03-26 8:38 ` Johannes Sixt
2013-03-26 8:47 ` Johannes Sixt
2013-03-26 9:31 ` John Keeping
2013-03-26 9:53 ` Johannes Sixt
2013-03-26 19:34 ` John Keeping
2013-03-26 20:52 ` Matt McClure
2013-03-26 21:01 ` John Keeping
2013-03-25 16:15 ` [PATCH v2 2/3] t7800: fix tests when difftool uses --no-symlinks Junio C Hamano
2013-03-24 21:29 ` David Aguilar
2013-03-25 10:57 ` John Keeping [this message]
2013-03-25 14:54 ` Junio C Hamano
2013-03-24 13:24 ` Matt McClure
2013-03-24 6:20 ` Eric Sunshine
2013-03-23 13:31 ` [PATCH v2 3/3] t7800: run --dir-diff tests with and without symlinks John Keeping
2013-03-25 7:26 ` Johannes Sixt
2013-03-25 10:35 ` John Keeping
2013-03-25 10:59 ` Johannes Sixt
2013-03-25 11:02 ` John Keeping
2013-03-25 21:50 ` Junio C Hamano
2013-03-26 9:22 ` John Keeping
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130325105731.GE2286@serenity.lan \
--to=john@keeping.me.uk \
--cc=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=jrnieder@gmail.com \
--cc=sitaramc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).