Johannes Sixt writes:
> Am 3/24/2013 16:15, schrieb John Keeping:
> ...
>> +for my $file (keys %worktree) {
>> next if $symlinks && -l "$b/$file";
>> next if ! -f "$b/$file";
>>
>> -my $diff = compare("$b/$file", "$workdir/$file");
>> -if ($
David Aguilar writes:
> 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 case
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
On Mon, Mar 25, 2013 at 08:41:59AM +0100, Johannes Sixt wrote:
> Am 3/24/2013 16:15, schrieb John Keeping:
> > Subject: [PATCH] difftool: don't overwrite modified files
> >
> > After running the user's diff tool, git-difftool will copy any files
> > that differ between the working tree and the tem
Am 3/24/2013 16:15, schrieb John Keeping:
> Subject: [PATCH] difftool: don't overwrite modified files
>
> After running the user's diff tool, git-difftool will copy any files
> that differ between the working tree and the temporary tree. This is
> useful when the user edits the file in their diff
On Sun, Mar 24, 2013 at 5:36 AM, John Keeping wrote:
> On Sat, Mar 23, 2013 at 10:19:36PM -0700, Junio C Hamano wrote:
>> > In the longer term, difftool probably needs to learn to warn the user
>> > instead of overwrite any changes that have been made to the working tree
>> > file.
>>
>> Questiona
On Sun, Mar 24, 2013 at 09:31:45AM -0400, Matt McClure wrote:
> On Sun, Mar 24, 2013 at 8:36 AM, John Keeping wrote:
> > In the
> > non-symlink case I think a user might find it surprising if the
> > (unmodified) file used by their diff tool were suddenly copied over the
> > working tree wiping ou
On Sun, Mar 24, 2013 at 8:36 AM, John Keeping wrote:
> In the
> non-symlink case I think a user might find it surprising if the
> (unmodified) file used by their diff tool were suddenly copied over the
> working tree wiping out the changes they have just made.
That's exactly what I was describing
On Sun, Mar 24, 2013 at 1:19 AM, Junio C Hamano wrote:
> Admittedly I do not use difftool myself, and I have long assumed
> that difftool users are using the tools to _view_ the changes, but
> apparently some of the tools let the user muck with what is shown,
> and also apparently people seem to l
On Sat, Mar 23, 2013 at 10:19:36PM -0700, Junio C Hamano wrote:
> > In the longer term, difftool probably needs to learn to warn the user
> > instead of overwrite any changes that have been made to the working tree
> > file.
>
> Questionable.
>
> Admittedly I do not use difftool myself, and I hav
On Sat, Mar 23, 2013 at 9:31 AM, John Keeping wrote:
> 1) the shell opens "output" to redirect the difftool output
> 2) difftool copies the empty "output" to the temporary directory
> 3) difftool runs "ls" which writes to "output"
> 4) difftool copies the empty "output" file back over the output o
John Keeping writes:
> When 'git difftool --dir-diff' is using --no-symlinks (either explicitly
> or implicitly because it's running on Windows), any working tree files
> that have been copied to the temporary directory are copied back after
> the difftool completes.
>
> Because an earlier test u
When 'git difftool --dir-diff' is using --no-symlinks (either explicitly
or implicitly because it's running on Windows), any working tree files
that have been copied to the temporary directory are copied back after
the difftool completes.
Because an earlier test uses "git add .", the "output" file
13 matches
Mail list logo
