On Tue, May 14, 2013 at 2:57 PM, Ramkumar Ramachandra
wrote:
> Junio C Hamano wrote:
>> I do not use zsh but with bash+readline the old tradition lnext can
>> be used (see "stty -a" output and it typically is set to ^V), i.e.
>> \C-v followed by \C-i should give you a literal HT.
>
> Just looked i
Junio C Hamano wrote:
> When a commit moves a file wholesale without affecting the block of
> code you are interested in, you know that whole block came from the
> file in the old tree at pre-rename location without looking at
> anywhere else. That is why renamed but pickaxe-uninteresting
> filepa
Ramkumar Ramachandra writes:
> What I was trying to say is that it's an accidental feature
There is nothing accidental about it. It was a very conscious
design decision.
When a commit moves a file wholesale without affecting the block of
code you are interested in, you know that whole block ca
Junio C Hamano wrote:
> I think what makes this paragraph unnecessarily hard to read is the
> "While rename works".
>
> With that, you are implying "if you rename a file as a whole without
> changing the block of text you identify with the -S parameter, then
> such a change is not interesting as fa
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
>> Should we mention in the -S documentation that temporary shell script
>> is the way to get multi-line input?
>
> No, because for almost everyone it isn't.
>
> An example in the EXAMPLES section including an aside that you might
> have to
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> I do not use zsh but with bash+readline the old tradition lnext can
>> be used (see "stty -a" output and it typically is set to ^V), i.e.
>> \C-v followed by \C-i should give you a literal HT.
>
> Just looked it up: zsh has quoted-insert (^V
Ramkumar Ramachandra wrote:
> Should we mention in the -S documentation that temporary shell script
> is the way to get multi-line input?
No, because for almost everyone it isn't.
An example in the EXAMPLES section including an aside that you might
have to hit ^V to enter a tab could be useful,
Jonathan Nieder wrote:
> Write a better shell?
Shell, editor. Both are very hard problems, and the successful
projects last many years (emacs, zsh are over 20 years old).
> Teach "git gui blame" to blame on arbitrary
> regions instead of single lines?
Or in my case: get magit to do log -S.
Sho
On Tue, May 14, 2013 at 2:44 PM, Ramkumar Ramachandra
wrote:
> Phil Hord wrote:
>> References to git-log seem out of place to me here in git-diffcore. I
>> know it's only an example, but it seems that Git normally describes
>> these 'reference selectors' more generically. The generic description
Ramkumar Ramachandra writes:
>>> +The S kind detects filepairs whose "result" side and "origin" side
>>> +have different number of occurrences of specified string. While
>>> +rename detection works as usual, 'git log -S' cannot omit commits
>>
>> The "cannot omit" feels like a confusing double-n
Ramkumar Ramachandra wrote:
> What can we do to improve the interface?
Write a better shell? Teach "git gui blame" to blame on arbitrary
regions instead of single lines? I'm not sure what you're asking,
mostly because I'm not sure who "we" is.
--
To unsubscribe from this list: send the line "un
Junio C Hamano wrote:
> I do not use zsh but with bash+readline the old tradition lnext can
> be used (see "stty -a" output and it typically is set to ^V), i.e.
> \C-v followed by \C-i should give you a literal HT.
Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
Still doesn't
Phil Hord writes:
> Normally the pickaxe options limit the diff output to those files which
> contained the changes being searched; that is, those files which
> had modifications including the search string. With the --pickaxe-all
> option, the diff of the entire commit will be s
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Any time you say "This means that", "More precisely", etc. please
>> check if you can rewrite it to lose everything before them (i.e. a
>> vague sentence that needs to be clarified may not have to be there
>> at all).
>
> Right. I thought b
Phil Hord wrote:
> References to git-log seem out of place to me here in git-diffcore. I
> know it's only an example, but it seems that Git normally describes
> these 'reference selectors' more generically. The generic description
> may be more confusing to new users, but this patch is not the pl
Junio C Hamano wrote:
> Any time you say "This means that", "More precisely", etc. please
> check if you can rewrite it to lose everything before them (i.e. a
> vague sentence that needs to be clarified may not have to be there
> at all).
Right. I thought both are necessary in this case: the firs
On Tue, May 14, 2013 at 1:44 PM, Phil Hord wrote:
> On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
> wrote:
>>
>> -S::
>> - Look for differences that introduce or remove an instance of
>> - . Note that this is different than the string simply
>> - appearing in diff outp
On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
wrote:
> The documentation of -S and -G is very sketchy. Completely rewrite the
> sections in Documentation/diff-options.txt and
> Documentation/gitdiffcore.txt.
>
> References:
> 52e9578 ([PATCH] Introducing software archaeologist's tool "pi
Ramkumar Ramachandra writes:
> -S::
> - Look for differences that introduce or remove an instance of
> - . Note that this is different than the string simply
> - appearing in diff output; see the 'pickaxe' entry in
> - linkgit:gitdiffcore[7] for more details.
> + Look for com
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".)
f506b8e (git log/diff: add -G that greps in the patch text)
Sign
20 matches
Mail list logo
