date:20130923

Thanks.

On Sun, Sep 22, 2013 at 10:43 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Brandon Casey wrote:
 Ensure buffer length is non-zero before attempting to access the last
 element.

 Signed-off-by: Brandon Casey draf...@gmail.com
 ---
  contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
 b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
 index 1081224..8ae2eab 100644
 --- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
 +++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
 @@ -315,7 +315,7 @@ static int credential_read(struct credential *c)
   {
   line_len = strlen(buf);

 - if(buf[line_len-1]=='\n')
 + if(line_len  buf[line_len-1] == '\n')

 The style is if ().

 --
 Felipe Contreras
--
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/15] Make Gnome Credential helper more Gnome-y and support ancient distros

On Mon, Sep 23, 2013 at 3:20 AM, John Szakmeister j...@szakmeister.net wrote:
 On Sun, Sep 22, 2013 at 10:07:56PM -0700, Brandon Casey wrote:
 A few cleanups, followed by improved usage of the glib library (no need
 to reinvent the wheel when glib provides the necessary functionality), and
 then the addition of support for RHEL 4.x and 5.x.

 Brandon Casey (15):
snip

 I reviewed all of the commits in this series, and most are nice
 cleanups.  The only thing I'm a little shaky on is RHEL4
 support (patch 15).  In particular, this:

 +/*
 + * Just a guess to support RHEL 4.X.
 + * Glib 2.8 was roughly Gnome 2.12 ?
 + * Which was released with gnome-keyring 0.4.3 ??
 + */

 Has that code been tested on RHEL4 at all?  I imagine it's hard
 to come by--it's pretty darn old--but it feels like a mistake to
 commit untested code.

The (poorly worded) comment is referring to the version of glib that
is being tested by the pre-processor statements.  Since gnome-keyring
doesn't provide a way to test its version, and I'm not sure exactly
which gnome release included gnome-keyring 0.4.3 or which glib version
was distributed with which gnome version, I'm just roughly guessing
based on dates and not-conclusive google searches that 2.8 is
reasonable.

I'll try to clarify the wording here.

The code has been tested on CentOS 4.X.

 Otherwise, there are a few stylistic nits that I'd like to clean
 up.  Only one was introduced by you--Felipe pointed it out--and

Well, not exactly introduced by me, but I guess I can fix it in that
same patch. :)

 I have a patch for the rest that I can submit after your series
 has been applied.

Sounds good.

 Acked-by: John Szakmeister j...@szakmeister.net

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

[PATCH v2] git-remote-mediawiki: bugfix for pages w/ 500 revisions

2013-09-23 Thread Benoit Person

Mediawiki introduces a new API for queries w/ more than 500 results in
version 1.21. That change triggered an infinite loop while cloning a
mediawiki with such a page.

The latest API renamed and moved the continuing information in the
response, necessary to build the next query. The code failed to retrieve
that information but still detected that it was in a continuing
query. As a result, it launched the same query over and over again.

If a continuing information is detected in the response (old or new),
the next query is updated accordingly. If not, we quit assuming it's not
a continuing query.

Signed-off-by: Benoit Person benoit.per...@gmail.fr
Reported-by: Benjamin Cathey
---
 contrib/mw-to-git/git-remote-mediawiki.perl | 14 --
 contrib/mw-to-git/t/t9365-continuing-queries.sh | 24 
 2 files changed, 36 insertions(+), 2 deletions(-)
 create mode 100755 contrib/mw-to-git/t/t9365-continuing-queries.sh

diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl 
b/contrib/mw-to-git/git-remote-mediawiki.perl
index c9a4805..f1db5d2 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -625,6 +625,9 @@ sub fetch_mw_revisions_for_page {
rvstartid = $fetch_from,
rvlimit = 500,
pageids = $id,
+
+   # let the mediawiki know that we support the latest API
+   continue = '',
};
 
my $revnum = 0;
@@ -640,8 +643,15 @@ sub fetch_mw_revisions_for_page {
push(@page_revs, $page_rev_ids);
$revnum++;
}
-   last if (!$result-{'query-continue'});
-   $query-{rvstartid} = 
$result-{'query-continue'}-{revisions}-{rvstartid};
+
+   if ($result-{'query-continue'}) { # For legacy APIs
+   $query-{rvstartid} = 
$result-{'query-continue'}-{revisions}-{rvstartid};
+   } elsif ($result-{continue}) { # For newer APIs
+   $query-{rvstartid} = $result-{continue}-{rvcontinue};
+   $query-{continue} = $result-{continue}-{continue};
+   } else {
+   last;
+   }
}
if ($shallow_import  @page_revs) {
print {*STDERR}   Found 1 revision (shallow import).\n;
diff --git a/contrib/mw-to-git/t/t9365-continuing-queries.sh 
b/contrib/mw-to-git/t/t9365-continuing-queries.sh
new file mode 100755
index 000..6fb5df4
--- /dev/null
+++ b/contrib/mw-to-git/t/t9365-continuing-queries.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+test_description='Test the Git Mediawiki remote helper: queries w/ more than 
500 results'
+
+. ./test-gitmw-lib.sh
+. ./push-pull-tests.sh
+. $TEST_DIRECTORY/test-lib.sh
+
+test_check_precond
+
+test_expect_success 'creating page w/ 500 revisions' '
+   wiki_reset 
+   for i in $(seq 1 501)
+   do
+   echo creating revision $i
+   wiki_editpage foo revision $ibr/ true
+   done
+'
+
+test_expect_success 'cloning page w/ 500 revisions' '
+   git clone mediawiki::'$WIKI_URL' mw_dir
+'
+
+test_done
-- 
1.8.4.GIT

--
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-remote-mediawiki: bugfix for pages w/ 500 revisions

Matthieu Moy wrote:
 Benoit Person benoit.per...@gmail.com writes:

 For now, if the tests suite is run without the fix, the new test
 introduces an infinite loop. I am not sure if this should be handled ?
 (a timeout of some kind maybe ?)

 If the patch fix this, then it's not a really big problem. The test
 failure is an infinite loop.

Yes, I think it's fine.

  That would be problematic if ran
 non-interactively, but I think it's Ok since we only run the testsuite
 manually.

Some distros (e.g., Debian) occasionally do run the testsuite
automatically, but it is still fine since they have a timeout that
varies by platform to detect if the test has stalled.  I suppose
ideally git's test harness could learn to do the same thing some day,
but for now it's easier one level above since an appropriate timeout
depends on the speed on the platform, what else is creating load on
the test machine, and other factors that are probably not easy for us
to guess.

(other tweaks snipped)

Thanks, both.
--
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/RFC 0/7] Support for Ruby

2013-09-23 Thread Patrick Donnelly

Hello Felipe,

On Sun, Sep 22, 2013 at 4:29 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sun, Sep 22, 2013 at 3:12 AM, Fredrik Gustafsson iv...@iveqy.com wrote:
And see my humble test of what the speedup would be for git-submodule
even with a faulty lua integration (still forking... but huge
performance boost anyway):
http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051

I don't see how that is relevant, but I'm certain the same can be done
with Ruby.

As you can see a lua integration would increase the git binary with
300kb.

And my patch would increase it 49Kb.

Unless you statically compile in Ruby (which is what the above quoted
300kb implied for Lua, in actually it is less than 200kb). [Also good
luck statically compiling Python/Ruby into an executable.]

IMO the problem with lua is that it's too simple, it's syntax doesn't
resemble c, perl, python, shell, or ruby, it's just weird. Also, it's
much less popular, it's not as powerful, and there isn't a big
community involved with Git like with Ruby.

*sigh*. At this point you've really cemented your purpose here as a
language evangelist. It's unfortunate I have to reply to dismiss this
FUD (which you complained about earlier, ironically) otherwise
community accepts it as fact (oh, I remember some guys saying Lua was
a language for idiots...).

Lua is by no means *simple*. Try small or lightweight. Its syntax
is engineered to be readable and amateur friendly. You've placed Ruby
on a pedestal alongside those other major languages but its syntax
doesn't resemble any of those.

Also, it's much less popular

https://sites.google.com/site/marbux/home/where-lua-is-used

The hallmark of a good embedded language is your users don't even know
it is there.

it's not as powerful,

This is really funny to me. Despite Lua's small size, it has lead the
way for modern dynamic language features, such as coroutines, block
level scoping and real closure, incremental GC, a simple and usable C
API (*yes* this is a feature), and a register based VM [1]. It is
consistently placed as the *fastest* dynamic language in existence
[e.g. 2]? The LuaJIT compiler often achieves competitive or better
performance than C [3]. What about this isn't powerful?

[1] Ierusalimschy, Roberto, Luiz Henrique De Figueiredo, and Waldemar
Celes Filho. The Implementation of Lua 5.0. J. UCS 11.7 (2005):
1159-1176.
[2]
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=alllang=lualang2=yarvdata=u32
[3] http://luajit.org/performance_x86.html

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

[PATCH v2 00/16] Make Gnome Credential helper more Gnome-y and support ancient distros

From: Brandon Casey draf...@gmail.com

Mostly unchanged.

Inserts a patch to fix the style issues for block statements.
i.e. use if () instead of if()

A couple early patches were reordered to improve logical flow.

Updated the comment in the last patch to hopefully improve clarity
wrt RHEL 4.X

The only functional change is in 14/16 report failure to store.
We should accept GNOME_KEYRING_RESULT_CANCELLED as a successful
return and _not_ produce an error message.

Interdiff follows...

Brandon Casey (16):
  contrib/git-credential-gnome-keyring.c: remove unnecessary
pre-declarations
  contrib/git-credential-gnome-keyring.c: remove unused die() function
  contrib/git-credential-gnome-keyring.c: *style* use if () not if()
etc.
  contrib/git-credential-gnome-keyring.c: add static where applicable
  contrib/git-credential-gnome-keyring.c: exit non-zero when called
incorrectly
  contrib/git-credential-gnome-keyring.c: strlen() returns size_t, not
ssize_t
  contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty
before accessing
  contrib/git-credential-gnome-keyring.c: set Gnome application name
  contrib/git-credential-gnome-keyring.c: use gnome helpers in
keyring_object()
  contrib/git-credential-gnome-keyring.c: use secure memory functions
for passwds
  contrib/git-credential-gnome-keyring.c: use secure memory for reading
passwords
  contrib/git-credential-gnome-keyring.c: use glib memory allocation
functions
  contrib/git-credential-gnome-keyring.c: use glib messaging functions
  contrib/git-credential-gnome-keyring.c: report failure to store
password
  contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring
  contrib/git-credential-gnome-keyring.c: support really ancient
gnome-keyring

 contrib/credential/gnome-keyring/Makefile  |   4 +-
 .../gnome-keyring/git-credential-gnome-keyring.c   | 301 -
 2 files changed, 169 insertions(+), 136 deletions(-)

---

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index ce2ddee..635c96b 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -50,7 +50,7 @@
 
 /*
  * ancient gnome-keyring returns DENIED when an entry is not found.
- * Setting NO_MATCH to DENIED will prevent us from reporting denied
+ * Setting NO_MATCH to DENIED will prevent us from reporting DENIED
  * errors during get and erase operations, but we will still report
  * DENIED errors during a store.
  */
@@ -87,8 +87,8 @@ static const char* 
gnome_keyring_result_to_message(GnomeKeyringResult result)
 }
 
 /*
- * Just a guess to support RHEL 4.X.
- * Glib 2.8 was roughly Gnome 2.12 ?
+ * Support really ancient gnome-keyring, circ. RHEL 4.X.
+ * Just a guess for the Glib version.  Glib 2.8 was roughly Gnome 2.12 ?
  * Which was released with gnome-keyring 0.4.3 ??
  */
 #if GLIB_MAJOR_VERSION == 2  GLIB_MINOR_VERSION  8
@@ -162,7 +162,7 @@ static char* keyring_object(struct credential *c)
if (!c-path)
return NULL;
 
-   if(c-port)
+   if (c-port)
return g_strdup_printf(%s:%hd/%s, c-host, c-port, c-path);
 
return g_strdup_printf(%s/%s, c-host, c-path);
@@ -251,7 +251,8 @@ static int keyring_store(struct credential *c)
 
g_free(object);
 
