* [PATCH/RFC] add lame win32 credential-helper
From: Erik Faye-Lund @ 2011-09-15 20:25 UTC (permalink / raw)
To: git; +Cc: jaysoffian, peff, gitster
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
I got curious what a credential-helper that uses Windows'
Credential Manager would look like; this is the result.
Some parts of the code is heavily inspired by Jay Soffian's
OSX-keychain work.
Not that it's useful yet, since the core-git code for the
credential-helper support doesn't compile on Windows. So
it's not fully tested, I've only read the interface
documentation and experimented with it from the command
line.
contrib/credential-wincred/Makefile | 8 +
.../credential-wincred/git-credential-wincred.c | 271 ++++++++++++++++++++
2 files changed, 279 insertions(+), 0 deletions(-)
create mode 100644 contrib/credential-wincred/Makefile
create mode 100644 contrib/credential-wincred/git-credential-wincred.c
diff --git a/contrib/credential-wincred/Makefile b/contrib/credential-wincred/Makefile
new file mode 100644
index 0000000..b4f098f
--- /dev/null
+++ b/contrib/credential-wincred/Makefile
@@ -0,0 +1,8 @@
+all: git-credential-wincred.exe
+
+CC = gcc
+RM = rm -f
+CFLAGS = -O2 -Wall
+
+git-credential-wincred.exe : git-credential-wincred.c
+ $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
diff --git a/contrib/credential-wincred/git-credential-wincred.c b/contrib/credential-wincred/git-credential-wincred.c
new file mode 100644
index 0000000..5c0e2d3
--- /dev/null
+++ b/contrib/credential-wincred/git-credential-wincred.c
@@ -0,0 +1,271 @@
+#include <windows.h>
+#include <stdio.h>
+
+/* MinGW doesn't have wincred.h, let's extract the stuff we need instead */
+
+typedef struct _CREDENTIAL_ATTRIBUTE {
+ LPWSTR Keyword;
+ DWORD Flags;
+ DWORD ValueSize;
+ LPBYTE Value;
+} CREDENTIAL_ATTRIBUTE, *PCREDENTIAL_ATTRIBUTE;
+
+typedef struct _CREDENTIALW {
+ DWORD Flags;
+ DWORD Type;
+ LPWSTR TargetName;
+ LPWSTR Comment;
+ FILETIME LastWritten;
+ DWORD CredentialBlobSize;
+ LPBYTE CredentialBlob;
+ DWORD Persist;
+ DWORD AttributeCount;
+ PCREDENTIAL_ATTRIBUTE Attributes;
+ LPWSTR TargetAlias;
+ LPWSTR UserName;
+} CREDENTIALW, *PCREDENTIALW;
+
+typedef struct _CREDUI_INFOW {
+ DWORD cbSize;
+ HWND hwndParent;
+ LPWSTR pszMessageText;
+ LPWSTR pszCaptionText;
+ HBITMAP hbmBanner;
+} CREDUI_INFOW, *PCREDUI_INFOW;
+
+#define CRED_TYPE_GENERIC 1
+#define CRED_PERSIST_LOCAL_MACHINE 2
+#define CREDUIWIN_GENERIC 1
+#define CREDUIWIN_CHECKBOX 2
+#define CREDUIWIN_IN_CRED_ONLY 32
+#define CRED_PACK_GENERIC_CREDENTIALS 4
+
+
+typedef BOOL (WINAPI *CredWriteWT)(PCREDENTIALW, DWORD);
+typedef BOOL (WINAPI *CredUnPackAuthenticationBufferWT)(DWORD, PVOID, DWORD,
+ LPWSTR, DWORD *, LPWSTR, DWORD *, LPWSTR, DWORD *);
+typedef DWORD (WINAPI *CredUIPromptForWindowsCredentialsWT)(PCREDUI_INFOW,
+ DWORD, ULONG *, LPCVOID, ULONG, LPVOID *, ULONG *, BOOL *, DWORD);
+typedef BOOL (WINAPI *CredEnumerateWT)(LPCWSTR, DWORD, DWORD *,
+ PCREDENTIALW **);
+typedef BOOL (WINAPI *CredPackAuthenticationBufferWT)(DWORD, LPWSTR, LPWSTR,
+ PBYTE, DWORD *);
+typedef VOID (WINAPI *CredFreeT)(PVOID);
+typedef BOOL (WINAPI *CredDeleteWT)(LPCWSTR, DWORD, DWORD);
+
+static HMODULE advapi, credui;
+static CredWriteWT CredWriteW;
+static CredUnPackAuthenticationBufferWT CredUnPackAuthenticationBufferW;
+static CredUIPromptForWindowsCredentialsWT CredUIPromptForWindowsCredentialsW;
+static CredEnumerateWT CredEnumerateW;
+static CredPackAuthenticationBufferWT CredPackAuthenticationBufferW;
+static CredFreeT CredFree;
+static CredDeleteWT CredDeleteW;
+
+static void die(const char *err, ...)
+{
+ char msg[4096];
+ va_list params;
+ va_start(params, err);
+ vsnprintf(msg, sizeof(msg), err, params);
+ fprintf(stderr, "%s\n", msg);
+ va_end(params);
+ exit(1);
+}
+
+static void emit_user_pass(WCHAR *username, WCHAR *password)
+{
+ if (username)
+ wprintf(L"username=%s\n", username);
+ if (password)
+ wprintf(L"password=%s\n", password);
+}
+
+static int find_credentials(WCHAR *target, WCHAR *username)
+{
+ WCHAR user_buf[256], pass_buf[256];
+ DWORD user_buf_size = sizeof(user_buf) - 1,
+ pass_buf_size = sizeof(pass_buf) - 1;
+ CREDENTIALW **creds, *cred = NULL;
+ DWORD num_creds;
+
+ if (!CredEnumerateW(target, 0, &num_creds, &creds))
+ return -1;
+
+ if (!username) {
+ /* no username was specified, just pick the first one */
+ cred = creds[0];
+ } else {
+ /* search for the first credential that matches username */
+ int i;
+ for (i = 0; i < num_creds; ++i)
+ if (!wcscmp(username, creds[i]->UserName)) {
+ cred = creds[i];
+ break;
+ }
+ if (!cred)
+ return -1;
+ }
+
+ if (!CredUnPackAuthenticationBufferW(0, cred->CredentialBlob,
+ cred->CredentialBlobSize, user_buf, &user_buf_size, NULL, NULL,
+ pass_buf, &pass_buf_size))
+ return -1;
+
+ CredFree(creds);
+
+ /* zero terminate */
+ user_buf[user_buf_size] = L'\0';
+ pass_buf[pass_buf_size] = L'\0';
+
+ emit_user_pass(user_buf, pass_buf);
+ return 0;
+}
+
+/* also saves the credentials if the user tells it to */
+static int ask_credentials(WCHAR *target, WCHAR *comment, WCHAR *username)
+{
+ BOOL save = FALSE;
+ LPVOID auth_buf = NULL;
+ ULONG auth_buf_size = 0;
+ WCHAR user_buf[256], pass_buf[256];
+ DWORD user_buf_size = sizeof(user_buf) - 1,
+ pass_buf_size = sizeof(pass_buf) - 1;
+ BYTE in_buf[1024];
+ DWORD in_buf_size = sizeof(in_buf);
+ DWORD err;
+ ULONG package = 0;
+ CREDUI_INFOW info = {
+ sizeof(info), NULL,
+ comment ? comment : target, L"Enter password", NULL
+ };
+
+ if (username)
+ CredPackAuthenticationBufferW(0, username, L"",
+ in_buf, &in_buf_size);
+ err = CredUIPromptForWindowsCredentialsW(&info, 0, &package,
+ in_buf, in_buf_size, &auth_buf, &auth_buf_size,
+ &save, CREDUIWIN_GENERIC | CREDUIWIN_CHECKBOX);
+ if (err == ERROR_CANCELLED)
+ return 0;
+ if (err != ERROR_SUCCESS)
+ return -1;
+
+ if (!CredUnPackAuthenticationBufferW(0, auth_buf, auth_buf_size,
+ user_buf, &user_buf_size, NULL, NULL,
+ pass_buf, &pass_buf_size))
+ return -1;
+
+ /* zero terminate */
+ user_buf[user_buf_size] = L'\0';
+ pass_buf[pass_buf_size] = L'\0';
+
+ emit_user_pass(user_buf, pass_buf);
+
+ if (save) {
+ CREDENTIALW cred;
+ cred.Flags = 0;
+ cred.Type = CRED_TYPE_GENERIC;
+ cred.TargetName = target;
+ cred.Comment = comment;
+ cred.CredentialBlobSize = auth_buf_size;
+ cred.CredentialBlob = auth_buf;
+ cred.Persist = CRED_PERSIST_LOCAL_MACHINE;
+ cred.AttributeCount = 0;
+ cred.Attributes = NULL;
+ cred.TargetAlias = NULL;
+ cred.UserName = user_buf;
+ if (!CredWriteW(&cred, 0))
+ fprintf(stderr, "failed to write credentials\n");
+ }
+ return 0;
+}
+
+static void delete_credentials(WCHAR *target, WCHAR *username)
+{
+ WCHAR temp[4096];
+
+ wcscpy(temp, target);
+ if (username) {
+ wcscat(temp, L"|");
+ wcscat(temp, username);
+ }
+ if (!CredDeleteW(target, CRED_TYPE_GENERIC, 0))
+ die("failed to delete credentials");
+}
+
+int main(int argc, char *argv[])
+{
+ const char *usage =
+ "Usage: git credential-osxkeychain --unique=TOKEN [options]\n"
+ "Options:\n"
+ " --description=DESCRIPTION\n"
+ " --username=USERNAME\n"
+ " --reject";
+ WCHAR desc_buf[4096], *description = NULL,
+ user_buf[256], *username = NULL,
+ unique_buf[1024], *unique = NULL;
+ int i, reject = 0;
+
+ for (i = 1; i < argc; ++i) {
+ const char *arg = argv[i];
+ if (!strncmp(arg, "--description=", 14)) {
+ MultiByteToWideChar(CP_UTF8, 0, arg + 14, -1,
+ desc_buf, sizeof(desc_buf));
+ description = desc_buf;
+ } else if (!strncmp(arg, "--username=", 11)) {
+ MultiByteToWideChar(CP_UTF8, 0, arg + 11, -1,
+ user_buf, sizeof(user_buf));
+ username = user_buf;
+ } else if (!strncmp(arg, "--unique=", 9)) {
+ MultiByteToWideChar(CP_UTF8, 0, arg + 9, -1,
+ unique_buf, sizeof(unique_buf));
+ unique = unique_buf;
+ } else if (!strcmp(arg, "--reject")) {
+ reject = 1;
+ } else if (!strcmp(arg, "--help")) {
+ die(usage);
+ } else
+ die("Unrecognized argument `%s'; try --help", arg);
+ }
+
+ if (!unique)
+ die("Must specify --unique=TOKEN; try --help");
+
+ /* load DLLs */
+ advapi = LoadLibrary("advapi32.dll");
+ credui = LoadLibrary("credui.dll");
+ if (!advapi || !credui)
+ die("failed to load DLLs");
+
+ /* get function pointers */
+ CredWriteW = (CredWriteWT)GetProcAddress(advapi, "CredWriteW");
+ CredUnPackAuthenticationBufferW = (CredUnPackAuthenticationBufferWT)
+ GetProcAddress(credui, "CredUnPackAuthenticationBufferW");
+ CredUIPromptForWindowsCredentialsW =
+ (CredUIPromptForWindowsCredentialsWT)GetProcAddress(credui,
+ "CredUIPromptForWindowsCredentialsW");
+ CredEnumerateW = (CredEnumerateWT)GetProcAddress(advapi,
+ "CredEnumerateW");
+ CredPackAuthenticationBufferW = (CredPackAuthenticationBufferWT)
+ GetProcAddress(credui, "CredPackAuthenticationBufferW");
+ CredFree = (CredFreeT)GetProcAddress(advapi, "CredFree");
+ CredDeleteW = (CredDeleteWT)GetProcAddress(advapi, "CredDeleteW");
+ if (!CredWriteW || !CredUnPackAuthenticationBufferW ||
+ !CredUIPromptForWindowsCredentialsW || !CredEnumerateW ||
+ !CredPackAuthenticationBufferW || !CredFree || !CredDeleteW)
+ die("failed to load functions");
+
+ if (reject) {
+ delete_credentials(unique, username);
+ return 0;
+ }
+
+ if (!find_credentials(unique, username))
+ return 0;
+
+ if (!ask_credentials(unique, description, username))
+ return 0;
+
+ return -1;
+}
--
1.7.6.355.g842ba.dirty
^ permalink raw reply related
* Re: Problems with format-patch UTF-8 and a missing second empty line
From: Alexey Shumkin @ 2011-09-15 20:05 UTC (permalink / raw)
To: Jeff King; +Cc: Ingo Ruhnke, git
In-Reply-To: <20110915185033.GA17016@sigill.intra.peff.net>
> >
> > I reproduced this bug with the latest git (v1.7.6.3)
> > It seems to me this is not the "git format-patch" bug
> > but "git am"'s one. (But it is only the supposition)
>
> Can you be more specific about what you tested? Running Ingo's snippet
> with a more recent git produces:
>
> Subject: [PATCH] =?UTF-8?q?=C3=84=C3=96=C3=9C=20=C3=84=C3=96=C3=9C?=
>
> which is right (and "git am", new or old, will apply it just fine).
>
> But there may be a different, related bug lurking somewhere.
>
> -Peff
>
this is my steps (log from terminal)
$ mkdir git-format-patch
Initialized empty Git repository
in /home/Alex/tmp/git-format-patch/.git/
$ cd git-format-patch
$ echo file content > file
$ git add -vf file
add 'file'
$ git commit -a -m 'коммит: строка-1
> коммит: строка-2'
[master (root-commit) 7ede929] коммит: строка-1 коммит: строка-2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
$ git log
commit 7ede9291cf2d160721bcd8362d8d0f6c6e28cf29
Author: Alexey Shumkin <zapped@mail.ru>
Date: Thu Sep 15 23:18:26 2011 +0400
коммит: строка-1
коммит: строка-2
$ git format-patch --root HEAD
0001-1.patch
$ cat 0001-1.patch
From 7ede9291cf2d160721bcd8362d8d0f6c6e28cf29 Mon Sep 17 00:00:00 2001
From: Alexey Shumkin <zapped@mail.ru>
Date: Thu, 15 Sep 2011 23:18:26 +0400
Subject: [PATCH]
=?UTF-8?q?=D0=BA=D0=BE=D0=BC=D0=BC=D0=B8=D1=82:=20=D1=81=D1?=
=?UTF-8?q?=82=D1=80=D0=BE=D0=BA=D0=B0-1=20=D0=BA=D0=BE=D0=BC=D0=BC=D0=B8=D1?=
=?UTF-8?q?=82:=20=D1=81=D1=82=D1=80=D0=BE=D0=BA=D0=B0-2?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
file | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
diff --git a/file b/file
new file mode 100644
index 0000000..dd59d09
--- /dev/null
+++ b/file
@@ -0,0 +1 @@
+file content
--
1.7.6.3.4.gf71f
$ git init ../git-format-patch-am
Initialized empty Git repository
in /home/Alex/tmp/git-format-patch-am/.git/
$ cd ../git-format-patch-am
$ git am < ../git-format-patch/0001-1.patch
Applying: коммит: строка-1 коммит: строка-2
applying to an empty history
$ git log
commit 9856238e06d4ca8faeefc48e5c80e8ef7bd34195
Author: Alexey Shumkin <zapped@mail.ru>
Date: Thu Sep 15 23:18:26 2011 +0400
коммит: строка-1 коммит: строка-2
$ git --version
git version 1.7.6.3.4.gf71f
But as you said
>>This is by design. Git commit messages are intended to have a
>>single-line subject, followed by a blank line, followed by more
>>elaboration
and solved with "-k" for both "format-patch" and "am" commands
^ permalink raw reply related
* Re: [PATCH 2/2] grep --no-index: don't use git standard exclusions
From: Junio C Hamano @ 2011-09-15 19:44 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <7b3551dd84a2bfec78c8db1d14dd2d0e6dda35f6.1316110876.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> On Wed, Jul 20, 2011 at 22:57, Junio C Hamano <gitster@pobox.com> wrote:
>> - Since 3081623 (grep --no-index: allow use of "git grep" outside a git
>> repository, 2010-01-15) and 59332d1 (Resurrect "git grep --no-index",
>> 2010-02-06), "grep --no-index" incorrectly paid attention to the
>> exclude patterns. We shouldn't have, and we'd fix that bug.
>
> Fix this bug.
On a busy list like this, it is brutal to withhold the better clues you
certainly had when you wrote this message that would help people to locate
the original message you are quoting, and instead forcing everybody to go
back 5000 messages in the archive to find it. E.g.
http://article.gmane.org/gmane.comp.version-control.git/177548
http://mid.gmane.org/7vzkk86577.fsf@alter.siamese.dyndns.org
Or perhaps have
References: <7vzkk86577.fsf@alter.siamese.dyndns.org>
in the header.
As to the patch, I think this addresses only one fourth of the issue
identified in that discussion (it is a good starting point, though).
With this change, it would now make sense to teach --[no-]exclude-standard
to "git grep", and "--exclude-standard" is immediately useful when used
with "--no-index". When we add "git grep --untracked-too" (which lets us
search in the working tree), people can add "--no-exclude-standard" to the
command line to say "I want to find the needle even from an ignored file".
Thanks.
^ permalink raw reply
* Re: Problems with format-patch UTF-8 and a missing second empty line
From: Jeff King @ 2011-09-15 19:01 UTC (permalink / raw)
To: Ingo Ruhnke; +Cc: git
In-Reply-To: <CAHz1FYgPuMHLC+f2mFqD73=NGXQSStRPDOsiCy-HtaWKbHu7NQ@mail.gmail.com>
On Thu, Sep 15, 2011 at 11:45:15AM +0200, Ingo Ruhnke wrote:
> Creating a patch of a commit including UTF-8 and no empty second line,
> like this:
I already responded about the bug with utf8-encoded subjects, but let me
address the second half of your mail, too:
> Here the newline between ABC\nABC gets stripped out and replaced with
> a space when transferring the commit with format-patch from one
> repository to another.
This is by design. Git commit messages are intended to have a
single-line subject, followed by a blank line, followed by more
elaboration. A multi-line subject is treated as a single line that has
been line-broken, and is subject to being reflowed onto a single line.
This is done to help with commits imported from other version control
systems which don't follow this pattern (the other option is truncating
the subject and putting the other lines into the "body", but that often
ends up quite unreadable).
If you really want to retain the newlines across "format-patch | am",
use the "-k" option of both to preserve the subject (I don't recall the
details, but I think you need a more recent version of git for
format-patch to correctly encode this, but "am" can be from any
version).
> Another small issue is that the filename of the patch will strip out
> any UTF-8 characters, Thus a commit message of "123Äöü456" will result
> in "0001-123-456.patch".
Yes, it's an attempt to strip out characters that some filesystems might
not support well. We could probably enable high-bit characters with a
config option (maybe even just using core.quotepath).
-Peff
^ permalink raw reply
* Re: Problems with format-patch UTF-8 and a missing second empty line
From: Jeff King @ 2011-09-15 18:50 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: Ingo Ruhnke, git
In-Reply-To: <20110915224456.14410ed8@zappedws>
[resending with git@vger cc'd; please keep discussion on list]
On Thu, Sep 15, 2011 at 10:44:56PM +0400, Alexey Shumkin wrote:
> > On Thu, Sep 15, 2011 at 11:45:15AM +0200, Ingo Ruhnke wrote:
> >
> > > Creating a patch of a commit including UTF-8 and no empty second
> > > line, like this:
> > > [...]
> > > Results in this:
> > > [...]
> > > Subject: [PATCH] =?UTF-8?q?=C3=84=C3=96=C3=9C
> > > =20=C3=84=C3=96=C3=9C?=
> > >[....]
> > > The problems happen with git version 1.7.4.1 (4b5eac7f0) on Ubuntu
> > > 11.04.
> >
> > I'm pretty sure I fixed this in a1f6baa, which is in v1.7.4.4 and
> > later.
>
> I reproduced this bug with the latest git (v1.7.6.3)
> It seems to me this is not the "git format-patch" bug
> but "git am"'s one. (But it is only the supposition)
Can you be more specific about what you tested? Running Ingo's snippet
with a more recent git produces:
Subject: [PATCH] =?UTF-8?q?=C3=84=C3=96=C3=9C=20=C3=84=C3=96=C3=9C?=
which is right (and "git am", new or old, will apply it just fine).
But there may be a different, related bug lurking somewhere.
-Peff
^ permalink raw reply
* [PATCH 2/2] grep --no-index: don't use git standard exclusions
From: Bert Wesarg @ 2011-09-15 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bert Wesarg
In-Reply-To: <2f376e61802a1a38c67698d5ec263d1807b1fcee.1316110876.git.bert.wesarg@googlemail.com>
The --no-index mode is intended to be used outside of a git repository, but
enabling the git standard exclusions outside a git repositories does not make
any sense. Especially if it is not possible to disable them.
Thus do not use the standard exclusions in --no-index mode.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
On Wed, Jul 20, 2011 at 22:57, Junio C Hamano <gitster@pobox.com> wrote:
> - Since 3081623 (grep --no-index: allow use of "git grep" outside a git
> repository, 2010-01-15) and 59332d1 (Resurrect "git grep --no-index",
> 2010-02-06), "grep --no-index" incorrectly paid attention to the
> exclude patterns. We shouldn't have, and we'd fix that bug.
Fix this bug.
builtin/grep.c | 1 -
t/t7810-grep.sh | 2 +-
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index e0562b0..127584e 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -643,7 +643,6 @@ static int grep_directory(struct grep_opt *opt, const struct pathspec *pathspec)
int i, hit = 0;
memset(&dir, 0, sizeof(dir));
- setup_standard_excludes(&dir);
fill_directory(&dir, pathspec->raw);
for (i = 0; i < dir.nr; i++) {
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 0d60016..4a05e79 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -554,7 +554,6 @@ test_expect_success 'outside of git repository' '
mkdir -p non/git/sub &&
echo hello >non/git/file1 &&
echo world >non/git/sub/file2 &&
- echo ".*o*" >non/git/.gitignore &&
{
echo file1:hello &&
echo sub/file2:world
@@ -581,6 +580,7 @@ test_expect_success 'inside git repository but with --no-index' '
echo world >is/git/sub/file2 &&
echo ".*o*" >is/git/.gitignore &&
{
+ echo ".gitignore:.*o*" &&
echo file1:hello &&
echo sub/file2:world
} >is/expect.full &&
--
1.7.6.789.gb4599
^ permalink raw reply related
* [PATCH 1/2] grep: do not use --index in the short usage output
From: Bert Wesarg @ 2011-09-15 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bert Wesarg
Utilize the PARSE_OPT_NEGHELP option to show --no-index in the usage
generated by parse-options.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
builtin/grep.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 1c359c2..e0562b0 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -774,8 +774,9 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT_BOOLEAN(0, "cached", &cached,
"search in index instead of in the work tree"),
- OPT_BOOLEAN(0, "index", &use_index,
- "--no-index finds in contents not managed by git"),
+ { OPTION_BOOLEAN, 0, "index", &use_index, NULL,
+ "finds in contents not managed by git",
+ PARSE_OPT_NOARG | PARSE_OPT_NEGHELP },
OPT_GROUP(""),
OPT_BOOLEAN('v', "invert-match", &opt.invert,
"show non-matching lines"),
--
1.7.6.789.gb4599
^ permalink raw reply related
* Re: [PATCH 0/4] Honor core.ignorecase for attribute patterns
From: Jeff King @ 2011-09-15 18:12 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, gitster, sunshine, bharrosh, trast, zapped
In-Reply-To: <1316051979-19671-1-git-send-email-drafnel@gmail.com>
On Wed, Sep 14, 2011 at 08:59:35PM -0500, Brandon Casey wrote:
> > I haven't even tested that it runs. :) No, I was hoping someone
> > who was more interested would finish it, and maybe even test on
> > an affected system.
>
> Ok, I lied. Here's a series that needs testing by people on a
> case-insensitive filesystem and some comments.
Thanks. I was trying to decide if I was interested enough to work on it,
but procrastination wins again.
I'm not sure I understand why you need a case-insensitive file system
for the final set of tests. If we have a case-sensitive system, we can
force the filesystem to show us whatever cases we want, and check
against them with both core.ignorecase off and on[1]. What are these
tests checking that requires the actual behavior of a case-insensitive
filesystem?
I'm sure there is something subtle that I'm missing. Can you explain it
either here or in the commit message?
-Peff
[1] Actually, I wondered at first if the other tests needed to be marked
for only case-sensitive systems, since we can't rely on the behavior of
insensitive ones (e.g., are they case-preserving, always downcasing,
etc). But looking at t0003, we don't seem to actually create the files
in the filesystem at all.
^ permalink raw reply
* Re: [Survey] Signed push
From: Jeff King @ 2011-09-15 17:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jonathan Nieder, Junio C Hamano, Git Mailing List
In-Reply-To: <CACsJy8BEES2j8K1v23RQQS=R1vRm1SVizBGFzq0wsDcMvC6Fjw@mail.gmail.com>
On Thu, Sep 15, 2011 at 08:42:40AM +1000, Nguyen Thai Ngoc Duy wrote:
> Yes, I think we can do that already. It's just more convenient to
> teach "git fetch/pull" to take pull requests and automatically verify
> them. Some repositories may also want to enforce signing and we can do
> that by setting config file and fetch/pull refuses if pull requests
> are not signed. We can also store the sign as git notes, just like in
> git-push (extra work if it has to be done manually).
Isn't there a human element in the verification? I.e., I see a pull
request, and we can computationally verify that it is signed by some
key. Now assuming GPG's web of trust works, that binds that key to an
email address and a real name. But how is that bound to the repository
you are actually fetching from (or more appropriately, that the commits
mentioned are appropriate to be pulled)?
That is a policy that the human must decide upon seeing "Oh, a pull
request from developer X; I should pull that into my local branch Y",
and which they do implicitly when they manually run the pull command
mentioned in the email.
Another way to think of it is that verifying the identity of the sender
(which GPG does) is only one step. You also need an ACL saying that the
sender is worth pulling from.
So either:
1. The human is still in the loop, in which case having git-pull
verify the sender's identity hasn't really done anything (because
probably their MUA already told them it was really from the
purported sender, and then they made the ACL decision in their head
before deciding to pull from you).
2. The human is not in the loop, and nothing is checking that ACL.
-Peff
^ permalink raw reply
* Re: Setting up Git Server
From: P Rouleau @ 2011-09-15 12:11 UTC (permalink / raw)
To: git
In-Reply-To: <CAOZxsTqFfOR+Eb3rqz5hZSJRTe=a1N-CEM--GGGGO2yayT-HLA@mail.gmail.com>
Joshua Stoutenburg <jehoshua02 <at> gmail.com> writes:
>
> Looking for some guidance in setting up a git server customized to my
> specific needs. Could anybody walk me through the process?
>
> I have a VirtualBox VM server on which I want to set up a cluster of VMs
> each one for a different purpose -- experimentation, web hosting, and,
> of course, git.
>
> I'm using Ubuntu 10.04 LTS for the operating system. I have a single
> public ip address.
As you are using VMs, you should have a look at Turnkey-Linux
(http://turnkey-linux.com/). They offer ready-to-use linux appliances,
which are based on Ubuntu.
There is two for code revision which already include git, hg and subversion.
There is also others appliances made to be web server.
^ permalink raw reply
* Re: vcs-svn and firends
From: Jonathan Nieder @ 2011-09-15 17:45 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: David Michael Barr, git
In-Reply-To: <CA+gfSn9TU1mfAifL=1CDdq_cz7M7BgNLDuPAtzbMSf04WB-K3w@mail.gmail.com>
Dmitry Ivankov wrote:
> A very quick view suggests that they could be reorganized, if it's okay.
> For example:
> - squash optifying REPORT_FILENO with it's addition.
> - drop changes to repo_tree.c that were later erased
> ...I bet there are more
>
> Does it make sense or we should better not rewrite the history?
All else being equal, it is better not to rewrite history, especially
when there are multiple series building on a commit (as is the case
for most commits in the
git://repo.or.cz/git/jrn.git svn-fe
branch, just like Junio's "master" branch).
Cheers,
Jonathan
^ permalink raw reply
* Re: Helping on Git development
From: Jeff King @ 2011-09-15 17:21 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Junio C Hamano, git, Eduardo D'Avila
In-Reply-To: <CAH5451n=yEYYb0jO85+5_0dkuupQA2_WLvnH-fwPESS1GWy4Sg@mail.gmail.com>
On Thu, Sep 15, 2011 at 04:24:22PM +1000, Andrew Ardill wrote:
> Does git even have an issue tracker? I have not seen one anywhere.
No. The general philosophy so far has been that the mailing list serves
the same purpose, and that if messages go by without comment on the
list, it's probably because they weren't that interesting to people
(i.e., in a bug tracker, they would have also sat untouched).
That being said, the mailing list is free-form, which can make it harder
to search and analyze. Something that organizes the information like a
bug tracker could be useful, but only if somebody (or somebodies) is
dedicated to keeping the information up to date and free of cruft.
-Peff
^ permalink raw reply
* Re: [PATCH] t6019: avoid refname collision on case-insensitive systems
From: Junio C Hamano @ 2011-09-15 16:45 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Brad King, git
In-Reply-To: <20110915155308.GA19667@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 15, 2011 at 08:52:01AM -0700, Junio C Hamano wrote:
>
>> > This fixes the tests on OS X. Together with Peff's fix to the poll
>> > issue, it now tests clean again.
>>
>> Hmm, I must have misplaced Peff's poll fix. Care to point me in the right
>> direction?
>
> You have it already; it's part of the new http-auth commits I sent
> yesterday (patch 2/5).
Ah, that one. Thanks, yes I do have it.
I somehow thought Thomas was talking about a test fix for 5800
"intermittent hang".
^ permalink raw reply
* Re: [PATCH] Un-static gitmkstemps
From: Junio C Hamano @ 2011-09-15 16:05 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1316089260-76049-1-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> It may not be used in most builds, but it's used via a #ifdef in
> git-compat-util.h ...
Hmm, do you mean "#define", not "#ifdef", specifically, this:
maint:git-compat-util.h:#define mkstemps gitmkstemps
> ... Also, making it static makes a -Wall compile fail
> since it's not used in the file without NO_MKSTEMPS.
Your alternative of not defining on builds without NO_MKSTEMPS is better,
and probably even better yet, it would make sense to move the definition
of git_mkstemps() out of wrapper.c and have it somewhere in compat/, just
like the way in which compat/qsort.c defines git_qsort() that is used as a
replacement for qsort() via #define on systems that lack it.
^ permalink raw reply
* Re: [PATCH] t6019: avoid refname collision on case-insensitive systems
From: Jeff King @ 2011-09-15 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Brad King, git
In-Reply-To: <7vzki5pzvi.fsf@alter.siamese.dyndns.org>
On Thu, Sep 15, 2011 at 08:52:01AM -0700, Junio C Hamano wrote:
> > This fixes the tests on OS X. Together with Peff's fix to the poll
> > issue, it now tests clean again.
>
> Hmm, I must have misplaced Peff's poll fix. Care to point me in the right
> direction?
You have it already; it's part of the new http-auth commits I sent
yesterday (patch 2/5).
-Peff
^ permalink raw reply
* Re: [PATCH] t6019: avoid refname collision on case-insensitive systems
From: Junio C Hamano @ 2011-09-15 15:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Brad King, git
In-Reply-To: <02451a2849fc8f1cab7983b6c8c629ebb6a1aaa9.1316075573.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The criss-cross tests kept failing for me because of collisions of 'a'
> with 'A' etc. Prefix the lowercase refnames with an extra letter to
> disambiguate.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> This fixes the tests on OS X. Together with Peff's fix to the poll
> issue, it now tests clean again.
Hmm, I must have misplaced Peff's poll fix. Care to point me in the right
direction?
^ permalink raw reply
* Re: Helping on Git development
From: Junio C Hamano @ 2011-09-15 15:50 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Jeff King, git, Eduardo D'Avila
In-Reply-To: <CAH5451n=yEYYb0jO85+5_0dkuupQA2_WLvnH-fwPESS1GWy4Sg@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
>> I am moderately averse to hardcoding that URL that is guaranteed not to
>> survive the maintainer change in our README file. The howto/maintain-git
>> document mentions the periodical "A note from the maintainer" posting to
>> the list that has the same text, which is a more appropriate reference.
>
> Would a link to the wiki be more appropriate? Perhaps even a 'getting
> started' page that collates information like this?
> ...
> When kernel.org comes back online I may have a go at creating such a
> page. Any thoughts?
"Getting started" that describes how they got started, collectively
maintained by people who got started recently, may serve as a good guide
for people who follow. And if it is done as a wiki, you are free to create
and update without asking permission from the community ;-).
^ permalink raw reply
* Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere
From: Brandon Casey @ 2011-09-15 15:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: peff, git, gitster, sunshine, bharrosh, trast, zapped
In-Reply-To: <4E71A0C7.8080602@viscovery.net>
On Thu, Sep 15, 2011 at 1:52 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 9/15/2011 3:59, schrieb Brandon Casey:
>> The "x"-prefixed versions of strdup, malloc, etc. will check whether the
>> allocation was successful and terminate the process otherwise.
>>
>> A few uses of malloc were left alone since they already implemented a
>> graceful path of failure or were in a quasi external library like xdiff.
>>
>> Signed-off-by: Brandon Casey <drafnel@gmail.com>
>> ---
>> ...
>> compat/mingw.c | 2 +-
>> compat/qsort.c | 2 +-
>> compat/win32/syslog.c | 2 +-
>
> There is a danger that the high-level die() routine (which is used by the
> x-wrappers) uses one of the low-level compat/ routines. IOW, in the case
> of errors, recursion might occur. Therefore, I would prefer that the
> compat/ routines do their own error reporting (preferably via return
> values and errno).
Thanks. Will do.
-Brandon
^ permalink raw reply
* Re: [PATCH 4/4] attr.c: respect core.ignorecase when matching attribute patterns
From: Brandon Casey @ 2011-09-15 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: peff, git, sunshine, bharrosh, trast, zapped
In-Reply-To: <7vobymqwjf.fsf@alter.siamese.dyndns.org>
On Wed, Sep 14, 2011 at 11:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
> > An alternative approach may be to move reading of core.attributesfile to
> > default_config, and drop git_config() call from bootstrap_attr_stack(),
> > getting rid of git_attr_config callback altogether.
>
> That is, something like this on top of your patch.
Ok.
I'll send a reroll that slides this underneath my top patch, and
addresses Hanne's comment.
-Brandon
> attr.c | 15 ++-------------
> builtin/check-attr.c | 2 ++
> cache.h | 1 +
> config.c | 3 +++
> environment.c | 1 +
> 5 files changed, 9 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: Problems with format-patch UTF-8 and a missing second empty line
From: Jeff King @ 2011-09-15 15:17 UTC (permalink / raw)
To: Ingo Ruhnke; +Cc: git
In-Reply-To: <CAHz1FYgPuMHLC+f2mFqD73=NGXQSStRPDOsiCy-HtaWKbHu7NQ@mail.gmail.com>
On Thu, Sep 15, 2011 at 11:45:15AM +0200, Ingo Ruhnke wrote:
> Creating a patch of a commit including UTF-8 and no empty second line,
> like this:
> [...]
> Results in this:
> [...]
> Subject: [PATCH] =?UTF-8?q?=C3=84=C3=96=C3=9C
> =20=C3=84=C3=96=C3=9C?=
>[....]
> The problems happen with git version 1.7.4.1 (4b5eac7f0) on Ubuntu 11.04.
I'm pretty sure I fixed this in a1f6baa, which is in v1.7.4.4 and later.
-Peff
^ permalink raw reply
* Re: [tig] Feeding specific revisions to tig
From: Jean-Baptiste Quenot @ 2011-09-15 15:10 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30904270321t3d73e2c5o5e3ac8d4b627e5ab@mail.gmail.com>
2009/4/27 Jonas Fonseca <jonas.fonseca@gmail.com>:
> Sorry for the slow reply ...
>
> On Thu, Apr 23, 2009 at 16:55, Jean-Baptiste Quenot <jbq@caraldi.com> wrote:
>> Restarting this old thread again. Starting from 0.13 the
>> *tignowalk()* hack does not work anymore. What's the preferred way to
>> feed specific revisions using stdin now?
>
> I don't know if it is preferred, but it works. First add a git alias:
>
> [alias]
> tignowalk-helper = !git rev-list --pretty=raw --no-walk --stdin<
>
> Then modify tignowalk by replacing the line calling tig to say:
>
> TIG_MAIN_CMD="git tignowalk-helper $tmp" tig </dev/tty
>
> ... and it should work. Maybe more git alias functionality can
> simplify the hack.
Restarting this thread again... it seems like every new version of tig
breaks this usecase :-)
Any idea how to feed specific revisions to tig 0.18? The trick does
not work anymore, as support for TIG_MAIN_CMD was dropped.
--
Jean-Baptiste Quenot
^ permalink raw reply
* Re: Anybody home?
From: Scott Chacon @ 2011-09-15 15:04 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <CAOZxsTqGt=gYr3t7e5Ma4z6W9wt_JxrgsNSGFGVbtk2rc3LZ9w@mail.gmail.com>
Hey,
On Thu, Sep 15, 2011 at 2:01 AM, Joshua Stoutenburg
<jehoshua02@gmail.com> wrote:
>> Reading your exchanges elsewhere in this thread, I think you missed that
>> you don't need a git server at all just to *use* git.
>>
>> Even when you want to exchange your commits between two or three machines,
>> all you need is ssh access. There is no *git server* necessary. git is not
>> svn. ;-)
>>
>> I thought I'd just mention this to help you streamline your search.
>>
>> -- Hannes
>>
>
> I read the first four and a half chapters from the Pro Git book pdf.
> So I think I understood that much.
>
> But in my situation, I do need a server so that other developers can
> access anytime over the internet.
>
> I should have mentioned that.
I guess I'm confused. The fourth chapter of the Pro Git book is
entirely about setting up your own Git server, including basically
step by step instructions on Gitolite and Gitosis, in addition to
simply running your own ssh-based server plus gitweb. It is like 20
pages long - how is this not exactly what you're asking for?
Scott
^ permalink raw reply
* Re: vcs-svn and friends
From: Stephen Bash @ 2011-09-15 14:06 UTC (permalink / raw)
To: David Michael Barr; +Cc: Jonathan Nieder, Dmitry Ivankov, git, Junio C Hamano
In-Reply-To: <CAFfmPPOBZ6cXG51mDHbj2VRDzjvH46Q7=_LvUWeMq0SGR40S1g@mail.gmail.com>
----- Original Message -----
> From: "David Michael Barr" <davidbarr@google.com>
> Sent: Wednesday, September 14, 2011 9:53:53 PM
> Subject: Fwd: vcs-svn and friends
>
> Thanks to the work of Dmitry, we now have a simple front-end
> that exercises the yet unmerged changes to vcs-svn that Jonathan
> and I authored a few months ago.
For those of us interested but out of the loop, does this mean you have a working example where I can point it at a SVN repo and see what happens? Having done our SVN to Git conversion last year, I know our repo has a lot of the common SVN screw cases (non-branching copies, partial merges, mis-merges, *lots* of retagging, changes committed to tags, etc.) so if it's relatively easy to setup a test I'm happy to run one.
Thanks,
Stephen
^ permalink raw reply
* Re: Anybody home?
From: Martin Langhoff @ 2011-09-15 13:17 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <CAOZxsTrxPZ1V+_W=trRpOTJ9emh8msreGOyAYm_1hs0zXaOd1w@mail.gmail.com>
On Thu, Sep 15, 2011 at 5:42 AM, Joshua Stoutenburg
<jehoshua02@gmail.com> wrote:
> I got confused in Chapter 5 of the Pro Git pdf book, trying to discern
> what needs to be done on the server, and what needs to be done on the
> work station
OK - some hints:
1 - For private code, or public code where you value the service, you
can use the commercial services out there, that's easy
2 - For public/foss code, with low/simple service expectations, you
can get free hosting
3 - For a private setup... the normal thing is to use git over ssh, so
the server should be reachable by your users, and your users need an
ssh account. You will want to setup a group ("gituser") and create a
directory ("/git") owned by that group, writable by the group, with
sticky group mode.
To create a new project repo, ssh into the server and say git
--git-dir /git/fooproject init --shared . It will be empty -- on a
user workstation create your first commit, and push it into the (so
far empty) repo with git push git+ssh://hostname/git/fooproject master
.
On the server you can add a gitweb or cgit install for browsability.
If you want to allow anonymous users to access your git repos in
readonly mode, you can setup the git "service", with xinetd. That
allows you to tell people "git clone git://hostname/fooproject" .
Careful when configuring network services if the host is public, you
don't want to serve git://host/etc/shadow :-)
This is what most "git servers" do -- it works in your company
network, it also works for a public FOSS project with anon readers and
a handful of ssh-authenticated committers.
(For a project using a more distributed model of
one-developer-one-repo, you follow the same setup but perhaps make
per-developer directories.)
4 - You _can_ do git over http, instead of ssh, but I suspect the
setup is more involved. In any case, others will have to fill in.
> Also, I'm not clear on the best way to manage large numbers of git
> users (like 12-24), who also may have permissions to other services as
> well (ftp, databases, email, etc). I have some hesitancy creating
> each one manually on the CLI.
CLI is generally fine :-) if you contract a hosting server that gives
you email/db/ftp and has a webbased admin UI, all you need
"additional" is to ensure you can manage ssh accounts with ease.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Fwd: vcs-svn and friends
From: Dmitry Ivankov @ 2011-09-15 13:00 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Michael Barr, Junio C Hamano, git
In-Reply-To: <20110915100106.GB2328@elie>
> - 3bba32e9 ("fast-import: allow top directory as an argument for some
> commands"): I'm not sure what the motivation is --- is this just
> about the principle of least surprise, or did it come up in practice
> somewhere?
(to ease one's reading, commands are ls, copy and move top directory)
Haven't seen them in practice. It seemed possible with svn import: if there were
no branches at start, and then someone did svn mv . trunk. But it
turns out that my
svn client doesn't allow such move. So more like a least surprise purpose.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox