Re: Push Windows to Linux Repository Problem

[Robin Rosenberg]

- 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 ever be necessary. I don't really understand
> why
> but apparently it is. 

No. Git itself does not require a reverse connection of any kind. Maybe the 
Linux
box checks that reverse lookup is set up for the client and refuses connection
if reverse lookup of the connecting client's ip does not resolve to a hostname 
that
in turn resolves back to the client's ip. If that is the case the server does 
not 
actually try to connect to the client with SSH or otherwise.

-- robin

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Peter Hofmann]

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 would break
compatibility with older versions of Tk.

Signed-off-by: Peter Hofmann 
---
 gitk-git/gitk | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..d7e922b 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2209,7 +2209,7 @@ proc makewindow {} {
set h [expr {[font metrics uifont -linespace] + 2}]
set progresscanv .tf.bar.progress
canvas $progresscanv -relief sunken -height $h -borderwidth 2
-   set progressitem [$progresscanv create rect -1 0 0 $h -fill green]
+   set progressitem [$progresscanv create rect -1 0 0 $h -fill "#00FF00"]
set fprogitem [$progresscanv create rect -1 0 0 $h -fill yellow]
set rprogitem [$progresscanv create rect -1 0 0 $h -fill red]
 }
@@ -2342,7 +2342,7 @@ proc makewindow {} {
 $ctext tag conf dresult -fore [lindex $diffcolors 1]
 $ctext tag conf m0 -fore red
 $ctext tag conf m1 -fore blue
-$ctext tag conf m2 -fore green
+$ctext tag conf m2 -fore "#00FF00"
 $ctext tag conf m3 -fore purple
 $ctext tag conf m4 -fore brown
 $ctext tag conf m5 -fore "#009090"
@@ -3226,7 +3226,7 @@ set rectmask {
0x00, 0x00, 0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f,
0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f, 0x00, 0x00};
 }
-image create bitmap reficon-H -background black -foreground green \
+image create bitmap reficon-H -background black -foreground "#00FF00" \
 -data $rectdata -maskdata $rectmask
 image create bitmap reficon-o -background black -foreground "#ff" \
 -data $rectdata -maskdata $rectmask
