Re: cvsps, parsecvs, svn2git and the CVS exporter mess

2013-01-05 Thread Max Horn

On 03.01.2013, at 21:53, Eric S. Raymond wrote:

 Michael Haggerty mhag...@alum.mit.edu:
 There are two good reasons that the output is written to two separate files:
 
 Those are good reasons to write to a pair of tempfiles, and I was able
 to deduce in advance most of what your explanation would be from the
 bare fact that you did it that way.
 
 They are *not* good reasons for having an interface that exposes this
 implementation detail to the caller - that choice I consider a failure
 of interface-design judgment.  But I know how to fix this in a simple and
 backward-compatible way, and will do so when I have time to write you
 a patch.  Next week or the week after, most likely.
 
 Also, the cvs2git manual page is still rather half-baked and careless,
 with several fossil references to cvs2svn that shouldn't be there and
 obviously incomplete feature coverage. Fixing these bugs is also on my
 to-do list for sometime this month.
 
 I'd be willing to put in this work anyway, but it still in the back of
 my mind that if cvs2git wins the test-suite competition I might
 officially end-of-life both cvsps and parsecvs.  One of the features
 of the new git-cvsimport is direct support for using cvs2git as a
 conversion engine.
 
 A potentially bigger problem is that if you want to handle such
 blob/dump output, you have to deal with git-fast-import format's blob
 command as opposed to only handling inline blobs.
 
 Not a problem.  All of the main potential consumers for this output,
 including reposurgeon, handle the blob command just fine.

Hm, you snipped this part of Michael's mail:

 However, if that is a
 problem, it is possible to configure cvs2git to write the blobs inline
 with the rest of the dumpfile (this mode is supported because hg
 fast-import doesn't support detached blobs).

I would call hg fast-import a main potential customer, given that there 
cvs2hg is another part of the cvs2svn suite. So I can't quite see how you can 
come to your conclusion above...



Cheers,
Max--
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] Add getenv.so for catching invalid getenv() use via LD_PRELOAD

2013-01-05 Thread Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 Perhaps this will help the getenv bug hunting (I assume we do the
 hunting on Linux platform only). So far it catches this and is stuck
 at getenv in git_pager().

  diff --git a/exec_cmd.c b/exec_cmd.c
  index 125fa6f..d8be5ce 100644
  --- a/exec_cmd.c
  +++ b/exec_cmd.c
  @@ -97,7 +97,7 @@ static void add_path(struct strbuf *out, const char *path)
   
   void setup_path(void)
   {
  -   const char *old_path = getenv(PATH);
  +   char *old_path = xstrdup(getenv(PATH));
  struct strbuf new_path = STRBUF_INIT;
   
  add_path(new_path, git_exec_path());
  @@ -110,6 +110,7 @@ void setup_path(void)
   
  setenv(PATH, new_path.buf, 1);
   
  +   free(old_path);
  strbuf_release(new_path);
   }

 contrib/getenv/Makefile |  2 ++
 contrib/getenv/getenv.c | 67 +
 2 files changed, 69 insertions(+)
 create mode 100644 contrib/getenv/Makefile
 create mode 100644 contrib/getenv/getenv.c

diff --git a/contrib/getenv/Makefile b/contrib/getenv/Makefile
new file mode 100644
index 000..4881b85
--- /dev/null
+++ b/contrib/getenv/Makefile
@@ -0,0 +1,2 @@
+getenv.so: getenv.c
+   $(CC) -g -shared -fPIC -ldl -o $@ $
diff --git a/contrib/getenv/getenv.c b/contrib/getenv/getenv.c
new file mode 100644
index 000..e351e10
--- /dev/null
+++ b/contrib/getenv/getenv.c
@@ -0,0 +1,67 @@
+#include gnu/lib-names.h
+#include sys/mman.h
+#include dlfcn.h
+#include execinfo.h
+#include stdlib.h
+#include string.h
+#include stdio.h
+
+/* Global symbols for easy access from gdb */
+static char *getenv_current;
+static char *getenv_prev;
+
+/*
+ * Intercept standard getenv() via LD_PRELOAD. The return value is
+ * made inaccessible by the next getenv() call. This helps catch
+ * places that ignore the statement The string pointed to may be
+ * overwritten by a subsequent call to getenv() [1].
+ *
+ * The backtrace is appended after the env string, which may be
+ * helpful to identify where this getenv() is called in a core dump.
+ *
+ * [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html
+ */
+char *getenv(const char *name)
+{
+   static char *(*libc_getenv)(const char*);
+   char *value;
+
+   if (!libc_getenv) {
+   void *libc = dlopen(LIBC_SO, RTLD_LAZY);
+   libc_getenv = dlsym(libc, getenv);
+   }
+   if (getenv_current) {
+   mprotect(getenv_current, strlen(getenv_current) + 1, PROT_NONE);
+   getenv_prev = getenv_current;
+   getenv_current = NULL;
+   }
+
+   value = libc_getenv(name);
+   if (value) {
+   int len = strlen(value) + 1;
+   int backtrace_len = 0;
+   void *buffer[100];
+   char **symbols;
+   int i, n;
+
+   n = backtrace(buffer, 100);
+   symbols = backtrace_symbols(buffer, n);
+   if (symbols) {
+   for (i = 0;i  n; i++)
+   backtrace_len += strlen(symbols[i]) + 1; /* \n 
*/
+   backtrace_len++; /* NULL */
+   }
+
+   getenv_current = mmap(NULL, len + backtrace_len, PROT_READ | 
PROT_WRITE,
+  MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+   memcpy(getenv_current, value, len);
+   value = getenv_current;
+
+   if (symbols) {
+   char *p = getenv_current + len;
+   for (i = 0; i  n; i++)
+   p += sprintf(p, %s\n, symbols[i]);
+   }
+   }
+   return value;
+}
-- 
1.8.0.rc2.23.g1fb49df

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


Re: [PATCH] Add getenv.so for catching invalid getenv() use via LD_PRELOAD

2013-01-05 Thread Matt Kraai
On Sat, Jan 05, 2013 at 03:55:46PM +0700, Nguyễn Thái Ngọc Duy wrote:
  Perhaps this will help the getenv bug hunting (I assume we do the
  hunting on Linux platform only). So far it catches this and is stuck
  at getenv in git_pager().

It seems like a static analysis tool might be able to detect these
problems.  Is there a way to do so using sparse?

 + n = backtrace(buffer, 100);
 + symbols = backtrace_symbols(buffer, n);
 + if (symbols) {
 + for (i = 0;i  n; i++)

s/;i/; i/

-- 
Matt Kraai
https://ftbfs.org/kraai
--
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


t7061: comments and one failure

2013-01-05 Thread Torsten Bögershausen
Hej,
TC 9 is failing (Mac OS X 10.6),
==
expecting success: 
tracked/uncommitted 
git status --porcelain --ignored actual 
test_cmp expected actual

--- expected2013-01-05 11:01:00.0 +
+++ actual  2013-01-05 11:01:00.0 +
@@ -1,4 +1,3 @@
 ?? .gitignore
 ?? actual
 ?? expected
-!! tracked/
not ok 9 - status ignored tracked directory and uncommitted file with --ignore
#   
#   tracked/uncommitted 
#   git status --porcelain --ignored actual 
#   test_cmp expected actual
#   
===
I haven't been able to dig further into this,
(I can volonteer to do some more debugging).
Looking into the code, there are 2 questions:

1) echo ignored .gitignore 
  We don't need the quoting of a simple string which does not have space in it.
2)  : untracked/ignored 
Do we need the colon here?

Would it make sence to do the following:


diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 0da1214..761a2e7 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -12,10 +12,10 @@ cat expected \EOF
 EOF
 
 test_expect_success 'status untracked directory with --ignored' '
-   echo ignored .gitignore 
+   echo ignored .gitignore 
mkdir untracked 
-   : untracked/ignored 
-   : untracked/uncommitted 
+   untracked/ignored 
+   untracked/uncommitted 
git status --porcelain --ignored actual 
test_cmp expected actual
 '
@@ -43,7 +43,7 @@ EOF
 test_expect_success 'status ignored directory with --ignore' '
rm -rf untracked 
mkdir ignored 
-   : ignored/uncommitted 
+   ignored/uncommitted 
git status --porcelain --ignored actual 
test_cmp expected actual
 '
@@ -71,8 +71,8 @@ test_expect_success 'status untracked directory with ignored 
files with --ignore
rm -rf ignored 
mkdir untracked-ignored 
mkdir untracked-ignored/test 
-   : untracked-ignored/ignored 
-   : untracked-ignored/test/ignored 
+   untracked-ignored/ignored 
+   untracked-ignored/test/ignored 
git status --porcelain --ignored actual 
test_cmp expected actual
 '
@@ -99,10 +99,10 @@ EOF
 test_expect_success 'status ignored tracked directory with --ignore' '
rm -rf untracked-ignored 
mkdir tracked 
-   : tracked/committed 
+   tracked/committed 
git add tracked/committed 
git commit -m. 
-   echo tracked .gitignore 
+   echo tracked .gitignore 
git status --porcelain --ignored actual 
test_cmp expected actual
 '
@@ -126,7 +126,7 @@ cat expected \EOF
 EOF
 
 test_expect_success 'status ignored tracked directory and uncommitted file 
with --ignore' '
-   : tracked/uncommitted 
+   tracked/uncommitted 
git status --porcelain --ignored actual 
test_cmp expected actual
 '


/Torsten




--
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] Add getenv.so for catching invalid getenv() use via LD_PRELOAD

2013-01-05 Thread Duy Nguyen
On Sat, Jan 5, 2013 at 5:39 PM, Matt Kraai kr...@ftbfs.org wrote:
 On Sat, Jan 05, 2013 at 03:55:46PM +0700, Nguyễn Thái Ngọc Duy wrote:
  Perhaps this will help the getenv bug hunting (I assume we do the
  hunting on Linux platform only). So far it catches this and is stuck
  at getenv in git_pager().

 It seems like a static analysis tool might be able to detect these
 problems.  Is there a way to do so using sparse?

That was my first thought. But this may involve flow analysis and I
don't think sparse is up to it. ccc-analyzer is still pretty basic.
And between static analysis and runtime check, I prefer the latter as
it's more reliable as long as you have a good coverage test.


 + n = backtrace(buffer, 100);
 + symbols = backtrace_symbols(buffer, n);
 + if (symbols) {
 + for (i = 0;i  n; i++)

 s/;i/; i/

Thanks. I will fix it later if people actually want this.
-- 
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: [BUG] git submodule update is not fail safe

2013-01-05 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 04/01/2013 22:51, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 $ git submodule update --init
 ...
 Submodule 'roms/vgabios' (git://git.qemu.org/vgabios.git/) registered
 for path 'roms/vgabios'
 fatal: unable to connect to anongit.freedesktop.org:
 anongit.freedesktop.org[0: 131.252.210.161]: errno=Connection timed out

 Unable to fetch in submodule path 'pixman'

 $ git submodule update --init
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'

 The problem is easy to solve: manually remove the pixman directory;
 however IMHO git submodule update should not fail this way since it may
 confuse the user.
 
 Sounds like a reasonable observation.  Jens, Heiko, comments?

I have found another, related problem.

Today I tried to update qemu submodules again, however the command
failed with an obscure error message:

$ git submodule update pixman
fatal: Needed a single revision
Unable to find current revision in submodule path 'pixman'


The pixman submodule is the one that I failed to update in the very begin.
The problem is not with the pixman or qemu repository: if I clone again
qemu (with the --recursive option), all is ok.

The problem is with the private working copy (in .git/modules/pixman)
being corrupted:

$git log
fatal: bad default revision 'HEAD'.

The HEAD file contains ref: refs/heads/master, but the refs/heads
directory is empty.


By the way: since git submodule is a porcelain command, IMHO it should
not show to the user these low level error message; at least it should
give more details.
As an example, in this case it could say something like:

  the local module pixmap seems to be corrupted.
  Run xxx to remove the module and yyy to create it again.

The ideal solution is, for submodule update, to never leave an
incomplete directory; that is: the update command should be atomic.


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDoMAEACgkQscQJ24LbaUQVugCggdl36Hx5JIW/hd1SVXWv+ths
zpYAnR+93BfDLaFhXEiaQvu/TickmDA0
=2Mnw
-END PGP SIGNATURE-
--
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] git submodule update is not fail safe

2013-01-05 Thread Jens Lehmann
Am 04.01.2013 22:51, schrieb Junio C Hamano:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 $ git submodule update --init
 ...
 Submodule 'roms/vgabios' (git://git.qemu.org/vgabios.git/) registered
 for path 'roms/vgabios'
 fatal: unable to connect to anongit.freedesktop.org:
 anongit.freedesktop.org[0: 131.252.210.161]: errno=Connection timed out

 Unable to fetch in submodule path 'pixman'

 $ git submodule update --init
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'

 The problem is easy to solve: manually remove the pixman directory;
 however IMHO git submodule update should not fail this way since it may
 confuse the user.
 
 Sounds like a reasonable observation.  Jens, Heiko, comments?

The reason seems to be that clone leaves a partial initialized .git
directory in case of connection problems. The next time submodule
update runs it tries to revive the submodule from .git/modules/name
but fails as there are no objects in it.

This looks like a bug in clone to me, as it takes precautions to clean
up if something goes wrong but doesn't do that in this case. But while
glancing over the code I didn't find out what goes wrong here.

If this isn't seen as a bug in clone, we could also remove the
.git/modules/name directory in module_clone() of git-submodule.s
h when the clone fails. Manilo, does the following patch remove the
problems you are seeing (after removing .git/modules/pixman manually)?

diff --git a/git-submodule.sh b/git-submodule.sh
index 2365149..4098702 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -208,7 +208,10 @@ module_clone()
git clone $quiet -n ${reference:+$reference} \
--separate-git-dir $gitdir $url $sm_path
) ||
-   die $(eval_gettext Clone of '\$url' into submodule path 
'\$sm_path' failed)
+   (
+   rm -rf $gitdir 
+   die $(eval_gettext Clone of '\$url' into submodule 
path '\$sm_path' failed)
+   )
fi

# We already are at the root of the work tree but cd_to_toplevel will

--
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: [RFC/PATCH] avoid SIGPIPE warnings for aliases

2013-01-05 Thread Jeff King
On Fri, Jan 04, 2013 at 02:20:52PM -0800, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  I have two reservations with this patch:
 
1. We are ignoring SIGPIPE all the time. For an alias that is calling
   log, that is fine. But if pack-objects dies on the server side,
   seeing that it died from SIGPIPE is useful data, and we are
   squelching that. Maybe callers of run-command should have to pass
   an ignore SIGPIPE flag?
 
 What should this do:
 
 GIT_PAGER='head -n 1' git -p -c alias.o='!cat longfile' o
 
 Should it behave just like
 
 cat longfile | head -n 1
 
 or should it behave differently?

With respect to error messages, I'd think they should behave the same.
But they don't necessarily. The latter does not print any message at
all. But consider this version of the former:

  $ cat foo
  #!/bin/sh
  exec cat longfile

  $ git -c alias.o='!./foo' o | head -n 1
  error: ./foo died of signal 13
  fatal: While expanding alias 'o': './foo': Success

So why don't we see that message more often? There are two reasons.

One reason is that we piped it ourselves here. When git pipes to the
pager, it sends stderr along the same channel. So even if you did:

  GIT_PAGER='head -n 1' git -p -c alias.o='!./foo' o

git writes the error, but it goes to the pager, which has already ended
(since that is what caused the SIGPIPE in the first place). But imagine
that your sub-command is actually invoking git itself, and it is the
sub-git which starts the pager. Meaning the outer git wrapper's stderr
is _not_ redirected. Like this:

  $ cat foo
  #!/bin/sh
  exec git log -p

  $ GIT_PAGER='head -n 1' git -c alias.o='!./foo' o
  error: ./foo died of signal 13
  fatal: While expanding alias 'o': './foo': Success

The second reason is that most shells will eat the SIGPIPE exit
status, and convert it into a high, positive error code. You can see
that effect here:

  $ GIT_PAGER='head -n 1' git log -p
  $ echo $?
  141

And since we execute aliases via the shell, we end up seeing the
converted exit code (141) instead of the signal death. _Unless_ we
optimize out the shell call (which is why we see it by putting the
command inside ./foo, which git executes directly, but not when we
give the literal cat longfile, which git will feed to the shell).

Or at least that's _one_ way to see it. Another way is to use a shell
that does not do such conversion. Setting SHELL_PATH to zsh seems to do
so, and I think that is how Bart ran into it (my patch is a followup to
a Google+ posting he made).

 I am having a feeling that whatever external command given as the
 value of alias.$cmd should choose what error status it wants to be
 reported.

I suppose. It means that our do not run the shell if there are no
meta-characters optimization is leaky, since the exit code behaves
differently depending on whether we run the shell (and depending on your
exact shell). One solution would be to fix that leakiness, and if
use_shell is in effect for run-command, to convert a signal death into
the value that the shell would otherwise give us.

In fact, I really wonder if this code from wait_or_whine is actually
correct:

  code = WTERMSIG(status);
  /*
   * This return value is chosen so that code  0xff
   * mimics the exit code that a POSIX shell would report for
   * a program that died from this signal.
   */
  code -= 128;

If we get signal 13, we end up with -115, because code is signed. When
the lower 8 bits are taken, and then converted into an unsigned value,
we get 141: the shell value.

But do we really want to return a negative value here? Should this
instead be:

  code += 128

which yields the same code when fed to exit, but internally looks like
the shell version to us? So we get a consistent result whether the shell
was actually used or not.

That makes more sense to me, and would mean that whether we converted
the signal number or whether it was done by a subshell, it looks the
same to us. Callers which care about signals (e.g., the recent changes
to launch_editor to detect SIGINT) would have to be adjusted. But I
think it fixes an obscure bug there. Right now launch_editor is actually
checking the whether the _shell_ died from a signal, and will fail to
notice when an editor invoked by the shell is killed by those signals
(this would be pretty rare, though, because typically SIGINT is
delivered to the shell as well as the editor).

This would also fix the code in handle_alias. It looks for a negative
return code from run_command as the sign that there was an internal
error running the command, and that errno would be valid. But right now
a negative return can also come from signal death.

2. The die_errno in handle_alias is definitely wrong. Even if we want
   to print a message for signal death, showing errno is bogus unless
   the return value was -1. But is it the right thing to just pass the
   negative value straight to exit()? It works, but it is depending on
   the 

Re: [PATCH] gitk: Display the date of a tag in a human friendly way.

2013-01-05 Thread Anand Kumria
Hi Junio,

On 4 January 2013 23:50, Junio C Hamano gits...@pobox.com wrote:
 Anand Kumria wildf...@progsoc.org writes:

 By selecting a tag within gitk you can display information about it.
 This information is output by using the command

  'git cat-file tag tagid'

 This outputs the *raw* information from the tag, amongst which is the
 time - in seconds since the epoch. As useful as that value is, I find it
 a lot easier to read and process time which it is something like:

  Mon Dec 31 14:26:11 2012 -0800

 This change will modify the display of tags in gitk like so:

   @@ -1,7 +1,7 @@
object 5d417842efeafb6e109db7574196901c4e95d273
type commit
tag v1.8.1
   -tagger Junio C Hamano gits...@pobox.com 1356992771 -0800
   +tagger Junio C Hamano gits...@pobox.com Mon Dec 31 14:26:11 2012 -0800

Git 1.8.1
-BEGIN PGP SIGNATURE-

 Signed-off-by: Anand Kumria wildf...@progsoc.org
 ---

 Sounds like a sensible thing to do but I didn't check how else
 (other than purely for displaying) this string is used.

As far as I can tell it is only used for display (cached_tagcontent in
gitk) purposes.

 Paul, the patch is not made against your tree, so if you choose to
 take it you would need to strip the leading directory at the top.

Sorry, I didn't know that gitk had been split back out (and
Documentation/gitk.txt still mentions it is part of the git suite).

Regards,
Anand
--
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] git submodule update is not fail safe

2013-01-05 Thread Jens Lehmann
Am 05.01.2013 14:52, schrieb Manlio Perillo:
 Il 04/01/2013 22:51, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 $ git submodule update --init
 ...
 Submodule 'roms/vgabios' (git://git.qemu.org/vgabios.git/) registered
 for path 'roms/vgabios'
 fatal: unable to connect to anongit.freedesktop.org:
 anongit.freedesktop.org[0: 131.252.210.161]: errno=Connection timed out

 Unable to fetch in submodule path 'pixman'

 $ git submodule update --init
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'

 The problem is easy to solve: manually remove the pixman directory;
 however IMHO git submodule update should not fail this way since it may
 confuse the user.
 
 Sounds like a reasonable observation.  Jens, Heiko, comments?
 
 I have found another, related problem.
 
 Today I tried to update qemu submodules again, however the command
 failed with an obscure error message:
 
 $ git submodule update pixman
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'
 
 
 The pixman submodule is the one that I failed to update in the very begin.
 The problem is not with the pixman or qemu repository: if I clone again
 qemu (with the --recursive option), all is ok.
 
 The problem is with the private working copy (in .git/modules/pixman)
 being corrupted:
 
 $git log
 fatal: bad default revision 'HEAD'.
 
 The HEAD file contains ref: refs/heads/master, but the refs/heads
 directory is empty.

Yep, as I explained in my other email the partially set up
.git/modules/pixman is the reason for the trouble you have.

 By the way: since git submodule is a porcelain command, IMHO it should
 not show to the user these low level error message; at least it should
 give more details.
 As an example, in this case it could say something like:
 
   the local module pixmap seems to be corrupted.
   Run xxx to remove the module and yyy to create it again.
 
 The ideal solution is, for submodule update, to never leave an
 incomplete directory; that is: the update command should be atomic.

I agree that submodule update should not leave an inconsistent state.
In that case you wouldn't see any low level error messages (which I
think is ok if something the porcelain didn't expect to happen occurs,
like it did here).
--
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] run-command: encode signal death as a positive integer

2013-01-05 Thread Jeff King
On Sat, Jan 05, 2013 at 09:03:16AM -0500, Jeff King wrote:

 In fact, I really wonder if this code from wait_or_whine is actually
 correct:
 
   code = WTERMSIG(status);
   /*
* This return value is chosen so that code  0xff
* mimics the exit code that a POSIX shell would report for
* a program that died from this signal.
*/
   code -= 128;

After looking at it some more, it is correct, but I think we could make
life slightly easier for callers. See the patch below.  I've tried to
re-state the somewhat rambling argument from my previous email;
hopefully it makes sense.

-- 8 --
Subject: [PATCH] run-command: encode signal death as a positive integer

When a sub-command dies due to a signal, we encode the
signal number into the numeric exit status as signal -
128. This is easy to identify (versus a regular positive
error code), and when cast to an unsigned integer (e.g., by
feeding it to exit), matches what a POSIX shell would return
when reporting a signal death in $? or through its own exit
code.

So we have a negative value inside the code, but once it
passes across an exit() barrier, it looks positive (and any
code we receive from a sub-shell will have the positive
form). E.g., death by SIGPIPE (signal 13) will look like
-115 to us in inside git, but will end up as 141 when we
call exit() with it. And a program killed by SIGPIPE but run
via the shell will come to us with an exit code of 141.

Unfortunately, this means that when the use_shell option
is set, we need to be on the lookout for _both_ forms. We
might or might not have actually invoked the shell (because
we optimize out some useless shell calls). If we didn't invoke
the shell, we will will see the sub-process's signal death
directly, and run-command converts it into a negative value.
But if we did invoke the shell, we will see the shell's
128+signal exit status. To be thorough, we would need to
check both, or cast the value to an unsigned char (after
checking that it is not -1, which is a magic error value).

Fortunately, most callsites do not care at all whether the
exit was from a code or from a signal; they merely check for
a non-zero status, and sometimes propagate the error via
exit(). But for the callers that do care, we can make life
slightly easier by just using the consistent positive form.

This actually fixes two minor bugs:

  1. In launch_editor, we check whether the editor died from
 SIGINT or SIGQUIT. But we checked only the negative
 form, meaning that we would fail to notice a signal
 death exit code which was propagated through the shell.

  2. In handle_alias, we assume that a negative return value
 from run_command means that errno tells us something
 interesting (like a fork failure, or ENOENT).
 Otherwise, we simply propagate the exit code. Negative
 signal death codes confuse us, and we print a useless
 unable to run alias 'foo': Success message. By
 encoding signal deaths using the positive form, the
 existing code just propagates it as it would a normal
 non-zero exit code.

The downside is that callers of run_command can no longer
differentiate between a signal received directly by the
sub-process, and one propagated. However, no caller
currently cares, and since we already optimize out some
calls to the shell under the hood, that distinction is not
something that should be relied upon by callers.

Signed-off-by: Jeff King p...@peff.net
---
 Documentation/technical/api-run-command.txt | 6 ++
 editor.c| 2 +-
 run-command.c   | 2 +-
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/Documentation/technical/api-run-command.txt 
b/Documentation/technical/api-run-command.txt
index f18b4f4..5d7d7f2 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -55,10 +55,8 @@ The functions above do the following:
   non-zero.
 
 . If the program terminated due to a signal, then the return value is the
-  signal number - 128, ie. it is negative and so indicates an unusual
-  condition; a diagnostic is printed. This return value can be passed to
-  exit(2), which will report the same code to the parent process that a
-  POSIX shell's $? would report for a program that died from the signal.
+  signal number + 128, ie. the same value that a POSIX shell's $? would
+  report.  A diagnostic is printed.
 
 
 `start_async`::
