Re: [PATCH v2] contrib: added git-diffall

From: David Aguilar <davvid@gmail.com>
Date: Apr 11, 2012, 08:38 UTC
Message-ID: <CAJDDKr47BZ=QE_nUqAoFJTRTBUxMHD2QwmqpGYrXb3q1hfyAHA@mail.gmail.com>
In-Reply-To: <loom.20120411T010200-132@post.gmane.org>

On Tue, Apr 10, 2012 at 4:06 PM, Matt McClure <matthewlmcclure@gmail.com> wrote:

Show 24 quoted lines

> Tim Henigan <tim.henigan <at> gmail.com> writes:
>
>> >> +     do
>> >> +             cp "$file" "$git_top_dir/${file#$tmp/$right_dir/}"
>> >> +     done
>> >> +fi
>> >
>> > This will copy new files created in $right_dir.  Is that intended?
>>
>> hmmm...that was not intended.  If would be odd for the user to create
>> new files in this tmp directory, but if the diff tool automatically
>> generates any files then this could result in unwanted files.
>
> I think more generally, I would prefer if either side of the comparison is the
> working copy that the temp directory on that side be populated with symlinks.
>
> A particularly bad failure mode of the copy-back approach is:
>
> git diffall --copy-back
> # while my diffall tool is running, I edit the file somewhere else.
> # quit my diffall tool
> # --> my edits in the other tool are overwritten by diffall
>
> Editing the files in place via symlinks would resolve that.

I had a similar idea but didn't mention it because Windows came to mind. I always want to say, "darn it, this code would be so much easier if we could just ignore Windows", but that's not very helpful.

I'd be happy with a runtime platform check where the copy back is only done on Windows. Everyone else can enjoy symlinks.

Reading between the lines that could be interpreted as, "well, that copy back code is no good and *we* don't want to use it, but it's okay for Windows users", which is slightly dangerous because we'd always be running the symlink code path and wouldn't hit problems with the other path.

So I'm torn. I think symlinks are a great idea, but Windows drives us towards the less-than-ideal solution. I want the best solution possible. Do we just accept that the copy-back code is simply the cost of supporting Windows and keep both code paths around? I would not be opposed to that if the result is a more robust user experience.

-- 
David