@@ -5909,7 +5909,7 @@ proc drawcmittext {id row col} {
 if {$id eq $nullid} {
set ofill red
 } elseif {$id eq $nullid2} {
-   set ofill green
+   set ofill "#00FF00"
 } elseif {$id eq $mainheadid} {
set ofill yellow
 } else {
@@ -6377,7 +6377,7 @@ proc drawtags {id x xt y1} {
} else {
# draw a head or other ref
if {[incr nheads -1] >= 0} {
-   set col green
+   set col "#00FF00"
if {$tag eq $mainhead} {
set font mainfontbold
}
@@ -11617,7 +11617,7 @@ if {[tk windowingsystem] eq "aqua"} {
 set extdifftool "meld"
 }
 
-set colors {green red blue magenta darkgrey brown orange}
+set colors {"#00FF00" red blue magenta darkgrey brown orange}
 if {[tk windowingsystem] eq "win32"} {
 set uicolor SystemButtonFace
 set bgcolor SystemWindow
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Remove Documentation/pt_BR/gittutorial.txt

[Thomas Ackermann]

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 
 1 file changed, 675 deletions(-)
 delete mode 100644 Documentation/pt_BR/gittutorial.txt

diff --git a/Documentation/pt_BR/gittutorial.txt 
b/Documentation/pt_BR/gittutorial.txt
deleted file mode 100644
index beba065..000
--- a/Documentation/pt_BR/gittutorial.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-gittutorial(7)
-==
-
-NOME
-
-gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)
-
-SINOPSE
-
-git *
-
-DESCRIÇÃO

-
-Este tutorial explica como importar um novo projeto para o git,
-adicionar mudanças a ele, e compartilhar mudanças com outros
-desenvolvedores.
-
-Se, ao invés disso, você está interessado primariamente em usar git para
-obter um projeto, por exemplo, para testar a última versão, você pode
-preferir começar com os primeiros dois capítulos de
-link:user-manual.html[O Manual do Usuário Git].
-
-Primeiro, note que você pode obter documentação para um comando como
-`git log --graph` com:
-
-
-$ man git-log
-
-
-ou:
-
-
-$ git help log
-
-
-Com a última forma, você pode usar o visualizador de manual de sua
-escolha; veja linkgit:git-help[1] para maior informação.
-
-É uma boa idéia informar ao git seu nome e endereço público de email
-antes de fazer qualquer operação. A maneira mais fácil de fazê-lo é:
-
-
-$ git config --global user.name "Seu Nome Vem Aqui"
-$ git config --global user.email v...@seudominio.exemplo.com
-
-
-
-Importando um novo projeto

-
-Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.
-Você pode colocá-lo sob controle de revisão git da seguinte forma:
-
-
-$ tar xzf project.tar.gz
-$ cd project
-$ git init
-
-
-Git irá responder
-
-
-Initialized empty Git repository in .git/
-
-
-Agora que você iniciou seu diretório de trabalho, você deve ter notado que um
-novo diretório foi criado com o nome de ".git".
-
-A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os
-arquivos sob o diretório atual (note o '.'), com 'git-add':
-
-
-$ git add .
-
-
-Este instantâneo está agora armazenado em uma área temporária que o git
-chama de "index" ou índice. Você pode armazenar permanentemente o
-conteúdo do índice no repositório com 'git-commit':
-
-
-$ git commit
-
-
-Isto vai te pedir por uma mensagem de commit. Você agora gravou sua
-primeira versão de seu projeto no git.
-
-Fazendo mudanças
---
-
-Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao
-índice:
-
-
-$ git add file1 file2 file3
-
-
-Você está agora pronto para fazer o commit. Você pode ver o que está
-para ser gravado usando 'git-diff' com a opção --cached:
-
-
-$ git diff --cached
-
-
-(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças
-que você tenha feito mas ainda não adicionou ao índice.) Você também
-pode obter um breve sumário da situação com 'git-status':
-
-
-$ git status
-# On branch master
-# Changes to be committed:
-#   (use "git reset HEAD ..." to unstage)
-#
-#  modified:   file1
-#  modified:   file2
-#  modified:   file3
-#
-
-
-Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,
-adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas
-mudanças com:
-
-
-$ git commit
-
-
-Ao executar esse comando, ele irá te pedir uma mensagem descrevendo a mudança,
-e, então, irá gravar a nova versão do projeto.
-
-Alternativamente, ao invés de executar 'git-add' antes, você pode usar
-
-
-$ git commit -a
-
-
-o que irá automaticamente notar quaisquer arquivos modif

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

[Antoine Pelisse]

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 only works if the --use-mailmap option is used.

Signed-off-by: Antoine Pelisse 
---
 revision.c |   54 
 t/t4203-mailmap.sh |   18 ++
 2 files changed, 72 insertions(+)

diff --git a/revision.c b/revision.c
index 95d21e6..fa16b9d 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
 #include "decorate.h"
 #include "log-tree.h"
 #include "string-list.h"
+#include "mailmap.h"
 
 volatile show_early_output_fn_t show_early_output;
 
@@ -2219,6 +2220,51 @@ static int rewrite_parents(struct rev_info *revs, struct 
commit *commit)
return 0;
 }
 
+static int commit_rewrite_person(struct strbuf *buf, const char *what, struct 
string_list *mailmap)
+{
+   char *person, *endp;
+   size_t len;
+   struct strbuf name = STRBUF_INIT;
+   struct strbuf mail = STRBUF_INIT;
+   struct ident_split ident;
+
+   person = strstr(buf->buf, what);
+   if (!person)
+   goto left_intact;
+
+   person += strlen(what);
+   endp = strchr(person, '\n');
+   if (!endp)
+   goto left_intact;
+
+   len = endp - person;
+
+   if (split_ident_line(&ident, person, len))
+   goto left_intact;
+
+   strbuf_add(&name, ident.name_begin, ident.name_end - ident.name_begin);
+   strbuf_add(&mail, ident.mail_begin, ident.mail_end - ident.mail_begin);
+
+   if (map_user(mailmap, &mail, &name)) {
+   strbuf_addf(&name, " <%s>", mail.buf);
+
+   strbuf_splice(buf, ident.name_begin - buf->buf,
+ ident.mail_end - ident.name_begin + 1,
+ name.buf, name.len);
+
+   strbuf_release(&name);
+   strbuf_release(&mail);
+
+   return 1;
+   }
+
+left_intact:
+   strbuf_release(&name);
+   strbuf_release(&mail);
+
+   return 0;
+}
+
 static int commit_match(struct commit *commit, struct rev_info *opt)
 {
int retval;
@@ -2237,6 +2283,14 @@ static int commit_match(struct commit *commit, struct 
rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
 
+   if (opt->mailmap) {
+   if (!buf.len)
+   strbuf_addstr(&buf, commit->buffer);
+
+   commit_rewrite_person(&buf, "\nauthor ", opt->mailmap);
+   commit_rewrite_person(&buf, "\ncommitter ", opt->mailmap);
+   }
+
/* Append "fake" message parts as needed */
if (opt->show_notes) {
if (!buf.len)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db043dc..e16187f 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -248,11 +248,29 @@ Author: Other Author 
 Author: Some Dude 
 Author: A U Thor 
 EOF
+
 test_expect_success 'Log output with --use-mailmap' '
git log --use-mailmap | grep Author >actual &&
test_cmp expect actual
 '
 
+cat >expect <<\EOF
+Author: Santa Claus 
+Author: Santa Claus 
+EOF
+
+test_expect_success 'Grep author with --use-mailmap' '
+   git log --use-mailmap --author Santa | grep Author >actual &&
+   test_cmp expect actual
+'
+
+>expect
+
+test_expect_success 'Only grep replaced author with --use-mailmap' '
+   git log --use-mailmap --author "" >actual &&
+   test_cmp expect actual
+'
+
 # git blame
 cat >expect <<\EOF
 ^OBJI (A U Thor DATE 1) one
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jeff King]

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 to me (point 3 in the table below).

By "committed", I assume you meat that you have "dirA/unco" as an
untracked file, and "dirA/committed" as a file in the index?

> Anyway I tried to make a table to sum-up/discuss the list of behaviors
> we would like to see/test, taking Jeff mail into account.
> (warning: that requires fixed width font)
> 
> |--+-+---|
> | Output   | A. status --ignored | B. status --ignored -uall |
> |  | | (or with potential|
> |  | | --ignored=all)|
> |--+-+---|
> | 1. Untracked dirU| Current:| Current:  |
> | with ignored unco.ig | Empty   | Empty |
> | in it| |   |
> |  | Expected:   | Expected: |
> |  | !!dirU/ | !!dirU/unco.ig|
> |--+-+---|
> | 2. Untracked and | Current (OK):   | Current:  |
> | ignored dirU with| !!dirU/ | !!dirU/   |
> | file in it   | |   |
> |  | | Expected: |
> |  | | !!dirU/unco   |
> |--+-+---|
> | 3. "Committed" dirA  | Current:| Current:  |
> | yet ignored  | Empty   | Empty |
> | with uncommitted | |   |
> | file in it   | Expected:   | Expected: |
> |  | dirA/   | dirA/unco |
> |--+-+---|

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 original report, case 2 is what I wrote in my mail, and case 3
is the one you just came up with). I can't think offhand of any others.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Antoine Pelisse]

> 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/discuss the list of behaviors
we would like to see/test, taking Jeff mail into account.
(warning: that requires fixed width font)

|--+-+---|
| Output   | A. status --ignored | B. status --ignored -uall |
|  | | (or with potential|
|  | | --ignored=all)|
|--+-+---|
| 1. Untracked dirU| Current:| Current:  |
| with ignored unco.ig | Empty   | Empty |
| in it| |   |
|  | Expected:   | Expected: |
|  | !!dirU/ | !!dirU/unco.ig|
|--+-+---|
| 2. Untracked and | Current (OK):   | Current:  |
| ignored dirU with| !!dirU/ | !!dirU/   |
| file in it   | |   |
|  | | Expected: |
|  | | !!dirU/unco   |
|--+-+---|
| 3. "Committed" dirA  | Current:| Current:  |
| yet ignored  | Empty   | Empty |
| with uncommitted | |   |
| file in it   | Expected:   | Expected: |
|  | dirA/   | dirA/unco |
|--+-+---|
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

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
into more desirable shape, without the final full-stop.

> The definition of "green" has changed in Tk 8.6:
>
> - http://wiki.tcl.tk/21276
> - http://www.tcl.tk/cgi-bin/tct/tip/403

Concise reference to the background information is very much
appreciated.  It would have been even nicer if you wrote one line
summary of it, e.g. "This change was to make Tk applications more in
line with Web standard colors."

> gitk looks pretty awkward with Tk 8.6. "green" is simply too dark now
> because it has changed from "#00FF00" to "#008000".

Your observation "awkward" is somewhat subjective and I am hesitant
to recommend this change without a better justification.  Given the
reasoning behind the change Tcl/Tk people made, I wouldn't be
surprised if people coming from webapp world view the "green" color
rendered by updated Tcl/Tk more natural.

Besides, if we are declaring with this patch that we will stick to
X11 colors and will not adopt W3C colors, the patch shouldn't update
only "green", but set all the other colors in stone, no?  "purple",
for example, is also different between X11 and W3C.

> One could also use "lime" instead of "#00FF00" but that would break
> compatibility with older versions of Tk.

A better solution might be to make these colors customizable.

> Signed-off-by: Peter Hofmann 
> ---
>  gitk-git/gitk | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Please make gitk patches against 

url = git://ozlabs.org/~paulus/gitk.git

which is my upstream maintained by Paul Mackerras 
(cc'ed) and keep him in the loop.

A patch against Paul's tree would have these lines

> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..d7e922b 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk

without "/gitk-git".

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Antoine Pelisse]

> 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 original report, case 2 is what I wrote in my mail, and case 3
> is the one you just came up with). I can't think offhand of any others.

Great, so I can build some tests reflecting those behaviors while
waiting more inputs
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alex Vandiver]

  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
git stash
git co HEAD~

$ 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 (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7)
foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a)
foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
fatal: git-write-tree: error building trees
Cannot save the current index state

 - Alex


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

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 mapped_name_or_email
>
> Of course it only works if the --use-mailmap option is used.
>
> Signed-off-by: Antoine Pelisse 
> ---

Thanks.  I'll queue this on top.

-- >8 --
Subject: [PATCH] log --use-mailmap: optimize for cases without 
--author/--committer search

When we taught the commit_match() mechanism to pay attention to the
new --use-mailmap option, we started to unconditionally copy the
commit object to a temporary buffer, just in case we need the author
and committer lines updated via the mailmap mechanism.

It turns out that this has a rather unpleasant performance
implications.  In the linux kernel repository, running

  $ git log --author='Junio C Hamano' --pretty=short >/dev/null

under /usr/bin/time, with and without --use-mailmap (the .mailmap
file is 118 entries long, the particular author does not appear in
it), cost (with warm cache):

  [without --use-mailmap]
  5.34user 0.25system 0:05.60elapsed 100%CPU (0avgtext+0avgdata 
2004832maxresident)k
  0inputs+0outputs (0major+137600minor)pagefaults 0swaps

  [with --use-mailmap]
  6.87user 0.24system 0:07.11elapsed 99%CPU (0avgtext+0avgdata 
2006352maxresident)k
  0inputs+0outputs (0major+137696minor)pagefaults 0swaps

which is with about 29% overhead.  The command is doing extra work,
so the extra cost may be justified.

But it is inexcusable to pay the cost when we do not need
author/committer match.  In the same repository,

  $ git log --grep='fix menuconfig on debian lenny' --pretty=short >/dev/null

shows very similar numbers as the above:

  [without --use-mailmap]
  5.30user 0.24system 0:05.55elapsed 99%CPU (0avgtext+0avgdata 
2004896maxresident)k
  0inputs+0outputs (0major+137604minor)pagefaults 0swaps

  [with --use-mailmap]
  6.82user 0.26system 0:07.07elapsed 100%CPU (0avgtext+0avgdata 
2006352maxresident)k
  0inputs+0outputs (0major+137697minor)pagefaults 0swaps

The latter case is an unnecessary performance regression.  We may
want to _show_ the result with mailmap applied, but we do not have
to copy and rewrite the author/committer of all commits we try to
match if we do not query for these fields.

Trivially optimize this performace regression by limiting the
rewrites for only when we are matching with author/committer fields.

Signed-off-by: Junio C Hamano 
---
 revision.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/revision.c b/revision.c
index fa16b9d..56b72f7 100644
--- a/revision.c
+++ b/revision.c
@@ -2283,7 +2283,7 @@ static int commit_match(struct commit *commit, struct 
rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
 
-   if (opt->mailmap) {
+   if (opt->grep_filter.header_list && opt->mailmap) {
if (!buf.len)
strbuf_addstr(&buf, commit->buffer);
 
-- 
1.8.1.rc3.221.g8d09d94

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

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: further
 optimize identity rewriting

We used to always allocate a temporary buffer to search for
author/committer names even when the author/committer does not
appear in the mailmap.  Update the logic to do the allocation
on demand to reduce needless malloc()/free() calls.

It turns out that this does not affect performance at all; all the
time is spent in map_user() which is a look-up in string_list, so
let's not use this patch in the production, but it illustrates an
interesting point.

In map_identities() function, we already know who the author
recorded in the commit is, either in "author" strbuf, or in buffer
between [a_at..a_len], so we could grep_buffer() the author
regexp(s) specified from the command line right there, and combine
that result with the main grep_buffer() done for the --grep= option
at the end of the commit_match() function.

That may essentially amount to going in the totally opposite
direction from what 2d10c55 (git log: Unify header_filter and
message_filter into one., 2006-09-20) attempted to do.  We used to
have two grep expressions (one for header, the other one for body)
commit_match() runs grep_buffer() on and combined the results.
2d10c55 merged them into one grep expression by introducing a term
that matches only header elements.  But we would instead split the
"header" expression into "author" and "committer" expressions
(making it three from one) if we go that route.

In any case, I *think* the bottleneck is in map_user() so until that
is solved, such an update (or this patch) is not very useful.

Signed-off-by: Junio C Hamano 
---
 revision.c | 95 +-
 1 file changed, 57 insertions(+), 38 deletions(-)

diff --git a/revision.c b/revision.c
index 56b72f7..4b66598 100644
--- a/revision.c
+++ b/revision.c
@@ -2220,49 +2220,73 @@ static int rewrite_parents(struct rev_info *revs, 
struct commit *commit)
return 0;
 }
 
-static int commit_rewrite_person(struct strbuf *buf, const char *what, struct 
string_list *mailmap)
+static void map_person(const char *buf, size_t len, const char *head, int 
headlen,
+  struct strbuf *result, struct string_list *mailmap,
+  int *matchofs, int *matchlen)
 {
-   char *person, *endp;
-   size_t len;
+   struct ident_split ident;
+   const char *endp, *person;
struct strbuf name = STRBUF_INIT;
struct strbuf mail = STRBUF_INIT;
-   struct ident_split ident;
 
-   person = strstr(buf->buf, what);
+   person = memmem(buf, len, head, headlen);
if (!person)
-   goto left_intact;
-
-   person += strlen(what);
+   return;
+   person += headlen;
endp = strchr(person, '\n');
if (!endp)
-   goto left_intact;
-
-   len = endp - person;
-
-   if (split_ident_line(&ident, person, len))
-   goto left_intact;
-
+   return;
+   *matchofs = person - buf;
+   *matchlen = endp - person;
+   if (split_ident_line(&ident, person, *matchlen))
+   return;
strbuf_add(&name, ident.name_begin, ident.name_end - ident.name_begin);
strbuf_add(&mail, ident.mail_begin, ident.mail_end - ident.mail_begin);
-
-   if (map_user(mailmap, &mail, &name)) {
-   strbuf_addf(&name, " <%s>", mail.buf);
-
-   strbuf_splice(buf, ident.name_begin - buf->buf,
- ident.mail_end - ident.name_begin + 1,
- name.buf, name.len);
-
-   strbuf_release(&name);
-   strbuf_release(&mail);
-
-   return 1;
-   }
-
-left_intact:
+   if (map_user(mailmap, &mail, &name))
+   strbuf_addf(result, "%s <%s>", name.buf, mail.buf);
strbuf_release(&name);
strbuf_release(&mail);
+}
 
-   return 0;
+static void map_identities(struct strbuf *buf, const char *buffer, struct 
string_list *mailmap)
+{
+   const char *eob;
+   struct strbuf author = STRBUF_INIT;
+   struct strbuf committer = STRBUF_INIT;
+   int a_at = -1, a_len, c_at = -1, c_len;
+
+   eob = strstr(buffer, "\n\n");
+   if (!eob)
+   eob = buffer + strlen(buffer);
+   map_person(buffer, eob - buffer, "\nauthor ", 8, &author, mailmap,
+  &a_at, &a_len);
+   map_person(buffer, eob - buffer, "\ncommitter ", 11, &committer, 
mailmap,
+  &c_at, &c_len);
+   if (!author.len && !committer.len)
+   goto done;
+
+   /* Now, we know we need rewriting */
+   if (!buf->len)
+   strbuf_addstr(buf, buffer);
+
+   if (c_at < 0

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

[Junio C Hamano]

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 (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7)
> foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a)
> foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
> fatal: git-write-tree: error building trees
> Cannot save the current index state

This is totally expected, isn't it?

You do not save state in the middle of a conflict with "git stash"
(instead, you would "git stash" away your own work in progress
before you start operation that may create and leave conflicts).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alex Vandiver]

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)
> > fatal: git-write-tree: error building trees
> > Cannot save the current index state
> 
> This is totally expected, isn't it?
> 
> You do not save state in the middle of a conflict with "git stash"
> (instead, you would "git stash" away your own work in progress
> before you start operation that may create and leave conflicts).

Apologies for not being clear.  While being unable to stash is not
unexpected, perhaps, "Cannot stash while resolving conflicts" or similar
would be more understandable to the end user than the above.
 - Alex

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jeff King]

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 (a77fa514de2720c72c1a861de098595959a2c97a)
> > > foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
> > > fatal: git-write-tree: error building trees
> > > Cannot save the current index state
> > 
> > This is totally expected, isn't it?
> > 
> > You do not save state in the middle of a conflict with "git stash"
> > (instead, you would "git stash" away your own work in progress
> > before you start operation that may create and leave conflicts).
> 
> Apologies for not being clear.  While being unable to stash is not
> unexpected, perhaps, "Cannot stash while resolving conflicts" or similar
> would be more understandable to the end user than the above.

Yeah, I think the outcome is reasonable, but that message is just
horrible. Something like this might be better:

diff --git a/git-stash.sh b/git-stash.sh
index 688e259..7ea425c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -217,6 +217,12 @@ save_stash () {
 
stash_msg="$*"
 
+   if ! git diff-index --cached --diff-filter=U --quiet HEAD; then
+   echo >&2 "fatal: unable to stash unmerged entries:"
+   git diff-index --cached --diff-filter=U --name-status HEAD
+   exit 1
+   fi
+
git update-index -q --refresh
if no_changes
then

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.

  2. Unmerged entries are only one reason that write-tree might fail.
 It's OK not to catch them all (since ultimately write-tree will
 complain if need be), but we may want to also handle intent-to-add
 entries with a nicer message.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

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) ||
die "$(gettext "Cannot apply a stash in the middle of a merge")"