-   if (result != GNOME_KEYRING_RESULT_OK) {
+   if (result != GNOME_KEYRING_RESULT_OK 
+   result != GNOME_KEYRING_RESULT_CANCELLED) {
g_critical(%s, gnome_keyring_result_to_message(result));
return EXIT_FAILURE;
}
@@ -363,14 +364,14 @@ static int credential_read(struct credential *c)
{
line_len = strlen(buf);
 
-   if(line_len  buf[line_len-1] == '\n')
+   if (line_len  buf[line_len-1] == '\n')
buf[--line_len]='\0';
 
-   if(!line_len)
+   if (!line_len)
break;
 
value = strchr(buf,'=');
-   if(!value) {
+   if (!value) {
g_warning(invalid credential line: %s, key);
gnome_keyring_memory_free(buf);
return -1;
@@ -432,9 +433,9 @@ static void usage(const char *name)
 
basename = (basename) ? basename + 1 : name;
fprintf(stderr, usage: %s , basename);
-   while(try_op-name) {
+   while (try_op-name) {
fprintf(stderr,%s,(try_op++)-name);
-   if(try_op-name)
+   if (try_op-name)
fprintf(stderr,%s,|);
}
fprintf(stderr,%s,\n);
@@ -455,15 +456,15 @@ int main(int argc, char *argv[])
g_set_application_name(Git Credential Helper);
 
/* lookup operation callback */
-   while(try_op-name  strcmp(argv[1], try_op-name))
+   while

[PATCH v2 02/16] contrib/git-credential-gnome-keyring.c: remove unused die() function

From: Brandon Casey draf...@gmail.com

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../credential/gnome-keyring/git-credential-gnome-keyring.c| 10 --
 1 file changed, 10 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 15b0a1c..4334f23 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -91,16 +91,6 @@ static inline void error(const char *fmt, ...)
va_end(ap);
 }
 
-static inline void die(const char *fmt, ...)
-{
-   va_list ap;
-
-   va_start(ap,fmt);
-   error(fmt, ap);
-   va_end(ap);
-   exit(EXIT_FAILURE);
-}
-
 static inline void die_errno(int err)
 {
error(%s, strerror(err));
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 10/16] contrib/git-credential-gnome-keyring.c: use secure memory functions for passwds

From: Brandon Casey draf...@gmail.com

gnome-keyring provides functions for allocating non-pageable memory (if
possible) intended to be used for storing passwords.  Let's use them.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../gnome-keyring/git-credential-gnome-keyring.c| 21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index b692e1f..d8a7038 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -30,6 +30,7 @@
 #include errno.h
 #include glib.h
 #include gnome-keyring.h
+#include gnome-keyring-memory.h
 
 /*
  * This credential struct and API is simplified from git's credential.{h,c}
@@ -60,16 +61,6 @@ struct credential_operation
 
 /*  common helper functions - */
 
-static inline void free_password(char *password)
-{
-   char *c = password;
-   if (!password)
-   return;
-
-   while (*c) *c++ = '\0';
-   free(password);
-}
-
 static inline void warning(const char *fmt, ...)
 {
va_list ap;
@@ -159,8 +150,8 @@ static int keyring_get(struct credential *c)
/* pick the first one from the list */
password_data = (GnomeKeyringNetworkPasswordData *) entries-data;
 
-   free_password(c-password);
-   c-password = xstrdup(password_data-password);
+   gnome_keyring_memory_free(c-password);
+   c-password = gnome_keyring_memory_strdup(password_data-password);
 
if (!c-username)
c-username = xstrdup(password_data-user);
@@ -291,7 +282,7 @@ static void credential_clear(struct credential *c)
free(c-host);
free(c-path);
free(c-username);
-   free_password(c-password);
+   gnome_keyring_memory_free(c-password);
 
credential_init(c);
 }
@@ -338,8 +329,8 @@ static int credential_read(struct credential *c)
free(c-username);
c-username = xstrdup(value);
} else if (!strcmp(key, password)) {
-   free_password(c-password);
-   c-password = xstrdup(value);
+   gnome_keyring_memory_free(c-password);
+   c-password = gnome_keyring_memory_strdup(value);
while (*value) *value++ = '\0';
}
/*
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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.txt: Fix asciidoc syntax of --*-pathspecs

2013-09-23 Thread Steffen Prohaska

Labeled lists require a double colon.

Signed-off-by: Steffen Prohaska proha...@zib.de
---
 Documentation/git.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5d68d33..4c2757e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -475,19 +475,19 @@ example the following invocations are equivalent:
This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
variable to `1`.
 
---glob-pathspecs:
+--glob-pathspecs::
Add glob magic to all pathspec. This is equivalent to setting
the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling
globbing on individual pathspecs can be done using pathspec
magic :(literal)
 
---noglob-pathspecs:
+--noglob-pathspecs::
Add literal magic to all pathspec. This is equivalent to setting
the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling
globbing on individual pathspecs can be done using pathspec
magic :(glob)
 
---icase-pathspecs:
+--icase-pathspecs::
Add icase magic to all pathspec. This is equivalent to setting
the `GIT_ICASE_PATHSPECS` environment variable to `1`.
 
-- 
1.8.4.477.gfa286b2

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

[PATCH v2 03/16] contrib/git-credential-gnome-keyring.c: style use if () not if() etc.

From: Brandon Casey draf...@gmail.com

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../gnome-keyring/git-credential-gnome-keyring.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 4334f23..809b1b7 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -117,10 +117,10 @@ static char* keyring_object(struct credential *c)
return object;
 
object = (char*) malloc(strlen(c-host)+strlen(c-path)+8);
-   if(!object)
+   if (!object)
die_errno(errno);
 
-   if(c-port)
+   if (c-port)
sprintf(object,%s:%hd/%s,c-host,c-port,c-path);
else
sprintf(object,%s/%s,c-host,c-path);
@@ -314,14 +314,14 @@ int credential_read(struct credential *c)
{
line_len = strlen(buf);
 
-   if(buf[line_len-1]=='\n')
+   if (buf[line_len-1]=='\n')
buf[--line_len]='\0';
 
-   if(!line_len)
+   if (!line_len)
break;
 
value = strchr(buf,'=');
-   if(!value) {
+   if (!value) {
warning(invalid credential line: %s, key);
return -1;
}
@@ -379,9 +379,9 @@ static void usage(const char *name)
 
basename = (basename) ? basename + 1 : name;
fprintf(stderr, usage: %s , basename);
-   while(try_op-name) {
+   while (try_op-name) {
fprintf(stderr,%s,(try_op++)-name);
-   if(try_op-name)
+   if (try_op-name)
fprintf(stderr,%s,|);
}
fprintf(stderr,%s,\n);
@@ -400,15 +400,15 @@ int main(int argc, char *argv[])
}
 
/* lookup operation callback */
-   while(try_op-name  strcmp(argv[1], try_op-name))
+   while (try_op-name  strcmp(argv[1], try_op-name))
try_op++;
 
/* unsupported operation given -- ignore silently */
-   if(!try_op-name || !try_op-op)
+   if (!try_op-name || !try_op-op)
goto out;
 
ret = credential_read(cred);
-   if(ret)
+   if (ret)
goto out;
 
/* perform credential operation */
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 15/16] contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring

From: Brandon Casey draf...@gmail.com

The gnome-keyring lib distributed with RHEL 5.X is ancient and does
not provide a few of the functions/defines that more recent versions
do, but mostly the API is the same.  Let's provide the missing bits
via macro definitions and function implementation.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../gnome-keyring/git-credential-gnome-keyring.c   | 58 ++
 1 file changed, 58 insertions(+)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 447e9aa..e1bc3fa 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -28,8 +28,66 @@
 #include stdlib.h
 #include glib.h
 #include gnome-keyring.h
+
+#ifdef GNOME_KEYRING_DEFAULT
+
+   /* Modern gnome-keyring */
+
 #include gnome-keyring-memory.h
 
+#else
+
+   /*
+* Support ancient gnome-keyring, circ. RHEL 5.X.
+* GNOME_KEYRING_DEFAULT seems to have been introduced with Gnome 2.22,
+* and the other features roughly around Gnome 2.20, 6 months before.
+* Ubuntu 8.04 used Gnome 2.22 (I think).  Not sure any distro used 2.20.
+* So the existence/non-existence of GNOME_KEYRING_DEFAULT seems like
+* a decent thing to use as an indicator.
+*/
+
+#define GNOME_KEYRING_DEFAULT NULL
+
+/*
+ * ancient gnome-keyring returns DENIED when an entry is not found.
+ * Setting NO_MATCH to DENIED will prevent us from reporting DENIED
+ * errors during get and erase operations, but we will still report
+ * DENIED errors during a store.
+ */
+#define GNOME_KEYRING_RESULT_NO_MATCH GNOME_KEYRING_RESULT_DENIED
+
+#define gnome_keyring_memory_alloc g_malloc
+#define gnome_keyring_memory_free gnome_keyring_free_password
+#define gnome_keyring_memory_strdup g_strdup
+
+static const char* gnome_keyring_result_to_message(GnomeKeyringResult result)
+{
+   switch (result) {
+   case GNOME_KEYRING_RESULT_OK:
+   return OK;
+   case GNOME_KEYRING_RESULT_DENIED:
+   return Denied;
+   case GNOME_KEYRING_RESULT_NO_KEYRING_DAEMON:
+   return No Keyring Daemon;
+   case GNOME_KEYRING_RESULT_ALREADY_UNLOCKED:
+   return Already UnLocked;
+   case GNOME_KEYRING_RESULT_NO_SUCH_KEYRING:
+   return No Such Keyring;
+   case GNOME_KEYRING_RESULT_BAD_ARGUMENTS:
+   return Bad Arguments;
+   case GNOME_KEYRING_RESULT_IO_ERROR:
+   return IO Error;
+   case GNOME_KEYRING_RESULT_CANCELLED:
+   return Cancelled;
+   case GNOME_KEYRING_RESULT_ALREADY_EXISTS:
+   return Already Exists;
+   default:
+   return Unknown Error;
+   }
+}
+
+#endif
+
 /*
  * This credential struct and API is simplified from git's credential.{h,c}
  */
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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/RFC 0/7] Support for Ruby

On Mon, Sep 23, 2013 at 1:20 PM, Patrick Donnelly batr...@batbytes.com wrote:
 Hello Felipe,

 On Sun, Sep 22, 2013 at 4:29 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Sun, Sep 22, 2013 at 3:12 AM, Fredrik Gustafsson iv...@iveqy.com wrote:
 And see my humble test of what the speedup would be for git-submodule
 even with a faulty lua integration (still forking... but huge
 performance boost anyway):
 http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051

 I don't see how that is relevant, but I'm certain the same can be done
 with Ruby.

 As you can see a lua integration would increase the git binary with
 300kb.

 And my patch would increase it 49Kb.

 Unless you statically compile in Ruby (which is what the above quoted
 300kb implied for Lua, in actually it is less than 200kb). [Also good
 luck statically compiling Python/Ruby into an executable.]

Yes, but that's not what the words said, the words said 'lua
integration' and 'ruby integration' would take that much. Either way
it doesn't matter, shared libraries exist for a reason. We don't need
to statically compile openssl do we? No? Good.

 IMO the problem with lua is that it's too simple, it's syntax doesn't
 resemble c, perl, python, shell, or ruby, it's just weird. Also, it's
 much less popular, it's not as powerful, and there isn't a big
 community involved with Git like with Ruby.

 *sigh*. At this point you've really cemented your purpose here as a
 language evangelist. It's unfortunate I have to reply to dismiss this
 FUD (which you complained about earlier, ironically) otherwise
 community accepts it as fact (oh, I remember some guys saying Lua was
 a language for idiots...).

I dismissed the claim as FUD, when the conclusion was exaggerated, and
there was no evidence in sight.

When I say Ruby is a superior alternative, I provide evidence.

 Lua is by no means *simple*. Try small or lightweight. Its syntax
 is engineered to be readable and amateur friendly. You've placed Ruby
 on a pedestal alongside those other major languages but its syntax
 doesn't resemble any of those.

Also, it's much less popular

 https://sites.google.com/site/marbux/home/where-lua-is-used

 The hallmark of a good embedded language is your users don't even know
 it is there.

Users don't even know in what language those projects are programmed,
that's irrelevant. If MediaWiki does indeed use Lua, it must be a tiny
fraction of it.

Lua is #25 in the tiobe index with 0.518%, Ruby is #13 with 1.382%,
right next to Perl. Ruby is 54 times used more in GitHub than Lua.
These are the numbers I have, if you have other numbers, please, share
them.

  it's not as powerful,

 This is really funny to me. Despite Lua's small size, it has lead the
 way for modern dynamic language features, such as coroutines, block
 level scoping and real closure, incremental GC, a simple and usable C
 API (*yes* this is a feature), and a register based VM [1]. It is
 consistently placed as the *fastest* dynamic language in existence
 [e.g. 2]? The LuaJIT compiler often achieves competitive or better
 performance than C [3]. What about this isn't powerful?

Talk is cheap, show me the code.

Do what I did. Add lua bindings for several C functions, replace a
script with a Lua script (like git request-pull), replace a major
builtin (like git reset), and show how this succinct example I
provided in Ruby would look like:

cb_data = 'foo'
for_each_ref() do |name, sha1, flags|
  puts '%s: %s: %s' % [cb_data, name, sha1_to_hex(sha1)]
end

Let's see how it looks.

Until you do that, I'd say you are the one that is language
evangelizing, I'm providing an actual real solution to a very
important problem.

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

[PATCH v2 06/16] contrib/git-credential-gnome-keyring.c: strlen() returns size_t, not ssize_t

From: Brandon Casey draf...@gmail.com

Also, initialization is not necessary since it is assigned before it is
used.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 04852d7..b9bb794 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -306,7 +306,7 @@ static void credential_clear(struct credential *c)
 static int credential_read(struct credential *c)
 {
charbuf[1024];
-   ssize_t line_len = 0;
+   size_t line_len;
char   *key  = buf;
char   *value;
 
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 14/16] contrib/git-credential-gnome-keyring.c: report failure to store password

From: Brandon Casey draf...@gmail.com

Produce an error message when we fail to store a password to the keyring.

Signed-off-by: Brandon Casey draf...@gmail.com
---

Difference from v1:
Additionally interpret GNOME_KEYRING_RESULT_CANCELLED as a successful exit
status, since that means that the user intentionally cancelled the
operation from the gui.  We should not produce a warning in that case.

 .../credential/gnome-keyring/git-credential-gnome-keyring.c| 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index b70bd53..447e9aa 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -125,6 +125,7 @@ static int keyring_store(struct credential *c)
 {
guint32 item_id;
char  *object = NULL;
+   GnomeKeyringResult result;
 
/*
 * Sanity check that what we are storing is actually sensible.
@@ -139,7 +140,7 @@ static int keyring_store(struct credential *c)
 
object = keyring_object(c);
 
-   gnome_keyring_set_network_password_sync(
+   result = gnome_keyring_set_network_password_sync(
GNOME_KEYRING_DEFAULT,
c-username,
NULL /* domain */,
@@ -152,6 +153,13 @@ static int keyring_store(struct credential *c)
item_id);
 
g_free(object);
+
+   if (result != GNOME_KEYRING_RESULT_OK 
+   result != GNOME_KEYRING_RESULT_CANCELLED) {
+   g_critical(%s, gnome_keyring_result_to_message(result));
+   return EXIT_FAILURE;
+   }
+
return EXIT_SUCCESS;
 }
 
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 07/16] contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty before accessing

From: Brandon Casey draf...@gmail.com

Ensure buffer length is non-zero before attempting to access the last
element.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index b9bb794..0d2c55e 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -314,7 +314,7 @@ static int credential_read(struct credential *c)
{
line_len = strlen(buf);
 
-   if (buf[line_len-1]=='\n')
+   if (line_len  buf[line_len-1] == '\n')
buf[--line_len]='\0';
 
if (!line_len)
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 12/16] contrib/git-credential-gnome-keyring.c: use glib memory allocation functions

From: Brandon Casey draf...@gmail.com

Rather than roll our own, let's use the memory allocation/free routines
provided by glib.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../gnome-keyring/git-credential-gnome-keyring.c   | 48 --
 1 file changed, 16 insertions(+), 32 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 5e79669..273c43b 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -27,7 +27,6 @@
 #include string.h
 #include stdarg.h
 #include stdlib.h
-#include errno.h
 #include glib.h
 #include gnome-keyring.h
 #include gnome-keyring-memory.h
