date:20140214

On Thu, Feb 13, 2014 at 11:35:13AM -0800, Junio C Hamano wrote:

test_normalize_tristate GIT_TEST_DAEMON
 
  Heh, great minds think alike.  This is what I am playing with,
  without committing (because I do like your ask config if this is a
  kind of various boolean 'false' representations, which I haven't
  managed to add to it).
 
 And this is with the ask config helper.

Thanks for picking this up.

 Two tangents.
 
  - We may want to do something similar in cvsserver and git-gui to
make them more robust.
 
$ git grep -e true --and -e 1 --and -e yes

I assume the something here is to respect bool options more
consistently? I have no problem with that, but nor do I care too much
about those programs (that is partially laziness, but also partially
that I do not want to deal with introducing a regression).

  - Do we want to do something similar to GIT_TEST_CREDENTIAL_HELPER?

No, it is not a boolean. It is a bit of a hack, but it is meant to be
used like:

  GIT_TEST_CREDENTIAL_HELPER=foo ./t0303-*

to test some random git-credential-foo you have in your PATH. There is
nothing to run by default there. It would be sensible to hook
contrib/credential to it, though.

 -- 8 --
 From: Jeff King p...@peff.net
 Date: Mon, 10 Feb 2014 16:29:37 -0500
 Subject: [PATCH] tests: turn on network daemon tests by default
 [...]
 In addition, we are forgiving of common setup failures (e.g., you do
 not have apache installed, or have an old version) when the
 tri-state is auto (or empty), but report an error when it is

You probably want to drop this or empty or change it to or unset,
given the magic we do with empty-but-set variables in this version.

 ---
  t/lib-git-daemon.sh |  8 ---
  t/lib-httpd.sh  | 22 +--
  t/test-lib-functions.sh | 58 
 +
  3 files changed, 74 insertions(+), 14 deletions(-)

Patch looks good to me.

-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: Git GSoC 2014

On Thu, Feb 13, 2014 at 06:17:17PM -0500, Ramkumar Ramachandra wrote:

 I'll throw in a few ideas from half-finished work.

Thanks. A few comments:

 1. Speed up git-rebase--am.sh
 
 Currently, git-rebase--am.sh is really slow because it dumps each
 patch to a file using git-format-patch, and picks it up to apply
 subsequently using git-am. Find a way to speed this up, without
 sacrificing safety. You can use the continuation features of
 cherry-pick, and dump to file only to persist state in the case of a
 failure.

Isn't the merge backend faster? I thought that was the point of it.

 3. Rewrite git-branch to use git-for-each-ref
 
 For higher flexibility in command-line options and output format, use
 git for-each-ref to re-implement git-branch. The first task is to grow
 features that are in branch but not fer into fer (like --column,
 --merged, --contains). The second task is to refactor fer so that an
 external program can call into it.

I actually have this about 95% done, waiting for the patches to be
polished. So I don't think it makes a good GSoC project (it would be
stupid to start from scratch, and polishing my patches is a lame
project).

 4. Implement @{publish}
 (I just can't find the time to finish this)
 
 @{publish} is a feature like @{upstream}, showing the state of the
 publish-point in the case of triangular workflows. Implement this
 while sharing code with git-push, and polish it until the prompt shows
 publish-state.

I think this could be a good GSoC-sized topic. I'm going to adjust the
title to be better support for triangular workflows. I think they may
want to examine other issues in the area, rather than drilling down on
@{publish} in particular (but ultimately, it is up to the student to
propose what they want to do).

-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

error: src refspec refs/heads/master matches more than one.

Hello folks,

after some commits to my master branch, I tried to push to the bare upstream
repository and got this error message:

  error: src refspec refs/heads/master matches more than one.

A quick check shows that there's indeed something wrong:

  jw@kiste:/git/scan$ git branch -a | grep master
  * master
refs/heads/master
remotes/origin/HEAD - origin/master
remotes/origin/master
  jw@kiste:/git/scan$ find .git -name master
  .git/refs/heads/master
  .git/logs/refs/remotes/origin/master
  .git/logs/refs/heads/master
  .git/logs/refs/heads/refs/heads/master
  jw@kiste:/git/scan$ find .git -name master
  .git/refs/heads
  .git/refs/heads/refs/heads
  .git/logs/refs/heads
  .git/logs/refs/heads/refs/heads
  jw@kiste:/git/scan$ find .git -name master

Notice the refs/heads _within_ refs/heads!

Now I wonder how I managed to get into this situation and what's the best way
to recover?

Any ideas?

PS: this is git-1.8.1.4.

-- 
Josef Wolf
j...@raven.inka.de
--
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 2/2] combine-diff: speed it up, by using multiparent diff tree-walker directly

2014-02-14 Thread Kirill Smelkov

On Thu, Feb 13, 2014 at 11:55:08AM -0800, Junio C Hamano wrote:
 Kirill Smelkov k...@mns.spb.ru writes:
 
  +   if (need_generic_pathscan) {
  +   /* NOTE generic case also handles --stat, as it computes
  +* diff(sha1,parent_i) for all i to do the job, specifically
  +* for parent0.
  +*/
  +   paths = find_paths_generic(sha1, parents, diffopts);
  +   }
  +   else {
  +   paths = find_paths_multitree(sha1, parents, diffopts);
  +
  +   /* show stat against the first parent even
  +* when doing combined diff.
  +*/
  +   int stat_opt = (opt-output_format 
  +   (DIFF_FORMAT_NUMSTAT|DIFF_FORMAT_DIFFSTAT));
 
 /*
  * We see decl-after-stmt here.
  * Also please have slash-asterisk and asterisk-slash
  * at the beginning and the end of a multi-line comment
  * block on their own line.
  */

Sorry, and thanks for noticing. I usually compile with -Wall, but it
seems it is not enough without explicitly specifying -std=c89.

Comments corrected and the decl-after-stmt fixed, and this time I've
compiled with `-std=c89 -pedantic -Wall -Wextra` to assure no new
warnings are introduced.

Please apply and thanks beforehand,
Kirill

 8 
From: Kirill Smelkov k...@mns.spb.ru
Subject: [PATCH v2 2/2] combine-diff: speed it up, by using multiparent diff
 tree-walker directly

As was recently shown (c839f1bd combine-diff: optimize
combine_diff_path sets intersection), combine-diff runs very slowly. In
that commit we optimized paths sets intersection, but that accounted
only for ~ 25% of the slowness, and as my tracing showed, for linux.git
v3.10..v3.11, for merges a lot of time is spent computing
diff(commit,commit^2) just to only then intersect that huge diff to
almost small set of files from diff(commit,commit^1).

In previous commit, we described the problem in more details, and
reworked the diff tree-walker to be general one - i.e. to work in
multiple parent case too. Now is the time to take advantage of it for
finding paths for combine diff.

The implementation is straightforward - if we know, we can get generated
diff paths directly, and at present that means no diff filtering or
rename/copy detection was requested(*), we can call multiparent tree-walker
directly and get ready paths.

(*) because e.g. at present, all diffcore transformations work on
diff_filepair queues, but in the future, that limitation can be
lifted, if filters would operate directly on combine_diff_paths.

Timings for `git log --raw --no-abbrev --no-renames` without `-c` (git log)
and with `-c` (git log -c) and with `-c --merges` (git log -c --merges)
before and after the patch are as follows:

linux.git v3.10..v3.11

log log -c log -c --merges

before  1.9s16.4s  15.2s
after   1.9s 2.4s   1.1s

The result stayed the same.

Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
 combine-diff.c | 88 ++
 diff.c |  1 +
 2 files changed, 84 insertions(+), 5 deletions(-)

Chages since v1:

- fixed declaration-after-statement, and reworked multiline comments to
  start and end with /* and */ on separate lines.

diff --git a/combine-diff.c b/combine-diff.c
index 1732dfd..12764fb 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1303,7 +1303,7 @@ static const char *path_path(void *obj)
 
 
 /* find set of paths that every parent touches */
-static struct combine_diff_path *find_paths(const unsigned char *sha1,
+static struct combine_diff_path *find_paths_generic(const unsigned char *sha1,
const struct sha1_array *parents, struct diff_options *opt)
 {
struct combine_diff_path *paths = NULL;
@@ -1316,6 +1316,7 @@ static struct combine_diff_path *find_paths(const 
unsigned char *sha1,
/* tell diff_tree to emit paths in sorted (=tree) order */
opt-orderfile = NULL;
 
+   /* D(A,P1...Pn) = D(A,P1) ^ ... ^ D(A,Pn)  (wrt paths) */
for (i = 0; i  num_parent; i++) {
/*
 * show stat against the first parent even when doing
@@ -1346,6 +1347,35 @@ static struct combine_diff_path *find_paths(const 
unsigned char *sha1,
 }
 
 
+/*
+ * find set of paths that everybody touches, assuming diff is run without
+ * rename/copy detection, etc, comparing all trees simultaneously (= faster).
+ */
+static struct combine_diff_path *find_paths_multitree(
+   const unsigned char *sha1, const struct sha1_array *parents,
+   struct diff_options *opt)
+{
+   int i, nparent = parents-nr;
+   const unsigned char **parents_sha1;
+   struct combine_diff_path paths_head;
+   struct strbuf base;
+
+   parents_sha1 = xmalloc(nparent * sizeof(parents_sha1[0]));
+   for (i = 0; i  nparent; i++)
+   parents_sha1[i] = parents-sha1[i];
+
+   /* fake list head, so worker can assume it is non-NULL */
+

Re: [PATCH 1/2] tree-diff: rework diff_tree() to generate diffs for multiparent cases as well

2014-02-14 Thread Kirill Smelkov

On Thu, Feb 13, 2014 at 11:51:19AM -0800, Junio C Hamano wrote:
 Kirill Smelkov k...@mns.spb.ru writes:
 
  +   /* until we go to it next round, .next holds how many bytes we
  +* allocated (for faster realloc - we don't need copying old 
  data).
  +*/
  +   p-next = (struct combine_diff_path *)alloclen;
 
 I am getting this here:
 
 tree-diff.c: In function '__path_appendnew':
 tree-diff.c:140:13: error: cast to pointer from integer of different size 
 [-Werror=int-to-pointer-cast]

Ah, sorry, I only tested on 32 bits, and this indeed could be a valid
warning on systems where sizeof(ptr) != sizeof(int).

In our case, alloclen is small enough that the code should be valid,
and we can avoid the warning, via proper usage of intptr_t.

Please find corrected patch below.

Thanks,
Kirill

 8 
From: Kirill Smelkov k...@mns.spb.ru
Subject: [PATCH v2 1/2] tree-diff: rework diff_tree() to generate diffs for
 multiparent cases as well
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Previously diff_tree(), which is now named __diff_tree_sha1(), was
generating diff_filepair(s) for two trees t1 and t2, and that was
usually used for a commit as t1=HEAD~, and t2=HEAD - i.e. to see changes
a commit introduces.

In Git, however, we have fundamentally built flexibility in that a
commit can have many parents - 1 for a plain commit, 2 for a simple merge,
but also more than 2 for merging several heads at once.

For merges there is a so called combine-diff, which shows diff, a merge
introduces by itself, omitting changes done by any parent. That works
through first finding paths, that are different to all parents, and then
showing generalized diff, with separate columns for +/- for each parent.
The code lives in combine-diff.c .

There is an impedance mismatch, however, in that a commit could
generally have any number of parents, and that while diffing trees, we
divide cases for 2-tree diffs and more-than-2-tree diffs. I mean there
is no special casing for multiple parents commits in e.g.
revision-walker .

That impedance mismatch *hurts* *performance* *badly* for generating
combined diffs - in c839f1bd (combine-diff: optimize combine_diff_path
sets intersection) I've already removed some slowness from it, but from
the timings provided there, it could be seen, that combined diffs still
cost more than an order of magnitude more cpu time, compared to diff for
usual commits, and that would only be an optimistic estimate, if we take
into account that for e.g. linux.git there is only one merge for several
dozens of plain commits.

That slowness comes from the fact that currently, while generating
combined diff, a lot of time is spent computing diff(commit,commit^2)
just to only then intersect that huge diff to almost small set of files
from diff(commit,commit^1).

That's because at present, to compute combine-diff, for first finding
paths, that every parent touches, we use the following combine-diff
property/definition:

D(A,P1...Pn) = D(A,P1) ^ ... ^ D(A,Pn)  (w.r.t. paths)

where

D(A,P1...Pn) is combined diff between commit A, and parents Pi

and

D(A,Pi) is usual two-tree diff Pi..A

So if any of that D(A,Pi) is huge, tracting 1 n-parent combine-diff as n
1-parent diffs and intersecting results will be slow.

And usually, for linux.git and other topic-based workflows, that
D(A,P2) is huge, because, if merge-base of A and P2, is several dozens
of merges (from A, via first parent) below, that D(A,P2) will be diffing
sum of merges from several subsystems to 1 subsystem.

The solution is to avoid computing n 1-parent diffs, and to find
changed-to-all-parents paths via scanning A's and all Pi's trees
simultaneously, at each step comparing their entries, and based on that
comparison, populate paths result, and deduce we could *skip*
*recursing* into subdirectories, if at least for 1 parent, sha1 of that
dir tree is the same as in A. That would save us from doing significant
amount of needless work.

Such approach is very similar to what diff_tree() does, only there we
deal with scanning only 2 trees simultaneously, and for n+1 tree, the
logic is a bit more complex:

D(A,X1...Xn) calculation scheme
---

D(A,X1...Xn) = D(A,X1) ^ ... ^ D(A,Xn)   (regarding resulting paths set)

 D(A,Xj) - diff between A..Xj
 D(A,X1...Xn)- combined diff from A to parents X1,...,Xn

We start from all trees, which are sorted, and compare their entries in
lock-step:

  A X1   Xn
  - --
 |a|   |x1| |xn|
 |-|   |--| ... |--|  i = argmin(x1...xn)
 | |   |  | |  |
 |-|   |--| |--|
 |.|   |. | |. |
  . ..
  . ..

at any time there could be 3 cases:

 1)  a  xi;
 2)  a  xi;
 3)  a = xi.

Schematic deduction of what every case means, and what to do, follows:

1)  a  xi  -  ∀j a ∉ Xj  -  +a ∈ D(A,Xj)  -  D +=

Re: error: src refspec refs/heads/master matches more than one.

On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote:
 Josef Wolf j...@raven.inka.de writes:

 Notice the refs/heads _within_ refs/heads!

 Now I wonder how I managed to get into this situation and what's the best way
 to recover?

 Probably you did something like git branch refs/heads/master.  You can
 remove it again with git branch -d refs/heads/master.

As a porcelain, git branch should prevent (or at least warn) users
from creating such refs, I think.
-- 
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: Instructions to release your payment.

2014-02-14 Thread Dr.William Davies

Attention

Sir,

Following an application brought, seeking the release of your due payment
through British bank, I am directed to inform you that the application has
been approved and Natwest bank of London has been mandated to make transfer
of your payment to the bank account you will nominate. Please kindly reply
for immediate release of your US$6.2 Million to you nominates account.

Sir, for the avoidance of doubts, reconfirm the following information to
me to enable us forward same to Natwest bank to contact you for your
payment.

Name:

Address:

Tel/Fax No.:

Nationality:

Occupation:

Date of birth: 

As soon as I received the above information, I will forward them to
Natwest bank to contact you for your approved payment. Please see in the
attachment, letter I wrote to Natwest bank informing them of the
transaction

Yours faithfully

Dr.William Davies
Chairman,British Banking Regulatory Board.
--
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] config: git_config_from_file(): handle - filename as stdin

The patch extends git config --file interface to allow read config from
stdin.

Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
 config.c   | 10 ++
 t/t1300-repo-config.sh |  4 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/config.c b/config.c
index d969a5aefc2b..f80cc7e657e8 100644
--- a/config.c
+++ b/config.c
@@ -1032,10 +1032,11 @@ static int do_config_from(struct config_source *top, 
config_fn_t fn, void *data)
 
 int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 {
-   int ret;
-   FILE *f = fopen(filename, r);
+   int from_stdin = !strcmp(filename, -);
+   int ret = -1;
+   FILE *f;
 
-   ret = -1;
+   f = from_stdin ? stdin : fopen(filename, r);
if (f) {
struct config_source top;
 
@@ -1048,7 +1049,8 @@ int git_config_from_file(config_fn_t fn, const char 
*filename, void *data)
 
ret = do_config_from(top, fn, data);
 
-   fclose(f);
+   if (!from_stdin)
+   fclose(f);
}
return ret;
 }
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 967359344dab..f1a63075e34f 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -484,6 +484,10 @@ test_expect_success 'alternative GIT_CONFIG (--file)' '
test_cmp expect output
 '
 
+test_expect_success 'alternative GIT_CONFIG (--file=-)' '
+   git config --file - -l  other-config  output 
+   test_cmp expect output
+'
 test_expect_success 'refer config from subdirectory' '
mkdir x 
(
-- 
1.8.5.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

Re: [PATCH] notes: Disallow reusing non-blob as a note object

2014-02-14 Thread Eric Sunshine

On Wed, Feb 12, 2014 at 4:54 AM, Johan Herland jo...@herland.net wrote:
 Currently git notes add -C $object will read the raw bytes from $object,
 and then copy those bytes into the note object, which is hardcoded to be
 of type blob. This means that if the given $object is a non-blob (e.g.
 tree or commit), the raw bytes from that object is copied into a blob
 object. This is probably not useful, and certainly not what any sane
 user would expect. So disallow it, by erroring out if the $object passed
 to the -C option is not a blob.

 The fix also applies to the -c option (in which the user is prompted to
 edit/verify the note contents in a text editor), and also when -c/-C is
 passed to git notes append (which appends the $object contents to an
 existing note object). In both cases, passing a non-blob $object does not
 make sense.

 Also add a couple of tests demonstrating expected behavior.

 Suggested-by: Junio C Hamano gits...@pobox.com
 Signed-off-by: Johan Herland jo...@herland.net
 ---
  builtin/notes.c  |  6 +-
  t/t3301-notes.sh | 27 +++
  2 files changed, 32 insertions(+), 1 deletion(-)

 diff --git a/builtin/notes.c b/builtin/notes.c
 index 2b24d05..bb89930 100644
 --- a/builtin/notes.c
 +++ b/builtin/notes.c
 @@ -269,7 +269,11 @@ static int parse_reuse_arg(const struct option *opt, 
 const char *arg, int unset)
 die(_(Failed to resolve '%s' as a valid ref.), arg);
 if (!(buf = read_sha1_file(object, type, len)) || !len) {
 free(buf);
 -   die(_(Failed to read object '%s'.), arg);;
 +   die(_(Failed to read object '%s'.), arg);
 +   }
 +   if (type != OBJ_BLOB) {
 +   free(buf);
 +   die(_(Cannot read note data from non-blob object '%s'.), 
 arg);

The way this diagnostic is worded, it sound as if the 'read' failed
rather than that the user specified an incorrect object type. Perhaps
Object is not a blob '%s' or Expected blob but '%s' has type '%s'
or something along those lines?

 }
 strbuf_add((msg-buf), buf, len);
 free(buf);
--
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: error: src refspec refs/heads/master matches more than one.

On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote:
 On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote:
  Josef Wolf j...@raven.inka.de writes:
 
  Notice the refs/heads _within_ refs/heads!
  Probably you did something like git branch refs/heads/master.  You can
  remove it again with git branch -d refs/heads/master.
 As a porcelain, git branch should prevent (or at least warn) users
 from creating such refs, I think.

I don't think I did it the way Andreas thinks. This repository is maintained
by a script, I don't create branches manually. The only command in this script
that uses heads is

  git symbolic-ref HEAD refs/heads/$new_branch

to create new branches without any ancestry. And I double-checked that this
command is _not_ resposible for those ghost branches.

BTW: I see such ghost branches reappearing again and again, so it must be
 something systematic.

-- 
Josef Wolf
j...@raven.inka.de
--
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 GSoC 2014

2014-02-14 Thread Ramkumar Ramachandra

Jeff King wrote:
 1. Speed up git-rebase--am.sh

 Isn't the merge backend faster? I thought that was the point of it.

I suppose, but I thought git-rebase--am.sh (the default flavor) could
be improved by leveraging relatively new cherry-pick features; I
assumed that the reason it was using format-patch/ am was because it
was written before cherry-pick matured. Alternatively, can you think
of a project that involves working on the sequencer?

 3. Rewrite git-branch to use git-for-each-ref

 I actually have this about 95% done, waiting for the patches to be
 polished. So I don't think it makes a good GSoC project (it would be
 stupid to start from scratch, and polishing my patches is a lame
 project).

Oh. I look forward to using a nicer git-branch soon.

 4. Implement @{publish}

 I think this could be a good GSoC-sized topic. I'm going to adjust the
 title to be better support for triangular workflows. I think they may
 want to examine other issues in the area, rather than drilling down on
 @{publish} in particular (but ultimately, it is up to the student to
 propose what they want to do).

That makes the project a little more open-ended then. I like it.

I was hoping you'd have more comments on 3. Invent new conflict
style. Although I'm not sure the conflict style I proposed would be
terribly useful in the general case, it'll give the student an
opportunity to look at older/ lesser-known portions of the codebase.
--
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: error: src refspec refs/heads/master matches more than one.

2014-02-14 Thread David Kastrup

Josef Wolf j...@raven.inka.de writes:

 On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote:
 On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org 
 wrote:
  Josef Wolf j...@raven.inka.de writes:
 
  Notice the refs/heads _within_ refs/heads!
  Probably you did something like git branch refs/heads/master.  You can
  remove it again with git branch -d refs/heads/master.
 As a porcelain, git branch should prevent (or at least warn) users
 from creating such refs, I think.

 I don't think I did it the way Andreas thinks. This repository is maintained
 by a script, I don't create branches manually. The only command in this script
 that uses heads is

   git symbolic-ref HEAD refs/heads/$new_branch

 to create new branches without any ancestry. And I double-checked that this
 command is _not_ resposible for those ghost branches.

 BTW: I see such ghost branches reappearing again and again, so it must be
  something systematic.

You probably should check how $new_branch comes about.  Also, once a
directory refs/heads/refs/heads exists, refs/heads/$new_branch may
possibly be resolved as a branch with the name refs/heads/$new_branch.

-- 
David Kastrup
--
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] tests: turn on network daemon tests by default