since 5fd448f (git stash: Give friendlier errors when there is
nothing to apply, 2009-08-11).  I would think something in line with
that change on the "create" side is a welcome one.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

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.  If the
only expected failure case is unmerged entries, it should be
sufficient to protect these two (and the one in apply_stash is
already covered, I think).

>   2. Unmerged entries are only one reason that write-tree might fail.
>  It's OK not to catch them all (since ultimately write-tree will
>  complain if need be), but we may want to also handle intent-to-add
>  entries with a nicer message.

Hrmph.

We used to fail write-tree when I-T-A entries existed and relied on
that behaviour to implement "no state lost"; as we broke write-tree
recently by allowing to write a tree out by pretending that I-T-A
entries do not exist, I think we broke it.  Stashing with I-T-A and
then unstashing it may lose the file.  Sigh...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Python version auditing followup

[Dennis Kaarsemaker]

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, seems
like a reasonable cut-off point).
-- 
Dennis Kaarsemaker

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Martin Fick]

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 
always be cleaned up manually (and it is a rare occurrence).  
However, in a multi user server environment, possibly even 
from multiple hosts over a shared filesystem such as NFS, 
stale locks could lead to serious downtime and risky recovery 
(since it is currently hard to figure out if a lock really is 
stale).  Even though stale locks are probably rare even today 
in the larger shared repo case, as git scales to even larger 
shared repositories, this will eventually become more of a 
problem *1.  Naturally, this has me thinking that git should 
possibly consider moving towards a lockless design for refs 
in the long term.

I realize this is hard and that git needs to support many 
different filesystems with different semantics.  I had an idea I 
think may be close to a functional lockless design for loose 
refs (one piece at a time) that I thought I should propose, 
just to get the ball rolling, even if it is just going to be 
found to be flawed (I realize that history suggests that such 
schemes usually are).  I hope that it does not make use of 
any semantics which are not currently expected from git of 
filesystems.  I think it relies only on the ability to rename 
a file atomically, and the ability to scan the contents of a 
directory reliably to detect the "ordered" existence of files.

My idea is based on using filenames to store sha1s instead of 
file contents.  To do this, the sha1 one of a ref would be 
stored in a file in a directory named after the loose ref.  I 
believe this would then make it possible to have lockless 
atomic ref updates by renaming the file.

To more fully illustrate the idea, imagine that any file 
(except for the null file) in the directory will represent the 
value of the ref with its name, then the following 
transitions can represent atomic state changes to a refs 
value and existence:

1) To update the value from a known value to a new value 
atomically, simply rename the file to the new value.  This 
operation should only succeed if the file exists and is still 
named old value before the rename.  This should even be 
faster than today's approach, especially on remote filesystems 
since it would require only 1 round trip in the success case 
instead of 3!

2) To delete the ref, simply delete the filename representing 
the current value of the ref.  This ensures that you are 
deleting the ref from a specific value.  I am not sure if git 
needs to be able to delete refs without knowing their values?  
If so, this would require reading the value and looping until 
the delete succeeds, this may be a bit slow for a constantly 
updated ref, but likely a rare situation (and not likely 
worse than trying to acquire the ref-lock today).  Overall, 
this again would likely be faster than today's approach.

