On Thu, Mar 14, 2013 at 09:43:00AM +, John Keeping wrote:
On Wed, Mar 13, 2013 at 09:45:47AM -0700, Junio C Hamano wrote:
Does the temporary checkout correctly apply the smudge filter and
crlf conversion, by the way? If not, regardless of the topic in
this thread, that may want to be
John Keeping j...@keeping.me.uk writes:
The path passed to get_stream_filter is only used to decide what filters
apply to the file, so shouldn't it be using ce-name and not path
for the same reason that the call to convert_to_working_tree() further
down the same function does?
Correct and
On Tue, Mar 12, 2013 at 5:17 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 12, 2013 at 04:48:16PM -0600, Matt McClure wrote:
On Mar 12, 2013, at 4:16 PM, Junio C Hamano gits...@pobox.com wrote:
Matt McClure matthewlmccl...@gmail.com writes:
* If you are comparing two trees, and
David Aguilar dav...@gmail.com writes:
The implementation of Junio's suggestion is relatively straightforward
(this is untested, although t7800 passes, and can probably be improved
by someone better versed in Perl). Does this work for your original
scenario?
This is a nice straightforward
Junio C Hamano gits...@pobox.com writes:
David Aguilar dav...@gmail.com writes:
The implementation of Junio's suggestion is relatively straightforward
(this is untested, although t7800 passes, and can probably be improved
by someone better versed in Perl). Does this work for your original
On Wed, Mar 13, 2013 at 09:45:47AM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
David Aguilar dav...@gmail.com writes:
The implementation of Junio's suggestion is relatively straightforward
(this is untested, although t7800 passes, and can probably be improved
John Keeping j...@keeping.me.uk writes:
git-hash-object(1) implies that it will apply the clean filter and EOL
conversion when it's given a path to a file in the working tree (as it
is here). Is that not the case?
Applying clean to smudged contents _ought to_ recover clean version,
but is
On Wed, Mar 13, 2013 at 10:40:55AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git-hash-object(1) implies that it will apply the clean filter and EOL
conversion when it's given a path to a file in the working tree (as it
is here). Is that not the case?
John Keeping j...@keeping.me.uk writes:
On Wed, Mar 13, 2013 at 10:40:55AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git-hash-object(1) implies that it will apply the clean filter and EOL
conversion when it's given a path to a file in the working tree (as it
On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure matthewlmccl...@gmail.com wrote:
On Tuesday, November 27, 2012, David Aguilar wrote:
It seems that there is an edge case here that we are not
accounting for: unmodified worktree paths, when checked out
into the temporary directory, can be edited
On Tue, Mar 12, 2013 at 12:09 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 12, 2013 at 02:12:29PM -0400, Matt McClure wrote:
On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure matthewlmccl...@gmail.com
wrote:
Your thoughts on the change?
Please include the patch in your message so that
David Aguilar dav...@gmail.com writes:
Interesting approach. While this does get the intended behavior
for difftool, I'm afraid this would be a grave regression for
existing git diff --raw users who cannot have such behavior.
The 0{40} in RHS of --raw output is to say that we do not know
John Keeping j...@keeping.me.uk writes:
How about something like --symlink-all where the everything in the
right-hand tree is symlink'd?
Does it even have to be conditional? What is the situation when you
do not want symbolic links?
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Mar 12, 2013 at 01:39:17PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
How about something like --symlink-all where the everything in the
right-hand tree is symlink'd?
Does it even have to be conditional? What is the situation when you
do not want
John Keeping j...@keeping.me.uk writes:
Does it even have to be conditional? What is the situation when you
do not want symbolic links?
When you're not comparing the working tree.
OK, so what you want is essentially:
* If you see 0{40} in diff --raw, you *know* you are showing the working
On Tue, Mar 12, 2013 at 5:06 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 12, 2013 at 01:39:17PM -0700, Junio C Hamano wrote:
What is the situation when you do not want symbolic links?
When you're not comparing the working tree.
If we can reliably say the RHS is the working tree
On Tue, Mar 12, 2013 at 5:43 PM, Matt McClure matthewlmccl...@gmail.com wrote:
On Tue, Mar 12, 2013 at 5:06 PM, John Keeping j...@keeping.me.uk wrote:
is it sufficient to say
there is no more than one non-option to the left of '--' and '--cached'
is not among the options?
An alternative
Matt McClure matthewlmccl...@gmail.com writes:
An alternative approach would be to reuse git-diff's option parsing
and make it tell git-difftool when git-diff sees the working tree
case. At this point, I haven't seen an obvious place in the source
where git-diff makes that choice, but if
On Mar 12, 2013, at 4:16 PM, Junio C Hamano gits...@pobox.com wrote:
Matt McClure matthewlmccl...@gmail.com writes:
An alternative approach would be to reuse git-diff's option parsing
I do not think you want to go there. That wouldn't solve the third
case in my previous message, no?
I
On Tue, Mar 12, 2013 at 04:48:16PM -0600, Matt McClure wrote:
On Mar 12, 2013, at 4:16 PM, Junio C Hamano gits...@pobox.com wrote:
Matt McClure matthewlmccl...@gmail.com writes:
* If you are comparing two trees, and especially if your RHS is not
HEAD, you will send everything to a
On Tuesday, November 27, 2012, David Aguilar wrote:
It seems that there is an edge case here that we are not
accounting for: unmodified worktree paths, when checked out
into the temporary directory, can be edited by the tool when
comparing against older commits. These edits will be lost.
On Mon, Nov 26, 2012 at 12:23 PM, Matt McClure
matthewlmccl...@gmail.com wrote:
I'm finding the behavior of `git difftool -d` surprising. It seems that it
only uses symlinks to the working copy for files that are modified in the
working copy since the most recent commit. I would have expected
22 matches
Mail list logo
