Re: [PATCH 4/8] wildmatch: support "no FNM_PATHNAME" mode

On Fri, Dec 28, 2012 at 1:24 PM, Junio C Hamano wrote: >> if (*++p == '*') { >> const uchar *prev_p = p - 2; >> while (*++p == '*') {} >> - if ((prev_p == text || *prev_p == '/') || >> +

Re: [PATCH 8/8] wildmatch: advance faster in + patterns

On Fri, Dec 28, 2012 at 1:24 PM, Junio C Hamano wrote: >> + while ((t_ch = *text) != '\0' && >> +(!(flags & WM_PATHNAME) || t_ch >> != '/')) { > > Why do we look at (flags & WM_PATHMAME) and not "special" here? Becau

Re: Find the starting point of a local branch

On Thu, Dec 27, 2012 at 9:15 PM, Woody Wu wrote: > On Mon, Dec 24, 2012 at 09:24:39AM -0800, Martin von Zweigbergk wrote: >> On Sun, Dec 23, 2012 at 11:31 PM, Woody Wu wrote: >> > >> > This is not working to me since I have more than one local branch that >> > diverged from the master, and in fac

Re: [PATCH 8/8] wildmatch: advance faster in + patterns

Nguyễn Thái Ngọc Duy writes: > compat, '*/*/*' on linux-2.6.git file list 2000 times, before: > wildmatch 7s 985049us > fnmatch 2s 735541us or 34.26% faster > > and after: > wildmatch 4s 492549us > fnmatch 0s 888263us or 19.77% slower > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > wildmat

Re: [PATCH 4/8] wildmatch: support "no FNM_PATHNAME" mode

Nguyễn Thái Ngọc Duy writes: > diff --git a/wildmatch.c b/wildmatch.c > index a79f97e..4fe1d65 100644 > --- a/wildmatch.c > +++ b/wildmatch.c > @@ -77,14 +77,17 @@ static int dowild(const uchar *p, const uchar *text, > unsigned int flags) > continue; > case '

Re: Find the starting point of a local branch

On Mon, Dec 24, 2012 at 09:24:39AM -0800, Martin von Zweigbergk wrote: > On Sun, Dec 23, 2012 at 11:31 PM, Woody Wu wrote: > > On Sun, Dec 23, 2012 at 11:09:58PM -0500, Seth Robertson wrote: > >> > >> In message <20121224035825.GA17203@zuhnb712>, Woody Wu writes: > >> > >> How can I find out w

[PATCH v2 7/9] wildmatch: make a special case for "*/" with FNM_PATHNAME

Normally we need recursion for "*". In this case we know that it matches everything until "/" so we can skip the recursion. glibc, '*/*/*' on linux-2.6.git file list 2000 times before: wildmatch 8s 74513us fnmatch 1s 97042us or 13.59% faster after: wildmatch 3s 521862us fnmatch 3s 488616us or

[PATCH v2 1/9] compat/fnmatch: respect NO_FNMATCH* even on glibc

Signed-off-by: Nguyễn Thái Ngọc Duy --- compat/fnmatch/fnmatch.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c index 9473aed..6f7387d 100644 --- a/compat/fnmatch/fnmatch.c +++ b/compat/fnmatch/fnmatch.c @@ -55,7 +55,8 @@

[PATCH v2 3/9] wildmatch: rename constants and update prototype

- All exported constants now have a prefix WM_ - Do not rely on FNM_* constants, use the WM_ counterparts - Remove TRUE and FALSE to follow Git's coding style - While at it, turn flags type from int to unsigned int - Add an (unused yet) argument to carry extra information so that we don't have to

[PATCH v2 4/9] wildmatch: make dowild() take arbitrary flags

Signed-off-by: Nguyễn Thái Ngọc Duy --- wildmatch.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/wildmatch.c b/wildmatch.c index f9b6451..68e4213 100644 --- a/wildmatch.c +++ b/wildmatch.c @@ -52,7 +52,7 @@ typedef unsigned char uchar; #define ISXDIGIT(c) (I

[PATCH v2 8/9] wildmatch: advance faster in + patterns

compat, '*/*/*' on linux-2.6.git file list 2000 times, before: wildmatch 7s 985049us fnmatch 2s 735541us or 34.26% faster and after: wildmatch 4s 492549us fnmatch 0s 888263us or 19.77% slower Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t3070-wildmatch.sh | 6 ++ wildmatch.c | 21

[PATCH v2 2/9] wildmatch: replace variable 'special' with better named ones

'special' is too generic and is used for two different purposes. Replace it with 'match_slash' to indicate "**" pattern and 'negated' for "[!...]" and "[^...]". Signed-off-by: Nguyễn Thái Ngọc Duy --- wildmatch.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --gi

[PATCH v2 0/9] fnmatch replacement step 1

v2 has no big changes: - 'special' variable in dowild() is removed in favor of two new, better named ones - fix TRUE/FALSE in comments as well as code in the rename patch - some tests for "*/" and "*" optimizations - USE_WILDMATCH patch is moved to the end of the series Nguyễn Thái Ngọc Du

[PATCH v2 5/9] wildmatch: support "no FNM_PATHNAME" mode

So far, wildmatch() has always honoured directory boundary and there was no way to turn it off. Make it behave more like fnmatch() by requiring all callers that want the FNM_PATHNAME behaviour to pass that in the equivalent flag WM_PATHNAME. Callers that do not specify WM_PATHNAME will get wildcard

[PATCH v2 9/9] Makefile: add USE_WILDMATCH to use wildmatch as fnmatch

This is similar to NO_FNMATCH but it uses wildmatch instead of compat/fnmatch. This is an intermediate step to let wildmatch be used as fnmatch replacement for wider audience before it replaces fnmatch completely and compat/fnmatch is removed. fnmatch in test-wildmatch is not impacted by this and

[PATCH v2 6/9] test-wildmatch: add "perf" command to compare wildmatch and fnmatch

It takes a text file, a pattern, a number and pathname flag. Each line in the text file is matched against the pattern times. If "pathname" is given, FNM_PATHNAME is used. test-wildmatch is built with -O2 and tested against glibc 2.14.1 (also -O2) and compat/fnmatch. The input file is linux-2.6.

Re: git log commit limiting "show commits with >1 child" possible?

CORRECTION: So I hope to see: * 00a27e0 J | * 160d232 I |/ * b981ea0 F | * daa5b69 H |/ * 546ae44 B * 734db0c A On 28/12/2012, David wrote: > My branches are very long so for years I have been doing a lot of scrolling > when using gitk. I have just now discovered

git log commit limiting "show commits with >1 child" possible?

My branches are very long so for years I have been doing a lot of scrolling when using gitk. I have just now discovered how to see a simplified history. For this example history where commits were added in alphabetical order: A--B--C--D--H \ E--F--G--I \

Thomas Sabo - History

Thomas Sabo was initially developed in Germany and the Thomas Sabo Charm Club Collection is now renowned all over the world. This jewelry spread across Europe side and the United States in initial years. It was in the year 1984 that this fashion valu

Re: nike air max 95

read more at : http://www.thomassabouksaleonline2013.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/nike-air-max-95-tp7571318p7573747.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the bod

[ANNOUNCE] Git v1.8.0.3

The latest maintenance release Git v1.8.0.3 is now available at the usual places. This is primarily to down-merge documentation updates that have been accumulating to the 'master' front for the upcoming 1.8.1 to the maintenance series. The release tarballs are found at: http://code.google.co

Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)

On Wednesday, December 26, 2012 01:24:39 am Michael Haggerty wrote: > ... lots of discussion about ref locking... It concerns me that git uses any locking at all, even for refs since it has the potential to leave around stale locks. For a single user repo this is not a big deal, the lock can

Re: Python version auditing followup

On do, 2012-12-20 at 10:30 -0800, Junio C Hamano wrote: > Which platforms that are long-term-maintained by their vendors still > pin their Python at 2.4.X? RHEL 5.x and its clones still use python 2.4. It is supported by red hat until at least 2017 (though end of production phase two, Q1 2014, se

Re: "fatal: git-write-tree: error building trees" from `git stash`

Jeff King writes: > but I suspect it is not sufficient: > > 1. There are other code paths that will end up in write-tree which > should probably be protected, too. Among 6 calls to write-tree, only the first ones in create_stash and apply_stash are about the index the user originally had.

Re: "fatal: git-write-tree: error building trees" from `git stash`

Alex Vandiver writes: > ... "Cannot stash while resolving conflicts" or similar would be > more understandable to the end user than the above. Interestingly enough, the "apply" side is protected with this one liner: # current index state c_tree=$(git write-tree) ||

Re: "fatal: git-write-tree: error building trees" from `git stash`

On Thu, Dec 27, 2012 at 01:55:56PM -0500, Alex Vandiver wrote: > On Thu, 2012-12-27 at 10:51 -0800, Junio C Hamano wrote: > > > $ git stash > > > foo: needs merge > > > foo: needs merge > > > foo: unmerged (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7) > > > foo: unmerged (a77fa514de2720c72c1a861de098

Re: "fatal: git-write-tree: error building trees" from `git stash`

On Thu, 2012-12-27 at 10:51 -0800, Junio C Hamano wrote: > > $ git stash > > foo: needs merge > > foo: needs merge > > foo: unmerged (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7) > > foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a) > > foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a) >

Re: "fatal: git-write-tree: error building trees" from `git stash`

Alex Vandiver writes: > Heya, > I just ran into the following with `git stash`. The set-up: > ... > $ git stash pop > Auto-merging foo > CONFLICT (content): Merge conflict in foo > Recorded preimage for 'foo' > > $ git stash > foo: needs merge > foo: needs merge > foo: unmerged (aeaa7e5e87cf309a

Re: [PATCH v2] log: grep author/committer using mailmap

Junio C Hamano writes: > Thanks. I'll queue this on top. > > -- >8 -- > Subject: [PATCH] log --use-mailmap: optimize for cases without > --author/--committer search And this I will *not* queue further on top. -- >8 -- Subject: [PATCH] [DO NOT USE] log --use-mailmap --author/--committer: furth

Re: [PATCH v2] log: grep author/committer using mailmap

Antoine Pelisse writes: > Currently you can use mailmap to display log authors and committers > but you can't use the mailmap to find commits with mapped values. > > This commit allows you to run: > > git log --use-mailmap --author mapped_name_or_email > git log --use-mailmap --committer

"fatal: git-write-tree: error building trees" from `git stash`

Heya, I just ran into the following with `git stash`. The set-up: git init echo "Initial" > foo git add . git commit -m 'Initial commit' echo "Rewrite" > foo git commit -am 'Second commit, rewrites content' echo "Stashed changes" >> foo

Re: [PATCH v2] wt-status: Show ignored files in untracked dirs

> By "committed", I assume you meat that you have "dirA/unco" as an > untracked file, and "dirA/committed" as a file in the index? Of course, > Thanks for putting this together. I agree with the expected output in > each case, and I think this covers the cases we have seen (case 1 is > Michael's

Re: [PATCH] gitk: Replaced "green" with "#00FF00".

Peter Hofmann writes: > Subject: Re: [PATCH] gitk: Replaced "green" with "#00FF00". That should be Subject: [PATCH] gitk: replace "green" with "#00FF00" around here. Instead of reporting what you did in the past tense, you give an order to somebody to do something to make the codebase

Re: [PATCH v2] wt-status: Show ignored files in untracked dirs

> Nicely analysed. Perhaps we would want new test pieces to define > the behaviour we want to see first? I think we should. I also thought about the use case of "committed" and ignored directory which is also broken to me (point 3 in the table below). Anyway I tried to make a table to sum-up/di

Re: [PATCH v2] wt-status: Show ignored files in untracked dirs

On Thu, Dec 27, 2012 at 05:14:54PM +0100, Antoine Pelisse wrote: > > Nicely analysed. Perhaps we would want new test pieces to define > > the behaviour we want to see first? > > I think we should. > > I also thought about the use case of "committed" and ignored directory > which is also broken

[PATCH v2] log: grep author/committer using mailmap

Currently you can use mailmap to display log authors and committers but you can't use the mailmap to find commits with mapped values. This commit allows you to run: git log --use-mailmap --author mapped_name_or_email git log --use-mailmap --committer mapped_name_or_email Of course it onl

[PATCH] Remove Documentation/pt_BR/gittutorial.txt

This file is rather outdated and IMHO shouldn't be there in the first place. (If there are translations of the Git documentation they are better be kept separate from the original documentation.) Signed-off-by: Thomas Ackermann --- Documentation/pt_BR/gittutorial.txt | 675 -

[PATCH] gitk: Replaced "green" with "#00FF00".

The definition of "green" has changed in Tk 8.6: - http://wiki.tcl.tk/21276 - http://www.tcl.tk/cgi-bin/tct/tip/403 gitk looks pretty awkward with Tk 8.6. "green" is simply too dark now because it has changed from "#00FF00" to "#008000". One could also use "lime" instead of "#00FF00" but that wo

Re: Push Windows to Linux Repository Problem

- Ursprungligt meddelande - > Hi Andreas, > > Thanks for the reply and no, I could not. However, you put me on the > right track. Since I was only pushing/pulling from Windows to/from my > Linux repository, I did not realize that an SSH session from the > Linux > back to Windows would ev