diff --git a/editor.c b/editor.c
index 065a7ab..27bdecd 100644
--- a/editor.c
+++ b/editor.c
@@ -51,7 +51,7 @@ int launch_editor(const char *path, struct strbuf *buffer, 
const char *const *en
sigchain_push(SIGINT, SIG_IGN);
sigchain_push(SIGQUIT, SIG_IGN);
ret = finish_command(p);
-   sig = ret + 128;
+   sig = ret - 128;
sigchain_pop(SIGINT);
sigchain_pop(SIGQUIT);
if (sig == SIGINT || sig == SIGQUIT)
diff 

Re: [BUG] git submodule update is not fail safe

2013-01-05 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 15:01, Jens Lehmann ha scritto:
 [...]
 $ git submodule update --init
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'

 The problem is easy to solve: manually remove the pixman directory;
 however IMHO git submodule update should not fail this way since it may
 confuse the user.

 Sounds like a reasonable observation.  Jens, Heiko, comments?
 
 The reason seems to be that clone leaves a partial initialized .git
 directory in case of connection problems. The next time submodule
 update runs it tries to revive the submodule from .git/modules/name
 but fails as there are no objects in it.
 
 [...]

 If this isn't seen as a bug in clone, we could also remove the
 .git/modules/name directory in module_clone() of git-submodule.s
 h when the clone fails. Manilo,

Its Manlio, not Manilo ;-).

 does the following patch remove the
 problems you are seeing (after removing .git/modules/pixman manually)?
 

I don't think I can test it right now, since the problem can only be
reproduced when git clone fails due to network problems.

Without the patch, if I remove the .git/modules/pixman directory,
`git submodule update --init pixamp` fails:

  Unable to find current revision in submodule path 'pixman'
  fatal: Not a git repository: pixman/../.git/modules/pixman


To reproduce the problem, however, it seems all you need to do is to
send SIGINT signal during `git submodule update` :

  $ git submodule update --init pixman
  Cloning into 'pixman'...
  remote: Counting objects: 10137, done.
  ^C

  $ git submodule update pixman
  remote: Counting objects: 10137, done.
  ^C

  $ git submodule update pixman
  fatal: Needed a single revision
  Unable to find current revision in submodule path 'pixman'


Note that I had to send SIGINT two times, in order to corrupt the module.

I suspect your patch does not fix this (since I don't get the Clone
failed error message).


I also noted that If I send SIGINT before git starts counting remote
objects, I get a different count number:


  $ git submodule update pixman
  Cloning into 'pixman'...
  ^C

  $ git submodule update pixman
  remote: Counting objects: 9757, done.
  ^C

  $ git submodule update pixman
  fatal: Needed a single revision
  Unable to find current revision in submodule path 'pixman'


Note that git is reporting 9757 remote objects, instead of 10137.


P.S.:
sorry for the mail I sent today.
It reported the exact same problem I reported yesterday: this morning I
was rather sure that I got a different error message from submodule
update...



Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDoPZMACgkQscQJ24LbaUTfNQCdFvhSQwGlJZlvOr+TIHHyDFJY
d8AAn0zuHKjBGIcqr8RH/rftHjomvPtM
=48RN
-END PGP SIGNATURE-
--
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] git submodule update is not fail safe

2013-01-05 Thread Jens Lehmann
Am 05.01.2013 15:01, schrieb Jens Lehmann:
 Am 04.01.2013 22:51, schrieb Junio C Hamano:
 Manlio Perillo manlio.peri...@gmail.com writes:

 $ git submodule update --init
 ...
 Submodule 'roms/vgabios' (git://git.qemu.org/vgabios.git/) registered
 for path 'roms/vgabios'
 fatal: unable to connect to anongit.freedesktop.org:
 anongit.freedesktop.org[0: 131.252.210.161]: errno=Connection timed out

 Unable to fetch in submodule path 'pixman'

 $ git submodule update --init
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'

 The problem is easy to solve: manually remove the pixman directory;
 however IMHO git submodule update should not fail this way since it may
 confuse the user.

 Sounds like a reasonable observation.  Jens, Heiko, comments?
 
 The reason seems to be that clone leaves a partial initialized .git
 directory in case of connection problems. The next time submodule
 update runs it tries to revive the submodule from .git/modules/name
 but fails as there are no objects in it.
 
 This looks like a bug in clone to me, as it takes precautions to clean
 up if something goes wrong but doesn't do that in this case. But while
 glancing over the code I didn't find out what goes wrong here.

I dug a bit deeper here and found the reason: In remove_junk() of
builtin/clone.c the junk_git_dir points to the gitfile in the
submodules work tree, not the .git/modules/name directory where
clone was told to put the git directory. Will see if I can come up
with a patch soonish ...
--
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] fix compilation with NO_PTHREADS

2013-01-05 Thread Jeff King
Commit 1327452 cleaned up an unused parameter from
wait_or_whine, but forgot to update a caller that is inside
#ifdef NO_PTHREADS.

Signed-off-by: Jeff King p...@peff.net
---
I happened to notice this while looking at the sigpipe topic. I guess
not many people are building with NO_PTHREADS these days.

 run-command.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/run-command.c b/run-command.c
index cfb7274..0471219 100644
--- a/run-command.c
+++ b/run-command.c
@@ -725,7 +725,7 @@ int finish_async(struct async *async)
 int finish_async(struct async *async)
 {
 #ifdef NO_PTHREADS
-   return wait_or_whine(async-pid, child process, 0);
+   return wait_or_whine(async-pid, child process);
 #else
void *ret = (void *)(intptr_t)(-1);
 
-- 
1.8.1.rc1.16.g6d46841
--
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: cvsps, parsecvs, svn2git and the CVS exporter mess

2013-01-05 Thread Eric S. Raymond
Max Horn post...@quendi.de:
 Hm, you snipped this part of Michael's mail:
 
  However, if that is a
  problem, it is possible to configure cvs2git to write the blobs inline
  with the rest of the dumpfile (this mode is supported because hg
  fast-import doesn't support detached blobs).
 
 I would call hg fast-import a main potential customer, given that there 
 cvs2hg is another part of the cvs2svn suite. So I can't quite see how you 
 can come to your conclusion above...

Perhaps I was unclear.  I consider the interface design error to
be not in the fact that all the blobs are written first or detached,
but rather that the implementation detail of the two separate journal
files is ever exposed.

I understand why the storage of intermediate results was done this
way, in order to decrease the tool's working set during the run, but
finishing by automatically concatenating the results and streaming
them to stdout would surely have been the right thing here.
 
The downstream cost of letting the journalling implementation be
exposed, instead, can be seen in this snippet from the new git-cvsimport
I've been working on:

def command(self):
Emit the command implied by all previous options.
return (cvs2git --username=git-cvsimport --quiet --quiet 
--blobfile={0} --dumpfile={1} {2} {3}  cat {0} {1}  rm {0} 
{1}).format(tempfile.mkstemp()[1], tempfile.mkstemp()[1], self.opts, 
self.modulepath)

According to the documentation, every caller of csv2git must go
through analogous contortions!  This is not the Unix way; if Unix
design principles had been minimally applied, that second line would
just read like this:

 return cvs2git --username=git-cvsimport --quiet --quiet

If Unix design principles had been thoroughly applied, the --quiet
--quiet part would be unnecessary too - well-behaved Unix commands
*default* to being completely quiet unless either (a) they have an
exceptional condition to report, or (b) their expected running time is
so long that tasteful silence would leave users in doubt that they're
working.

(And yes, I do think violating these principles is a lapse of taste when
git tools do it, too.)

Michael Haggerty wants me to trust that cvs2git's analysis stage has
been fixed, but I must say that is a more difficult leap of faith when
two of the most visible things about it are still (a) a conspicuous
instance of interface misdesign, and (b) documentation that is careless and
incomplete.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/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: cvsps, parsecvs, svn2git and the CVS exporter mess

2013-01-05 Thread Eric S. Raymond
Bart Massey b...@cs.pdx.edu:
 I don't know what Eric Raymond officially end-of-life-ing parsecvs means?

You and Keith handed me the maintainer's baton.  If I were to EOL it,
that would be the successor you two designated judging in public that
the code is unsalvageable or has become pointless.  If you wanted to
exclude the possibility that a successor would make that call, you
shouldn't have handed it off in a state so broken that I can't even
test it properly.

But I don't in fact think the parsecvs code is pointless. The fact that it
only needs the ,v files is nifty and means it could be used as an RCS
exporter too.  The parsing and topo-analysis stages look like really
good work, very crisp and elegant (which is no less than I'd expect
from Keith, actually).

Alas, after wrestling with it I'm beginning to wonder whether the
codebase is salvageable by anyone but Keith himself.  The tight coupling
to the git cache mechanism is the biggest problem.  So far, I can't
figure out what tree.c is actually doing in enough detail to fix it or pry
it loose - the code is opaque and internal documentation is lacking.

More generally, interfacing to the unstable API of libgit was clearly
a serious mistake, leading directly to the current brokenness.  The
tool should have emitted an import stream to begin with.  I'm trying
to fix that, but success is looking doubtful.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/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


[PATCH] git-fast-import(1): remove duplicate --done option

2013-01-05 Thread John Keeping
The --done option to git-fast-import is documented twice in its manual
page.  Combine the best bits of each description, keeping the location
of the instance that was added first.

Signed-off-by: John Keeping j...@keeping.me.uk
---
I'm guessing that the reason the option was documented again (in commit
3266de10) is because the options are not in an obvious order.  There
does seem to be some grouping of the options by type, but without
subheadings I wonder if it would make more sense to just put them all in
alphabetical order?

 Documentation/git-fast-import.txt | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-fast-import.txt 
b/Documentation/git-fast-import.txt
index 68bca1a..4ef5721 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -39,10 +39,6 @@ OPTIONS
See ``Date Formats'' below for details about which formats
are supported, and their syntax.
 
--- done::
-   Terminate with error if there is no 'done' command at the
-   end of the stream.
-
 --force::
Force updating modified existing branches, even if doing
so would cause commits to be lost (as the new commit does
@@ -108,7 +104,8 @@ OPTIONS
output.
 
 --done::
-   Require a `done` command at the end of the stream.
+   Terminate with error if there is no 'done' command at the
+   end of the stream.
This option might be useful for detecting errors that
cause the frontend to terminate before it has started to
write a stream.
-- 
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Documentation: fix man page dependency on asciidoc.conf

2013-01-05 Thread John Keeping
When building manual pages, the source text is transformed to XML with
AsciiDoc before the man pages are generated from the XML with xmlto.

Fix the dependency in the Makefile so that the XML files are rebuilt
when asciidoc.conf changes and not just the manual pages from unchanged
XML.

Signed-off-by: John Keeping j...@keeping.me.uk
---
 Documentation/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/Makefile b/Documentation/Makefile
index e53d333..71d2b4a 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -178,7 +178,7 @@ all: html man
 
 html: $(DOC_HTML)
 
-$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf
+$(DOC_HTML) $(MAN_XML): asciidoc.conf
 
 man: man1 man5 man7
 man1: $(DOC_MAN1)
-- 
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-01-05 Thread Jeff King
On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote:

 The general approach is to setup a transaction and either 
 commit or abort it.  A transaction can be setup by renaming 
 an appropriately setup directory to the ref.lock name.  If 
 the rename succeeds, the transaction is begun.  Any actor can 
 abort the transaction (up until it is committed) by simply 
 deleting the ref.lock directory, so it is not at risk of 
 going stale.

Deleting a directory is not atomic, as you first have to remove the
contents, putting it into a potentially inconsistent state. I'll assume
you deal with that later...

 One important piece of the transaction is the use of uuids.  
 The uuids provide a mechanism to tie the atomic commit pieces 
 to the transactions and thus to prevent long sleeping process 
 from inadvertently performing actions which could be out of 
 date when they wake finally up.

Has this been a problem for you in practice? Avoiding this is one of the
reasons that git does not take out long locks; instead, it takes the
lock only at the moment it is ready to write, and aborts if it has been
updated since the longer-term operation began. This has its own problems
(you might do a lot of work only to have your operation aborted), but I
am not sure that your proposal improves on that.

Your proposal does sound like it could potentially improve robustness
when killing stale transactions (i.e., you know that the transaction
originator will never wake up and think it still has the lock). But
again, is that a problem in practice? Git typically holds ref locks for
a few syscalls. If you are conservative about leaving potentially stale
locks in place (e.g., give them a few minutes to complete before
assuming they are now bogus), you will not run into that problem.

The more conservative you are about treating a lock as stale, of course,
the less performant you will be in the face of stale locks. But since
they're the exception, that isn't a big problem in practice (at least it
has not been for me).

 In each case, the atomic 
 commit piece is the renaming of a file.   For the create and 
 update pieces, a file is renamed from the ref.lock dir to 
 the ref file resulting in an update to the sha for the ref.

I think we've had problems with cross-directory renames on some
filesystems, but I don't recall the details. I know that Coda does not
like cross-directory links, but cross-directory renames are OK (and in
fact we fall back to the latter when the former does not work).

Ah, here we go: 5723fe7 (Avoid cross-directory renames and linking on
object creation, 2008-06-14). Looks like NFS is the culprit.

 In the case of a delete, the actor may verify that ref 
 currently contains the sha to prune if it needs to, and 
 then renames the ref file to ref.lock/uuid/delete. On 
 success, the ref was deleted.
 
 Whether successful or not, the actor may now simply delete 
 the ref.lock directory, clearing the way for a new 
 transaction.  Any other actor may delete this directory at 
 any time also, likely either on conflict (if they are 
 attempting to initiate a transaction), or after a grace 
 period just to cleanup the FS.  Any actor may also safely 
 cleanup the tmp directories, preferably also after a grace 
 period.

Hmm. So what happens to the delete file when the ref.lock directory is
being deleted? Presumably deleting the ref.lock directory means doing it
recursively (which is non-atomic). But then why are we keeping the
delete file at all, if we're just about to remove it?

What happens if another process wants to cancel a transaction that is
partially done? That is, the ref.lock directory is created, but it
contains the uuid subdir? It sounds like it's OK to just delete from it,
and the original process will then fail at its rename?

 One neat part about this scheme is that I believe it would be 
 backwards compatible with the current locking mechanism since 
 the transaction directory will simply appear to be a lock to 
 older clients.  And the old lock file should continue to lock 
 out these newer transactions.

Yeah, I don't see anything that would prevent that. The current code
only cares about open($ref.lock, O_EXCL). But that should be correct
and atomic with respect to the renamed directories. You are depending on
atomic directory renames. Those aren't used anywhere yet in git, as far
as I know. So that may run into problems (but there's no reason this
system couldn't be optional for filesystems that are more abled, and
other systems could fall back to the straight-file locking).


So in response to your question, no, I don't see any real showstoppers
here. And unlike the all refs are files in a directory scheme, it's
confined to writing, which solves the readdir() atomicity questions I
had there.

I still can't say I'm super excited about it, just because it seems like
a solution in search of a problem that I have not experienced myself.
But if it's solving a problem for you, I don't want to 

Re: [PATCH] git-fast-import(1): remove duplicate --done option

2013-01-05 Thread Eric S. Raymond
John Keeping j...@keeping.me.uk:
 I'm guessing that the reason the option was documented again (in commit
 3266de10) is because the options are not in an obvious order.  There
 does seem to be some grouping of the options by type, but without
 subheadings I wonder if it would make more sense to just put them all in
 alphabetical order?

+1

This duplication originated with me. I'll apologize with a 
reordering patch.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/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


[PATCH] Alphabetize the fast-import options, following a suggestion on the list.

2013-01-05 Thread Eric S. Raymond
---
 Documentation/git-fast-import.txt | 94 +++
 1 file changed, 45 insertions(+), 49 deletions(-)

diff --git a/Documentation/git-fast-import.txt 
b/Documentation/git-fast-import.txt
index 68bca1a..d006bcf 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -33,24 +33,9 @@ the frontend program in use.
 
 OPTIONS
 ---
---date-format=fmt::
-   Specify the type of dates the frontend will supply to
-   fast-import within `author`, `committer` and `tagger` commands.
-   See ``Date Formats'' below for details about which formats
-   are supported, and their syntax.
-
--- done::
-   Terminate with error if there is no 'done' command at the
-   end of the stream.
-
---force::
-   Force updating modified existing branches, even if doing
-   so would cause commits to be lost (as the new commit does
-   not contain the old commit).
-
---max-pack-size=n::
-   Maximum size of each output packfile.
-   The default is unlimited.
+--active-branches=n::
+   Maximum number of branches to maintain active at once.
+   See ``Memory Utilization'' below for details.  Default is 5.
 
 --big-file-threshold=n::
Maximum size of a blob that fast-import will attempt to
@@ -58,13 +43,27 @@ OPTIONS
(512 MiB).  Some importers may wish to lower this on systems
with constrained memory.
 
+--cat-blob-fd=fd::
+   Write responses to `cat-blob` and `ls` queries to the
+   file descriptor fd instead of `stdout`.  Allows `progress`
+   output intended for the end-user to be separated from other
+   output.
+
+--date-format=fmt::
+   Specify the type of dates the frontend will supply to
+   fast-import within `author`, `committer` and `tagger` commands.
+   See ``Date Formats'' below for details about which formats
+   are supported, and their syntax.
+
 --depth=n::
Maximum delta depth, for blob and tree deltification.
Default is 10.
 
---active-branches=n::
-   Maximum number of branches to maintain active at once.
-   See ``Memory Utilization'' below for details.  Default is 5.
+--done::
+   Terminate with error if there is no 'done' command at the end
+   of the stream.  This option might be useful for detecting
+   errors that cause the frontend to terminate before it has
+   started to write a stream.
 
 --export-marks=file::
Dumps the internal marks table to file when complete.
@@ -75,6 +74,20 @@ OPTIONS
at checkpoint (or completion) the same path can also be
safely given to \--import-marks.
 
+--export-pack-edges=file::
+   After creating a packfile, print a line of data to
+   file listing the filename of the packfile and the last
+   commit on each branch that was written to that packfile.
+   This information may be useful after importing projects
+   whose total object set exceeds the 4 GiB packfile limit,
+   as these commits can be used as edge points during calls
+   to 'git pack-objects'.
+
+--force::
+   Force updating modified existing branches, even if doing
+   so would cause commits to be lost (as the new commit does
+   not contain the old commit).
+
 --import-marks=file::
Before processing any input, load the marks specified in
file.  The input file must exist, must be readable, and
@@ -87,13 +100,9 @@ OPTIONS
Like --import-marks but instead of erroring out, silently
skips the file if it does not exist.
 
---relative-marks::
-   After specifying --relative-marks the paths specified
-   with --import-marks= and --export-marks= are relative
-   to an internal directory in the current repository.
-   In git-fast-import this means that the paths are relative
-   to the .git/info/fast-import directory. However, other
-   importers may use a different location.
+--max-pack-size=n::
+   Maximum size of each output packfile.
+   The default is unlimited.
 
 --no-relative-marks::
Negates a previous --relative-marks. Allows for combining
@@ -101,32 +110,19 @@ OPTIONS
--(no-)-relative-marks with the --(import|export)-marks=
options.
 
---cat-blob-fd=fd::
-   Write responses to `cat-blob` and `ls` queries to the
-   file descriptor fd instead of `stdout`.  Allows `progress`
-   output intended for the end-user to be separated from other
-   output.
-
---done::
-   Require a `done` command at the end of the stream.
-   This option might be useful for detecting errors that
-   cause the frontend to terminate before it has started to
-   write a stream.
-
---export-pack-edges=file::
-   After creating a packfile, print a line of data to
-   file listing the filename of the packfile and the last
-   commit on each branch that was written to that packfile.
-   This information may be useful after importing projects
-  

Re: [LHF] making t5000 tar xf tests more lenient

2013-01-05 Thread René Scharfe
Am 24.12.2012 21:49, schrieb Junio C Hamano:
 I've been running testsuite on a few platforms that are unfamiliar
 to me, and was bitten by BSD implementation of tar that do not grok
 the extended pax headers.  I've already fixed one in t9502 [*1*]
 where we produce a tarball with git archive and then try to
 validate it with the platform implementation of tar so that the
 test won't barf when it sees the extended pax header.
 
 t5000 is littered with similar tests that break unnecessarily with
 BSD implementations.  I think what it wants to test are:
 
   - archive produces tarball, and tar can extract from it.  If
 your tar does not understand pax header, you may get it as an
 extra file that shouldn't be there, but that should not cause the
 test to fail---in real life, people without a pax-aware tar
 will just ignore and remove the header and can go on.
 
   - get-tar-commmit-id can inspect a tarball produced by archive
 to recover the object name of the commit even on a platform
 without a pax-aware tar.
 
 Perhaps t5000 can be restructured like so:
 
   - create a tarball with the commit-id and test with
 get-tar-commit-id to validate it; also create a tarball out of
 a tree to make sure it does not have commit-id and check with
 get-tar-commit-id.  Do this on any and all platform, even on
 the ones without a pax-aware tar.
 
   - check platform implementation of tar early to see if extracting
 a simple output from git archive results in an extra pax header
 file.  If so, remember this fact and produce any and all tarballs
 used in the remainder of the test by forcing ^{tree}.
 
 so that people on platforms without pax-aware tar do not have to
 install GNU tar only to pass this test.
 
 It would be a good exercise during the holiday week for somebody on
 BSD (it seems NetBSD is more troublesome than OpenBSD) to come up
 with a patch to help users on these platforms.

I got around to building a virtual machine with NetBSD 6.0.1, which
involved a bit of cursing because networking only seems to work when I
turn off ACPI and SMP -- and running tests is a lot more pleasant with
more than one CPU.

Anyway, I don't think the pax headers are to blame here.  The patch below
fixes the tar failures for me, but I'm not sure why.  There must be
something special about some (not all!) directory entries with trailing
slashes after directory names.

Several ZIP tests still fail, however, because NetBSD's unzip doesn't
seem to support (our flavour of) symlinks and streamed files.

I'll take a deeper look into it over the weekend.

René


---
 archive-tar.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/archive-tar.c b/archive-tar.c
index 0ba3f25..fd2d3e8 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -215,6 +215,8 @@ static int write_tar_entry(struct archiver_args *args,
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
*header.typeflag = TYPEFLAG_DIR;
mode = (mode | 0777)  ~tar_umask;
+   if (pathlen  path[pathlen - 1] == '/')
+   pathlen--;
} else if (S_ISLNK(mode)) {
*header.typeflag = TYPEFLAG_LNK;
mode |= 0777;
-- 
1.7.12

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


Re: [PATCH] gitk: Display the date of a tag in a human friendly way.

2013-01-05 Thread Junio C Hamano
Anand Kumria wildf...@progsoc.org writes:

 Sorry, I didn't know that gitk had been split back out (and
 Documentation/gitk.txt still mentions it is part of the git suite).

It is not split back at all, and it won't be.  From git user's
point of view it is part of the suite.

Gitk however is still a viable freestanding project, so it would be
selfish for me to take a patch to gitk-git/gitk directly to my tree,
as the patch will not be able to flow back to the standalone gitk
project. Hence we always let patches go through Paul's tree and then
I pull from him.

--
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 00/10] push: switch default from matching to simple

2013-01-05 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com writes:

 We promised to change the behaviour of lazy git push [there] that
 does not say what to push on the command line from matching to
 simple in Git 2.0.  Even though the top-level RelNotes symbolic
 link points at 1.8.2, we can change our mind to tag 2.0 at the end
 of this cycle.

I had a quick look at the series, it sounds straightforward and correct.
Thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: [LHF] making t5000 tar xf tests more lenient

2013-01-05 Thread Junio C Hamano
René Scharfe rene.scha...@lsrfire.ath.cx writes:

 Anyway, I don't think the pax headers are to blame here.  The patch below
 fixes the tar failures for me, but I'm not sure why.  There must be
 something special about some (not all!) directory entries with trailing
 slashes after directory names.

 Several ZIP tests still fail, however, because NetBSD's unzip doesn't
 seem to support (our flavour of) symlinks and streamed files.

Just FYI, I found that unzip that comes with base distro and the one
you can add via pkg_add (or pkgin) are different, and the latter
seemed to behave better.
--
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] run-command: encode signal death as a positive integer

2013-01-05 Thread Johannes Sixt
Am 05.01.2013 15:49, schrieb Jeff King:
 On Sat, Jan 05, 2013 at 09:03:16AM -0500, Jeff King wrote:
 
 In fact, I really wonder if this code from wait_or_whine is actually
 correct:

   code = WTERMSIG(status);
   /*
* This return value is chosen so that code  0xff
* mimics the exit code that a POSIX shell would report for
* a program that died from this signal.
*/
   code -= 128;
 
 After looking at it some more, it is correct, but I think we could make
 life slightly easier for callers. See the patch below.  I've tried to
 re-state the somewhat rambling argument from my previous email;
 hopefully it makes sense.
 
 -- 8 --
 Subject: [PATCH] run-command: encode signal death as a positive integer
 
 When a sub-command dies due to a signal, we encode the
 signal number into the numeric exit status as signal -
 128. This is easy to identify (versus a regular positive
 error code), and when cast to an unsigned integer (e.g., by
 feeding it to exit), matches what a POSIX shell would return
 when reporting a signal death in $? or through its own exit
 code.
 
 So we have a negative value inside the code, but once it
 passes across an exit() barrier, it looks positive (and any
 code we receive from a sub-shell will have the positive
 form). E.g., death by SIGPIPE (signal 13) will look like
 -115 to us in inside git, but will end up as 141 when we
 call exit() with it. And a program killed by SIGPIPE but run
 via the shell will come to us with an exit code of 141.
 
 Unfortunately, this means that when the use_shell option
 is set, we need to be on the lookout for _both_ forms. We
 might or might not have actually invoked the shell (because
 we optimize out some useless shell calls). If we didn't invoke
 the shell, we will will see the sub-process's signal death
 directly, and run-command converts it into a negative value.
 But if we did invoke the shell, we will see the shell's
 128+signal exit status. To be thorough, we would need to
 check both, or cast the value to an unsigned char (after
 checking that it is not -1, which is a magic error value).
 
 Fortunately, most callsites do not care at all whether the
 exit was from a code or from a signal; they merely check for
 a non-zero status, and sometimes propagate the error via
 exit(). But for the callers that do care, we can make life
 slightly easier by just using the consistent positive form.
 
 This actually fixes two minor bugs:
 
   1. In launch_editor, we check whether the editor died from
  SIGINT or SIGQUIT. But we checked only the negative
  form, meaning that we would fail to notice a signal
  death exit code which was propagated through the shell.
 
   2. In handle_alias, we assume that a negative return value
  from run_command means that errno tells us something
  interesting (like a fork failure, or ENOENT).
  Otherwise, we simply propagate the exit code. Negative
  signal death codes confuse us, and we print a useless
  unable to run alias 'foo': Success message. By
  encoding signal deaths using the positive form, the
  existing code just propagates it as it would a normal
  non-zero exit code.
 
 The downside is that callers of run_command can no longer
 differentiate between a signal received directly by the
 sub-process, and one propagated. However, no caller
 currently cares, and since we already optimize out some
 calls to the shell under the hood, that distinction is not
 something that should be relied upon by callers.