@@ -83,21 +82,6 @@ static inline void error(const char *fmt, ...)
va_end(ap);
 }
 
-static inline void die_errno(int err)
-{
-   error(%s, strerror(err));
-   exit(EXIT_FAILURE);
-}
-
-static inline char *xstrdup(const char *str)
-{
-   char *ret = strdup(str);
-   if (!ret)
-   die_errno(errno);
-
-   return ret;
-}
-
 /* - GNOME Keyring functions - */
 
 /* create a special keyring option string, if path is given */
@@ -134,7 +118,7 @@ static int keyring_get(struct credential *c)
c-port,
entries);
 
-   free(object);
+   g_free(object);
 
if (result == GNOME_KEYRING_RESULT_NO_MATCH)
return EXIT_SUCCESS;
@@ -154,7 +138,7 @@ static int keyring_get(struct credential *c)
c-password = gnome_keyring_memory_strdup(password_data-password);
 
if (!c-username)
-   c-username = xstrdup(password_data-user);
+   c-username = g_strdup(password_data-user);
 
gnome_keyring_network_password_list_free(entries);
 
@@ -192,7 +176,7 @@ static int keyring_store(struct credential *c)
c-password,
item_id);
 
-   free(object);
+   g_free(object);
return EXIT_SUCCESS;
 }
 
@@ -226,7 +210,7 @@ static int keyring_erase(struct credential *c)
c-port,
entries);
 
-   free(object);
+   g_free(object);
 
if (result == GNOME_KEYRING_RESULT_NO_MATCH)
return EXIT_SUCCESS;
@@ -278,10 +262,10 @@ static void credential_init(struct credential *c)
 
 static void credential_clear(struct credential *c)
 {
-   free(c-protocol);
-   free(c-host);
-   free(c-path);
-   free(c-username);
+   g_free(c-protocol);
+   g_free(c-host);
+   g_free(c-path);
+   g_free(c-username);
gnome_keyring_memory_free(c-password);
 
credential_init(c);
@@ -315,22 +299,22 @@ static int credential_read(struct credential *c)
*value++ = '\0';
 
if (!strcmp(key, protocol)) {
-   free(c-protocol);
-   c-protocol = xstrdup(value);
+   g_free(c-protocol);
+   c-protocol = g_strdup(value);
} else if (!strcmp(key, host)) {
-   free(c-host);
-   c-host = xstrdup(value);
+   g_free(c-host);
+   c-host = g_strdup(value);
value = strrchr(c-host,':');
if (value) {
*value++ = '\0';
c-port = atoi(value);
}
} else if (!strcmp(key, path)) {
-   free(c-path);
-   c-path = xstrdup(value);
+   g_free(c-path);
+   c-path = g_strdup(value);
} else if (!strcmp(key, username)) {
-   free(c-username);
-   c-username = xstrdup(value);
+   g_free(c-username);
+   c-username = g_strdup(value);
} else if (!strcmp(key, password)) {
gnome_keyring_memory_free(c-password);
c-password = gnome_keyring_memory_strdup(value);
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] git-remote-mediawiki: bugfix for pages w/ 500 revisions

2013-09-23 Thread Matthieu Moy

Benoit Person benoit.per...@gmail.com writes:

 The latest API renamed and moved the continuing information in the
 response, necessary to build the next query. The code failed to retrieve
 that information but still detected that it was in a continuing
 query. As a result, it launched the same query over and over again.

Good, that's much cleaner.

 + if ($result-{'query-continue'}) { # For legacy APIs
 + $query-{rvstartid} = 
 $result-{'query-continue'}-{revisions}-{rvstartid};
 + } elsif ($result-{continue}) { # For newer APIs

I'd rather have the comments say # API version  X and # API version
= X. Next time the API change, new Vs old will become meaningless.

(But that should not block the patch from inclusion)

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

[PATCH v2 11/16] contrib/git-credential-gnome-keyring.c: use secure memory for reading passwords

From: Brandon Casey draf...@gmail.com

gnome-keyring provides functions to allocate non-pageable memory (if
possible).  Let's use them to allocate memory that may be used to hold
secure data read from the keyring.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../credential/gnome-keyring/git-credential-gnome-keyring.c  | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index d8a7038..5e79669 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -289,12 +289,14 @@ static void credential_clear(struct credential *c)
 
 static int credential_read(struct credential *c)
 {
-   charbuf[1024];
+   char*buf;
size_t line_len;
-   char   *key  = buf;
+   char   *key;
char   *value;
 
-   while (fgets(buf, sizeof(buf), stdin))
+   key = buf = gnome_keyring_memory_alloc(1024);
+
+   while (fgets(buf, 1024, stdin))
{
line_len = strlen(buf);
 
@@ -307,6 +309,7 @@ static int credential_read(struct credential *c)
value = strchr(buf,'=');
if (!value) {
warning(invalid credential line: %s, key);
+   gnome_keyring_memory_free(buf);
return -1;
}
*value++ = '\0';
@@ -339,6 +342,9 @@ static int credential_read(struct credential *c)
 * learn new lines, and the helpers are updated to match.
 */
}
+
+   gnome_keyring_memory_free(buf);
+
return 0;
 }
 
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 16/16] contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring

From: Brandon Casey draf...@gmail.com

The gnome-keyring lib (0.4) distributed with RHEL 4.X is really ancient
and does not provide most of the synchronous functions that even ancient
releases do.  Thankfully, we're only using one function that is missing.
Let's emulate gnome_keyring_item_delete_sync() by calling the asynchronous
function and then triggering the event loop processing until our
callback is called.

Signed-off-by: Brandon Casey draf...@gmail.com
---

Clarified the comment about RHEL 4.X support.

 .../gnome-keyring/git-credential-gnome-keyring.c   | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index e1bc3fa..635c96b 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -86,6 +86,45 @@ static const char* 
gnome_keyring_result_to_message(GnomeKeyringResult result)
}
 }
 
+/*
+ * Support really ancient gnome-keyring, circ. RHEL 4.X.
+ * Just a guess for the Glib version.  Glib 2.8 was roughly Gnome 2.12 ?
+ * Which was released with gnome-keyring 0.4.3 ??
+ */
+#if GLIB_MAJOR_VERSION == 2  GLIB_MINOR_VERSION  8
+
+static void gnome_keyring_done_cb(GnomeKeyringResult result, gpointer 
user_data)
+{
+   gpointer *data = (gpointer*) user_data;
+   int *done = (int*) data[0];
+   GnomeKeyringResult *r = (GnomeKeyringResult*) data[1];
+
+   *r = result;
+   *done = 1;
+}
+
+static void wait_for_request_completion(int *done)
+{
+   GMainContext *mc = g_main_context_default();
+   while (!*done)
+   g_main_context_iteration(mc, TRUE);
+}
+
+static GnomeKeyringResult gnome_keyring_item_delete_sync(const char *keyring, 
guint32 id)
+{
+   int done = 0;
+   GnomeKeyringResult result;
+   gpointer data[] = { done, result };
+
+   gnome_keyring_item_delete(keyring, id, gnome_keyring_done_cb, data,
+   NULL);
+
+   wait_for_request_completion(done);
+
+   return result;
+}
+
+#endif
 #endif
 
 /*
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 13/16] contrib/git-credential-gnome-keyring.c: use glib messaging functions

From: Brandon Casey draf...@gmail.com

Rather than roll our own, let's use the messaging functions provided
by glib.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../gnome-keyring/git-credential-gnome-keyring.c   | 33 +++---
 1 file changed, 4 insertions(+), 29 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 273c43b..b70bd53 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -25,7 +25,6 @@
 
 #include stdio.h
 #include string.h
-#include stdarg.h
 #include stdlib.h
 #include glib.h
 #include gnome-keyring.h
@@ -58,30 +57,6 @@ struct credential_operation
 #define CREDENTIAL_OP_END \
   { NULL,NULL }
 
-/*  common helper functions - */
-
-static inline void warning(const char *fmt, ...)
-{
-   va_list ap;
-
-   va_start(ap, fmt);
-   fprintf(stderr, warning: );
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n );
-   va_end(ap);
-}
-
-static inline void error(const char *fmt, ...)
-{
-   va_list ap;
-
-   va_start(ap, fmt);
-   fprintf(stderr, error: );
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n );
-   va_end(ap);
-}
-
 /* - GNOME Keyring functions - */
 
 /* create a special keyring option string, if path is given */
@@ -127,7 +102,7 @@ static int keyring_get(struct credential *c)
return EXIT_SUCCESS;
 
if (result != GNOME_KEYRING_RESULT_OK) {
-   error(%s,gnome_keyring_result_to_message(result));
+   g_critical(%s, gnome_keyring_result_to_message(result));
return EXIT_FAILURE;
}
 
@@ -220,7 +195,7 @@ static int keyring_erase(struct credential *c)
 
if (result != GNOME_KEYRING_RESULT_OK)
{
-   error(%s,gnome_keyring_result_to_message(result));
+   g_critical(%s, gnome_keyring_result_to_message(result));
return EXIT_FAILURE;
}
 
@@ -234,7 +209,7 @@ static int keyring_erase(struct credential *c)
 
if (result != GNOME_KEYRING_RESULT_OK)
{
-   error(%s,gnome_keyring_result_to_message(result));
+   g_critical(%s, gnome_keyring_result_to_message(result));
return EXIT_FAILURE;
}
 
@@ -292,7 +267,7 @@ static int credential_read(struct credential *c)
 
value = strchr(buf,'=');
if (!value) {
-   warning(invalid credential line: %s, key);
+   g_warning(invalid credential line: %s, key);
gnome_keyring_memory_free(buf);
return -1;
}
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 08/16] contrib/git-credential-gnome-keyring.c: set Gnome application name

From: Brandon Casey draf...@gmail.com

Since this is a Gnome application, let's set the application name to
something reasonable.  This will be displayed in Gnome dialog boxes
e.g. the one that prompts for the user's keyring password.

We add an include statement for glib.h and add the glib-2.0 cflags and
libs to the compilation arguments, but both of these are really noops
since glib is already a dependency of gnome-keyring.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 contrib/credential/gnome-keyring/Makefile   | 4 ++--
 contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/contrib/credential/gnome-keyring/Makefile 
b/contrib/credential/gnome-keyring/Makefile
index e6561d8..c3c7c98 100644
--- a/contrib/credential/gnome-keyring/Makefile
+++ b/contrib/credential/gnome-keyring/Makefile
@@ -8,8 +8,8 @@ CFLAGS = -g -O2 -Wall
 -include ../../../config.mak.autogen
 -include ../../../config.mak
 
-INCS:=$(shell pkg-config --cflags gnome-keyring-1)
-LIBS:=$(shell pkg-config --libs gnome-keyring-1)
+INCS:=$(shell pkg-config --cflags gnome-keyring-1 glib-2.0)
+LIBS:=$(shell pkg-config --libs gnome-keyring-1 glib-2.0)
 
 SRCS:=$(MAIN).c
 OBJS:=$(SRCS:.c=.o)
diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 0d2c55e..43b19dd 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -28,6 +28,7 @@
 #include stdarg.h
 #include stdlib.h
 #include errno.h
+#include glib.h
 #include gnome-keyring.h
 
 /*
@@ -399,6 +400,8 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
 
+   g_set_application_name(Git Credential Helper);
+
/* lookup operation callback */
while (try_op-name  strcmp(argv[1], try_op-name))
try_op++;
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 01/16] contrib/git-credential-gnome-keyring.c: remove unnecessary pre-declarations

From: Brandon Casey draf...@gmail.com

These are all defined before they are used, so it is not necessary to
pre-declare them.  Remove the pre-declarations.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../credential/gnome-keyring/git-credential-gnome-keyring.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index f2cdefe..15b0a1c 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -46,11 +46,6 @@ struct credential
 #define CREDENTIAL_INIT \
   { NULL,NULL,0,NULL,NULL,NULL }
 
-void credential_init(struct credential *c);
-void credential_clear(struct credential *c);
-int  credential_read(struct credential *c);
-void credential_write(const struct credential *c);
-
 typedef int (*credential_op_cb)(struct credential*);
 
 struct credential_operation
@@ -62,14 +57,6 @@ struct credential_operation
 #define CREDENTIAL_OP_END \
   { NULL,NULL }
 
-/*
- * Table with operation callbacks is defined in concrete
- * credential helper implementation and contains entries
- * like { get, function_to_get_credential } terminated
- * by CREDENTIAL_OP_END.
- */
-struct credential_operation const credential_helper_ops[];
-
 /*  common helper functions - */
 
 static inline void free_password(char *password)
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 09/16] contrib/git-credential-gnome-keyring.c: use gnome helpers in keyring_object()

From: Brandon Casey draf...@gmail.com

Rather than carefully allocating memory for sprintf() to write into,
let's make use of the glib helper function g_strdup_printf(), which
makes things a lot easier and less error-prone.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../gnome-keyring/git-credential-gnome-keyring.c   | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 43b19dd..b692e1f 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -112,21 +112,13 @@ static inline char *xstrdup(const char *str)
 /* create a special keyring option string, if path is given */
 static char* keyring_object(struct credential *c)
 {
-   char* object = NULL;
-
if (!c-path)
-   return object;
-
-   object = (char*) malloc(strlen(c-host)+strlen(c-path)+8);
-   if (!object)
-   die_errno(errno);
+   return NULL;
 
if (c-port)
-   sprintf(object,%s:%hd/%s,c-host,c-port,c-path);
-   else
-   sprintf(object,%s/%s,c-host,c-path);
+   return g_strdup_printf(%s:%hd/%s, c-host, c-port, c-path);
 
-   return object;
+   return g_strdup_printf(%s/%s, c-host, c-path);
 }
 
 static int keyring_get(struct credential *c)
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 05/16] contrib/git-credential-gnome-keyring.c: exit non-zero when called incorrectly

From: Brandon Casey draf...@gmail.com

If the correct arguments were not specified, this program should exit
non-zero.  Let's do so.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 3ff541c..04852d7 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -396,7 +396,7 @@ int main(int argc, char *argv[])
 
if (!argv[1]) {
usage(argv[0]);
-   goto out;
+   exit(EXIT_FAILURE);
}
 
/* lookup operation callback */
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 04/16] contrib/git-credential-gnome-keyring.c: add static where applicable

From: Brandon Casey draf...@gmail.com

