Re: git checkout error

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

Re: git svn clone options

乙酸鋰 ch3co...@gmail.com 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

Re: git checkout error

Angelo Borsotti angelo.borso...@gmail.com 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

[PATCH v2 0/7] Tying loose ends on grep-pcre

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

[PATCH v2 1/7] builtin/grep.c: make configuration callback more reusable

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.

[PATCH v2 2/7] grep: move the configuration parsing logic to grep.[ch]

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 gits...@pobox.com --- builtin/grep.c | 131 - grep.c

[PATCH v2 3/7] grep: move pattern-type bits support to top-level grep.[ch]

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 gits...@pobox.com

[PATCH v2 4/7] revisions: initialize revs-grep_filter using grep_init()

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 gits...@pobox.com ---

[PATCH v2 5/7] log --grep: use the same helper to set -E/-F options as git grep

The command line option parser for git log -F -E --grep='ere' did not flip the fixed bit, violating the general last option wins principle among conflicting options. Signed-off-by: Junio C Hamano gits...@pobox.com --- revision.c | 4 ++-- t/t4202-log.sh | 6 ++ 2 files changed, 8

[PATCH v2 6/7] log --grep: accept --basic-regexp and --perl-regexp

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

[PATCH v2 7/7] log: honor grep.* configuration

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 gits...@pobox.com --- builtin/log.c | 8 +++- 1 file changed, 7

Re: git checkout error

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 is

RE: username case conflict in git svn clone [SOLVED]

Gah! Schoolboy error. juser = Joe User joe.u...@example.com 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

Re: [PATCH 2/5] format-patch: do not wrap rfc2047 encoded headers too late

Am 09.10.2012 21:30, schrieb Junio C Hamano: Jan H. Schönherr schn...@cs.tu-berlin.de writes: ... static int is_rfc2047_special(char ch) { +/* + * We encode ' ' using '=20' even though rfc2047 + * allows using '_' for readability. Unfortunately, + * many programs do not

[PATCH v2 2/2] attr: more matching optimizations from .gitignore

.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

[PATCH v4 00/12] Wildmatch v4

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

[PATCH v4 01/12] ctype: make sane_ctype[] const array

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- 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 =

[PATCH v4 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint

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 pclo...@gmail.com --- ctype.c | 18 ++ git-compat-util.h | 13 + 2 files changed, 31 insertions(+) diff

[PATCH v4 03/12] Import wildmatch from rsync

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

[PATCH v4 04/12] wildmatch: remove unnecessary functions

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- 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 ---

[PATCH v4 05/12] Integrate wildmatch to git

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- .gitignore | 1 + Makefile | 3 + t/t3070-wildmatch.sh | 178 +++ t/t3070/wildtest.txt | 165 --- test-wildmatch.c |

[PATCH v4 06/12] wildmatch: make wildmatch's return value compatible with fnmatch

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 pclo...@gmail.com --- test-wildmatch.c | 4 ++-- wildmatch.c | 21 - 2 files changed, 14

[PATCH v4 07/12] wildmatch: remove static variable force_lower_case

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 pclo...@gmail.com --- test-wildmatch.c | 4 ++-- wildmatch.c | 21 + wildmatch.h | 3 +-- 3 files changed, 8 insertions(+), 20

[PATCH v4 08/12] wildmatch: fix case-insensitive matching

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.

[PATCH v4 09/12] wildmatch: adjust ** behavior

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 with

[PATCH v4 10/12] wildmatch: make /**/ match zero or more directories

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

[PATCH v4 11/12] Support ** wildcard in .gitignore and .gitattributes

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/gitattributes.txt| 6 ++ Documentation/gitignore.txt| 19 +++ attr.c | 4 +++- dir.c | 4 +++- t/t0003-attributes.sh |

Re: [PATCH 0/5] Cure some format-patch wrapping and encoding issues

Am 09.10.2012 21:07, schrieb Junio C Hamano: Jan H. Schönherr schn...@cs.tu-berlin.de 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

Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree

On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net 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

[PATCH 1/3] quote: let caller reset buffer for quote_path_relative()

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

[PATCH 3/3] grep: stop looking at random places for .gitattributes

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

[PATCH 2/3] grep: pass true path name to grep machinery

From: Jeff King p...@peff.net 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 pclo...@gmail.com ---

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

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.

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt j.s...@viscovery.net 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

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

Am 10/10/2012 14:03, schrieb Nguyen Thai Ngoc Duy: On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt j.s...@viscovery.net 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

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

On Wed, Oct 10, 2012 at 7:12 PM, Johannes Sixt j.s...@viscovery.net 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

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

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

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

On Wed, Oct 10, 2012 at 7:43 PM, Johannes Sixt j.s...@viscovery.net 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

[PATCH] attr: a note about the order of .gitattributes lookup

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 pclo...@gmail.com --- I looked around but did not see anywhere mentioning

[PATCH v2 0/2] Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree

Round too. .gitattributes should be respected in all cases except blob grepping. As Johannes pointed elsewhere in this thread, if git diff rev1 rev2 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:

[PATCH v2 2/2] grep: stop looking at random places for .gitattributes

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

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

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 still

Re: [PATCH v2 0/7] Tying loose ends on grep-pcre

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

Re: [PATCH v4 04/12] wildmatch: remove unnecessary functions

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 pclo...@gmail.com --- wildmatch.c | 161 wildmatch.h | 2 - 2 files changed, 9 insertions(+), 154 deletions(-) diff --git

Re: [PATCH v2 0/7] Tying loose ends on grep-pcre

Michael Haggerty mhag...@alum.mit.edu 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

Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak

Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk 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'

Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak

Elia Pinto wrote: 2012/10/6 Junio C Hamano gits...@pobox.com: Ramsay Jones ram...@ramsay1.demon.co.uk 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

Re: [PATCH] attr: a note about the order of .gitattributes lookup

Nguyen Thai Ngoc Duy pclo...@gmail.com 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 pclo...@gmail.com

Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak

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 ram...@ramsay1.demon.co.uk: Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk writes: The

Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak

No reboot. lsb-release -a from memory or something similar, always on travel... Regards 2012/10/10, Elia Pinto gitter.spi...@gmail.com: 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

rm and add, but not rename, of identical files

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

Re: Is anyone working on a next-gen Git protocol?

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 haves sparsely and possibly backtracking to bisect history, etc. as fundamental). I've

Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak

Ramsay Jones ram...@ramsay1.demon.co.uk 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

[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND

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

[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND

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

[PATCH 2/2] show color hints based on state of the git tree

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 s.oosth...@xs4all.nl --- contrib/completion/git-prompt.sh | 36

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

Johannes Sixt j.s...@viscovery.net 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

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

Johannes Sixt j.s...@viscovery.net 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

Re: [PATCH v2 2/2] attr: more matching optimizations from .gitignore

Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: rm and add, but not rename, of identical files

Drew Northup drew.nort...@maine.edu 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.

Re: [PATCH/RFC v2] git svn: work around SVN 1.7 mishandling of svn:special changes

Jonathan Nieder jrnie...@gmail.com 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 [...]

Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev

Jonathan Nieder jrnie...@gmail.com wrote: Michael J Gruber wrote: Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41: Signed-off-by: Jonathan Nieder jrnie...@gmail.com Tested with Subversion 1.6.18. Thanks both. Also pushed to master on git://bogomips.org/git-svn.git (commit

Re: Is anyone working on a next-gen Git protocol?

Steffen Prohaska proha...@zib.de 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

[PATCH v3] git svn: work around SVN 1.7 mishandling of svn:special changes

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

Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev

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

Re: [PATCH 1/3] quote: let caller reset buffer for quote_path_relative()

Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev

Jonathan Nieder jrnie...@gmail.com 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

Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev

Eric Wong wrote: Jonathan Nieder jrnie...@gmail.com 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

Re: rm and add, but not rename, of identical files

Drew Northup drew.nort...@maine.edu writes: # Untracked files: # (use git add file... 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)

Re: [PATCH v2 2/2] attr: more matching optimizations from .gitignore

Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com 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 ||

Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev

Jonathan Nieder jrnie...@gmail.com wrote: Eric Wong wrote: Jonathan Nieder jrnie...@gmail.com 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

Re: Is anyone working on a next-gen Git protocol?

From: Junio C Hamano gits...@pobox.com Steffen Prohaska proha...@zib.de 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

Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev

Eric Wong normalper...@yhbt.net writes: Jonathan Nieder jrnie...@gmail.com wrote: Michael J Gruber wrote: Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41: Signed-off-by: Jonathan Nieder jrnie...@gmail.com Tested with Subversion 1.6.18. Thanks both. Also pushed to master on

Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND

Simon Oosthoek s.oosth...@xs4all.nl 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 ()

Re: [PATCH v4 00/12] Wildmatch v4

Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: [PATCH v2 2/2] attr: more matching optimizations from .gitignore

On Thu, Oct 11, 2012 at 4:41 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: @@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int pathlen, * contain the trailing slash */ - if (pathlen baselen || +

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt j.s...@viscovery.net 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 git grep

Re: Is anyone working on a next-gen Git protocol?

On Wed, Oct 10, 2012 at 6:44 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano gits...@pobox.com wrote: Steffen Prohaska proha...@zib.de writes: I've recently discovered that the current protocol can be amazingly inefficient when it comes to

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt j.s...@viscovery.net 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^ +'

[PATCH] mergetools/p4merge: Handle /dev/null

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 ad...@game-point.net Signed-off-by: David Aguilar dav...@gmail.com --- Jeremy, can you test this? mergetools/p4merge | 25

Re: Rebase doesn't restore branch pointer back on out of memory

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

[PATCH] rebase: Handle cases where format-patch fails

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

Re: [PATCH v4 00/12] Wildmatch v4

Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

Am 10/10/2012 21:56, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net 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

Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes

Am 10/10/2012 21:44, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net 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. ...

Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file

On Sat, Oct 6, 2012 at 12:07 PM, Jeff King p...@peff.net 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