3) To create a ref, it must be renamed from the null file (sha 
...) to the new value just as if it were being updated 
from any other value, but there is one extra condition: 
before renaming the null file, a full directory scan must be 
done to ensure that the null file is the only file in the 
directory (this condition exists because creating the 
directory and null file cannot be atomic unless the filesystem 
supports atomic directory renames, an expectation git does 
not currently make).  I am not sure how this compares to 
today's approach, but including the setup costs (described 
below), I suspect it is slower.

While this outlines the state changes, some additional 
operations may be needed to setup some starting conditions 
and to clean things up. But these operations could/should be 
performed by any process/thread and would not cause any state 
changes to the ref existence or value.  For example, when 
creating a ref, the ref directory would need to be created 
and the null file needs to be created.  Whenever a null file is 
detected in the directory at the same time as another file, it 
should be deleted.   Whenever the directory is empty, it may 
be deleted (perhaps after a grace period to reduce retries 
during ref creation unless the process just deleted the ref).

I don't know how this new scheme could be made to work with 
the current scheme, it seems like perhaps new git releases 
could be made to understand both the old and the new, and a 
config option could be used to tell it which method to write 
new refs with.  Since in this new scheme ref directory names 
would conflict with old ref filenames, this would likely 
prevent both schemes from erroneously being used 
simultaneously (so they shouldn't corrupt each other), except 
for the fact that refs can be nested in directories which 
confuses things a bit.  I am not sure what a good solution to 
this is?

[ANNOUNCE] Git v1.8.0.3

[Junio C Hamano]

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.com/p/git-core/downloads/list

and their SHA-1 checksums are:

b1695f28448c00e61e110b3c7bcd66c8047ef176  git-1.8.0.3.tar.gz
83c46b62e0c3979c5ef77a407ca41507658b5726  git-htmldocs-1.8.0.3.tar.gz
63df55f90b9c6c11dd827ce1880b5b5fdf79c1c1  git-manpages-1.8.0.3.tar.gz

Also the following public repositories all have a copy of the v1.8.0.3
tag and the maint branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v1.8.0.3 Release Notes
==

Fixes since v1.8.0.2


 * "git log -p -S" did not apply the textconv filter while
   looking for the .

 * In the documentation, some invalid example e-mail addresses were
   formatted into mailto: links.

Also contains many documentation updates backported from the 'master'
branch that is preparing for the upcoming 1.8.1 release.



Changes since v1.8.0.2 are as follows:

Adam Spiers (2):
  SubmittingPatches: add convention of prefixing commit messages
  Documentation: move support for old compilers to CodingGuidelines

Anders Kaseorg (1):
  git-prompt: Document GIT_PS1_DESCRIBE_STYLE

Chris Rorvick (2):
  Documentation/git-checkout.txt: clarify usage
  Documentation/git-checkout.txt: document 70c9ac2 behavior

Gunnlaugur Þór Briem (1):
  Document git-svn fetch --log-window-size parameter

Jeff King (7):
  pickaxe: hoist empty needle check
  pickaxe: use textconv for -S counting
  .mailmap: match up some obvious names/emails
  .mailmap: fix broken entry for Martin Langhoff
  .mailmap: normalize emails for Jeff King
  .mailmap: normalize emails for Linus Torvalds
  contrib: update stats/mailmap script

John Keeping (1):
  Documentation: don't link to example mail addresses

Junio C Hamano (6):
  fetch --tags: clarify documentation
  README: it does not matter who the current maintainer is
  t7004: do not create unneeded gpghome/gpg.conf when GPG is not used
  Documentation: Describe "git diff  " separately
  git(1): show link to contributor summary page
  Git 1.8.0.3

Krzysztof Mazur (1):
  doc: git-reset: make "" optional

Manlio Perillo (1):
  git.txt: add missing info about --git-dir command-line option

Matthew Daley (1):
  Fix sizeof usage in get_permutations

Max Horn (1):
  git-remote-helpers.txt: document invocation before input format

Nguyễn Thái Ngọc Duy (1):
  index-format.txt: clarify what is "invalid"

Ramkumar Ramachandra (1):
  Documentation: move diff.wordRegex from config.txt to diff-config.txt

Sebastian Leske (4):
  git-svn: Document branches with at-sign(@).
  git-svn: Recommend use of structure options.
  git-svn: Expand documentation for --follow-parent
  git-svn: Note about tags.

Sitaram Chamarty (1):
  clarify -M without % symbol in diff-options

Stefano Lattarini (1):
  README: Git is released under the GPLv2, not just "the GPL"

Thomas Ackermann (8):
  Split over-long synopsis in git-fetch-pack.txt into several lines
  Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some 
sha1
  Change headline of technical/send-pack-pipeline.txt to not confuse its 
content with content from git-send-pack.txt
  Documentation/technical: convert plain text files to asciidoc
  Documentation/howto: convert plain text files to asciidoc
  Documentation: build html for all files in technical and howto
  Remove misleading date from api-index-skel.txt
  Sort howto documents in howto-index.txt

Tom Jones (1):
  Add -S, --gpg-sign option to manpage of "git commit"

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nike air max 95

[jasen]

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 body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thomas Sabo - History

[jasen]

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
valuable metals silver jewelry brand was found by self made man Thomas Sabo.
In a picture which happens to be the sole picture of Thomas riding a
motorbike, he gives a look of a heavy rock-and-roll singer with hair which
are curled and he adorn his look with a jacket and a pair of sharp-head
boots.

Thomas Sabo    established his own
jewelry company. The headquarters of the company was located in a historical
town of Bavaria this company stood out for its quality in silver jewelry and
with an extraordinary quality of design from the very beginning. In addition
to designing of silver ornaments, Thomas Sabo's interest also lies in music
and hence rock & roll spirit happened to be the design topic of the products
in quite a few time of year.

The retailers kept ordering volumes for the jewelry with every fair trade.
It was at this time that the silver jewelry was obtained anonymously. It was
this time that  Thomas Sabo   
decided to start a brand of his own. This was primarily around late 1980's.
Designer Susanne Kolbli services were secured as the company's creative
director, in early 1990. Many customers were won over for this jewelry brand
due to the successful cooperation of both of them jointly.

The brand developed its own distinctive way, a distinguishing face due to
constant support and designs by both of them. They had an eye for detail, an
amazing compassion for the material and a sixth sense for fashions and
trends. A complete new segment was created for the market because of this.

Looking at the amazing success achieved, by the end of 1990 his company
determined to establish retail outlets of its own. Throughout Asia, Europe
and America exclusive stores, sales agencies and shops were set in different
countries in rapid succession. Thomas Sabo changed from being a secretive
protection of fashion insiders to getting developed as a well-built,
globally acknowledged brand.

The most popular collection of  Thomas Sabo
   Charm Club Collection was
originated with the creative director Susanne Kolbli's idea. Today fashion
has more freedom than ever before. There are diverse trends all over and so
is their collection.

The collection of jewellery and watches suit almost all diverse outfits and
occasions which covers business attire, festive clothing, and casual-look
clothing. The different collections can be united, or enhance each other's
look.

Twice a year fresh ideas are floated in the collection. These new ideas of
jewelry are launched every spring as well as autumn in correspondence with
the foremost international fashion shows in Milan, London, Paris and New
York.

The history of Thomas Sabo has been quite an interesting one and gives you
an amazing choice with different styles and designs of jewelry offered by 
Thomas Sabo    Charm Club
Collection to choose from.


more details at:
http://www.thomassabouksaleonline2013.co.uk/
http://www.thomassabosaleuk2013.co.uk/
http://www.thomassabosaleonline2013.co.uk/
http://www.thomassaboukonlinesale2013.co.uk/
http://www.thomassaboukonline2013.co.uk/
http://www.thomassabosalecharms2013.co.uk/
http://www.thomassaboukonlinestores2013.co.uk/
http://www.thomassabouksaleonline2013.co.uk/



--
View this message in context: 
http://git.661346.n2.nabble.com/Thomas-Sabo-History-tp7573748.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David]

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
\
 J

I do this:

$ git log --graph --branches --simplify-by-decoration --source --oneline
* 00a27e0   J
| * 160d232 I
|/
| * daa5b69 H
|/
* 734db0c   A

and similar in gitk using the View > Edit View > Simple History = 1
This is a great step forward for me! I am very happy with it.

Is there any way to ask git log to additionally display all commits with
more than one child, to show where each branch diverges?

So I hope to see:

* 00a27e0   J
| * 160d232 I
|/
* b981ea0   G
| * daa5b69 H
|/
* 546ae44   C
* 734db0c   A

I have read man git-log but I do not understand it all. If there is a way to
achieve this then I am not seeing it.

I notice that there is commit limiting by --merges and --no-merges.
If --merges means "show only commits with more than one parent", and
--no-merges means "show only commits with only one parent", what I
want is "show also commits with more than one child".

Or perhaps "show only commits with more than one parent or child".

Is there a way to do this? It will be nice if it also works in gitk.
Presently I have git version 1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David]

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 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
> \
>  J
>
> I do this:
>
> $ git log --graph --branches --simplify-by-decoration --source --oneline
> * 00a27e0   J
> | * 160d232 I
> |/
> | * daa5b69 H
> |/
> * 734db0c   A
>
> and similar in gitk using the View > Edit View > Simple History = 1
> This is a great step forward for me! I am very happy with it.
>
> Is there any way to ask git log to additionally display all commits with
> more than one child, to show where each branch diverges?
>
> So I hope to see:
>
> * 00a27e0   J
> | * 160d232 I
> |/
> * b981ea0   G
> | * daa5b69 H
> |/
> * 546ae44   C
> * 734db0c   A
>
> I have read man git-log but I do not understand it all. If there is a way
> to
> achieve this then I am not seeing it.
>
> I notice that there is commit limiting by --merges and --no-merges.
> If --merges means "show only commits with more than one parent", and
> --no-merges means "show only commits with only one parent", what I
> want is "show also commits with more than one child".
>
> Or perhaps "show only commits with more than one parent or child".
>
> Is there a way to do this? It will be nice if it also works in gitk.
> Presently I have git version 1.7.2.3
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyễn Thái Ngọc Duy]

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.git file list.
 is 2000. The complete command list is at the end.

