Re: [PATCH] credential-libsecret: unlock locked secrets
On Fri, Nov 3, 2017 at 10:44 PM, Dennis Kaarsemaker wrote: > Credentials exposed by the secret service DBUS interface may be locked. > Setting the SECRET_SEARCH_UNLOCK flag will make the secret service > unlock these secrets, possibly prompting the user for credentials to do > so. Without this flag, the secret is simply not loaded. > > Signed-off-by: Dennis Kaarsemaker > --- > contrib/credential/libsecret/git-credential-libsecret.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/contrib/credential/libsecret/git-credential-libsecret.c > b/contrib/credential/libsecret/git-credential-libsecret.c > index 4c56979d8a..b4750c9ee8 100644 > --- a/contrib/credential/libsecret/git-credential-libsecret.c > +++ b/contrib/credential/libsecret/git-credential-libsecret.c > @@ -104,7 +104,7 @@ static int keyring_get(struct credential *c) > items = secret_service_search_sync(service, >SECRET_SCHEMA_COMPAT_NETWORK, >attributes, > - SECRET_SEARCH_LOAD_SECRETS, > + SECRET_SEARCH_LOAD_SECRETS | > SECRET_SEARCH_UNLOCK, >NULL, >&error); > g_hash_table_unref(attributes); > -- > 2.15.0-rc2-464-gb5de734 > Looks okay. (It seems that's what all other programs do, too...) -- Mantas Mikulėnas
Re: How do you script linux GIT client to pass kerberos credential to apache enabled GIT server?
On 2017-04-03 19:04, ken edward wrote: > Hello, > > I have my git repositories behind an apache server configured with > kerberos. Works fine if the user is logged in on their workstation. > Apache gets the kerberos credential, and validates, and then sends > the GIT repo being requested. > > BUT, I want to write a script on linux that will also pass the > kerberos credential to the apache GIT server without having any > manually intervention. Seems I would create a kerberos keytab for the > principal and then use that to authenticate kinit supports > authenticating from a keytab using the -k -t options, kinit works, but I think kstart [1] is commonly used for this as well; takes care of automatic ticket renewal. ktutil should be able to create a keytab based on your password, but I've had mixed luck with that. Though still probably easier than creating a separate instance just for batch tasks... [1]: https://www.eyrie.org/~eagle/software/kstart/ -- Mantas Mikulėnas
Re: [PATCH] http(s): automatically try NTLM authentication first
On 2017-02-23 03:03, David Turner wrote: > Actually, though, I am not sure this is as bad as it seems, because gssapi > might protect us. When I locally tried a fake server, git (libcurl) refused > to > send my Kerberos credentials because "Server not found in Kerberos > database". I don't have a machine set up with NTLM authentication > (because, apparently, that would be insane), so I don't know how to > confirm that gssapi would operate off of a whitelist for NTLM as well. NTLM and Kerberos work very differently in that regard. Kerberos is ticket-based so the client *first* has to obtain a ticket from the domain's KDC, so a malicious server at minimum needs to know what principal name to provide (i.e. which real server to try impersonating). And even if it does that, the ticket doesn't contain crackable hashes, just data encrypted with a key known only to the KDC and the real server. So the whitelist is only for privacy and/or performance reasons, I guess? NTLM is challenge/response without any third party, and yes, it requires the application to implement its own whitelisting to avoid the security problems. -- Mantas Mikulėnas
Re: [PATCH] contrib: add credential helper for libsecret
On 2016-10-11 22:48, Mantas Mikulėnas wrote: > On 2016-10-11 22:36, Junio C Hamano wrote: >> Thanks for a review. I'll wait until one of (1) a squashable patch >> to address the "we do not want unconditional overwrite" issue, (2) a >> reroll from Mantas to do the same, or (3) a counter-argument from >> somebody to explain why unconditional overwrite is a good idea here >> (but not in the original) appears. > > I overlooked that. I can write a patch, but it shouldn't make any > difference in practice – if c->username *was* set, then it would also > get added to the search attribute list, therefore the search couldn't > possibly return any results with a different username anyway. On a second thought, it doesn't actually make sense _not_ to override the username. Let's say the search query *somehow* returned a different account than requested. With the original (gnome-keyring helper's) behavior, the final output would have the old account's username, but the new account's password – which has very little chance of working. -- Mantas Mikulėnas
Re: [PATCH] contrib: add credential helper for libsecret
On 2016-10-11 22:36, Junio C Hamano wrote: > Thanks for a review. I'll wait until one of (1) a squashable patch > to address the "we do not want unconditional overwrite" issue, (2) a > reroll from Mantas to do the same, or (3) a counter-argument from > somebody to explain why unconditional overwrite is a good idea here > (but not in the original) appears. I overlooked that. I can write a patch, but it shouldn't make any difference in practice – if c->username *was* set, then it would also get added to the search attribute list, therefore the search couldn't possibly return any results with a different username anyway. -- Mantas Mikulėnas
[PATCH] contrib: add credential helper for libsecret
This is based on the existing gnome-keyring helper, but instead of
libgnome-keyring (which was specific to GNOME and is deprecated), it
uses libsecret which can support other implementations of XDG Secret
Service API.
Passes t0303-credential-external.sh.
Signed-off-by: Mantas Mikulėnas
---
contrib/credential/libsecret/Makefile | 25 ++
.../libsecret/git-credential-libsecret.c | 370 +
2 files changed, 395 insertions(+)
create mode 100644 contrib/credential/libsecret/Makefile
create mode 100644 contrib/credential/libsecret/git-credential-libsecret.c
diff --git a/contrib/credential/libsecret/Makefile
b/contrib/credential/libsecret/Makefile
new file mode 100644
index ..3e67552cc5b5
--- /dev/null
+++ b/contrib/credential/libsecret/Makefile
@@ -0,0 +1,25 @@
+MAIN:=git-credential-libsecret
+all:: $(MAIN)
+
+CC = gcc
+RM = rm -f
+CFLAGS = -g -O2 -Wall
+PKG_CONFIG = pkg-config
+
+-include ../../../config.mak.autogen
+-include ../../../config.mak
+
+INCS:=$(shell $(PKG_CONFIG) --cflags libsecret-1 glib-2.0)
+LIBS:=$(shell $(PKG_CONFIG) --libs libsecret-1 glib-2.0)
+
+SRCS:=$(MAIN).c
+OBJS:=$(SRCS:.c=.o)
+
+%.o: %.c
+ $(CC) $(CFLAGS) $(CPPFLAGS) $(INCS) -o $@ -c $<
+
+$(MAIN): $(OBJS)
+ $(CC) -o $@ $(LDFLAGS) $^ $(LIBS)
+
+clean:
+ @$(RM) $(MAIN) $(OBJS)
diff --git a/contrib/credential/libsecret/git-credential-libsecret.c
b/contrib/credential/libsecret/git-credential-libsecret.c
new file mode 100644
index ..4c56979d8a08
--- /dev/null
+++ b/contrib/credential/libsecret/git-credential-libsecret.c
@@ -0,0 +1,370 @@
+/*
+ * Copyright (C) 2011 John Szakmeister
+ * 2012 Philipp A. Hartmann
+ * 2016 Mantas Mikulėnas
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/*
+ * Credits:
+ * - GNOME Keyring API handling originally written by John Szakmeister
+ * - ported to credential helper API by Philipp A. Hartmann
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * This credential struct and API is simplified from git's credential.{h,c}
+ */
+struct credential {
+ char *protocol;
+ char *host;
+ unsigned short port;
+ char *path;
+ char *username;
+ char *password;
+};
+
+#define CREDENTIAL_INIT { NULL, NULL, 0, NULL, NULL, NULL }
+
+typedef int (*credential_op_cb)(struct credential *);
+
+struct credential_operation {
+ char *name;
+ credential_op_cb op;
+};
+
+#define CREDENTIAL_OP_END { NULL, NULL }
+
+/* - Secret Service functions - */
+
+static char *make_label(struct credential *c)
+{
+ if (c->port)
+ return g_strdup_printf("Git: %s://%s:%hu/%s",
+ c->protocol, c->host, c->port, c->path
? c->path : "");
+ else
+ return g_strdup_printf("Git: %s://%s/%s",
+ c->protocol, c->host, c->path ? c->path
: "");
+}
+
+static GHashTable *make_attr_list(struct credential *c)
+{
+ GHashTable *al = g_hash_table_new_full(g_str_hash, g_str_equal, NULL,
g_free);
+
+ if (c->username)
+ g_hash_table_insert(al, "user", g_strdup(c->username));
+ if (c->protocol)
+ g_hash_table_insert(al, "protocol", g_strdup(c->protocol));
+ if (c->host)
+ g_hash_table_insert(al, "server", g_strdup(c->host));
+ if (c->port)
+ g_hash_table_insert(al, "port", g_strdup_printf("%hu",
c->port));
+ if (c->path)
+ g_hash_table_insert(al, "object", g_strdup(c->path));
+
+ return al;
+}
+
+static int keyring_get(struct credential *c)
+{
+ SecretService *service = NULL;
+ GHashTable *attributes = NULL;
+ GError *error = NULL;
+ GList *items = NULL;
+
+ if (!c->protocol || !(c->host || c->path))
+ return EXIT_FAILURE;
+
+ service = secret_service_get_sync(0, NULL, &error);
+ if (error != NULL) {
+ g_critical("could not connect to Secret Service: %s",
er
Re: Segfault in `git describe`
On Mon, Jul 15, 2013 at 4:03 PM, Michael Haggerty wrote: > On 07/13/2013 03:27 PM, Mantas Mikulėnas wrote: >> I have a clone of linux.git with various stuff added to it (remotes for >> 'stable' and 'next', a bunch of local tags, and historical repositories >> imported using `git replace`). >> >> Yesterday, I noticed that `git describe`, built from git.git master >> (v1.8.3.2-804-g0da7a53, gcc 4.8) would simply crash when run in that >> repository, with the following backtrace: >> >>> Program terminated with signal 11, Segmentation fault. >>> #0 0x004c39dc in hashcpy (sha_src=0x1c >> bounds>, >>> sha_dst=0x7fffc0b4d610 "\242\271\301\366 >>> \201&\346\337l\002B\214P\037\210ShX\022") >>> at cache.h:694 >>> 694 memcpy(sha_dst, sha_src, 20); >>> (gdb) bt >>> #0 0x004c39dc in hashcpy (sha_src=0x1c >> bounds>, >>> sha_dst=0x7fffc0b4d610 "\242\271\301\366 >>> \201&\346\337l\002B\214P\037\210ShX\022") >>> at cache.h:694 >>> #1 peel_ref (refname=refname@entry=0x1fe2d10 "refs/tags/next-20130607", >>> sha1=sha1@entry=0x7fffc0b4d610 "\242\271\301\366 >>> \201&\346\337l\002B\214P\037\210ShX\022") at refs.c:1586 >>> #2 0x00424194 in get_name (path=0x1fe2d10 >>> "refs/tags/next-20130607", >>> sha1=0x1fe2ce8 >>> "\222V\356\276S5\tk\231Hi\264\r=\336\315\302\225\347\257\300N\376\327\064@\237ZDq[T\246\312\033T\260\314\362\025refs/tags/next-20130607", >>> flag=, >>> cb_data=) at builtin/describe.c:156 >>> #3 0x004c1c21 in do_one_ref (entry=0x1fe2ce0, >>> cb_data=0x7fffc0b4d7c0) >>> at refs.c:646 >>> #4 0x004c318d in do_for_each_entry_in_dir (dir=0x1fe1728, >>> offset=, fn=0x4c1bc0 , >>> cb_data=0x7fffc0b4d7c0) >>> at refs.c:672 >>> #5 0x004c33d1 in do_for_each_entry_in_dirs (dir1=0x1fdf4d8, >>> dir2=0x1fd6318, >>> cb_data=0x7fffc0b4d7c0, fn=0x4c1bc0 ) at refs.c:716 >>> #6 0x004c33d1 in do_for_each_entry_in_dirs (dir1=0x1fdf1f8, >>> dir2=0x1fd62d8, >>> cb_data=0x7fffc0b4d7c0, fn=0x4c1bc0 ) at refs.c:716 >>> #7 0x004c3540 in do_for_each_entry (refs=refs@entry=0x7a2800 >>> , >>> base=base@entry=0x509cc6 "", cb_data=cb_data@entry=0x7fffc0b4d7c0, >>> fn=0x4c1bc0 ) at refs.c:1689 >>> #8 0x004c3ff8 in do_for_each_ref (cb_data=cb_data@entry=0x0, >>> flags=1, trim=0, >>> fn=fn@entry=0x424120 , base=0x509cc6 "", refs=0x7a2800 >>> ) >>> at refs.c:1724 >>> #9 for_each_rawref (fn=fn@entry=0x424120 , >>> cb_data=cb_data@entry=0x0) >>> at refs.c:1873 >>> #10 0x00424f5b in cmd_describe (argc=0, argv=0x7fffc0b4ddc0, >>> prefix=0x0) >>> at builtin/describe.c:466 >>> #11 0x0040596d in run_builtin (argv=0x7fffc0b4ddc0, argc=1, >>> p=0x760b40 ) at git.c:291 >>> #12 handle_internal_command (argc=1, argv=0x7fffc0b4ddc0) at git.c:453 >>> #13 0x00404d6e in run_argv (argv=0x7fffc0b4dc78, >>> argcp=0x7fffc0b4dc5c) >>> at git.c:499 >>> #14 main (argc=1, av=) at git.c:575 >>> (gdb) >> >> According to `git bisect`, the first bad commit is: >> >> commit 9a489f3c17d6c974b18c47cf406404ca2a721c87 >> Author: Michael Haggerty >> Date: Mon Apr 22 21:52:22 2013 +0200 >> >> refs: extract a function peel_entry() >> >> The crash happens only in repositories that have at least one replaced >> object in the branch's history. Running `git --no-replace-objects >> describe` avoids the crash. >> >> The crash happens only if there are any tags under .git/refs/tags/ that >> do not exist in .git/packed-refs, or if I remove all "peeled" lines from >> .git/packed-refs (including the '#' line; /^[#^]/d). >> >> A quick way to reproduce this with git.git master is: >> >> git tag -f test-tag HEAD~10 >> git replace -f HEAD $(git --no-replace-objects cat-file commit HEAD \ >> | sed 's/@/@test/' | git hash-object --stdin -t commit -w) >> ./git describe > > Thanks for the bug report. > > I think the cause of this bug is that peel_entry() is causing a nested > call to do_for_each_entry() to look up the replace reference, which > resets current_ref to NULL between the test and the dereference of > current_r
Segfault in `git describe`
I have a clone of linux.git with various stuff added to it (remotes for 'stable' and 'next', a bunch of local tags, and historical repositories imported using `git replace`). Yesterday, I noticed that `git describe`, built from git.git master (v1.8.3.2-804-g0da7a53, gcc 4.8) would simply crash when run in that repository, with the following backtrace: > Program terminated with signal 11, Segmentation fault. > #0 0x004c39dc in hashcpy (sha_src=0x1c , > sha_dst=0x7fffc0b4d610 "\242\271\301\366 > \201&\346\337l\002B\214P\037\210ShX\022") > at cache.h:694 > 694 memcpy(sha_dst, sha_src, 20); > (gdb) bt > #0 0x004c39dc in hashcpy (sha_src=0x1c , > sha_dst=0x7fffc0b4d610 "\242\271\301\366 > \201&\346\337l\002B\214P\037\210ShX\022") > at cache.h:694 > #1 peel_ref (refname=refname@entry=0x1fe2d10 "refs/tags/next-20130607", > sha1=sha1@entry=0x7fffc0b4d610 "\242\271\301\366 > \201&\346\337l\002B\214P\037\210ShX\022") at refs.c:1586 > #2 0x00424194 in get_name (path=0x1fe2d10 "refs/tags/next-20130607", > sha1=0x1fe2ce8 > "\222V\356\276S5\tk\231Hi\264\r=\336\315\302\225\347\257\300N\376\327\064@\237ZDq[T\246\312\033T\260\314\362\025refs/tags/next-20130607", > flag=, > cb_data=) at builtin/describe.c:156 > #3 0x004c1c21 in do_one_ref (entry=0x1fe2ce0, cb_data=0x7fffc0b4d7c0) > at refs.c:646 > #4 0x004c318d in do_for_each_entry_in_dir (dir=0x1fe1728, > offset=, fn=0x4c1bc0 , cb_data=0x7fffc0b4d7c0) > at refs.c:672 > #5 0x004c33d1 in do_for_each_entry_in_dirs (dir1=0x1fdf4d8, > dir2=0x1fd6318, > cb_data=0x7fffc0b4d7c0, fn=0x4c1bc0 ) at refs.c:716 > #6 0x004c33d1 in do_for_each_entry_in_dirs (dir1=0x1fdf1f8, > dir2=0x1fd62d8, > cb_data=0x7fffc0b4d7c0, fn=0x4c1bc0 ) at refs.c:716 > #7 0x004c3540 in do_for_each_entry (refs=refs@entry=0x7a2800 > , > base=base@entry=0x509cc6 "", cb_data=cb_data@entry=0x7fffc0b4d7c0, > fn=0x4c1bc0 ) at refs.c:1689 > #8 0x004c3ff8 in do_for_each_ref (cb_data=cb_data@entry=0x0, > flags=1, trim=0, > fn=fn@entry=0x424120 , base=0x509cc6 "", refs=0x7a2800 > ) > at refs.c:1724 > #9 for_each_rawref (fn=fn@entry=0x424120 , > cb_data=cb_data@entry=0x0) > at refs.c:1873 > #10 0x00424f5b in cmd_describe (argc=0, argv=0x7fffc0b4ddc0, > prefix=0x0) > at builtin/describe.c:466 > #11 0x0040596d in run_builtin (argv=0x7fffc0b4ddc0, argc=1, > p=0x760b40 ) at git.c:291 > #12 handle_internal_command (argc=1, argv=0x7fffc0b4ddc0) at git.c:453 > #13 0x00404d6e in run_argv (argv=0x7fffc0b4dc78, argcp=0x7fffc0b4dc5c) > at git.c:499 > #14 main (argc=1, av=) at git.c:575 > (gdb) According to `git bisect`, the first bad commit is: commit 9a489f3c17d6c974b18c47cf406404ca2a721c87 Author: Michael Haggerty Date: Mon Apr 22 21:52:22 2013 +0200 refs: extract a function peel_entry() The crash happens only in repositories that have at least one replaced object in the branch's history. Running `git --no-replace-objects describe` avoids the crash. The crash happens only if there are any tags under .git/refs/tags/ that do not exist in .git/packed-refs, or if I remove all "peeled" lines from .git/packed-refs (including the '#' line; /^[#^]/d). A quick way to reproduce this with git.git master is: git tag -f test-tag HEAD~10 git replace -f HEAD $(git --no-replace-objects cat-file commit HEAD \ | sed 's/@/@test/' | git hash-object --stdin -t commit -w) ./git describe -- Mantas Mikulėnas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] cat-file: print tags raw for "cat-file -p"
On Mon, Feb 25, 2013 at 8:50 PM, Jeff King wrote: > Note that "git verify-tag" and "git tag -v" depend on > "cat-file -p" to show the tag. This means they will start > showing the raw timestamp. We may want to adjust them to > use the pretty-printing code from "git show". > > Signed-off-by: Jeff King > --- > I don't use "git tag -v" much, so I'm not sure what is sane there. But > this seems like it would be a regression for people who want to check > the human-readable date given by GPG against the date in the tag object. Personally, I've found it quite confusing that commits (incl. merged tags) can be verified with `git show --show-signature`, but for tags I must use `git tag -v`... took me a while to find the latter. (`git show --verify` might be even better, but that's just me.) -- Mantas Mikulėnas -- 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: Crashes while trying to show tag objects with bad timestamps
On Sat, Feb 23, 2013 at 1:04 AM, Jeff King wrote: > On Fri, Feb 22, 2013 at 02:53:48PM -0800, Junio C Hamano wrote: >> and no for disappointing. IIRC, in the very early implementations >> allowed tag object without dates. >> >> I _think_ we can start tightening fsck, though. > > Then I think it would make sense to allow the very specific no-date tag, > but not allow arbitrary crud. I wonder if there's an example in the > kernel or in git.git. I couldn't find any such examples. However, I did find several tags with no "tagger" line at all: git.git has "v0.99" and linux.git has many such tags starting with "v2.6.11" ending with "v2.6.13-rc3". It seems that `git cat-file -p` doesn't like such tags too – if there is no "tagger", it doesn't display *any* header lines. More bugs? -- Mantas Mikulėnas -- 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
Crashes while trying to show tag objects with bad timestamps
When messing around with various repositories, I noticed that git 1.8
(currently using 1.8.2.rc0.22.gb3600c3) has problems parsing tag objects
that have invalid timestamps.
Times in tag objects appear to be kept as Unix timestamps, but I didn't
realize this at first, and ran something roughly equivalent to:
git cat-file -p $tagname | git hash-object -w -t tag --stdin
creating a tag object the "tagger" line containing formatted time
instead of a Unix timestamp.
Git doesn't handle the resulting tag objects nicely at all. For example,
running `git cat-file -p` on the new object outputs a really odd
timestamp "Thu Jun Thu Jan 1 00:16:09 1970 +0016" (I'm guessing it
parses the year as Unix time), and `git show` outright crashes
(backtrace included below.)
I would have expected both commands to print a "tag object corrupt"
message, or maybe even a more specific "bad timestamp in tagger line"...
To reproduce:
printf '%s\n' \
'object 4b825dc642cb6eb9a060e54bf8d69288fbee4904' 'type tree' \
'tag test' 'tagger User Thu Jun 9 16:44:04 2005 +' \
'' 'Test tag' | git hash-object -w -t tag --stdin | xargs git show
> #0 0x7f42560bb5f3 in strtoull_l_internal () from /usr/lib/libc.so.6
> No symbol table info available.
> #1 0x004b4c81 in pp_user_info (pp=pp@entry=0x7fff3c30f1a0,
> what=what@entry=0x50c13b "Tagger", sb=sb@entry=0x7fff3c30f140,
> line=0xc267c7 "Jilles Tjoelker Thu Jun 9 16:44:04 2005
> +\n\nTag 1.0rc1.\n\n", encoding=0x507e20 "UTF-8") at pretty.c:431
> name = {alloc = 24, len = 15, buf = 0xc24690 "Jilles Tjoelker"}
> mail = {alloc = 24, len = 15, buf = 0xc24750 "jil...@stack.nl"}
> ident = {
> name_begin = 0xc267c7 "Jilles Tjoelker Thu Jun 9
> 16:44:04 2005 +\n\nTag 1.0rc1.\n\n",
> name_end = 0xc267d6 " Thu Jun 9 16:44:04 2005
> +\n\nTag 1.0rc1.\n\n",
> mail_begin = 0xc267d8 "jil...@stack.nl> Thu Jun 9 16:44:04 2005
> +\n\nTag 1.0rc1.\n\n", mail_end = 0xc267e7 "> Thu Jun 9 16:44:04 2005
> +\n\nTag 1.0rc1.\n\n",
> date_begin = 0x0, date_end = 0x0, tz_begin = 0x0, tz_end = 0x0}
> linelen =
> line_end =
> date =
> mailbuf = 0xc267d8 "jil...@stack.nl> Thu Jun 9 16:44:04 2005
> +\n\nTag 1.0rc1.\n\n"
> namebuf = 0xc267c7 "Jilles Tjoelker Thu Jun 9
> 16:44:04 2005 +\n\nTag 1.0rc1.\n\n"
> namelen = 33
> maillen = 15
> max_length = 78
> time =
> tz =
> #2 0x00439af5 in show_tagger (buf=, len= out>,
> rev=) at builtin/log.c:400
> pp = {fmt = CMIT_FMT_MEDIUM, abbrev = 0, subject = 0x0, after_subject
> = 0x0,
> preserve_subject = 0, date_mode = DATE_NORMAL, date_mode_explicit =
> 0,
> need_8bit_cte = 0, notes_message = 0x0, reflog_info = 0x0,
> output_encoding = 0x0, mailmap = 0x0, color = 0}
> out = {alloc = 0, len = 0, buf = 0x7a8188 ""}
> #3 show_tag_object (rev=0x7fff3c30f1f0,
> sha1=0xc2be44
> "\230\211\275\331\365Q\306z\017\071d\331\035\062\247a\347~M8P", sequence \303>) at builtin/log.c:427
> new_offset = 151
> type = OBJ_TAG
> buf = 0xc26770 "object ffa28d13e40e03bd367d0219c7eb516be0f180d2\ntype
> commit\ntag hyperion-1.0rc1\ntagger Jilles Tjoelker Thu Jun
> 9 16:44:04 2005 +\n\nTag 1.0rc1.\n\n"
> size = 165
> offset =
--
Mantas Mikulėnas
--
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