Mark global variable and functions as static.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 .../gnome-keyring/git-credential-gnome-keyring.c   | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 809b1b7..3ff541c 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -128,7 +128,7 @@ static char* keyring_object(struct credential *c)
return object;
 }
 
-int keyring_get(struct credential *c)
+static int keyring_get(struct credential *c)
 {
char* object = NULL;
GList *entries;
@@ -178,7 +178,7 @@ int keyring_get(struct credential *c)
 }
 
 
-int keyring_store(struct credential *c)
+static int keyring_store(struct credential *c)
 {
guint32 item_id;
char  *object = NULL;
@@ -212,7 +212,7 @@ int keyring_store(struct credential *c)
return EXIT_SUCCESS;
 }
 
-int keyring_erase(struct credential *c)
+static int keyring_erase(struct credential *c)
 {
char  *object = NULL;
GList *entries;
@@ -277,7 +277,7 @@ int keyring_erase(struct credential *c)
  * Table with helper operation callbacks, used by generic
  * credential helper main function.
  */
-struct credential_operation const credential_helper_ops[] =
+static struct credential_operation const credential_helper_ops[] =
 {
{ get,   keyring_get   },
{ store, keyring_store },
@@ -287,12 +287,12 @@ struct credential_operation const credential_helper_ops[] 
=
 
 /* -- credential functions -- */
 
-void credential_init(struct credential *c)
+static void credential_init(struct credential *c)
 {
memset(c, 0, sizeof(*c));
 }
 
-void credential_clear(struct credential *c)
+static void credential_clear(struct credential *c)
 {
free(c-protocol);
free(c-host);
@@ -303,7 +303,7 @@ void credential_clear(struct credential *c)
credential_init(c);
 }
 
-int credential_read(struct credential *c)
+static int credential_read(struct credential *c)
 {
charbuf[1024];
ssize_t line_len = 0;
@@ -358,14 +358,14 @@ int credential_read(struct credential *c)
return 0;
 }
 
-void credential_write_item(FILE *fp, const char *key, const char *value)
+static void credential_write_item(FILE *fp, const char *key, const char *value)
 {
if (!value)
return;
fprintf(fp, %s=%s\n, key, value);
 }
 
-void credential_write(const struct credential *c)
+static void credential_write(const struct credential *c)
 {
/* only write username/password, if set */
credential_write_item(stdout, username, c-username);
-- 
1.8.4.rc4.6.gd19


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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/RFC 0/7] Support for Ruby

Junio C Hamano wrote:
 [on vacaion, with only gmail webmail UI; please excuse me if this message 
 comes
 out badly formatted or gets dropped by vger.kernel.org]
 
 On Sat, Sep 21, 2013 at 4:56 PM, brian m. carlson
 sand...@crustytoothpaste.net wrote:
  On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote:
  On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson
  sand...@crustytoothpaste.net wrote:
   As Junio has also pointed out in the past, there are people who aren't
   able to use Ruby in the same way that they are Perl and Python.  If it's
   announced now, Git 2.0 might be a good time to start accepting Ruby
   scripts, as that will give people time to plan for its inclusion.
 
 In the very beginning, the codebase and development community of Git was
 very small. In order to give usability and also easy availability of minimally
 sufficient features, we used shell and Perl for quicker turn-around and
 implementation and included these Porcelain scripts written in higher level
 languages in the same package as the core Git.
 
 We should look at use of shell and Perl as necessary evil in that context,
 not as an enabler for people who do not want to write in C. It is no longer
 2005 and the enabler side has a much more suited project for it these days.
 
 Namely, it is better served by various language-binding efforts around 
 libgit2.
 Binding that takes advantage of each specific language is better done over
 there, I think. Cf. http://www.youtube.com/watch?v=4ZWqr6iih3s

If libgit2 is so good as a library to interact with Git repositories, why isn't
Git using it?

Because it's not. It is a necessary evil due to the fact that Git developers
neglected to write code in a reusable manner so other people could utilize
libgit. So somebody else had to step up, so now we have two code-bases.

 If anything, I think the core side should be focused on three things
 (in addition
 to bug-fixes, of course) in the longer term:
 
  - Defining and implementing necessary improvements to the core on-file and
on-the-wire data structures and the protocols to serve as the canonical
implementation.
 
  - Moving away from higher-level scripting languages such as shell and Perl.
Recent clean --interactive may have added some code that could be
reused for a rewrite of add -i (which I think is in Perl), for example.
The minimum You need to have these to use Git should be made more
portable by doing *less* in shell or Perl, not by adding more in the 
 higher-
level languages, and certainly not by adding other languages, be it Ruby or
Lua.
 
  - Giving solid interface to the outside world, e.g. remote-helpers, 
 credential-
helpers API, and let the users and developers that want to use them do 
 their
own projects, without adding things to contrib/.

It's interesting how none of these goals reflect what the users want:

https://www.survs.com/results/QPESOB10/ME8UTHXM4M

1. Better user-interface
2. Better documentation
3. GUI tools

Do you deny this is what users want? Or you just don't care?

I'm not trying to antagonize you, I just truly don't understand how something
so obvious for so many users just doesn't even factor into your decision making
as what needs to be done.

 In other words, now the Git user and developer community are strong
 and thriving,
 we should strive to make the core smaller, not larger, and encourage people to
 form more third party communities that specialise in the areas the
 participant of
 these communities are stronger than those who are involved in the core
 (e.g. like
 myself, Peff, Nico, Jonathan, etc.). For programs that talk remote-helper or
 credential-helper protocols, for example, it is wasteful to have them
 in our contrib/
 and have the changes to them go through my tree, with the same coding style
 standard applied to the core, which would in the longer term only add
 unnecessary overhead to what they want to do and what their effort supply the
 users with.

Of course, we can make the core smaller, by replacing all the perl/shell
scripts with ruby ones.

Sure, it would be better if all the scripts were rewritten in C, but that has
been going on for years, and there's no end in sight, and not that much
progress at all.

So, it's fair to say that the rewrite to C is just not going to happen any time
soon, and if we accept that, we should accept that an interim solution is
needed, because Windows users are important and they are hurting right now, and
that solution could definitely be Ruby.

Rewriting scripts to C is hard, rewriting them to Ruby is easy, and one of the
advantages of rewriting to Ruby, is that having the C-Ruby bindings available
would make it easy to replace part of the scripts chunk by chunk, so we could
have a half Ruby, half C script, and eventually 100% C.

This is a practical solution, it's a realistic path to move forward, not one
based on wishful thinking and intentions that never get realized.

Once again, the

Re: [PATCH/RFC 0/7] Support for Ruby

2013-09-23 Thread Patrick Donnelly

On Mon, Sep 23, 2013 at 2:53 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Yes, but that's not what the words said, the words said 'lua
 integration' and 'ruby integration' would take that much. Either way
 it doesn't matter, shared libraries exist for a reason. We don't need
 to statically compile openssl do we? No? Good.

Uh, you're willfully ignoring the conversation about avoiding
dependencies. One way to do that is to include and statically link Lua
along with Git. The cost of doing that is 200kb. I know this because I
actually do it for Nmap.

 IMO the problem with lua is that it's too simple, it's syntax doesn't
 resemble c, perl, python, shell, or ruby, it's just weird. Also, it's
 much less popular, it's not as powerful, and there isn't a big
 community involved with Git like with Ruby.

 *sigh*. At this point you've really cemented your purpose here as a
 language evangelist. It's unfortunate I have to reply to dismiss this
 FUD (which you complained about earlier, ironically) otherwise
 community accepts it as fact (oh, I remember some guys saying Lua was
 a language for idiots...).

 I dismissed the claim as FUD, when the conclusion was exaggerated, and
 there was no evidence in sight.

 When I say Ruby is a superior alternative, I provide evidence.

You have provided *no* evidence.

 Lua is by no means *simple*. Try small or lightweight. Its syntax
 is engineered to be readable and amateur friendly. You've placed Ruby
 on a pedestal alongside those other major languages but its syntax
 doesn't resemble any of those.

Also, it's much less popular

 https://sites.google.com/site/marbux/home/where-lua-is-used

 The hallmark of a good embedded language is your users don't even know
 it is there.

 Users don't even know in what language those projects are programmed,
 that's irrelevant.

*Absolutely relevant*: as normal git user *never* wants to know, care,
or be exposed to the details of how `git` operates.

 If MediaWiki does indeed use Lua, it must be a tiny
 fraction of it.

They just started using it. Well done cherry-picking 1 example from a
host for your dismissal.

  it's not as powerful,

 This is really funny to me. Despite Lua's small size, it has lead the
 way for modern dynamic language features, such as coroutines, block
 level scoping and real closure, incremental GC, a simple and usable C
 API (*yes* this is a feature), and a register based VM [1]. It is
 consistently placed as the *fastest* dynamic language in existence
 [e.g. 2]? The LuaJIT compiler often achieves competitive or better
 performance than C [3]. What about this isn't powerful?

 Talk is cheap, show me the code.

 Do what I did. Add lua bindings for several C functions, replace a
 script with a Lua script (like git request-pull), replace a major
 builtin (like git reset), and show how this succinct example I
 provided in Ruby would look like:

 cb_data = 'foo'
 for_each_ref() do |name, sha1, flags|
   puts '%s: %s: %s' % [cb_data, name, sha1_to_hex(sha1)]
 end

 Let's see how it looks.

I address your performance claims, you dismiss them and then ask for
code to compare? Code which is primarily bindings to C which does all
the work? No thanks, that circle jerk doesn't interest me.

 Until you do that, I'd say you are the one that is language
 evangelizing, I'm providing an actual real solution to a very
 important problem.

As mentioned elsewhere, the solution Git is using is to move porcelain
commands to C. You're manufacturing problems and spreading FUD.

I'm letting this thread die as I only wanted to confront your baseless
dismissal of Lua. If you want to continue this, I'll do it offlist.

-- 
Patrick Donnelly
--
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-prune-packed.txt: Fix reference to GIT_OBJECT_DIRECTORY

2013-09-23 Thread Steffen Prohaska

git-prune-packed operates on GIT_OBJECT_DIRECTORY.  See 'environment.c',

git_object_dir = getenv(DB_ENVIRONMENT);

and cache.h,

#define DB_ENVIRONMENT GIT_OBJECT_DIRECTORY

Signed-off-by: Steffen Prohaska proha...@zib.de
---
 Documentation/git-prune-packed.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-prune-packed.txt 
b/Documentation/git-prune-packed.txt
index 80dc022..6738055 100644
--- a/Documentation/git-prune-packed.txt
+++ b/Documentation/git-prune-packed.txt
@@ -14,7 +14,7 @@ SYNOPSIS
 
 DESCRIPTION
 ---
-This program searches the `$GIT_OBJECT_DIR` for all objects that currently
+This program searches the `$GIT_OBJECT_DIRECTORY` for all objects that 
currently
 exist in a pack file as well as the independent object directories.
 
 All such extra objects are removed.
-- 
1.8.4.477.gfa286b2

--
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/RFC 0/7] Support for Ruby

On Mon, Sep 23, 2013 at 2:20 PM, Patrick Donnelly batr...@batbytes.com wrote:
 On Mon, Sep 23, 2013 at 2:53 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 Yes, but that's not what the words said, the words said 'lua
 integration' and 'ruby integration' would take that much. Either way
 it doesn't matter, shared libraries exist for a reason. We don't need
 to statically compile openssl do we? No? Good.

 Uh, you're willfully ignoring the conversation about avoiding
 dependencies. One way to do that is to include and statically link Lua
 along with Git. The cost of doing that is 200kb. I know this because I
 actually do it for Nmap.

Dependencies are avoided when it's possible and sensible to do so.
Yet, we still depend on a bunch of things.

My proposal to replace perl/shell with ruby would actually remove two
dependencies and add one, so in effect would remove one dependency. Of
course, people could still build with NO_RUBY=y, just like they can
build with NO_PERL=y, and deal with the consequences.

 IMO the problem with lua is that it's too simple, it's syntax doesn't
 resemble c, perl, python, shell, or ruby, it's just weird. Also, it's
 much less popular, it's not as powerful, and there isn't a big
 community involved with Git like with Ruby.

 *sigh*. At this point you've really cemented your purpose here as a
 language evangelist. It's unfortunate I have to reply to dismiss this
 FUD (which you complained about earlier, ironically) otherwise
 community accepts it as fact (oh, I remember some guys saying Lua was
 a language for idiots...).

 I dismissed the claim as FUD, when the conclusion was exaggerated, and
 there was no evidence in sight.

 When I say Ruby is a superior alternative, I provide evidence.

 You have provided *no* evidence.

I have, you just chose to ignore it.

 Lua is by no means *simple*. Try small or lightweight. Its syntax
 is engineered to be readable and amateur friendly. You've placed Ruby
 on a pedestal alongside those other major languages but its syntax
 doesn't resemble any of those.

Also, it's much less popular

 https://sites.google.com/site/marbux/home/where-lua-is-used

 The hallmark of a good embedded language is your users don't even know
 it is there.

 Users don't even know in what language those projects are programmed,
 that's irrelevant.

 *Absolutely relevant*: as normal git user *never* wants to know, care,
 or be exposed to the details of how `git` operates.

So? Before and after this patch they still wouldn't be exposed.

This is a total red herring.

 If MediaWiki does indeed use Lua, it must be a tiny
 fraction of it.

 They just started using it. Well done cherry-picking 1 example from a
 host for your dismissal.

I didn't cherry pick anything, I used the project I'm more familiar
with, replace MediaWiki with any other of your examples, and the claim
still stands.

  it's not as powerful,

 This is really funny to me. Despite Lua's small size, it has lead the
 way for modern dynamic language features, such as coroutines, block
 level scoping and real closure, incremental GC, a simple and usable C
 API (*yes* this is a feature), and a register based VM [1]. It is
 consistently placed as the *fastest* dynamic language in existence
 [e.g. 2]? The LuaJIT compiler often achieves competitive or better
 performance than C [3]. What about this isn't powerful?

 Talk is cheap, show me the code.

 Do what I did. Add lua bindings for several C functions, replace a
 script with a Lua script (like git request-pull), replace a major
 builtin (like git reset), and show how this succinct example I
 provided in Ruby would look like:

 cb_data = 'foo'
 for_each_ref() do |name, sha1, flags|
   puts '%s: %s: %s' % [cb_data, name, sha1_to_hex(sha1)]
 end

 Let's see how it looks.

 I address your performance claims, you dismiss them and then ask for
 code to compare? Code which is primarily bindings to C which does all
 the work? No thanks, that circle jerk doesn't interest me.

I didn't make any performance claims, you made claims about being a
powerful language, well, let's see how powerful it is.

Ruby is so powerful I was able to write these patches with moderate
effort, surely if Lua is so powerful you can do the same.

 Until you do that, I'd say you are the one that is language
 evangelizing, I'm providing an actual real solution to a very
 important problem.

 As mentioned elsewhere, the solution Git is using is to move porcelain
 commands to C. You're manufacturing problems and spreading FUD.

This effort has no end in sight, and as I've explained, using Ruby as
an interim solution would actually speed up the move to pure C.

In fact, I would know much more about the impediments since I sent
twenty eight patches to start replacing 'git rebase' with C code:

http://thread.gmane.org/gmane.comp.version-control.git/233396

They got rejected without so much as a reply. Why if it's so important
to move the scripts to C did these patches get ignored? Because

Re: [PATCH v2 15/16] contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring

On Mon, Sep 23, 2013 at 1:49 PM, Brandon Casey bca...@nvidia.com wrote:
 From: Brandon Casey draf...@gmail.com

 The gnome-keyring lib distributed with RHEL 5.X is ancient and does
 not provide a few of the functions/defines that more recent versions
 do, but mostly the API is the same.  Let's provide the missing bits
 via macro definitions and function implementation.

 Signed-off-by: Brandon Casey draf...@gmail.com
 ---
  .../gnome-keyring/git-credential-gnome-keyring.c   | 58 
 ++
  1 file changed, 58 insertions(+)

 diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c 
 b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
 index 447e9aa..e1bc3fa 100644
 --- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
 +++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
 @@ -28,8 +28,66 @@
  #include stdlib.h
  #include glib.h
  #include gnome-keyring.h
 +
 +#ifdef GNOME_KEYRING_DEFAULT
 +
 +   /* Modern gnome-keyring */
 +
  #include gnome-keyring-memory.h

 +#else
 +
 +   /*
 +* Support ancient gnome-keyring, circ. RHEL 5.X.
 +* GNOME_KEYRING_DEFAULT seems to have been introduced with Gnome 2.22,
 +* and the other features roughly around Gnome 2.20, 6 months before.
 +* Ubuntu 8.04 used Gnome 2.22 (I think).  Not sure any distro used 2.20.
 +* So the existence/non-existence of GNOME_KEYRING_DEFAULT seems like
 +* a decent thing to use as an indicator.
 +*/
 +
 +#define GNOME_KEYRING_DEFAULT NULL
 +
 +/*
 + * ancient gnome-keyring returns DENIED when an entry is not found.
 + * Setting NO_MATCH to DENIED will prevent us from reporting DENIED
 + * errors during get and erase operations, but we will still report
 + * DENIED errors during a store.
 + */
 +#define GNOME_KEYRING_RESULT_NO_MATCH GNOME_KEYRING_RESULT_DENIED
 +
 +#define gnome_keyring_memory_alloc g_malloc
 +#define gnome_keyring_memory_free gnome_keyring_free_password
 +#define gnome_keyring_memory_strdup g_strdup
 +
 +static const char* gnome_keyring_result_to_message(GnomeKeyringResult result)

The style is:
static const char *gnome_keyring_result_to_message

There might not be a need to reroll, depending on what Junio says.

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

Re: [PATCH v2 00/16] Make Gnome Credential helper more Gnome-y and support ancient distros

On Mon, Sep 23, 2013 at 1:49 PM, Brandon Casey bca...@nvidia.com wrote:
 From: Brandon Casey draf...@gmail.com

 Mostly unchanged.

 Inserts a patch to fix the style issues for block statements.
 i.e. use if () instead of if()

 A couple early patches were reordered to improve logical flow.

 Updated the comment in the last patch to hopefully improve clarity
 wrt RHEL 4.X

 The only functional change is in 14/16 report failure to store.
 We should accept GNOME_KEYRING_RESULT_CANCELLED as a successful
 return and _not_ produce an error message.

 Interdiff follows...

I'm familiar with GLib and I looked at the patches, they look good to me.

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

Re: [PATCH v2] git-remote-mediawiki: bugfix for pages w/ 500 revisions

2013-09-23 Thread Eric Sunshine

On Mon, Sep 23, 2013 at 1:26 PM, Benoit Person benoit.per...@gmail.com wrote:
 diff --git a/contrib/mw-to-git/t/t9365-continuing-queries.sh 
 b/contrib/mw-to-git/t/t9365-continuing-queries.sh
 new file mode 100755
 index 000..6fb5df4
 --- /dev/null
 +++ b/contrib/mw-to-git/t/t9365-continuing-queries.sh
 @@ -0,0 +1,24 @@
 +#!/bin/sh
 +
 +test_description='Test the Git Mediawiki remote helper: queries w/ more than 
 500 results'
 +
 +. ./test-gitmw-lib.sh
 +. ./push-pull-tests.sh
 +. $TEST_DIRECTORY/test-lib.sh
 +
 +test_check_precond
 +
 +test_expect_success 'creating page w/ 500 revisions' '
 +   wiki_reset 
 +   for i in $(seq 1 501)

s/seq/test_seq/

d17cf5f3a32f07bf (tests: Introduce test_seq;  2012-08-03)

 +   do
 +   echo creating revision $i

Do you want to end this line with ''?

 +   wiki_editpage foo revision $ibr/ true
 +   done
 +'
 +
 +test_expect_success 'cloning page w/ 500 revisions' '
 +   git clone mediawiki::'$WIKI_URL' mw_dir
 +'
 +
 +test_done
 --
--
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] diff: add a config option to control orderfile