The idea was initially to regard death by signal as an internal error.
But since (1) there are no callers that are really interested in the
difference and (2) we get it wrong in the shell case anyway, this change
makes total sense.

Acked-by: Johannes Sixt j...@kdbg.org

 
 Signed-off-by: Jeff King p...@peff.net
 ---
  Documentation/technical/api-run-command.txt | 6 ++
  editor.c| 2 +-
  run-command.c   | 2 +-
  3 files changed, 4 insertions(+), 6 deletions(-)
 
 diff --git a/Documentation/technical/api-run-command.txt 
 b/Documentation/technical/api-run-command.txt
 index f18b4f4..5d7d7f2 100644
 --- a/Documentation/technical/api-run-command.txt
 +++ b/Documentation/technical/api-run-command.txt
 @@ -55,10 +55,8 @@ The functions above do the following:
non-zero.
  
  . If the program terminated due to a signal, then the return value is the
 -  signal number - 128, ie. it is negative and so indicates an unusual
 -  condition; a diagnostic is printed. This return value can be passed to
 -  exit(2), which will report the same code to the parent process that a
 -  POSIX shell's $? would report for a program that died from the signal.
 +  signal number + 128, ie. the same value that a POSIX shell's $? would
 +  report.  A diagnostic is printed.
  
  
  `start_async`::
 diff --git a/editor.c b/editor.c
 index 065a7ab..27bdecd 100644
 --- a/editor.c
 +++ b/editor.c
 @@ -51,7 +51,7 @@ int 

Re: [LHF] making t5000 tar xf tests more lenient

2013-01-05 Thread Junio C Hamano
René Scharfe rene.scha...@lsrfire.ath.cx writes:

 Anyway, I don't think the pax headers are to blame here.

Hmph, I am reasonably sure I saw a test that created an archive from
a commit (hence with pax header), asked platform tar to either list
the contents or actually extracted to the filesystem, and tried to
ensure nothing but the paths in the repository existed in the
archive.  When the platform tar implementation treated the pax
header as an extra file, such a test sees something not in the
repository and fails.

This was on (and I am still on) NetBSD 6.0 not 6.0.1, by the way.
--
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] clone: support atomic operation with --separate-git-dir

2013-01-05 Thread Jens Lehmann
Since b57fb80a7d (init, clone: support --separate-git-dir for .git file)
git clone supports the --separate-git-dir option to create the git dir
outside the work tree. But when that option is used, the git dir won't be
deleted in case the clone fails like it would be without this option. This
makes clone lose its atomicity as in case of a failure a partly set up git
dir is left behind. A real world example where this leads to problems is
when git submodule update fails to clone a submodule and later calls to
git submodule update stumble over the partially set up git dir and try
to revive the submodule from there, which then fails with a not very user
friendly error message.

Fix that by updating the junk_git_dir variable (used to remember if and
what git dir should be removed in case of failure) to the new value given
with the --seperate-git-dir option. Also add a test for this to t5600 (and
while at it fix the former last test to not cd into a directory to test
for its existence but use test -d instead).

Reported-by: Manlio Perillo manlio.peri...@gmail.com
Signed-off-by: Jens Lehmann jens.lehm...@web.de
---


Am 05.01.2013 15:50, schrieb Jens Lehmann:
 Am 05.01.2013 15:01, schrieb Jens Lehmann:
 The reason seems to be that clone leaves a partial initialized .git
 directory in case of connection problems. The next time submodule
 update runs it tries to revive the submodule from .git/modules/name
 but fails as there are no objects in it.

 This looks like a bug in clone to me, as it takes precautions to clean
 up if something goes wrong but doesn't do that in this case. But while
 glancing over the code I didn't find out what goes wrong here.
 
 I dug a bit deeper here and found the reason: In remove_junk() of
 builtin/clone.c the junk_git_dir points to the gitfile in the
 submodules work tree, not the .git/modules/name directory where
 clone was told to put the git directory. Will see if I can come up
 with a patch soonish ...

And this fixes it for me. Manlio, it'd be great if you could test
this patch (but please not only remove .git/modules/name but also
the submodule work tree before doing that).


 builtin/clone.c   |  4 +++-
 t/t5600-clone-fail-cleanup.sh | 12 +++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/builtin/clone.c b/builtin/clone.c
index ec2f75b..8d23a62 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -771,8 +771,10 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
die(_(could not create leading directories of '%s'), git_dir);

set_git_dir_init(git_dir, real_git_dir, 0);
-   if (real_git_dir)
+   if (real_git_dir) {
git_dir = real_git_dir;
+   junk_git_dir = real_git_dir;
+   }

