[PATCH 45/45] Rename field "raw" to "_raw" in struct pathspec

This patch is essentially no-op. It helps catching new use of this field though. This field is introduced as an intermediate step for the pathspec conversion and will be removed eventually. At this stage no more access sites should be introduced. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/l

[PATCH 41/45] Kill limit_pathspec_to_literal() as it's only used by parse_pathspec()

Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 8 pathspec.c | 8 ++-- pathspec.h | 2 -- 3 files changed, 6 insertions(+), 12 deletions(-) diff --git a/dir.c b/dir.c index 1098133..76a2e1a 100644 --- a/dir.c +++ b/dir.c @@ -1475,14 +1475,6 @@ int remove_path(const char *name

[PATCH 40/45] parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN

The prefix length is passed from one command to another via the new magic 'prefix'. The magic is for parse_pathspec's internal use only, not visible to parse_pathspec's callers. Prefix length is not preserved across commands when --literal-pathspecs is specified (no magic is allowed, including 'pr

[PATCH 42/45] pathspec: support :(literal) syntax for noglob pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/glossary-content.txt | 20 builtin/add.c | 2 +- builtin/diff.c | 2 +- dir.c | 15 --- pathspec.c | 11 -

[PATCH 38/45] tree-diff: remove the use of pathspec's raw[] in follow-rename codepath

Put a checkpoint to guard unsupported pathspec features in future. Signed-off-by: Nguyễn Thái Ngọc Duy --- tree-diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tree-diff.c b/tree-diff.c index e1145c6..21a50d8 100644 --- a/tree-diff.c +++ b/tree-diff.c @@ -224,7 +22

[PATCH 43/45] pathspec: make --literal-pathspecs disable pathspec magic

--literal-pathspecs and its equivalent environment variable are probably used for scripting. In that setting, pathspec magic may be unwanted. Disabling globbing in individual pathspec can be done via :(literal) magic. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git.txt | 4 ++-- p

[PATCH 39/45] parse_pathspec: make sure the prefix part is wildcard-free

Prepending prefix to pathspec is a trick to workaround the fact that commands can be executed in a subdirectory, but all git commands run at worktree's root. The prefix part should always be treated as literal string. Make it so. Signed-off-by: Nguyễn Thái Ngọc Duy --- cache.h| 2 ++ path.c

[PATCH 44/45] pathspec: support :(glob) syntax

:(glob)path differs from plain pathspec that it uses wildmatch with WM_PATHNAME while the other uses fnmatch without FNM_PATHNAME. The difference lies in how '*' (and '**') is processed. With the introduction of :(glob) and :(literal) and their global options --[no]glob-pathspecs, the user can:

[PATCH 31/45] Convert refresh_index to take struct pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/add.c| 15 +++ builtin/commit.c | 2 +- builtin/rm.c | 2 +- cache.h | 2 +- read-cache.c | 5 +++-- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/builtin/add.c b/builtin/add.c index d039fc9..

[PATCH 32/45] Convert {read,fill}_directory to take struct pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/add.c | 4 +++- builtin/clean.c| 2 +- builtin/grep.c | 2 +- builtin/ls-files.c | 2 +- dir.c | 16 +++- dir.h | 4 ++-- wt-status.c| 2 +- 7 files changed, 20 insertions(+), 12 dele

[PATCH 37/45] Remove match_pathspec() in favor of match_pathspec_depth()

match_pathspec_depth was created to replace match_pathspec (see 61cf282 (pathspec: add match_pathspec_depth() - 2010-12-15). It took more than two years, but the replacement finally happens :-) Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/add.c | 30 +++--- builtin/check-ign

[PATCH 36/45] Remove init_pathspec() in favor of parse_pathspec()

While at there, move free_pathspec() to pathspec.c Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/blame.c| 8 +--- builtin/log.c | 2 +- builtin/ls-files.c | 11 +-- diff-lib.c | 2 +- dir.c | 58 --

[PATCH 33/45] Convert add_files_to_cache to take struct pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/add.c| 11 +++ builtin/commit.c | 2 +- cache.h | 2 +- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/builtin/add.c b/builtin/add.c index 34c9358..a47aeb4 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -16

[PATCH 27/45] Convert run_add_interactive to use struct pathspec

This passes the pathspec, more or less unmodified, to git-add--interactive. The command itself does not process pathspec. It simply passes the pathspec to other builtin commands. So if all those commands support pathspec, we're good. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/add.c | 2

[PATCH 34/45] Convert common_prefix() to use struct pathspec

The code now takes advantage of nowildcard_len field. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/commit.c | 2 +- builtin/ls-files.c | 2 +- dir.c | 31 +++ dir.h | 2 +- 4 files changed, 18 insertions(+), 19 deletions(-) diff --gi

[PATCH 28/45] Convert unmerge_cache to take struct pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- rerere.c | 2 +- resolve-undo.c | 4 ++-- resolve-undo.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/rerere.c b/rerere.c index 27afbfe..4105bca 100644 --- a/rerere.c +++ b/rerere.c @@ -668,7 +668,7 @@ int rerere_forget(stru

[PATCH 35/45] Remove diff_tree_{setup,release}_paths

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/blame.c | 12 ++-- builtin/reset.c | 9 + diff.h | 2 -- notes-merge.c | 4 ++-- revision.c | 5 +++-- tree-diff.c | 18 -- 6 files changed, 20 insertions(+), 30 deletions(-) diff --git a/bui

[PATCH 23/45] add: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/add.c | 103 +- pathspec.c| 43 2 files changed, 45 insertions(+), 101 deletions(-) diff --git a/builtin/add.c b/builtin/add.c index f45d9d4..9a7235e 100644 ---

[PATCH 30/45] Convert report_path_error to take struct pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 2 +- builtin/commit.c | 14 ++ builtin/ls-files.c | 19 +++ cache.h| 2 +- 4 files changed, 19 insertions(+), 18 deletions(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index be08

[PATCH 21/45] archive: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- archive.c | 19 +++ archive.h | 4 +++- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/archive.c b/archive.c index c699a2d..99fadc8 100644 --- a/archive.c +++ b/archive.c @@ -5,7 +5,6 @@ #include "archive.h" #include "pa

[PATCH 22/45] check-ignore: convert to use parse_pathspec

check-ignore (at least the test suite) seems to rely on the pattern order. PATHSPEC_KEEP_ORDER is introduced to explictly express this. The lack of PATHSPEC_MAXDEPTH_VALID is sufficient because it's the only flag that reorders pathspecs, but it's less obvious that way. Cc: Adam Spiers Signed-off-

[PATCH 29/45] checkout: convert read_tree_some to take struct pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 9 +++-- tree.c | 4 ++-- tree.h | 2 +- 3 files changed, 6 insertions(+), 9 deletions(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index 0e93af0..be08061 100644 --- a/builtin/checkout.c +++ b/bu

[PATCH 26/45] Convert read_cache_preload() to take struct pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 2 +- builtin/commit.c | 4 ++-- builtin/diff-files.c | 2 +- builtin/diff-index.c | 2 +- builtin/diff.c | 4 ++-- cache.h | 2 +- preload-index.c | 20 +++- 7 files changed, 19 inse

[PATCH 25/45] line-log: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- line-log.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/line-log.c b/line-log.c index 4bbb09b..843a334 100644 --- a/line-log.c +++ b/line-log.c @@ -747,7 +747,7 @@ void line_log_init(struct rev_info *rev, const char *prefix, struct

[PATCH 20/45] ls-files: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/ls-files.c | 46 +- 1 file changed, 13 insertions(+), 33 deletions(-) diff --git a/builtin/ls-files.c b/builtin/ls-files.c index a0b7e30..1534a39 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-files.c

[PATCH 24/45] reset: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/reset.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/builtin/reset.c b/builtin/reset.c index 6032131..da7282e 100644 --- a/builtin/reset.c +++ b/builtin/reset.c @@ -171,7 +171,10 @@ static void di

[PATCH 12/45] parse_pathspec: support prefixing original patterns

This makes 'original' suitable for passing to an external command because all pathspec magic is left in place, provided that the external command understands pathspec. The prefixing is needed because we usually launch a subcommand at worktree's top directory and the subcommand can no longer calcula

[PATCH 18/45] checkout: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 34 +- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index f5b50e5..197198b 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -46,7 +46

[PATCH 14/45] clean: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/clean.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/builtin/clean.c b/builtin/clean.c index f955a40..fdd4980 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -13,6 +13,7 @@ #include "refs.h" #includ

[PATCH 13/45] Guard against new pathspec magic in pathspec matching code

GUARD_PATHSPEC() marks pathspec-sensitive code, basically all those that touch anything in 'struct pathspec' except fields "nr" and "original". GUARD_PATHSPEC() is not supposed to fail. It's mainly to help the designers to catch unsupported codepaths. Signed-off-by: Nguyễn Thái Ngọc Duy --- Docu

[PATCH 15/45] commit: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/commit.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index d2f30d9..0efe269 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -279,17 +279,17 @@ static char *prepa

[PATCH 16/45] status: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/commit.c | 9 + wt-status.c | 16 +++- wt-status.h | 2 +- 3 files changed, 13 insertions(+), 14 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index 0efe269..833c7be 100644 --- a/builtin/commit.c +++

[PATCH 19/45] rm: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/rm.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/builtin/rm.c b/builtin/rm.c index 7b91d52..0b38de3 100644 --- a/builtin/rm.c +++ b/builtin/rm.c @@ -10,6 +10,7 @@ #include "tree-walk.h" #include

[PATCH 17/45] rerere: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/rerere.c | 8 +--- rerere.c | 9 + rerere.h | 4 +++- 3 files changed, 13 insertions(+), 8 deletions(-) diff --git a/builtin/rerere.c b/builtin/rerere.c index dc1708e..4e51add 100644 --- a/builtin/rerere.c +++ b/builtin

[PATCH 08/45] Convert some get_pathspec() calls to parse_pathspec()

These call sites follow the pattern: paths = get_pathspec(prefix, argv); init_pathspec(&pathspec, paths); which can be converted into a single parse_pathspec() call. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/grep.c | 6 +++--- builtin/ls-tree.c | 10 +- builti

[PATCH 09/45] parse_pathspec: a special flag for max_depth feature

match_pathspec_depth() and tree_entry_interesting() check max_depth field in order to support "git grep --max-depth". The feature activation is tied to "recursive" field, which led to some unwanted activation, e.g. 5c8eeb8 (diff-index: enable recursive pathspec matching in unpack_trees - 2012-01-15

[PATCH 07/45] parse_pathspec: add PATHSPEC_PREFER_{CWD,FULL}

We have two ways of dealing with empty pathspec: 1. limit it to current prefix 2. match the entire working directory Some commands go with #1, some #2. get_pathspec() and parse_pathspec() only support #1. Make parse_pathspec() reject empty pathspec by default. #1 and #2 can be specified via new f

[PATCH 11/45] parse_pathspec: support stripping/checking submodule paths

PATHSPEC_SYMLINK_LEADING_PATH and _STRIP_SUBMODULE_SLASH_EXPENSIVE are respectively the alternate implementation of pathspec.c:die_if_path_beyond_symlink() and pathspec.c:check_path_for_gitlink(). They are intended to replace those functions when builtin/add.c and builtin/check-ignore.c are convert

[PATCH 06/45] parse_pathspec: save original pathspec for reporting

We usually use pathspec_item's match field for pathspec error reporting. However "match" (or "raw") does not show the magic part, which will play more important role later on. Preserve exact user input for reporting. Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 1 + pathspec.c | 2 ++ pa

[PATCH 10/45] parse_pathspec: support stripping submodule trailing slashes

This flag is equivalent to builtin/ls-files.c:strip_trailing_slashes() and is intended to replace that function when ls-files is converted to use parse_pathspec. Signed-off-by: Nguyễn Thái Ngọc Duy --- pathspec.c | 9 + pathspec.h | 2 ++ 2 files changed, 11 insertions(+) diff --git a/p

[PATCH 05/45] Add parse_pathspec() that converts cmdline args to struct pathspec

Currently to fill a struct pathspec, we do: const char **paths; paths = get_pathspec(prefix, argv); ... init_pathspec(&pathspec, paths); "paths" can only carry bare strings, which loses information from command line arguments such as pathspec magic or the prefix part's length for each

[PATCH 01/45] clean: remove unused variable "seen"

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/clean.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/builtin/clean.c b/builtin/clean.c index 04e396b..f955a40 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -155,7 +155,6 @@ int cmd_clean(int argc, const ch

[PATCH 04/45] pathspec: add copy_pathspec

The function is made to use with free_pathspec() because a simple struct assignment is not enough (free_pathspec wants to free "items" pointer). Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/mv.c | 13 +++-- pathspec.c | 8 pathspec.h | 1 + 3 files changed, 16 insertion

[PATCH 03/45] pathspec: i18n-ize error strings in pathspec parsing code

Signed-off-by: Nguyễn Thái Ngọc Duy --- pathspec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pathspec.c b/pathspec.c index 133f8be..403095b 100644 --- a/pathspec.c +++ b/pathspec.c @@ -167,11 +167,11 @@ static const char *prefix_pathspec(const char *prefix, int p

[PATCH 02/45] Move struct pathspec and related functions to pathspec.[ch]

Signed-off-by: Nguyễn Thái Ngọc Duy --- archive.c | 1 + builtin/grep.c | 1 + builtin/ls-files.c | 1 + builtin/ls-tree.c | 1 + builtin/update-index.c | 1 + cache.h| 22 +--- diff.h | 1 + dir.c |

[PATCH 00/45] "struct pathspec" conversion and :(glob)

This series finishes off "struct pathspec" conversion that was started 2 years ago when this struct was added. In the end we can pass more information down the callchain than simply a series of strings. This makes it possible to add more pathspec "magic", the :(glob) in the end of this series is an

Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing

On Sat, Jun 08, 2013 at 09:00:30PM +0200, Matthieu Moy wrote: > > + # Auto-loading in browser > > + if ($autoload) { > > + open(my $browser, "-|:encoding(UTF-8)", "xdg-open > > ".$preview_file_name); > > That could be read from Git's configuration, and default to xdg-open. > But yo

Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing

On Fri, Jun 07, 2013 at 11:50:31PM +0200, benoit.per...@ensimag.fr wrote: > The #7 issue on git-mediawiki's issue tracker [1] states that the ability to > preview content without pushing would be a nice thing to have. Sounds like a useful goal. > The default behaviour for the `preview` subcomman

Re: [PATCH 2/2] git.txt: document GIT_TRACE_PACKET

On Sun, Jun 09, 2013 at 12:53:30PM +0700, Nguyen Thai Ngoc Duy wrote: > "This can help with debugging object negotiation or other protocol > issues." > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > >> +'GIT_TRACE_PACKET':: > >> +     If this variable is set, it shows a trace of all packets >

[PATCH 2/2] git.txt: document GIT_TRACE_PACKET

"This can help with debugging object negotiation or other protocol issues." Signed-off-by: Nguyễn Thái Ngọc Duy --- >> +'GIT_TRACE_PACKET':: >> +     If this variable is set, it shows a trace of all packets >> +     coming in or out of a given program. This can help with >> +     debugging ob

Re: [PATCH 2/2] git.txt: document GIT_TRACE_PACKET

On Sun, Jun 09, 2013 at 12:22:49PM +0700, Nguyen Thai Ngoc Duy wrote: > diff --git a/Documentation/git.txt b/Documentation/git.txt > index c760918..72e9045 100644 > --- a/Documentation/git.txt > +++ b/Documentation/git.txt > @@ -845,6 +845,11 @@ for further details. > recorded. This may be h

Re: [PATCH 2/2] Move sequencer to builtin

On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote: > > Definitely, yes. Even if you look at the impact on code alone and > > don't care about the people, destroying a collegial work environment > > is harmful enough to the code to outweigh the (admittedly often > > useful) patches.

[PATCH 1/2] core: use env variable instead of config var to turn on logging pack access

5f44324 (core: log offset pack data accesses happened - 2011-07-06) provides a way to observe pack access patterns via a config switch. Setting an environment variable looks more obvious than a config var, especially when you just need to _observe_, and more inline with other tracing knobs we have.

Re: [PATCH] git-remote-mediawiki: Fix a bug in a regexp

On Sat, Jun 8, 2013 at 10:57 PM, Jeff King wrote: > On Sat, Jun 08, 2013 at 08:38:56PM +0200, Matthieu Moy wrote: > >> Célestin Matte writes: >> >> > In Perl, '\n' is not a newline, but instead a literal backslash followed >> > by an >> > "n". As the output of "rev-list --first-parent" is line-o

[PATCH 2/2] git.txt: document GIT_TRACE_PACKET

"This can help with debugging object negotiation or other protocol issues." Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/git.txt b/Documentation/git.txt index c760918..72e9045 100644 --- a/Documentation/git.t

Re: [PATCH] git-remote-mediawiki: Fix a bug in a regexp

On Sat, Jun 8, 2013 at 9:35 AM, Célestin Matte wrote: > In Perl, '\n' is not a newline, but instead a literal backslash followed by an > "n". As the output of "rev-list --first-parent" is line-oriented, what we want > here is a newline. > > Signed-off-by: Célestin Matte > Signed-off-by: Matthieu

Re: [PATCH v2 14/22] git-remote-mediawiki: Check return value of open + remove import of unused open2

On Sat, Jun 8, 2013 at 2:45 PM, Célestin Matte wrote: > Le 08/06/2013 20:41, Matthieu Moy a écrit : >> Célestin Matte writes: >> >>> Le 08/06/2013 02:14, Eric Sunshine a écrit : These two changes are unrelated and could be split into distinct patches (IMHO, though others may disagree).

Re: [PATCH v2 16/22] git-remote-mediawiki: Modify strings for a better coding-style

On Sat, Jun 8, 2013 at 4:32 PM, Célestin Matte wrote: > Le 08/06/2013 02:39, Eric Sunshine a écrit : >> On Fri, Jun 7, 2013 at 5:42 PM, Célestin Matte >> wrote: >>> - strings which don't need interpolation are single-quoted for more clarity >>> and >>> slight gain of performance >>> - interpolat

Re: [PATCH 2/2] Move sequencer to builtin

On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote: > Let the code speak. Show me a script in any language that does > something useful using libgit2, doing the equivalent to at least a > couple of 'git foo' commands. Sorry that I cannot show you the source code, but you may interes

Re: [PATCH 2/2] Move sequencer to builtin

On Sat, Jun 8, 2013 at 10:21 PM, Jonathan Nieder wrote: > Felipe Contreras wrote: > >> A collegial work environment is overrated, and proof of that the Linux >> kernel, where honest and straight talk is the bread and butter of the >> mailing list. > > An aside, since it doesn't bear too much on th

Re: [PATCH 2/2] Move sequencer to builtin

Felipe Contreras wrote: > A collegial work environment is overrated, and proof of that the Linux > kernel, where honest and straight talk is the bread and butter of the > mailing list. An aside, since it doesn't bear too much on the topic at hand: For what it's worth, in my experience the people

Re: [Administrivia] On ruby and contrib/

Hi Duy, On Sat, 8 Jun 2013, Duy Nguyen wrote: > On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin > wrote: > > Hi Greg, > > > > On Thu, 6 Jun 2013, Greg Troxel wrote: > > > >> As one of the people who helps maintain git packages in pkgsrc, my > >> initial reaction is negative to adding a ruby

Re: [Administrivia] On ruby and contrib/

Hi Ram, On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: > > While at it, why not re-evaluate the whole msysgit approach? I bet we > > don't need a whole separate project just to create a Windows > > installer. I've written Windows installers before, it's very easy to > >

Re: [PATCH] git-remote-mediawiki: Fix a bug in a regexp

On Sat, Jun 08, 2013 at 08:38:56PM +0200, Matthieu Moy wrote: > Célestin Matte writes: > > > In Perl, '\n' is not a newline, but instead a literal backslash followed by > > an > > "n". As the output of "rev-list --first-parent" is line-oriented, what we > > want > > here is a newline. > > Thi

Re: [Administrivia] On ruby and contrib/

Hi Ram, On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: > >> Also we heard from no regular/high-value reviewers that they feel > >> comfortable reviewing additions in Ruby. > > > > Correction; *current* regular/high-value reviewers. > > Correct. The opinions of inactiv

Re: [Administrivia] On ruby and contrib/

On Sat, Jun 8, 2013 at 9:23 PM, Jeff King wrote: > On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote: > >> > No, I didn't say that at all. >> >> Then you truly think libgit2 will ever reach the point where it can >> replace libgit.a? > > I don't know. It may. Or something like it ma

Re: [PATCH v3 2/2] read-cache: plug a few leaks

On Sat, Jun 8, 2013 at 9:11 PM, René Scharfe wrote: > Am 08.06.2013 19:27, schrieb Felipe Contreras: > >> On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe >> wrote: >> >>> Let's find and fix those leaks by freeing memory in the right places. >>> Freeing memory just in case in places where we can sho

Re: [Administrivia] On ruby and contrib/

On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote: > > No, I didn't say that at all. > > Then you truly think libgit2 will ever reach the point where it can > replace libgit.a? I don't know. It may. Or something like it may. It is certainly not ready to do so yet, but perhaps one

Re: [PATCH 2/2] Move sequencer to builtin

On Sat, Jun 8, 2013 at 8:40 PM, Jonathan Nieder wrote: > Felipe Contreras wrote: > >> Just the past three months I've probably done more work than anybody >> else[1], and you would ban me because you don't like my words? > > Definitely, yes. Even if you look at the impact on code alone and > don'

Re: [PATCH v3 2/2] read-cache: plug a few leaks

Am 08.06.2013 19:27, schrieb Felipe Contreras: On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe wrote: Let's find and fix those leaks by freeing memory in the right places. Freeing memory just in case in places where we can show that no leak is triggered by our test suite doesn't help. It helps

Re: [PATCH 2/2] Move sequencer to builtin

Felipe Contreras wrote: > Just the past three months I've probably done more work than anybody > else[1], and you would ban me because you don't like my words? Definitely, yes. Even if you look at the impact on code alone and don't care about the people, destroying a collegial work environment i

Re: [Administrivia] On ruby and contrib/

On Sat, Jun 8, 2013 at 7:10 PM, Jeff King wrote: > On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote: > >> > These are problems that can be solved. But there is a lot of work >> > involved in finding these subtle bugs and coming up with fixes. I think >> > you would be better off wo

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Fri, Jun 07, 2013 at 12:12:52PM +0200, Erik Faye-Lund wrote: > > Yeah, if it were mingw_raise responsible for this, I would suggest using > > the POSIX shell "128+sig" instead. We could potentially check for > > SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if > > that would

Re: [Administrivia] On ruby and contrib/

On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote: > > These are problems that can be solved. But there is a lot of work > > involved in finding these subtle bugs and coming up with fixes. I think > > you would be better off working on an implementation of git that was > > designed

[PATCH] build: trivial cleanup

There's no need to list again the prerequisites. Signed-off-by: Felipe Contreras --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 03524d0..fda98d6 100644 --- a/Makefile +++ b/Makefile @@ -2067,13 +2067,13 @@ $(REMOTE_CURL_PRIMARY):

[PATCH] diff: add --ignore-blank-lines option

The goal of the patch is to introduce the GNU diff -B/--ignore-blank-lines as closely as possible. The short option is not available because it's already used for "break-rewrites". When this option is used, git-diff will not create hunks that simply adds or removes empty lines, but will still show

Re: [PATCH v2 16/22] git-remote-mediawiki: Modify strings for a better coding-style

Le 08/06/2013 02:39, Eric Sunshine a écrit : > On Fri, Jun 7, 2013 at 5:42 PM, Célestin Matte > wrote: >> - strings which don't need interpolation are single-quoted for more clarity >> and >> slight gain of performance >> - interpolation is preferred over concatenation in many cases, for more >>

Re: [PATCH] git-remote-mediawiki: Fix a bug in a regexp

Le 08/06/2013 20:38, Matthieu Moy a écrit :> This is right, but the code actually worked the way it was. I'm not > sure, but my understanding is that '\n' is the string "backslash > followed by n", but interpreted as a regexp, it is a newline. > > The new code looks better than the old one, but the

Re: [PATCH 2/2] Move sequencer to builtin

On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote: > If I were managing this list, I would ban mails from you, since this > discussion style does more harm than good. There is a nice motto around: "Talk is cheap. Show me the code." Just the past three months I've probably done more work th

Re: [PATCH v2 14/22] git-remote-mediawiki: Check return value of open + remove import of unused open2

Célestin Matte writes: > Oh, I thought a part of a patch was called a commit. 1 patch = 1 commit 1 patch series = several commits sent together. Will normally end-up in a branch in Junio's repo (named with /) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe f

Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing

benoit.per...@ensimag.fr writes: > From: Benoit Person > > The #7 issue on git-mediawiki's issue tracker [1] states that the ability to > preview content without pushing would be a nice thing to have. > > This commit is a first attempt to achieve it. It adds a new git command, > named `git mw`. T

Re: [PATCH v2 14/22] git-remote-mediawiki: Check return value of open + remove import of unused open2

Le 08/06/2013 20:41, Matthieu Moy a écrit : > Célestin Matte writes: > >> Le 08/06/2013 02:14, Eric Sunshine a écrit : >>> These two changes are unrelated and could be split into distinct >>> patches (IMHO, though others may disagree). >> >> Two distinct patches or two distinct commits? > > That

Re: [PATCH v2 14/22] git-remote-mediawiki: Check return value of open + remove import of unused open2

Célestin Matte writes: > Le 08/06/2013 02:14, Eric Sunshine a écrit : >> These two changes are unrelated and could be split into distinct >> patches (IMHO, though others may disagree). > > Two distinct patches or two distinct commits? That's the same. You write commits locally, send them as patc

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

Ramkumar Ramachandra writes: > Yes, please merge. The commit message looks good as well: it doesn't > say anything about waiting for 2.0. The commit message doesn't, but the doc does. I'll resend without the 2.0 mention. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from

Re: [PATCH] git-remote-mediawiki: Fix a bug in a regexp

Célestin Matte writes: > In Perl, '\n' is not a newline, but instead a literal backslash followed by an > "n". As the output of "rev-list --first-parent" is line-oriented, what we want > here is a newline. This is right, but the code actually worked the way it was. I'm not sure, but my understan

Re: [PATCH v2 02/22] git-remote-mediawiki: Use the Readonly module instead of the constant pragma

Jeff King writes: > Thanks both for the explanation. I don't see us using that to our > advantage anywhere in the patch. So I think this is purely a style > issue, which to me indicates that the extra dependency is not worth it, > and the patch should be dropped. Same here: I'd rather keep the

Re: [PATCH] build: get rid of the notion of a git library

On Sat, Jun 8, 2013 at 1:02 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> There's no libgit, and there will never be, every object file in Git is >> the same, and there's wish to organize them in any way; they are *all* >> for the 'git' binary and its builtin commands. > > Nice joke

Re: [PATCH] build: get rid of the notion of a git library

Felipe Contreras wrote: > There's no libgit, and there will never be, every object file in Git is > the same, and there's wish to organize them in any way; they are *all* > for the 'git' binary and its builtin commands. Nice joke patch to illustrate your point ;) On a more serious note, please be

Re: [PATCH 2/2] Move sequencer to builtin

On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote: > Felipe Contreras wrote: > >> This has nothing to do with better strategy, it has everything to do >> with gut feelings and tradition. Not reasons. > > I try to help you, and you insult me. I don't think this is worth it. I didn't direct t

Re: [Administrivia] On ruby and contrib/

On Sat, Jun 8, 2013 at 12:15 PM, Jeff King wrote: > On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote: > >> > There are a lot of static variables in builtin/ (and outside too), >> > which make it non-entrant, or at least not safe. >> >> So? >> >> > fork provides a process space isol

Re: [PATCH 2/2] Move sequencer to builtin

Felipe Contreras wrote: > This has nothing to do with better strategy, it has everything to do > with gut feelings and tradition. Not reasons. I try to help you, and you insult me. I don't think this is worth it. If I were managing this list, I would ban mails from you, since this discussion st

Re: [PATCH v2 02/22] git-remote-mediawiki: Use the Readonly module instead of the constant pragma

On Sat, Jun 08, 2013 at 03:01:03PM +0200, Célestin Perdu wrote: > Oh yes, part of this commit went into the previous one, which was not > formated as an email when I did my git-format-patch. I should check my > patches more carefully before sending them. Sorry for this. No problem. It is easy to

[PATCH] build: get rid of the notion of a git library

There's no libgit, and there will never be, every object file in Git is the same, and there's wish to organize them in any way; they are *all* for the 'git' binary and its builtin commands. So let's shatter any hopes of ever having a library, and be clear about it; both the top-level objects (./*.

Re: [PATCH v3 2/2] read-cache: plug a few leaks

On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe wrote: > Let's find and fix those leaks by freeing memory in the right places. > Freeing memory just in case in places where we can show that no leak is > triggered by our test suite doesn't help. It helps; it prevents leaks. The real culprit is the

Re: [PATCH v3 2/2] read-cache: plug a few leaks

Am 08.06.2013 18:53, schrieb Felipe Contreras: On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe wrote: Am 08.06.2013 16:04, schrieb Felipe Contreras: On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe wrote: Am 08.06.2013 14:15, schrieb Felipe Contreras: Why leave it out? If somebody makes the

Re: [Administrivia] On ruby and contrib/

On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote: > > There are a lot of static variables in builtin/ (and outside too), > > which make it non-entrant, or at least not safe. > > So? > > > fork provides a process space isolation, some depend on that. > > Process space isolation f

Re: [PATCH 2/2] Move sequencer to builtin

On Sat, Jun 8, 2013 at 11:49 AM, Jonathan Nieder wrote: > Duy Nguyen wrote: > >> libgit.a is just a way of grouping a bunch of objects together, not a >> real library and not meant to be. If you aim something more organized, >> please show at least a roadmap what to move where. > > Exactly. There

Re: [PATCH] tests: fix autostash

Ramkumar Ramachandra wrote: > How else am I supposed to write them? If there is a stale state from > the previous test, there isn't too much I can do. Or should I be > cleaning up state at the beginning of each test, instead of at the > end? That's one strategy. "test_when_finished" to restore

Re: [PATCH v3 2/2] read-cache: plug a few leaks

On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe wrote: > Am 08.06.2013 16:04, schrieb Felipe Contreras: > >> On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe >> wrote: >>> >>> Am 08.06.2013 14:15, schrieb Felipe Contreras: >> >> Why leave it out? If somebody makes the mistake of doing the above >>

Re: [PATCH 2/2] Move sequencer to builtin

Duy Nguyen wrote: > libgit.a is just a way of grouping a bunch of objects together, not a > real library and not meant to be. If you aim something more organized, > please show at least a roadmap what to move where. Exactly. There are some rough plans I would like to help with in the direction o

  1   2   >