On Tue, May 28, 2013 at 11:57:08AM -0700, Junio C Hamano wrote:
> John Keeping <j...@keeping.me.uk> writes:
> > Yeah, the commit message is still quite focused on the end effect of
> > copying files back. But that's not what's being changed here.
> > In my suggested commit message I tried to make it clear that we're
> > changing when we decide to copy a file across to the temporary tree.
> > This has the beneficial (side-)effect of changing the set of files we
> > consider for copying back into the working tree after the diff tool has
> > been run.
> I actually think the effect of copying files back _is_ the primary
> motivation of this change, and stressing that end effect is a much
> better description. After all, if the working tree files do not
> have any difference from the RHS of the comparison, copying from the
> working tree and stuffing the $rsha1 to the RHS temporary index and
> running "checkout -f" should produce identical temporary directory
> for the user to start viewing.
> The _only_ difference in behaviour before and after this patch that
> matters to the end user is if that path is in @working_tree, which
> is returned to @worktree of dir_diff sub to be later copied back,
> no? I would view this change as a mere means, an implementation
> detail, to achieve that end of stuffing more paths in the @worktree
I agree with this, but like you I found it confusing that the patch
touched code seemingly unrelated to copying files back. I went toward
describing the patch more literally and giving the motivation in the
final paragraph. Your message below is better, but I think it needs to
say that the set of files considered for copying back is the set that is
copied across to begin with.
> difftool --dir-diff: allow changing any clean working tree file
> The temporary directory prepared by "difftool --dir-diff" to
> show the result of a change can be modified by the user via
> the tree diff program, and we try hard not to lose changes
> to them after tree diff program returns to us.
> However, the set of files to be copied back is computed
> differently between --symlinks and --no-symlinks modes. The
> former checks all paths that start out as identical to the
> working tree file, while the latter checks paths that
> already had a local modification in the working tree,
> allowing changes made in the tree diff program to paths that
> did not have any local change to be lost.
> or something. This invites a few questions, though.
> - By allowing these files in the temporary directory to be
> modified, aren't we making the user's life harder by forcing them
> to handle "working tree file was already modified, made different
> changes in the temporary directory, now these changes need to be
> consolidated" case?
> - When comparing two revisions, e.g. "--dir-diff HEAD^^ HEAD^",
> that checks out (via $rsha1 to "checkout -f" codepath) a blob
> that does not match what is in the working tree of HEAD to the
> temporary directory, we still allow modifications to the copy in
> the temporary directory, but what can the user do with these
> changes that are _not_ based on HEAD, short of checking out HEAD^
> and apply the difference first?
> I still cannot shake this nagging feeling that giving a writable
> temporary directory might have been a mistake in the first place.
> Perhaps it may be a better design to make the ones that the user
> shouldn't touch (or will lead to the above confusion) read-only,
> while the ones that match the working tree read-write?
My ideal scenario would be that we only allow users to edit files when
they are comparing against the working tree, but that would require
git-difftool to fully understand all git-diff options since it just
passes through any it doesn't recognise. I don't think there's an easy
way to do that, which leaves us with this confusing situation.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html