Jeff King p...@peff.net writes:

  - We may want to do something similar in cvsserver and git-gui to
make them more robust.
 
$ git grep -e true --and -e 1 --and -e yes

 I assume the something here is to respect bool options more
 consistently?

Yeah, mostly by employing your 'git -c magic.var=X config --bool'
trick and check only for 'false' and 'true', instead of keeping a
hard-coded logic like the lines that hit the above query do.

 I have no problem with that, but nor do I care too much
 about those programs (that is partially laziness, but also partially
 that I do not want to deal with introducing a regression).

True, too ;-)

  - Do we want to do something similar to GIT_TEST_CREDENTIAL_HELPER?

 No, it is not a boolean. It is a bit of a hack, but it is meant to be
 used like:

   GIT_TEST_CREDENTIAL_HELPER=foo ./t0303-*

 to test some random git-credential-foo you have in your PATH. There is
 nothing to run by default there.

Ah, OK.  I was only grepping for test -z .*GIT_TEST_.
 tri-state is auto (or empty), but report an error when it is

 You probably want to drop this or empty or change it to or unset,

Thanks, I totally missed that.
--
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] notes: Disallow reusing non-blob as a note object

Eric Sunshine sunsh...@sunshineco.com writes:

 +   if (type != OBJ_BLOB) {
 +   free(buf);
 +   die(_(Cannot read note data from non-blob object '%s'.), 
 arg);

 The way this diagnostic is worded, it sound as if the 'read' failed
 rather than that the user specified an incorrect object type. Perhaps
 Object is not a blob '%s' or Expected blob but '%s' has type '%s'
 or something along those lines?

Yeah, sounds good.  You also need to say what expects a blob, too.
Perhaps something like this?

 builtin/notes.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/builtin/notes.c b/builtin/notes.c
index c11d6e6..a16bc00 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -272,8 +272,10 @@ static int parse_reuse_arg(const struct option *opt, const 
char *arg, int unset)
die(_(Failed to read object '%s'.), arg);
}
if (type != OBJ_BLOB) {
+   struct msg_arg *msg = opt-value;
free(buf);
-   die(_(Cannot read note data from non-blob object '%s'.), arg);
+   die(_(The -%c option takes a blob, which '%s' is not.,
+ msg-use_editor ? 'c' : 'C', arg));
}
strbuf_add((msg-buf), buf, len);
free(buf);
--
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] for-each-ref: add option to omit newlines

Øystein Walle oys...@gmail.com writes:

 However, when specifying a format string it's just a matter of ending
 the format string in '%00' and you're good to go. But then you get the
 null byte *and* a newline. And with your proposal there would be no way
 of saying you want neither.

I very well understand that.  All other commands that support -z
to give you NUL terminated output do not consider that a downside.
Why should for-each-ref be special?
--
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: error: src refspec refs/heads/master matches more than one.

Duy Nguyen pclo...@gmail.com writes:

 On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote:
 Josef Wolf j...@raven.inka.de writes:

 Notice the refs/heads _within_ refs/heads!

 Now I wonder how I managed to get into this situation and what's the best 
 way
 to recover?

 Probably you did something like git branch refs/heads/master.  You can
 remove it again with git branch -d refs/heads/master.

 As a porcelain, git branch should prevent (or at least warn) users
 from creating such refs, I think.

warn, possibly, but I do not see a reason to *prevent*.

 A. You are not allowed to call your branch with a string that begins with
'refs/heads/'.
 B. Why?
 A. Because it will confuse you.
 B. I know what I am doing.
 A. ???


--
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: Bug: Problem with CRLF line ending in git-diff with coloring

2014-02-14 Thread Stefan-W. Hahn

Mail von Stefan-W. Hahn, Sun, 09 Feb 2014 at 12:01:55 +0100:

Good afternoon,

I updated the test a little bit. Test 3 and 7 are going wrong.
Both tests have a CRLF line ending in the changed line.

I you redirect the output of the test to a file you see the main
problem:

,
| -[32m+[m[32mZeile 22[m[32m
[m
| +[32m+[m[32mZeile 22[m[41m
[m
`

 It's the right solution. IOW, you should place something like this in
 your .gitattributes:
  *.html whitespace=cr-at-eol

Sorry, but this is not possible, because I have files of both sorts (mainly
C/C++) files in my repository and cannot change the files as I wish.

With kind regards,
Stefan

-- 
Stefan-W. Hahn  It is easy to make things.
It is hard to make things simple.


t4060-diff-eol.sh
Description: Bourne shell script

Re: error: src refspec refs/heads/master matches more than one.

2014-02-14 Thread David Kastrup

Junio C Hamano gits...@pobox.com writes:

 Duy Nguyen pclo...@gmail.com writes:

 On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org 
 wrote:
 Josef Wolf j...@raven.inka.de writes:

 Notice the refs/heads _within_ refs/heads!

 Now I wonder how I managed to get into this situation and what's the best 
 way
 to recover?

 Probably you did something like git branch refs/heads/master.  You can
 remove it again with git branch -d refs/heads/master.

 As a porcelain, git branch should prevent (or at least warn) users
 from creating such refs, I think.

 warn, possibly, but I do not see a reason to *prevent*.

  A. You are not allowed to call your branch with a string that begins with
 'refs/heads/'.
  B. Why?
  A. Because it will confuse you.
  B. I know what I am doing.
  A. ???

A. But maybe Git will no longer know what you are doing.  Its standard
way of resolving references will mean that once a branch
refs/heads/wibble exists, referring to a branch wibble will become extra
hard.  For example, stuff like

push origin HEAD:refs/heads/wibble

will maybe create or update a new branch wibble, or maybe it will just
push to the existing branch refs/heads/wibble.

-- 
David Kastrup
--
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: error: src refspec refs/heads/master matches more than one.

On Fri, Feb 14, 2014 at 04:35:14PM +0100, David Kastrup wrote:
 Josef Wolf j...@raven.inka.de writes:
  The only command in this script that uses heads is
 
git symbolic-ref HEAD refs/heads/$new_branch
 
 You probably should check how $new_branch comes about.

This is the line of code where $new_branch is comes to live:

my (undef, $new_branch, @new_path) = split (/, $new_item);

So it is impossible that it might contain any slashes.

In any other situation, this script cares only about branches which start with
the string scan-file-:

sub local_branches  { grep {m+^scan-file-+} all_branches; }
sub remote_branches { grep {m+^remotes/origin/scan-file-+} all_branches; }

This is hard-coded, so I can't see any way for the user to inject refs/heads

 Also, once a
 directory refs/heads/refs/heads exists, refs/heads/$new_branch may
 possibly be resolved as a branch with the name refs/heads/$new_branch.

Can you elobarte on this? I don't get what you are trying to say.

As I already said, this happens on opensuse with git-1.8.1.4.
I have not yet seen this problem on ubuntu with  git-1.7.9.5.

-- 
Josef Wolf
j...@raven.inka.de
--
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 GSoC 2014

On Fri, Feb 14, 2014 at 10:30:28AM -0500, Ramkumar Ramachandra wrote:

  Isn't the merge backend faster? I thought that was the point of it.
 
 I suppose, but I thought git-rebase--am.sh (the default flavor) could
 be improved by leveraging relatively new cherry-pick features; I
 assumed that the reason it was using format-patch/ am was because it
 was written before cherry-pick matured.

I think that's somewhat the case. But the am technique also knows a lot
of tricks that cherry-pick doesn't. For example, there is currently a
bug where git rebase --keep-empty --whitespace=fix silently ignores
the latter option, because the former causes it to follow a cherry-pick
code path.

So I am a little hesitant in pushing more code paths down the
cherry-pick route (though it would be OK if we correctly identified
_when_ we could use cherry-pick for performance, and only kick in then).

 Alternatively, can you think of a project that involves working on the
 sequencer?

So yeah, obviously this is all tied up with the sequencer. In the spirit
of let's not re-propose old projects, I shied away from suggesting
finish up the sequencer. I know that the past projects did make
progress, and that is a good thing. But I also think it doesn't make for
a good bite-sized chunk.

  3. Rewrite git-branch to use git-for-each-ref
 
  I actually have this about 95% done, waiting for the patches to be
  polished. So I don't think it makes a good GSoC project (it would be
  stupid to start from scratch, and polishing my patches is a lame
  project).
 
 Oh. I look forward to using a nicer git-branch soon.

Actually, it is mostly about making a nicer git-for-each-ref, as I am
pulling out the ref selection code (which is more advanced in git tag
and git branch) and using it everywhere. So in that sense, maybe I am
not shooting for what you want. I think you want the follow-on to that,
which is to pull out the formatting code (which is more advanced in
for-each-ref), and let it be used everywhere.

I added this into the ideas page, but noting that there were two sides
to it, and that one would need to examine and build on existing work (I
know there was some discussion and experiments on the formatting side,
too).

 I was hoping you'd have more comments on 3. Invent new conflict
 style. Although I'm not sure the conflict style I proposed would be
 terribly useful in the general case, it'll give the student an
 opportunity to look at older/ lesser-known portions of the codebase.

I almost said more. :) I am not sure I have in my mind what a useful
new format would look like, and I would worry that we are leading the
student into a bit of a trap, as they need to both code, but also invent
a new and useful format.

But one thing I was really hoping for with these project descriptions
(and I think we got) is that they are not completed project proposals.
They are the kernels of ideas that the student will need to develop into
full proposals. I would much rather have a student who reads that and
says I have a brilliant idea for a format and proposes it, rather than
one who blindly says OK, I'll implement your idea. Getting the former
is much less likely, but if we do, I think it will lead to a much higher
quality project.

So I included it as-is, and I am curious to see what proposals we get.
:)

Thanks again for your list. I marked you as a potential mentor for the
conflict-style project; given the right proposal, I'd be happy to mentor
it, too (and without the right proposal, I do not think we should do it
at all). I also listed both you and me as potential mentors for
@{publish}, since we have both looked at the problem space. If you can't
make the time commitment, that's fine; I can do it (and we don't need to
decide until later anyway).

-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 1/2] tree-diff: rework diff_tree() to generate diffs for multiparent cases as well

Kirill Smelkov k...@mns.spb.ru writes:

  8 
 From: Kirill Smelkov k...@mns.spb.ru
 Subject: [PATCH v2 1/2] tree-diff: rework diff_tree() to generate diffs for
  multiparent cases as well
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

The last three do not belong here.  Only From, Date and Subject are
relevant and taken as in-body headers.

For that matter, as the From and Subject above are exactly the same
as what you have on the e-mail header, you do not want any of them.

I'll strip them out here, so no need to resend.  Thanks.

 Previously diff_tree(), which is now named __diff_tree_sha1(), was

That name with two leading underscores is a rather unfortunate,
especially for a function that is not a file scope static.  No way
to rename this to something more sensible?

 That impedance mismatch *hurts* *performance* *badly* for generating
 combined diffs - in c839f1bd (combine-diff: optimize combine_diff_path

Please avoid referring to a commit that is not in 'master' by its
object name.  It can be reworked later and get a different name.

 That slowness comes from the fact that currently, while generating
 combined diff, a lot of time is spent computing diff(commit,commit^2)
 just to only then intersect that huge diff to almost small set of files
 from diff(commit,commit^1).

Good observation.

|a|   |b|a  b   -  a ∉ B   -   D(A,B) +=  +aa↓
|-|   |-|a  b   -  b ∉ A   -   D(A,B) +=  -bb↓
| |   | |a = b   -  investigate δ(a,b)a↓ b↓

In both the n-parallel and diff-tree, when an entry 'a' is a
tree, I take this D(A,B) += +a to mean (recursively) adding all
the paths within 'a' to the result as addition.  Sounds sensible.

 D(A,B)

 is by definition the same as combined diff

 D(A,[B]),

 so if we could rework the code for common case and make it be not slower
 for nparent=1 case, usual diff(t1,t2) generation will not be slower, and
 multiparent diff tree-walker would greatly benefit generating
 combine-diff.

OK.

 What we do is as follows:

 1) diff tree-walker __diff_tree_sha1() is internally reworked to be
a paths generator (new name diff_tree_paths()), with each generated path
being `struct combine_diff_path` with info for path, new sha1,mode and for
every parent which sha1,mode it was in it.

 2) From that info, we can still generate usual diff queue with
struct diff_filepairs, via exporting generated
combine_diff_path, if we know we run for nparent=1 case.
(see emit_diff() which is now named emit_diff_p0only())

s/p0/first_parent_/; perhaps?

 3) In order for diff_can_quit_early(), which checks

DIFF_OPT_TST(opt, HAS_CHANGES))

to work, that exporting have to be happening not in bulk, but
incrementally, one diff path at a time.

Good thinking.

 Some notes(*):

 1) For loops,

  i = 0; do { ... } while (++i  nparent);

 is used instead of

  for (i = 0; i  nparent; ++i)
  ...

 because for the former case, the compiler have to emit additional
 prologue code which checks for i = nparent case before entering the
 loop.

 As we require nparent must be 0, that additional overhead
 conflicts with the runs not slower for nparent=1 case than before
 goal.

Unfortunate.  I'd rather see us stick to more readable and familiar
form for maintainability if this were not measurable.

 2) alloca(), for small arrays, is used for the same reason - if we change
 it to xmalloc()/free() the timings get worse

Do you see any use of it outside compat/?

I thought we specifically avoid alloca() for portability.  Also we
do not use variable-length-arrays on the stack either, I think.

 3) For every parent tree, we need to keep a tag, whether entry from that
 parent equals to entry from minimal parent. For performance reasons I'm
 keeping that tag in entry's mode field in unused bit - see S_IFXMIN_NEQ.

Unfortunate, but I do not see another place to keep this
information offhand (nor implement this approach without keeping
that piece of information).

 P.S. and combined diff is not some exotic/for-play-only stuff - for

No need to convince us about that ;-)

 example for a program I write to represent Git archives as readonly
 filesystem, there is initial scan with

 `git log --reverse --raw --no-abbrev --no-renames -c`

 to extract log of what was created/changed when, as a result building a
 map

 {}  sha1-  in which commit (and date) a content was added

 that `-c` means also show combined diff for merges, and without them, if
 a merge is non-trivial (merges changes from two parents with both having
 separate changes to a file), or an evil one, the map will not be full,
 i.e. some valid sha1 would be absent from it.

 That case was my initial motivation for combined diffs speedup.

I wonder if this machinery can be reused for log -m as well (or
perhaps you do that already?).  After all, by performing a single
parallel scan, you are gathering all the necessary

Re: Git GSoC 2014

2014-02-14 Thread Vicent Martí

On Thu, Feb 13, 2014 at 10:45 PM, Thomas Rast t...@thomasrast.ch wrote:
 Replace object loading/writing layer by libgit2

 Git reads objects from storage (loose and packed) through functions in
 sha1_file.c.  Most commands only require very simple, opaque read and
 write access to the object storage.  As a weatherballoon, show that it
 is feasible to use libgit2 git_odb_* routines for these simple callers.

 Aim for passing the git test suite using git_odb_* object storage
 access, except for tests that verify behavior in the face of storage
 corruption, replacement objects, alternate storage locations, and
 similar quirks.  Of course it is even better if you pass the test suite
 without exception.

 Language: C
 Difficulty: hard
 Possible mentors: Thomas Rast and fill in libgit2 expert

Note that we have several people in the libgit2 team that are willing
(and excited) to mentor or co-mentor this project or any of the other
libgit2 related projects that have been proposed.

Prospective list is

- Vicent Marti
- Russell Belfer
- Ed Thomson
- Carlos Martin (past GSoC student)

So there shouldn't be any mentor shortage.

Cheers,
vmg
--
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] config: git_config_from_file(): handle - filename as stdin

Kirill A. Shutemov kir...@shutemov.name writes:

 The patch extends git config --file interface to allow read config from
 stdin.

Thanks.  The external interface proposed by this change that behaves
the way your new test expects is a good addition to the system.  I
would describe it as:

  Subject: config: teach git config --file - to read from the standard input

I however think the patch implements it at the level that is too low
in the callchain.  It will affect a lot more than the dash given to
git config --file -.  Fortunately, it does not make it possible
for users to make this mistake

[include]
path = -

and scratch their heads, wondering why git config is not answering
until they hit ^D.  But that is _only_ because we check if a file
whose name is - actually exists in the current directory before
falling into this codepath (and usually no such file exists).  If
such a funnily-named file does exist, we read from that file, not
the standard input.  So that include codepath happens to be safe,
but who knows what dragons lie in other codepaths that call this
function.

I recall that an earlier implementation of git diff --no-index
that made - read one side to be compared from the standard input
had exactly the same issue of comparing filename with -, which we
had to fix with code reorganization recently.  I'd prefer to see
this update to git config --file - done the right way from the
start.

 diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
 index 967359344dab..f1a63075e34f 100755
 --- a/t/t1300-repo-config.sh
 +++ b/t/t1300-repo-config.sh
 @@ -484,6 +484,10 @@ test_expect_success 'alternative GIT_CONFIG (--file)' '
   test_cmp expect output
  '
  
 +test_expect_success 'alternative GIT_CONFIG (--file=-)' '
 + git config --file - -l  other-config  output 

Please leave no SP between redirection operator and its file, i.e.

git config --file - --list other-config output

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: Git GSoC 2014

On Thu, Feb 13, 2014 at 04:10:37AM -0500, Jeff King wrote:

 The Google Summer of Code application process is upon us. We have about
 34 hours until the deadline (2014-02-14T19:00 UTC) . That's not very
 much time, but I know some people have been thinking about projects for
 a while, so I have hope that we can put together an ideas page.

Just to let everybody know, the application is submitted. For reference,
I've updated the submitted application text here:

  http://git.github.io/SoC-2014-Org-Application.html

I've collected the discussion on the list on the ideas page:

  http://git.github.io/SoC-2014-Ideas.html

Google folks will be looking at it over the next week, but prospective
students probably won't see it until we are accepted to the program,
which would happen Feb 24th.

Please feel free to continue discussing or updating the ideas page in
the meantime. I think there is enough there already to show Google what
we are thinking about, but ultimately the students are the ones whom the
page is meant to serve.  Anything we can do to improve it before they
read it is a good thing.

-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

git-reset does not seem to respect GIT_WORK_TREE

2014-02-14 Thread Patrick Palka

Hi everyone,

I noticed that git-reset does not seem to respect GIT_WORK_TREE.  Here
is a simplified test case:

$ mkdir src_dir  cd src_dir
$ git init
$ touch A  git add A  git commit -m Dummy commit.
$ mkdir ../build_dir  cd ../build_dir
$ export GIT_WORK_TREE=../src_dir
$ export GIT_DIR=../src_dir/.git
$ git reset
Unstaged changes after reset:
D   A

The final command git reset erroneously suggests that the file A
does not exist in the working tree.  Does anybody know why git-reset
behaves this way?

Thanks,
Patrick
--
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: Make the git codebase thread-safe

2014-02-14 Thread Karsten Blees

Am 14.02.2014 00:09, schrieb Zachary Turner:
 To elaborate a little bit more, you can verify with a sample program
 that ReadFile with OVERLAPPED does in fact modify the HANDLE's file
 position.  The documentation doesn't actually state one way or
 another.   My original attempt at a patch didn't have the ReOpenFile,
 and we experienced regular read corruption.  We scratched our heads
 over it for a bit, and then hypothesized that someone must be mixing
 read styles, which led to this ReOpenFile workaround, which
 incidentally also solved the corruption problems.  We wrote a similar
 sample program to verify that when using ReOpenHandle, and changing
 the file pointer of the duplicated handle, that the file pointer of
 the original handle is not modified.
 
 We did not actually try to identify the source of the mixed read
 styles, but it seems like the only possible explanation.
 
 On Thu, Feb 13, 2014 at 2:53 PM, Stefan Zager sza...@google.com wrote:
 On Thu, Feb 13, 2014 at 2:51 PM, Karsten Blees karsten.bl...@gmail.com 
 wrote:
 Am 13.02.2014 19:38, schrieb Zachary Turner:

 The only reason ReOpenFile is necessary at
 all is because some code somewhere is mixing read-styles against the same
 fd.


 I don't understand...ReadFile with OVERLAPPED parameter doesn't modify the 
 HANDLE's file position, so you should be able to mix read()/pread() however 
 you like (as long as read() is only called from one thread).

 That is, apparently, a bald-faced lie in the ReadFile API doc.  First
 implementation didn't use ReOpenFile, and it crashed all over the
 place.  ReOpenFile fixed it.

 Stefan

Damn...you're right, multi-threaded git-index-pack works fine, but some tests 
fail badly. Mixed reads would have to be from git_mmap, which is the only other 
caller of pread().

A simple alternative to ReOpenHandle is to reset the file pointer to its 
original position, as in compat/pread.c::git_pread. Thus single-theaded code 
can mix read()/pread() at will, but multi-threaded code has to use pread() 
exclusively (which is usually the case anyway). A main thread using read() and 
background threads using pread() (which is technically allowed by POSIX) will 
fail with this solution.

This version passes the test suite on msysgit:

8
ssize_t mingw_pread(int fd, void *buf, size_t count, off64_t offset)
{
DWORD bytes_read;
OVERLAPPED overlapped;
off64_t current;
memset(overlapped, 0, sizeof(overlapped));
overlapped.Offset = (DWORD) offset;
overlapped.OffsetHigh = (DWORD) (offset  32);

current = lseek64(fd, 0, SEEK_CUR);

if (!ReadFile((HANDLE)_get_osfhandle(fd), buf, count, bytes_read, 
overlapped)) {
errno = err_win_to_posix(GetLastError());
return -1;
}

lseek64(fd, current, SEEK_SET);

return (ssize_t) bytes_read;
}

--
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 blame: Not Committed Yet with clean WD

On Thu, Feb 13, 2014 at 10:08:55AM +0100, Ephrim Khong wrote:
 Hi,
 
 for files that contain windows line endings in a repository with
 core.autocrlf=input, git blame will show lines as Not Committed
 Yet, even though they were not modified.
 
 Example:
 
 --
 git init
 git config core.autocrlf false
 echo foo  a
 unix2dos a
 git add a
 git commit -m initial commit
 git config core.autocrlf input
 git status
 git blame a
 --
 
 Output:
 
 --
 Reinitialized existing Git repository in /.../testblame2/.git/
 unix2dos: converting file a to DOS format ...
 On branch master
 nothing to commit, working directory clean
 On branch master
 nothing to commit, working directory clean
  (Not Committed Yet 2014-02-13 10:02:43 +0100 1) foo
 --
 
 Is there an easy way to work around this; is this desired behaviour
 or mor a bug?

I'm pretty sure this is a bug.  git blame should show the proper
information in this case.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: error: src refspec refs/heads/master matches more than one.

David Kastrup d...@gnu.org writes:

 Junio C Hamano gits...@pobox.com writes:
 ...
  A. Because it will confuse you.
  B. I know what I am doing.
  A. ???

 A. But maybe Git will no longer know what you are doing.  Its standard
 way of resolving references will mean that once a branch
 refs/heads/wibble exists, referring to a branch wibble will become extra
 hard.  For example, stuff like

 push origin HEAD:refs/heads/wibble

 will maybe create or update a new branch wibble, or maybe it will just
 push to the existing branch refs/heads/wibble.

I suspect that is a bad example (do refs on _our_ side influence how
RHS of the colon that names refs on the other side is interpreted),
but I think I know what you are trying to say.  But Git never knows
what you are doing---it just does what you tell it to, so it comes
back to It will confuse you to the point that you would not be able
to guess what Git will do matches your expectation.  Whenever I
tell them that, a counterpoint B. makes is still I know what I am
doing., which is stubborn, rather obvious, and unfortunate.

How much of the namespace are we willing to carve out if we were to
go this route anyway?  Things we use, i.e. refs/heads and refs/tags,
would be no-brainers, but do we also forbid refs/review, which we
ourselves do not use but some people may have in their repositories?
Anything that begins with refs/?  Anything that begins with refs/
and has more than two slashes in it?

--
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: Make the git codebase thread-safe

2014-02-14 Thread Zachary Turner

(Gah, sorry if you're receiving multiple emails to your personal
addresses, I need to get used to manually setting Plain-text mode
every time I send a message).

For the mixed read, we wouldn't be looking for another caller of
pread() (since it doesn't care what the file pointer is), but instead
a caller of read() or lseek() (since those do depend on the current
file pointer).  In index-pack.c, I see two possible culprits:

1) A call to xread() from inside fill()
2) A call to lseek in parse_pack_objects()

Do you think these could be related?  If so, maybe that opens up some
other solutions?

BTW, the version you posted isn't thread safe.  Suppose thread A and
thread B execute this function at the same time.  A executes through
the ReadFile(), but does not yet reset the second lseek64.  B then
executes the first lseek64(), storing off the modified file pointer.
Then A finishes, then B finishes.  At the end, the file pointer is
still modified.

On Fri, Feb 14, 2014 at 11:15 AM, Zachary Turner ztur...@chromium.org wrote:
 For the mixed read, we wouldn't be looking for another caller of pread()
 (since it doesn't care what the file pointer is), but instead a caller of
 read() or lseek().  In index-pack.c, I see two possible culprits:

 1) A call to xread() from inside fill()
 2) A call to lseek in parse_pack_objects()

 Do you think these could be related?  If so, maybe that opens up some other
 solutions?

 BTW, the version you posted isn't thread safe.  Suppose thread A and thread
 B execute this function at the same time.  A executes through the
 ReadFile(), but does not yet reset the second lseek64.  B then executes the
 first lseek64(), storing off the modified file pointer.  Then A finishes,
 then B finishes.  At the end, the file pointer is still modified.



 On Fri, Feb 14, 2014 at 11:04 AM, Karsten Blees karsten.bl...@gmail.com
 wrote:

 Am 14.02.2014 00:09, schrieb Zachary Turner:
  To elaborate a little bit more, you can verify with a sample program
  that ReadFile with OVERLAPPED does in fact modify the HANDLE's file
  position.  The documentation doesn't actually state one way or
  another.   My original attempt at a patch didn't have the ReOpenFile,
  and we experienced regular read corruption.  We scratched our heads
  over it for a bit, and then hypothesized that someone must be mixing
  read styles, which led to this ReOpenFile workaround, which
  incidentally also solved the corruption problems.  We wrote a similar
  sample program to verify that when using ReOpenHandle, and changing
  the file pointer of the duplicated handle, that the file pointer of
  the original handle is not modified.
 
  We did not actually try to identify the source of the mixed read
  styles, but it seems like the only possible explanation.
 
  On Thu, Feb 13, 2014 at 2:53 PM, Stefan Zager sza...@google.com wrote:
  On Thu, Feb 13, 2014 at 2:51 PM, Karsten Blees
  karsten.bl...@gmail.com wrote:
  Am 13.02.2014 19:38, schrieb Zachary Turner:
 
  The only reason ReOpenFile is necessary at
  all is because some code somewhere is mixing read-styles against the
  same
  fd.
 
 
  I don't understand...ReadFile with OVERLAPPED parameter doesn't modify
  the HANDLE's file position, so you should be able to mix read()/pread()
  however you like (as long as read() is only called from one thread).
 
  That is, apparently, a bald-faced lie in the ReadFile API doc.  First
  implementation didn't use ReOpenFile, and it crashed all over the
  place.  ReOpenFile fixed it.
 
  Stefan

 Damn...you're right, multi-threaded git-index-pack works fine, but some
 tests fail badly. Mixed reads would have to be from git_mmap, which is the
 only other caller of pread().

 A simple alternative to ReOpenHandle is to reset the file pointer to its
 original position, as in compat/pread.c::git_pread. Thus single-theaded code
 can mix read()/pread() at will, but multi-threaded code has to use pread()
 exclusively (which is usually the case anyway). A main thread using read()
 and background threads using pread() (which is technically allowed by POSIX)
 will fail with this solution.

 This version passes the test suite on msysgit:

 8
 ssize_t mingw_pread(int fd, void *buf, size_t count, off64_t offset)
 {
 DWORD bytes_read;
 OVERLAPPED overlapped;
 off64_t current;
 memset(overlapped, 0, sizeof(overlapped));
 overlapped.Offset = (DWORD) offset;
 overlapped.OffsetHigh = (DWORD) (offset  32);

 current = lseek64(fd, 0, SEEK_CUR);

 if (!ReadFile((HANDLE)_get_osfhandle(fd), buf, count, bytes_read,
 overlapped)) {
 errno = err_win_to_posix(GetLastError());
 return -1;
 }

 lseek64(fd, current, SEEK_SET);

 return (ssize_t) bytes_read;
 }


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

diff weirdness (bug?)

2014-02-14 Thread Dario Bertini

git clone g...@github.com:ansible/ansible.git
git revert 3616dffb68badb2b8d56

manually solve the conflict (you can look at the commit here:
https://github.com/ansible/ansible/commit/3616dffb68badb2b8d56ef34391d7aae8de79cd6
)

git diff will output:

dario@macbook ~/P/ansible (devel*+|REVERTING) git diff
diff --cc lib/ansible/constants.py
index c055ccf,6eac602..000
--- a/lib/ansible/constants.py
+++ b/lib/ansible/constants.py
@@@ -84,16 -61,8 +84,12 @@@ active_user   = pwd.getpwuid(os.geteuid

  # Needed so the RPM can call setup.py and have modules land in the
  # correct location. See #1277 for discussion
- if getattr(sys, real_prefix, None):
- # in a virtualenv
- DIST_MODULE_PATH = os.path.join(sys.prefix, 'share/ansible/')
- else:
- DIST_MODULE_PATH = '/usr/share/ansible/'
+ DIST_MODULE_PATH = os.path.join(sys.prefix, 'share/ansible/')

 +# check all of these extensions when looking for yaml files for things
like
 +# group variables
 +YAML_FILENAME_EXTENSIONS = [ , .yml, .yaml ]
 +
  # sections in config file
  DEFAULTS='defaults'



now, it weirdly/incorrectly says that we added the YAML-related lines

if we remove these 3 lines, we'll get this diff:

dario@macbook ~/P/ansible (devel*+|REVERTING) git diff --patience
diff --cc lib/ansible/constants.py
index c055ccf,6eac602..000
--- a/lib/ansible/constants.py
+++ b/lib/ansible/constants.py
@@@ -84,16 -61,8 +84,9 @@@ active_user   = pwd.getpwuid(os.geteuid

  # Needed so the RPM can call setup.py and have modules land in the
  # correct location. See #1277 for discussion
- if getattr(sys, real_prefix, None):
- # in a virtualenv
- DIST_MODULE_PATH = os.path.join(sys.prefix, 'share/ansible/')
- else:
- DIST_MODULE_PATH = '/usr/share/ansible/'
+ DIST_MODULE_PATH = os.path.join(sys.prefix, 'share/ansible/')

- # check all of these extensions when looking for yaml files for things
like
- # group variables
- YAML_FILENAME_EXTENSIONS = [ , .yml, .yaml ]
 +
  # sections in config file
  DEFAULTS='defaults'


even more weirdly, it'll say that we deleted the yaml-related lines

if we also remove one of the extra blank lines next to the yaml lines we
get an empty diff:

dario@macbook ~/P/ansible (devel*+|REVERTING) git diff
diff --cc lib/ansible/constants.py
index c055ccf,6eac602..000
--- a/lib/ansible/constants.py
+++ b/lib/ansible/constants.py


running `git add .` and then checking with git diff --cached will show
that everything is normal

the output is the same also with
git diff --minimal
or
git diff --patience


-- 
xmpp: berda...@gmail.com
bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP
gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just
for signing commits)
--
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: Download of the latest release of git 1.8.5.5 does not work

On Fri, Feb 14, 2014 at 10:21:35AM +0100, Peter Marx wrote:
 Hello,

 On your web-side  http://git-scm.com I see following information
 Latest stable release
 1.8.5.5
 Release Notes (2014-02-13)

 When I click on the link Download for Windows the page 
 http://git-scm.com/download/win; is opened
 and the download of file Git-1.8.5.2-preview20131230.exe started.

 I would like to download the latest release 1.8.5.5 but this is not possible.

 Could you check your web-side and add the latest release to it.

The version number is the version of the latest source release.  On
systems where code is not generally built directly from source (Mac OS X
and Windows), independent groups of people build these versions and then
upload them.  You can always attempt to build the latest source
yourself, though.

Also, the git-scm.com site isn't maintained by the Git project; it's
maintained at https://github.com/git/git-scm.com.  What you're seeing
appears to be issue #268 at that project:
https://github.com/git/git-scm.com/issues/268.  That's probably the
most appropriate place to go.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)

On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
 * bc/gpg-sign-everywhere (2014-02-11) 9 commits
  - pull: add the --gpg-sign option.
  - rebase: add the --gpg-sign option
  - rebase: parse options in stuck-long mode
  - rebase: don't try to match -M option
  - rebase: remove useless arguments check
  - am: add the --gpg-sign option
  - am: parse options in stuck-long mode
  - git-sh-setup.sh: add variable to use the stuck-long mode
  - cherry-pick, revert: add the --gpg-sign option
 
  Teach --gpg-sign option to many commands that create commits.
 
  Changes to some scripted Porcelains use unsafe variable
  substitutions and still need to be tightened.
 
  Will merge to 'next'.

Junio, did you want a reroll with that fixed commit message, or will you
fix it up yourself?

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)

brian m. carlson sand...@crustytoothpaste.net writes:

  Changes to some scripted Porcelains use unsafe variable
  substitutions and still need to be tightened.
 
  Will merge to 'next'.

 Junio, did you want a reroll with that fixed commit message, or will you
 fix it up yourself?

I haven't merged them yet---if there are need to update any one of
them, please reroll a replacement set.

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

[PATCH v5 7/9] rebase: parse options in stuck-long mode

From: Nicolas Vigier bo...@mars-attacks.org

There is no functional change. The reason for this change is to be able
to add a new option taking an optional argument.

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 git-rebase.sh | 50 ++
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 3b55211..842d7d4 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -5,7 +5,7 @@
 
 SUBDIRECTORY_OK=Yes
 OPTIONS_KEEPDASHDASH=
-OPTIONS_STUCKLONG=
+OPTIONS_STUCKLONG=t
 OPTIONS_SPEC=\
 git rebase [-i] [options] [--exec cmd] [--onto newbase] [upstream] 
[branch]
 git rebase [-i] [options] [--exec cmd] [--onto newbase] --root [branch]
@@ -237,21 +237,19 @@ do
test $total_argc -eq 2 || usage
action=${1##--}
;;
-   --onto)
-   onto=$2
-   shift
+   --onto=*)
+   onto=${1#--onto=}
;;
-   -x)
-   cmd=${cmd}exec $2${LF}
-   shift
+   --exec=*)
+   cmd=${cmd}exec ${1#--exec=}${LF}
;;
-   -i)
+   --interactive)
interactive_rebase=explicit
;;
-   -k)
+   --keep-empty)
keep_empty=yes
;;
-   -p)
+   --preserve-merges)
preserve_merges=t
test -z $interactive_rebase  interactive_rebase=implied
;;
@@ -267,21 +265,19 @@ do
--no-fork-point)
fork_point=
;;
-   -m)
+   --merge)
do_merge=t
;;
-   -X)
-   shift
-   strategy_opts=$strategy_opts $(git rev-parse --sq-quote 
--$1)
+   --strategy-option=*)
+   strategy_opts=$strategy_opts $(git rev-parse --sq-quote 
--${1#--strategy-option=})
do_merge=t
test -z $strategy  strategy=recursive
;;
-   -s)
-   shift
-   strategy=$1
+   --strategy=*)
+   strategy=${1#--strategy=}
do_merge=t
;;
-   -n)
+   --no-stat)
diffstat=
;;
--stat)
@@ -290,21 +286,20 @@ do
--autostash)
autostash=true
;;
-   -v)
+   --verbose)
verbose=t
diffstat=t
GIT_QUIET=
;;
-   -q)
+   --quiet)
GIT_QUIET=t
git_am_opt=$git_am_opt -q
verbose=
diffstat=
;;
-   --whitespace)
-   shift
-   git_am_opt=$git_am_opt --whitespace=$1
-   case $1 in
+   --whitespace=*)
+   git_am_opt=$git_am_opt --whitespace=${1#--whitespace=}
+   case ${1#--whitespace=} in
fix|strip)
force_rebase=t
;;
@@ -317,14 +312,13 @@ do
git_am_opt=$git_am_opt $1
force_rebase=t
;;
-   -C)
-   shift
-   git_am_opt=$git_am_opt -C$1
+   -C*)
+   git_am_opt=$git_am_opt $1
;;
--root)
rebase_root=t
;;
-   -f|--no-ff)
+   --force-rebase|--no-ff)
force_rebase=t
;;
--rerere-autoupdate|--no-rerere-autoupdate)
-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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 v5 5/9] rebase: remove useless arguments check

From: Nicolas Vigier bo...@mars-attacks.org

Remove a check on the number of arguments for --onto and -x options.
It is not possible for $# to be = 2 at this point :

 - if --onto or -x has an argument, git rev-parse --parseopt will
   provide something like this :
 set -- --onto 'x' --
   when parsing the --onto option, $# will be 3 or more if there are
   other options.

 - if --onto or -x doesn't have an argument, git rev-parse --parseopt
   will exit with an error and display usage information.

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 git-rebase.sh | 2 --
 1 file changed, 2 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index c1f98ae..d1835ba 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -238,12 +238,10 @@ do
action=${1##--}
;;
--onto)
-   test 2 -le $# || usage
onto=$2
shift
;;
-x)
-   test 2 -le $# || usage
cmd=${cmd}exec $2${LF}
shift
;;
-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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 v5 8/9] rebase: add the --gpg-sign option

From: Nicolas Vigier bo...@mars-attacks.org

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 Documentation/git-rebase.txt |  4 
 git-rebase--am.sh|  8 +---
 git-rebase--interactive.sh   | 39 ++-
 git-rebase--merge.sh |  2 +-
 git-rebase.sh| 11 +++
 5 files changed, 47 insertions(+), 17 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2889be6..2a93c64 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -281,6 +281,10 @@ which makes little sense.
specified, `-s recursive`.  Note the reversal of 'ours' and
'theirs' as noted above for the `-m` option.
 
+-S[keyid]::
+--gpg-sign[=keyid]::
+   GPG-sign commits.
+
 -q::
 --quiet::
Be quiet. Implies --no-stat.
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index a4f683a..df46f4c 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -6,7 +6,8 @@
 
 case $action in
 continue)
-   git am --resolved --resolvemsg=$resolvemsg 
+   git am --resolved --resolvemsg=$resolvemsg \
+   ${gpg_sign_opt:+$gpg_sign_opt} 
move_to_original_branch
return
;;
@@ -26,7 +27,7 @@ then
# empty commits and even if it didn't the format doesn't really lend
# itself well to recording empty patches.  fortunately, cherry-pick
# makes this easy
-   git cherry-pick --allow-empty $revisions
+   git cherry-pick ${gpg_sign_opt:+$gpg_sign_opt} --allow-empty 
$revisions
ret=$?
 else
rm -f $GIT_DIR/rebased-patches
@@ -60,7 +61,8 @@ else
return $?
fi
 
-   git am $git_am_opt --rebasing --resolvemsg=$resolvemsg 
$GIT_DIR/rebased-patches
+   git am $git_am_opt --rebasing --resolvemsg=$resolvemsg \
+   ${gpg_sign_opt:+$gpg_sign_opt} $GIT_DIR/rebased-patches
ret=$?
 
rm -f $GIT_DIR/rebased-patches
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 43c19e0..a1adae8 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -179,9 +179,10 @@ exit_with_patch () {
echo $1  $state_dir/stopped-sha
make_patch $1
git rev-parse --verify HEAD  $amend
+   gpg_sign_opt_quoted=${gpg_sign_opt:+$(git rev-parse --sq-quote 
$gpg_sign_opt)}
warn You can amend the commit now, with
warn
-   warn   git commit --amend
+   warn   git commit --amend $gpg_sign_opt_quoted
warn
warn Once you are satisfied with your changes, run
warn
@@ -248,7 +249,9 @@ pick_one () {
 
test -d $rewritten 
pick_one_preserving_merges $@  return
-   output eval git cherry-pick $strategy_args $empty_args $ff $@
+   output eval git cherry-pick \
+   ${gpg_sign_opt:+$(git rev-parse --sq-quote 
$gpg_sign_opt)} \
+   $strategy_args $empty_args $ff $@
 }
 
 pick_one_preserving_merges () {
@@ -351,7 +354,8 @@ pick_one_preserving_merges () {
new_parents=${new_parents# $first_parent}
merge_args=--no-log --no-ff
if ! do_with_author output eval \
-   'git merge $merge_args $strategy_args -m $msg_content 
$new_parents'
+   'git merge ${gpg_sign_opt:+$gpg_sign_opt} \
+   $merge_args $strategy_args -m $msg_content 
$new_parents'
then
printf %s\n $msg_content  
$GIT_DIR/MERGE_MSG
die_with_patch $sha1 Error redoing merge $sha1
@@ -359,7 +363,9 @@ pick_one_preserving_merges () {
echo $sha1 $(git rev-parse HEAD^0)  
$rewritten_list
;;
*)
-   output eval git cherry-pick $strategy_args $@ ||
+   output eval git cherry-pick \
+   ${gpg_sign_opt:+$(git rev-parse --sq-quote 
$gpg_sign_opt)} \
+   $strategy_args $@ ||
die_with_patch $sha1 Could not pick $sha1
;;
esac
@@ -470,7 +476,8 @@ do_pick () {
   --no-post-rewrite -n -q -C $1 
pick_one -n $1 
git commit --allow-empty --allow-empty-message \
-  --amend --no-post-rewrite -n -q -C $1 ||
+  --amend --no-post-rewrite -n -q -C $1 \
+  ${gpg_sign_opt:+$gpg_sign_opt} ||
die_with_patch $1 Could not apply $1... $2
else
pick_one $1 ||
@@ -497,7 +504,7 @@ do_next () {
 
mark_action_done
do_pick $sha1 $rest
-   git commit --amend

[PATCH v5 4/9] am: add the --gpg-sign option

From: Nicolas Vigier bo...@mars-attacks.org

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 Documentation/git-am.txt | 6 +-
 git-am.sh| 9 -
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 54d8461..17924d0 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -14,7 +14,7 @@ SYNOPSIS
 [--ignore-date] [--ignore-space-change | --ignore-whitespace]
 [--whitespace=option] [-Cn] [-pn] [--directory=dir]
 [--exclude=path] [--include=path] [--reject] [-q | --quiet]
-[--[no-]scissors]
+[--[no-]scissors] [-S[keyid]]
 [(mbox | Maildir)...]
 'git am' (--continue | --skip | --abort)
 
@@ -119,6 +119,10 @@ default.   You can use `--no-utf8` to override this.
Skip the current patch.  This is only meaningful when
restarting an aborted patch.
 
+-S[keyid]::
+--gpg-sign[=keyid]::
+   GPG-sign commits.
+
 --continue::
 -r::
 --resolved::
diff --git a/git-am.sh b/git-am.sh
index 020abf6..78517f2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -38,6 +38,7 @@ abort   restore the original branch and abort the 
patching operation.
 committer-date-is-author-datelie about committer date
 ignore-date use current timestamp for author date
 rerere-autoupdate update the index with reused conflict resolution if possible
+S,gpg-sign? GPG-sign commits
 rebasing*   (internal use for git-rebase)
 
 . git-sh-setup
@@ -375,6 +376,7 @@ git_apply_opt=
 committer_date_is_author_date=
 ignore_date=
 allow_rerere_autoupdate=
+gpg_sign_opt=
 
 if test $(git config --bool --get am.keepcr) = true
 then
@@ -436,6 +438,10 @@ it will be removed. Please do not use it anymore.
keepcr=t ;;
--no-keep-cr)
keepcr=f ;;
+   --gpg-sign)
+   gpg_sign_opt=-S ;;
+   --gpg-sign=*)
+   gpg_sign_opt=-S${1#--gpg-sign=} ;;
--)
shift; break ;;
*)
@@ -900,7 +906,8 @@ did you forget to use 'git add'?
GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE
export GIT_COMMITTER_DATE
fi 
-   git commit-tree $tree ${parent:+-p} $parent 
$dotest/final-commit
+   git commit-tree ${parent:+-p} $parent 
${gpg_sign_opt:+$gpg_sign_opt} $tree  \
+   $dotest/final-commit
) 
git update-ref -m $GIT_REFLOG_ACTION: $FIRSTLINE HEAD $commit $parent 
||
stop_here $this
-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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 v5 3/9] am: parse options in stuck-long mode

From: Nicolas Vigier bo...@mars-attacks.org

There is no functional change. The reason for this change is to be able
to add a new option taking an optional argument.

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 git-am.sh | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/git-am.sh b/git-am.sh
index a3b6f98..020abf6 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -4,7 +4,7 @@
 
 SUBDIRECTORY_OK=Yes
 OPTIONS_KEEPDASHDASH=
-OPTIONS_STUCKLONG=
+OPTIONS_STUCKLONG=t
 OPTIONS_SPEC=\
 git am [options] [(mbox|Maildir)...]
 git am [options] (--continue | --skip | --abort)
@@ -414,14 +414,14 @@ it will be removed. Please do not use it anymore.
abort=t ;;
--rebasing)
rebasing=t threeway=t ;;
-   --resolvemsg)
-   shift; resolvemsg=$1 ;;
-   --whitespace|--directory|--exclude|--include)
-   git_apply_opt=$git_apply_opt $(sq $1=$2); shift ;;
-   -C|-p)
-   git_apply_opt=$git_apply_opt $(sq $1$2); shift ;;
-   --patch-format)
-   shift ; patch_format=$1 ;;
+   --resolvemsg=*)
+   resolvemsg=${1#--resolvemsg=} ;;
+   --whitespace=*|--directory=*|--exclude=*|--include=*)
+   git_apply_opt=$git_apply_opt $(sq $1) ;;
+   -C*|-p*)
+   git_apply_opt=$git_apply_opt $(sq $1) ;;
+   --patch-format=*)
+   patch_format=${1#--patch-format=} ;;
--reject|--ignore-whitespace|--ignore-space-change)
git_apply_opt=$git_apply_opt $1 ;;
--committer-date-is-author-date)
-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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 v5 6/9] rebase: don't try to match -M option

From: Nicolas Vigier bo...@mars-attacks.org

The -M option does not exist in OPTIONS_SPEC, so there is no use to try
to find it.

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 git-rebase.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index d1835ba..3b55211 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -267,7 +267,7 @@ do
--no-fork-point)
fork_point=
;;
-   -M|-m)
+   -m)
do_merge=t
;;
-X)
-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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 v5 9/9] pull: add the --gpg-sign option.

git merge already allows us to sign commits, and git rebase has recently
learned how to do so as well.  Teach git pull to parse the -S/--gpg-sign
option and pass this along to merge or rebase, as appropriate.

Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 git-pull.sh | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/git-pull.sh b/git-pull.sh
index 0a5aa2c..6986e0f 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -138,6 +138,15 @@ do
--no-verify-signatures)
verify_signatures=--no-verify-signatures
;;
+   --gpg-sign|-S)
+   gpg_sign_args=-S
+   ;;
+   --gpg-sign=*)
+   gpg_sign_args=$(git rev-parse --sq-quote -S${1#--gpg-sign=})
+   ;;
+   -S*)
+   gpg_sign_args=$(git rev-parse --sq-quote $1)
+   ;;
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
dry_run=--dry-run
;;
@@ -305,11 +314,13 @@ merge_name=$(git fmt-merge-msg $log_arg 
$GIT_DIR/FETCH_HEAD) || exit
 case $rebase in
 true)
eval=git-rebase $diffstat $strategy_args $merge_args $rebase_args 
$verbosity
+   eval=$eval $gpg_sign_args
eval=$eval --onto $merge_head ${oldremoteref:-$merge_head}
;;
 *)
eval=git-merge $diffstat $no_commit $verify_signatures $edit $squash 
$no_ff $ff_only
-   eval=$eval  $log_arg $strategy_args $merge_args $verbosity $progress
+   eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
+   eval=$eval $gpg_sign_args
eval=$eval \\$merge_name\ HEAD $merge_head
;;
 esac
-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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 v5 1/9] cherry-pick, revert: add the --gpg-sign option

From: Nicolas Vigier bo...@mars-attacks.org

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 Documentation/git-cherry-pick.txt |  7 ++-
 Documentation/git-revert.txt  |  6 +-
 builtin/revert.c  |  2 ++
 sequencer.c   | 11 +++
 sequencer.h   |  2 ++
 5 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-cherry-pick.txt 
b/Documentation/git-cherry-pick.txt
index c205d23..f1e6b2f 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -8,7 +8,8 @@ git-cherry-pick - Apply the changes introduced by some existing 
commits
 SYNOPSIS
 
 [verse]
-'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] commit...
+'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
+ [-S[keyid]] commit...
 'git cherry-pick' --continue
 'git cherry-pick' --quit
 'git cherry-pick' --abort
@@ -100,6 +101,10 @@ effect to your index in a row.
 --signoff::
Add Signed-off-by line at the end of the commit message.
 
+-S[keyid]::
+--gpg-sign[=keyid]::
+   GPG-sign commits.
+
 --ff::
If the current HEAD is the same as the parent of the
cherry-pick'ed commit, then a fast forward to this commit will
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 2de67a5..9eb83f0 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -8,7 +8,7 @@ git-revert - Revert some existing commits
 SYNOPSIS
 
 [verse]
-'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] commit...
+'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] [-S[keyid]] 
commit...
 'git revert' --continue
 'git revert' --quit
 'git revert' --abort
@@ -80,6 +80,10 @@ more details.
 This is useful when reverting more than one commits'
 effect to your index in a row.
 
+-S[keyid]::
+--gpg-sign[=keyid]::
+   GPG-sign commits.
+
 -s::
 --signoff::
Add Signed-off-by line at the end of the commit message.
diff --git a/builtin/revert.c b/builtin/revert.c
index 87659c9..065d88d 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -89,6 +89,8 @@ static void parse_args(int argc, const char **argv, struct 
replay_opts *opts)
OPT_STRING(0, strategy, opts-strategy, N_(strategy), 
N_(merge strategy)),
OPT_CALLBACK('X', strategy-option, opts, N_(option),
N_(option for merge strategy), option_parse_x),
+   { OPTION_STRING, 'S', gpg-sign, opts-gpg_sign, N_(key id),
+ N_(GPG sign commit), PARSE_OPT_OPTARG, NULL, (intptr_t)  
},
OPT_END(),
OPT_END(),
OPT_END(),
diff --git a/sequencer.c b/sequencer.c
index 90cac7b..bde5f04 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -392,11 +392,18 @@ static int run_git_commit(const char *defmsg, struct 
replay_opts *opts,
 {
struct argv_array array;
int rc;
+   char *gpg_sign;
 
argv_array_init(array);
argv_array_push(array, commit);
argv_array_push(array, -n);
 
+   if (opts-gpg_sign) {
+   gpg_sign = xmalloc(3 + strlen(opts-gpg_sign));
+   sprintf(gpg_sign, -S%s, opts-gpg_sign);
+   argv_array_push(array, gpg_sign);
+   free(gpg_sign);
+   }
if (opts-signoff)
argv_array_push(array, -s);
if (!opts-edit) {
@@ -808,6 +815,8 @@ static int populate_opts_cb(const char *key, const char 
*value, void *data)
opts-mainline = git_config_int(key, value);
else if (!strcmp(key, options.strategy))
git_config_string(opts-strategy, key, value);
+   else if (!strcmp(key, options.gpg-sign))
+   git_config_string(opts-gpg_sign, key, value);
else if (!strcmp(key, options.strategy-option)) {
ALLOC_GROW(opts-xopts, opts-xopts_nr + 1, opts-xopts_alloc);
opts-xopts[opts-xopts_nr++] = xstrdup(value);
@@ -981,6 +990,8 @@ static void save_opts(struct replay_opts *opts)
}
if (opts-strategy)
git_config_set_in_file(opts_file, options.strategy, 
opts-strategy);
+   if (opts-gpg_sign)
+   git_config_set_in_file(opts_file, options.gpg-sign, 
opts-gpg_sign);
if (opts-xopts) {
int i;
for (i = 0; i  opts-xopts_nr; i++)
diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..db43e9c 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -37,6 +37,8 @@ struct replay_opts {
 
int mainline;
 
+   const char *gpg_sign;
+
/* Merge strategy */
const char *strategy;
const char **xopts;
-- 
1.9.0.rc3.1008.gd08b47c.dirty

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

[PATCH v5 2/9] git-sh-setup.sh: add variable to use the stuck-long mode

From: Nicolas Vigier bo...@mars-attacks.org

If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse
option parsing is done in --stuck-long mode.

Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
 contrib/git-resurrect.sh | 1 +
 git-am.sh| 1 +
 git-instaweb.sh  | 1 +
 git-quiltimport.sh   | 1 +
 git-rebase.sh| 1 +
 git-request-pull.sh  | 1 +
 git-sh-setup.sh  | 2 ++
 7 files changed, 8 insertions(+)

diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh
index a4ed4c3..d7e97bb 100755
--- a/contrib/git-resurrect.sh
+++ b/contrib/git-resurrect.sh
@@ -10,6 +10,7 @@ is rather slow but allows you to resurrect other people's 
topic
 branches.
 
 OPTIONS_KEEPDASHDASH=
+OPTIONS_STUCKLONG=
 OPTIONS_SPEC=\
 git resurrect $USAGE
 --
diff --git a/git-am.sh b/git-am.sh
index bbea430..a3b6f98 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -4,6 +4,7 @@
 
 SUBDIRECTORY_OK=Yes
 OPTIONS_KEEPDASHDASH=
+OPTIONS_STUCKLONG=
 OPTIONS_SPEC=\
 git am [options] [(mbox|Maildir)...]
 git am [options] (--continue | --skip | --abort)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index e93a238..4aa3eb8 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -5,6 +5,7 @@
 
 PERL='@@PERL@@'
 OPTIONS_KEEPDASHDASH=
+OPTIONS_STUCKLONG=
 OPTIONS_SPEC=\
 git instaweb [options] (--start | --stop | --restart)
 --
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 8e17525..167d79f 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -1,5 +1,6 @@
 #!/bin/sh
 OPTIONS_KEEPDASHDASH=
+OPTIONS_STUCKLONG=
 OPTIONS_SPEC=\
 git quiltimport [options]
 --
diff --git a/git-rebase.sh b/git-rebase.sh
index 8a3efa2..c1f98ae 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -5,6 +5,7 @@
 
 SUBDIRECTORY_OK=Yes
 OPTIONS_KEEPDASHDASH=
+OPTIONS_STUCKLONG=
 OPTIONS_SPEC=\
 git rebase [-i] [options] [--exec cmd] [--onto newbase] [upstream] 
[branch]
 git rebase [-i] [options] [--exec cmd] [--onto newbase] --root [branch]
diff --git a/git-request-pull.sh b/git-request-pull.sh
index fe21d5d..cf4f150 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -9,6 +9,7 @@ LONG_USAGE='Summarizes the changes between two commits to the 
standard output,
 and includes the given URL in the generated summary.'
 SUBDIRECTORY_OK='Yes'
 OPTIONS_KEEPDASHDASH=
+OPTIONS_STUCKLONG=
 OPTIONS_SPEC='git request-pull [options] start url [end]
 --
 pshow patch text as well
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index fffa3c7..5f28b32 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -72,6 +72,8 @@ if test -n $OPTIONS_SPEC; then
parseopt_extra=
[ -n $OPTIONS_KEEPDASHDASH ] 
parseopt_extra=--keep-dashdash
+   [ -n $OPTIONS_STUCKLONG ] 
+   parseopt_extra=$parseopt_extra --stuck-long
 
eval $(
echo $OPTIONS_SPEC |
-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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: Make the git codebase thread-safe

2014-02-14 Thread Stefan Zager

On Fri, Feb 14, 2014 at 11:15 AM, Zachary Turner ztur...@chromium.org wrote:
For the mixed read, we wouldn't be looking for another caller of pread()
(since it doesn't care what the file pointer is), but instead a caller of
read() or lseek(). In index-pack.c, I see two possible culprits:

1) A call to xread() from inside fill()
2) A call to lseek in parse_pack_objects()

Do you think these could be related? If so, maybe that opens up some other
solutions?

From my observations, it's not that simple. As you pointed out to me
before, fill() is only called before the threading part of the code,
and lseek is only called after the threading part; and the lseek() is
lseek(fd, 0, SEEK_CUR), so it's purely advisory.

Also, here is the error output we got before you added ReOpenFile:

remote: Total 2514467 (delta 1997300), reused 2513040 (delta 1997113)
Checking connectivity... error: packfile
d:/src/chromium2/_gclient_src_a6y1bf/.git/objects/pack/pack-3b8d06040ac37f14d0b43859926f1153fea61a7a.pack
does not match index
warning: packfile
d:/src/chromium2/_gclient_src_a6y1bf/.git/objects/pack/pack-3b8d06040ac37f14d0b43859926f1153fea61a7a.pack
cannot be accessed
error: packfile
d:/src/chromium2/_gclient_src_a6y1bf/.git/objects/pack/pack-3b8d06040ac37f14d0b43859926f1153fea61a7a.pack
does not match index
warning: packfile
d:/src/chromium2/_gclient_src_a6y1bf/.git/objects/pack/pack-3b8d06040ac37f14d0b43859926f1153fea61a7a.pack
cannot be accessed
error: packfile
d:/src/chromium2/_gclient_src_a6y1bf/.git/objects/pack/pack-3b8d06040ac37f14d0b43859926f1153fea61a7a.pack
does not match index
warning: packfile
d:/src/chromium2/_gclient_src_a6y1bf/.git/objects/pack/pack-3b8d06040ac37f14d0b43859926f1153fea61a7a.pack
cannot be accessed
fatal: bad object e0f9f23f765a45e6d80863a8f881ee735c9347fe

The 'Checking connectivity...' message comes from builtin/clone.c,
which runs in a separate process from builtin/index-pack.c. What this
suggests to me is that file descriptors for the loose object files are
not being flushed or closed properly before index-pack finishes.

BTW, the version you posted isn't thread safe. Suppose thread A and thread
B execute this function at the same time. A executes through the
ReadFile(), but does not yet reset the second lseek64. B then executes the
first lseek64(), storing off the modified file pointer. Then A finishes,
then B finishes. At the end, the file pointer is still modified.

Yes, that. I would also point out that in our experiments, ReOpenFile
is not nearly as expensive as its name might suggest. Since the
solution using ReOpenFile is pretty solidly thread-safe (at least as
far as we can tell), I'm in favor of using it unless or until we
properly root-case the failure.

Stefan
--
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 v5 0/9] add --gpg-sign to rebase and pull

This series was posted to the list some time back.  This is a re-send of
Nicolas Vigier's work with an additional patch that adds --gpg-sign to
pull as well, as well as the fixes that Junio suggested in review for
v3 and a typo noted in the v4 series.

There is also one additional merge call that was not previously given a
signature option that is now provided one as of v4.  I believe this was an
oversight, so I fixed it.

Nicolas Vigier (8):
  cherry-pick, revert: add the --gpg-sign option
  git-sh-setup.sh: add variable to use the stuck-long mode
  am: parse options in stuck-long mode
  am: add the --gpg-sign option
  rebase: remove useless arguments check
  rebase: don't try to match -M option
  rebase: parse options in stuck-long mode
  rebase: add the --gpg-sign option

brian m. carlson (1):
  pull: add the --gpg-sign option.

 Documentation/git-am.txt  |  6 +++-
 Documentation/git-cherry-pick.txt |  7 -
 Documentation/git-rebase.txt  |  4 +++
 Documentation/git-revert.txt  |  6 +++-
 builtin/revert.c  |  2 ++
 contrib/git-resurrect.sh  |  1 +
 git-am.sh | 26 ++--
 git-instaweb.sh   |  1 +
 git-pull.sh   | 13 +++-
 git-quiltimport.sh|  1 +
 git-rebase--am.sh |  8 +++--
 git-rebase--interactive.sh| 39 
 git-rebase--merge.sh  |  2 +-
 git-rebase.sh | 62 +--
 git-request-pull.sh   |  1 +
 git-sh-setup.sh   |  2 ++
 sequencer.c   | 11 +++
 sequencer.h   |  2 ++
 18 files changed, 135 insertions(+), 59 deletions(-)

-- 
1.9.0.rc3.1008.gd08b47c.dirty

--
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: What's cooking in git.git (Feb 2014, #04; Wed, 12)

2014-02-14 Thread Andrew Eikum

On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
 As a workaround to make life easier for third-party tools, the
 upcoming major release will be called Git 1.9.0 (not Git 1.9).
 The first maintenance release for it will be Git 1.9.1, and the
 major release after Git 1.9.0 will either be Git 2.0.0 or Git
 1.10.0.
 

Apologies if this ground has been tread before, but has there been a
version numbering discussion? A quick google didn't seem to turn
anything up.

This seems to be an opportune time to drop the useless first digit.
Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0,
3.0, 4.0, etc, with the 2nd digit would take the meaning of the
current 3rd digit and so on.

Andrew
--
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: diff weirdness (bug?)

Dario Bertini berda...@gmail.com writes:

 git clone g...@github.com:ansible/ansible.git
 git revert 3616dffb68badb2b8d56

 manually solve the conflict (you can look at the commit here:
 https://github.com/ansible/ansible/commit/3616dffb68badb2b8d56ef34391d7aae8de79cd6
 )

 git diff will output:

 dario@macbook ~/P/ansible (devel*+|REVERTING) git diff
 diff --cc lib/ansible/constants.py
 index c055ccf,6eac602..000
 --- a/lib/ansible/constants.py
 +++ b/lib/ansible/constants.py
 @@@ -84,16 -61,8 +84,12 @@@ active_user   = pwd.getpwuid(os.geteuid

   # Needed so the RPM can call setup.py and have modules land in the
   # correct location. See #1277 for discussion
 - if getattr(sys, real_prefix, None):
 - # in a virtualenv
 - DIST_MODULE_PATH = os.path.join(sys.prefix, 'share/ansible/')
 - else:
 - DIST_MODULE_PATH = '/usr/share/ansible/'
 + DIST_MODULE_PATH = os.path.join(sys.prefix, 'share/ansible/')

  +# check all of these extensions when looking for yaml files for things
 like
  +# group variables
  +YAML_FILENAME_EXTENSIONS = [ , .yml, .yaml ]
  +
   # sections in config file
   DEFAULTS='defaults'



 now, it weirdly/incorrectly says that we added the YAML-related lines

This is a combined diff, and yaml-related lines are added relative
to your _other_ branch you are merging (notice these + are indented
by one place).  Relative to what you had at the tip of your branch
before you started this operation that ended up conflicted, the
half-merged result removes if/else that sets DIST_MODULE_PATH and
replaces it with a single line (their +/- are on the first column,
signifying that these are differences relative to the first parent,
i.e. your state before you started the operation).

 if we remove these 3 lines, we'll get this diff:

With that understanding, I think the output after removing these
three lines is perfectlyh understandable and correct.  You are
looking at the three lines that used to exist in the version you
started from, that were missing from the other side.  If you remoe
them, it will show as removal from _your_ version (notice these -
that shows what _you_ did manually are on the first column, saying
that that is relative to _your_ version).
--
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] config: git_config_from_file(): handle - filename as stdin

On Fri, Feb 14, 2014 at 10:27:11AM -0800, Junio C Hamano wrote:
 Kirill A. Shutemov kir...@shutemov.name writes:
 
  The patch extends git config --file interface to allow read config from
  stdin.
 
 Thanks.  The external interface proposed by this change that behaves
 the way your new test expects is a good addition to the system.  I
 would describe it as:
 
   Subject: config: teach git config --file - to read from the standard input
 
 I however think the patch implements it at the level that is too low
 in the callchain.  It will affect a lot more than the dash given to
 git config --file -.  Fortunately, it does not make it possible
 for users to make this mistake
 
   [include]
   path = -
 
 and scratch their heads, wondering why git config is not answering
 until they hit ^D.  But that is _only_ because we check if a file
 whose name is - actually exists in the current directory before
 falling into this codepath (and usually no such file exists).  If
 such a funnily-named file does exist, we read from that file, not
 the standard input.  So that include codepath happens to be safe,
 but who knows what dragons lie in other codepaths that call this
 function.
 
 I recall that an earlier implementation of git diff --no-index
 that made - read one side to be compared from the standard input
 had exactly the same issue of comparing filename with -, which we
 had to fix with code reorganization recently.  I'd prefer to see
 this update to git config --file - done the right way from the
 start.

Okay, reworked version is below. It's slightly more invasive then the
original.

From 199e6a995bb5228578e66189ef586421a4d8d9ba Mon Sep 17 00:00:00 2001
From: Kirill A. Shutemov kir...@shutemov.name
Date: Fri, 14 Feb 2014 21:59:39 +0200
Subject: [PATCH] config: teach git config --file - to read from the standard
 input

The patch extends git config --file interface to allow read config from
stdin.

Editing stdin or setting value in stdin is an error.

Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
 builtin/config.c   | 39 ++-
 cache.h|  1 +
 config.c   | 41 +++--
 t/t1300-repo-config.sh | 17 +++--
 4 files changed, 69 insertions(+), 29 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index 92ebf23f0a9a..625f914c44a0 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -21,6 +21,7 @@ static char key_delim = ' ';
 static char term = '\n';
 
 static int use_global_config, use_system_config, use_local_config;
+static int use_stdin;
 static const char *given_config_file;
 static const char *given_config_blob;
 static int actions, types;
@@ -224,7 +225,7 @@ static int get_value(const char *key_, const char *regex_)
}
 
git_config_with_options(collect_config, values,
-   given_config_file, given_config_blob,
+   use_stdin, given_config_file, given_config_blob,
respect_includes);
 
ret = !values.nr;
@@ -309,7 +310,7 @@ static void get_color(const char *def_color)
get_color_found = 0;
parsed_color[0] = '\0';
git_config_with_options(git_get_color_config, NULL,
-   given_config_file, given_config_blob,
+   use_stdin, given_config_file, given_config_blob,
respect_includes);
 
if (!get_color_found  def_color)
@@ -339,7 +340,7 @@ static int get_colorbool(int print)
get_diff_color_found = -1;
get_color_ui_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
-   given_config_file, given_config_blob,
+   use_stdin, given_config_file, given_config_blob,
respect_includes);
 
if (get_colorbool_found  0) {
@@ -362,8 +363,11 @@ static int get_colorbool(int print)
return get_colorbool_found ? 0 : 1;
 }
 
-static void check_blob_write(void)
+static void check_write(void)
 {
+   if (use_stdin)
+   die(writing to stdin is not supported);
+
if (given_config_blob)
die(writing config blobs is not supported);
 }
@@ -435,7 +439,8 @@ static int get_urlmatch(const char *var, const char *url)
}
 
git_config_with_options(urlmatch_config_entry, config,
-   given_config_file, NULL, respect_includes);
+   use_stdin, given_config_file, NULL,
+   respect_includes);
 
for_each_string_list_item(item, values) {
struct urlmatch_current_candidate_value *matched = item-util;
@@ -476,6 +481,11 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
usage_with_options(builtin_config_usage, 
builtin_config_options);
}
 
+   if

Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)

Andrew Eikum aei...@codeweavers.com writes:

 On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
 As a workaround to make life easier for third-party tools, the
 upcoming major release will be called Git 1.9.0 (not Git 1.9).
 The first maintenance release for it will be Git 1.9.1, and the
 major release after Git 1.9.0 will either be Git 2.0.0 or Git
 1.10.0.
 

 Apologies if this ground has been tread before, but has there been a
 version numbering discussion? A quick google didn't seem to turn
 anything up.

 This seems to be an opportune time to drop the useless first digit.
 Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0,
 3.0, 4.0, etc, with the 2nd digit would take the meaning of the
 current 3rd digit and so on.

Considered, and discarded.

cf. http://article.gmane.org/gmane.comp.version-control.git/241498

When you see a version number vX.Y.0 next time, think of it as just
play vX.Y without the third digit, and you will be fine.  People's
script cannot learn the think of it as ... part overnight, and
that is why we have the .0 there.
--
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] config: git_config_from_file(): handle - filename as stdin

Kirill A. Shutemov kir...@shutemov.name writes:

 On Fri, Feb 14, 2014 at 10:27:11AM -0800, Junio C Hamano wrote:
 ...
 I recall that an earlier implementation of git diff --no-index
 that made - read one side to be compared from the standard input
 had exactly the same issue of comparing filename with -, which we
 had to fix with code reorganization recently.  I'd prefer to see
 this update to git config --file - done the right way from the
 start.

 Okay, reworked version is below. It's slightly more invasive then the
 original.

Thanks.

It looks more invasive mostly because you renamed check_blob_write()
to check_write().  While I think that rename is a right thing to do
(it used to be if we are attempting to write to blob, signal an
error, but we could have called it check_write(), meaning we are
attempting to write; error out if that should not be allowed), it
would have been much easier to review and comment if this were done
as a separate clean-up preparatory patch.  It wouldn't have had to
touch this many lines, I would think.

And clean-up existing code as a separate step, without changing the
behaviour, before starting to work on a new feature is actively
encouraged around here.

 From 199e6a995bb5228578e66189ef586421a4d8d9ba Mon Sep 17 00:00:00 2001
 From: Kirill A. Shutemov kir...@shutemov.name
 Date: Fri, 14 Feb 2014 21:59:39 +0200
 Subject: [PATCH] config: teach git config --file - to read from the standard
  input

I do not see a need for these four lines in your e-mail.  All the
necessary information is already in your e-mail header.  Please drop
them, perhaps except for the Subject: in-body header.

If you are going to have a discussion and then your proposed patch,
please do it this way (without the 8-space indentation I added for
illustration) using the -- 8 -- scissors line:

...
Okay, reworked version is below.

-- 8 --
Subject: config: teach git config --file - to read from the standard 
input

Extend git config --file interface to allow reading from
the standard input

Editing or setting value is an error.

Signed-off-by: ...
---
 diffstat and patch here

The in-body header Subject:  is there to let you retitle the
commit.

 Editing stdin or setting value in stdin is an error.

Good thinking.  Even comes with tests to cover these cases.  Good.

 diff --git a/builtin/config.c b/builtin/config.c
 index 92ebf23f0a9a..625f914c44a0 100644
 --- a/builtin/config.c
 +++ b/builtin/config.c
 @@ -21,6 +21,7 @@ static char key_delim = ' ';
  static char term = '\n';
  
  static int use_global_config, use_system_config, use_local_config;
 +static int use_stdin;
  static const char *given_config_file;
  static const char *given_config_blob;

If we are changing the function signature of git_config_with_options()
anyway, would it be even a better idea to introduce something like:

struct config_source {
int use_stdin;
const char *config_file;
const char *config_blob;
};

static struct config_source given_config_source;

and have one _fewer_ parameter to the function, instead of adding
one extra parameter?

 diff --git a/config.c b/config.c
 index d969a5aefc2b..53dd39f0b9ef 100644
 --- a/config.c
 +++ b/config.c
 @@ -1030,24 +1030,34 @@ static int do_config_from(struct config_source *top, 
 config_fn_t fn, void *data)
   return ret;
  }
  
 -int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 +static int do_config_from_file(config_fn_t fn, const char *filename, FILE *f,
 +void *data)
  {
 - int ret;
 - FILE *f = fopen(filename, r);
 + struct config_source top;
  
 - ret = -1;
 - if (f) {
 - struct config_source top;
 + top.u.file = f;
 + top.name = filename;
 + top.die_on_error = 1;
 + top.do_fgetc = config_file_fgetc;
 + top.do_ungetc = config_file_ungetc;
 + top.do_ftell = config_file_ftell;
 +
 + return do_config_from(top, fn, data);
 +}
  
 - top.u.file = f;
 - top.name = filename;
 - top.die_on_error = 1;
 - top.do_fgetc = config_file_fgetc;
 - top.do_ungetc = config_file_ungetc;
 - top.do_ftell = config_file_ftell;
 +static int git_config_from_stdin(config_fn_t fn, void *data)
 +{
 + return do_config_from_file(fn, stdin, stdin, data);
 +}

So the above callchain will set top.name to the string stdin.
How would that interact with the code in handle_path_include() that
makes sure that relative config includes are only allowed in file
with known location?

Other than that, I didn't spot any issue in this round looks.  It
seems to be almost there.

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: What's cooking in git.git (Feb 2014, #04; Wed, 12)

2014-02-14 Thread Andrew Eikum

On Fri, Feb 14, 2014 at 12:10:05PM -0800, Junio C Hamano wrote:
 Andrew Eikum aei...@codeweavers.com writes:
 
  On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
  As a workaround to make life easier for third-party tools, the
  upcoming major release will be called Git 1.9.0 (not Git 1.9).
  The first maintenance release for it will be Git 1.9.1, and the
  major release after Git 1.9.0 will either be Git 2.0.0 or Git
  1.10.0.
  
 
  Apologies if this ground has been tread before, but has there been a
  version numbering discussion? A quick google didn't seem to turn
  anything up.
 
  This seems to be an opportune time to drop the useless first digit.
  Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0,
  3.0, 4.0, etc, with the 2nd digit would take the meaning of the
  current 3rd digit and so on.
 
 Considered, and discarded.
 
 cf. http://article.gmane.org/gmane.comp.version-control.git/241498
 

Thank you for the link, it hadn't turned up in my searching.

 When you see a version number vX.Y.0 next time, think of it as just
 play vX.Y without the third digit, and you will be fine.  People's
 script cannot learn the think of it as ... part overnight, and
 that is why we have the .0 there.

Sorry if I wasn't clear, I meant the useless digit is the first one,
which is currently 1. and has been hanging around for a bit over
eight years.

My worry is having 2. hang around for another decade or longer. I'd
rather see X.0.0 denote a major feature release (currently represented
as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix. So
the major release version sequence would become 1.8.0, 1.9.0, 2.0.0,
3.0.0, with minor releases like 2.1.0, and bugfix releases like 2.1.1.

It seems reasonable to expect fewer backwards incompatible changes in
the future as Git has become more mature. This reduces the utility of
reserving X.0.0 for major backwards incompatible changes, especially
considering it's already been eight years for the first increment.

Andrew
--
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: What's cooking in git.git (Feb 2014, #04; Wed, 12)

Andrew Eikum aei...@codeweavers.com writes:

 My worry is having 2. hang around for another decade or longer. I'd
 rather see X.0.0 denote a major feature release (currently represented
 as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix.

We need three categories: (1) potentially incompatible, (2) feature,
(3) fixes-only.  We have been doing two levels of features by having
both second and third numbers and we are flattening by removing the
second one.

 It seems reasonable to expect fewer backwards incompatible changes in
 the future as Git has become more mature. This reduces the utility of
 reserving X.0.0 for major backwards incompatible changes, especially
 considering it's already been eight years for the first increment.

We are not done yet, far from it.  If we can stay at 2.X longer,
that is a very good thing.

If we followed your numbering scheme, you rob from the users a way
to learn about a rare event, a potentially backward-incompatible
change.  How would you tell your users when the version gap really
matters?  After hearing You need to plan carefully when you update
to version 47 and then updating to version 47 (or the user may skip
that version), the user will learn about a new version 48 and does
not hear such a you need to be careful.  What should he think?  No
news is a good news?  He should refrain from updating because the
last one was a big one?  What if the last time he updated was to
version 43, stayed at that version for a long time without paying
much attention (as Git grows more and more mature), and now we have
version 50 after having a large compatibility gap at version 47 he
did not pay much attention because he was skipping?

The rarer the important event is, the more necessary that the
importance is communicated clearly.

--
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: Bug: Problem with CRLF line ending in git-diff with coloring

2014-02-14 Thread Stefan-W. Hahn

Mail von Stefan-W. Hahn, Sun, 09 Feb 2014 at 12:01:55 +0100:

Good afternoon,

I updated the test a little bit. Test 3 and 7 are going wrong.
Both tests have a CRLF line ending in the changed line.

I you redirect the output of the test to a file you see the main
problem:

,
| -[32m+[m[32mZeile 22[m[32m
[m
| +[32m+[m[32mZeile 22[m[41m
[m
`

 It's the right solution. IOW, you should place something like this in
 your .gitattributes:
  *.html whitespace=cr-at-eol

Sorry, but this is not possible, because I have files of both sorts (mainly
C/C++) files in my repository and cannot change the files as I wish.

Second try, the mail was blocked because of the attachment blocked the mail,
so not as attachment.

,
| Date: Fri, 14 Feb 2014 11:50:37 -0500
| From: Administrator scanm...@arrisi.com
| To: stefan.h...@s-hahn.de
| Subject: [MailServer Notification]Attachment Blocking Notification
| From prvs=81222a4311=scanm...@arrisi.com  Fri Feb 14 22:03:58 2014
| X-Mailer: Microsoft CDO for Windows 2000
| 
| The t4060-diff-eol.sh has been blocked since it violated the Microsoft
| Exchange attachment policy and Replace with text/file has been taken on
| 2/14/2014 11:49:56 AM.
| Please zip the attachment and send it again. If you have any questions,
| please contact IT. Thank you
| 
| Message details:
| Server: ATLOWA1
| Sender: stefan.h...@s-hahn.de;
| Recipient: git@vger.kernel.org;
| Subject: Re: Bug: Problem with CRLF line ending in git-diff with coloring
| Attachment name: t4060-diff-eol.sh
| ~
`


With kind regards,
Stefan

#!/bin/sh
#
# Copyright (c) 2014 Stefan-W. Hahn
#

test_description='Test coloring of diff with CRLF line ending.

'
. ./test-lib.sh

get_color ()
{
git config --get-color $1
}

test_expect_success setup '
git config color.diff.plain black 
git config color.diff.meta blue 
git config color.diff.frag yellow 
git config color.diff.func normal 
git config color.diff.old red 
git config color.diff.new green 
git config color.diff.commit normal 
c_reset=$(git config --get-color no.such.color reset) 
c_plain=$(get_color color.diff.plain) 
c_meta=$(get_color color.diff.meta) 
c_frag=$(get_color color.diff.frag) 
c_func=$(get_color color.diff.func) 
c_old=$(get_color color.diff.old) 
c_new=$(get_color color.diff.new) 
c_commit=$(get_color color.diff.commit) 
c_whitespace=$(get_color color.diff.whitespace)
'

# Test cases
# - DOS line ending
#   - change one line
#   - change one line ending to UNIX
# - UNIX line ending
#   - change one line (trivial not tested here)
#   - change one line ending to DOS

tr 'Q' '\015'  EOF  x
Zeile 1Q
Zeile 2Q
Zeile 3Q
EOF

git update-index --add x

tr 'Q' '\015'  EOF  x
Zeile 1Q
Zeile 22Q
Zeile 3Q
EOF

tr 'Q' '\015'  EOF  expect
diff --git a/x b/x
index 3411cc1..68a4b2c 100644
--- a/x
+++ b/x
@@ -1,3 +1,3 @@
 Zeile 1Q
-Zeile 2Q
+Zeile 22Q
 Zeile 3Q
EOF

tr 'Q' '\015'  EOF  expect_color
${c_meta}diff --git a/x b/x${c_reset}
${c_meta}index 3411cc1..68a4b2c 100644${c_reset}
${c_meta}--- a/x${c_reset}
${c_meta}+++ b/x${c_reset}
${c_frag}@@ -1,3 +1,3 @@${c_reset}
${c_plain} Zeile 1${c_reset}Q
${c_old}-Zeile 2${c_reset}Q
${c_new}+${c_reset}${c_new}Zeile 22${c_reset}${c_new}Q${c_reset}
${c_plain} Zeile 3${c_reset}Q
EOF

git -c color.diff=false diff  out
test_expect_success diff files: change line in DOS file without color '
test_cmp expect out'

git -c color.diff=always diff  out
test_expect_success diff files: change line in DOS file with color '
test_cmp expect_color out'


tr 'Q' '\015'  EOF  x
Zeile 1Q
Zeile 2Q
Zeile 3Q
EOF

git update-index --add x

tr 'Q' '\015'  EOF  x
Zeile 1Q
Zeile 2
Zeile 3Q
EOF

tr 'Q' '\015'  EOF  expect
diff --git a/x b/x
index 3411cc1..c040c67 100644
--- a/x
+++ b/x
@@ -1,3 +1,3 @@
 Zeile 1Q
-Zeile 2Q
+Zeile 2
 Zeile 3Q
EOF

tr 'Q' '\015'  EOF  expect_color
${c_meta}diff --git a/x b/x${c_reset}
${c_meta}index 3411cc1..c040c67 100644${c_reset}
${c_meta}--- a/x${c_reset}
${c_meta}+++ b/x${c_reset}
${c_frag}@@ -1,3 +1,3 @@${c_reset}
${c_plain} Zeile 1${c_reset}Q
${c_old}-Zeile 2${c_reset}Q
${c_new}+${c_reset}${c_new}Zeile 2${c_reset}
${c_plain} Zeile 3${c_reset}Q
EOF

git -c color.diff=false diff  out
test_expect_success diff files: change line ending in DOS file to LF ending 
without color '
test_cmp expect out'

git -c color.diff=always diff  out
test_expect_success diff files: change line ending in DOS file to LF ending 
with color '
test_cmp expect_color out'

tr 'Q' '\015'  EOF  x
Zeile 1
Zeile 2
Zeile 3
EOF

git update-index --add x

tr 'Q' '\015'  EOF  x
Zeile 1
Zeile 2Q
Zeile 3
EOF

tr 'Q' '\015'  EOF  expect
diff --git a/x b/x
index a385875..63416d7 100644
--- a/x
+++ b/x
@@ -1,3 +1,3 @@
 Zeile 1
-Zeile 2
+Zeile 2Q
 Zeile 3
EOF

tr 'Q' '\015'  EOF  expect_color
${c_meta}diff --git a/x b/x${c_reset}
${c_meta}index a385875..63416d7 100644${c_reset}

Re: Bug: Problem with CRLF line ending in git-diff with coloring

2014-02-14 Thread Johannes Sixt

Am 14.02.2014 17:47, schrieb Stefan-W. Hahn:
 It's the right solution. IOW, you should place something like this in
 your .gitattributes:
  *.html whitespace=cr-at-eol
 
 Sorry, but this is not possible, because I have files of both sorts (mainly
 C/C++) files in my repository and cannot change the files as I wish.

I'm confused. This setting does not change your files, but instructs git
diff and git apply to not report the trailing CR as white-space error.
Didn't you try it?

-- Hannes

--
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: What's cooking in git.git (Feb 2014, #04; Wed, 12)

2014-02-14 Thread Andrew Eikum

On Fri, Feb 14, 2014 at 01:08:32PM -0800, Junio C Hamano wrote:
 Andrew Eikum aei...@codeweavers.com writes:
 
  My worry is having 2. hang around for another decade or longer. I'd
  rather see X.0.0 denote a major feature release (currently represented
  as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix.
 
 We need three categories: (1) potentially incompatible, (2) feature,
 (3) fixes-only.  We have been doing two levels of features by having
 both second and third numbers and we are flattening by removing the
 second one.
 
  It seems reasonable to expect fewer backwards incompatible changes in
  the future as Git has become more mature. This reduces the utility of
  reserving X.0.0 for major backwards incompatible changes, especially
  considering it's already been eight years for the first increment.
 
 We are not done yet, far from it.  If we can stay at 2.X longer,
 that is a very good thing.
 

Okay, fair enough. Thanks for explaining :)

Andrew
--
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 v5 02/14] trailer: process trailers from file and arguments

2014-02-14 Thread Christian Couder

From: Junio C Hamano gits...@pobox.com

 These numerous questions you have to ask are indications why
 choosing this condition goes to the left hand side of the equal
 sign (e.g. exists) and this condition goes to the right hand side
 (e.g. do-this-if_neighbor) is not working well.  The user has to
 remember which conditions go to the variable name and which
 conditions go to the action part.

If we limit it to if_exists and if_missing, the user can remember
that without things becoming too complex.

 That is, not splitting the logic into two parts like you did,
 i.e. if_X = do_Y_if_Z, which invites why is it not if_true =
 do_Y_if_X_and_Z, if_X_and_Z = do_Y, if_Z = do_Y_if_X?

It perhaps invite it, but there are reasons why splitting the logic
too much is not a good idea and why limiting the split to if_exists
and if_missing is a good tradeoff.

 One possible way to avoid the confusion is to say do_Y_if_X_and_Z
 without making the rule split into conditions and actions---I am
 NOT saying that is _better_, there may be other solutions to avoid
 this two-part logic in a cleaner way.

This has been discussed first last November and I don't think that a
solution better than what I implemented has been suggested.

The problem is we not only want to say:

action = do_Y_if_X_and_Z

but we also want to say:

action = do_Y_if_X_and_Z AND do_U_if_V

For example some people might want:

if_exists = overwrite
if_missing = add

while others might want:

if_exists = overwrite
if_missing = do_nothing

and I don't see how we can say that with just:

action = do_Y_if_X_and_Z

Thanks,
Christian.

--
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 v5 02/14] trailer: process trailers from file and arguments

Christian Couder chrisc...@tuxfamily.org writes:

 For example some people might want:

 if_exists = overwrite
 if_missing = add

 while others might want:

 if_exists = overwrite
 if_missing = do_nothing

 and I don't see how we can say that with just:

 action = do_Y_if_X_and_Z

Yes, but then we go back to my original question: why exists and
missing are so special, and why there aren't two kinds of exists
(i.e. there exists an entry with the same key, value vs there
exists an entry with the same key).  I would have understood your
this is not too hard to understand for users if you had three
(i.e. missing, in addition to these two flavours of exists), but
with only two, I do not see how it is useful in a hypothetical
situation like above.

For example, how would you express something like this only with
if-exists vs if-missing?

if_exists_exactly = ignore
if_exists_with_different_value = append
if_missng = prepend_to_the_beginning
--
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] git-completion.zsh: do not clobber complete()

2014-02-14 Thread Mark Lodato

Previously, git-completion.zsh redefined complete() to make __git_complete()
a no-op. This broke zsh's built-in bash completion compatibility layer
(bashcompinit), which defines its own complete().

Sadly, since there is no way in zsh to restore the original defintion of
complete() after bash-completion.bash is sourced, we must pass in a flag to
git-completion.bash to change its behavior.

Signed-off-by: Mark Lodato lod...@google.com
---
 contrib/completion/git-completion.bash | 1 +
 contrib/completion/git-completion.zsh  | 8 +---
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 9525343..36aa8bb 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2650,6 +2650,7 @@ __git_func_wrap ()
 # This is NOT a public function; use at your own risk.
 __git_complete ()
 {
+   [[ -n $GIT_DO_NOT_CALL_COMPLETE ]]  return
local wrapper=__git_wrap${2}
eval $wrapper () { __git_func_wrap $2 ; }
complete -o bashdefault -o default -o nospace -F $wrapper $1 
2/dev/null \
diff --git a/contrib/completion/git-completion.zsh 
b/contrib/completion/git-completion.zsh
index 6b77968..9f68d63 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -16,12 +16,6 @@
 #
 #  fpath=(~/.zsh $fpath)
 
-complete ()
-{
-   # do nothing
-   return 0
-}
-
 zstyle -T ':completion:*:*:git:*' tag-order  \
zstyle ':completion:*:*:git:*' tag-order 'common-commands'
 
@@ -39,7 +33,7 @@ if [ -z $script ]; then
test -f $e  script=$e  break
done
 fi
-ZSH_VERSION='' . $script
+GIT_DO_NOT_CALL_COMPLETE=1 ZSH_VERSION='' . $script
 
 __gitcomp ()
 {
-- 
1.9.0.rc1.175.g0b1dcb5

--
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: Make the git codebase thread-safe

2014-02-14 Thread Stefan Zager

On Fri, Feb 14, 2014 at 11:04 AM, Karsten Blees karsten.bl...@gmail.com wrote:

 Damn...you're right, multi-threaded git-index-pack works fine, but some tests 
 fail badly. Mixed reads would have to be from git_mmap, which is the only 
 other caller of pread().

msysgit used git_mmap() as defined in compat/win32mmap.c, which does
not use pread.

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

[ANNOUNCE] Git v1.9.0

The latest feature release Git v1.9.0 is now available at the
usual places.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

e60667fc16e5a5f1cde46616b0458cc802707743  git-1.9.0.tar.gz
65eb3f411f4699695c7081a7c716cabb9ce23d75  git-htmldocs-1.9.0.tar.gz
cff590c92b4d1c8a143c078473140b653cc5d56a  git-manpages-1.9.0.tar.gz

The following public repositories all have a copy of the v1.9.0
tag and the master branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  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

Also, http://www.kernel.org/pub/software/scm/git/ has copies of the
release tarballs.

Git v1.9.0 Release Notes


Backward compatibility notes


git submodule foreach $cmd $args used to treat $cmd $args the same
way ssh did, concatenating them into a single string and letting the
shell unquote. Careless users who forget to sufficiently quote $args
get their argument split at $IFS whitespaces by the shell, and got
unexpected results due to this. Starting from this release, the
command line is passed directly to the shell, if it has an argument.

Read-only support for experimental loose-object format, in which users
could optionally choose to write their loose objects for a short
while between v1.4.3 and v1.5.3 era, has been dropped.

The meanings of the --tags option to git fetch has changed; the
command fetches tags _in addition to_ what is fetched by the same
command line without the option.

The way git push $there $what interprets the $what part given on the
command line, when it does not have a colon that explicitly tells us
what ref at the $there repository is to be updated, has been enhanced.

A handful of ancient commands that have long been deprecated are
finally gone (repo-config, tar-tree, lost-found, and peek-remote).


Backward compatibility notes (for Git 2.0.0)


When git push [$there] does not say what to push, we have used the
traditional matching semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there).  In Git 2.0, the default will change to the simple
semantics, which pushes:

 - only the current branch to the branch with the same name, and only
   when the current branch is set to integrate with that remote
   branch, if you are pushing to the same remote as you fetch from; or

 - only the current branch to the branch with the same name, if you
   are pushing to a remote that is not where you usually fetch from.

Use the user preference configuration variable push.default to
change this.  If you are an old-timer who is used to the matching
semantics, you can set the variable to matching to keep the
traditional behaviour.  If you want to live in the future early, you
can set it to simple today without waiting for Git 2.0.

When git add -u (and git add -A) is run inside a subdirectory and
does not specify which paths to add on the command line, it
will operate on the entire tree in Git 2.0 for consistency
with git commit -a and other commands.  There will be no
mechanism to make plain git add -u behave like git add -u ..
Current users of git add -u (without a pathspec) should start
training their fingers to explicitly say git add -u .
before Git 2.0 comes.  A warning is issued when these commands are
run without a pathspec and when you have local changes outside the
current directory, because the behaviour in Git 2.0 will be different
from today's version in such a situation.

In Git 2.0, git add path will behave as git add -A path, so
that git add dir/ will notice paths you removed from the directory
and record the removal.  Versions before Git 2.0, including this
release, will keep ignoring removals, but the users who rely on this
behaviour are encouraged to start using git add --ignore-removal path
now before 2.0 is released.

The default prefix for git svn will change in Git 2.0.  For a long
time, git svn created its remote-tracking branches directly under
refs/remotes, but it will place them under refs/remotes/origin/ unless
it is told otherwise with its --prefix option.


Updates since v1.8.5


Foreign interfaces, subsystems and ports.

 * The HTTP transport, when talking GSS-Negotiate, uses 100
   Continue response to avoid having to rewind and resend a large
   payload, which may not be always doable.

 * Various bugfixes to remote-bzr and remote-hg (in contrib/).

 * The build procedure is aware of MirBSD now.

 * Various git p4, git svn and gitk updates.


UI, Workflows  Features

 * Fetching from a shallowly-cloned repository used to be forbidden,
   primarily because the codepaths involved were

What's cooking in git.git (Feb 2014, #05; Fri, 14)

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

The tip of 'master' is v1.9.0.  The first maintenance release for it
will be Git 1.9.1, and the major release after Git 1.9.0 will
either be Git 2.0.0 or Git 1.10.0.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* ks/tree-diff-nway (2014-02-14) 2 commits
 - combine-diff: speed it up, by using multiparent diff
 - tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
 (this branch uses ks/combine-diff, ks/tree-diff-more and ks/tree-diff-walk.)

 Instead of running N pair-wise diff-trees when inspecting a
 N-parent merge, find the set of paths that were touched by walking
 N+1 trees in parallel.  These set of paths can then be turned into
 N pair-wise diff-tree results to be processed through rename
 detections and such.  And N=2 case nicely degenerates to the usual
 2-way diff-tree, which is very nice.

 Promising, but unfortunately the implementation seems a bit too
 unportable for such a core part of the system.

--
[Stalled]

* po/everyday-doc (2014-01-27) 1 commit
 - Make 'git help everyday' work

 This may make the said command to emit something, but the source is
 not meant to be formatted into a manual pages to begin with, and
 also its contents are a bit stale.  It may be a good first step in
 the right direction, but needs more work to at least get the
 mark-up right before public consumption.

 Will hold.


* jk/branch-at-publish-rebased (2014-01-17) 5 commits
 - t1507 (rev-parse-upstream): fix typo in test title
 - implement @{publish} shorthand
 - branch_get: provide per-branch pushremote pointers
 - branch_get: return early on error
 - sha1_name: refactor upstream_mark

 Give an easier access to the tracking branches from other side in
 a triangular workflow by introducing B@{publish} that works in a
 similar way to how B@{upstream} does.

 Meant to be used as a basis for whatever Ram wants to build on.

 Will hold.


* rb/merge-prepare-commit-msg-hook (2014-01-10) 4 commits
 - merge: drop unused arg from abort_commit method signature
 - merge: make prepare_to_commit responsible for write_merge_state
 - t7505: ensure cleanup after hook blocks merge
 - t7505: add missing 

 Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that
 run during git merge.  The log message stresses too much on one
 hook, prepare-commit-msg, but it would equally apply to other hooks
 like post-merge, I think.

 Waiting for a reroll.


* jl/submodule-recursive-checkout (2013-12-26) 5 commits
 - Teach checkout to recursively checkout submodules
 - submodule: teach unpack_trees() to update submodules
 - submodule: teach unpack_trees() to repopulate submodules
 - submodule: teach unpack_trees() to remove submodule contents
 - submodule: prepare for recursive checkout of submodules

 Expecting a reroll.


* jc/graph-post-root-gap (2013-12-30) 3 commits
 - WIP: document what we want at the end
 - graph: remove unused code a bit
 - graph: stuff the current commit into graph-columns[]

 This was primarily a RFH ($gmane/239580).


* fc/transport-helper-fixes (2013-12-09) 6 commits
 - remote-bzr: support the new 'force' option
 - test-hg.sh: tests are now expected to pass
 - transport-helper: check for 'forced update' message
 - transport-helper: add 'force' to 'export' helpers
 - transport-helper: don't update refs in dry-run
 - transport-helper: mismerge fix

 Updates transport-helper, fast-import and fast-export to allow the
 ref mapping and ref deletion in a way similar to the natively
 supported transports.

 Reported to break t5541, and has been stalled for a while without
 fixes.

 Will discard.


* fc/completion (2013-12-09) 1 commit
 - completion: fix completion of certain aliases

 SZEDER Gábor noticed that this breaks git -c var=val alias and
 also suggested a better description of the change.

 Has been stalled for a while without much comments from anybody
 interested.

 Will discard.


* mo/subtree-split-updates (2013-12-10) 3 commits
 - subtree: add --edit option
 - subtree: allow --squash and --message with push
 - subtree: support split --rejoin --squash

 Has been stalled for a while without much comments from anybody
 interested.

 Will discard.


* hv/submodule-ignore-fix (2013-12-06) 4 commits
 - disable complete ignorance of submodules for index - HEAD diff
 - always show committed submodules in summary after commit
 - teach add -f option for ignored submodules
 - fix 'git add' to skip submodules configured as ignored

 Teach git add to be consistent with git status when changes to
 submodules are set to be ignored, to avoid surprises after checking
 with git status to see there isn't any

Re: error: src refspec refs/heads/master matches more than one.

On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote:
  A. You are not allowed to call your branch with a string that begins with
 'refs/heads/'.
  B. Why?
  A. Because it will confuse you.
  B. I know what I am doing.
  A. ???

Your reply in
http://git.661346.n2.nabble.com/1-8-0-git-checkout-refs-heads-foo-checks-out-branch-foo-td536.html
suggests that one should explicitly use the refs/heads prefix to to work
around ambiguities in some situations.

Are there any best-practices sugestions out there about when to use the
refs/heads prefix and when not? It looks like git delibaretly cuts off this
prefix in some situations.

I don't think my problem stems from something like git branch 
refs/heads/master
Anyway, some clarifications about the usage of this prefix would be great!

-- 
Josef Wolf
j...@raven.inka.de
--
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] for-each-ref: add option to omit newlines

2014-02-14 Thread Øystein Walle

Junio C Hamano gitster at pobox.com writes:

 
 I very well understand that.  All other commands that support -z
 to give you NUL terminated output do not consider that a downside.
 Why should for-each-ref be special?
 

After I discovered log also has this there is nothing special about
for-each-ref any longer, so my patch as-is would only make things less
consistent. What is special is that they give you the option of
supplying a format string.

ls-files, diff and others print a specific list of items (paths, shas,
...) and there's no question about how they are presented other than the
delimiter between each item, to which a selection of either a newline or
a null byte is plenty.

With log, for-each-ref and rev-list (any others?) that sort of breaks
down. With the format string you're given the power to make the command
print basically anything you like, however you like; no longer only a
question of mere delimiters. It only makes sense then (to me, at least)
that the command does not meddle with the format the user has chosen.

Maybe it's all subjective... I'm okay with just leaving things as they
are. There are ways around it.


--
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: Make the git codebase thread-safe

2014-02-14 Thread Karsten Blees

Am 14.02.2014 20:16, schrieb Zachary Turner:
 For the mixed read, we wouldn't be looking for another caller of
 pread() (since it doesn't care what the file pointer is), but instead
 a caller of read() or lseek() (since those do depend on the current
 file pointer).  In index-pack.c, I see two possible culprits:
 
 1) A call to xread() from inside fill()
 2) A call to lseek in parse_pack_objects()
 
 Do you think these could be related?  If so, maybe that opens up some
 other solutions?
 

Yeah, I think that's it. The problem is that the single-threaded part 
(parse_pack_objects/parse_pack_header) _also_ calls pread (via sha1_object - 
get_data_from_pack - unpack_data). So a pread() that modifies the file 
position would naturally be bad in this single-threaded scenario. Incidentally, 
that's exactly what the lstat64 in the version below fixes (similar to 
git_pread).

 BTW, the version you posted isn't thread safe.

It is true that, in a multi-threaded scenario, my version modifies the file 
position in some indeterministic way. However, as you noted above, the file 
position is irrelevant to pread(), so that's perfectly thread-safe, as long as 
all threads use pread() exclusively.

Using [x]read() in one of the threads would _not_ be thread-safe, but we're not 
doing that here. Both fill()/xread() and parse_pack_objects()/lseek() are 
unreachable from threaded_second_pass(), and the main thread just waits for the 
background threads to complete...

 A simple alternative to ReOpenHandle is to reset the file pointer to its
 original position, as in compat/pread.c::git_pread. Thus single-theaded code
 can mix read()/pread() at will, but multi-threaded code has to use pread()
 exclusively (which is usually the case anyway). A main thread using read()
 and background threads using pread() (which is technically allowed by POSIX)
 will fail with this solution.

 This version passes the test suite on msysgit:

 8
 ssize_t mingw_pread(int fd, void *buf, size_t count, off64_t offset)
 {
 DWORD bytes_read;
 OVERLAPPED overlapped;
 off64_t current;
 memset(overlapped, 0, sizeof(overlapped));
 overlapped.Offset = (DWORD) offset;
 overlapped.OffsetHigh = (DWORD) (offset  32);

 current = lseek64(fd, 0, SEEK_CUR);

 if (!ReadFile((HANDLE)_get_osfhandle(fd), buf, count, bytes_read,
 overlapped)) {
 errno = err_win_to_posix(GetLastError());
 return -1;
 }

 lseek64(fd, current, SEEK_SET);

 return (ssize_t) bytes_read;
 }



--
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] for-each-ref: add option to omit newlines

Øystein Walle oys...@gmail.com writes:

 Maybe it's all subjective... I'm okay with just leaving things as they
 are.

Lack of -z in for-each-ref can be called an inconsistency that
already exists you may want to fix in any case.

As an extension to that, I would not be fundamentally against a new
option, e.g. --terminiator=7, that causes us to use putchar(7)
instead of putchar('\n') or putchar('\0') to terminate each records.
At that point, -z becomes a synonym for --terminator=0.

And --terminator='' might even be a natural extension to that
option to cause us not to call any putchar() there.

If we were to do that, we should do them for all commands that let
you use -z, not just for-each-ref, for consistency reasons, I
would think.




--
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 v5 02/14] trailer: process trailers from file and arguments

2014-02-14 Thread Christian Couder

From: Junio C Hamano gits...@pobox.com

 Christian Couder chrisc...@tuxfamily.org writes:
 
 For example some people might want:

 if_exists = overwrite
 if_missing = add

 while others might want:

 if_exists = overwrite
 if_missing = do_nothing

 and I don't see how we can say that with just:

 action = do_Y_if_X_and_Z
 
 Yes, but then we go back to my original question: why exists and
 missing are so special,

Because they are completely disjoint, easy to understand, and they can
avoid a lot of combinatorial explosion we would have if we used only
one action variable, while still providing lot of expressiveness.

They are just a good tradeoff for the special problem we have.

 and why there aren't two kinds of exists
 (i.e. there exists an entry with the same key, value vs there
 exists an entry with the same key).

Because it doesn't improve expressiveness much, doesn't remove much
combinatorial explosion and make it significantly more difficult to
understand, compared to only if_exists and if_missing.

 I would have understood your
 this is not too hard to understand for users if you had three
 (i.e. missing, in addition to these two flavours of exists), but
 with only two, I do not see how it is useful in a hypothetical
 situation like above.

You mean that you do not see why:

 if_exists = overwrite
 if_missing = do_nothing

is simple and expressive?

 For example, how would you express something like this only with
 if-exists vs if-missing?
 
   if_exists_exactly = ignore
 if_exists_with_different_value = append
 if_missng = prepend_to_the_beginning

First, previously in the discussion you said that you didn't want us
to talk about the where = (after | before) part, because you could
see that it was orthogonal to the other stuff, but now it looks like
you want again to put that on the table.

Then yes, it is not possible to express the above with what I
implemented. But it could be possible with only if-exists vs
if-missing like this:

if_exists = append_if_different
if_missing = prepend

And yes I think it is much better than:

if_exists_exactly = ignore
if_exists_with_different_value = append
if_missng = prepend_to_the_beginning

because we can still easily express things like:

if_exists = append_if_different_neighbor
if_missing = prepend

while it would be more difficult to understand with
if_exists_exactly, if_exists_with_different_value and
if_missing.

Thanks,
Christian.
--
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 3/3] config: teach git config --file - to read from the standard input

The patch extends git config --file interface to allow read config from
stdin.

Editing stdin or setting value in stdin is an error.

Include by absolute path is allowed in stdin config, but not by relative
path.

Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
 builtin/config.c  | 11 +
 cache.h   |  1 +
 config.c  | 58 ---
 t/t1300-repo-config.sh| 17 --
 t/t1305-config-include.sh | 14 
 5 files changed, 81 insertions(+), 20 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index de41ba50e9ca..5677c942b693 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -360,6 +360,9 @@ static int get_colorbool(int print)
 
 static void check_write(void)
 {
+   if (given_config_source.use_stdin)
+   die(writing to stdin is not supported);
+
if (given_config_source.blob)
die(writing config blobs is not supported);
 }
@@ -472,6 +475,12 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
usage_with_options(builtin_config_usage, 
builtin_config_options);
}
 
+   if (given_config_source.file 
+   !strcmp(given_config_source.file, -)) {
+   given_config_source.file = NULL;
+   given_config_source.use_stdin = 1;
+   }
+
if (use_global_config) {
char *user_config = NULL;
char *xdg_config = NULL;
@@ -558,6 +567,8 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
check_argc(argc, 0, 0);
if (!given_config_source.file  nongit)
die(not in a git directory);
+   if (given_config_source.use_stdin)
+   die(editing stdin is not supported);
if (given_config_source.blob)
die(editing blobs is not supported);
git_config(git_default_config, NULL);
diff --git a/cache.h b/cache.h
index 9d94bd69f7db..4db19b537059 100644
--- a/cache.h
+++ b/cache.h
@@ -1147,6 +1147,7 @@ extern int update_server_info(int);
 #define CONFIG_GENERIC_ERROR 7
 
 struct git_config_source {
+   unsigned int use_stdin:1;
const char *file;
const char *blob;
 };
diff --git a/config.c b/config.c
index 6269da907964..7b42608f5c89 100644
--- a/config.c
+++ b/config.c
@@ -443,10 +443,20 @@ static int git_parse_source(config_fn_t fn, void *data)
if (get_value(fn, data, var)  0)
break;
}
-   if (cf-die_on_error)
-   die(bad config file line %d in %s, cf-linenr, cf-name);
-   else
-   return error(bad config file line %d in %s, cf-linenr, 
cf-name);
+   if (cf-die_on_error) {
+   if (cf-name)
+   die(bad config file line %d in %s,
+   cf-linenr, cf-name);
+   else
+   die(bad config file line %d, cf-linenr);
+
+   } else {
+   if (cf-name)
+   return error(bad config file line %d in %s,
+   cf-linenr, cf-name);
+   else
+   return error(bad config file line %d, cf-linenr);
+   }
 }
 
 static int parse_unit_factor(const char *end, uintmax_t *val)
@@ -1030,24 +1040,34 @@ static int do_config_from(struct config_source *top, 
config_fn_t fn, void *data)
return ret;
 }
 
-int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+static int do_config_from_file(config_fn_t fn, const char *filename, FILE *f,
+  void *data)
 {
-   int ret;
-   FILE *f = fopen(filename, r);
+   struct config_source top;
 
-   ret = -1;
-   if (f) {
-   struct config_source top;
+   top.u.file = f;
+   top.name = filename;
+   top.die_on_error = 1;
+   top.do_fgetc = config_file_fgetc;
+   top.do_ungetc = config_file_ungetc;
+   top.do_ftell = config_file_ftell;
 
-   top.u.file = f;
-   top.name = filename;
-   top.die_on_error = 1;
-   top.do_fgetc = config_file_fgetc;
-   top.do_ungetc = config_file_ungetc;
-   top.do_ftell = config_file_ftell;
+   return do_config_from(top, fn, data);
+}
+
+static int git_config_from_stdin(config_fn_t fn, void *data)
+{
+   return do_config_from_file(fn, NULL, stdin, data);
+}
 
-   ret = do_config_from(top, fn, data);
+int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+{
+   int ret = -1;
+   FILE *f;
 
+   f = fopen(filename, r);
+   if (f) {
+   ret = do_config_from_file(fn, filename, f, data);
fclose(f);
}
return ret;
@@ -1188,7 +1208,9 @@ int git_config_with_options(config_fn_t fn, void *data,
 *

[PATCH 1/3] builtin/config.c: rename check_blob_write() - check_write()

The function will be reused to check for other conditions which prevent
write.

Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
 builtin/config.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index 92ebf23f0a9a..a7c55e68883c 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -362,7 +362,7 @@ static int get_colorbool(int print)
return get_colorbool_found ? 0 : 1;
 }
 
-static void check_blob_write(void)
+static void check_write(void)
 {
if (given_config_blob)
die(writing config blobs is not supported);
@@ -572,7 +572,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
}
else if (actions == ACTION_SET) {
int ret;
-   check_blob_write();
+   check_write();
check_argc(argc, 2, 2);
value = normalize_value(argv[0], argv[1]);
ret = git_config_set_in_file(given_config_file, argv[0], value);
@@ -582,21 +582,21 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
return ret;
}
else if (actions == ACTION_SET_ALL) {
-   check_blob_write();
+   check_write();
check_argc(argc, 2, 3);
value = normalize_value(argv[0], argv[1]);
return git_config_set_multivar_in_file(given_config_file,
   argv[0], value, argv[2], 
0);
}
else if (actions == ACTION_ADD) {
-   check_blob_write();
+   check_write();
check_argc(argc, 2, 2);
value = normalize_value(argv[0], argv[1]);
return git_config_set_multivar_in_file(given_config_file,
   argv[0], value, ^$, 0);
}
else if (actions == ACTION_REPLACE_ALL) {
-   check_blob_write();
+   check_write();
check_argc(argc, 2, 3);
value = normalize_value(argv[0], argv[1]);
return git_config_set_multivar_in_file(given_config_file,
@@ -623,7 +623,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
return get_urlmatch(argv[0], argv[1]);
}
else if (actions == ACTION_UNSET) {
-   check_blob_write();
+   check_write();
check_argc(argc, 1, 2);
if (argc == 2)
return 
git_config_set_multivar_in_file(given_config_file,
@@ -633,14 +633,14 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
  argv[0], NULL);
}
else if (actions == ACTION_UNSET_ALL) {
-   check_blob_write();
+   check_write();
check_argc(argc, 1, 2);
return git_config_set_multivar_in_file(given_config_file,
   argv[0], NULL, argv[1], 
1);
}
else if (actions == ACTION_RENAME_SECTION) {
int ret;
-   check_blob_write();
+   check_write();
check_argc(argc, 2, 2);
ret = git_config_rename_section_in_file(given_config_file,
argv[0], argv[1]);
@@ -651,7 +651,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
}
else if (actions == ACTION_REMOVE_SECTION) {
int ret;
-   check_blob_write();
+   check_write();
check_argc(argc, 1, 1);
ret = git_config_rename_section_in_file(given_config_file,
argv[0], NULL);
-- 
1.8.5.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 2/3] config: change git_config_with_options() interface

We're going to have more options for config source.

Let's alter git_config_with_options() interface to accept struct with
all source options.

Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
 builtin/config.c | 75 ++--
 cache.h  |  8 --
 config.c | 13 +-
 3 files changed, 47 insertions(+), 49 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index a7c55e68883c..de41ba50e9ca 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -21,8 +21,7 @@ static char key_delim = ' ';
 static char term = '\n';
 
 static int use_global_config, use_system_config, use_local_config;
-static const char *given_config_file;
-static const char *given_config_blob;
+static struct git_config_source given_config_source;
 static int actions, types;
 static const char *get_color_slot, *get_colorbool_slot;
 static int end_null;
@@ -55,8 +54,8 @@ static struct option builtin_config_options[] = {
OPT_BOOL(0, global, use_global_config, N_(use global config file)),
OPT_BOOL(0, system, use_system_config, N_(use system config file)),
OPT_BOOL(0, local, use_local_config, N_(use repository config 
file)),
-   OPT_STRING('f', file, given_config_file, N_(file), N_(use given 
config file)),
-   OPT_STRING(0, blob, given_config_blob, N_(blob-id), N_(read 
config from given blob object)),
+   OPT_STRING('f', file, given_config_source.file, N_(file), N_(use 
given config file)),
+   OPT_STRING(0, blob, given_config_source.blob, N_(blob-id), 
N_(read config from given blob object)),
OPT_GROUP(N_(Action)),
OPT_BIT(0, get, actions, N_(get value: name [value-regex]), 
ACTION_GET),
OPT_BIT(0, get-all, actions, N_(get all values: key 
[value-regex]), ACTION_GET_ALL),
@@ -224,8 +223,7 @@ static int get_value(const char *key_, const char *regex_)
}
 
git_config_with_options(collect_config, values,
-   given_config_file, given_config_blob,
-   respect_includes);
+   given_config_source, respect_includes);
 
ret = !values.nr;
 
@@ -309,8 +307,7 @@ static void get_color(const char *def_color)
get_color_found = 0;
parsed_color[0] = '\0';
git_config_with_options(git_get_color_config, NULL,
-   given_config_file, given_config_blob,
-   respect_includes);
+   given_config_source, respect_includes);
 
if (!get_color_found  def_color)
color_parse(def_color, command line, parsed_color);
@@ -339,8 +336,7 @@ static int get_colorbool(int print)
get_diff_color_found = -1;
get_color_ui_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
-   given_config_file, given_config_blob,
-   respect_includes);
+   given_config_source, respect_includes);
 
if (get_colorbool_found  0) {
if (!strcmp(get_colorbool_slot, color.diff))
@@ -364,7 +360,7 @@ static int get_colorbool(int print)
 
 static void check_write(void)
 {
-   if (given_config_blob)
+   if (given_config_source.blob)
die(writing config blobs is not supported);
 }
 
@@ -435,7 +431,7 @@ static int get_urlmatch(const char *var, const char *url)
}
 
git_config_with_options(urlmatch_config_entry, config,
-   given_config_file, NULL, respect_includes);
+   given_config_source, respect_includes);
 
for_each_string_list_item(item, values) {
struct urlmatch_current_candidate_value *matched = item-util;
@@ -464,14 +460,14 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
int nongit = !startup_info-have_repository;
char *value;
 
-   given_config_file = getenv(CONFIG_ENVIRONMENT);
+   given_config_source.file = getenv(CONFIG_ENVIRONMENT);
 
argc = parse_options(argc, argv, prefix, builtin_config_options,
 builtin_config_usage,
 PARSE_OPT_STOP_AT_NON_OPTION);
 
if (use_global_config + use_system_config + use_local_config +
-   !!given_config_file + !!given_config_blob  1) {
+   !!given_config_source.file + !!given_config_source.blob  1) {
error(only one config file at a time.);
usage_with_options(builtin_config_usage, 
builtin_config_options);
}
@@ -493,24 +489,24 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
 
if (access_or_warn(user_config, R_OK, 0) 
xdg_config  !access_or_warn(xdg_config, R_OK, 0))
-   given_config_file = xdg_config;
+   given_config_source.file = xdg_config;
else
-

Re: [PATCH v5 02/14] trailer: process trailers from file and arguments

 For example, how would you express something like this only with
 if-exists vs if-missing?

   if_exists_exactly = ignore
 if_exists_with_different_value = append
 if_missng = prepend_to_the_beginning

 First, previously in the discussion you said that you didn't want us
 to talk about the where = (after | before) part, because you could
 see that it was orthogonal to the other stuff, but now it looks like
 you want again to put that on the table.

Oh, then replace both append and prepend with append (it was a mistake).
Can you express that without having two kinds of if-exists?

 But it could be possible with only if-exists vs
 if-missing like this:

 if_exists = append_if_different
 if_missing = prepend
 ...
 because we can still easily express things like:

 if_exists = append_if_different_neighbor

The proliferation of these random if_X on the action part _is_ exactly
what I find the proposal confusing.
--
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 v5 02/14] trailer: process trailers from file and arguments

Christian Couder chrisc...@tuxfamily.org writes:

 but we also want to say:

 action = do_Y_if_X_and_Z AND do_U_if_V

 For example some people might want:

 if_exists = overwrite
 if_missing = add

 while others might want:

 if_exists = overwrite
 if_missing = do_nothing

 and I don't see how we can say that with just:

 action = do_Y_if_X_and_Z

That is a very relevant illustration that makes me realize why I
found your if-exists/if-missing = do-Y-if-Z somewhat distasteful.

Your

 if_exists = add_if_different

says if the same key is there, add it if the value is different,
but it also implicitly says donothing if the value is the same.

That is, you are saying with the above

 if_exists = add_if_different AND ignore_if_same

So you already have to support more than one actions depending on
the condition, unless you want to limit the actions for all the
cases other than X to be only ignore when you invent your next
do_Y_if_X, X being different in this case, but you support (and
need to support) different-neighbour and other random collections
of conditions, I think.  Which is essentially the same as saying
that you need this:

 action = do_Y_if_X_and_Z AND do_U_if_V

Again, unless all the U's are limited to ignore, that is.

--
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 v5 02/14] trailer: process trailers from file and arguments

Junio C Hamano gits...@pobox.com writes:

 That is, you are saying with the above

  if_exists = add_if_different AND ignore_if_same

 So you already have to support more than one actions depending on
 the condition, ...
 of conditions, I think.  Which is essentially the same as saying
 that you need this:

 action = do_Y_if_X_and_Z AND do_U_if_V

 Again, unless all the U's are limited to ignore, that is.

Oh by the way, don't get me wrong.  I am not saying that the last
one is necessarily better or worse.  I am only saying that the
semantics proposed seems to be hard to explain and we need to do
find a way to do better.

If you have these existing ones:

Sob: A
Sob: B
Sob: C
Sob: D

and you have Sob: B at hand, Sob.if-missing would not fire
(because if-exists/if-missing is only about keys) ans
Sob.if-exists will.  What happens is now up to the action part
(i.e. what follows if_exists =, e.g. add_if_different).

The conditional part of add_if_different action is explainable as
a conditon on the value (as opposed to condition on keys, which is
the left-hand-side).  But what does a condition with neighbour in
its name really mean?  It is not a condition about the value, but
also is a condition about the order of the existing records.

What is the right mental model the end-user needs to form when
understanding these?  Conditions on keys go on the left, and any
other random conditions can come as a modifier after action
e.g. add_if_same_value_is_not_at_the_end?
--
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: Make the git codebase thread-safe

On Sat, Feb 15, 2014 at 2:16 AM, Zachary Turner ztur...@chromium.org wrote:
 (Gah, sorry if you're receiving multiple emails to your personal
 addresses, I need to get used to manually setting Plain-text mode
 every time I send a message).

 For the mixed read, we wouldn't be looking for another caller of
 pread() (since it doesn't care what the file pointer is), but instead
 a caller of read() or lseek() (since those do depend on the current
 file pointer).  In index-pack.c, I see two possible culprits:

 1) A call to xread() from inside fill()
 2) A call to lseek in parse_pack_objects()

 Do you think these could be related?  If so, maybe that opens up some
 other solutions?

For index-pack alone, what's wrong with open one file handle per thread?
-- 
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: Make the git codebase thread-safe

2014-02-14 Thread Stefan Zager

On Fri, Feb 14, 2014 at 4:45 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Sat, Feb 15, 2014 at 2:16 AM, Zachary Turner ztur...@chromium.org wrote:
 (Gah, sorry if you're receiving multiple emails to your personal
 addresses, I need to get used to manually setting Plain-text mode
 every time I send a message).

 For the mixed read, we wouldn't be looking for another caller of
 pread() (since it doesn't care what the file pointer is), but instead
 a caller of read() or lseek() (since those do depend on the current
 file pointer).  In index-pack.c, I see two possible culprits:

 1) A call to xread() from inside fill()
 2) A call to lseek in parse_pack_objects()

 Do you think these could be related?  If so, maybe that opens up some
 other solutions?

 For index-pack alone, what's wrong with open one file handle per thread?

Nothing wrong with that, except that it would mean either using
thread-local storage (which the code doesn't currently use); or
plumbing pack_fd through the call stack, which doesn't sound very fun.

Stefan

 --
 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: Make the git codebase thread-safe

On Sat, Feb 15, 2014 at 7:50 AM, Stefan Zager sza...@google.com wrote:
 On Fri, Feb 14, 2014 at 4:45 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Sat, Feb 15, 2014 at 2:16 AM, Zachary Turner ztur...@chromium.org wrote:
 (Gah, sorry if you're receiving multiple emails to your personal
 addresses, I need to get used to manually setting Plain-text mode
 every time I send a message).

 For the mixed read, we wouldn't be looking for another caller of
 pread() (since it doesn't care what the file pointer is), but instead
 a caller of read() or lseek() (since those do depend on the current
 file pointer).  In index-pack.c, I see two possible culprits:

 1) A call to xread() from inside fill()
 2) A call to lseek in parse_pack_objects()

 Do you think these could be related?  If so, maybe that opens up some
 other solutions?

 For index-pack alone, what's wrong with open one file handle per thread?

 Nothing wrong with that, except that it would mean either using
 thread-local storage (which the code doesn't currently use); or
 plumbing pack_fd through the call stack, which doesn't sound very fun.

Current code does use thread-local storage (struct thread_local and
get_thread_data). Adding a new file handle when NO_THREAD_SAFE_PREAD
is defined is simpler imo.
-- 
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: Make the git codebase thread-safe

2014-02-14 Thread Zachary Turner

Even if we make that change to use TLS for this case, the
implementation of pread() will still change in such a way that the
semantics of pread() are different on Windows.  Is that ok?

Just to summarize, here's the viable approaches I've seen discussed so far:

1) Use _WINVER at compile time to select either a thread-safe or
non-thread-safe implementation of pread.  This is the easiest possible
code change, but would necessitate 2 binary distributions of git for
windows.
2) Use TLS as you suggest and have one fd per pack thread.  Probably
the most complicated code change (at least for me, being a first-time
contributor)
3) Use Karsten's suggested implementation from earlier in the thread.
Seems to work, but it's a little confusing from a readability
standpoint since the implementation is not-thread safe except in this
specific usage context.

On Fri, Feb 14, 2014 at 4:56 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Sat, Feb 15, 2014 at 7:50 AM, Stefan Zager sza...@google.com wrote:
 On Fri, Feb 14, 2014 at 4:45 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Sat, Feb 15, 2014 at 2:16 AM, Zachary Turner ztur...@chromium.org 
 wrote:
 (Gah, sorry if you're receiving multiple emails to your personal
 addresses, I need to get used to manually setting Plain-text mode
 every time I send a message).

 For the mixed read, we wouldn't be looking for another caller of
 pread() (since it doesn't care what the file pointer is), but instead
 a caller of read() or lseek() (since those do depend on the current
 file pointer).  In index-pack.c, I see two possible culprits:

 1) A call to xread() from inside fill()
 2) A call to lseek in parse_pack_objects()

 Do you think these could be related?  If so, maybe that opens up some
 other solutions?

 For index-pack alone, what's wrong with open one file handle per thread?

 Nothing wrong with that, except that it would mean either using
 thread-local storage (which the code doesn't currently use); or
 plumbing pack_fd through the call stack, which doesn't sound very fun.

 Current code does use thread-local storage (struct thread_local and
 get_thread_data). Adding a new file handle when NO_THREAD_SAFE_PREAD
 is defined is simpler imo.
 --
 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: Make the git codebase thread-safe

On Sat, Feb 15, 2014 at 8:15 AM, Zachary Turner ztur...@chromium.org wrote:
 Even if we make that change to use TLS for this case, the
 implementation of pread() will still change in such a way that the
 semantics of pread() are different on Windows.  Is that ok?

 Just to summarize, here's the viable approaches I've seen discussed so far:

 1) Use _WINVER at compile time to select either a thread-safe or
 non-thread-safe implementation of pread.  This is the easiest possible
 code change, but would necessitate 2 binary distributions of git for
 windows.
 2) Use TLS as you suggest and have one fd per pack thread.  Probably
 the most complicated code change (at least for me, being a first-time
 contributor)

It's not so complicated. I suggested a patch [1] before (surprise!).

 3) Use Karsten's suggested implementation from earlier in the thread.
 Seems to work, but it's a little confusing from a readability
 standpoint since the implementation is not-thread safe except in this
 specific usage contex

[1] http://article.gmane.org/gmane.comp.version-control.git/196042
-- 
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

[PATCH 3/4] Stop using fnmatch (either native or compat)

Since v1.8.4 (about six months ago) wildmatch is used as default
replacement for fnmatch. We have seen only one fix since so wildmatch
probably has done a good job as fnmatch replacement. This concludes
the fnmatch-wildmatch transition by no longer relying on fnmatch.

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 Makefile | 22 --
 config.mak.uname | 10 --
 configure.ac | 28 
 git-compat-util.h| 12 
 t/t3070-wildmatch.sh | 13 -
 test-wildmatch.c |  6 --
 6 files changed, 91 deletions(-)

diff --git a/Makefile b/Makefile
index dddaf4f..ca38f99 100644
--- a/Makefile
+++ b/Makefile
@@ -101,14 +101,6 @@ all::
 #
 # Define NO_MKSTEMPS if you don't have mkstemps in the C library.
 #
-# Define NO_FNMATCH if you don't have fnmatch in the C library.
-#
-# Define NO_FNMATCH_CASEFOLD if your fnmatch function doesn't have the
-# FNM_CASEFOLD GNU extension.
-#
-# Define NO_WILDMATCH if you do not 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.
 #
@@ -1271,20 +1263,6 @@ endif
 ifdef NO_STRTOULL
COMPAT_CFLAGS += -DNO_STRTOULL
 endif
-ifdef NO_FNMATCH
-   COMPAT_CFLAGS += -Icompat/fnmatch
-   COMPAT_CFLAGS += -DNO_FNMATCH
-   COMPAT_OBJS += compat/fnmatch/fnmatch.o
-else
-ifdef NO_FNMATCH_CASEFOLD
-   COMPAT_CFLAGS += -Icompat/fnmatch
-   COMPAT_CFLAGS += -DNO_FNMATCH_CASEFOLD
-   COMPAT_OBJS += compat/fnmatch/fnmatch.o
-endif
-endif
-ifndef NO_WILDMATCH
-   COMPAT_CFLAGS += -DUSE_WILDMATCH
-endif
 ifdef NO_SETENV
COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
diff --git a/config.mak.uname b/config.mak.uname
index 7d31fad..6069a44 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -108,7 +108,6 @@ ifeq ($(uname_S),SunOS)
NO_MKDTEMP = YesPlease
NO_MKSTEMPS = YesPlease
NO_REGEX = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
NO_MSGFMT_EXTENDED_OPTIONS = YesPlease
HAVE_DEV_TTY = YesPlease
ifeq ($(uname_R),5.6)
@@ -259,7 +258,6 @@ ifeq ($(uname_S),IRIX)
# issue, comment out the NO_MMAP statement.
NO_MMAP = YesPlease
NO_REGEX = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
SHELL_PATH = /usr/gnu/bin/bash
NEEDS_LIBGEN = YesPlease
@@ -279,7 +277,6 @@ ifeq ($(uname_S),IRIX64)
# issue, comment out the NO_MMAP statement.
NO_MMAP = YesPlease
NO_REGEX = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
SHELL_PATH = /usr/gnu/bin/bash
NEEDS_LIBGEN = YesPlease
@@ -296,7 +293,6 @@ ifeq ($(uname_S),HP-UX)
NO_UNSETENV = YesPlease
NO_HSTRERROR = YesPlease
NO_SYS_SELECT_H = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
NO_NSEC = YesPlease
ifeq ($(uname_R),B.11.00)
@@ -327,7 +323,6 @@ ifeq ($(uname_S),Windows)
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
-   NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
# NEEDS_LIBICONV = YesPlease
NO_ICONV = YesPlease
@@ -389,13 +384,11 @@ ifeq ($(uname_S),Interix)
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
NO_SOCKADDR_STORAGE = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
endif
ifeq ($(uname_R),5.2)
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
NO_SOCKADDR_STORAGE = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
endif
 endif
 ifeq ($(uname_S),Minix)
@@ -440,7 +433,6 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_D_TYPE_IN_DIRENT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
NO_MEMMEM = YesPlease
NO_STRLCPY = YesPlease
NO_SETENV = YesPlease
@@ -484,7 +476,6 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
-   NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
NEEDS_LIBICONV = YesPlease
NO_STRTOUMAX = YesPlease
@@ -538,7 +529,6 @@ ifeq ($(uname_S),QNX)
EXPAT_NEEDS_XMLPARSE_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_SOCKET = YesPlease
-   NO_FNMATCH_CASEFOLD = YesPlease
NO_GETPAGESIZE = YesPlease
NO_ICONV = YesPlease
NO_MEMMEM = YesPlease
diff --git a/configure.ac b/configure.ac
index 2f43393..24ab738 100644
--- a/configure.ac
+++ b/configure.ac
@@ -901,34 +901,6 @@ GIT_CHECK_FUNC(strcasestr,
 [NO_STRCASESTR=YesPlease])
 GIT_CONF_SUBST([NO_STRCASESTR])
 #
-# Define NO_FNMATCH if you don't have fnmatch

[PATCH 1/4] Use wildmatch() directly without fnmatch() wrapper

Make it clear that we don't use fnmatch() anymore.

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/apply.c|  2 +-
 builtin/branch.c   |  2 +-
 builtin/describe.c |  2 +-
 builtin/for-each-ref.c |  2 +-
 builtin/ls-remote.c|  2 +-
 builtin/name-rev.c |  2 +-
 builtin/reflog.c   |  2 +-
 builtin/replace.c  |  2 +-
 builtin/show-branch.c  |  2 +-
 builtin/tag.c  |  2 +-
 diffcore-order.c   |  2 +-
 dir.c  | 11 +++
 refs.c |  2 +-
 revision.c |  2 +-
 14 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/builtin/apply.c b/builtin/apply.c
index b0d0986..66e2eed 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -4152,7 +4152,7 @@ static int use_patch(struct patch *p)
/* See if it matches any of exclude/include rule */
for (i = 0; i  limit_by_name.nr; i++) {
struct string_list_item *it = limit_by_name.items[i];
-   if (!fnmatch(it-string, pathname, 0))
+   if (!wildmatch(it-string, pathname, 0, NULL))
return (it-util != NULL);
}
 
diff --git a/builtin/branch.c b/builtin/branch.c
index b4d7716..652b1d2 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -315,7 +315,7 @@ static int match_patterns(const char **pattern, const char 
*refname)
if (!*pattern)
return 1; /* no pattern always matches */
while (*pattern) {
-   if (!fnmatch(*pattern, refname, 0))
+   if (!wildmatch(*pattern, refname, 0, NULL))
return 1;
pattern++;
}
diff --git a/builtin/describe.c b/builtin/describe.c
index 7db43da..848acdf 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -150,7 +150,7 @@ static int get_name(const char *path, const unsigned char 
*sha1, int flag, void
return 0;
 
/* Accept only tags that match the pattern, if given */
-   if (pattern  (!is_tag || fnmatch(pattern, path + 10, 0)))
+   if (pattern  (!is_tag || wildmatch(pattern, path + 10, 0, NULL)))
return 0;
 
/* Is it annotated? */
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 51798b4..3e1d5c3 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -864,7 +864,7 @@ static int grab_single_ref(const char *refname, const 
unsigned char *sha1, int f
 refname[plen] == '/' ||
 p[plen-1] == '/'))
break;
-   if (!fnmatch(p, refname, FNM_PATHNAME))
+   if (!wildmatch(p, refname, WM_PATHNAME, NULL))
break;
}
if (!*pattern)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 39e5144..3e9eefb 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -22,7 +22,7 @@ static int tail_match(const char **pattern, const char *path)
if (snprintf(pathbuf, sizeof(pathbuf), /%s, path)  sizeof(pathbuf))
return error(insanely long ref %.*s..., 20, path);
while ((p = *(pattern++)) != NULL) {
-   if (!fnmatch(p, pathbuf, 0))
+   if (!wildmatch(p, pathbuf, 0, NULL))
return 1;
}
return 0;
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 0b21d7e..c824d4e 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -87,7 +87,7 @@ static int subpath_matches(const char *path, const char 
*filter)
const char *subpath = path;
 
while (subpath) {
-   if (!fnmatch(filter, subpath, 0))
+   if (!wildmatch(filter, subpath, 0, NULL))
return subpath - path;
subpath = strchr(subpath, '/');
if (subpath)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 852cff6..c12a9784 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -561,7 +561,7 @@ static void set_reflog_expiry_param(struct 
cmd_reflog_expire_cb *cb, int slot, c
return; /* both given explicitly -- nothing to tweak */
 
for (ent = reflog_expire_cfg; ent; ent = ent-next) {
-   if (!fnmatch(ent-pattern, ref, 0)) {
+   if (!wildmatch(ent-pattern, ref, 0, NULL)) {
if (!(slot  EXPIRE_TOTAL))
cb-expire_total = ent-expire_total;
if (!(slot  EXPIRE_UNREACH))
diff --git a/builtin/replace.c b/builtin/replace.c
index 2336325..80b152a 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -36,7 +36,7 @@ static int show_reference(const char *refname, const unsigned 
char *sha1,
 {
struct show_data *data = cb_data;
 
-   if (!fnmatch(data-pattern, refname, 0)) {
+   if (!wildmatch(data-pattern, refname, 0, NULL)) {
if (data-format == REPLACE_FORMAT_SHORT)

[PATCH 2/4] Revert test-wildmatch: add perf command to compare wildmatch and fnmatch

This reverts commit 1b25892636d2f250eb2163301440ee8c8c1ac944. compat
fnmatch will be removed soon and we can't rely on fnmatch() available
everywhere.

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 test-wildmatch.c | 73 
 1 file changed, 73 deletions(-)

diff --git a/test-wildmatch.c b/test-wildmatch.c
index a3e2643..1564bd5 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -4,82 +4,9 @@
 #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 char *pattern = av[1];
-
-   lang = getenv(LANG);
-   if (lang  strcmp(lang, C))
-   die(Please test it on C locale.);
-
-   if ((fd = open(file, O_RDONLY)) == -1 || fstat(fd, st))
-   die_errno(file open);
-
-   buffer = xmalloc(st.st_size + 2);
-   if (read(fd, buffer, st.st_size) != st.st_size)
-   die_errno(read);
-
-   buffer[st.st_size] = '\0';
-   buffer[st.st_size + 1] = '\0';
-   for (i = 0; i  st.st_size; i++)
-   if (buffer[i] == '\n')
-   buffer[i] = '\0';
-
-   n = atoi(av[2]);
-   if (av[3]  !strcmp(av[3], pathname)) {
-   flags1 = WM_PATHNAME;
-   flags2 = FNM_PATHNAME;
-   }
-
-   gettimeofday(tv1, NULL);
-   for (i = 0; i  n; i++) {
-   for (p = buffer; *p; p += strlen(p) + 1)
-   wildmatch(pattern, p, flags1, NULL);
-   }
-   gettimeofday(tv2, NULL);
-
-   usec1 = (uint32_t)tv2.tv_sec * 100 + tv2.tv_usec;
-   usec1 -= (uint32_t)tv1.tv_sec * 100 + tv1.tv_usec;
-   printf(wildmatch %ds %dus\n,
-  (int)(usec1 / 100),
-  (int)(usec1 % 100));
-
-   gettimeofday(tv1, NULL);
-   for (i = 0; i  n; i++) {
-   for (p = buffer; *p; p += strlen(p) + 1)
-   fnmatch(pattern, p, flags2);
-   }
-   gettimeofday(tv2, NULL);
-
-   usec2 = (uint32_t)tv2.tv_sec * 100 + tv2.tv_usec;
-   usec2 -= (uint32_t)tv1.tv_sec * 100 + tv1.tv_usec;
-   if (usec2  usec1)
-   printf(fnmatch   %ds %dus or %.2f%% slower\n,
-  (int)((usec2 - usec1) / 100),
-  (int)((usec2 - usec1) % 100),
-  (float)(usec2 - usec1) / usec1 * 100);
-   else
-   printf(fnmatch   %ds %dus or %.2f%% faster\n,
-  (int)((usec1 - usec2) / 100),
-  (int)((usec1 - usec2) % 100),
-  (float)(usec1 - usec2) / usec1 * 100);
-   return 0;
-}
-
 int main(int argc, char **argv)
 {
int i;
-
-   if (!strcmp(argv[1], perf))
-   return perf(argc - 2, argv + 2);
-
for (i = 2; i  argc; i++) {
if (argv[i][0] == '/')
die(Forward slash is not allowed at the beginning of 
the\n
-- 
1.8.5.2.240.g8478abd

--
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 4/4] Actually remove compat fnmatch source code

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 compat/fnmatch/fnmatch.c (gone) | 494 
 compat/fnmatch/fnmatch.h (gone) |  84 ---
 2 files changed, 578 deletions(-)

diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
deleted file mode 100644
index 378c467..000
--- a/compat/fnmatch/fnmatch.c
+++ /dev/null
@@ -1,494 +0,0 @@
-/* Copyright (C) 1991, 92, 93, 96, 97, 98, 99 Free Software Foundation, Inc.
-   This file is part of the GNU C Library.
-
-   This library is free software; you can redistribute it and/or
-   modify it under the terms of the GNU Library General Public License as
-   published by the Free Software Foundation; either version 2 of the
-   License, or (at your option) any later version.
-
-   This library is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-   Library General Public License for more details.
-
-   You should have received a copy of the GNU Library General Public
-   License along with this library; see the file COPYING.LIB.  If not,
-   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-   Boston, MA 02111-1307, USA.  */
-
-#if HAVE_CONFIG_H
-# include config.h
-#endif
-
-/* Enable GNU extensions in fnmatch.h.  */
-#ifndef _GNU_SOURCE
-# define _GNU_SOURCE   1
-#endif
-
-#include stddef.h
-#include errno.h
-#include fnmatch.h
-#include ctype.h
-
-#if HAVE_STRING_H || defined _LIBC
-# include string.h
-#else
-# include strings.h
-#endif
-
-#if defined STDC_HEADERS || defined _LIBC
-# include stdlib.h
-#endif
-
-/* For platforms which support the ISO C amendment 1 functionality we
-   support user defined character classes.  */
-#if defined _LIBC || (defined HAVE_WCTYPE_H  defined HAVE_WCHAR_H)
-/* Solaris 2.5 has a bug: wchar.h must be included before wctype.h.  */
-# include wchar.h
-# include wctype.h
-#endif
-
-/* Comment out all this code if we are using the GNU C Library, and are not
-   actually compiling the library itself.  This code is part of the GNU C
-   Library, but also included in many other GNU distributions.  Compiling
-   and linking in this code is a waste when using the GNU C library
-   (especially if it is a shared library).  Rather than having every GNU
-   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 NO_FNMATCH || defined NO_FNMATCH_CASEFOLD || \
-defined _LIBC || !defined __GNU_LIBRARY__
-
-
-# if defined STDC_HEADERS || !defined isascii
-#  define ISASCII(c) 1
-# else
-#  define ISASCII(c) isascii(c)
-# endif
-
-# ifdef isblank
-#  define ISBLANK(c) (ISASCII (c)  isblank (c))
-# else
-#  define ISBLANK(c) ((c) == ' ' || (c) == '\t')
-# endif
-# ifdef isgraph
-#  define ISGRAPH(c) (ISASCII (c)  isgraph (c))
-# else
-#  define ISGRAPH(c) (ISASCII (c)  isprint (c)  !isspace (c))
-# endif
-
-# define ISPRINT(c) (ISASCII (c)  isprint (c))
-# define ISDIGIT(c) (ISASCII (c)  isdigit (c))
-# define ISALNUM(c) (ISASCII (c)  isalnum (c))
-# define ISALPHA(c) (ISASCII (c)  isalpha (c))
-# define ISCNTRL(c) (ISASCII (c)  iscntrl (c))
-# define ISLOWER(c) (ISASCII (c)  islower (c))
-# define ISPUNCT(c) (ISASCII (c)  ispunct (c))
-# define ISSPACE(c) (ISASCII (c)  isspace (c))
-# define ISUPPER(c) (ISASCII (c)  isupper (c))
-# define ISXDIGIT(c) (ISASCII (c)  isxdigit (c))
-
-# define STREQ(s1, s2) ((strcmp (s1, s2) == 0))
-
-# if defined _LIBC || (defined HAVE_WCTYPE_H  defined HAVE_WCHAR_H)
-/* The GNU C library provides support for user-defined character classes
-   and the functions from ISO C amendment 1.  */
-#  ifdef CHARCLASS_NAME_MAX
-#   define CHAR_CLASS_MAX_LENGTH CHARCLASS_NAME_MAX
-#  else
-/* This shouldn't happen but some implementation might still have this
-   problem.  Use a reasonable default value.  */
-#   define CHAR_CLASS_MAX_LENGTH 256
-#  endif
-
-#  ifdef _LIBC
-#   define IS_CHAR_CLASS(string) __wctype (string)
-#  else
-#   define IS_CHAR_CLASS(string) wctype (string)
-#  endif
-# else
-#  define CHAR_CLASS_MAX_LENGTH  6 /* Namely, `xdigit'.  */
-
-#  define IS_CHAR_CLASS(string)
  \
-   (STREQ (string, alpha) || STREQ (string, upper)   \
-|| STREQ (string, lower) || STREQ (string, digit)\
-|| STREQ (string, alnum) || STREQ (string, xdigit)   \
-|| STREQ (string, space) || STREQ (string, print)\
-|| STREQ (string, punct) || STREQ (string, graph)\
-|| STREQ (string, cntrl) || STREQ (string, blank))
-# endif
-
-/* Avoid depending on library functions or files
-   whose names are inconsistent.  */
-
-# if !defined _LIBC  !defined getenv
-extern char *getenv (const char *name);
-# endif
-
-# ifndef errno
-extern int errno;
-#

[PATCH 0/4] Good bye fnmatch

Long story short, we wanted globbing wildcard ** so I ripped
wildmatch library from rsync to do it. And it opened a possibility
to replace fnmatch completely, which would provide consistent behavior
across platforms (native fnmatch behaves differently on many corner
cases), and some performance gains. I started fnmatch replacement with
4917e1e (Makefile: promote wildmatch to be the default fnmatch
implementation - 2013-05-30). This is the final step.

Nguyễn Thái Ngọc Duy (4):
  Use wildmatch() directly without fnmatch() wrapper
  Revert test-wildmatch: add perf command to compare wildmatch and fnmatch
  Stop using fnmatch (either native or compat)
  Actually remove compat fnmatch source code

 Makefile|  22 --
 builtin/apply.c |   2 +-
 builtin/branch.c|   2 +-
 builtin/describe.c  |   2 +-
 builtin/for-each-ref.c  |   2 +-
 builtin/ls-remote.c |   2 +-
 builtin/name-rev.c  |   2 +-
 builtin/reflog.c|   2 +-
 builtin/replace.c   |   2 +-
 builtin/show-branch.c   |   2 +-
 builtin/tag.c   |   2 +-
 compat/fnmatch/fnmatch.c (gone) | 494 
 compat/fnmatch/fnmatch.h (gone) |  84 ---
 config.mak.uname|  10 -
 configure.ac|  28 ---
 diffcore-order.c|   2 +-
 dir.c   |  11 +-
 git-compat-util.h   |  12 -
 refs.c  |   2 +-
 revision.c  |   2 +-
 t/t3070-wildmatch.sh|  13 --
 test-wildmatch.c|  79 ---
 22 files changed, 20 insertions(+), 759 deletions(-)

-- 
1.8.5.2.240.g8478abd

--
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/RESEND] attr: allow pattern escape using backslashes