On Tue, Apr 10, 2012 at 4:06 PM, Matt McClure <matthewlmcclure@xxxxxxxxx> wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html