2013-09-23 Thread Michael S. Tsirkin

On Fri, Sep 20, 2013 at 12:32:26AM +0300, Michael S. Tsirkin wrote:
 On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
  On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
  
A problem with both schemes, though, is that they are not
backwards-compatible with existing git-patch-id implementations.
   
   Could you clarify?
   We never send patch IDs on the wire - how isn't this compatible?
  
  I meant that you might be comparing patch-ids generated by different
  implementations, or across time. There are no dedicated tools to do so,
  but it is very easy to do so with standard tools like join.
  
  For example, you can do:
  
patch_ids() {
  git rev-list $1 |
  git diff-tree --stdin -p |
  git patch-id |
  sort
}
  
patch_ids origin..topic1 us
patch_ids origin..topic2 them
  
join us them | cut -d' ' -f2-3
  
  to get a list of correlated commits between two branches. If the them
  was on another machine with a different implementation (or is saved from
  an earlier time), your patch-ids would not match.
  
  It may be esoteric enough not to worry about, though. By far the most
  common use of patch-ids is going to be in a single rev-list
  --cherry-pick situation where you are trying to omit commits during
  a rebase.
  
  I am mostly thinking of the problems we had with the kup tool, which
  expected stability across diffs that would be signed by both kernel.org.
  But as far as I know, they do not use patch-id. More details in case you
  are curious (including me arguing that we should not care, and it is
  kup's problem!) are here:
  
http://thread.gmane.org/gmane.comp.version-control.git/192331/focus=192424
  
  rerere is mentioned in that thread, but I believe that it does its own
  hash, and does not rely on patch-id.
  
  -Peff
 
 OK so far I came up with the following.
 Needs documentation and tests obviously.
 But besides that -
 would something like this be enough to address the
 issue Junio raised?

Ping. Junio could you comment on this please?

 ---
 
 patch-id: make it more stable
 
 Add a new patch-id algorithm making it stable against
 hunk reodering:
   - prepend header to each hunk (if not there)
   - calculate SHA1 hash for each hunk separately
   - sum all hashes to get patch id
 
 Add --order-sensitive to get historical unstable behaviour.
 
 Signed-off-by: Michael S. Tsirkin m...@redhat.com
 ---
  builtin/patch-id.c | 65 
 +-
  1 file changed, 50 insertions(+), 15 deletions(-)
 
 diff --git a/builtin/patch-id.c b/builtin/patch-id.c
 index 3cfe02d..d1902ff 100644
 --- a/builtin/patch-id.c
 +++ b/builtin/patch-id.c
 @@ -1,17 +1,14 @@
  #include builtin.h
  
 -static void flush_current_id(int patchlen, unsigned char *id, git_SHA_CTX *c)
 +static void flush_current_id(int patchlen, unsigned char *id, unsigned char 
 *result)
  {
 - unsigned char result[20];
   char name[50];
  
   if (!patchlen)
   return;
  
 - git_SHA1_Final(result, c);
   memcpy(name, sha1_to_hex(id), 41);
   printf(%s %s\n, sha1_to_hex(result), name);
 - git_SHA1_Init(c);
  }
  
  static int remove_space(char *line)
 @@ -56,10 +53,30 @@ static int scan_hunk_header(const char *p, int *p_before, 
 int *p_after)
   return 1;
  }
  
 -static int get_one_patchid(unsigned char *next_sha1, git_SHA_CTX *ctx, 
 struct strbuf *line_buf)
 +static void flush_one_hunk(unsigned char *result, git_SHA_CTX *ctx)
  {
 - int patchlen = 0, found_next = 0;
 + unsigned char hash[20];
 + unsigned short carry = 0;
 + int i;
 +
 + git_SHA1_Final(hash, ctx);
 + git_SHA1_Init(ctx);
 + /* 20-byte sum, with carry */
 + for (i = 0; i  20; ++i) {
 + carry += result[i] + hash[i];
 + result[i] = carry;
 + carry = 8;
 + }
 +}
 +static int get_one_patchid(unsigned char *next_sha1, unsigned char *result,
 +struct strbuf *line_buf, int stable)
 +{
 + int patchlen = 0, found_next = 0, hunks = 0;
   int before = -1, after = -1;
 + git_SHA_CTX ctx, header_ctx;
 +
 + git_SHA1_Init(ctx);
 + hashclr(result);
  
   while (strbuf_getwholeline(line_buf, stdin, '\n') != EOF) {
   char *line = line_buf-buf;
 @@ -99,6 +116,18 @@ static int get_one_patchid(unsigned char *next_sha1, 
 git_SHA_CTX *ctx, struct st
   if (!memcmp(line, @@ -, 4)) {
   /* Parse next hunk, but ignore line numbers.  */
   scan_hunk_header(line, before, after);
 + if (stable) {
 + if (hunks) {
 + flush_one_hunk(result, ctx);
 + memcpy(ctx, header_ctx,
 +sizeof ctx);
 + }

[PATCH v2 0/3] Add cleanup action to perf-lib

This patch series comes out of the discussion at $gmane/234874, adding
a new (modern) form of writing tests.  This form allows easier
extensibility of test cases.  In the next patch a --cleanup option is
added for performance tests.  The option does nothing for normal
tests, as test_when_finished is the better option for them.

The last patch adds a few simple tests to show the capabilities of the
new --cleanup option.

Junio C Hamano (1):
  test-lib: introduce modern style tests

Thomas Gummerer (1):
  perf-lib: add cleanup option

Thomas Rast (1):
  p0003-index.sh: add perf test for the index formats

 t/README| 24 +--
 t/perf/README   | 21 -
 t/perf/p0003-index.sh   | 56 +++
 t/perf/perf-lib.sh  | 32 +---
 t/t0008-ignores.sh  | 34 ++---
 t/test-lib-functions.sh | 78 +++--
 6 files changed, 200 insertions(+), 45 deletions(-)
 create mode 100755 t/perf/p0003-index.sh

-- 
1.8.3.4.1241.g1ce9896

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

[PATCH v2 1/3] test-lib: introduce modern style tests

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

Add a new, extensible style for tests that allows the addition of new
parameters other than the prerequitites

Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
 t/README| 24 +++--
 t/perf/README   | 12 -
 t/perf/perf-lib.sh  | 17 +---
 t/t0008-ignores.sh  | 34 +++
 t/test-lib-functions.sh | 72 ++---
 5 files changed, 114 insertions(+), 45 deletions(-)

diff --git a/t/README b/t/README
index 2167125..bf41c29 100644
--- a/t/README
+++ b/t/README
@@ -390,6 +390,12 @@ below), e.g.:
 $PERL_PATH -e hlagh() if unf_unf()
 '
 
+or in the modern form, specifying the prerequisite as a parameter, e.g.:
+
+test_expect_success --prereq PERL 'I need Perl' '
+$PERL_PATH -e hlagh() if unf_unf()
+'
+
 The advantage of skipping tests like this is that platforms that don't
 have the PERL and other optional dependencies get an indication of how
 many tests they're missing.
@@ -422,6 +428,7 @@ There are a handful helper functions defined in the test 
harness
 library for your script to use.
 
  - test_expect_success [prereq] message script
+ - test_expect_success [--prereq prereq] [--] message script
 
Usually takes two strings as parameters, and evaluates the
script.  If it yields success, test is considered
@@ -434,19 +441,31 @@ library for your script to use.
'tree=$(git-write-tree)'
 
If you supply three parameters the first will be taken to be a
-   prerequisite; see the test_set_prereq and test_have_prereq
+   prerequisite; if you ues the modern test style, you can specify
+   the prerequisites with --prereq; see the test_set_prereq and 
test_have_prereq
documentation below:
 
test_expect_success TTY 'git --paginate rev-list uses a pager' \
' ... '
 
+   test_expect_success --prereq TTY 'git --paginate rev-list uses a pager' 
\
+   ' ... '
+
You can also supply a comma-separated list of prerequisites, in the
rare case where your test depends on more than one:
 
test_expect_success PERL,PYTHON 'yo dawg' \
' test $(perl -E 'print eval 1 + . qx[python -c print 2]') == 
4 '
 
+   test_expect_success --prereq PERL,PYTHON 'yo dawg' \
+   ' test $(perl -E 'print eval 1 + . qx[python -c print 2]') == 
4 '
+
+The modern version also allows to distinguish the message from the
+description and test script with --, in case the message starts
+with --.
+
  - test_expect_failure [prereq] message script
+ - test_expect_failure [--prereq prereq] [--] message script
 
This is NOT the opposite of test_expect_success, but is used
to mark a test that demonstrates a known breakage.  Unlike
@@ -456,7 +475,8 @@ library for your script to use.
tests won't cause -i (immediate) to stop.
 
Like test_expect_success this function can optionally use a three
-   argument invocation with a prerequisite as the first argument.
+   argument invocation with a prerequisite as the first argument, or
+   the modern invocation with the prerequisite as an extra parameter.
 
  - test_debug script
 
diff --git a/t/perf/README b/t/perf/README
index 8848c14..21abbaf 100644
--- a/t/perf/README
+++ b/t/perf/README
@@ -118,11 +118,21 @@ At least one of the first two is required!
 You can use test_expect_success as usual.  For actual performance
 tests, use
 
-   test_perf 'descriptive string' '
+   test_perf [prereq] 'descriptive string' '
+   command1 
+   command2
+   '
+
+   test_perf [--prereq prereq] [--] 'descriptive string' '
command1 
command2
'
 
+prereq is an optional parameter to test_perf, and the performance
+tests are only executed if the prerequisite is fulfilled.  The modern
+version also allows to distinguish the message from the description
+and test script with --, in case the message starts with --.
+
 test_perf spawns a subshell, for lack of better options.  This means
 that
 
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index f4eecaa..6477d38 100644
--- a/t/perf/perf-lib.sh
+++ b/t/perf/perf-lib.sh
@@ -151,23 +151,20 @@ exit $ret' 3 24
 
 test_perf () {
test_start_
-   test $# = 3  { test_prereq=$1; shift; } || test_prereq=
-   test $# = 2 ||
-   error bug in the test script: not 2 or 3 parameters to 
test-expect-success
-   export test_prereq
+   test_expect_parse test_perf $@
if ! test_skip $@
then
base=$(basename $0 .sh)
echo $test_count $perf_results_dir/$base.subtests
-   echo $1 $perf_results_dir/$base.$test_count.descr
+   echo $test_label $perf_results_dir/$base.$test_count.descr
if test -z $verbose; then
-   printf %s perf $test_count - $1:
+

[PATCH v2 2/3] perf-lib: add cleanup option

Add a --cleanup for the performance tests.  This option can be used to
clean up the tested repository after each time the performance tests are
run.  The option can be specified for normal tests too, although it will
not do anything for them.  Use test_when_finished for those tests.

Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
 t/perf/README   | 11 ++-
 t/perf/perf-lib.sh  | 15 +++
 t/test-lib-functions.sh |  6 ++
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/t/perf/README b/t/perf/README
index 21abbaf..73a1d1c 100644
--- a/t/perf/README
+++ b/t/perf/README
@@ -123,7 +123,7 @@ tests, use
command2
'
 
-   test_perf [--prereq prereq] [--] 'descriptive string' '
+   test_perf [--prereq prereq] [--cleanup cleanup] [--] 'descriptive 
string' '
command1 
command2
'
@@ -133,6 +133,15 @@ tests are only executed if the prerequisite is fulfilled.  
The modern
 version also allows to distinguish the message from the description
 and test script with --, in case the message starts with --.
 
+cleanup is another optional parameter to test_perf, which is executed
+after every run of the performance test.  It can specify actions to
+bring the repository to the original state, in order to be able to
+execute the exact same test multiple times, e.g:
+
+   test_perf --cleanup 'git reset' 'test performance of git add' '
+ git add $somefile
+   '
+
 test_perf spawns a subshell, for lack of better options.  This means
 that
 
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index 6477d38..8ace4a3 100644
--- a/t/perf/perf-lib.sh
+++ b/t/perf/perf-lib.sh
@@ -176,6 +176,21 @@ test_perf () {
test_failure_ $@
break
fi
+   if ! test -z $cleanup_action; then
+   say 3 cleaning up: $cleanup_action
+   if test_run_ $cleanup_action
+   then
+   if test -z $verbose; then
+   printf  c%s $i
+   else
+   echo * cleaning up run 
$i/$GIT_PERF_REPEAT_COUNT:
+   fi
+   else
+   test -z $verbose  echo
+   test_failure_ $@
+   break
+   fi
+   fi
done
if test -z $verbose; then
echo  ok
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 473b21d..4bad14f 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -360,6 +360,12 @@ test_expect_parse () {
test_prereq=$2
shift
;;
+   --cleanup)
+   test $# -gt 1 ||
+   error bug in the test script: --cleanup needs a 
parameter
+   cleanup_action=$2
+   shift
+   ;;
--)
shift
break
-- 
1.8.3.4.1241.g1ce9896

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

[PATCH v2 3/3] p0003-index.sh: add perf test for the index formats

From: Thomas Rast tr...@inf.ethz.ch

Add a performance test for index version [23]/4 by using
git update-index --index-version=x, thus testing both the reader
and the writer speed of all index formats.

Signed-off-by: Thomas Rast tr...@inf.ethz.ch
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
 t/perf/p0003-index.sh | 56 +++
 1 file changed, 56 insertions(+)
 create mode 100755 t/perf/p0003-index.sh

diff --git a/t/perf/p0003-index.sh b/t/perf/p0003-index.sh
new file mode 100755
index 000..f2308c0
--- /dev/null
+++ b/t/perf/p0003-index.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+test_description=Tests index versions [23]/4/5
+
+. ./perf-lib.sh
+
+test_perf_large_repo
+test_checkout_worktree
+
+test_expect_success convert to v3 
+   git update-index --index-version=2
+
+subdir=$(git ls-files | sed 's#/[^/]*$##' | grep -v '^$' | uniq | tail -n 30 | 
head -1)
+file=$(git ls-files | tail -n 100 | head -1)
+
+test_expect_success modify a file 
+   echo 'foo bar' $file
+
+
+test_perf v[23]: update-index 
+   git update-index --index-version=2 /dev/null
+
+
+test_perf v[23]: grep nonexistent -- subdir 
+   test_must_fail git grep nonexistent -- $subdir /dev/null
+
+
+test_perf v[23]: ls-files -- subdir 
+   git ls-files $subdir /dev/null
+
+
+test_perf --cleanup git reset v[23]: update-index -- file 
+   git update-index $file
+
+
+test_expect_success convert to v4 
+   git update-index --index-version=4
+
+
+test_perf v4: update-index 
+   git update-index --index-version=4 /dev/null
+
+
+test_perf v4: grep nonexistent -- subdir 
+   test_must_fail git grep nonexistent -- $subdir /dev/null
+
+
+test_perf v4: ls-files -- subdir 
+   git ls-files $subdir /dev/null
+
+
+test_perf --cleanup git reset v4: update-index -- file 
+   git update-index $file
+
+
+test_done
-- 
1.8.3.4.1241.g1ce9896

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

What's cooking in git.git (Sep 2013, #07; Mon, 23)

What's cooking in git.git (Sep 2013, #07; Mon, 23)
--

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

The fifth batch of topics are in 'master'.

You can find the changes described here in the integration branches at

https://repo.or.cz/r/git/jrn.git

I am still catching up on patches sent since last week.  If I have
missed yours, do not despair, but feel free to send me a reminder to
look at it.

For those following along at home, the process used to build this
message is described in Documentation/howto/maintain-git.txt.  Maybe
some day someone will tweak the tools so they can be used by other
projects and more than a few people will know how to use them (hint,
hint).  In the meantime the documentation has been serving well as a
teacher.

--
[New Topics]

* bc/gnome-keyring (2013-09-23) 15 commits
 - contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring
 - contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring
 - contrib/git-credential-gnome-keyring.c: report failure to store password
 - contrib/git-credential-gnome-keyring.c: use glib messaging functions
 - contrib/git-credential-gnome-keyring.c: use glib memory allocation functions
 - contrib/git-credential-gnome-keyring.c: use secure memory for reading 
passwords
 - contrib/git-credential-gnome-keyring.c: use secure memory functions for 
passwds
 - contrib/git-credential-gnome-keyring.c: use gnome helpers in keyring_object()
 - contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty before 
accessing
 - contrib/git-credential-gnome-keyring.c: strlen() returns size_t, not ssize_t
 - contrib/git-credential-gnome-keyring.c: set Gnome application name
 - contrib/git-credential-gnome-keyring.c: exit non-zero when called incorrectly
 - contrib/git-credential-gnome-keyring.c: add static where applicable
 - contrib/git-credential-gnome-keyring.c: remove unused die() function
 - contrib/git-credential-gnome-keyring.c: remove unnecessary pre-declarations

 Cleanups and tweaks for credential handling to work with ancient versions
 of the gnome-keyring library that are still in use.
 
 This is version 1 of the series, to give it more exposure.  Waiting for
 the series to stabilize before including in 'next'.


* bp/mediawiki-infinite-loop-fix (2013-09-23) 1 commit
 - git-remote-mediawiki: bugfix for pages w/ 500 revisions

 The mediawiki:: remote helper would hang while handling results from
 queries with more than 500 results against version 1.21 or newer of
 the Mediawiki server.

 Will merge to 'maint'.

--
[Stalled]

* tr/merge-recursive-index-only (2013-07-07) 3 commits
 - merge-recursive: -Xindex-only to leave worktree unchanged
 - merge-recursive: untangle double meaning of o-call_depth
 - merge-recursive: remove dead conditional in update_stages()

 Will hold until there is a caller to learn from.


* jc/ref-excludes (2013-09-03) 2 commits
 - document --exclude option
 - revision: introduce --exclude=glob to tame wildcards

 People often wished a way to tell git log --branches (and git
 log --remotes --not --branches) to exclude some local branches
 from the expansion of --branches (similarly for --tags, --all
 and --glob=pattern).  Now they have one.

 Needs a matching change to rev-parse.


* rv/send-email-cache-generated-mid (2013-08-21) 2 commits
 - git-send-email: Cache generated message-ids, use them when prompting
 - git-send-email: add optional 'choices' parameter to the ask sub


* rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits
 - ### DONTMERGE: needs better explanation on what config they need
 - pack-refs.c: Add missing call to git_config()
 - show-ref.c: Add missing call to git_config()

 The changes themselves are probably good, but it is unclear what
 basic setting needs to be read for which exact operation.

 Waiting for clarification.
 $gmane/228294


* jh/shorten-refname (2013-05-07) 4 commits
 - t1514: refname shortening is done after dereferencing symbolic refs
 - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin
 - t1514: Demonstrate failure to correctly shorten refs/remotes/origin/HEAD
 - t1514: Add tests of shortening refnames in strict/loose mode

 When remotes/origin/HEAD is not a symbolic ref, rev-parse
 --abbrev-ref remotes/origin/HEAD ought to show origin, not
 origin/HEAD, which is fixed with this series (if it is a symbolic
 ref that points at remotes/origin/something, then it should show
 origin/something and it already does).

 Expecting a reroll, as an early part of a larger series.
 $gmane/225137


* mg/more-textconv (2013-05-10) 7 commits
 - grep: honor --textconv for the case rev:path
 - grep: allow to use textconv filters
 - t7008: demonstrate behavior of grep with

[PATCH] git-svn.txt: mention how to rebuild rev_map files

2013-09-23 Thread Keshav Kini

The man page for `git svn` describes a situation in which 'git svn'
will not be able to rebuild your .git/svn/**/.rev_map files, but no
mention is made of in what circumstances `git svn` *will* be able to do
so, or how to get `git svn` to do so.

This patch adds some language to the description of the 'fetch' command
to rectify this oversight, and also fixes an AsciiDoc escaping typo.

Signed-off-by: Keshav Kini keshav.k...@gmail.com
---
 Documentation/git-svn.txt | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 4dd3bcb..040117a 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -103,9 +103,12 @@ COMMANDS
 
 'fetch'::
Fetch unfetched revisions from the Subversion remote we are
-   tracking.  The name of the [svn-remote ...] section in the
-   .git/config file may be specified as an optional command-line
-   argument.
+   tracking.  If necessary, rebuild the .git/svn/\*\*/.rev_map.*
+   files, given the requisite information exists in commit
+   messages (see the svn.noMetadata config option for more
+   information).  The name of the [svn-remote ...] section in
+   the .git/config file may be specified as an optional
+   command-line argument.
 
 --localtime;;
Store Git commit times in the local timezone instead of UTC.  This
@@ -684,7 +687,7 @@ svn-remote.name.noMetadata::
 +
 This option can only be used for one-shot imports as 'git svn'
 will not be able to fetch again without metadata. Additionally,
-if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not
+if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not
 be able to rebuild them.
 +
 The 'git svn log' command will not work on repositories using
-- 
1.8.3.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: What's cooking in git.git (Sep 2013, #07; Mon, 23)

2013-09-23 Thread Stefan Beller

On 09/23/2013 11:10 PM, Jonathan Nieder wrote:
 You can find the changes described here in the integration branches at
 
 https://repo.or.cz/r/git/jrn.git
 
 I am still catching up on patches sent since last week.  If I have
 missed yours, do not despair, but feel free to send me a reminder to
 look at it.

How would I get these changes?
A plain 
git fetch https://repo.or.cz/r/git/jrn.git
doesn't work, as it yields:
fatal: unable to access 'https://repo.or.cz/r/git/jrn.git/': server certificate 
verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

So I'll try without security:
$ env GIT_SSL_NO_VERIFY=true git fetch https://repo.or.cz/r/git/jrn.git
fatal: Couldn't find remote ref HEAD
Unexpected end of command stream

I guess I'm doing it not quite right, so please enlighten me.
Thanks,
Stefan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] diff: add a config option to control orderfile

Hi,

Michael S. Tsirkin wrote:
 On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:

 A problem with both schemes, though, is that they are not
 backwards-compatible with existing git-patch-id implementations.
[...]
 It may be esoteric enough not to worry about, though.

Yeah, I think it would be okay.  Details of the diff generation
algorithm have changed from time to time anyway (and broken things,
as you mentioned) and we make no guarantee about this.

[...]
 patch-id: make it more stable

 Add a new patch-id algorithm making it stable against
 hunk reodering:
  - prepend header to each hunk (if not there)
  - calculate SHA1 hash for each hunk separately
  - sum all hashes to get patch id

 Add --order-sensitive to get historical unstable behaviour.

The --order-sensitive option seems confusing.  How do I use it to
replicate a historical patch-id?  If I record all options that might
have influenced ordering (which are those?) then am I guaranteed to
get a reproducible result?  

So I would prefer either of the following over the above:

 a) When asked to compute the patch-id of a seekable file, use the
current streaming implementation until you notice a filename that
is out of order.  Then start over with sorted hunks (for example
building a table of offsets within the patch for each hunk to
support this).

When asked to compute the patch-id of an unseekable file, stream
to a temporary file under $GIT_DIR to get a seekable file.

 b) Unconditionally use the new patch-id definition that is stable
under permutation of hunks.  If and when someone complains that
this invalidates their old patch-ids, they can work on adding a
nice interface for getting the old-style patch-ids.  I suspect it
just wouldn't come up.

Of course I can easily be wrong.  Thanks for a clear patch that makes
the choices easy to reasonable about.

Thoughts?
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: What's cooking in git.git (Sep 2013, #07; Mon, 23)

Stefan Beller wrote:
 On 09/23/2013 11:10 PM, Jonathan Nieder wrote:

 https://repo.or.cz/r/git/jrn.git
[...]
 How would I get these changes?
 A plain 
   git fetch https://repo.or.cz/r/git/jrn.git
 doesn't work, as it yields:
 fatal: unable to access 'https://repo.or.cz/r/git/jrn.git/': server 
 certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
 CRLfile: none

Thanks for noticing.  Hm, I'll bug the repo.or.cz admins about this.

The URL

git://repo.or.cz/git/jrn.git

should work for access by git protocol.  Web interface:
http://repo.or.cz/w/git/jrn.git

 So I'll try without security:
   $ env GIT_SSL_NO_VERIFY=true git fetch https://repo.or.cz/r/git/jrn.git
   fatal: Couldn't find remote ref HEAD

Fixed, thanks.  (I had left HEAD pointing to branch that doesn't
exist any more.)

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: What's cooking in git.git (Sep 2013, #07; Mon, 23)

Stefan Beller wrote:

   git fetch https://repo.or.cz/r/git/jrn.git
 doesn't work, as it yields:
 fatal: unable to access 'https://repo.or.cz/r/git/jrn.git/': server 
 certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
 CRLfile: none

Ah, figured it out.  http://repo.or.cz/h/rootcert.html explains.

Later this week I'll start pushing to multiple hosts, including github
which has a certificate signed by DigiCert.

Thanks again,
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: What's cooking in git.git (Sep 2013, #07; Mon, 23)

2013-09-23 Thread Kyle J. McKay


On Sep 23, 2013, at 14:54, Jonathan Nieder wrote:

Stefan Beller wrote:


git fetch https://repo.or.cz/r/git/jrn.git
doesn't work, as it yields:
fatal: unable to access 'https://repo.or.cz/r/git/jrn.git/': server  
certificate verification failed. CAfile: /etc/ssl/certs/ca- 
certificates.crt CRLfile: none


Ah, figured it out.  [1] http://repo.or.cz/h/rootcert.html explains.


The four possible fetch URLs are also listed on the http://repo.or.cz/w/git/jrn.git 
 page:


  git://repo.or.cz/git/jrn.git

  http://repo.or.cz/r/git/jrn.git

  ssh://repo.or.cz/srv/git/git/jrn.git

  https://repo.or.cz/r/git/jrn.git

As Jonathan has pointed out, fetching over https may require some  
additional setup as explained above [1].


Fetching using ssh can be accomplished without needing to create a  
user account by using the mob user as in the URL ssh://m...@repo.or.cz/srv/git/git/jrn.git 
.


The git: and http: URLs should work as-is for fetching.
--
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

Самое результативное средство в борьбе с излишним весом

2013-09-23 Thread anqelina-2012

Травяной чай представляется мощным естественным антиоксидантом 
http://jilc.net/fba5

Re: [PATCH v2 00/16] Make Gnome Credential helper more Gnome-y and support ancient distros

On Mon, Sep 23, 2013 at 11:49:01AM -0700, Brandon Casey wrote:

 Brandon Casey (16):
   contrib/git-credential-gnome-keyring.c: remove unnecessary
 pre-declarations
 [...]

Thanks, I think this is a good change. There were patches[1] from
Philipp about a year ago that went in the opposite direction, factoring
out common credential functions to be used by several helpers. We ended
up not merging them, because porting the wincred helper to the generic
implementation introduced complications.

And that was part of the reason for splitting out the helpers in the
first place: to let them worry about their own individual
system-specific quirks (and take advantage of system-specific helpers).
IOW, to make the gnome helper more gnome-y than git-y. And your patches
go in that direction, which I think is sane.

[1] http://thread.gmane.org/gmane.comp.version-control.git/204154/focus=204157

   contrib/git-credential-gnome-keyring.c: report failure to store
 password

Your subject lines are rather on the long side. I wonder if they would
be more readable as just:

  gnome-keyring: report failure to store password

and so forth. Anyone familiar with git.git knows that the contrib
and git-credential- bits are implied by gnome-keyring. But it's not
a huge deal either way.

 Inserts a patch to fix the style issues for block statements.
 i.e. use if () instead of if()

There are a ton of other style issues in the existing code (lack of
whitespace around operators and function arguments, and char* foo
instead of char *foo were the two I noticed). As a separate contrib/
project, I'm not that concerned, and I would say it is up to whoever is
nominally in charge of maintaining that contrib directory (Philipp or
John, in this case).

-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.txt: Fix asciidoc syntax of --*-pathspecs

On Mon, Sep 23, 2013 at 08:54:35PM +0200, Steffen Prohaska wrote:

 Labeled lists require a double colon.

Thanks, this looks good.

While looking at the git.txt source, I noticed it is quite awkward to
read due to the size of the stalenotes section. The patch below moves
that section out to its own file.

That section used to be turned on when Junio auto-built the
documentation after pushing to kernel.org. But he does not seem to do so
for recent versions of the auto-generated docs, as of commit adaa3ca on
the 'todo' branch. I don't know if that is a bug, or if the whole
stalenotes thing can simply go away.

-- 8 --
Subject: [PATCH] docs: split stalenotes out from git.txt

The git.txt manpage contains a section indicating the
current version, and pointing to release notes for past
versions. We don't usually include this version in the built
manpages, but anyone looking at the source needs to scroll
past it. Let's make it easier on them by splitting it out
into its own file.

Signed-off-by: Jeff King p...@peff.net
---
 Documentation/git.txt| 345 +--
 Documentation/stalenotes.txt | 344 ++
 2 files changed, 345 insertions(+), 344 deletions(-)
 create mode 100644 Documentation/stalenotes.txt

diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5d68d33..3d99668 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -34,350 +34,7 @@ can be viewed at 
`http://git-htmldocs.googlecode.com/git/git.html`.
 Formatted and hyperlinked version of the latest Git documentation
 can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`.
 
-ifdef::stalenotes[]
-[NOTE]
-
-
-You are reading the documentation for the latest (possibly
-unreleased) version of Git, that is available from 'master'
-branch of the `git.git` repository.
-Documentation for older releases are available here:
-
-* link:v1.8.4/git.html[documentation for release 1.8.4]
-
-* release notes for
-  link:RelNotes/1.8.4.txt[1.8.4].
-
-* link:v1.8.3.4/git.html[documentation for release 1.8.3.4]
-
-* release notes for
-  link:RelNotes/1.8.3.4.txt[1.8.3.4],
-  link:RelNotes/1.8.3.3.txt[1.8.3.3],
-  link:RelNotes/1.8.3.2.txt[1.8.3.2],
-  link:RelNotes/1.8.3.1.txt[1.8.3.1],
-  link:RelNotes/1.8.3.txt[1.8.3].
-
-* link:v1.8.2.3/git.html[documentation for release 1.8.2.3]
-
-* release notes for
-  link:RelNotes/1.8.2.3.txt[1.8.2.3],
-  link:RelNotes/1.8.2.2.txt[1.8.2.2],
-  link:RelNotes/1.8.2.1.txt[1.8.2.1],
-  link:RelNotes/1.8.2.txt[1.8.2].
-
-* link:v1.8.1.6/git.html[documentation for release 1.8.1.6]
-
-* release notes for
-  link:RelNotes/1.8.1.6.txt[1.8.1.6],
-  link:RelNotes/1.8.1.5.txt[1.8.1.5],
-  link:RelNotes/1.8.1.4.txt[1.8.1.4],
-  link:RelNotes/1.8.1.3.txt[1.8.1.3],
-  link:RelNotes/1.8.1.2.txt[1.8.1.2],
-  link:RelNotes/1.8.1.1.txt[1.8.1.1],
-  link:RelNotes/1.8.1.txt[1.8.1].
-
-* link:v1.8.0.3/git.html[documentation for release 1.8.0.3]
-
-* release notes for
-  link:RelNotes/1.8.0.3.txt[1.8.0.3],
-  link:RelNotes/1.8.0.2.txt[1.8.0.2],
-  link:RelNotes/1.8.0.1.txt[1.8.0.1],
-  link:RelNotes/1.8.0.txt[1.8.0].
-
-* link:v1.7.12.4/git.html[documentation for release 1.7.12.4]
-
-* release notes for
-  link:RelNotes/1.7.12.4.txt[1.7.12.4],
-  link:RelNotes/1.7.12.3.txt[1.7.12.3],
-  link:RelNotes/1.7.12.2.txt[1.7.12.2],
-  link:RelNotes/1.7.12.1.txt[1.7.12.1],
-  link:RelNotes/1.7.12.txt[1.7.12].
-
-* link:v1.7.11.7/git.html[documentation for release 1.7.11.7]
-
-* release notes for
-  link:RelNotes/1.7.11.7.txt[1.7.11.7],
-  link:RelNotes/1.7.11.6.txt[1.7.11.6],
-  link:RelNotes/1.7.11.5.txt[1.7.11.5],
-  link:RelNotes/1.7.11.4.txt[1.7.11.4],
-  link:RelNotes/1.7.11.3.txt[1.7.11.3],
-  link:RelNotes/1.7.11.2.txt[1.7.11.2],
-  link:RelNotes/1.7.11.1.txt[1.7.11.1],
-  link:RelNotes/1.7.11.txt[1.7.11].
-
-* link:v1.7.10.5/git.html[documentation for release 1.7.10.5]
-
-* release notes for
-  link:RelNotes/1.7.10.5.txt[1.7.10.5],
-  link:RelNotes/1.7.10.4.txt[1.7.10.4],
-  link:RelNotes/1.7.10.3.txt[1.7.10.3],
-  link:RelNotes/1.7.10.2.txt[1.7.10.2],
-  link:RelNotes/1.7.10.1.txt[1.7.10.1],
-  link:RelNotes/1.7.10.txt[1.7.10].
-
-* link:v1.7.9.7/git.html[documentation for release 1.7.9.7]
-
-* release notes for
-  link:RelNotes/1.7.9.7.txt[1.7.9.7],
-  link:RelNotes/1.7.9.6.txt[1.7.9.6],
-  link:RelNotes/1.7.9.5.txt[1.7.9.5],
-  link:RelNotes/1.7.9.4.txt[1.7.9.4],
-  link:RelNotes/1.7.9.3.txt[1.7.9.3],
-  link:RelNotes/1.7.9.2.txt[1.7.9.2],
-  link:RelNotes/1.7.9.1.txt[1.7.9.1],
-  link:RelNotes/1.7.9.txt[1.7.9].
-
-* link:v1.7.8.6/git.html[documentation for release 1.7.8.6]
-
-* release notes for
-  link:RelNotes/1.7.8.6.txt[1.7.8.6],
-  link:RelNotes/1.7.8.5.txt[1.7.8.5],
-  link:RelNotes/1.7.8.4.txt[1.7.8.4],
-  link:RelNotes/1.7.8.3.txt[1.7.8.3],
-  link:RelNotes/1.7.8.2.txt[1.7.8.2],
-  link:RelNotes/1.7.8.1.txt[1.7.8.1],
-  link:RelNotes/1.7.8.txt[1.7.8].
-
-* link:v1.7.7.7/git.html[documentation for release 1.7.7.7]
-
-*

Re: Using alternate working directory

2013-09-23 Thread Ram Rachum


Does anyone care to help? I'd really like to solve this  :(

On 22/9/2013 00:04, Ram Rachum wrote:

Hi everybody!

I need some help with Git.

I'm making a script `gm` which lets me merge one branch into another 
without having either checked out. It works for some cases but not 
all. I'm trying to make it work for more cases.


I concluded that the best way to do it would be by using an alternate, 
temporary working directory instead of the repo itself.


This is my script:

https://gist.github.com/cool-RR/6575042

Now, the problem is that when I try it, it gives these errors:

git checkout-index: my_file is not in the cache and then error:
my_file: cannot add to the index - missing --add option?

Anyone has any idea what to do?

P.S. I've also asked this on Stack Overflow, so whoever comes up with 
an answer can claim his 150 imaginary internet points on that question.



Thanks,
Ram.


--
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 v3] build: add default aliases

On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:

 For now simply add a few common aliases.
 
   co = checkout
   ci = commit
   rb = rebase
   st = status

Are these the best definitions of those shortcuts? It seems[1] that some
people define ci as commit -a, and some people define st as
status -s or even status -sb.

You are making things more consistent for people who already define
those aliases in the same way (they are available everywhere, even if
they have not moved their config to a new installation), but less so for
people who define them differently. Rather than get an obvious:

  git: 'co' is not a git command. See 'git --help'.

the result will be subtly different (especially so in the case of
commit versus commit -a).

-Peff

[1] 
https://github.com/search?q=%22ci+%3D+commit+-a%22+path%3A.gitconfigtype=Code

https://github.com/search?q=%22st+%3D+status+-s%22type=Code

https://github.com/search?q=%22st+%3D+status+-sb%22type=Code
--
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: Using alternate working directory

On Sun, Sep 22, 2013 at 12:04:24AM +0300, Ram Rachum wrote:

 I'm making a script `gm` which lets me merge one branch into another
 without having either checked out. It works for some cases but not
 all. I'm trying to make it work for more cases.
 
 I concluded that the best way to do it would be by using an
 alternate, temporary working directory instead of the repo itself.

Yes, otherwise you will be stomping all over the working tree of
whatever branch _is_ checked out.

 This is my script:
 
 https://gist.github.com/cool-RR/6575042
 
 Now, the problem is that when I try it, it gives these errors:
 
 git checkout-index: my_file is not in the cache and then error:
 my_file: cannot add to the index - missing --add option?
 
 Anyone has any idea what to do?

Your script is quite similar to the one that is used server-side at
GitHub to generate the this can be merged button for each pull
request. So it should work in principle.

Just a guess, but using a relative path for the temporary index file
might be a problem. read-tree will operate from $GIT_DIR as its working
directory, for example, but I think the git-merge-one-file script will
be at the top-level of $GIT_WORK_TREE. Meaning that all of the
sub-commands it runs will see an empty index.

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

Re: [PATCH 1/2] fetch: add missing documentation

On Sat, Sep 21, 2013 at 09:09:22AM -0500, Felipe Contreras wrote:

 There's no mention of the 'origin' default, or the fact that the
 upstream tracking branch remote is used.

Sounds like a good thing to mention.

 diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
 index e08a028..7e75dc4 100644
 --- a/Documentation/git-fetch.txt
 +++ b/Documentation/git-fetch.txt
 @@ -37,6 +37,9 @@ or from several repositories at once if group is given and
  there is a remotes.group entry in the configuration file.
  (See linkgit:git-config[1]).
  
 +When no remote is specified, by the default the `origin` remote will be used,

s/the (default the)/\1/

 +unless there's an upstream branch configured for the current branch.

Should this be upstream remote rather than upstream branch? I don't
think we should be looking at branch.*.merge at all for git-fetch.

-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 2/2] remote: fix trivial memory leak

On Sat, Sep 21, 2013 at 09:09:23AM -0500, Felipe Contreras wrote:

 diff --git a/remote.c b/remote.c
 index efcba93..654e7f5 100644
 --- a/remote.c
 +++ b/remote.c
 @@ -480,7 +480,6 @@ static void read_config(void)
   int flag;
   if (default_remote_name) /* did this already */
   return;
 - default_remote_name = xstrdup(origin);
   current_branch = NULL;
   head_ref = resolve_ref_unsafe(HEAD, sha1, 0, flag);
   if (head_ref  (flag  REF_ISSYMREF) 
 @@ -489,6 +488,8 @@ static void read_config(void)
   make_branch(head_ref + strlen(refs/heads/), 0);
   }
   git_config(handle_config, NULL);
 + if (!default_remote_name)
 + default_remote_name = xstrdup(origin);
   alias_all_urls();

I wondered if we might also leak when seeing duplicate config options
(i.e., leaking the old one when replacing it with the new). But we don't
actually strdup() the configured remote names, but instead just point
into the struct branch, which owns the data.

So I think an even better fix would be:

-- 8 --
Subject: remote: do not copy origin string literal

Our default_remote_name starts at origin, but may be
overridden by the config file. In the former case, we
allocate a new string, but in the latter case, we point to
the remote name in an existing struct branch.

This gives the variable inconsistent free() semantics (we
are sometimes responsible for freeing the string and
sometimes pointing to somebody else's storage), and causes a
small leak when the allocated string is overridden by
config.

We can fix both by simply dropping the extra copy and
pointing to the string literal.

Noticed-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
 remote.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/remote.c b/remote.c
index e9fedfa..9f1a8aa 100644
--- a/remote.c
+++ b/remote.c
@@ -483,7 +483,7 @@ static void read_config(void)
int flag;
if (default_remote_name) /* did this already */
return;
-   default_remote_name = xstrdup(origin);
+   default_remote_name = origin;
current_branch = NULL;
head_ref = resolve_ref_unsafe(HEAD, sha1, 0, flag);
if (head_ref  (flag  REF_ISSYMREF) 
-- 
1.8.4.rc3.19.g9da5bf6

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

Re: [PATCH 1/2] fetch: add missing documentation

On Tue, Sep 24, 2013 at 12:03 AM, Jeff King p...@peff.net wrote:
 On Sat, Sep 21, 2013 at 09:09:22AM -0500, Felipe Contreras wrote:

 There's no mention of the 'origin' default, or the fact that the
 upstream tracking branch remote is used.

 Sounds like a good thing to mention.

 diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
 index e08a028..7e75dc4 100644
 --- a/Documentation/git-fetch.txt
 +++ b/Documentation/git-fetch.txt
 @@ -37,6 +37,9 @@ or from several repositories at once if group is given 
 and
  there is a remotes.group entry in the configuration file.
  (See linkgit:git-config[1]).

 +When no remote is specified, by the default the `origin` remote will be 
 used,

 s/the (default the)/\1/

Right.

 +unless there's an upstream branch configured for the current branch.

 Should this be upstream remote rather than upstream branch? I don't
 think we should be looking at branch.*.merge at all for git-fetch.

As a general user, how do I configure the upstream remote?

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

Re: [PATCH 1/2] fetch: add missing documentation

On Tue, Sep 24, 2013 at 12:23:21AM -0500, Felipe Contreras wrote:

  Should this be upstream remote rather than upstream branch? I don't
  think we should be looking at branch.*.merge at all for git-fetch.
 
 As a general user, how do I configure the upstream remote?

Yeah, it's not a term we use elsewhere, so it's not great. Probably
default remote would be better, or even just say branch.*.remote for
the current branch or something.

I dunno. I don't particularly like any of those, but I really dislike
the imprecision of upstream branch in this case.

-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 v3] build: add default aliases

On Mon, Sep 23, 2013 at 11:53 PM, Jeff King p...@peff.net wrote:
 On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:

 For now simply add a few common aliases.

   co = checkout
   ci = commit
   rb = rebase
   st = status

 Are these the best definitions of those shortcuts? It seems[1] that some
 people define ci as commit -a, and some people define st as
 status -s or even status -sb.

 You are making things more consistent for people who already define
 those aliases in the same way (they are available everywhere, even if
 they have not moved their config to a new installation), but less so for
 people who define them differently. Rather than get an obvious:

   git: 'co' is not a git command. See 'git --help'.

 the result will be subtly different (especially so in the case of
 commit versus commit -a).

Before:

# machine A: git ci
git: 'ca' is not a git command. See 'git --help'.

# machine B: git ci
commits

After:

# machine A: git ci
no changes added to commit (use git add and/or git commit -a)

# machine B: git ci
commits

The after part is much more consistent, at least several commands
have a higher chance of doing what the user actually wants, at worst
they would do something close to what the user wants.

-- 
Felipe Contreras
--
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-compat-util: Avoid strcasecmp() being inlined

On Fri, Sep 20, 2013 at 08:21:04AM +0200, Piotr Krukowiecki wrote:

 I can't think off-hand of a way to do so using preprocessor tricks, and
 even if we could, I suspect the result would end up quite ugly. 
 
 What I meant was: can we add a test (in t/) which greps git source
 code and fails if it finds strcasecmp string?
 
 It could count number of strcasecmp and expect to find only 1 or
 exclude  known location of the wrapper.

No, because it is perfectly fine (and desirable) to use strcasecmp as a
function, just not as a function pointer. Telling the difference would
involve minor parsing of C.

So I think the least bad thing is to simply catch it in review, or by
testing on affected platforms.

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

Re: [PATCH 1/2] fetch: add missing documentation

On Tue, Sep 24, 2013 at 12:30 AM, Jeff King p...@peff.net wrote:
 On Tue, Sep 24, 2013 at 12:23:21AM -0500, Felipe Contreras wrote:

  Should this be upstream remote rather than upstream branch? I don't
  think we should be looking at branch.*.merge at all for git-fetch.

 As a general user, how do I configure the upstream remote?

 Yeah, it's not a term we use elsewhere, so it's not great. Probably
 default remote would be better, or even just say branch.*.remote for
 the current branch or something.

Yeah, general users don't know what you are talking about when you say that.

 I dunno. I don't particularly like any of those, but I really dislike
 the imprecision of upstream branch in this case.

For most users it's the remote configured by:

% git branch --set-upstream-to foo
% git checkout -b foo origin/foo
% git checkout -t -b foo bar

So when they read upstream branch they know from where it got configured.

-- 
Felipe Contreras
--
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 v3] build: add default aliases

On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote:

  You are making things more consistent for people who already define
  those aliases in the same way (they are available everywhere, even if
  they have not moved their config to a new installation), but less so for
  people who define them differently. Rather than get an obvious:
 
git: 'co' is not a git command. See 'git --help'.
 
  the result will be subtly different (especially so in the case of
  commit versus commit -a).
 
 Before:
 
 # machine A: git ci
 git: 'ca' is not a git command. See 'git --help'.
 
 # machine B: git ci
 commits
 
 After:
 
 # machine A: git ci
 no changes added to commit (use git add and/or git commit -a)
 
 # machine B: git ci
 commits

That is the output if there are no files to commit. What about while
resolving a merge, or after using git add on a path? In that case we
create a commit, but it is subtly different than what the user intended.

I think for the merge case, it is probably OK, as the surprise should
always go in the safe direction (user expects commit -a, gets
commit, and commit balks). But the other omits intended files from the
commit.

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

Re: [PATCH 1/2] fetch: add missing documentation

On Tue, Sep 24, 2013 at 12:36:38AM -0500, Felipe Contreras wrote:

  Yeah, it's not a term we use elsewhere, so it's not great. Probably
  default remote would be better, or even just say branch.*.remote for
  the current branch or something.
 
 Yeah, general users don't know what you are talking about when you say that.

Right, I understand your complaint and agree that those terms are
potentially confusing.

  I dunno. I don't particularly like any of those, but I really dislike
  the imprecision of upstream branch in this case.
 
 For most users it's the remote configured by:
 
 % git branch --set-upstream-to foo
 % git checkout -b foo origin/foo
 % git checkout -t -b foo bar
 
 So when they read upstream branch they know from where it got configured.

Yes, but it is also wrong, in the sense that the upstream branch is
unrelated. You are giving breadcrumbs to users who know upstream
branch as a concept and nothing else, but you are misleading users who
know that branch.*.remote exists.

I was hoping you might suggest something that can help both users by
being both precise and giving the appropriate breadcrumbs.

-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] diff: add a config option to control orderfile

On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:

  Add --order-sensitive to get historical unstable behaviour.
 
 The --order-sensitive option seems confusing.  How do I use it to
 replicate a historical patch-id?  If I record all options that might
 have influenced ordering (which are those?) then am I guaranteed to
 get a reproducible result?  

Yes, I have the same complaint. I'd much rather the classic mode be
given a name of some sort, and then have a --patch-id-mode=classic
parameter (or probably some better name) that sets all of the
parameters. Then you know that two implementations using classic
should get the same output, and so forth if we have to tweak it again.

 So I would prefer either of the following over the above:
 
  a) When asked to compute the patch-id of a seekable file, use the
 current streaming implementation until you notice a filename that
 is out of order.  Then start over with sorted hunks (for example
 building a table of offsets within the patch for each hunk to
 support this).
 
 When asked to compute the patch-id of an unseekable file, stream
 to a temporary file under $GIT_DIR to get a seekable file.

This would mean that everybody, whether they care about compatibility or
not, would have to pay the price to spool to $GIT_DIR, right? That's not
great, as most cases would not care.

  b) Unconditionally use the new patch-id definition that is stable
 under permutation of hunks.  If and when someone complains that
 this invalidates their old patch-ids, they can work on adding a
 nice interface for getting the old-style patch-ids.  I suspect it
 just wouldn't come up.

I think I'd prefer this one. The --patch-id-mode above is how I would
do it, and in general when we are potentially breaking compatibility,
it's nice to anticipate and give an escape hatch. But I do find it
reasonably unlikely that this will come up, so maybe this is a good time
to practice YAGNI.

-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 v3] build: add default aliases

On Tue, Sep 24, 2013 at 12:37 AM, Jeff King p...@peff.net wrote:
 On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote:

  You are making things more consistent for people who already define
  those aliases in the same way (they are available everywhere, even if
  they have not moved their config to a new installation), but less so for
  people who define them differently. Rather than get an obvious:
 
git: 'co' is not a git command. See 'git --help'.
 
  the result will be subtly different (especially so in the case of
  commit versus commit -a).

 Before:

 # machine A: git ci
 git: 'ca' is not a git command. See 'git --help'.

 # machine B: git ci
 commits

 After:

 # machine A: git ci
 no changes added to commit (use git add and/or git commit -a)

 # machine B: git ci
 commits

 That is the output if there are no files to commit. What about while
 resolving a merge, or after using git add on a path? In that case we
 create a commit, but it is subtly different than what the user intended.

It might be different, but it might not.

Anyway, if you are so worried about this hypothetical user not
noticing that 'git ci' didn't commit all the files, we could ma ci to
'git commit -v' so we are being straightforward to the user as to what
is being committed.

-- 
Felipe Contreras
--
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] diff: add a config option to control orderfile

2013-09-23 Thread Michael S. Tsirkin

On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
 Hi,
 
 Michael S. Tsirkin wrote:
  On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
 
  A problem with both schemes, though, is that they are not
  backwards-compatible with existing git-patch-id implementations.
 [...]
  It may be esoteric enough not to worry about, though.
 
 Yeah, I think it would be okay.  Details of the diff generation
 algorithm have changed from time to time anyway (and broken things,
 as you mentioned) and we make no guarantee about this.
 
 [...]
  patch-id: make it more stable
 
  Add a new patch-id algorithm making it stable against
  hunk reodering:
 - prepend header to each hunk (if not there)
 - calculate SHA1 hash for each hunk separately
 - sum all hashes to get patch id
 
  Add --order-sensitive to get historical unstable behaviour.
 
 The --order-sensitive option seems confusing.  How do I use it to
 replicate a historical patch-id?

You supply a historical diff to it :)

 If I record all options that might
 have influenced ordering (which are those?) then am I guaranteed to
 get a reproducible result?  

Maybe not. But if you have a patch on disk, you will get
old hash from it with --order-sensitive.

 So I would prefer either of the following over the above:
 
  a) When asked to compute the patch-id of a seekable file, use the
 current streaming implementation until you notice a filename that
 is out of order.  Then start over with sorted hunks (for example
 building a table of offsets within the patch for each hunk to
 support this).
 
 When asked to compute the patch-id of an unseekable file, stream
 to a temporary file under $GIT_DIR to get a seekable file.

This can be computed in one pass: just keep two checksums around.

But the result won't be stable: if you get same patch from two
people one is ordered, the other isn't, you get two different checksums.

What are we trying to achieve here?


  b) Unconditionally use the new patch-id definition that is stable
 under permutation of hunks.  If and when someone complains that
 this invalidates their old patch-ids, they can work on adding a
 nice interface for getting the old-style patch-ids.  I suspect it
 just wouldn't come up.

That's certainly easy to implement.

 Of course I can easily be wrong.  Thanks for a clear patch that makes
 the choices easy to reasonable about.
 
 Thoughts?
 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 1/2] fetch: add missing documentation