wildmatch is beaten in the following cases. Apparently it needs some
improvement in FNM_PATHNAME case:

glibc, '*/*/*' with FNM_PATHNAME:
wildmatch 8s 1559us
fnmatch   1s 11877us or 12.65% faster

compat, '*/*/*' with FNM_PATHNAME:
wildmatch 7s 922458us
fnmatch   2s 905111us or 36.67% faster

compat, '*/*/*' without FNM_PATHNAME:
wildmatch 7s 264201us
fnmatch   2s 1897us or 27.56% faster

compat, '[a-z]*/[a-z]*/[a-z]*' with FNM_PATHNAME:
wildmatch 8s 742827us
fnmatch   0s 922943us or 10.56% faster

compat, '[a-z]*/[a-z]*/[a-z]*' without FNM_PATHNAME:
wildmatch 8s 284520us
fnmatch   0s 6936us or 0.08% faster

The rest of glibc numbers
-

'Documentation/*'
wildmatch 1s 529479us
fnmatch   1s 98263us or 71.81% slower

'drivers/*'
wildmatch 1s 988288us
fnmatch   1s 192049us or 59.95% slower

'Documentation/*' pathname
wildmatch 1s 557507us
fnmatch   1s 93696us or 70.22% slower

'drivers/*' pathname
wildmatch 2s 161626us
fnmatch   1s 230372us or 56.92% slower

'[Dd]ocu[Mn]entation/*'
wildmatch 1s 776581us
fnmatch   1s 471693us or 82.84% slower

'[Dd]o?u[Mn]en?ati?n/*'
wildmatch 1s 770770us
fnmatch   1s 555727us or 87.86% slower

'[Dd]o?u[Mn]en?ati?n/*' pathname
wildmatch 1s 783507us
fnmatch   1s 537029us or 86.18% slower

'[A-Za-z][A-Za-z]??*'
wildmatch 4s 110386us
fnmatch   4s 926306us or 119.85% slower

'[A-Za-z][A-Za-z]??'
wildmatch 3s 918114us
fnmatch   3s 686175us or 94.08% slower

'[A-Za-z][A-Za-z]??*' pathname
wildmatch 4s 453746us
fnmatch   4s 955856us or 111.27% slower

'[A-Za-z][A-Za-z]??' pathname
wildmatch 3s 896646us
fnmatch   3s 733828us or 95.82% slower

'*/*/*'
wildmatch 7s 287985us
fnmatch   1s 74083us or 14.74% slower

'[a-z]*/[a-z]*/[a-z]*' pathname
wildmatch 8s 796659us
fnmatch   1s 568409us or 17.83% slower

'[a-z]*/[a-z]*/[a-z]*'
wildmatch 8s 316559us
fnmatch   3s 430652us or 41.25% slower

The rest of compat numbers
--

'Documentation/*'
wildmatch 1s 520389us
fnmatch   0s 62579us or 4.12% slower

'drivers/*'
wildmatch 1s 955354us
fnmatch   0s 190109us or 9.72% slower

'Documentation/*' pathname
wildmatch 1s 561675us
fnmatch   0s 55336us or 3.54% slower

'drivers/*' pathname
wildmatch 2s 106100us
fnmatch   0s 219680us or 10.43% slower

'[Dd]ocu[Mn]entation/*'
wildmatch 1s 750810us
fnmatch   0s 542721us or 31.00% slower

'[Dd]o?u[Mn]en?ati?n/*'
wildmatch 1s 724791us
fnmatch   0s 538948us or 31.25% slower

'[Dd]o?u[Mn]en?ati?n/*' pathname
wildmatch 1s 731403us
fnmatch   0s 537474us or 31.04% slower

'[A-Za-z][A-Za-z]??*'
wildmatch 4s 28555us
fnmatch   1s 67297us or 26.49% slower

'[A-Za-z][A-Za-z]??'
wildmatch 3s 838279us
fnmatch   0s 880005us or 22.93% slower

'[A-Za-z][A-Za-z]??*' pathname
wildmatch 4s 379476us
fnmatch   1s 55643us or 24.10% slower

'[A-Za-z][A-Za-z]??' pathname
wildmatch 3s 830910us
fnmatch   0s 849699us or 22.18% slower

The following commands are used:

LANG=C ./test-wildmatch perf /tmp/filelist.txt 'Documentation/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt 'drivers/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt 'Documentation/*' 2000 pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt 'drivers/*' 2000 pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[Dd]ocu[Mn]entation/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[Dd]o?u[Mn]en?ati?n/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[Dd]o?u[Mn]en?ati?n/*' 2000 
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??*' 2000 
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??' 2000 
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '*/*/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '*/*/*' 2000 pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[a-z]*/[a-z]*/[a-z]*' 2000 
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[a-z]*/[a-z]*/[a-z]*' 2000

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 test-wildmatch.c | 73 
 1 file changed, 73 insertions(+)

diff --git a/test-wildmatch.c b/test-wildmatch.c
index a5f4833..ac86800 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -1,9 +1,82 @@
 #include "cache.h"
 #include "wildmatch.h"
 
+static int perf(int ac, char **av)
+{
+   struct timeval tv1, tv2;
+   struct stat st;
+   int fd, i, n, flags1 = 0, flags2 = 0;
+   char *buffer, *p;
+   uint32_t usec1, usec2;
+   const char *lang;
+   const char *file = av[0];
+   const 

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

[Nguyễn Thái Ngọc Duy]

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 wildcards like ? and * in their patterns matched
against '/', just like not passing FNM_PATHNAME to fnmatch().

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 dir.c|  2 +-
 t/t3070-wildmatch.sh | 27 +++
 test-wildmatch.c |  6 --
 wildmatch.c  | 13 +
 wildmatch.h  |  1 +
 5 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/dir.c b/dir.c
index 175a182..6ef0396 100644
--- a/dir.c
+++ b/dir.c
@@ -595,7 +595,7 @@ int match_pathname(const char *pathname, int pathlen,
}
 
return wildmatch(pattern, name,
-ignore_case ? WM_CASEFOLD : 0,
+WM_PATHNAME | (ignore_case ? WM_CASEFOLD : 0),
 NULL) == 0;
 }
 
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index d5bafef..dbfa903 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -29,6 +29,18 @@ match() {
 fi
 }
 
+pathmatch() {
+if [ $1 = 1 ]; then
+   test_expect_success "pathmatch:match '$2' '$3'" "
+   test-wildmatch pathmatch '$2' '$3'
+   "
+else
+   test_expect_success "pathmatch: no match '$2' '$3'" "
+   ! test-wildmatch pathmatch '$2' '$3'
+   "
+fi
+}
+
 # Basic wildmat features
 match 1 1 foo foo
 match 0 0 foo bar
@@ -192,4 +204,19 @@ match 0 0 
'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/
 match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
 match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
 