if (0 = option_verbosity) {
if (option_bare)
diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
index ee06d28..4435693 100755
--- a/t/t5600-clone-fail-cleanup.sh
+++ b/t/t5600-clone-fail-cleanup.sh
@@ -37,6 +37,16 @@ test_expect_success \

 test_expect_success \
 'successful clone must leave the directory' \
-'cd bar'
+'test -d bar'
+
+test_expect_success 'failed clone --separate-git-dir should not leave any 
directories' '
+   mkdir foo/.git/objects.bak/ 
+   mv foo/.git/objects/* foo/.git/objects.bak/ 
+   test_must_fail git clone --separate-git-dir gitdir foo worktree 
+   test_must_fail test -e gitdir 
+   test_must_fail test -e worktree 
+   mv foo/.git/objects.bak/* foo/.git/objects/ 
+   rmdir foo/.git/objects.bak
+'

 test_done
-- 
1.8.1.81.gb1e9864

--
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 v4] git-completion.bash: add support for path completion

2013-01-05 Thread Marc Khouzam

 Junio C Hamano gits...@pobox.com writes:
 
  Marc Khouzam marc.khou...@ericsson.com writes:

 I've been playing with it but I'm not getting the expected
 behavior when I cd to a sub-directory.

 Thanks for testing.  Manlio?
 
 Can you try the attached patch?

Thanks for this, it improves the situation dramatically.
I did further testing with your patch and found some less obvious
issues.  I didn't debug the script myself as I'm not that familiar with
it either, but I think the testcases below should help Manlio or
someone else look into some regressions.

1- Using .. or . breaks completion when after the '/':
 cd git/contrib
 git rm ../contrib/completion/tab
../contrib/completion/ion.bash  ../contrib/completion/ion.tcsh  
../contrib/completion/ion.zsh   ../contrib/completion/sh
It looks like the space taken by the path where we are located, eats up the 
same number of characters from the file name, e.g.,
   ../contrib/completion/ion.bash
   ../contrib/git-completion.bash

2- Maybe related to problem 1.  Using .. breaks completion in other ways:
 cd git/contrib
 git rm ../contab
../config.c   ../config.mak.in  ../configure.ac   ../connect.c  
../connected.c../connected.h../convert.c  ../convert.h
Notice that 'contrib' is not proposed.
Don't be fooled by the fact that
 git rm ../conttab
will complete to 
 git rm ../contrib
as it is only because the completion script returned nothing, and bash 
file-completion 
kicked-in instead (it fooled me :)).

3- Also probably related to problems 1 and 2.  Using absolute paths behaves 
wierdly and 
worse than before:
git rm /home/marc/git/git/contab
will give
git rm /home/marc/git/git/config-
although there is the 'contrib' dir that should be shown, amongst others.
Seems like the same problem as above with 'git rm ../contab'

In my opinion, the above three cases are regressions.

4- Completion choices include their entire path, which is not what bash does by 
default.  For example:
 cd git/contrib
 ls completion/git-tab
git-completion.bash  git-completion.tcsh  git-completion.zsh   git-prompt.sh
but
 git rm completion/git-tab
completion/git-completion.bash  completion/git-completion.tcsh  
completion/git-completion.zsh   completion/git-prompt.sh
notice the extra 'completion/' before each completion.  This can get pretty 
large when completing with 
many directory prefixes.  The current tcsh completion has the same problem 
which I couldn't fix.  However, I am 
not sure if it can be fixed for bash.

I personally don't think this is regression, just an slight annoyance.

5- With this feature git-completion.bash will return directories as 
completions.  This is something
git-completion.tcsh is not handling very well.  I will post a patch to fix that.

Below are two suggestions that are in line with this effort but that are not 
regressions.

A) It would be nice if 
git commit -a TAB
also completed with untracked files

B) Now that, for example, 'git rm' completion is smart about path completion 
it would be nice to somehow not trigger bash default file completion
when 'git rm' does not report any completions.  

For example, if I have a file called zz.tar.gz (which is an ignored file) 
and I do 'git rm tab', I will get the proper list of files that can be
removed by git, excluding zz.tar.gz.  But if I complete
'git rm zz.tar.tab' then the completion script will return nothing,
since git cannot remove that ignored file, but we will then fall-back
to the bash default completion, which will complete the file to zz.tar.gz.

Although there are some issues, I think this feature will greatly benefit the 
user
and is worth the time needed to fix.

Thanks!

Marc
--
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] status: report ignored yet tracked directories

2013-01-05 Thread Antoine Pelisse
Tracked directories (i.e. directories containing tracked files) that
are ignored must be reported as ignored if they contain untracked files.

Currently, tracked files or directories can't be reported untracked or ignored.
Remove that constraint when searching ignored files.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Torsten, Jeff,

Can you please test this patch and tell me if this is better ? (t7061 is now
successful with core.ignorecase=true)

This patch applies on top of ap/status-ignored-in-ignored-directory (but
 should also apply cleanly on top of next for testing purpose).

Thanks,

 dir.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dir.c b/dir.c
index 9b80348..eefa8ab 100644
--- a/dir.c
+++ b/dir.c
@@ -672,7 +672,8 @@ static struct dir_entry *dir_entry_new(const char 
*pathname, int len)

 static struct dir_entry *dir_add_name(struct dir_struct *dir, const char 
*pathname, int len)
 {
-   if (cache_name_exists(pathname, len, ignore_case))
+   if (!(dir-flags  DIR_SHOW_IGNORED) 
+   cache_name_exists(pathname, len, ignore_case))
return NULL;

ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
--
1.7.12.4.2.geb8c5b8.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


[Feature request] make git buildable from a separate directory

2013-01-05 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

Many C projects I have seen (based on autoconf, but not always - like
Nginx) allow the project to be build in a separate directory, in order
to avoid to pollute the working directory with compiled files.

Unfortunately this seems to not be possible with Git.
The Makefile seems quite complex to me, so I'm not sure to be able to
change it to do what I want, without breaking it.


Thanks  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDoknUACgkQscQJ24LbaUTw/QCdHbphkU3Mepo98D07yLaj3YyF
5I4Anii94QDHsC1zm2Jp1hy2X/JFa/NE
=vV1z
-END PGP SIGNATURE-
--
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] clone: support atomic operation with --separate-git-dir

2013-01-05 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 21:17, Jens Lehmann ha scritto:
 Since b57fb80a7d (init, clone: support --separate-git-dir for .git file)
 git clone supports the --separate-git-dir option to create the git dir
 outside the work tree. But when that option is used, the git dir won't be
 deleted in case the clone fails like it would be without this option. This
 makes clone lose its atomicity as in case of a failure a partly set up git
 dir is left behind. A real world example where this leads to problems is
 when git submodule update fails to clone a submodule and later calls to
 git submodule update stumble over the partially set up git dir and try
 to revive the submodule from there, which then fails with a not very user
 friendly error message.
 
 Fix that by updating the junk_git_dir variable (used to remember if and
 what git dir should be removed in case of failure) to the new value given
 with the --seperate-git-dir option. Also add a test for this to t5600 (and
 while at it fix the former last test to not cd into a directory to test
 for its existence but use test -d instead).
 
 Reported-by: Manlio Perillo manlio.peri...@gmail.com
 Signed-off-by: Jens Lehmann jens.lehm...@web.de
 ---
 [...]
 And this fixes it for me. Manlio, it'd be great if you could test
 this patch (but please not only remove .git/modules/name but also
 the submodule work tree before doing that).
 

I can confirm that the patch solves the problem I reported.


Thanks   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDomR4ACgkQscQJ24LbaUQszACfV42L9Xcy+mme6RY/vY+K2H4T
QDAAoIIupUSjwv6qUgzUMQV1aNplrWJD
=uN3W
-END PGP SIGNATURE-
--
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: Suggested improvements to the git-p4 documentation (branch-related)

2013-01-05 Thread Pete Wyckoff
sh...@keba.be wrote on Thu, 03 Jan 2013 15:58 -0500:
 While struggling to get git-p4 to work properly with branches, I
 thought the documentation on http://git-scm.com/docs/git-p4 could use
 some improvements:

Thanks, I definitely appreciate the constructive comments here.

 1. At the end of the Branch detection section, the following
 commands are provided (for when you want to explicitly provide branch
 mappings to git-p4):
 
 git config git-p4.branchList main:branch1
 git p4 clone --detect-branches //depot@all
 
 The second command should end with a dot (.) because the first
 command only works if you are already in a git-initialized folder.
 Thus I would also suggest to add git init as first command to type.

That is confusing.  I'll make it this:

git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all .

 2. Even though having a main branch is standard in Perforce, it
 would be worth mentioning what happens when you don't: there is a
 message Could not detect main branch. No checkout/master branch
 created output by the git p4 clone command. However, it will still
 work if you manually set the master branch (git checkout -b master
 remotes/p4/my_custom_main_branch).

This feels like a bug to me, and indeed I had an old patch series
that planned to fix it.  Let me knock that into shape, instead of
changing the documentation.  It will automatically do the
checkout step you did.

 3. I don't know what I missed for that one, but I haven't been able to
 get the example for the --branch option to work. It says that after
 git init, we can import a p4 branch with:
 
 git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
 
 However, after doing this, followed by git checkout -b proj2
 remotes/p4/proj2, I am unable to properly use git p4 sync or git
 p4 submit from this branch, as git complains about a missing
 refs/remotes/p4/master.

Yes, also annoying.  I have a failing test case for this, but
haven't fixed it yet.  The idea is that git p4 sync --branch=proj2
will sync refs/remotes/p4/proj2.  If there is no p4/master, and
you don't specify --branch, it will fail with a more useful error
message.

For submit, there is code that walks from your current branch
back in history until it finds a commit on a known p4 remote
branch.  This is sort of like the merge-base calculation in git,
but restricted to a linear history.  I haven't tested that
recently, but will add a test and fix it if needed too.


Please do feel welcome to to rearrange or expand the
documentation so it makes more sense, if you are so inspired.

-- Pete
--
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 00/10] Log mailmap optimization

2013-01-05 Thread Antoine Pelisse
Hi,

Here is a reroll of ap/log-mailmap.
The idea is to use another preparatory step:
Allow case-insensitive and length search in list_lookup

We can now search for mapping name and email without any copy.
Of course a copy is then necessary to store the info, but we no
longer need any copy to look-up the mapping (useful for replacing or not
before grep).

Thanks,

Antoine Pelisse (10):
  list_lookup: create case and length search
  Use split_ident_line to parse author and committer
  mailmap: remove email copy and length limitation
  mailmap: simplify map_user() interface
  mailmap: add mailmap structure to rev_info and pp
  pretty: use mailmap to display username and email
  log: add --use-mailmap option
  test: add test for --use-mailmap option
  log: grep author/committer using mailmap
  log: add log.mailmap configuration option

 Documentation/config.txt  |   4 +
 Documentation/git-log.txt |   5 ++
 builtin/blame.c   | 183 ++
 builtin/log.c |  16 +++-
 builtin/shortlog.c|  54 --
 commit.h  |   1 +
 log-tree.c|   1 +
 mailmap.c |  55 +-
 mailmap.h |   4 +-
 pretty.c  | 114 -
 revision.c|  54 ++
 revision.h|   1 +
 string-list.c |  30 ++--
 string-list.h |   2 +
 t/t4203-mailmap.sh|  56 ++
 15 files changed, 349 insertions(+), 231 deletions(-)

--
1.7.12.4.3.g2036a08.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 01/10] list_lookup: create case and length search

2013-01-05 Thread Antoine Pelisse
Create a new function to look-up a string in a string_list, but:
 - add a new parameter to ignore case differences
 - add a length parameter to search for a substring

The idea is to avoid several copies (lowering a string before searching
it when we just want to ignore case), or copying a substring of a bigger
string to search it in the string_list

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 string-list.c | 30 --
 string-list.h |  2 ++
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/string-list.c b/string-list.c
index 397e6cf..f06e110 100644
--- a/string-list.c
+++ b/string-list.c
@@ -4,13 +4,21 @@
 /* if there is no exact match, point to the index where the entry could be
  * inserted */
 static int get_entry_index(const struct string_list *list, const char *string,
-   int *exact_match)
+   int *exact_match, int case_sensitive, size_t n)
 {
int left = -1, right = list-nr;
 
while (left + 1  right) {
+   int compare;
int middle = (left + right) / 2;
-   int compare = strcmp(string, list-items[middle].string);
+   if (case_sensitive)
+   compare = strncmp(string, list-items[middle].string, 
n);
+   else
+   compare = strncasecmp(string, 
list-items[middle].string, n);
+   /* Make sure our string is not a substring of item string */
+   if (!compare  n != -1)
+   if (list-items[middle].string[n] != '\0')
+   compare = -1;
if (compare  0)
right = middle;
else if (compare  0)
@@ -29,7 +37,7 @@ static int get_entry_index(const struct string_list *list, 
const char *string,
 static int add_entry(int insert_at, struct string_list *list, const char 
*string)
 {
int exact_match = 0;
-   int index = insert_at != -1 ? insert_at : get_entry_index(list, string, 
exact_match);
+   int index = insert_at != -1 ? insert_at : get_entry_index(list, string, 
exact_match, 1, -1);
 
if (exact_match)
return -1 - index;
@@ -70,7 +78,7 @@ struct string_list_item *string_list_insert_at_index(struct 
string_list *list,
 int string_list_has_string(const struct string_list *list, const char *string)
 {
int exact_match;
-   get_entry_index(list, string, exact_match);
+   get_entry_index(list, string, exact_match, 1, -1);
return exact_match;
 }
 
@@ -78,7 +86,7 @@ int string_list_find_insert_index(const struct string_list 
*list, const char *st
  int negative_existing_index)
 {
int exact_match;
-   int index = get_entry_index(list, string, exact_match);
+   int index = get_entry_index(list, string, exact_match, 1, -1);
if (exact_match)
index = -1 - (negative_existing_index ? index : 0);
return index;
@@ -86,7 +94,17 @@ int string_list_find_insert_index(const struct string_list 
*list, const char *st
 
 struct string_list_item *string_list_lookup(struct string_list *list, const 
char *string)
 {
-   int exact_match, i = get_entry_index(list, string, exact_match);
+   int exact_match, i = get_entry_index(list, string, exact_match, 1, -1);
+   if (!exact_match)
+   return NULL;
+   return list-items + i;
+}
+
+struct string_list_item *string_list_lookup_extended(struct string_list *list,
+const char *string, int case_sensitive, size_t n)
+{
+   int exact_match, i = get_entry_index(list, string, exact_match,
+case_sensitive, n);
if (!exact_match)
return NULL;
return list-items + i;
diff --git a/string-list.h b/string-list.h
index c50b0d0..4f5ae19 100644
--- a/string-list.h
+++ b/string-list.h
@@ -62,6 +62,8 @@ struct string_list_item *string_list_insert(struct 
string_list *list, const char
 struct string_list_item *string_list_insert_at_index(struct string_list *list,
 int insert_at, const char 
*string);
 struct string_list_item *string_list_lookup(struct string_list *list, const 
char *string);
+struct string_list_item *string_list_lookup_extended(struct string_list *list,
+const char *string, int case_sensitive, size_t n);
 
 /*
  * Remove all but the first of consecutive entries with the same
-- 
1.7.12.4.3.g2036a08.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 02/10] Use split_ident_line to parse author and committer

2013-01-05 Thread Antoine Pelisse
Currently blame.c::get_acline, pretty.c::pp_user_info() and
shortlog.c::insert_one_record are parsing author name, email, time and
tz themselves.

Use ident.c::split_ident_line for better code reuse.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 builtin/blame.c| 59 +++---
 builtin/shortlog.c | 36 +
 pretty.c   | 35 +++-
 3 files changed, 52 insertions(+), 78 deletions(-)

diff --git a/builtin/blame.c b/builtin/blame.c
index cfae569..dd4aff9 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1343,8 +1343,9 @@ static void get_ac_line(const char *inbuf, const char 
*what,
int mail_len, char *mail,
unsigned long *time, const char **tz)
 {
-   int len, tzlen, maillen;
-   char *tmp, *endp, *timepos, *mailpos;
+   struct ident_split ident;
+   int len, tzlen, maillen, namelen;
+   char *tmp, *endp, *mailpos;
 
tmp = strstr(inbuf, what);
if (!tmp)
@@ -1355,7 +1356,10 @@ static void get_ac_line(const char *inbuf, const char 
*what,
len = strlen(tmp);
else
len = endp - tmp;
-   if (person_len = len) {
+   if (person_len = len)
+   goto error_out;
+
+   if (split_ident_line(ident, tmp, len)) {
error_out:
/* Ugh */
*tz = (unknown);
@@ -1364,47 +1368,26 @@ static void get_ac_line(const char *inbuf, const char 
*what,
*time = 0;
return;
}
-   memcpy(person, tmp, len);
 
-   tmp = person;
-   tmp += len;
-   *tmp = 0;
-   while (person  tmp  *tmp != ' ')
-   tmp--;
-   if (tmp = person)
-   goto error_out;
-   *tz = tmp+1;
-   tzlen = (person+len)-(tmp+1);
+   namelen = ident.name_end - ident.name_begin;
+   memcpy(person, ident.name_begin, namelen);
+   person[namelen] = 0;
 
-   *tmp = 0;
-   while (person  tmp  *tmp != ' ')
-   tmp--;
-   if (tmp = person)
-   goto error_out;
-   *time = strtoul(tmp, NULL, 10);
-   timepos = tmp;
+   maillen = ident.mail_end - ident.mail_begin + 2;
+   memcpy(mail, ident.mail_begin - 1, maillen);
+   mail[maillen] = 0;
 
-   *tmp = 0;
-   while (person  tmp  !(*tmp == ' '  tmp[1] == ''))
-   tmp--;
-   if (tmp = person)
-   return;
-   mailpos = tmp + 1;
-   *tmp = 0;
-   maillen = timepos - tmp;
-   memcpy(mail, mailpos, maillen);
+   *time = strtoul(ident.date_begin, NULL, 10);
 
-   if (!mailmap.nr)
-   return;
+   tzlen = ident.tz_end - ident.tz_begin;
 
-   /*
-* mailmap expansion may make the name longer.
-* make room by pushing stuff down.
-*/
-   tmp = person + person_len - (tzlen + 1);
-   memmove(tmp, *tz, tzlen);
+   /* Place tz at the end of person */
+   *tz = tmp = person + person_len - (tzlen + 1);
+   memcpy(tmp, ident.tz_begin, tzlen);
tmp[tzlen] = 0;
-   *tz = tmp;
+
+   if (!mailmap.nr)
+   return;
 
/*
 * Now, convert both name and e-mail using mailmap
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index b316cf3..03c6cd7 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -40,40 +40,24 @@ static void insert_one_record(struct shortlog *log,
char emailbuf[1024];
size_t len;
const char *eol;
-   const char *boemail, *eoemail;
struct strbuf subject = STRBUF_INIT;
+   struct ident_split ident;
 
-   boemail = strchr(author, '');
-   if (!boemail)
-   return;
-   eoemail = strchr(boemail, '');
-   if (!eoemail)
+   if (split_ident_line(ident, author, strlen(author)))
return;
 
/* copy author name to namebuf, to support matching on both name and 
email */
-   memcpy(namebuf, author, boemail - author);
-   len = boemail - author;
-   while (len  0  isspace(namebuf[len-1]))
-   len--;
+   len = ident.name_end - ident.name_begin;
+   memcpy(namebuf, ident.name_begin, len);
namebuf[len] = 0;
 
/* copy email name to emailbuf, to allow email replacement as well */
-   memcpy(emailbuf, boemail+1, eoemail - boemail);
-   emailbuf[eoemail - boemail - 1] = 0;
-
-   if (!map_user(log-mailmap, emailbuf, sizeof(emailbuf), namebuf, 
sizeof(namebuf))) {
-   while (author  boemail  isspace(*author))
-   author++;
-   for (len = 0;
-len  sizeof(namebuf) - 1  author + len  boemail;
-len++)
-   namebuf[len] = author[len];
-   while (0  len  isspace(namebuf[len-1]))
-   len--;
-   namebuf[len] = '\0';
-   }
-   else
-

[PATCH 05/10] mailmap: add mailmap structure to rev_info and pp

2013-01-05 Thread Antoine Pelisse
the mailmap string_list structure filled with mailmap
information is passed along from rev_info to pretty_print_context
to provide mailmap information to pretty print each commits
with the correct username and email.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 commit.h   | 1 +
 log-tree.c | 1 +
 revision.h | 1 +
 3 files changed, 3 insertions(+)

diff --git a/commit.h b/commit.h
index b6ad8f3..7f8f987 100644
--- a/commit.h
+++ b/commit.h
@@ -89,6 +89,7 @@ struct pretty_print_context {
char *notes_message;
struct reflog_walk_info *reflog_info;
const char *output_encoding;
+   struct string_list *mailmap;
 };
 
 struct userformat_want {
diff --git a/log-tree.c b/log-tree.c
index 4f86def..92254fd 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -671,6 +671,7 @@ void show_log(struct rev_info *opt)
ctx.preserve_subject = opt-preserve_subject;
ctx.reflog_info = opt-reflog_info;
ctx.fmt = opt-commit_format;
+   ctx.mailmap = opt-mailmap;
pretty_print_commit(ctx, commit, msgbuf);
 
if (opt-add_signoff)
diff --git a/revision.h b/revision.h
index 059bfff..83a79f5 100644
--- a/revision.h
+++ b/revision.h
@@ -143,6 +143,7 @@ struct rev_info {
const char  *subject_prefix;
int no_inline;
int show_log_size;
+   struct string_list *mailmap;
 
/* Filter by commit log message */
struct grep_opt grep_filter;
-- 
1.7.12.4.3.g2036a08.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 08/10] test: add test for --use-mailmap option

2013-01-05 Thread Antoine Pelisse
The new option '--use-mailmap' can be used to make
sure that mailmap file is used to convert name
when running log commands.

The test is simple and checks that the Author line
is correctly replaced when running log.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 t/t4203-mailmap.sh | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 1f182f6..db043dc 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -239,6 +239,20 @@ test_expect_success 'Log output (complex mapping)' '
test_cmp expect actual
 '
 
+cat expect \EOF
+Author: CTO c...@company.xx
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Other Author ot...@author.xx
+Author: Other Author ot...@author.xx
+Author: Some Dude s...@dude.xx
+Author: A U Thor aut...@example.com
+EOF
+test_expect_success 'Log output with --use-mailmap' '
+   git log --use-mailmap | grep Author actual 
+   test_cmp expect actual
+'
+
 # git blame
 cat expect \EOF
 ^OBJI (A U Thor DATE 1) one
-- 
1.7.12.4.3.g2036a08.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 04/10] mailmap: simplify map_user() interface

2013-01-05 Thread Antoine Pelisse
The new string_list_lookup_extended() allows us to simplify map_user(),
mostly to avoid copies of string buffers. It also simplifies caller
functions.

map_user() directly receive pointers and length from the commit buffer
as mail and name. If mapping of the user and mail can be done, the
pointer is updated to a new location. Lengths are also updated if
necessary.

The caller of map_user() can then copy the new email and name if
necessary.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 builtin/blame.c| 156 +++--
 builtin/shortlog.c |  32 +--
 mailmap.c  |  43 +++
 mailmap.h  |   4 +-
 pretty.c   |  35 +---
 5 files changed, 126 insertions(+), 144 deletions(-)

diff --git a/builtin/blame.c b/builtin/blame.c
index dd4aff9..86450e3 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1321,31 +1321,31 @@ static void pass_blame(struct scoreboard *sb, struct 
origin *origin, int opt)
  * Information on commits, used for output.
  */
 struct commit_info {
-   const char *author;
-   const char *author_mail;
+   struct strbuf author;
+   struct strbuf author_mail;
unsigned long author_time;
-   const char *author_tz;
+   struct strbuf author_tz;
 
/* filled only when asked for details */
-   const char *committer;
-   const char *committer_mail;
+   struct strbuf committer;
+   struct strbuf committer_mail;
unsigned long committer_time;
-   const char *committer_tz;
+   struct strbuf committer_tz;
 
-   const char *summary;
+   struct strbuf summary;
 };
 
 /*
  * Parse author/committer line in the commit object buffer
  */
 static void get_ac_line(const char *inbuf, const char *what,
-   int person_len, char *person,
-   int mail_len, char *mail,
-   unsigned long *time, const char **tz)
+   struct strbuf *name, struct strbuf *mail,
+   unsigned long *time, struct strbuf *tz)
 {
struct ident_split ident;
-   int len, tzlen, maillen, namelen;
-   char *tmp, *endp, *mailpos;
+   size_t len, maillen, namelen;
+   char *tmp, *endp;
+   const char *tmpname, *tmpmail;
 
tmp = strstr(inbuf, what);
if (!tmp)
@@ -1356,51 +1356,61 @@ static void get_ac_line(const char *inbuf, const char 
*what,
len = strlen(tmp);
else
len = endp - tmp;
-   if (person_len = len)
-   goto error_out;
 
if (split_ident_line(ident, tmp, len)) {
error_out:
/* Ugh */
-   *tz = (unknown);
-   strcpy(person, *tz);
-   strcpy(mail, *tz);
+   tmp = (unknown);
+   strbuf_addstr(name, tmp);
+   strbuf_addstr(mail, tmp);
+   strbuf_addstr(tz, tmp);
*time = 0;
return;
}
 
namelen = ident.name_end - ident.name_begin;
-   memcpy(person, ident.name_begin, namelen);
-   person[namelen] = 0;
+   tmpname = ident.name_begin;
 
-   maillen = ident.mail_end - ident.mail_begin + 2;
-   memcpy(mail, ident.mail_begin - 1, maillen);
-   mail[maillen] = 0;
+   maillen = ident.mail_end - ident.mail_begin;
+   tmpmail = ident.mail_begin;
 
*time = strtoul(ident.date_begin, NULL, 10);
 
-   tzlen = ident.tz_end - ident.tz_begin;
-
-   /* Place tz at the end of person */
-   *tz = tmp = person + person_len - (tzlen + 1);
-   memcpy(tmp, ident.tz_begin, tzlen);
-   tmp[tzlen] = 0;
-
-   if (!mailmap.nr)
-   return;
+   len = ident.tz_end - ident.tz_begin;
+   strbuf_add(tz, ident.tz_begin, len);
 
/*
 * Now, convert both name and e-mail using mailmap
 */
-   if (map_user(mailmap, mail+1, mail_len-1, person, tmp-person-1)) {
-   /* Add a trailing '' to email, since map_user returns plain 
emails
-  Note: It already has '', since we replace from mail+1 */
-   mailpos = memchr(mail, '\0', mail_len);
-   if (mailpos  mailpos-mail  mail_len - 1) {
-   *mailpos = '';
-   *(mailpos+1) = '\0';
-   }
-   }
+   map_user(mailmap, tmpmail, maillen,
+tmpname, namelen);
+
+   strbuf_addf(mail, %.*s, (int)maillen, tmpmail);
+   strbuf_add(name, tmpname, namelen);
+}
+
+static void commit_info_init(struct commit_info *ci)
+{
+
+   strbuf_init(ci-author, 0);
+   strbuf_init(ci-author_mail, 0);
+   strbuf_init(ci-author_tz, 0);
+   strbuf_init(ci-committer, 0);
+   strbuf_init(ci-committer_mail, 0);
+   strbuf_init(ci-committer_tz, 0);
+   strbuf_init(ci-summary, 0);
+}
+
+static void commit_info_destroy(struct commit_info *ci)
+{
+
+   strbuf_release(ci-author);
+   

[PATCH 10/10] log: add log.mailmap configuration option

2013-01-05 Thread Antoine Pelisse
Teach log.mailmap configuration variable to turn --use-mailmap
option on to git log, git show and git whatchanged.

The --no-use-mailmap option from the command line can countermand
the setting.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 Documentation/config.txt |  4 
 builtin/log.c|  7 +++
 t/t4203-mailmap.sh   | 24 
 3 files changed, 35 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..226362a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1509,6 +1509,10 @@ log.showroot::
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
 
+log.mailmap::
+   If true, makes linkgit:git-log[1], linkgit:git-show[1], and
+   linkgit:git-whatchanged[1] assume `--use-mailmap`.
+
 mailmap.file::
The location of an augmenting mailmap file. The default
mailmap, located in the root of the repository, is loaded
diff --git a/builtin/log.c b/builtin/log.c
index d2bd8ce..16e6520 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static int default_abbrev_commit;
 static int default_show_root = 1;
 static int decoration_style;
 static int decoration_given;
+static int use_mailmap_config;
 static const char *fmt_patch_subject_prefix = PATCH;
 static const char *fmt_pretty;
 
@@ -106,6 +107,7 @@ static void cmd_log_init_finish(int argc, const char 
**argv, const char *prefix,
OPT_END()
};
 
+   mailmap = use_mailmap_config;
argc = parse_options(argc, argv, prefix,
 builtin_log_options, builtin_log_usage,
 PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN |
@@ -358,6 +360,11 @@ static int git_log_config(const char *var, const char 
*value, void *cb)
}
if (!prefixcmp(var, color.decorate.))
return parse_decorate_color_config(var, 15, value);
+   if (!strcmp(var, log.mailmap)) {
+   use_mailmap_config = git_config_bool(var, value);
+   return 0;
+   }
+
if (grep_config(var, value, cb)  0)
return -1;
return git_diff_ui_config(var, value, cb);
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index e16187f..7d4d31c 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -255,6 +255,21 @@ test_expect_success 'Log output with --use-mailmap' '
 '
 
 cat expect \EOF
+Author: CTO c...@company.xx
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Other Author ot...@author.xx
+Author: Other Author ot...@author.xx
+Author: Some Dude s...@dude.xx
+Author: A U Thor aut...@example.com
+EOF
+
+test_expect_success 'Log output with log.mailmap' '
+   git -c log.mailmap=True log | grep Author actual 
+   test_cmp expect actual
+'
+
+cat expect \EOF
 Author: Santa Claus santa.cl...@northpole.xx
 Author: Santa Claus santa.cl...@northpole.xx
 EOF
@@ -263,6 +278,15 @@ test_expect_success 'Grep author with --use-mailmap' '
git log --use-mailmap --author Santa | grep Author actual 
test_cmp expect actual
 '
+cat expect \EOF
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Santa Claus santa.cl...@northpole.xx
+EOF
+
+test_expect_success 'Grep author with log.mailmap' '
+   git -c log.mailmap=True log --author Santa | grep Author actual 
+   test_cmp expect actual
+'
 
 expect
 
-- 
1.7.12.4.3.g2036a08.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 03/10] mailmap: remove email copy and length limitation

2013-01-05 Thread Antoine Pelisse
In map_user(), the new string_list_lookup_extended() allows us to remove
the copy of email buffer to lower it.
This also removes the limitation on the length of the copy buffer and
simplifies the function.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 mailmap.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/mailmap.c b/mailmap.c
index ea4b471..9db8a1b 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -193,8 +193,7 @@ int map_user(struct string_list *map,
char *end_of_email;
struct string_list_item *item;
struct mailmap_entry *me;
-   char buf[1024], *mailbuf;
-   int i;
+   size_t maillen;
 
/* figure out space requirement for email */
end_of_email = strchr(email, '');
@@ -204,18 +203,11 @@ int map_user(struct string_list *map,
if (!end_of_email)
return 0;
}
-   if (end_of_email - email + 1  sizeof(buf))
-   mailbuf = buf;
-   else
-   mailbuf = xmalloc(end_of_email - email + 1);
-
-   /* downcase the email address */
-   for (i = 0; i  end_of_email - email; i++)
-   mailbuf[i] = tolower(email[i]);
-   mailbuf[i] = 0;
-
-   debug_mm(map_user: map '%s' %s\n, name, mailbuf);
-   item = string_list_lookup(map, mailbuf);
+
+   maillen = end_of_email - email;
+
+   debug_mm(map_user: map '%s' %.*s\n, name, maillen, email);
+   item = string_list_lookup_extended(map, email, 0, maillen);
if (item != NULL) {
me = (struct mailmap_entry *)item-util;
if (me-namemap.nr) {
@@ -226,8 +218,6 @@ int map_user(struct string_list *map,
item = subitem;
}
}
-   if (mailbuf != buf)
-   free(mailbuf);
if (item != NULL) {
struct mailmap_info *mi = (struct mailmap_info *)item-util;
if (mi-name == NULL  (mi-email == NULL || maxlen_email == 
0)) {
-- 
1.7.12.4.3.g2036a08.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 09/10] log: grep author/committer using mailmap

2013-01-05 Thread Antoine Pelisse
Currently you can use mailmap to display log authors and committers
but you can't use the mailmap to find commits with mapped values.

This commit allows you to run:

git log --use-mailmap --author mapped_name_or_email
git log --use-mailmap --committer mapped_name_or_email

Of course it only works if the --use-mailmap option is used.

The new name and email are copied only when necessary.

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

diff --git a/revision.c b/revision.c
index 95d21e6..2cce85a 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
 #include decorate.h
 #include log-tree.h
 #include string-list.h
+#include mailmap.h
 
 volatile show_early_output_fn_t show_early_output;
 
@@ -2219,6 +2220,51 @@ static int rewrite_parents(struct rev_info *revs, struct 
commit *commit)
return 0;
 }
 
+static int commit_rewrite_person(struct strbuf *buf, const char *what, struct 
string_list *mailmap)
+{
+   char *person, *endp;
+   size_t len, namelen, maillen;
+   const char *name;
+   const char *mail;
+   struct ident_split ident;
+
+   person = strstr(buf-buf, what);
+   if (!person)
+   return 0;
+
+   person += strlen(what);
+   endp = strchr(person, '\n');
+   if (!endp)
+   return 0;
+
+   len = endp - person;
+
+   if (split_ident_line(ident, person, len))
+   return 0;
+
+   mail = ident.mail_begin;
+   maillen = ident.mail_end - ident.mail_begin;
+   name = ident.name_begin;
+   namelen = ident.name_end - ident.name_begin;
+
+   if (map_user(mailmap, mail, maillen, name, namelen)) {
+   struct strbuf namemail = STRBUF_INIT;
+
+   strbuf_addf(namemail, %.*s %.*s,
+   (int)namelen, name, (int)maillen, mail);
+
+   strbuf_splice(buf, ident.name_begin - buf-buf,
+ ident.mail_end - ident.name_begin + 1,
+ namemail.buf, namemail.len);
+
+   strbuf_release(namemail);
+
+   return 1;
+   }
+
+   return 0;
+}
+
 static int commit_match(struct commit *commit, struct rev_info *opt)
 {
int retval;
@@ -2237,6 +2283,14 @@ static int commit_match(struct commit *commit, struct 
rev_info *opt)
if (buf.len)
strbuf_addstr(buf, commit-buffer);
 
+   if (opt-mailmap) {
+   if (!buf.len)
+   strbuf_addstr(buf, commit-buffer);
+
+   commit_rewrite_person(buf, \nauthor , opt-mailmap);
+   commit_rewrite_person(buf, \ncommitter , opt-mailmap);
+   }
+
/* Append fake message parts as needed */
if (opt-show_notes) {
if (!buf.len)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db043dc..e16187f 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -248,11 +248,29 @@ Author: Other Author ot...@author.xx
 Author: Some Dude s...@dude.xx
 Author: A U Thor aut...@example.com
 EOF
+
 test_expect_success 'Log output with --use-mailmap' '
git log --use-mailmap | grep Author actual 
test_cmp expect actual
 '
 
+cat expect \EOF
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Santa Claus santa.cl...@northpole.xx
+EOF
+
+test_expect_success 'Grep author with --use-mailmap' '
+   git log --use-mailmap --author Santa | grep Author actual 
+   test_cmp expect actual
+'
+
+expect
+
+test_expect_success 'Only grep replaced author with --use-mailmap' '
+   git log --use-mailmap --author c...@coompany.xx actual 
+   test_cmp expect actual
+'
+
 # git blame
 cat expect \EOF
 ^OBJI (A U Thor DATE 1) one
-- 
1.7.12.4.3.g2036a08.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: [PATCH v4] git-completion.bash: add support for path completion

2013-01-05 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 21:23, Marc Khouzam ha scritto:
 [...]
 I did further testing with your patch and found some less obvious
 issues.  I didn't debug the script myself as I'm not that familiar with
 it either, but I think the testcases below should help Manlio or
 someone else look into some regressions.
 
 1- Using .. or . breaks completion when after the '/':
 [...] 
 2- Maybe related to problem 1.  Using .. breaks completion in other ways:
 [...]
 3- Also probably related to problems 1 and 2.  Using absolute paths behaves 
 wierdly and 
 worse than before:

Thanks for this.

I begin to suspect that this is the reason why path completion has not
been implemented by the original author of the bash completion script.

These issues seems hard to fix.

Tomorrow I will take some time to try to fix all the reported issues.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDomskACgkQscQJ24LbaUQJdwCfX0bMq3V88soqtf+xlypZ5D4f
qwAAn3bK7UlcOK+hm+u06jmT05l1aJVf
=IWap
-END PGP SIGNATURE-
--
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] status: report ignored yet tracked directories

2013-01-05 Thread Torsten Bögershausen
On 05.01.13 21:42, Antoine Pelisse wrote:
 Tracked directories (i.e. directories containing tracked files) that
 are ignored must be reported as ignored if they contain untracked files.

 Currently, tracked files or directories can't be reported untracked or 
 ignored.
 Remove that constraint when searching ignored files.

 Signed-off-by: Antoine Pelisse apeli...@gmail.com
 ---
 Torsten, Jeff,

 Can you please test this patch and tell me if this is better ? (t7061 is now
 successful with core.ignorecase=true)

 This patch applies on top of ap/status-ignored-in-ignored-directory (but
  should also apply cleanly on top of next for testing purpose).

 Thanks,

  dir.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/dir.c b/dir.c
 index 9b80348..eefa8ab 100644
 --- a/dir.c
 +++ b/dir.c
 @@ -672,7 +672,8 @@ static struct dir_entry *dir_entry_new(const char 
 *pathname, int len)

  static struct dir_entry *dir_add_name(struct dir_struct *dir, const char 
 *pathname, int len)
  {
 - if (cache_name_exists(pathname, len, ignore_case))
 + if (!(dir-flags  DIR_SHOW_IGNORED) 
 + cache_name_exists(pathname, len, ignore_case))
   return NULL;

   ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
 --
 1.7.12.4.2.geb8c5b8.dirty

(BTW: thanks for contributing to git)
Antoine, the test is OK:
# passed all 10 test(s)

I'm not sure if I am happy with the commit message, so I try to have an improved
version below, which may be a starting point for a discussion:

git status: report ignored directories correctly

A directory containing tracked files where the directory
is ignored must be reported as ignored even if it contains untracked files.

/Torsten


--
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 07/10] log: add --use-mailmap option

2013-01-05 Thread Antoine Pelisse
Add the --use-mailmap option to log commands. It allows
to display names from mailmap file when displaying logs,
whatever the format used.

Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
 Documentation/git-log.txt | 5 +
 builtin/log.c | 9 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 585dac4..a99be97 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -47,6 +47,11 @@ OPTIONS
Print out the ref name given on the command line by which each
commit was reached.
 
+--use-mailmap::
+   Use mailmap file to map author and committer names and email
+   to canonical real names and email addresses. See
+   linkgit:git-shortlog[1].
+
 --full-diff::
Without this flag, git log -p path... shows commits that
touch the specified paths, and diffs about the same specified
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..d2bd8ce 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -22,6 +22,7 @@
 #include branch.h
 #include streaming.h
 #include version.h
+#include mailmap.h
 
 /* Set a default date-time format for git log (log.date config variable) */
 static const char *default_date_mode = NULL;
@@ -94,11 +95,12 @@ static void cmd_log_init_finish(int argc, const char 
**argv, const char *prefix,
 struct rev_info *rev, struct setup_revision_opt *opt)
 {
struct userformat_want w;
-   int quiet = 0, source = 0;
+   int quiet = 0, source = 0, mailmap = 0;
 
const struct option builtin_log_options[] = {
OPT_BOOLEAN(0, quiet, quiet, N_(suppress diff output)),
OPT_BOOLEAN(0, source, source, N_(show source)),
+   OPT_BOOLEAN(0, use-mailmap, mailmap, N_(Use mail map 
file)),
{ OPTION_CALLBACK, 0, decorate, NULL, NULL, N_(decorate 
options),
  PARSE_OPT_OPTARG, decorate_callback},
OPT_END()
@@ -136,6 +138,11 @@ static void cmd_log_init_finish(int argc, const char 
**argv, const char *prefix,
if (source)
rev-show_source = 1;
 
+   if (mailmap) {
+   rev-mailmap = xcalloc(1, sizeof(struct string_list));
+   read_mailmap(rev-mailmap, NULL);
+   }
+
if (rev-pretty_given  rev-commit_format == CMIT_FMT_RAW) {
/*
 * log --pretty=raw is special; ignore UI oriented
-- 
1.7.12.4.3.g2036a08.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: [PATCH 01/10] list_lookup: create case and length search

2013-01-05 Thread Junio C Hamano
Antoine Pelisse apeli...@gmail.com writes:

 Create a new function to look-up a string in a string_list, but:
  - add a new parameter to ignore case differences
  - add a length parameter to search for a substring

 The idea is to avoid several copies (lowering a string before searching
 it when we just want to ignore case), or copying a substring of a bigger
 string to search it in the string_list

 Signed-off-by: Antoine Pelisse apeli...@gmail.com
 ---

I did not read beyond the log message and the function signature of
the updated get_entry_index(), but it strikes me insane to build a
sorted list using case sensitive full string comarison and then to
look for an element in that list using a different comparison
criteria (e.g. case insensitive comparison) and to expect the
bisection search to still work.  Shouldn't the codepath that builds
the string-list be sorting the list in case insensitive way from the
beginning if this were to work correctly?

It seems to suggest to me that this are the keys case sensitive?
bit belongs to the entire struct string_list structure as its
property (similar to the way do the keys need to be strdup'ed?
bit), not something you would flip per invocation basis of the
lookup function.

Also isn't size_t an unsigned type?  What does it even mean to pass
-1 to it, and propagate it down to strncmp()?

If you have a list sorted by a key, and if you want to query it with
a partial prefix of a possibly valid key, I think you shouldn't have
to add the length search at all. The existing look up function
would return the location in the list that short key would have been
inserted, which would come before the first entry that your short
key is a prefix of, so the caller can iterate the list from there to
find all entries.  In other words, if existing list has aaa,
bba, and bbc, and you want to grab entries that begin with bb,
you can ask for bb to the loop up function, which would say the
key does not exist in the list, but it would be inserted before this
'bba' entry.  Then you can discover that bba and bbc both
matches the shortened key you have, no?
--
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: [LHF] making t5000 tar xf tests more lenient

2013-01-05 Thread René Scharfe

Am 05.01.2013 21:11, schrieb Junio C Hamano:

René Scharfe rene.scha...@lsrfire.ath.cx writes:


Anyway, I don't think the pax headers are to blame here.


Hmph, I am reasonably sure I saw a test that created an archive from
a commit (hence with pax header), asked platform tar to either list
the contents or actually extracted to the filesystem, and tried to
ensure nothing but the paths in the repository existed in the
archive.  When the platform tar implementation treated the pax
header as an extra file, such a test sees something not in the
repository and fails.


t5000 avoids that issue by comparing only the contents of a 
subdirectory.  The script could do with a little cleanup, in any case. 
Moving ZIP testing into its own file, more explicit pax header file 
handling, speaking file and directory names, and modern coding style 
would all be nice. :)


René

--
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] Add getenv.so for catching invalid getenv() use via LD_PRELOAD

2013-01-05 Thread Jonathan Nieder
Nguyễn Thái Ngọc Duy wrote:

 Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
 ---
  Perhaps this will help the getenv bug hunting

Even if no one decides to do the getenv hunting (I haven't decided yet
whether it's worth the trouble, though patches like the setup_path()
one that make string lifetimes clearer are valuable anyway), this
looks useful as a debugging tool when people on strange platforms
report problems.  And unlike the trick I sent a while ago, it doesn't
involve recompiling git.  So for what it's worth,

Acked-by: Jonathan Nieder jrnie...@gmail.com

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: cvsps, parsecvs, svn2git and the CVS exporter mess

2013-01-05 Thread Jonathan Nieder
Eric S. Raymond wrote:

 Michael Haggerty wants me to trust that cvs2git's analysis stage has
 been fixed, but I must say that is a more difficult leap of faith when
 two of the most visible things about it are still (a) a conspicuous
 instance of interface misdesign, and (b) documentation that is careless and
 incomplete.

For what it's worth, I use cvs2git quite often.  I've found it to work
well and its code to be clear and its developers responsive.  But I
don't mind if we disagree, and multiple implementations to explore the
design space of importers doesn't seem like a terrible outcome.

Thanks for your work,
Jonathan
--
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] status: report ignored yet tracked directories

2013-01-05 Thread Jeff King
On Sat, Jan 05, 2013 at 09:42:43PM +0100, Antoine Pelisse wrote:

 Tracked directories (i.e. directories containing tracked files) that
 are ignored must be reported as ignored if they contain untracked files.
 
 Currently, tracked files or directories can't be reported untracked or 
 ignored.
 Remove that constraint when searching ignored files.
 
 Signed-off-by: Antoine Pelisse apeli...@gmail.com
 ---

I was expecting to see some explanation of the user-visible bug here. In
other words, what does this fix, and why does the bug only happen when
core.ignorecase is set.

Looking at your fix and remembering how the index hashing works, I think
the answer is that:

  1. This bug only affects directories, because they are the only thing
 that can be simultaneously ignored and untracked and tracked
 (i.e., they have entries of both, and we are using
 DIR_SHOW_OTHER_DIRECTORIES).

  2. When core.ignorecase is false, the index name hash contains only
 the file entries, and cache_name_exists returns an exact match. So
 it doesn't matter if we make an extra check when adding the
 directory via dir_add_name; we know that it will not be there, and
 the final check is a no-op.

  3. When core.ignorecase is true, we also store directory entries in
 the index name hash, and this extra check is harmful; the entry
 does not really exist in the index, and we still need to add it.

But that makes me wonder. In the ignorecase=false case, I claimed that
the check in dir_add_name is a no-op for mixed tracked/ignored
directories. But it is presumably not a no-op for other cases. Your
patch only turns it off when DIR_SHOW_IGNORED is set. But is it possible
for us to have DIR_SHOW_IGNORED set, _and_ to pass in a path that exists
in the index as a regular file?

I think in the normal file case, we'd expect treat_path to just tell us
that it is handled, and we would not ever call dir_add_name in the first
place. But what if we have an index entry for a file, but the working
tree now contains a directory?

I _think_ we still do not hit this code path in that instance, because
we will end up in treat_directory, and we will end up checking
directory_exists_in_index. And I cannot get it to misbehave in practice.
So I think your fix is correct, but the exact how and why is a bit
subtle.

-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] Alphabetize the fast-import options, following a suggestion on the list.

2013-01-05 Thread Jonathan Nieder
Eric S. Raymond wrote:

 ---

Missing sign-off.  Depending on when you prefer to add the sign-off, something
like

echo '[alias] c = commit --signoff' ~/.gitconfig

or

echo '[alias] f = format-patch --signoff' ~/.gitconfig

might be useful for the future, assuming you already look over what
you are sending out in a mail client to avoid mistakes.

 Documentation/git-fast-import.txt | 94 +++
 1 file changed, 45 insertions(+), 49 deletions(-)

My knee-jerk response was If the options are currently organized logically,
wouldn't it be more appropriate to add a sub-heading for each group of options
and alphabetize only within the subgroups?

But in fact the current options list doesn't seem to be well organized at all.
What do you think would be a logical way to group these?

 Features of input syntax

--date-format
--done

 Verbosity

--quiet
--stats

 Marks handling (checkpoint/restore)

--import-marks
--import-marks-if-exists
--export-marks
--relative-marks

 Semantics of execution

--dry-run
--force
--cat-blob-fd
--export-pack-edges

 Tuning

--active-branches
--max-pack-size
--big-file-threshold
--depth
--
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] run-command: encode signal death as a positive integer

2013-01-05 Thread Jeff King
On Sat, Jan 05, 2013 at 02:19:09PM -0800, Jonathan Nieder wrote:

   Documentation/technical/api-run-command.txt | 6 ++
   editor.c| 2 +-
   run-command.c   | 2 +-
   3 files changed, 4 insertions(+), 6 deletions(-)
 
 t/test-terminal.perl imitates the same logic.  It doesn't check for
 anything other than whether the exit status is 0, but maybe it would
 be worth squashing in the below as a futureproofing measure
 nonetheless.

Yeah, I think so. As you say, it does not matter, but it makes sense to
keep our conventions consistent.

 Aside from the launch_editor bugfix, the only observable effects of
 the above patch I can find are some changed error messages:
 
   error: external filter cat failed -126
   - error: external filter cat failed 130
 
   warning: svnrdump, returned -126
   - warning: svnrdump, returned 130
 
 Those messages are equally senseless before and after the patch, so
 for what it's worth,

Thanks. I agree that change isn't a big deal (I would argue the positive
return is slightly more coherent as it matches what the shell would
report, but I really think user-facing errors should probably not even
mention the exact exit code, as it is just noise most of the time, and
we already complain about signals in wait_or_whine).

I did try auditing the callers of finish_command (and run_command) to
make sure I wasn't regressing anybody, but there are a lot of call
sites. In some cases we immediately say:

  if (finish_command(child))
  die(failed...);

which is obviously unaffected. But in many cases we pass the exit code
up through several levels. It usually just ends up in exit() or being
collapsed to an error boolean, which is fine, but I may have missed a
spot where it matters. I'd expecting cooking this patch for a while
would flush out any I missed.

 Reviewed-by: Jonathan Nieder jrnie...@gmail.com

Thanks (and to J6t) for the review.

-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] git-fast-import(1): remove duplicate --done option

2013-01-05 Thread Jonathan Nieder
John Keeping wrote:

 The --done option to git-fast-import is documented twice in its manual
 page.  Combine the best bits of each description, keeping the location
 of the instance that was added first.

 Signed-off-by: John Keeping j...@keeping.me.uk

Good catch, thanks.

Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation: fix man page dependency on asciidoc.conf

2013-01-05 Thread Jonathan Nieder
John Keeping wrote:

 When building manual pages, the source text is transformed to XML with
 AsciiDoc before the man pages are generated from the XML with xmlto.

 Fix the dependency in the Makefile so that the XML files are rebuilt
 when asciidoc.conf changes and not just the manual pages from unchanged
 XML.

Good catch, thanks.

Would something like the following make sense, to make it more obvious
how the dependency needs to be adjusted if we change the $(ASCIIDOC)
command line for some reason?

diff --git i/Documentation/Makefile w/Documentation/Makefile
index e53d333e..971977b8 100644
--- i/Documentation/Makefile
+++ w/Documentation/Makefile
@@ -178,8 +178,6 @@ all: html man
 
 html: $(DOC_HTML)
 
-$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf
-
 man: man1 man5 man7
 man1: $(DOC_MAN1)
 man5: $(DOC_MAN5)
@@ -257,7 +255,7 @@ clean:
$(RM) $(cmds_txt) *.made
$(RM) manpage-base-url.xsl
 
-$(MAN_HTML): %.html : %.txt
+$(MAN_HTML): %.html : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@  \
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $  \
@@ -270,7 +268,7 @@ manpage-base-url.xsl: manpage-base-url.xsl.in
$(QUIET_XMLTO)$(RM) $@  \
$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $
 
-%.xml : %.txt
+%.xml : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@  \
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $  \
@@ -286,7 +284,7 @@ technical/api-index.txt: technical/api-index-skel.txt \
$(QUIET_GEN)cd technical  '$(SHELL_PATH_SQ)' ./api-index.sh
 
 technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
-$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : 
%.txt
+$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : 
%.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
 
diff --git i/t/test-terminal.perl w/t/test-terminal.perl
index 10172aee..1fb373f2 100755
--- i/t/test-terminal.perl
+++ w/t/test-terminal.perl
@@ -31,7 +31,7 @@ sub finish_child {
} elsif ($?  127) {
my $code = $?  127;
warn died of signal $code;
-   return $code - 128;
+   return $code + 128;
} else {
return $?  8;
}
--
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] archive-tar: split long paths more carefully

2013-01-05 Thread Jonathan Nieder
René Scharfe wrote:

 --- a/archive-tar.c
 +++ b/archive-tar.c
 @@ -153,6 +153,8 @@ static unsigned int ustar_header_chksum(const struct 
 ustar_header *header)
  static size_t get_path_prefix(const char *path, size_t pathlen, size_t 
 maxlen)
  {
   size_t i = pathlen;
 + if (i  1  path[i - 1] == '/')
 + i--;

Beautiful.
--
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] fix compilation with NO_PTHREADS

2013-01-05 Thread Jonathan Nieder
Jeff King wrote:

 I happened to notice this while looking at the sigpipe topic. I guess
 not many people are building with NO_PTHREADS these days.

Or that those people don't build next. :)

Thanks for catching 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: [PATCH] run-command: encode signal death as a positive integer

2013-01-05 Thread Jonathan Nieder
Jeff King wrote:

I'd expecting cooking this patch for a while
 would flush out any I missed.

Heh, probably not. ;-)  But I tried to examine all the callsites (and
only found the two messages I mentioned), and among the reviewers, I'm
guessing we hit them all.

Ciao,
Jonathan
--
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: [Feature request] make git buildable from a separate directory

2013-01-05 Thread Jonathan Nieder
Hi Manlio,

Manlio Perillo wrote:

 Many C projects I have seen (based on autoconf, but not always - like
 Nginx) allow the project to be build in a separate directory, in order
 to avoid to pollute the working directory with compiled files.

 Unfortunately this seems to not be possible with Git.

I believe the Cygwin build[1] does this, so that could be a starting
point if you want to work on it.

They use the VPATH variable[2].

Hope that helps,
Jonathan

[1] http://cygwin.com/ml/cygwin/2012-02/msg00391.html
[2] 
https://www.gnu.org/software/make/manual/html_node/General-Search.html#General-Search
--
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


Trying to understand the web dav details

2013-01-05 Thread Jason Pyeron
When doing a clone by https (reverse proxied to http) the first request is

GET /git/project/info/refs?service=git-upload-pack

How does the ?service= get translated in to the action performed on the web
server?

I ask because I have 2 projects, one works the other does not.

I am using httpd-2.0.52-49.ent.centos4 and git-1.7.9.6-1.

I am not even sure what to tell more about or where to look next.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


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


Version 1.8.1 does not compile on Cygwin 1.7.14

2013-01-05 Thread Stephen Linda Smith
 Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message states that
 the macro was being renamed for clarity. The patch also changes a define.

This change causes the code to not compile on cygwin 1.7.14.

 I narrowed the problem to this patch by bisecting commits between v1.8.0 and 
1.8.1

Here is the error sequence:

CC compat/cygwin.o
In file included from compat/../git-compat-util.h:90,
 from compat/cygwin.c:9:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: 
warning: #warning fd_set and associated macros have been defined in sys/types. 
 
This may cause runtime problems with W32 sockets
In file included from /usr/include/sys/socket.h:16,
 from compat/../git-compat-util.h:131,
 from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr'
/usr/include/cygwin/socket.h:41: error: redefinition of `struct 
sockaddr_storage'
In file included from /usr/include/sys/socket.h:16,
 from compat/../git-compat-util.h:131,
 from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:59: error: redefinition of `struct linger'
In file included from compat/../git-compat-util.h:131,
 from compat/cygwin.c:9:
/usr/include/sys/socket.h:30: error: conflicting types for 'accept'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: 
error: previous declaration of 'accept' was here
/usr/include/sys/socket.h:30: error: conflicting types for 'accept'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: 
error: previous declaration of 'accept' was here
/usr/include/sys/socket.h:32: error: conflicting types for 'bind'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537: 
error: previous declaration of 'bind' was here
/usr/include/sys/socket.h:32: error: conflicting types for 'bind'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537: 
error: previous declaration of 'bind' was here
/usr/include/sys/socket.h:33: error: conflicting types for 'connect'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539: 
error: previous declaration of 'connect' was here
/usr/include/sys/socket.h:33: error: conflicting types for 'connect'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539: 
error: previous declaration of 'connect' was here
/usr/include/sys/socket.h:34: error: conflicting types for 'getpeername'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541: 
error: previous declaration of 'getpeername' was here
/usr/include/sys/socket.h:34: error: conflicting types for 'getpeername'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541: 
error: previous declaration of 'getpeername' was here
/usr/include/sys/socket.h:35: error: conflicting types for 'getsockname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542: 
error: previous declaration of 'getsockname' was here
/usr/include/sys/socket.h:35: error: conflicting types for 'getsockname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542: 
error: previous declaration of 'getsockname' was here
/usr/include/sys/socket.h:36: error: conflicting types for 'listen'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546: 
error: previous declaration of 'listen' was here
/usr/include/sys/socket.h:36: error: conflicting types for 'listen'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546: 
error: previous declaration of 'listen' was here
/usr/include/sys/socket.h:37: error: conflicting types for 'recv'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547: 
error: previous declaration of 'recv' was here
/usr/include/sys/socket.h:37: error: conflicting types for 'recv'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547: 
error: previous declaration of 'recv' was here
/usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548: 
error: previous declaration of 'recvfrom' was here
/usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548: 
error: previous declaration of 'recvfrom' was here
/usr/include/sys/socket.h:41: error: conflicting types for 'send'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549: 
error: previous declaration of 'send' was here
/usr/include/sys/socket.h:41: error: conflicting types for 'send'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549: 
error: previous declaration of 'send' was here
/usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:550: 
error: previous declaration of 

RE: Version 1.8.1 does not compile on Cygwin 1.7.14

2013-01-05 Thread Jason Pyeron

 Stephen  Linda Smith
 Sent: Saturday, January 05, 2013 21:05
 
  Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message 
 states that  the macro was being renamed for clarity. The 
 patch also changes a define.

Was it the commit before 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles
or was it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I am doing a
cygwin update presently to look at it.

 
 This change causes the code to not compile on cygwin 1.7.14.
 
  I narrowed the problem to this patch by bisecting commits 
 between v1.8.0 and
 1.8.1
 
 Here is the error sequence:
 
 CC compat/cygwin.o
 In file included from compat/../git-compat-util.h:90,
  from compat/cygwin.c:9:
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:103:2: 
 warning: #warning fd_set and associated macros have been 
 defined in sys/types.  
 This may cause runtime problems with W32 sockets
 In file included from /usr/include/sys/socket.h:16,
  from compat/../git-compat-util.h:131,
  from compat/cygwin.c:9:
 /usr/include/cygwin/socket.h:29: error: redefinition of 
 `struct sockaddr'
 /usr/include/cygwin/socket.h:41: error: redefinition of 
 `struct sockaddr_storage'
 In file included from /usr/include/sys/socket.h:16,
  from compat/../git-compat-util.h:131,
  from compat/cygwin.c:9:
 /usr/include/cygwin/socket.h:59: error: redefinition of 
 `struct linger'
 In file included from compat/../git-compat-util.h:131,
  from compat/cygwin.c:9:
 /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:536: 
 error: previous declaration of 'accept' was here
 /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:536: 
 error: previous declaration of 'accept' was here
 /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:537: 
 error: previous declaration of 'bind' was here
 /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:537: 
 error: previous declaration of 'bind' was here
 /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:539: 
 error: previous declaration of 'connect' was here
 /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:539: 
 error: previous declaration of 'connect' was here
 /usr/include/sys/socket.h:34: error: conflicting types for 
 'getpeername'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:541: 
 error: previous declaration of 'getpeername' was here
 /usr/include/sys/socket.h:34: error: conflicting types for 
 'getpeername'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:541: 
 error: previous declaration of 'getpeername' was here
 /usr/include/sys/socket.h:35: error: conflicting types for 
 'getsockname'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:542: 
 error: previous declaration of 'getsockname' was here
 /usr/include/sys/socket.h:35: error: conflicting types for 
 'getsockname'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:542: 
 error: previous declaration of 'getsockname' was here
 /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:546: 
 error: previous declaration of 'listen' was here
 /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:546: 
 error: previous declaration of 'listen' was here
 /usr/include/sys/socket.h:37: error: conflicting types for 'recv'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:547: 
 error: previous declaration of 'recv' was here
 /usr/include/sys/socket.h:37: error: conflicting types for 'recv'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:547: 
 error: previous declaration of 'recv' was here
 /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:548: 
 error: previous declaration of 'recvfrom' was here
 /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:548: 
 error: previous declaration of 'recvfrom' was here
 /usr/include/sys/socket.h:41: error: conflicting types for 'send'
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:549: 
 error: previous declaration of 'send' was 

Re: Trying to understand the web dav details

2013-01-05 Thread Jeff King
On Sat, Jan 05, 2013 at 08:32:09PM -0500, Jason Pyeron wrote:

 When doing a clone by https (reverse proxied to http) the first request is
 
 GET /git/project/info/refs?service=git-upload-pack
 
 How does the ?service= get translated in to the action performed on the 
 web
 server?

If you are using the git-http-backend CGI, it will interpret the service
tag and start smart-http. See git help http-backend for details on
plugging it into Apache.

Cloning/fetching does not use DAV at all; it is only for non-smart
pushing (and I would not recommend setting it up; the smart protocol
spoken by git-http-backend does pushing much more efficiently, and is
better maintained).

 I ask because I have 2 projects, one works the other does not.
 
 I am using httpd-2.0.52-49.ent.centos4 and git-1.7.9.6-1.
 
 I am not even sure what to tell more about or where to look next.

If you haven't set up git-http-backend, then git is just going to fetch
the remote repo's data directly over http. So the usual advice for
accessing something via http would apply (check the server's access and
error logs, try hitting it with a web browser, etc).

If you set GIT_CURL_VERBOSE=1 in your environment, git will spew a lot
of debugging information about what http requests it is making. That
might give you a clue (you haven't said anything about what does not
work, so I can't be more specific).

-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: Version 1.8.1 does not compile on Cygwin 1.7.14

2013-01-05 Thread Jason Pyeron

 -Original Message-
 From: Jason Pyeron
 Sent: Saturday, January 05, 2013 22:38
 
 
  Stephen  Linda Smith
  Sent: Saturday, January 05, 2013 21:05
  
   Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message 
 states that  
  the macro was being renamed for clarity. The patch also changes a 
  define.
 
 Was it the commit before 
 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was 
 it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I 
 am doing a cygwin update presently to look at it.
 
  
  This change causes the code to not compile on cygwin 1.7.14.
  
   I narrowed the problem to this patch by bisecting commits between 
  v1.8.0 and
  1.8.1
  
  Here is the error sequence:

Cannot reproduce on head and current cygwin, more details please.

  
  CC compat/cygwin.o
  In file included from compat/../git-compat-util.h:90,
   from compat/cygwin.c:9:
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:103:2: 
  warning: #warning fd_set and associated macros have been 
  defined in sys/types.  
  This may cause runtime problems with W32 sockets
  In file included from /usr/include/sys/socket.h:16,
   from compat/../git-compat-util.h:131,
   from compat/cygwin.c:9:
  /usr/include/cygwin/socket.h:29: error: redefinition of `struct 
  sockaddr'
  /usr/include/cygwin/socket.h:41: error: redefinition of `struct 
  sockaddr_storage'
  In file included from /usr/include/sys/socket.h:16,
   from compat/../git-compat-util.h:131,
   from compat/cygwin.c:9:
  /usr/include/cygwin/socket.h:59: error: redefinition of `struct 
  linger'
  In file included from compat/../git-compat-util.h:131,
   from compat/cygwin.c:9:
  /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:536: 
  error: previous declaration of 'accept' was here
  /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:536: 


jpyeron@porsche /projects/git/git
$ make  uname -a  git status  git log --oneline | head -n1
GEN perl/PM.stamp
SUBDIR gitweb
SUBDIR ../
make[2]: `GIT-VERSION-FILE' is up to date.
GEN git-instaweb
BUILTIN all
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Nothing to be done for `all'.
SUBDIR perl
SUBDIR git_remote_helpers
SUBDIR templates
CYGWIN_NT-5.2-WOW64 porsche 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin
# On branch master
nothing to commit (working directory clean)
3e293fb Update draft release notes to 1.8.2



  error: previous declaration of 'accept' was here
  /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:537: 
  error: previous declaration of 'bind' was here
  /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:537: 
  error: previous declaration of 'bind' was here
  /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:539: 
  error: previous declaration of 'connect' was here
  /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:539: 
  error: previous declaration of 'connect' was here
  /usr/include/sys/socket.h:34: error: conflicting types for 
  'getpeername'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:541: 
  error: previous declaration of 'getpeername' was here
  /usr/include/sys/socket.h:34: error: conflicting types for 
  'getpeername'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:541: 
  error: previous declaration of 'getpeername' was here
  /usr/include/sys/socket.h:35: error: conflicting types for 
  'getsockname'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:542: 
  error: previous declaration of 'getsockname' was here
  /usr/include/sys/socket.h:35: error: conflicting types for 
  'getsockname'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:542: 
  error: previous declaration of 'getsockname' was here
  /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:546: 
  error: previous declaration of 'listen' was here
  /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:546: 
  error: previous declaration of 'listen' was here
  /usr/include/sys/socket.h:37: error: conflicting types for 'recv'
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
 insock2.h:547: 
  error: previous 

RE: Trying to understand the web dav details

2013-01-05 Thread Pyeron, Jason J CTR (US)
 -Original Message-
 From: Jeff King
 Sent: Saturday, January 05, 2013 11:20 PM
 
 On Sat, Jan 05, 2013 at 08:32:09PM -0500, Jason Pyeron wrote:
 
  When doing a clone by https (reverse proxied to http) the first
 request is
 
  GET /git/project/info/refs?service=git-upload-pack
 
  How does the ?service= get translated in to the action performed
 on the web
  server?
 
 If you are using the git-http-backend CGI, it will interpret the
 service

No, using plain jane http and webdav. This server is not allowed to use cgi 
processes.

 tag and start smart-http. See git help http-backend for details on
 plugging it into Apache.
 
 Cloning/fetching does not use DAV at all; it is only for non-smart
 pushing (and I would not recommend setting it up; the smart protocol
 spoken by git-http-backend does pushing much more efficiently, and is
 better maintained).
 
  I ask because I have 2 projects, one works the other does not.

Should have said I get a 404 versus 200, see below.

 
  I am using httpd-2.0.52-49.ent.centos4 and git-1.7.9.6-1.
 
  I am not even sure what to tell more about or where to look next.
 
 If you haven't set up git-http-backend, then git is just going to fetch
 the remote repo's data directly over http. So the usual advice for
 accessing something via http would apply (check the server's access and
 error logs, try hitting it with a web browser, etc).
 
 If you set GIT_CURL_VERBOSE=1 in your environment, git will spew a lot

That’s what I did before mailing out the first time. I tried to summarize the 
contents, but I will paste the relevant portions below.

 of debugging information about what http requests it is making. That
 might give you a clue (you haven't said anything about what does not
 work, so I can't be more specific).

Below are two traces, the first one is the one that does not work, the second 
does. I cannot see any differences on the web server for the two directory 
trees.

**
**
**
**

jason.pyeron@localhost ~/tmp
$ GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone https://server/git/project-x
trace: built-in: git 'clone' 'https://server/git/project-x'
Cloning into 'project-x'...
trace: run_command: 'git-remote-https' 'origin' 'https://server/git/project-x'
* Couldn't find host server in the .netrc file; using defaults
* About to connect() to proxy 214.36.0.135 port 8080 (#0)
*   Trying 214.36.0.135...
* 0x80076a48 is at send pipe head!
* STATE: CONNECT = WAITCONNECT handle 0x8007f3c0; (connection #0)
* Connected to 214.36.0.135 (214.36.0.135) port 8080 (#0)
* Connected to 214.36.0.135 (214.36.0.135) port 8080 (#0)
* Establish HTTP proxy tunnel to server:443
 CONNECT server:443 HTTP/1.1
Host: server:443
User-Agent: git/1.7.9
Proxy-Connection: Keep-Alive
Pragma: no-cache

* STATE: WAITCONNECT = WAITPROXYCONNECT handle 0x8007f3c0; (connection #0)
* Multi mode finished polling for response from proxy CONNECT
 HTTP/1.1 200 Connection established

* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: /usr/ssl/certs/ca-bundle.crt
  CApath: none
* STATE: WAITPROXYCONNECT = WAITCONNECT handle 0x8007f3c0; (connection #0)
* STATE: WAITCONNECT = PROTOCONNECT handle 0x8007f3c0; (connection #0)
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*subject: C=US; ST=Maryland; O=PD Inc; OU=Intranet; CN=server; 
emailAddress=secur...@pdinc.us
*start date: 201
*expire date: 201
*issuer: C=U
*SSL certificate verify result: self signed certificate in certificate 
chain (19), continuing anyway.
* STATE: PROTOCONNECT = DO handle 0x8007f3c0; (connection #0)
 GET /git/project-x/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.9
Host: server
Accept: */*
Pragma: no-cache

* STATE: DO = DO_DONE handle 0x8007f3c0; (connection #0)
* STATE: DO_DONE = WAITPERFORM handle 0x8007f3c0; (connection #0)
* STATE: WAITPERFORM = PERFORM handle 0x8007f3c0; (connection #0)
* additional stuff not fine 
/usr/src/ports/curl/curl-7.27.0-1/src/curl-7.27.0/lib/transfer.c:1037: 0 0
* additional stuff not fine 
/usr/src/ports/curl/curl-7.27.0-1/src/curl-7.27.0/lib/transfer.c:1037: 0 0
* The requested URL returned error: 404 Not Found
* Closing connection #0
* Couldn't find host server in the .netrc file; using defaults
* About to connect() to proxy 214.36.0.135 port 8080 (#0)
*   Trying 214.36.0.135...
* 0x80076a48 is at send pipe head!
* STATE: CONNECT = WAITCONNECT handle 0x80139640; (connection #0)
* Connected to 214.36.0.135 (214.36.0.135) port 8080 (#0)
* Connected to 214.36.0.135 (214.36.0.135) port 8080 (#0)
* Establish HTTP proxy tunnel to server:443
 CONNECT server:443 HTTP/1.1
Host: server:443
User-Agent: git/1.7.9

[PATCH 00/21] struct pathspec conversion

2013-01-05 Thread Nguyễn Thái Ngọc Duy
This is another step towards the pathspec unification. This series
introduces a get_pathspec() alternative: parse_pathspec(). The new
function intializes struct pathspec directly. Many builtin commands
(except mv) are converted to use this function. As a result, struct
pathspec is used from the start for many commands.

The next step would be dealing with pathspec manipulation code blocks
that use raw field, init_pathspec or get_pathspec(). add.c, dir.c,
rm.c and mv.c are hot places. And perhaps move pathspec code from
dir.c and setup.c to pathspec.c after as/check-ignore enters master.

This series shares a patch (the first one) with nd/pathspec-wildcard. I
put the patch in the series to avoid dependency.

This series also disables wildcards in the prefix part, but it's only
effective in combination with nd/pathspec-wildcard. And of course it's
not fully effective until all raw use is eliminated.

Nguyễn Thái Ngọc Duy (21):
  pathspec: save the non-wildcard length part
  Add parse_pathspec() that converts cmdline args to struct pathspec
  pathspec: make sure the prefix part is wildcard-clean
  Export parse_pathspec() and convert some get_pathspec() calls
  clean: convert to use parse_pathspec
  commit: convert to use parse_pathspec
  status: convert to use parse_pathspec
  rerere: convert to use parse_pathspec
  checkout: convert to use parse_pathspec
  rm: convert to use parse_pathspec
  ls-files: convert to use parse_pathspec
  archive: convert to use parse_pathspec
  add: convert to use parse_pathspec
  Convert read_cache_preload() to take struct pathspec
  Convert unmerge_cache to take struct pathspec
  checkout: convert read_tree_some to take struct pathspec
  Convert report_path_error to take struct pathspec
  Convert refresh_index to take struct pathspec
  Convert {read,fill}_directory to take struct pathspec
  Convert add_files_to_cache to take struct pathspec
  Convert more init_pathspec() to parse_pathspec()

 archive.c  |  12 +++---
 archive.h  |   2 +-
 builtin/add.c  |  75 ++--
 builtin/checkout.c |  37 --
 builtin/clean.c|  20 +-
 builtin/commit.c   |  35 +
 builtin/diff-files.c   |   2 +-
 builtin/diff-index.c   |   2 +-
 builtin/diff.c |   4 +-
 builtin/grep.c |   6 +--
 builtin/log.c  |   2 +-
 builtin/ls-files.c |  64 +++
 builtin/ls-tree.c  |   4 +-
 builtin/rerere.c   |   6 +--
 builtin/rm.c   |  16 
 builtin/update-index.c |   3 +-
 cache.h|  19 +++---
 diff-lib.c |   2 +-
 dir.c  |  38 ++-
 dir.h  |   5 ++-
 merge-recursive.c  |   2 +-
 preload-index.c|  20 +-
 read-cache.c   |   5 ++-
 rerere.c   |   6 +--
 rerere.h   |   4 +-
 resolve-undo.c |   4 +-
 resolve-undo.h |   2 +-
 revision.c |   4 +-
 setup.c| 101 +
 tree-walk.c|   4 +-
 tree.c |   4 +-
 tree.h |   2 +-
 wt-status.c|  17 -
 wt-status.h|   2 +-
 34 files changed, 291 insertions(+), 240 deletions(-)

-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 01/21] pathspec: save the non-wildcard length part

2013-01-05 Thread Nguyễn Thái Ngọc Duy
We mark pathspec with wildcards with the field use_wildcard. We
could do better by saving the length of the non-wildcard part, which
can be used for optimizations such as f9f6e2c (exclude: do strcmp as
much as possible before fnmatch - 2012-06-07).

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 builtin/ls-files.c | 2 +-
 builtin/ls-tree.c  | 2 +-
 cache.h| 2 +-
 dir.c  | 6 +++---
 tree-walk.c| 4 ++--
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index b5434af..4a9ee69 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -337,7 +337,7 @@ void overlay_tree_on_cache(const char *tree_name, const 
char *prefix)
matchbuf[0] = prefix;
matchbuf[1] = NULL;
init_pathspec(pathspec, matchbuf);
-   pathspec.items[0].use_wildcard = 0;
+   pathspec.items[0].nowildcard_len = pathspec.items[0].len;
} else
init_pathspec(pathspec, NULL);
if (read_tree(tree, 1, pathspec))
diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
index 235c17c..fb76e38 100644
--- a/builtin/ls-tree.c
+++ b/builtin/ls-tree.c
@@ -168,7 +168,7 @@ int cmd_ls_tree(int argc, const char **argv, const char 
*prefix)
 
init_pathspec(pathspec, get_pathspec(prefix, argv + 1));
for (i = 0; i  pathspec.nr; i++)
-   pathspec.items[i].use_wildcard = 0;
+   pathspec.items[i].nowildcard_len = pathspec.items[i].len;
pathspec.has_wildcard = 0;
tree = parse_tree_indirect(sha1);
if (!tree)
diff --git a/cache.h b/cache.h
index 2b192d2..9304d91 100644
--- a/cache.h
+++ b/cache.h
@@ -482,7 +482,7 @@ struct pathspec {
struct pathspec_item {
const char *match;
int len;
-   unsigned int use_wildcard:1;
+   int nowildcard_len;
} *items;
 };
 
diff --git a/dir.c b/dir.c
index 5a83aa7..c391d46 100644
--- a/dir.c
+++ b/dir.c
@@ -230,7 +230,7 @@ static int match_pathspec_item(const struct pathspec_item 
*item, int prefix,
return MATCHED_RECURSIVELY;
}
 
-   if (item-use_wildcard  !fnmatch(match, name, 0))
+   if (item-nowildcard_len  item-len  !fnmatch(match, name, 0))
return MATCHED_FNMATCH;
 
return 0;
@@ -1429,8 +1429,8 @@ int init_pathspec(struct pathspec *pathspec, const char 
**paths)
 
item-match = path;
item-len = strlen(path);
-   item-use_wildcard = !no_wildcard(path);
-   if (item-use_wildcard)
+   item-nowildcard_len = simple_length(path);
+   if (item-nowildcard_len  item-len)
pathspec-has_wildcard = 1;
}
 
diff --git a/tree-walk.c b/tree-walk.c
index 3f54c02..af871c5 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -626,7 +626,7 @@ enum interesting tree_entry_interesting(const struct 
name_entry *entry,
never_interesting))
return entry_interesting;
 
-   if (item-use_wildcard) {
+   if (item-nowildcard_len  item-len) {
if (!fnmatch(match + baselen, entry-path, 0))
return entry_interesting;
 
@@ -642,7 +642,7 @@ enum interesting tree_entry_interesting(const struct 
name_entry *entry,
}
 
 match_wildcards:
-   if (!item-use_wildcard)
+   if (item-nowildcard_len == item-len)
continue;
 
/*
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 02/21] Add parse_pathspec() that converts cmdline args to struct pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy
Currently to fill a struct pathspec, we do:

   const char **paths;
   paths = get_pathspec(prefix, argv);
   ...
   init_pathspec(pathspec, paths);

paths can only carry bare strings, which loses information from
command line arguments such as pathspec magic or the prefix part's
length for each argument.

parse_pathspec() is introduced to combine the two calls into one. The
plan is gradually replace all get_pathspec() and init_pathspec() with
parse_pathspec(). get_pathspec() now becomes a thin wrapper of
parse_pathspec().

parse_pathspec() allows the caller to reject the pathspec magics that
it does not support. When a new pathspec magic is introduced, we can
enable it per command after making sure that all underlying code has no
problem with the new magic.

flags parameter is currently unused. But it would allow callers to
pass certain instructions to parse_pathspec, for example forcing
literal pathspec when no magic is used.

With the introduction of parse_pathspec, there are now two functions
that can initialize struct pathspec: init_pathspec and
parse_pathspec. Any semantic changes in struct pathspec must be
reflected in both functions. init_pathspec() will be phased out in
favor of parse_pathspec().

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 dir.c   |  2 +-
 dir.h   |  1 +
 setup.c | 99 +
 3 files changed, 77 insertions(+), 25 deletions(-)

diff --git a/dir.c b/dir.c
index c391d46..31f0995 100644
--- a/dir.c
+++ b/dir.c
@@ -291,7 +291,7 @@ int match_pathspec_depth(const struct pathspec *ps,
 /*
  * Return the length of the simple part of a path match limiter.
  */
-static int simple_length(const char *match)
+int simple_length(const char *match)
 {
int len = -1;
 
diff --git a/dir.h b/dir.h
index f5c89e3..1d4888b 100644
--- a/dir.h
+++ b/dir.h
@@ -66,6 +66,7 @@ struct dir_struct {
 #define MATCHED_RECURSIVELY 1
 #define MATCHED_FNMATCH 2
 #define MATCHED_EXACTLY 3
+extern int simple_length(const char *match);
 extern char *common_prefix(const char **pathspec);
 extern int match_pathspec(const char **pathspec, const char *name, int 
namelen, int prefix, char *seen);
 extern int match_pathspec_depth(const struct pathspec *pathspec,
diff --git a/setup.c b/setup.c
index f108c4b..4fcdae6 100644
--- a/setup.c
+++ b/setup.c
@@ -174,7 +174,7 @@ static struct pathspec_magic {
 
 /*
  * Take an element of a pathspec and check for magic signatures.
- * Append the result to the prefix.
+ * Append the result to the prefix. Return the magic bitmap.
  *
  * For now, we only parse the syntax and throw out anything other than
  * top magic.
@@ -185,7 +185,10 @@ static struct pathspec_magic {
  * the prefix part must always match literally, and a single stupid
  * string cannot express such a case.
  */
-static const char *prefix_pathspec(const char *prefix, int prefixlen, const 
char *elt)
+static unsigned prefix_pathspec(struct pathspec_item *item,
+   const char **raw,
+   const char *prefix, int prefixlen,
+   const char *elt)
 {
unsigned magic = 0;
const char *copyfrom = elt;
@@ -241,39 +244,87 @@ static const char *prefix_pathspec(const char *prefix, 
int prefixlen, const char
}
 
if (magic  PATHSPEC_FROMTOP)
-   return xstrdup(copyfrom);
+   item-match = xstrdup(copyfrom);
else
-   return prefix_path(prefix, prefixlen, copyfrom);
+   item-match = prefix_path(prefix, prefixlen, copyfrom);
+   *raw = item-match;
+   item-len = strlen(item-match);
+   item-nowildcard_len = simple_length(item-match);
+   return magic;
 }
 
-const char **get_pathspec(const char *prefix, const char **pathspec)
+static int pathspec_item_cmp(const void *a_, const void *b_)
 {
-   const char *entry = *pathspec;
-   const char **src, **dst;
-   int prefixlen;
+   struct pathspec_item *a, *b;
 
-   if (!prefix  !entry)
-   return NULL;
+   a = (struct pathspec_item *)a_;
+   b = (struct pathspec_item *)b_;
+   return strcmp(a-match, b-match);
+}
+
+/*
+ * Given command line arguments and a prefix, convert the input to
+ * pathspec. die() if any magic other than ones in magic_mask.
+ */
+static void parse_pathspec(struct pathspec *pathspec,
+  unsigned magic_mask, unsigned flags,
+  const char *prefix, const char **argv)
+{
+   struct pathspec_item *item;
+   const char *entry = *argv;
+   int i, n, prefixlen;
+
+   memset(pathspec, 0, sizeof(*pathspec));
+
+   /* No arguments, no prefix - no pathspec */
+   if (!entry  !prefix)
+   return;
 
+   /* No arguments with prefix - prefix pathspec */
if (!entry) {
-   static const char *spec[2];
-   spec[0] = prefix;
-   spec[1] = NULL;
- 

[PATCH 03/21] pathspec: make sure the prefix part is wildcard-clean

2013-01-05 Thread Nguyễn Thái Ngọc Duy
Prefix is the result of Git moving back from current directory to
worktree's top directory and it has to prepend all user provided paths
so that they become relative to the new current directory. Any
wildcards in the prefix should not be treated as such because it's not
the user intention. Make sure all wildcards in the prefix part is
disabled.

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 setup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/setup.c b/setup.c
index 4fcdae6..573ef79 100644
--- a/setup.c
+++ b/setup.c
@@ -250,6 +250,8 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
*raw = item-match;
item-len = strlen(item-match);
item-nowildcard_len = simple_length(item-match);
+   if (item-nowildcard_len  prefixlen)
+   item-nowildcard_len = prefixlen;
return magic;
 }
 
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 04/21] Export parse_pathspec() and convert some get_pathspec() calls

2013-01-05 Thread Nguyễn Thái Ngọc Duy
These call sites follow the pattern:

   paths = get_pathspec(prefix, argv);
   init_pathspec(pathspec, paths);

which can be converted into a single parse_pathspec() call.

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/grep.c | 4 +---
 builtin/ls-tree.c  | 2 +-
 builtin/update-index.c | 3 +--
 cache.h| 6 ++
 revision.c | 4 ++--
 setup.c| 6 +++---
 6 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/builtin/grep.c b/builtin/grep.c
index 0e1b6c8..705f9ff 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -630,7 +630,6 @@ int cmd_grep(int argc, const char **argv, const char 
*prefix)
const char *show_in_pager = NULL, *default_pager = dummy;
struct grep_opt opt;
struct object_array list = OBJECT_ARRAY_INIT;
-   const char **paths = NULL;
struct pathspec pathspec;
struct string_list path_list = STRING_LIST_INIT_NODUP;
int i;
@@ -857,8 +856,7 @@ int cmd_grep(int argc, const char **argv, const char 
*prefix)
verify_filename(prefix, argv[j], j == i);
}
 
-   paths = get_pathspec(prefix, argv + i);
-   init_pathspec(pathspec, paths);
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv + i);
pathspec.max_depth = opt.max_depth;
pathspec.recursive = 1;
 
diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
index fb76e38..a78ba53 100644
--- a/builtin/ls-tree.c
+++ b/builtin/ls-tree.c
@@ -166,7 +166,7 @@ int cmd_ls_tree(int argc, const char **argv, const char 
*prefix)
if (get_sha1(argv[0], sha1))
die(Not a valid object name %s, argv[0]);
 
-   init_pathspec(pathspec, get_pathspec(prefix, argv + 1));
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv + 1);
for (i = 0; i  pathspec.nr; i++)
pathspec.items[i].nowildcard_len = pathspec.items[i].len;
pathspec.has_wildcard = 0;
diff --git a/builtin/update-index.c b/builtin/update-index.c
index ada1dff..6728e59 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -546,10 +546,9 @@ static int do_reupdate(int ac, const char **av,
 */
int pos;
int has_head = 1;
-   const char **paths = get_pathspec(prefix, av + 1);
struct pathspec pathspec;
 
-   init_pathspec(pathspec, paths);
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, av + 1);
 
if (read_ref(HEAD, head_sha1))
/* If there is no HEAD, that means it is an initial
diff --git a/cache.h b/cache.h
index 9304d91..e52365d 100644
--- a/cache.h
+++ b/cache.h
@@ -473,6 +473,9 @@ extern int index_name_is_other(const struct index_state *, 
const char *, int);
 extern int ie_match_stat(const struct index_state *, struct cache_entry *, 
struct stat *, unsigned int);
 extern int ie_modified(const struct index_state *, struct cache_entry *, 
struct stat *, unsigned int);
 
+/* Pathspec magic */
+#define PATHSPEC_FROMTOP(10)
+
 struct pathspec {
const char **raw; /* get_pathspec() result, not freed by 
free_pathspec() */
int nr;
@@ -487,6 +490,9 @@ struct pathspec {
 };
 
 extern int init_pathspec(struct pathspec *, const char **);
+extern void parse_pathspec(struct pathspec *pathspec, unsigned magic,
+  unsigned flags, const char *prefix,
+  const char **args);
 extern void free_pathspec(struct pathspec *);
 extern int ce_path_match(const struct cache_entry *ce, const struct pathspec 
*pathspec);
 
diff --git a/revision.c b/revision.c
index 95d21e6..a044242 100644
--- a/revision.c
+++ b/revision.c
@@ -1851,8 +1851,8 @@ int setup_revisions(int argc, const char **argv, struct 
rev_info *revs, struct s
 */
ALLOC_GROW(prune_data.path, prune_data.nr+1, prune_data.alloc);
prune_data.path[prune_data.nr++] = NULL;
-   init_pathspec(revs-prune_data,
- get_pathspec(revs-prefix, prune_data.path));
+   parse_pathspec(revs-prune_data, PATHSPEC_FROMTOP, 0,
+  revs-prefix, prune_data.path);
}
 
if (revs-def == NULL)
diff --git a/setup.c b/setup.c
index 573ef79..cd6680e 100644
--- a/setup.c
+++ b/setup.c
@@ -268,9 +268,9 @@ static int pathspec_item_cmp(const void *a_, const void *b_)
  * Given command line arguments and a prefix, convert the input to
  * pathspec. die() if any magic other than ones in magic_mask.
  */
-static void parse_pathspec(struct pathspec *pathspec,
-  unsigned magic_mask, unsigned flags,
-  const char *prefix, const char **argv)
+void parse_pathspec(struct pathspec *pathspec,
+   unsigned magic_mask, unsigned flags,
+   const char *prefix, const char **argv)
 {
struct pathspec_item *item;
const char *entry = *argv;
-- 
1.8.0.rc2.23.g1fb49df

--
To 

[PATCH 05/21] clean: convert to use parse_pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/clean.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..788ad8c 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -42,7 +42,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
struct strbuf directory = STRBUF_INIT;
struct dir_struct dir;
-   static const char **pathspec;
+   struct pathspec pathspec;
struct strbuf buf = STRBUF_INIT;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
const char *qname;
@@ -101,12 +101,12 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
add_exclude(exclude_list.items[i].string, , 0,
dir.exclude_list[EXC_CMDL]);
 
-   pathspec = get_pathspec(prefix, argv);
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
 
-   fill_directory(dir, pathspec);
+   fill_directory(dir, pathspec.raw);
 
-   if (pathspec)
-   seen = xmalloc(argc  0 ? argc : 1);
+   if (pathspec.nr)
+   seen = xmalloc(pathspec.nr);
 
for (i = 0; i  dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
@@ -141,10 +141,10 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
if (lstat(ent-name, st))
continue;
 
-   if (pathspec) {
-   memset(seen, 0, argc  0 ? argc : 1);
-   matches = match_pathspec(pathspec, ent-name, len,
-0, seen);
+   if (pathspec.nr) {
+   memset(seen, 0, pathspec.nr);
+   matches = match_pathspec_depth(pathspec, ent-name, 
len,
+  0, seen);
}
 
if (S_ISDIR(st.st_mode)) {
@@ -169,7 +169,7 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
}
strbuf_reset(directory);
} else {
-   if (pathspec  !matches)
+   if (pathspec.nr  !matches)
continue;
qname = quote_path_relative(ent-name, -1, buf, 
prefix);
if (show_only) {
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 06/21] commit: convert to use parse_pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/commit.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index d6dd3df..8410617 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -277,17 +277,18 @@ static char *prepare_index(int argc, const char **argv, 
const char *prefix,
 {
int fd;
struct string_list partial;
-   const char **pathspec = NULL;
+   struct pathspec pathspec;
char *old_index_env = NULL;
int refresh_flags = REFRESH_QUIET;
 
if (is_status)
refresh_flags |= REFRESH_UNMERGED;
-
if (*argv)
-   pathspec = get_pathspec(prefix, argv);
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
+   else
+   memset(pathspec, 0, sizeof(pathspec));
 
-   if (read_cache_preload(pathspec)  0)
+   if (read_cache_preload(pathspec.raw)  0)
die(_(index file corrupt));
 
if (interactive) {
@@ -329,9 +330,9 @@ static char *prepare_index(int argc, const char **argv, 
const char *prefix,
 * (A) if all goes well, commit the real index;
 * (B) on failure, rollback the real index.
 */
-   if (all || (also  pathspec  *pathspec)) {
+   if (all || (also  pathspec.nr)) {
fd = hold_locked_index(index_lock, 1);
-   add_files_to_cache(also ? prefix : NULL, pathspec, 0);
+   add_files_to_cache(also ? prefix : NULL, pathspec.raw, 0);
refresh_cache_or_die(refresh_flags);
update_main_cache_tree(WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
@@ -350,7 +351,7 @@ static char *prepare_index(int argc, const char **argv, 
const char *prefix,
 * and create commit from the_index.
 * We still need to refresh the index here.
 */
-   if (!only  (!pathspec || !*pathspec)) {
+   if (!only  !pathspec.nr) {
fd = hold_locked_index(index_lock, 1);
refresh_cache_or_die(refresh_flags);
if (active_cache_changed) {
@@ -395,7 +396,7 @@ static char *prepare_index(int argc, const char **argv, 
const char *prefix,
 
memset(partial, 0, sizeof(partial));
partial.strdup_strings = 1;
-   if (list_paths(partial, !current_head ? NULL : HEAD, prefix, 
pathspec))
+   if (list_paths(partial, !current_head ? NULL : HEAD, prefix, 
pathspec.raw))
exit(1);
 
discard_cache();
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 07/21] status: convert to use parse_pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/commit.c |  6 +++---
 wt-status.c  | 17 +++--
 wt-status.h  |  2 +-
 3 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 8410617..b706ebb 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1207,10 +1207,10 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
if (show_ignored_in_status)
s.show_ignored_files = 1;
if (*argv)
-   s.pathspec = get_pathspec(prefix, argv);
+   parse_pathspec(s.pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
 
-   read_cache_preload(s.pathspec);
-   refresh_index(the_index, REFRESH_QUIET|REFRESH_UNMERGED, s.pathspec, 
NULL, NULL);
+   read_cache_preload(s.pathspec.raw);
+   refresh_index(the_index, REFRESH_QUIET|REFRESH_UNMERGED, 
s.pathspec.raw, NULL, NULL);
 
fd = hold_locked_index(index_lock, 0);
if (0 = fd)
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..13e6aba 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -434,7 +434,7 @@ static void wt_status_collect_changes_worktree(struct 
wt_status *s)
}
rev.diffopt.format_callback = wt_status_collect_changed_cb;
rev.diffopt.format_callback_data = s;
-   init_pathspec(rev.prune_data, s-pathspec);
+   rev.prune_data = s-pathspec;
run_diff_files(rev, 0);
 }
 
@@ -459,22 +459,20 @@ static void wt_status_collect_changes_index(struct 
wt_status *s)
rev.diffopt.detect_rename = 1;
rev.diffopt.rename_limit = 200;
rev.diffopt.break_opt = 0;
-   init_pathspec(rev.prune_data, s-pathspec);
+   rev.prune_data = s-pathspec;
run_diff_index(rev, 1);
 }
 
 static void wt_status_collect_changes_initial(struct wt_status *s)
 {
-   struct pathspec pathspec;
int i;
 
-   init_pathspec(pathspec, s-pathspec);
for (i = 0; i  active_nr; i++) {
struct string_list_item *it;
struct wt_status_change_data *d;
struct cache_entry *ce = active_cache[i];
 
-   if (!ce_path_match(ce, pathspec))
+   if (!ce_path_match(ce, s-pathspec))
continue;
it = string_list_insert(s-change, ce-name);
d = it-util;
@@ -489,7 +487,6 @@ static void wt_status_collect_changes_initial(struct 
wt_status *s)
else
d-index_status = DIFF_STATUS_ADDED;
}
-   free_pathspec(pathspec);
 }
 
 static void wt_status_collect_untracked(struct wt_status *s)
@@ -505,11 +502,11 @@ static void wt_status_collect_untracked(struct wt_status 
*s)
DIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;
setup_standard_excludes(dir);
 
-   fill_directory(dir, s-pathspec);
+   fill_directory(dir, s-pathspec.raw);
for (i = 0; i  dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
if (cache_name_is_other(ent-name, ent-len) 
-   match_pathspec(s-pathspec, ent-name, ent-len, 0, NULL))
+   match_pathspec_depth(s-pathspec, ent-name, ent-len, 0, 
NULL))
string_list_insert(s-untracked, ent-name);
free(ent);
}
@@ -517,11 +514,11 @@ static void wt_status_collect_untracked(struct wt_status 
*s)
if (s-show_ignored_files) {
dir.nr = 0;
dir.flags = DIR_SHOW_IGNORED | DIR_SHOW_OTHER_DIRECTORIES;
-   fill_directory(dir, s-pathspec);
+   fill_directory(dir, s-pathspec.raw);
for (i = 0; i  dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
if (cache_name_is_other(ent-name, ent-len) 
-   match_pathspec(s-pathspec, ent-name, ent-len, 0, 
NULL))
+   match_pathspec_depth(s-pathspec, ent-name, 
ent-len, 0, NULL))
string_list_insert(s-ignored, ent-name);
free(ent);
}
diff --git a/wt-status.h b/wt-status.h
index 236b41f..dd8df41 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -44,7 +44,7 @@ struct wt_status {
int is_initial;
char *branch;
const char *reference;
-   const char **pathspec;
+   struct pathspec pathspec;
int verbose;
int amend;
enum commit_whence whence;
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 08/21] rerere: convert to use parse_pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/rerere.c | 6 +++---
 rerere.c | 8 
 rerere.h | 4 +++-
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/builtin/rerere.c b/builtin/rerere.c
index dc1708e..a573c4a 100644
--- a/builtin/rerere.c
+++ b/builtin/rerere.c
@@ -68,11 +68,11 @@ int cmd_rerere(int argc, const char **argv, const char 
*prefix)
return rerere(flags);
 
if (!strcmp(argv[0], forget)) {
-   const char **pathspec;
+   struct pathspec pathspec;
if (argc  2)
warning('git rerere forget' without paths is 
deprecated);
-   pathspec = get_pathspec(prefix, argv + 1);
-   return rerere_forget(pathspec);
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv + 
1);
+   return rerere_forget(pathspec);
}
 
fd = setup_rerere(merge_rr, flags);
diff --git a/rerere.c b/rerere.c
index a6a5cd5..f8ddf85 100644
--- a/rerere.c
+++ b/rerere.c
@@ -655,7 +655,7 @@ static int rerere_forget_one_path(const char *path, struct 
string_list *rr)
return 0;
 }
 
-int rerere_forget(const char **pathspec)
+int rerere_forget(struct pathspec *pathspec)
 {
int i, fd;
struct string_list conflict = STRING_LIST_INIT_DUP;
@@ -666,12 +666,12 @@ int rerere_forget(const char **pathspec)
 
fd = setup_rerere(merge_rr, RERERE_NOAUTOUPDATE);
 
-   unmerge_cache(pathspec);
+   unmerge_cache(pathspec-raw);
find_conflict(conflict);
for (i = 0; i  conflict.nr; i++) {
struct string_list_item *it = conflict.items[i];
-   if (!match_pathspec(pathspec, it-string, strlen(it-string),
-   0, NULL))
+   if (!match_pathspec_depth(pathspec, it-string, 
strlen(it-string),
+ 0, NULL))
continue;
rerere_forget_one_path(it-string, merge_rr);
}
diff --git a/rerere.h b/rerere.h
index 156d2aa..4aa06c9 100644
--- a/rerere.h
+++ b/rerere.h
@@ -3,6 +3,8 @@
 
 #include string-list.h
 
+struct pathspec;
+
 #define RERERE_AUTOUPDATE   01
 #define RERERE_NOAUTOUPDATE 02
 
@@ -16,7 +18,7 @@ extern void *RERERE_RESOLVED;
 extern int setup_rerere(struct string_list *, int);
 extern int rerere(int);
 extern const char *rerere_path(const char *hex, const char *file);
-extern int rerere_forget(const char **);
+extern int rerere_forget(struct pathspec *);
 extern int rerere_remaining(struct string_list *);
 extern void rerere_clear(struct string_list *);
 extern void rerere_gc(struct string_list *);
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 09/21] checkout: convert to use parse_pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/checkout.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index a9c1b5a..da25298 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -45,7 +45,7 @@ struct checkout_opts {
 
int branch_exists;
const char *prefix;
-   const char **pathspec;
+   struct pathspec pathspec;
struct tree *source_tree;
 };
 
@@ -256,39 +256,37 @@ static int checkout_paths(const struct checkout_opts 
*opts,
 
if (opts-patch_mode)
return run_add_interactive(revision, --patch=checkout,
-  opts-pathspec);
+  opts-pathspec.raw);
 
lock_file = xcalloc(1, sizeof(struct lock_file));
 
newfd = hold_locked_index(lock_file, 1);
-   if (read_cache_preload(opts-pathspec)  0)
+   if (read_cache_preload(opts-pathspec.raw)  0)
return error(_(corrupt index file));
 
if (opts-source_tree)
-   read_tree_some(opts-source_tree, opts-pathspec);
+   read_tree_some(opts-source_tree, opts-pathspec.raw);
 
-   for (pos = 0; opts-pathspec[pos]; pos++)
-   ;
-   ps_matched = xcalloc(1, pos);
+   ps_matched = xcalloc(1, opts-pathspec.nr);
 
for (pos = 0; pos  active_nr; pos++) {
struct cache_entry *ce = active_cache[pos];
if (opts-source_tree  !(ce-ce_flags  CE_UPDATE))
continue;
-   match_pathspec(opts-pathspec, ce-name, ce_namelen(ce), 0, 
ps_matched);
+   match_pathspec_depth(opts-pathspec, ce-name, ce_namelen(ce), 
0, ps_matched);
}
 
-   if (report_path_error(ps_matched, opts-pathspec, opts-prefix))
+   if (report_path_error(ps_matched, opts-pathspec.raw, opts-prefix))
return 1;
 
/* checkout -m path to recreate conflicted state */
if (opts-merge)
-   unmerge_cache(opts-pathspec);
+   unmerge_cache(opts-pathspec.raw);
 
/* Any unmerged paths? */
for (pos = 0; pos  active_nr; pos++) {
struct cache_entry *ce = active_cache[pos];
-   if (match_pathspec(opts-pathspec, ce-name, ce_namelen(ce), 0, 
NULL)) {
+   if (match_pathspec_depth(opts-pathspec, ce-name, 
ce_namelen(ce), 0, NULL)) {
if (!ce_stage(ce))
continue;
if (opts-force) {
@@ -315,7 +313,7 @@ static int checkout_paths(const struct checkout_opts *opts,
struct cache_entry *ce = active_cache[pos];
if (opts-source_tree  !(ce-ce_flags  CE_UPDATE))
continue;
-   if (match_pathspec(opts-pathspec, ce-name, ce_namelen(ce), 0, 
NULL)) {
+   if (match_pathspec_depth(opts-pathspec, ce-name, 
ce_namelen(ce), 0, NULL)) {
if (!ce_stage(ce)) {
errs |= checkout_entry(ce, state, NULL);
continue;
@@ -960,7 +958,7 @@ static int switch_unborn_to_new_branch(const struct 
checkout_opts *opts)
 static int checkout_branch(struct checkout_opts *opts,
   struct branch_info *new)
 {
-   if (opts-pathspec)
+   if (opts-pathspec.nr)
die(_(paths cannot be used with switching branches));
 
if (opts-patch_mode)
@@ -1110,9 +1108,9 @@ int cmd_checkout(int argc, const char **argv, const char 
*prefix)
}
 
if (argc) {
-   opts.pathspec = get_pathspec(prefix, argv);
+   parse_pathspec(opts.pathspec, PATHSPEC_FROMTOP, 0, prefix, 
argv);
 
-   if (!opts.pathspec)
+   if (!opts.pathspec.nr)
die(_(invalid path specification));
 
/*
@@ -1144,7 +1142,7 @@ int cmd_checkout(int argc, const char **argv, const char 
*prefix)
strbuf_release(buf);
}
 
-   if (opts.patch_mode || opts.pathspec)
+   if (opts.patch_mode || opts.pathspec.nr)
return checkout_paths(opts, new.name);
else
return checkout_branch(opts, new);
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 10/21] rm: convert to use parse_pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/rm.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/builtin/rm.c b/builtin/rm.c
index dabfcf6..d719d95 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -216,7 +216,7 @@ static struct option builtin_rm_options[] = {
 int cmd_rm(int argc, const char **argv, const char *prefix)
 {
int i, newfd;
-   const char **pathspec;
+   struct pathspec pathspec;
char *seen;
 
git_config(git_default_config, NULL);
@@ -249,27 +249,25 @@ int cmd_rm(int argc, const char **argv, const char 
*prefix)
}
}
 
-   pathspec = get_pathspec(prefix, argv);
-   refresh_index(the_index, REFRESH_QUIET, pathspec, NULL, NULL);
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
+   refresh_index(the_index, REFRESH_QUIET, pathspec.raw, NULL, NULL);
 
seen = NULL;
-   for (i = 0; pathspec[i] ; i++)
-   /* nothing */;
-   seen = xcalloc(i, 1);
+   seen = xcalloc(pathspec.nr, 1);
 
for (i = 0; i  active_nr; i++) {
struct cache_entry *ce = active_cache[i];
-   if (!match_pathspec(pathspec, ce-name, ce_namelen(ce), 0, 
seen))
+   if (!match_pathspec_depth(pathspec, ce-name, ce_namelen(ce), 
0, seen))
continue;
ALLOC_GROW(list.entry, list.nr + 1, list.alloc);
list.entry[list.nr].name = ce-name;
list.entry[list.nr++].is_submodule = S_ISGITLINK(ce-ce_mode);
}
 
-   if (pathspec) {
+   if (pathspec.nr) {
const char *match;
int seen_any = 0;
-   for (i = 0; (match = pathspec[i]) != NULL ; i++) {
+   for (i = 0; (match = pathspec.raw[i]) != NULL ; i++) {
if (!seen[i]) {
if (!ignore_unmatch) {
die(_(pathspec '%s' did not match any 
files),
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 11/21] ls-files: convert to use parse_pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/ls-files.c | 42 +++---
 cache.h|  1 +
 dir.c  | 20 
 3 files changed, 32 insertions(+), 31 deletions(-)

diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 4a9ee69..9336abd 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -30,7 +30,7 @@ static int debug_mode;
 static const char *prefix;
 static int max_prefix_len;
 static int prefix_len;
-static const char **pathspec;
+static struct pathspec pathspec;
 static int error_unmatch;
 static char *ps_matched;
 static const char *with_tree;
@@ -58,7 +58,7 @@ static void show_dir_entry(const char *tag, struct dir_entry 
*ent)
if (len = ent-len)
die(git ls-files: internal error - directory entry not 
superset of prefix);
 
-   if (!match_pathspec(pathspec, ent-name, ent-len, len, ps_matched))
+   if (!match_pathspec_depth(pathspec, ent-name, ent-len, len, 
ps_matched))
return;
 
fputs(tag, stdout);
@@ -133,7 +133,7 @@ static void show_ce_entry(const char *tag, struct 
cache_entry *ce)
if (len = ce_namelen(ce))
die(git ls-files: internal error - cache entry not superset of 
prefix);
 
-   if (!match_pathspec(pathspec, ce-name, ce_namelen(ce), len, 
ps_matched))
+   if (!match_pathspec_depth(pathspec, ce-name, ce_namelen(ce), len, 
ps_matched))
return;
 
if (tag  *tag  show_valid_bit 
@@ -187,7 +187,7 @@ static void show_ru_info(void)
len = strlen(path);
if (len  max_prefix_len)
continue; /* outside of the prefix */
-   if (!match_pathspec(pathspec, path, len, max_prefix_len, 
ps_matched))
+   if (!match_pathspec_depth(pathspec, path, len, max_prefix_len, 
ps_matched))
continue; /* uninterested */
for (i = 0; i  3; i++) {
if (!ui-mode[i])
@@ -216,7 +216,7 @@ static void show_files(struct dir_struct *dir)
 
/* For cached/deleted files we don't need to even do the readdir */
if (show_others || show_killed) {
-   fill_directory(dir, pathspec);
+   fill_directory(dir, pathspec.raw);
if (show_others)
show_other_files(dir);
if (show_killed)
@@ -287,21 +287,6 @@ static void prune_cache(const char *prefix)
active_nr = last;
 }
 
-static void strip_trailing_slash_from_submodules(void)
-{
-   const char **p;
-
-   for (p = pathspec; *p != NULL; p++) {
-   int len = strlen(*p), pos;
-
-   if (len  1 || (*p)[len - 1] != '/')
-   continue;
-   pos = cache_name_pos(*p, len - 1);
-   if (pos = 0  S_ISGITLINK(active_cache[pos]-ce_mode))
-   *p = xstrndup(*p, len - 1);
-   }
-}
-
 /*
  * Read the tree specified with --with-tree option
  * (typically, HEAD) into stage #1 and then
@@ -549,23 +534,18 @@ int cmd_ls_files(int argc, const char **argv, const char 
*cmd_prefix)
if (require_work_tree  !is_inside_work_tree())
setup_work_tree();
 
-   pathspec = get_pathspec(prefix, argv);
+   parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
 
/* be nice with submodule paths ending in a slash */
-   if (pathspec)
-   strip_trailing_slash_from_submodules();
+   strip_trailing_slash_from_submodules(pathspec);
 
/* Find common prefix for all pathspec's */
-   max_prefix = common_prefix(pathspec);
+   max_prefix = common_prefix(pathspec.raw);
max_prefix_len = max_prefix ? strlen(max_prefix) : 0;
 
/* Treat unmatching pathspec elements as errors */
-   if (pathspec  error_unmatch) {
-   int num;
-   for (num = 0; pathspec[num]; num++)
-   ;
-   ps_matched = xcalloc(1, num);
-   }
+   if (pathspec.nr  error_unmatch)
+   ps_matched = xcalloc(1, pathspec.nr);
 
if ((dir.flags  DIR_SHOW_IGNORED)  !exc_given)
die(ls-files --ignored needs some exclude pattern);
@@ -592,7 +572,7 @@ int cmd_ls_files(int argc, const char **argv, const char 
*cmd_prefix)
 
if (ps_matched) {
int bad;
-   bad = report_path_error(ps_matched, pathspec, prefix);
+   bad = report_path_error(ps_matched, pathspec.raw, prefix);
if (bad)
fprintf(stderr, Did you forget to 'git add'?\n);
 
diff --git a/cache.h b/cache.h
index e52365d..890d89b 100644
--- a/cache.h
+++ b/cache.h
@@ -493,6 +493,7 @@ extern int init_pathspec(struct pathspec *, const char **);
 extern void parse_pathspec(struct pathspec *pathspec, unsigned magic,
   unsigned flags, const char *prefix,
   const char 

[PATCH 14/21] Convert read_cache_preload() to take struct pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/checkout.c   |  2 +-
 builtin/commit.c |  4 ++--
 builtin/diff-files.c |  2 +-
 builtin/diff-index.c |  2 +-
 builtin/diff.c   |  4 ++--
 cache.h  |  4 +++-
 preload-index.c  | 20 +++-
 7 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index da25298..00910dc 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -261,7 +261,7 @@ static int checkout_paths(const struct checkout_opts *opts,
lock_file = xcalloc(1, sizeof(struct lock_file));
 
newfd = hold_locked_index(lock_file, 1);
-   if (read_cache_preload(opts-pathspec.raw)  0)
+   if (read_cache_preload(opts-pathspec)  0)
return error(_(corrupt index file));
 
if (opts-source_tree)
diff --git a/builtin/commit.c b/builtin/commit.c
index b706ebb..7b5f123 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -288,7 +288,7 @@ static char *prepare_index(int argc, const char **argv, 
const char *prefix,
else
memset(pathspec, 0, sizeof(pathspec));
 
-   if (read_cache_preload(pathspec.raw)  0)
+   if (read_cache_preload(pathspec)  0)
die(_(index file corrupt));
 
if (interactive) {
@@ -1209,7 +1209,7 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
if (*argv)
parse_pathspec(s.pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
 
-   read_cache_preload(s.pathspec.raw);
+   read_cache_preload(s.pathspec);
refresh_index(the_index, REFRESH_QUIET|REFRESH_UNMERGED, 
s.pathspec.raw, NULL, NULL);
 
fd = hold_locked_index(index_lock, 0);
diff --git a/builtin/diff-files.c b/builtin/diff-files.c
index 46085f8..9200069 100644
--- a/builtin/diff-files.c
+++ b/builtin/diff-files.c
@@ -61,7 +61,7 @@ int cmd_diff_files(int argc, const char **argv, const char 
*prefix)
(rev.diffopt.output_format  DIFF_FORMAT_PATCH))
rev.combine_merges = rev.dense_combined_merges = 1;
 
-   if (read_cache_preload(rev.diffopt.pathspec.raw)  0) {
+   if (read_cache_preload(rev.diffopt.pathspec)  0) {
perror(read_cache_preload);
return -1;
}
diff --git a/builtin/diff-index.c b/builtin/diff-index.c
index 1c737f7..ce15b23 100644
--- a/builtin/diff-index.c
+++ b/builtin/diff-index.c
@@ -43,7 +43,7 @@ int cmd_diff_index(int argc, const char **argv, const char 
*prefix)
usage(diff_cache_usage);
if (!cached) {
setup_work_tree();
-   if (read_cache_preload(rev.diffopt.pathspec.raw)  0) {
+   if (read_cache_preload(rev.diffopt.pathspec)  0) {
perror(read_cache_preload);
return -1;
}
diff --git a/builtin/diff.c b/builtin/diff.c
index 8c2af6c..62bdc4d 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -140,7 +140,7 @@ static int builtin_diff_index(struct rev_info *revs,
usage(builtin_diff_usage);
if (!cached) {
setup_work_tree();
-   if (read_cache_preload(revs-diffopt.pathspec.raw)  0) {
+   if (read_cache_preload(revs-diffopt.pathspec)  0) {
perror(read_cache_preload);
return -1;
}
@@ -240,7 +240,7 @@ static int builtin_diff_files(struct rev_info *revs, int 
argc, const char **argv
revs-combine_merges = revs-dense_combined_merges = 1;
 
setup_work_tree();
-   if (read_cache_preload(revs-diffopt.pathspec.raw)  0) {
+   if (read_cache_preload(revs-diffopt.pathspec)  0) {
perror(read_cache_preload);
return -1;
}
diff --git a/cache.h b/cache.h
index 890d89b..7871cd1 100644
--- a/cache.h
+++ b/cache.h
@@ -182,6 +182,8 @@ struct cache_entry {
 #error CE_EXTENDED_FLAGS out of range
 #endif
 
+struct pathspec;
+
 /*
  * Copy the sha1 and stat state of a cache entry from one to
  * another. But we never change the name, or the hash state!
@@ -433,7 +435,7 @@ extern int init_db(const char *template_dir, unsigned int 
flags);
 
 /* Initialize and use the cache information */
 extern int read_index(struct index_state *);
-extern int read_index_preload(struct index_state *, const char **pathspec);
+extern int read_index_preload(struct index_state *, const struct pathspec 
*pathspec);
 extern int read_index_from(struct index_state *, const char *path);
 extern int is_index_unborn(struct index_state *);
 extern int read_index_unmerged(struct index_state *);
diff --git a/preload-index.c b/preload-index.c
index 49cb08d..91f27f7 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -4,7 +4,8 @@
 #include cache.h
 
 #ifdef NO_PTHREADS
-static void preload_index(struct index_state *index, const char **pathspec)
+static void preload_index(struct index_state *index,
+ const 

[PATCH 16/21] checkout: convert read_tree_some to take struct pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/checkout.c | 9 +++--
 tree.c | 4 ++--
 tree.h | 2 +-
 3 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index aa399d6..a7ddb35 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -82,12 +82,9 @@ static int update_some(const unsigned char *sha1, const char 
*base, int baselen,
return 0;
 }
 
-static int read_tree_some(struct tree *tree, const char **pathspec)
+static int read_tree_some(struct tree *tree, const struct pathspec *pathspec)
 {
-   struct pathspec ps;
-   init_pathspec(ps, pathspec);
-   read_tree_recursive(tree, , 0, 0, ps, update_some, NULL);
-   free_pathspec(ps);
+   read_tree_recursive(tree, , 0, 0, pathspec, update_some, NULL);
 
/* update the index with the given tree's info
 * for all args, expanding wildcards, and exit
@@ -265,7 +262,7 @@ static int checkout_paths(const struct checkout_opts *opts,
return error(_(corrupt index file));
 
if (opts-source_tree)
-   read_tree_some(opts-source_tree, opts-pathspec.raw);
+   read_tree_some(opts-source_tree, opts-pathspec);
 
ps_matched = xcalloc(1, opts-pathspec.nr);
 
diff --git a/tree.c b/tree.c
index 62fed63..ff72f67 100644
--- a/tree.c
+++ b/tree.c
@@ -47,7 +47,7 @@ static int read_one_entry_quick(const unsigned char *sha1, 
const char *base, int
 }
 
 static int read_tree_1(struct tree *tree, struct strbuf *base,
-  int stage, struct pathspec *pathspec,
+  int stage, const struct pathspec *pathspec,
   read_tree_fn_t fn, void *context)
 {
struct tree_desc desc;
@@ -116,7 +116,7 @@ static int read_tree_1(struct tree *tree, struct strbuf 
*base,
 
 int read_tree_recursive(struct tree *tree,
const char *base, int baselen,
-   int stage, struct pathspec *pathspec,
+   int stage, const struct pathspec *pathspec,
read_tree_fn_t fn, void *context)
 {
struct strbuf sb = STRBUF_INIT;
diff --git a/tree.h b/tree.h
index 69bcb5e..9dc90ba 100644
--- a/tree.h
+++ b/tree.h
@@ -25,7 +25,7 @@ typedef int (*read_tree_fn_t)(const unsigned char *, const 
char *, int, const ch
 
 extern int read_tree_recursive(struct tree *tree,
   const char *base, int baselen,
-  int stage, struct pathspec *pathspec,
+  int stage, const struct pathspec *pathspec,
   read_tree_fn_t fn, void *context);
 
 extern int read_tree(struct tree *tree, int stage, struct pathspec *pathspec);
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 17/21] Convert report_path_error to take struct pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/checkout.c |  2 +-
 builtin/commit.c   | 14 ++
 builtin/ls-files.c | 14 --
 cache.h|  2 +-
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index a7ddb35..648768e 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -273,7 +273,7 @@ static int checkout_paths(const struct checkout_opts *opts,
match_pathspec_depth(opts-pathspec, ce-name, ce_namelen(ce), 
0, ps_matched);
}
 
-   if (report_path_error(ps_matched, opts-pathspec.raw, opts-prefix))
+   if (report_path_error(ps_matched, opts-pathspec, opts-prefix))
return 1;
 
/* checkout -m path to recreate conflicted state */
diff --git a/builtin/commit.c b/builtin/commit.c
index 7b5f123..71c5afb 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -181,20 +181,18 @@ static int commit_index_files(void)
  * and return the paths that match the given pattern in list.
  */
 static int list_paths(struct string_list *list, const char *with_tree,
- const char *prefix, const char **pattern)
+ const char *prefix, const struct pathspec *pattern)
 {
int i;
char *m;
 
-   if (!pattern)
+   if (!pattern-nr)
return 0;
 
-   for (i = 0; pattern[i]; i++)
-   ;
-   m = xcalloc(1, i);
+   m = xcalloc(1, pattern-nr);
 
if (with_tree) {
-   char *max_prefix = common_prefix(pattern);
+   char *max_prefix = common_prefix(pattern-raw);
overlay_tree_on_cache(with_tree, max_prefix ? max_prefix : 
prefix);
free(max_prefix);
}
@@ -205,7 +203,7 @@ static int list_paths(struct string_list *list, const char 
*with_tree,
 
if (ce-ce_flags  CE_UPDATE)
continue;
-   if (!match_pathspec(pattern, ce-name, ce_namelen(ce), 0, m))
+   if (!match_pathspec_depth(pattern, ce-name, ce_namelen(ce), 0, 
m))
continue;
item = string_list_insert(list, ce-name);
if (ce_skip_worktree(ce))
@@ -396,7 +394,7 @@ static char *prepare_index(int argc, const char **argv, 
const char *prefix,
 
memset(partial, 0, sizeof(partial));
partial.strdup_strings = 1;
-   if (list_paths(partial, !current_head ? NULL : HEAD, prefix, 
pathspec.raw))
+   if (list_paths(partial, !current_head ? NULL : HEAD, prefix, 
pathspec))
exit(1);
 
discard_cache();
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 9336abd..be6e05d 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -349,7 +349,9 @@ void overlay_tree_on_cache(const char *tree_name, const 
char *prefix)
}
 }
 
-int report_path_error(const char *ps_matched, const char **pathspec, const 
char *prefix)
+int report_path_error(const char *ps_matched,
+ const struct pathspec *pathspec,
+ const char *prefix)
 {
/*
 * Make sure all pathspec matched; otherwise it is an error.
@@ -357,7 +359,7 @@ int report_path_error(const char *ps_matched, const char 
**pathspec, const char
struct strbuf sb = STRBUF_INIT;
const char *name;
int num, errors = 0;
-   for (num = 0; pathspec[num]; num++) {
+   for (num = 0; num  pathspec-nr; num++) {
int other, found_dup;
 
if (ps_matched[num])
@@ -367,11 +369,11 @@ int report_path_error(const char *ps_matched, const char 
**pathspec, const char
 * twice.  Do not barf on such a mistake.
 */
for (found_dup = other = 0;
-!found_dup  pathspec[other];
+!found_dup  pathspec-raw[other];
 other++) {
if (other == num || !ps_matched[other])
continue;
-   if (!strcmp(pathspec[other], pathspec[num]))
+   if (!strcmp(pathspec-raw[other], pathspec-raw[num]))
/*
 * Ok, we have a match already.
 */
@@ -380,7 +382,7 @@ int report_path_error(const char *ps_matched, const char 
**pathspec, const char
if (found_dup)
continue;
 
-   name = quote_path_relative(pathspec[num], -1, sb, prefix);
+   name = quote_path_relative(pathspec-raw[num], -1, sb, prefix);
error(pathspec '%s' did not match any file(s) known to git.,
  name);
errors++;
@@ -572,7 +574,7 @@ int cmd_ls_files(int argc, const char **argv, const char 
*cmd_prefix)
 
if (ps_matched) {
int bad;
-   bad = report_path_error(ps_matched, pathspec.raw, prefix);
+   

[PATCH 18/21] Convert refresh_index to take struct pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/add.c| 14 ++
 builtin/commit.c |  2 +-
 builtin/rm.c |  2 +-
 cache.h  |  2 +-
 read-cache.c |  5 +++--
 5 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index af36bc4..623f167 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -180,19 +180,17 @@ static void treat_gitlinks(const char **pathspec)
}
 }
 
-static void refresh(int verbose, const char **pathspec)
+static void refresh(int verbose, const struct pathspec *pathspec)
 {
char *seen;
-   int i, specs;
+   int i;
 
-   for (specs = 0; pathspec[specs];  specs++)
-   /* nothing */;
-   seen = xcalloc(specs, 1);
+   seen = xcalloc(pathspec-nr, 1);
refresh_index(the_index, verbose ? REFRESH_IN_PORCELAIN : 
REFRESH_QUIET,
  pathspec, seen, _(Unstaged changes after refreshing the 
index:));
-   for (i = 0; i  specs; i++) {
+   for (i = 0; i  pathspec-nr; i++) {
if (!seen[i])
-   die(_(pathspec '%s' did not match any files), 
pathspec[i]);
+   die(_(pathspec '%s' did not match any files), 
pathspec-raw[i]);
}
 free(seen);
 }
@@ -437,7 +435,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
 
if (refresh_only) {
-   refresh(verbose, pathspec.raw);
+   refresh(verbose, pathspec);
goto finish;
}
 
diff --git a/builtin/commit.c b/builtin/commit.c
index 71c5afb..193a37e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1208,7 +1208,7 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
parse_pathspec(s.pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
 
read_cache_preload(s.pathspec);
-   refresh_index(the_index, REFRESH_QUIET|REFRESH_UNMERGED, 
s.pathspec.raw, NULL, NULL);
+   refresh_index(the_index, REFRESH_QUIET|REFRESH_UNMERGED, s.pathspec, 
NULL, NULL);
 
fd = hold_locked_index(index_lock, 0);
if (0 = fd)
diff --git a/builtin/rm.c b/builtin/rm.c
index d719d95..b5edde8 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -250,7 +250,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
}
 
parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
-   refresh_index(the_index, REFRESH_QUIET, pathspec.raw, NULL, NULL);
+   refresh_index(the_index, REFRESH_QUIET, pathspec, NULL, NULL);
 
seen = NULL;
seen = xcalloc(pathspec.nr, 1);
diff --git a/cache.h b/cache.h
index 3c34ef5..41e1421 100644
--- a/cache.h
+++ b/cache.h
@@ -511,7 +511,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, 
struct stat *st);
 #define REFRESH_IGNORE_MISSING 0x0008  /* ignore non-existent */
 #define REFRESH_IGNORE_SUBMODULES  0x0010  /* ignore submodules */
 #define REFRESH_IN_PORCELAIN   0x0020  /* user friendly output, not needs 
update */
-extern int refresh_index(struct index_state *, unsigned int flags, const char 
**pathspec, char *seen, const char *header_msg);
+extern int refresh_index(struct index_state *, unsigned int flags, const 
struct pathspec *pathspec, char *seen, const char *header_msg);
 
 struct lock_file {
struct lock_file *next;
diff --git a/read-cache.c b/read-cache.c
index fda78bc..dec2ba6 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1093,7 +1093,8 @@ static void show_file(const char * fmt, const char * 
name, int in_porcelain,
printf(fmt, name);
 }
 
-int refresh_index(struct index_state *istate, unsigned int flags, const char 
**pathspec,
+int refresh_index(struct index_state *istate, unsigned int flags,
+ const struct pathspec *pathspec,
  char *seen, const char *header_msg)
 {
int i;
@@ -1128,7 +1129,7 @@ int refresh_index(struct index_state *istate, unsigned 
int flags, const char **p
continue;
 
if (pathspec 
-   !match_pathspec(pathspec, ce-name, ce_namelen(ce), 0, 
seen))
+   !match_pathspec_depth(pathspec, ce-name, ce_namelen(ce), 
0, seen))
filtered = 1;
 
if (ce_stage(ce)) {
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 19/21] Convert {read,fill}_directory to take struct pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/add.c  |  2 +-
 builtin/clean.c|  2 +-
 builtin/grep.c |  2 +-
 builtin/ls-files.c |  2 +-
 dir.c  | 10 +-
 dir.h  |  4 ++--
 wt-status.c|  4 ++--
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index 623f167..f5ceb5c 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -429,7 +429,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
 
/* This picks up the paths that are not tracked */
-   baselen = fill_directory(dir, pathspec.raw);
+   baselen = fill_directory(dir, pathspec);
if (pathspec.nr)
seen = prune_directory(dir, pathspec.raw, baselen);
}
diff --git a/builtin/clean.c b/builtin/clean.c
index 788ad8c..41c8cad 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -103,7 +103,7 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
 
parse_pathspec(pathspec, PATHSPEC_FROMTOP, 0, prefix, argv);
 
-   fill_directory(dir, pathspec.raw);
+   fill_directory(dir, pathspec);
 
if (pathspec.nr)
seen = xmalloc(pathspec.nr);
diff --git a/builtin/grep.c b/builtin/grep.c
index 705f9ff..f370bad 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -522,7 +522,7 @@ static int grep_directory(struct grep_opt *opt, const 
struct pathspec *pathspec,
if (exc_std)
setup_standard_excludes(dir);
 
-   fill_directory(dir, pathspec-raw);
+   fill_directory(dir, pathspec);
for (i = 0; i  dir.nr; i++) {
const char *name = dir.entries[i]-name;
int namelen = strlen(name);
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index be6e05d..7bb637b 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -216,7 +216,7 @@ static void show_files(struct dir_struct *dir)
 
/* For cached/deleted files we don't need to even do the readdir */
if (show_others || show_killed) {
-   fill_directory(dir, pathspec.raw);
+   fill_directory(dir, pathspec);
if (show_others)
show_other_files(dir);
if (show_killed)
diff --git a/dir.c b/dir.c
index 11e8c1d..cfd9dac 100644
--- a/dir.c
+++ b/dir.c
@@ -72,7 +72,7 @@ char *common_prefix(const char **pathspec)
return len ? xmemdupz(*pathspec, len) : NULL;
 }
 
-int fill_directory(struct dir_struct *dir, const char **pathspec)
+int fill_directory(struct dir_struct *dir, const struct pathspec *pathspec)
 {
size_t len;
 
@@ -80,10 +80,10 @@ int fill_directory(struct dir_struct *dir, const char 
**pathspec)
 * Calculate common prefix for the pathspec, and
 * use that to optimize the directory walk
 */
-   len = common_prefix_len(pathspec);
+   len = common_prefix_len(pathspec-raw);
 
/* Read the directory and prune it */
-   read_directory(dir, pathspec ? *pathspec : , len, pathspec);
+   read_directory(dir, pathspec-nr ? pathspec-raw[0] : , len, 
pathspec);
return len;
 }
 
@@ -1211,14 +1211,14 @@ static int treat_leading_path(struct dir_struct *dir,
return rc;
 }
 
-int read_directory(struct dir_struct *dir, const char *path, int len, const 
char **pathspec)
+int read_directory(struct dir_struct *dir, const char *path, int len, const 
struct pathspec *pathspec)
 {
struct path_simplify *simplify;
 
if (has_symlink_leading_path(path, len))
return dir-nr;
 
-   simplify = create_simplify(pathspec);
+   simplify = create_simplify(pathspec ? pathspec-raw : NULL);
if (!len || treat_leading_path(dir, path, len, simplify))
read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
diff --git a/dir.h b/dir.h
index 1d4888b..b51d2e9 100644
--- a/dir.h
+++ b/dir.h
@@ -74,8 +74,8 @@ extern int match_pathspec_depth(const struct pathspec 
*pathspec,
int prefix, char *seen);
 extern int within_depth(const char *name, int namelen, int depth, int 
max_depth);
 
-extern int fill_directory(struct dir_struct *dir, const char **pathspec);
-extern int read_directory(struct dir_struct *, const char *path, int len, 
const char **pathspec);
+extern int fill_directory(struct dir_struct *dir, const struct pathspec 
*pathspec);
+extern int read_directory(struct dir_struct *, const char *path, int len, 
const struct pathspec *pathspec);
 
 extern int excluded_from_list(const char *pathname, int pathlen, const char 
*basename,
  int *dtype, struct exclude_list *el);
diff --git a/wt-status.c b/wt-status.c
index 13e6aba..2e1a62b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -502,7 +502,7 @@ static void wt_status_collect_untracked(struct wt_status *s)
DIR_SHOW_OTHER_DIRECTORIES | 

[PATCH 20/21] Convert add_files_to_cache to take struct pathspec

2013-01-05 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 builtin/add.c| 8 +---
 builtin/commit.c | 2 +-
 cache.h  | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index f5ceb5c..641037f 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -80,13 +80,15 @@ static void update_callback(struct diff_queue_struct *q,
}
 }
 
-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
+int add_files_to_cache(const char *prefix,
+  const struct pathspec *pathspec, int flags)
 {
struct update_callback_data data;
struct rev_info rev;
init_revisions(rev, prefix);
setup_revisions(0, NULL, rev, NULL);
-   init_pathspec(rev.prune_data, pathspec);
+   if (pathspec)
+   rev.prune_data = *pathspec;
rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = update_callback;
data.flags = flags;
@@ -464,7 +466,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 
plug_bulk_checkin();
 
-   exit_status |= add_files_to_cache(prefix, pathspec.raw, flags);
+   exit_status |= add_files_to_cache(prefix, pathspec, flags);
 
if (add_new_files)
exit_status |= add_files(dir, flags);
diff --git a/builtin/commit.c b/builtin/commit.c
index 193a37e..a3a22b8 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -330,7 +330,7 @@ static char *prepare_index(int argc, const char **argv, 
const char *prefix,
 */
if (all || (also  pathspec.nr)) {
fd = hold_locked_index(index_lock, 1);
-   add_files_to_cache(also ? prefix : NULL, pathspec.raw, 0);
+   add_files_to_cache(also ? prefix : NULL, pathspec, 0);
refresh_cache_or_die(refresh_flags);
update_main_cache_tree(WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
diff --git a/cache.h b/cache.h
index 41e1421..10cba21 100644
--- a/cache.h
+++ b/cache.h
@@ -1224,7 +1224,7 @@ void packet_trace_identity(const char *prog);
  * return 0 if success, 1 - if addition of a file failed and
  * ADD_FILES_IGNORE_ERRORS was specified in flags
  */
-int add_files_to_cache(const char *prefix, const char **pathspec, int flags);
+int add_files_to_cache(const char *prefix, const struct pathspec *pathspec, 
int flags);
 
 /* diff.c */
 extern int diff_auto_refresh_index;
-- 
1.8.0.rc2.23.g1fb49df

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


[PATCH 21/21] Convert more init_pathspec() to parse_pathspec()

2013-01-05 Thread Nguyễn Thái Ngọc Duy
init_pathspec() was introduced to work with the result from
get_pathspec(). init_pathspec() will be removed eventually after
parse_pathspec() takes over, so that there is only place that
initializes struct pathspec.

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 archive.c  |  2 +-
 builtin/log.c  |  2 +-
 builtin/ls-files.c | 10 --
 diff-lib.c |  2 +-
 merge-recursive.c  |  2 +-
 5 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/archive.c b/archive.c
index 530badb..3caa31f 100644
--- a/archive.c
+++ b/archive.c
@@ -218,7 +218,7 @@ static int path_exists(struct tree *tree, const char *path)
struct pathspec pathspec;
int ret;
 
-   init_pathspec(pathspec, paths);
+   parse_pathspec(pathspec, 0, 0, , paths);
ret = read_tree_recursive(tree, , 0, 0, pathspec, reject_entry, 
NULL);
free_pathspec(pathspec);
return ret != 0;
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..495ae77 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -455,7 +455,7 @@ int cmd_show(int argc, const char **argv, const char 
*prefix)
init_grep_defaults();
git_config(git_log_config, NULL);
 
-   init_pathspec(match_all, NULL);
+   memset(match_all, 0, sizeof(match_all));
init_revisions(rev, prefix);
rev.diff = 1;
rev.always_show_header = 1;
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 7bb637b..79949de 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -318,13 +318,11 @@ void overlay_tree_on_cache(const char *tree_name, const 
char *prefix)
}
 
if (prefix) {
-   static const char *(matchbuf[2]);
-   matchbuf[0] = prefix;
-   matchbuf[1] = NULL;
-   init_pathspec(pathspec, matchbuf);
-   pathspec.items[0].nowildcard_len = pathspec.items[0].len;
+   static const char *(matchbuf[1]);
+   matchbuf[0] = NULL;
+   parse_pathspec(pathspec, 0, 0, prefix, matchbuf);
} else
-   init_pathspec(pathspec, NULL);
+   memset(pathspec, 0, sizeof(pathspec));
if (read_tree(tree, 1, pathspec))
die(unable to read tree entries %s, tree_name);
 
diff --git a/diff-lib.c b/diff-lib.c
index f35de0f..9c07f6a 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -500,7 +500,7 @@ int do_diff_cache(const unsigned char *tree_sha1, struct 
diff_options *opt)
struct rev_info revs;
 
init_revisions(revs, NULL);
-   init_pathspec(revs.prune_data, opt-pathspec.raw);
+   revs.prune_data = opt-pathspec;
revs.diffopt = *opt;
 
if (diff_cache(revs, tree_sha1, NULL, 1))
diff --git a/merge-recursive.c b/merge-recursive.c
index d882060..cd95bdb 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -297,7 +297,7 @@ static int get_files_dirs(struct merge_options *o, struct 
tree *tree)
 {
int n;
struct pathspec match_all;
-   init_pathspec(match_all, NULL);
+   memset(match_all, 0, sizeof(match_all));
if (read_tree_recursive(tree, , 0, 0, match_all, save_files_dirs, o))
return 0;
n = o-current_file_set.nr + o-current_directory_set.nr;
-- 
1.8.0.rc2.23.g1fb49df

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


RE: Trying to understand the web dav details

2013-01-05 Thread Jason Pyeron
Ignore everything below, it was a case sensitive typo. It always worked it.

 -Original Message-
 From: Jeff King
 Sent: Sunday, January 06, 2013 0:38
 
 On Sun, Jan 06, 2013 at 04:49:57AM +, Pyeron, Jason J CTR 
 (US) wrote:
 
How does the ?service= get translated in to the action 
performed on the web server?
   
   If you are using the git-http-backend CGI, it will interpret the 
   service
  
  No, using plain jane http and webdav. This server is not 
 allowed to 
  use cgi processes.
 
 Then the service parameter should be ignored by your 
 webserver, and it should just serve the info/refs file from 
 the repository on the filesystem. And you are stuck using 
 WebDAV for push.
 
   GET /git/project-x/info/refs HTTP/1.1
  [...]
  * The requested URL returned error: 404 Not Found
 
 Does the info/refs file exist in the project-x repository?

Yes.

 
  fatal: https://server/git/project-x/info/refs not found: 
 did you run git update-server-info on the server?
 
 Did you?
 

Many times.

 If you can't run any git programs on the server at all (and 
 it sounds like that may be the case), you'll need to run it 
 locally before putting the repository data on the server.
 
 Once you have WebDAV set up for pushing, it will update the 
 info/refs file for each push. But if you are initially 
 seeding the server with rsync or a tarfile, you'll want to 

Seeding it seems to work, it is the bare init that seems to be failing. Might be
on to something there.

 make sure it has an up-to-date info/refs file.

Here is the create script:

#!/bin/bash

if [ $# != 1 ]; then
exit 1;
fi

if [ -e $1 ]; then
exit 2;
fi

mkdir $1
cd $1
git init --bare
cp hooks/post-update.sample hooks/post-update
chmod +x hooks/post-update
git update-server-info




--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

--
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: Version 1.8.1 does not compile on Cygwin 1.7.14

2013-01-05 Thread Jason Pyeron
 -Original Message-
 From: Stephen  Linda Smith 
 Sent: Sunday, January 06, 2013 1:21
 
  Was it the commit before
  9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it 
  9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I 
 am doing a 
  cygwin update presently to look at it.
 
 Since the email earlier today, I had blown away the 
 directory.   I just now 
 did the following
 
 git clone https://github.com/git/git.git git-src  cd 
 git-src  make all
 ...   The make errored out as before
 

No error for me.

 git co 9fca6c  make all
 ...   The make errored out as before

No error for me.

 
 git co 9fca6c^   make all
 ... and this compiles to completion
 
 CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 
 i686 Cygwin

This is old, do you have the luxury of updating it?

 
 What else can I do to test this out (I will get a current 
 cygwin tomorrow to use in a test).

I would also check to see if your devel packages are up to date too.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

--
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] clone: support atomic operation with --separate-git-dir

2013-01-05 Thread Junio C Hamano
Jens Lehmann jens.lehm...@web.de writes:

 Since b57fb80a7d (init, clone: support --separate-git-dir for .git file)
 git clone supports the --separate-git-dir option to create the git dir
 outside the work tree. But when that option is used, the git dir won't be
 deleted in case the clone fails like it would be without this option. This
 makes clone lose its atomicity as in case of a failure a partly set up git
 dir is left behind. A real world example where this leads to problems is
 when git submodule update fails to clone a submodule and later calls to
 git submodule update stumble over the partially set up git dir and try
 to revive the submodule from there, which then fails with a not very user
 friendly error message.

 Fix that by updating the junk_git_dir variable (used to remember if and
 what git dir should be removed in case of failure) to the new value given
 with the --seperate-git-dir option. Also add a test for this to t5600 (and
 while at it fix the former last test to not cd into a directory to test
 for its existence but use test -d instead).

 Reported-by: Manlio Perillo manlio.peri...@gmail.com
 Signed-off-by: Jens Lehmann jens.lehm...@web.de
 ---

I hate to see that git_link is not an argument to init_db() but is a
file-scope static in init-db.c to be used to communicate between
set_git_dir_init() and init_db(), but that would be a separate thing
to be cleaned up, I guess.

How is the file that points at the real git dir removed with this
fix, by the way?

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


Re: [PATCH] Documentation: fix man page dependency on asciidoc.conf

2013-01-05 Thread Junio C Hamano
Jonathan Nieder jrnie...@gmail.com writes:

 John Keeping wrote:

 When building manual pages, the source text is transformed to XML with
 AsciiDoc before the man pages are generated from the XML with xmlto.

 Fix the dependency in the Makefile so that the XML files are rebuilt
 when asciidoc.conf changes and not just the manual pages from unchanged
 XML.

 Good catch, thanks.

 Would something like the following make sense, to make it more obvious
 how the dependency needs to be adjusted if we change the $(ASCIIDOC)
 command line for some reason?

I think such a more explicit approach is easier to understand, than
a separate By the way, I do not define any rule to build these
targets using asciidoc.conf, but I know they depend on it rule.

Care to do a real patch?

Thanks.


 diff --git i/Documentation/Makefile w/Documentation/Makefile
 index e53d333e..971977b8 100644
 --- i/Documentation/Makefile
 +++ w/Documentation/Makefile
 @@ -178,8 +178,6 @@ all: html man
  
  html: $(DOC_HTML)
  
 -$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf
 -
  man: man1 man5 man7
  man1: $(DOC_MAN1)
  man5: $(DOC_MAN5)
 @@ -257,7 +255,7 @@ clean:
   $(RM) $(cmds_txt) *.made
   $(RM) manpage-base-url.xsl
  
 -$(MAN_HTML): %.html : %.txt
 +$(MAN_HTML): %.html : %.txt asciidoc.conf
   $(QUIET_ASCIIDOC)$(RM) $@+ $@  \
   $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
   $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $  \
 @@ -270,7 +268,7 @@ manpage-base-url.xsl: manpage-base-url.xsl.in
   $(QUIET_XMLTO)$(RM) $@  \
   $(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $
  
 -%.xml : %.txt
 +%.xml : %.txt asciidoc.conf
   $(QUIET_ASCIIDOC)$(RM) $@+ $@  \
   $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
   $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $  \
 @@ -286,7 +284,7 @@ technical/api-index.txt: technical/api-index-skel.txt \
   $(QUIET_GEN)cd technical  '$(SHELL_PATH_SQ)' ./api-index.sh
  
  technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
 -$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : 
 %.txt
 +$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : 
 %.txt asciidoc.conf
   $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
   $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
  
 diff --git i/t/test-terminal.perl w/t/test-terminal.perl
 index 10172aee..1fb373f2 100755
 --- i/t/test-terminal.perl
 +++ w/t/test-terminal.perl
 @@ -31,7 +31,7 @@ sub finish_child {
   } elsif ($?  127) {
   my $code = $?  127;
   warn died of signal $code;
 - return $code - 128;
 + return $code + 128;
   } else {
   return $?  8;
   }
--
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] archive-tar: split long paths more carefully

2013-01-05 Thread Junio C Hamano
René Scharfe rene.scha...@lsrfire.ath.cx writes:

 The name field of a tar header has a size of 100 characters.  This limit
 was extended long ago in a backward compatible way by providing the
 additional prefix field, which can hold 155 additional characters.  The
 actual path is constructed at extraction time by concatenating the prefix
 field, a slash and the name field.

 get_path_prefix() is used to determine which slash in the path is used as
 the cutting point and thus which part of it is placed into the field
 prefix and which into the field name.  It tries to cram as much into the
 prefix field as possible.  (And only if we can't fit a path into the
 provided 255 characters we use a pax extended header to store it.)

 If a path is longer than 100 but shorter than 156 characters and ends
 with a slash (i.e. is for a directory) then get_path_prefix() puts the
 whole path in the prefix field and leaves the name field empty.  GNU tar
 reconstructs the path without complaint, but the tar included with
 NetBSD 6 does not: It reports the header to be invalid.

 For compatibility with this version of tar, make sure to never leave the
 name field empty.  In order to do that, trim the trailing slash from the
 part considered as possible prefix, if it exists -- that way the last
 path component (or more, but not less) will end up in the name field.

Nicely explained; thanks.

Makes me wonder what we should do for a file inside a directory
whose name is 10 bytes long, and whose filename is 120 bytes long,
though.

Sounds like people on NetBSD are SOL due to the 155+'/'+100 in such
a case and there is nothing we can do, I guess.

 Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
 ---
  archive-tar.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/archive-tar.c b/archive-tar.c
 index 0ba3f25..923daf5 100644
 --- a/archive-tar.c
 +++ b/archive-tar.c
 @@ -153,6 +153,8 @@ static unsigned int ustar_header_chksum(const struct 
 ustar_header *header)
  static size_t get_path_prefix(const char *path, size_t pathlen, size_t 
 maxlen)
  {
   size_t i = pathlen;
 + if (i  1  path[i - 1] == '/')
 + i--;
   if (i  maxlen)
   i = maxlen;
   do {
--
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] run-command: encode signal death as a positive integer

2013-01-05 Thread Junio C Hamano
Jeff King p...@peff.net writes:

 On Sat, Jan 05, 2013 at 09:03:16AM -0500, Jeff King wrote:
 ...
 The downside is that callers of run_command can no longer
 differentiate between a signal received directly by the
 sub-process, and one propagated. However, no caller
 currently cares, and since we already optimize out some
 calls to the shell under the hood, that distinction is not
 something that should be relied upon by callers.

 Signed-off-by: Jeff King p...@peff.net
 ---

Very nicely explained.  Thanks.

  Documentation/technical/api-run-command.txt | 6 ++
  editor.c| 2 +-
  run-command.c   | 2 +-
  3 files changed, 4 insertions(+), 6 deletions(-)

 diff --git a/Documentation/technical/api-run-command.txt 
 b/Documentation/technical/api-run-command.txt
 index f18b4f4..5d7d7f2 100644
 --- a/Documentation/technical/api-run-command.txt
 +++ b/Documentation/technical/api-run-command.txt
 @@ -55,10 +55,8 @@ The functions above do the following:
non-zero.
  
  . If the program terminated due to a signal, then the return value is the
 -  signal number - 128, ie. it is negative and so indicates an unusual
 -  condition; a diagnostic is printed. This return value can be passed to
 -  exit(2), which will report the same code to the parent process that a
 -  POSIX shell's $? would report for a program that died from the signal.
 +  signal number + 128, ie. the same value that a POSIX shell's $? would
 +  report.  A diagnostic is printed.
  
  
  `start_async`::
 diff --git a/editor.c b/editor.c
 index 065a7ab..27bdecd 100644
 --- a/editor.c
 +++ b/editor.c
 @@ -51,7 +51,7 @@ int launch_editor(const char *path, struct strbuf *buffer, 
 const char *const *en
   sigchain_push(SIGINT, SIG_IGN);
   sigchain_push(SIGQUIT, SIG_IGN);
   ret = finish_command(p);
 - sig = ret + 128;
 + sig = ret - 128;
   sigchain_pop(SIGINT);
   sigchain_pop(SIGQUIT);
   if (sig == SIGINT || sig == SIGQUIT)
 diff --git a/run-command.c b/run-command.c
 index 757f263..cfb7274 100644
 --- a/run-command.c
 +++ b/run-command.c
 @@ -249,7 +249,7 @@ static int wait_or_whine(pid_t pid, const char *argv0)
* mimics the exit code that a POSIX shell would report for
* a program that died from this signal.
*/
 - code -= 128;
 + code += 128;
   } else if (WIFEXITED(status)) {
   code = WEXITSTATUS(status);
   /*
--
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] Alphabetize the fast-import options, following a suggestion on the list.

2013-01-05 Thread Junio C Hamano
Jonathan Nieder jrnie...@gmail.com writes:

 My knee-jerk response was If the options are currently organized logically,
 wouldn't it be more appropriate to add a sub-heading for each group of options
 and alphabetize only within the subgroups?

 But in fact the current options list doesn't seem to be well organized at all.
 What do you think would be a logical way to group these?

  Features of input syntax

   --date-format
   --done

  Verbosity

   --quiet
   --stats

  Marks handling (checkpoint/restore)

   --import-marks
   --import-marks-if-exists
   --export-marks
   --relative-marks

  Semantics of execution

   --dry-run
   --force
   --cat-blob-fd
   --export-pack-edges

  Tuning

   --active-branches
   --max-pack-size
   --big-file-threshold
   --depth

Sounds sensible.
--
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: Version 1.8.1 does not compile on Cygwin 1.7.14

2013-01-05 Thread Torsten Bögershausen
On 06.01.13 07:29, Jason Pyeron wrote:
 -Original Message-
 From: Stephen  Linda Smith 
 Sent: Sunday, January 06, 2013 1:21

 Was it the commit before
 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it 
 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I 
 am doing a 
 cygwin update presently to look at it.

 Since the email earlier today, I had blown away the 
 directory.   I just now 
 did the following

 git clone https://github.com/git/git.git git-src  cd 
 git-src  make all
 ...   The make errored out as before

 
 No error for me.
 
 git co 9fca6c  make all
 ...   The make errored out as before
 
 No error for me.
 

 git co 9fca6c^   make all
 ... and this compiles to completion

 CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 
 i686 Cygwin
 
 This is old, do you have the luxury of updating it?
 

 What else can I do to test this out (I will get a current 
 cygwin tomorrow to use in a test).
 
 I would also check to see if your devel packages are up to date too.

You can either upgrade to cygwin 1.17 or higher.
Or, if that is really not possible (because you are sitting on a production 
machine,
where no changes are allowed),

You can enable this in Makefile: 
CYGWIN_V15_WIN32API = YesPlease

HTH
/Torsten



--
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] SubmittingPatches: Document how to request a patch review tag

2013-01-05 Thread Michael Haggerty
On 01/04/2013 09:58 PM, Jason Holden wrote:
 Document the preferred way a developer should request to have their
 Acked-by/Tested-by/Reviewed-by tag to a patch series under discussion
 
 Signed-off-by: Jason Holden jason.k.holden.sw...@gmail.com
 ---
 Junio,
   I was ready to add my Reviewed-by to this patch series, but I wasn't sure if
 I should email just you the patch author (to cut down on overall list traffic)
 or both you and the list.  If all reviewed-by/acked-by/tested-by traffic 
 should go via the email list I think this patch would be helpful, as I 
 wasn't quite sure how wide of a distribution list to use for my 
 Reviewed-by email.
 
 A very similiar question was asked previously in:
 http://thread.gmane.org/gmane.comp.version-control.git/185564/focus=185570

On 01/04/2013 10:47 PM, Junio C Hamano wrote:
 Reviewed-by is for those who are familiar with the part of the
 system being touched to say I reviewed this patch, it looks good,
 and Michael indeed was involved in recent updates to the refs.c
 infrastructure, so as he said in his message it looks like I should,
 it was the right thing to do.

 I do not think Michael was asking if that was the standard _thing_
 to do; I think the question was if there was a standard _way_
 (perhaps a tool) to send such a Reviewed-by: line.

Junio is correct; I was just asking whether there was a particular email
convention for adding a Reviewed-by: line.  It would be nice for this
to be mentioned in the documentation.

  Documentation/SubmittingPatches | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
 index f6276ff..80001c9 100644
 --- a/Documentation/SubmittingPatches
 +++ b/Documentation/SubmittingPatches
 @@ -268,6 +268,11 @@ If you like, you can put extra tags at the end:
  4. Tested-by: is used to indicate that the person applied the patch
 and found it to have the desired effect.
  
 +If you are a reviewer and wish to add your Acked-by/Reviewed-by/Tested-by tag
 +to a patch series under discussion (after having reviewed it or tested it
 +of course!), reply to the author of the patch series, cc'ing the git mailing
 +list.
 +
  You can also create your own tag or use one that's in common usage
  such as Thanks-to:, Based-on-patch-by:, or Mentored-by:.

I don't think this is quite correct.  Such emails should be
reply-to-all people who have participated in the thread, which might
include more than just the patch author and the git mailing list.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html