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 -Gregexp that greps in the patch text)
Ramkumar Ramachandra artag...@gmail.com writes:
-Sstring::
- Look for differences that introduce or remove an instance of
- string. Note that this is different than the string simply
- appearing in diff output; see the 'pickaxe' entry in
- linkgit:gitdiffcore[7] for more
On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
artag...@gmail.com 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
On Tue, May 14, 2013 at 1:44 PM, Phil Hord phil.h...@gmail.com wrote:
On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
-Sstring::
- Look for differences that introduce or remove an instance of
- string. Note that this is different than the string
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 first
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 place
Ramkumar Ramachandra artag...@gmail.com 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
Phil Hord phil.h...@gmail.com 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
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
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
Ramkumar Ramachandra artag...@gmail.com 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
On Tue, May 14, 2013 at 2:44 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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.
Should
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,
Ramkumar Ramachandra artag...@gmail.com 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
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 far as
Ramkumar Ramachandra artag...@gmail.com 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
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
filepairs
On Tue, May 14, 2013 at 2:57 PM, Ramkumar Ramachandra
artag...@gmail.com 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
19 matches
Mail list logo
