On Sat, Oct 6, 2012 at 12:07 PM, Jeff King wrote:
> Are you sure? Does "--only" mean "only the changes I am about to mark"
> or "only the paths I am about to tell you about"? Without partial hunk
> selection (i.e., "commit -p"), they were the same; a path you mention is
> a path which will be eit
Am 10/10/2012 21:44, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Is there already an established definition which the "correct"
>> .gitattributes are?
>
> No, and it is deliberately kept vague while waiting for us to come
> up with a clear definition of what is "correct".
...
> Very oft
Am 10/10/2012 21:56, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> At any rate, I don't observe the warnings anymore with this series.
>
> What kind of warnings have you been getting? Earlier we had a bug
> in the jk/config-warn-on-inaccessible-paths series that made it warn
> when we tr
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> Really small updates. I did not want to resend it this soon but this
>> may fix the compile errors for Junio.
t3070 seems to break TAP,
*** prove ***
t3070-wildmatch.sh .. Failed 1/151 subtests
Test Summary Report
--
'format-patch' could fail due to reasons such as out of memory. Such
failures are not detected or handled, which causes rebase to incorrectly
think that it completed successfully and continue with cleanup. i.e.
calling move_to_original_branch
Instead of using a pipe, we separate 'format-patch' and
For the 'format-patch' part, originally I was going to do something like:
git format-patch ... || {
...
}
But later I thought it's better to use a consistent style as the following
'am' part.
For the 'am' part, if we kept the following line at the end of the if-bl
p4merge does not properly handle the case where "/dev/null"
is passed as a filename.
Workaround it by creating a temporary file for this purpose.
Reported-by: Jeremy Morton
Signed-off-by: David Aguilar
---
Jeremy, can you test this?
mergetools/p4merge | 25 +
1 file ch
Nguyen Thai Ngoc Duy writes:
> On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt wrote:
>>> + git commit -m new &&
>>> + echo "Binary file HEAD:t matches" >expect &&
>>> + git grep text HEAD -- t >actual &&
>>> + test_cmp expect actual &&
>>> + git reset HEAD^
>>> +'
>>
>> And i
On Wed, Oct 10, 2012 at 6:44 PM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano wrote:
>> Steffen Prohaska writes:
>>
>>> I've recently discovered that the current protocol can be amazingly
>>> inefficient when it comes to transferring binary objects. Assuming two
On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt wrote:
>> + git commit -m new &&
>> + echo "Binary file HEAD:t matches" >expect &&
>> + git grep text HEAD -- t >actual &&
>> + test_cmp expect actual &&
>> + git reset HEAD^
>> +'
>
> And in yet another test, should
>
> gi
On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano wrote:
> Steffen Prohaska writes:
>
>> I've recently discovered that the current protocol can be amazingly
>> inefficient when it comes to transferring binary objects. Assuming two
>> repositories that are in sync. After a 'git checkout --orphan &
On Thu, Oct 11, 2012 at 4:41 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>>@@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int
>> pathlen,
>>* contain the trailing slash
>>*/
>>
>>- if (pathlen < baselen ||
>>+ if (pathlen < basel
Nguyễn Thái Ngọc Duy writes:
> Really small updates. I did not want to resend it this soon but this
> may fix the compile errors for Junio.
Thanks; queued and pushed out on 'pu'. Comments later.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
Simon Oosthoek writes:
> __git_ps1 ()
> {
> + local pcmode=no
> + #defaults/examples:
> + local ps1pc_start='\u@\h:\w '
> + local ps1pc_end='\$ '
> + local printf_format='(%s)'
> + ...
This conversion is wrong, given that ...
> @@ -284,6 +317,12 @@ __git_ps1 ()
>
Eric Wong writes:
> Jonathan Nieder wrote:
>> Michael J Gruber wrote:
>> > Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41:
>>
>> >> Signed-off-by: Jonathan Nieder
>> >
>> > Tested with Subversion 1.6.18.
>
> Thanks both. Also pushed to "master" on git://bogomips.org/git-svn.git
> (commi
From: "Junio C Hamano"
Steffen Prohaska writes:
I've recently discovered that the current protocol can be amazingly
inefficient when it comes to transferring binary objects. Assuming
two
repositories that are in sync. After a 'git checkout --orphan && git
commit', a subsequent transfers s
Jonathan Nieder wrote:
> Eric Wong wrote:
> > Jonathan Nieder wrote:
>
> >> -- >8 --
> >> Subject: Git::SVN::Editor::T: pass $deletions to ->A and ->D
> >
> > For future reference, it'd be slightly easier for me to apply if you
> > included the From: (and Date:) headers so I don't have to yank+p
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>>@@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int
>> pathlen,
>> * contain the trailing slash
>> */
>>
>>- if (pathlen < baselen ||
>>+ if (pathlen < baselen + 1 ||
>> (baselen
Drew Northup writes:
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> # rc.d/rc2.d/S08iptables
> # rc.d/rc3.d/S08iptables
> # rc.d/rc4.d/S08iptables
> ...
> no changes added to commit (use "git add" and/or "git commit -a")
>
> It detects
Eric Wong wrote:
> Jonathan Nieder wrote:
>> -- >8 --
>> Subject: Git::SVN::Editor::T: pass $deletions to ->A and ->D
>
> For future reference, it'd be slightly easier for me to apply if you
> included the From: (and Date:) headers so I don't have to yank+paste
> them myself :>
Ah, I assumed you
Nguyễn Thái Ngọc Duy writes:
>@@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int
> pathlen,
>* contain the trailing slash
>*/
>
>- if (pathlen < baselen ||
>+ if (pathlen < baselen + 1 ||
> (baselen && pathname[baselen] != '/') |
Jonathan Nieder wrote:
> Eric Wong wrote:
>
> > Thanks both. Also pushed to "master" on git://bogomips.org/git-svn.git
> > (commit 44bc5ac71fd99f195bf1a3bea63c11139d2d535f)
> >
> > Jonathan Nieder (2):
> > git svn: work around SVN 1.7 mishandling of svn:special changes
> > svn test:
Nguyễn Thái Ngọc Duy writes:
> quote_path_relative() resetting output buffer is sometimes unnecessary
> as the buffer has never been used, and some other times makes it
> harder for the caller to use (see builtin/grep.c, the caller has to
> insert a string after quote_path_relative)
>
> Move the
Eric Wong wrote:
> Thanks both. Also pushed to "master" on git://bogomips.org/git-svn.git
> (commit 44bc5ac71fd99f195bf1a3bea63c11139d2d535f)
>
> Jonathan Nieder (2):
> git svn: work around SVN 1.7 mishandling of svn:special changes
> svn test: escape peg revision separator using empt
Subversion represents symlinks as ordinary files with content starting
with "link " and the svn:special property set to "*". Thus a file can
switch between being a symlink and a non-symlink simply by toggling
its svn:special property, and new checkouts will automatically write a
file of the approp
Steffen Prohaska writes:
> I've recently discovered that the current protocol can be amazingly
> inefficient when it comes to transferring binary objects. Assuming two
> repositories that are in sync. After a 'git checkout --orphan && git
> commit', a subsequent transfers sends all the blobs at
Jonathan Nieder wrote:
> Michael J Gruber wrote:
> > Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41:
>
> >> Signed-off-by: Jonathan Nieder
> >
> > Tested with Subversion 1.6.18.
Thanks both. Also pushed to "master" on git://bogomips.org/git-svn.git
(commit 44bc5ac71fd99f195bf1a3bea63c111
Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>
> > Revisions prepared with ordinary svn commands ("svn add" and not "svn
> > propset") don't trip this because they represent filetype changes
> > using a replace operation [...]
> >Perhaps
Drew Northup writes:
> It detects the changes as renames however—which in this case isn't
> appropriate:
Why is that a problem? A rename is just something which is computed on
the fly for display purpose, the repository only stores a snapshot of
the resulting tree.
Andreas.
--
Andreas Schwab
Nguyễn Thái Ngọc Duy writes:
> .gitattributes and .gitignore share the same pattern syntax but has
> separate matching implementation. Over the years, ignore's
> implementation accumulates more optimizations while attr's stays the
> same.
>
> This patch adds those optimizations to attr. Basically
Johannes Sixt writes:
> At any rate, I don't observe the warnings anymore with this series.
What kind of warnings have you been getting? Earlier we had a bug
in the jk/config-warn-on-inaccessible-paths series that made it warn
when we tried to open a .gitattribute file and open() returned an
er
Johannes Sixt writes:
> Is there already an established definition which the "correct"
> .gitattributes are? IIRC, everywhere else we are looking at the
> .gitattributes in the worktree, regardless of whether the object at the
> path in question is in the worktree, the index, or in an old commit.
By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.) to indicate the state of
the tree.
Signed-off-by: Simon Oosthoek
---
contrib/completion/git-prompt.sh | 36 +++-
1
Apologies if you receive this e-mail multiple times, my MTA was misconfigured...
Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping iss
On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote:
> All,
>
> Our company is researching version control software, something which we have
> not used previously. I have a very basic question about git which I have
> not been able to answer from reading. As I understand it, a git repository
> can
By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.) to indicate the state of
the tree.
Signed-off-by: Simon Oosthoek
---
contrib/completion/git-prompt.sh | 36 +++-
1
Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping issues. Only by assigning \[ and \] to PS1
directly can bash know that these and the e
Ramsay Jones writes:
> Yes, so I can simply disable the malloc checks in my ~/.bashrc file.
> However, it would be disappointing to have my config tweeks in two
> places ... :(
>
> I guess I can live with it ...
You could write "export that-variable" in your config.mak yourself
;-) Let's apply
On Oct 8, 2012, at 6:27 PM, Junio C Hamano wrote:
> Once we go into "want/have" phase, I do not think there is a need
> for fundamental change in the protocol (by this, I am not counting a
> change to send "have"s sparsely and possibly backtracking to bisect
> history, etc. as "fundamental").
I'v
I use etckeeper on some of my systems, backed by Git. On a system still
using a SYSV style init I recently modified my iptables settings,
changing which runlevels would stop/start the firewall.
[root@drew-northup ~]# etckeeper vcs status
# On branch master
# Changes not staged for commit:
# (use
No reboot. lsb-release -a from memory or something similar, always on travel...
Regards
2012/10/10, Elia Pinto :
> Hemm, too old release distro , no ? 4-5 year ago. It is time to
> upgrade to something more recent , 5.7 5.8 . Rhel5.3 is not a good
> distro for a developer isn't it ?
>
> 2012/10/
Hemm, too old release distro , no ? 4-5 year ago. It is time to
upgrade to something more recent , 5.7 5.8 . Rhel5.3 is not a good
distro for a developer isn't it ?
2012/10/10, Ramsay Jones :
> Junio C Hamano wrote:
>> Ramsay Jones writes:
>>
>>> The malloc checks can be disabled using the TEST_N
Nguyen Thai Ngoc Duy writes:
> This is the documentation part of
>
> 1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14)
> 06f33c1 (Read attributes from the index that is being checked out -
> 2009-03-13)
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> I looked around but di
All,
Our company is researching version control software, something which we have
not used previously. I have a very basic question about git which I have
not been able to answer from reading. As I understand it, a git repository
can be a mixture of files which are under development, staged or c
Elia Pinto wrote:
> 2012/10/6 Junio C Hamano :
>> Ramsay Jones writes:
>> Elia, you brought the MALLOC_CHECK_ up. Did you hear about this
>> issue elsewhere before, and if you did, do you know how other
>> projects solves it?
> Ok. I have found. For me this is not a problem any more these days.
>
Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK
>> variable, either from the environment or command line of an
>> 'make test' invocation. In order to allow the malloc checks to be
>> disabled from the 'config.mak' file, we add TES
"Jan H. Schönherr" writes:
> Am 09.10.2012 21:45, schrieb Junio C Hamano:
>> Jan H. Schönherr writes:
>>
>>> +test_expect_failure 'additional command line cc (rfc822)' '
>>> +
>>> + git config --replace-all format.headers "Cc: R E Cipient
>>> " &&
>>> git format-patch --cc="S. E. Cipient
Michael Haggerty writes:
>> The last one teaches "git log" family to honor the "grep.*"
>> configuration variables, e.g. "grep.patterntype", so that you can
>> say "git -c grep.patterntype=perl log --grep='(?:pcre)'".
>
> Maybe this has been discussed already, but it seems to me that adding a
> p
On 10/10/2012 12:40 PM, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> wildmatch.c | 161
>
> wildmatch.h | 2 -
> 2 files changed, 9 insertions(+), 154 deletions(-)
>
> diff --git a/wildmatch.c b/wildm
On 10/10/2012 09:55 AM, Junio C Hamano wrote:
> It took longer than expected, but here is a reroll of the previous
> series to bring more recent "git grep" enhancements to the "--grep"
> option of commands in "git log" family.
>
> The early part of the series (1-3) refactors the code that reads
>
Am 10/10/2012 15:59, schrieb Nguyễn Thái Ngọc Duy:
> This patch passes real paths down to grep_source_load_driver(). Except
> grepping a blob, all other cases should have right paths down to
... grepping a blob or tree object...
> grep_source_load_driver(). In other words, .gitattributes are stil
grep searches for .gitattributes using "name" field in struct
grep_source but that field is not real on-disk path name. For example,
"grep pattern rev" fills the field with "rev:path", which is
non-existent usually until somebody exploits it to drive git away.
This patch passes real paths down to
quote_path_relative() resetting output buffer is sometimes unnecessary
as the buffer has never been used, and some other times makes it
harder for the caller to use (see builtin/grep.c, the caller has to
insert a string after quote_path_relative)
Move the buffer reset back to call sites when neces
Round too. .gitattributes should be respected in all cases except blob
grepping. As Johannes pointed elsewhere in this thread, if "git
diff " looks up worktree's .gitattributes (and none in
rev1/rev2), there's no reason "git grep" should behave differently.
Nguyễn Thái Ngọc Duy (2):
quote: let
This is the documentation part of
1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14)
06f33c1 (Read attributes from the index that is being checked out - 2009-03-13)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I looked around but did not see anywhere mentioning this. If I did
no
On Wed, Oct 10, 2012 at 7:43 PM, Johannes Sixt wrote:
> Am 10/10/2012 14:32, schrieb Nguyen Thai Ngoc Duy:
>> git-archive has --worktree-attributes to specify where attributes come
>> from. Sparse checkout can choose to read index version first then
>> worktree's or the other way around. All norma
Am 10/10/2012 14:32, schrieb Nguyen Thai Ngoc Duy:
> git-archive has --worktree-attributes to specify where attributes come
> from. Sparse checkout can choose to read index version first then
> worktree's or the other way around. All normal operations read
> worktree version, if not found index ver
On Wed, Oct 10, 2012 at 7:12 PM, Johannes Sixt wrote:
> Is there already an established definition which the "correct"
> .gitattributes are?
If I ask to grep the index then to me it should read only the index.
Although other people can counter that they may want different
attributes than the one
Am 10/10/2012 14:03, schrieb Nguyen Thai Ngoc Duy:
> On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt wrote:
>> Thanks for working on this issue!
>>
>> Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy:
>>> + linkgit:gitattributes[5]). Note that .gitattributes are only
>>> + support for sear
On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt wrote:
> Thanks for working on this issue!
>
> Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy:
>> + linkgit:gitattributes[5]). Note that .gitattributes are only
>> + support for searching files in working directory.
>
> Does this mean it do
Thanks for working on this issue!
Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy:
> + linkgit:gitattributes[5]). Note that .gitattributes are only
> + support for searching files in working directory.
Does this mean it does not work for 'git grep --cached'? That would be a
real loss.
grep searches for .gitattributes using "name" field in struct
grep_source but that field is not real on-disk path name. For example,
"grep pattern rev" fills the field with "rev:path", which is
non-existent usually until somebody exploits it to drive git away.
attr does not support looking up .git
From: Jeff King
Having path name (if available) may be useful. For example, if grep
machinery needs to look up git attributes, it'll need a good path
name. grep_source->name is not good because it's for display purpose
only.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/grep.c | 17 +
quote_path_relative() resetting output buffer is sometimes unnecessary
as the buffer has never been used, and some other times makes it
harder for the caller to use (see builtin/grep.c, the caller has to
insert a string after quote_path_relative)
Move the buffer reset back to call sites when neces
On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> I think we just need to have callers of grep_source_init provide us with
>> the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is
>> where the information is lost.
>
> Yes. I agree that is the right
Am 09.10.2012 21:07, schrieb Junio C Hamano:
> Jan H. Schönherr writes:
>
>> During the creation of this series, I came across the strbuf
>> wrapping functions, and I wonder if there is an off-by-one issue.
>>
>> Consider the following excerpt from t4202:
...
>
> Yeah, that does sound like an o
Am 09.10.2012 21:45, schrieb Junio C Hamano:
> Jan H. Schönherr writes:
>
>> +test_expect_failure 'additional command line cc (rfc822)' '
>> +
>> +git config --replace-all format.headers "Cc: R E Cipient
>> " &&
>> git format-patch --cc="S. E. Cipient " --stdout
>> master..side | sed -
fnmatch on glibc-2.12.1 returns no match. glibc-2.15 returns ok.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t3070-wildmatch.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index f21da6c..38042eb 100755
--- a/t/t3070-wildmatc
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitattributes.txt| 6 ++
Documentation/gitignore.txt| 19 +++
attr.c | 4 +++-
dir.c | 4 +++-
t/t0003-attributes.sh | 38 +++
"foo/**/bar" matches "foo/x/bar", "foo/x/y/bar"... but not
"foo/bar". We make a special case, when foo/**/ is detected (and
"foo/" part is already matched), try matching "bar" with the rest of
the string.
"Match one or more directories" semantics can be easily achieved using
"foo/*/**/bar".
This
Standard wildmatch() sees consecutive asterisks as "*" that can also
match slashes. But that may be hard to explain to users as
"abc/**/def" can match "abcdef", "abcxyzdef", "abc/def", "abc/x/def",
"abc/x/y/def"...
This patch changes wildmatch so that users can do
- "**/def" -> all paths ending w
dowild() does case insensitive matching by lower-casing the text. That
means lower case letters in patterns imply case-insensitive matching,
but upper case means exact matching.
We do not want that subtlety. Lower case pattern too so iwildmatch()
always does what we expect it to do.
Signed-off-by
One place less to worry about thread safety. Also combine wildmatch
and iwildmatch into one.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-wildmatch.c | 4 ++--
wildmatch.c | 21 +
wildmatch.h | 3 +--
3 files changed, 8 insertions(+), 20 deletions(-)
diff --git a
wildmatch returns non-zero if matched, zero otherwise. This patch
makes it return zero if matches, non-zero otherwise, like fnmatch().
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-wildmatch.c | 4 ++--
wildmatch.c | 21 -
2 files changed, 14 insertions(+), 11 deletions(
Signed-off-by: Nguyễn Thái Ngọc Duy
---
.gitignore | 1 +
Makefile | 3 +
t/t3070-wildmatch.sh | 178 +++
t/t3070/wildtest.txt | 165 ---
test-wildmatch.c | 14
wildmatc
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wildmatch.c | 161
wildmatch.h | 2 -
2 files changed, 9 insertions(+), 154 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index f3a1731..71dba76 100644
--- a/wildmatch.c
+++ b/wildmatch.
These files are from rsync.git commit
f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit
before rsync turned GPL-3. All files are imported as-is and
no-op. Adaptation is done in a separate patch.
rsync.git -> git.git
lib/wildmatch.[ch] wildmatch.[ch]
wildtest.txt
A new table sane_ctype2[] is added, otherwise we'll need to OR with
current bits in sane_ctype[] and that looks ugly.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
ctype.c | 18 ++
git-compat-util.h | 13 +
2 files changed, 31 insertions(+)
diff --git a/ctype.c b
Signed-off-by: Nguyễn Thái Ngọc Duy
---
ctype.c | 2 +-
git-compat-util.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ctype.c b/ctype.c
index 9353271..faeaf34 100644
--- a/ctype.c
+++ b/ctype.c
@@ -14,7 +14,7 @@ enum {
P = GIT_PATHSPEC_MAGIC /* other
Really small updates. I did not want to resend it this soon but this
may fix the compile errors for Junio. Changes are
- cleanup in wildmatch.c so #include "cache.h" is at the top of the
file.
- wildmatch() returns no match if it encounters "**" without
surrounding slashes. It returns a s
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch adds those optimizations to attr. Basically it tries to
avoid fnmatch as much as poss
Am 09.10.2012 21:30, schrieb Junio C Hamano:
> Jan H. Schönherr writes:
...
>> static int is_rfc2047_special(char ch)
>> {
>> +/*
>> + * We encode ' ' using '=20' even though rfc2047
>> + * allows using '_' for readability. Unfortunately,
>> + * many programs do not understand t
Gah! Schoolboy error.
juser = Joe User
Thanks for the pointer!
Cheers,
Dave.
> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: 09 October 2012 19:03
> To: Balch, David
> Cc: git@vger.kernel.org
> Subject: Re: username case conflict in git svn clone
>
>
Hi Junio
> It is not difficult. The discussion on this list is usually done
> via patches, and without one, constant talking is buried in other
> noise and often go unnoticed.
Could you accept for very small changes also the simple indication of
the change itself instead of a patch?
>
> There i
Now the grep_config() callback is reusable from other configuration
callbacks, call it from git_log_config() so that grep.patterntype
and friends can be used with the commands in the "git log" family.
Signed-off-by: Junio C Hamano
---
builtin/log.c | 8 +++-
1 file changed, 7 insertions(+),
When we added the "--perl-regexp" option (or "-P") to "git grep", we
should have done the same for the commands in the "git log" family,
but somehow we forgot to do so. This corrects it, but we will
reserve the short-and-sweet "-P" option for something else for now.
Also introduce the "--basic-re
The command line option parser for "git log -F -E --grep=''"
did not flip the "fixed" bit, violating the general "last option
wins" principle among conflicting options.
Signed-off-by: Junio C Hamano
---
revision.c | 4 ++--
t/t4202-log.sh | 6 ++
2 files changed, 8 insertions(+), 2 delet
Instead of using the hand-rolled initialization sequence,
use grep_init() to populate the necessary bits. This opens
the door to allow the calling commands to optionally read
grep.* configuration variables via git_config() if they
want to.
Signed-off-by: Junio C Hamano
---
grep.c | 5 +
Switching between -E/-G/-P/-F correctly needs a lot more than just
flipping opt->regflags bit these days, and we have a nice helper
function buried in builtin/grep.c for the sole use of "git grep".
Extract it so that "log --grep" family can also use it.
Signed-off-by: Junio C Hamano
---
builtin
The configuration handling is a library-ish part of this program,
that is not specific to "git grep" command. It should be reusable
by "log" and others.
Signed-off-by: Junio C Hamano
---
builtin/grep.c | 131 -
grep.c | 130 +++
The grep_config() function takes one instance of grep_opt as its
callback parameter, and populates it by running git_config().
This has three practical implications:
- You have to have an instance of grep_opt already when you call
the configuration, but that is not necessarily always true. Y
It took longer than expected, but here is a reroll of the previous
series to bring more recent "git grep" enhancements to the "--grep"
option of commands in "git log" family.
The early part of the series (1-3) refactors the code that reads
configuration items related to "grep" and the code that mi
Angelo Borsotti writes:
> Why it is so difficult to convince people to make documentation better?
It is not difficult. The discussion on this list is usually done
via patches, and without one, constant talking is buried in other
noise and often go unnoticed.
There is however an issue about doc
乙酸鋰 writes:
> Could you clarify --branch option, is it the same as --branches.
Switches can be abbreviated as long as they are unambiguous.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something complet
Junio,
giving the user a better error message is certainly an improvement.
But would not be another improvement to describe better the command syntax
so as to help the user write the command right in the first place?
After all, what is the syntax section in commands for?
If I had seen in the synta
95 matches
Mail list logo
