Re: git diff bug?

2013-06-10 Thread Sarma Tangirala
On Mon, Jun 10, 2013 at 8:44 AM, Célestin Matte
celestin.ma...@ensimag.fr wrote:

 Since nobody answered you (publicly at least), I will try doing it myself:
 I think the best thing to do if you want a feature to be added is to
 come with a patch and request for comments on it. Then, people will
 discuss it and decide whether it's worth adding it to git. So yes, you
 can try implementing it - all work is welcome :)

That sounds great. I will try implementing and send out a patch soon!


--
010
001
111
--
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


Re: git diff bug?

2013-06-07 Thread Sarma Tangirala
On Thu, Jun 6, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote:
 Célestin Matte celestin.ma...@ensimag.fr writes:


 But for a two-endpoint diff Porcelain (not the plumbing diff-files,
 diff-index and diff-tree), I do not think it is particularly a bad
 idea to add such a typo-detection feature.

I was wondering if this feature is going to be added and if I could
try implementing it.

--
010
001
111
--
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


Re: git diff bug?

2013-06-06 Thread Célestin Matte
Le 06/06/2013 23:26, Sarma Tangirala a écrit :
 Hello All,
 
 If I did 'git diff HEAD^..HEAD -- file' should git not report some
 kind of warning if it could not match the file? For example, if 'file'
 were infact 'dir/file' and 'file' were unique, would it not be a good
 idea to report that in the present working directory 'file' were not
 found but 'dir/file' were a match?

I don't know any program doing such a thing, and I don't think it is the
role of the program to predict which file the user actually wanted to
provide in the command line.
That would imply looking for files with the same name or a close name in
the current directory and its subdirectories - and maybe even in the
superdirectory? It is hard to decide when you have to stop looking for
the file.

--
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


Re: git diff bug?

2013-06-06 Thread Junio C Hamano
Célestin Matte celestin.ma...@ensimag.fr writes:

 Le 06/06/2013 23:26, Sarma Tangirala a écrit :
 Hello All,
 
 If I did 'git diff HEAD^..HEAD -- file' should git not report some
 kind of warning if it could not match the file? For example, if 'file'
 were infact 'dir/file' and 'file' were unique, would it not be a good
 idea to report that in the present working directory 'file' were not
 found but 'dir/file' were a match?

 I don't know any program doing such a thing, and I don't think it is the
 role of the program to predict which file the user actually wanted to
 provide in the command line.
 That would imply looking for files with the same name or a close name in
 the current directory and its subdirectories - and maybe even in the
 superdirectory? It is hard to decide when you have to stop looking for
 the file.

The parameters after -- are pathspecs, which is a set of patterns
the paths discovered by the operation (in this case diff that
finds paths in HEAD^ and HEAD) are matched against.  They are used
to filter out uninteresting paths.

If HEAD^ and HEAD does not have anything that match the given
pattern (in this case, literal four-letter string file), the set
of interesting paths may become empty and that is perfectly normal.

So this is working as designed.

Having said that, we do detect typo by noticing when a pathspec did
not find _any_ path that matched it in some front-end Porcelain
commands, e.g.

$ git add 'foo*'
fatal: pathspec 'foo*' did not match any files

It is unreasonable to do the same in git log old..new -- path and
error out when the pathspec does not match, because it is normal for
some revisions to have path while some other revisions to lack it.

But for a two-endpoint diff Porcelain (not the plumbing diff-files,
diff-index and diff-tree), I do not think it is particularly a bad
idea to add such a typo-detection feature.
--
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