+pathmatch 1 foo foo
+pathmatch 0 foo fo
+pathmatch 1 foo/bar foo/bar
+pathmatch 1 foo/bar 'foo/*'
+pathmatch 1 foo/bba/arr 'foo/*'
+pathmatch 1 foo/bba/arr 'foo/**'
+pathmatch 1 foo/bba/arr 'foo*'
+pathmatch 1 foo/bba/arr 'foo**'
+pathmatch 1 foo/bba/arr 'foo/*arr'
+pathmatch 1 foo/bba/arr 'foo/**arr'
+pathmatch 0 foo/bba/arr 'foo/*z'
+pathmatch 0 foo/bba/arr 'foo/**z'
+pathmatch 1 foo/bar 'foo?bar'
+pathmatch 1 foo/bar 'foo[/]bar'
+
 test_done
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 4bb23b4..a5f4833 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -12,9 +12,11 @@ int main(int argc, char **argv)
argv[i] += 3;
}
if (!strcmp(argv[1], "wildmatch"))
-   return !!wildmatch(argv[3], argv[2], 0, NULL);
+   return !!wildmatch(argv[3], argv[2], WM_PATHNAME, NULL);
else if (!strcmp(argv[1], "iwildmatch"))
-   return !!wildmatch(argv[3], argv[2], WM_CASEFOLD, NULL);
+   return !!wildmatch(argv[3], argv[2], WM_PATHNAME | WM_CASEFOLD, 
NULL);
+   else if (!strcmp(argv[1], "pathmatch"))
+   return !!wildmatch(argv[3], argv[2], 0, NULL);
else if (!strcmp(argv[1], "fnmatch"))
return !!fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 68e4213..0c8edb8 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 '?':
/* Match anything but '/'. */
-   if (t_ch == '/')
+   if ((flags & WM_PATHNAME) && t_ch == '/')
return WM_NOMATCH;
continue;
case '*':
if (*++p == '*') {
const uchar *prev_p = p - 2;
while (*++p == '*') {}
-   if ((prev_p == text || *prev_p == '/') ||
+   if (!(flags & WM_PATHNAME))
+   /* without WM_PATHNAME, '*' == '**' */
+   match_slash = 1;
+   else if ((prev_p == text || *prev_p == '/') ||
(*p == '\0' || *p == '/' ||
 (p[0] == '\\' && p[1] == '/'))) {
/*
@@ -103,7 +106,8 @@ static int dowild(const uchar *p, const uchar *text, 
unsigned int flags)
} else
return WM_ABORT_MALFORMED;
} else
-   match_slash = 0;
+   /* without WM_PATHNAME, '*' == '**' */
+   match_slash = flags & WM_PATHNAME ? 0 : 1;
if (*p == '\0') {
/* Trailing "**" matches everything.  Trailing 
"*" matches
 * only if there are no

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

[Nguyễn Thái Ngọc Duy]

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 is the only
place that NO_FNMATCH or NO_FNMATCH_CASEFOLD remain active when
USE_WILDMATCH is set.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Makefile  |  6 ++
 git-compat-util.h | 13 +
 test-wildmatch.c  |  3 +++
 3 files changed, 22 insertions(+)

diff --git a/Makefile b/Makefile
index bc868d1..24e2774 100644
--- a/Makefile
+++ b/Makefile
@@ -99,6 +99,9 @@ all::
 # Define NO_FNMATCH_CASEFOLD if your fnmatch function doesn't have the
 # FNM_CASEFOLD GNU extension.
 #
+# Define USE_WILDMATCH if you want to use Git's wildmatch
+# implementation as fnmatch
+#
 # Define NO_GECOS_IN_PWENT if you don't have pw_gecos in struct passwd
 # in the C library.
 #
@@ -1625,6 +1628,9 @@ ifdef NO_FNMATCH_CASEFOLD
COMPAT_OBJS += compat/fnmatch/fnmatch.o
 endif
 endif
+ifdef USE_WILDMATCH
+   COMPAT_CFLAGS += -DUSE_WILDMATCH
+endif
 ifdef NO_SETENV
COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
diff --git a/git-compat-util.h b/git-compat-util.h
index 02f48f6..b2c7638 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -106,7 +106,9 @@
 #include 
 #include 
 #include 
+#ifndef USE_WILDMATCH
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -238,6 +240,17 @@ extern char *gitbasename(char *);
 
 #include "compat/bswap.h"
 
+#ifdef USE_WILDMATCH
+#include "wildmatch.h"
+#define FNM_PATHNAME WM_PATHNAME
+#define FNM_CASEFOLD WM_CASEFOLD
+#define FNM_NOMATCH  WM_NOMATCH
+static inline int fnmatch(const char *pattern, const char *string, int flags)
+{
+   return wildmatch(pattern, string, flags, NULL);
+}
+#endif
+
 /* General helper functions */
 extern void vreportf(const char *prefix, const char *err, va_list params);
 extern void vwritef(int fd, const char *prefix, const char *err, va_list 
params);
diff --git a/test-wildmatch.c b/test-wildmatch.c
index ac86800..a3e2643 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -1,3 +1,6 @@
+#ifdef USE_WILDMATCH
+#undef USE_WILDMATCH  /* We need real fnmatch implementation here */
+#endif
 #include "cache.h"
 #include "wildmatch.h"
 
-- 
1.8.0.rc2.23.g1fb49df

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/9] fnmatch replacement step 1

[Nguyễn Thái Ngọc Duy]

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 Duy (9):
  compat/fnmatch: respect NO_FNMATCH* even on glibc
  wildmatch: replace variable 'special' with better named ones
  wildmatch: rename constants and update prototype
  wildmatch: make dowild() take arbitrary flags
  wildmatch: support "no FNM_PATHNAME" mode
  test-wildmatch: add "perf" command to compare wildmatch and fnmatch
  wildmatch: make a special case for "*/" with FNM_PATHNAME
  wildmatch: advance faster in  +  patterns
  Makefile: add USE_WILDMATCH to use wildmatch as fnmatch

 Makefile |   6 ++
 compat/fnmatch/fnmatch.c |   3 +-
 dir.c|   3 +-
 git-compat-util.h|  13 +
 t/t3070-wildmatch.sh |  41 +
 test-wildmatch.c |  82 +-
 wildmatch.c  | 147 +--
 wildmatch.h  |  23 +---
 8 files changed, 251 insertions(+), 67 deletions(-)

-- 
1.8.0.rc2.23.g1fb49df

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyễn Thái Ngọc Duy]

'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 --git a/wildmatch.c b/wildmatch.c
index 3972e26..8a58ad4 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -60,7 +60,7 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
uchar p_ch;
 
for ( ; (p_ch = *p) != '\0'; text++, p++) {
-   int matched, special;
+   int matched, match_slash, negated;
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
return ABORT_ALL;
@@ -102,15 +102,15 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
if (p[0] == '/' &&
dowild(p + 1, text, 
force_lower_case) == MATCH)
return MATCH;
-   special = TRUE;
+   match_slash = TRUE;
} else
return ABORT_MALFORMED;
} else
-   special = FALSE;
+   match_slash = FALSE;
if (*p == '\0') {
/* Trailing "**" matches everything.  Trailing 
"*" matches
 * only if there are no more slash characters. 
*/
-   if (!special) {
+   if (!match_slash) {
if (strchr((char*)text, '/') != NULL)
return NOMATCH;
}
@@ -120,9 +120,9 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
if (t_ch == '\0')
break;
if ((matched = dowild(p, text,  
force_lower_case)) != NOMATCH) {
-   if (!special || matched != 
ABORT_TO_STARSTAR)
+   if (!match_slash || matched != 
ABORT_TO_STARSTAR)
return matched;
-   } else if (!special && t_ch == '/')
+   } else if (!match_slash && t_ch == '/')
return ABORT_TO_STARSTAR;
t_ch = *++text;
}
@@ -134,8 +134,8 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
p_ch = NEGATE_CLASS;
 #endif
/* Assign literal TRUE/FALSE because of "matched" 
comparison. */
-   special = p_ch == NEGATE_CLASS? TRUE : FALSE;
-   if (special) {
+   negated = p_ch == NEGATE_CLASS? TRUE : FALSE;
+   if (negated) {
/* Inverted character class. */
p_ch = *++p;
}
@@ -217,7 +217,7 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
} else if (t_ch == p_ch)
matched = TRUE;
} while (prev_ch = p_ch, (p_ch = *++p) != ']');
-   if (matched == special || t_ch == '/')
+   if (matched == negated || t_ch == '/')
return NOMATCH;
continue;
}
-- 
1.8.0.rc2.23.g1fb49df

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyễn Thái Ngọc Duy]

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) (ISASCII(c) && isxdigit(c))
 
 /* Match pattern "p" against "text" */
-static int dowild(const uchar *p, const uchar *text, int force_lower_case)
+static int dowild(const uchar *p, const uchar *text, unsigned int flags)
 {
uchar p_ch;
 
@@ -61,9 +61,9 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
return WM_ABORT_ALL;
-   if (force_lower_case && ISUPPER(t_ch))
+   if ((flags & WM_CASEFOLD) && ISUPPER(t_ch))
t_ch = tolower(t_ch);
-   if (force_lower_case && ISUPPER(p_ch))
+   if ((flags & WM_CASEFOLD) && ISUPPER(p_ch))
p_ch = tolower(p_ch);
switch (p_ch) {
case '\\':
@@ -97,7 +97,7 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
 * both foo/bar and foo/a/bar.
 */
if (p[0] == '/' &&
-   dowild(p + 1, text, 
force_lower_case) == WM_MATCH)
+   dowild(p + 1, text, flags) == 
WM_MATCH)
return WM_MATCH;
match_slash = 1;
} else
@@ -116,7 +116,7 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
while (1) {
if (t_ch == '\0')
break;
-   if ((matched = dowild(p, text,  
force_lower_case)) != WM_NOMATCH) {
+   if ((matched = dowild(p, text, flags)) != 
WM_NOMATCH) {
if (!match_slash || matched != 
WM_ABORT_TO_STARSTAR)
return matched;
} else if (!match_slash && t_ch == '/')
@@ -227,6 +227,5 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
 int wildmatch(const char *pattern, const char *text,
  unsigned int flags, struct wildopts *wo)
 {
-   return dowild((const uchar*)pattern, (const uchar*)text,
- flags & WM_CASEFOLD ? 1 :0);
+   return dowild((const uchar*)pattern, (const uchar*)text, flags);
 }
-- 
1.8.0.rc2.23.g1fb49df

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyễn Thái Ngọc Duy]

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 +
 2 files changed, 27 insertions(+)

diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 4cdb13b..dcbc8bc 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -207,6 +207,9 @@ match 0 x foo '*/*/*'
 match 0 x foo/bar '*/*/*'
 match 1 x foo/bba/arr '*/*/*'
 match 0 x foo/bb/aa/rr '*/*/*'
+match 1 x abcXdefXghi '*X*i'
+match 0 x ab/cXd/efXg/hi '*X*i'
+match 1 x ab/cXd/efXg/hi '*/*X*/*/*i'
 
 pathmatch 1 foo foo
 pathmatch 0 foo fo
@@ -226,5 +229,8 @@ pathmatch 0 foo '*/*/*'
 pathmatch 0 foo/bar '*/*/*'
 pathmatch 1 foo/bba/arr '*/*/*'
 pathmatch 1 foo/bb/aa/rr '*/*/*'
+pathmatch 1 abcXdefXghi '*X*i'
+pathmatch 1 ab/cXd/efXg/hi '*/*X*/*/*i'
+pathmatch 1 ab/cXd/efXg/hi '*Xg*i'
 
 test_done
diff --git a/wildmatch.c b/wildmatch.c
index f6d45d5..40eda08 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -132,6 +132,27 @@ static int dowild(const uchar *p, const uchar *text, 
unsigned int flags)
while (1) {
if (t_ch == '\0')
break;
+   /*
+* Try to advance faster when an asterisk is
+* followed by a literal. We know in this case
+* that the the string before the literal
+* must belong to "*".
+*/
+   if (!is_glob_special(*p)) {
+   p_ch = *p;
+   if ((flags & WM_CASEFOLD) && 
ISUPPER(p_ch))
+   p_ch = tolower(p_ch);
+   while ((t_ch = *text) != '\0' &&
+  (!(flags & WM_PATHNAME) || t_ch 
!= '/')) {
+   if ((flags & WM_CASEFOLD) && 
ISUPPER(t_ch))
+   t_ch = tolower(t_ch);
+   if (t_ch == p_ch)
+   break;
+   text++;
+   }
+   if (t_ch != p_ch)
+   return WM_NOMATCH;
+   }
if ((matched = dowild(p, text, flags)) != 
WM_NOMATCH) {
if (!match_slash || matched != 
WM_ABORT_TO_STARSTAR)
return matched;
-- 
1.8.0.rc2.23.g1fb49df

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyễn Thái Ngọc Duy]

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 @@
program understand `configure --with-gnu-libc' and omit the object files,
it is simpler to just do this in the source for each such file.  */
 
-#if defined _LIBC || !defined __GNU_LIBRARY__
+#if defined NO_FNMATCH || defined NO_FNMATCH_CASEFOLD || \
+defined _LIBC || !defined __GNU_LIBRARY__
 
 
 # if defined STDC_HEADERS || !defined isascii
-- 
1.8.0.rc2.23.g1fb49df

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyễn Thái Ngọc Duy]

- 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 change the prototype again later
  when we need to pass other stuff to wildmatch

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 dir.c|  3 +-
 test-wildmatch.c |  4 +--
 wildmatch.c  | 88 +++-
 wildmatch.h  | 22 +-
 4 files changed, 62 insertions(+), 55 deletions(-)

diff --git a/dir.c b/dir.c
index cb7328b..175a182 100644
--- a/dir.c
+++ b/dir.c
@@ -595,7 +595,8 @@ int match_pathname(const char *pathname, int pathlen,
}
 
return wildmatch(pattern, name,
-ignore_case ? FNM_CASEFOLD : 0) == 0;
+ignore_case ? WM_CASEFOLD : 0,
+NULL) == 0;
 }
 
 /* Scan the list and let the last match determine the fate.
diff --git a/test-wildmatch.c b/test-wildmatch.c
index e384c8e..4bb23b4 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -12,9 +12,9 @@ int main(int argc, char **argv)
argv[i] += 3;
}
if (!strcmp(argv[1], "wildmatch"))
-   return !!wildmatch(argv[3], argv[2], 0);
+   return !!wildmatch(argv[3], argv[2], 0, NULL);
else if (!strcmp(argv[1], "iwildmatch"))
-   return !!wildmatch(argv[3], argv[2], FNM_CASEFOLD);
+   return !!wildmatch(argv[3], argv[2], WM_CASEFOLD, NULL);
else if (!strcmp(argv[1], "fnmatch"))
return !!fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 8a58ad4..f9b6451 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -18,9 +18,6 @@ typedef unsigned char uchar;
 #define NEGATE_CLASS   '!'
 #define NEGATE_CLASS2  '^'
 
-#define FALSE 0
-#define TRUE 1
-
 #define CC_EQ(class, len, litmatch) ((len) == sizeof (litmatch)-1 \
&& *(class) == *(litmatch) \
&& strncmp((char*)class, litmatch, len) == 
0)
@@ -63,7 +60,7 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
int matched, match_slash, negated;
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
-   return ABORT_ALL;
+   return WM_ABORT_ALL;
if (force_lower_case && ISUPPER(t_ch))
t_ch = tolower(t_ch);
if (force_lower_case && ISUPPER(p_ch))
@@ -76,12 +73,12 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
/* FALLTHROUGH */
default:
if (t_ch != p_ch)
-   return NOMATCH;
+   return WM_NOMATCH;
continue;
case '?':
/* Match anything but '/'. */
if (t_ch == '/')
-   return NOMATCH;
+   return WM_NOMATCH;
continue;
case '*':
if (*++p == '*') {
@@ -100,135 +97,136 @@ static int dowild(const uchar *p, const uchar *text, int 
force_lower_case)
 * both foo/bar and foo/a/bar.
 */
if (p[0] == '/' &&
-   dowild(p + 1, text, 
force_lower_case) == MATCH)
-   return MATCH;
-   match_slash = TRUE;
+   dowild(p + 1, text, 
force_lower_case) == WM_MATCH)
+   return WM_MATCH;
+   match_slash = 1;
} else
-   return ABORT_MALFORMED;
+   return WM_ABORT_MALFORMED;
} else
-   match_slash = FALSE;
+   match_slash = 0;
if (*p == '\0') {
/* Trailing "**" matches everything.  Trailing 
"*" matches
 * only if there are no more slash characters. 
*/
if (!match_slash) {
if (strchr((char*)text, '/') != NULL)
-   return NOMATCH;
+   return WM_NOMATCH;
}
-   return MATCH;
+   return WM_MATCH;

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

[Nguyễn Thái Ngọc Duy]

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 99.06% slower

Same test with compat/fnmatch:
wildmatch 8s 110763us
fnmatch   2s 980845us or 36.75% faster
wildmatch 3s 522156us
fnmatch   1s 544487us or 43.85% slower

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 t/t3070-wildmatch.sh |  8 
 wildmatch.c  | 12 
 2 files changed, 20 insertions(+)

diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index dbfa903..4cdb13b 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -203,6 +203,10 @@ match 1 1 
'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/
 match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 
'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
 match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
 match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
+match 0 x foo '*/*/*'
+match 0 x foo/bar '*/*/*'
+match 1 x foo/bba/arr '*/*/*'
+match 0 x foo/bb/aa/rr '*/*/*'
 
 pathmatch 1 foo foo
 pathmatch 0 foo fo
@@ -218,5 +222,9 @@ pathmatch 0 foo/bba/arr 'foo/*z'
 pathmatch 0 foo/bba/arr 'foo/**z'
 pathmatch 1 foo/bar 'foo?bar'
 pathmatch 1 foo/bar 'foo[/]bar'
+pathmatch 0 foo '*/*/*'
+pathmatch 0 foo/bar '*/*/*'
+pathmatch 1 foo/bba/arr '*/*/*'
+pathmatch 1 foo/bb/aa/rr '*/*/*'
 
 test_done
diff --git a/wildmatch.c b/wildmatch.c
index 0c8edb8..f6d45d5 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -116,6 +116,18 @@ static int dowild(const uchar *p, const uchar *text, 
unsigned int flags)
return WM_NOMATCH;
}
return WM_MATCH;
+   } else if (*p == '/' && (flags & WM_PATHNAME) && 
!match_slash) {
+   /*
+* an asterisk followed by a slash
+* with WM_PATHNAME matches the next
+* directory
+*/
+   const char *slash = strchr((char*)text, '/');
+   if (!slash)
+   return WM_NOMATCH;
+   text = (const uchar*)slash;
+   /* the slash is consumed by the top-level for 
loop */
+   break;
}
while (1) {
if (t_ch == '\0')
-- 
1.8.0.rc2.23.g1fb49df

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Find the starting point of a local branch

[Woody Wu]

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 what's the staring reference point (a commit number
> >> or tag name) of a locally created branch? I can use gitk to find out it
> >> but this method is slow, I think there might be a command line to do it
> >> quickly.
> >>
> >> The answer is more complex than you probably suspected.
> >>
> >> Technically, `git log --oneline mybranch | tail -n 1` will tell you
> >> the starting point of any branch.  But...I'm sure that isn't what you
> >> want to know.
> >>
> >> You want to know "what commit was I at when I typed `git branch
> >> mybranch`"?
> >
> > Yes, this is exactly I want to know.
> >
> >>The problem is git doesn't record this information and
> >> doesn't have the slightest clue.
> >>
> >> But, you say, I can use `gitk` and see it.  See?  Right there.  That
> >> isn't (necessarily) the "starting point" of the branch, it is the
> >> place where your branch diverged from some other branch.  Git is
> >> actually quite able to tell you when the last time your branch
> >> diverged from some other branch.  `git merge-base mybranch master`
> >> will tell you this, and is probably the answer you were looking for.
> >
> > This is not working to me since I have more than one local branch that
> > diverged from the master, and in fact, the branch I have in question was
> > diverged from another local branch.
> 
> As Jeff mentions in a later message, "git pull --rebase" would
> probably do what you want. It works with local branches too.
> 

I think what 'git pull --rebase' would do is to fetch from the origin
and do a 'git rebase'.  On one hand, I don't understand 'git rebase' so
much from the manual, ont the other hand, I did not get the point why
'git rebase' has something to do with the thing I want to do (what I
want is just query some kind of history information).

I know, my knowledge about git is still so limit. I will keep study from
the man pages.


> I once tried to add the same cleverness that "git pull --rebase"
> directly in "git rebase" [1], but there were several issues with those
> patches, one of was regarding the performance ("git pull --rebase" can
> be equally slow, but since it often involves network, users probably
> rarely notice). I think it would be nice to at least add it as an
> option to "git rebase" some day. Until then, "git pull --rebase" works
> fine.
> 
>  [1] http://thread.gmane.org/gmane.comp.version-control.git/166710

-- 
woody
I can't go back to yesterday - because I was a different person then.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

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 '?':
>   /* Match anything but '/'. */
> - if (t_ch == '/')
> + if ((flags & WM_PATHNAME) && t_ch == '/')
>   return WM_NOMATCH;
>   continue;
>   case '*':
>   if (*++p == '*') {
>   const uchar *prev_p = p - 2;
>   while (*++p == '*') {}
> - if ((prev_p == text || *prev_p == '/') ||
> + if (!(flags & WM_PATHNAME))
> + /* without WM_PATHNAME, '*' == '**' */
> + special = 1;
> + else if ((prev_p == text || *prev_p == '/') ||

Not a new issue in this patch, but here, "prev_p" points into the
pattern string, two bytes before p, which is the byte before the
"**" that we are looking at (which might be before the beginning of
the pattern).  "text" is the string we are trying to match that
pattern against.  How can these two pointers be compared to yield a
meaningful value?

>   (*p == '\0' || *p == '/' ||
>(p[0] == '\\' && p[1] == '/'))) {

OK.  "**/", "**" (end of pattern), and "**\/" are handled here.  

Do we have to worry about "**[/]" the same way, or a class never
matches the directory separator, even if it is a singleton class
that consists of '/' (which is fine by me)?  If so, is "\/" more or
less like "[/]"?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

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 
> ---
>  wildmatch.c | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/wildmatch.c b/wildmatch.c
> index 3794c4d..68b02e4 100644
> --- a/wildmatch.c
> +++ b/wildmatch.c
> @@ -132,6 +132,27 @@ static int dowild(const uchar *p, const uchar *text, 
> unsigned int flags)
>   while (1) {
>   if (t_ch == '\0')
>   break;
> + /*
> +  * Try to advance faster when an asterisk is
> +  * followed by a literal. We know in this case
> +  * that the the string before the literal
> +  * must belong to "*".
> +  */
> + if (!is_glob_special(*p)) {

So far, we have looked at "*x" or "**x" in the pattern, p points at
'x' (not an asterisk), and we have "text" to match.  For "text" to
match this pattern, the earlier part of it that is consumed to match
the asterisk must be followed by "x".  "special" tells us if we are
allowed to treat '/' as matching the asterisk.

> + p_ch = *p;
> + if ((flags & WM_CASEFOLD) && 
> ISUPPER(p_ch))
> + p_ch = tolower(p_ch);

That "x" in the example is picked up here and stored in "p_ch".
Let's skip over "text" and find that "x" in there.

> + while ((t_ch = *text) != '\0' &&
> +(!(flags & WM_PATHNAME) || t_ch 
> != '/')) {

Why do we look at (flags & WM_PATHMAME) and not "special" here?

> + if ((flags & WM_CASEFOLD) && 
> ISUPPER(t_ch))
> + t_ch = tolower(t_ch);
> + if (t_ch == p_ch)
> + break;

Found it.

> + text++;
> + }
> + if (t_ch != p_ch)
> + return WM_NOMATCH;

If we did not find that "x", then "**x" or "*x" can never match.
OK.  And at this point "text" points at that "x" we found, and "p"
points at "x" after the asterisk in the pattern.

Looks good so far.  Thanks.

> + }
>   if ((matched = dowild(p, text,  flags)) != 
> WM_NOMATCH) {
>   if (!special || matched != 
> WM_ABORT_TO_STARSTAR)
>   return matched;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Find the starting point of a local branch

[Martin von Zweigbergk]

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 fact, the branch I have in question was
>> > diverged from another local branch.
>>
>> As Jeff mentions in a later message, "git pull --rebase" would
>> probably do what you want. It works with local branches too.
>>
>
> I think what 'git pull --rebase' would do is to fetch from the origin
> and do a 'git rebase'.

Not if the configured upstream is a local branch (see the
"branch..*" configuration variables). In that case it will just
rebase the local branch onto the new position of its upstream. If the
upstream is not configured, I believe you can still do "git pull
--rebase . ".

> On one hand, I don't understand 'git rebase' so
> much from the manual, ont the other hand, I did not get the point why
> 'git rebase' has something to do with the thing I want to do (what I
> want is just query some kind of history information).

I may have misunderstood or assumed things incorrectly that you wanted
to rebase the commits on your branch. So why do you want to know?
(Please ignore me if this was answered elsewhere in the thread that I
might have missed.)

Anyway, to answer your question, you could use a method similar to
what "git pull --rebase" uses internally to figure out the branch
point:

git merge-base $(git rev-parse ) $(git rev-list -g )

Hope that helps
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyen Thai Ngoc Duy]

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?

Because I was careless. Thanks for spotting it. I'll fix it and add
some more tests about ** with WM_PATHNAME.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nguyen Thai Ngoc Duy]

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 == '/') ||
>> + if (!(flags & WM_PATHNAME))
>> + /* without WM_PATHNAME, '*' == '**' */
>> + special = 1;
>> + else if ((prev_p == text || *prev_p == '/') ||
>
> Not a new issue in this patch,

No, it's an issue from nd/wildmatch, 40bbee0 (wildmatch: adjust "**"
behavior - 2012-10-15).

> but here, "prev_p" points into the
> pattern string, two bytes before p, which is the byte before the
> "**" that we are looking at (which might be before the beginning of
> the pattern).  "text" is the string we are trying to match that
> pattern against.  How can these two pointers be compared to yield a
> meaningful value?

They can't. I wanted to check whether "**" is at the start of the
pattern (so no preceding '/' needed) and used a wrong pointer to
compare to. Funny there is a test about this and it does not catch it
because prev_p access something before the pattern. Will fix.

>
>>   (*p == '\0' || *p == '/' ||
>>(p[0] == '\\' && p[1] == '/'))) {
>
> OK.  "**/", "**" (end of pattern), and "**\/" are handled here.
>
> Do we have to worry about "**[/]" the same way, or a class never
> matches the directory separator, even if it is a singleton class
> that consists of '/' (which is fine by me)?  If so, is "\/" more or
> less like "[/]"?

This is a special case of "**" with FNM_PATHNAME on. With
FNM_PATHNAME, '[]' and '?' cannot match '/' so any patterns with '[/]'
match nothing. I think we don't need to worry about this case.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html