* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 21:00 UTC (permalink / raw)
To: Scott Chacon; +Cc: Git List
In-Reply-To: <CAP2yMaJcKnghtxxDNVYk=00KQ-ZOGEwACHRTU15tGnOuk3R4Hw@mail.gmail.com>
On Thu, Sep 15, 2011 at 8:04 AM, Scott Chacon <schacon@gmail.com> wrote:
> 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
>
Scott -- the man himself!
I've been reading the pdf version of the excellent Pro Git book:
http://progit.org/ebook/progit.pdf
In the pdf version, Chapter 5 covers "Git on the Server". I was a
little confused at section 5.2, "Getting Git on a Server".
I was expecting a process very similar to installing on a work station
(sections 2.4, "Installing Git", and 2.5, "First-Time Git Setup"),
with differences pertaining to the server. But this section (5.2)
didn't talk about that and seemed to assume I already installed Git on
the server. Instead, this section explains how to create a bare
repository and Section 5.2.1 explains how to put the bare repository
on the server.
So I jumped ahead to section 5.4, "Setting Up the Server", hoping to
find the process I was expecting. For the most part it was there. But
I was left pondering how tedious it would be to manage a couple dozen
git users.
So I read sections 5.7 "Gitosis" and 5.8 "Gitolite". It sounds like
these two tools do the same thing. Since I'm not sure what makes them
different, I wasn't sure which one would fit my needs.
Then, I heard about Gitorious and would like to give that a spin. The
idea of installing a single piece of software that does everything
seems more appealing than installing and configuring multiple pieces
of software.
I'll return to the books for now and do the best I can.
I'm running the Git server in a VirtualBox VM server and keep
snapshots after significant changes. So if I break anything, it will
be a couple clicks to recover.
Thanks for everyone's help.
^ permalink raw reply
* Re: vcs-svn and friends
From: Jonathan Nieder @ 2011-09-15 20:48 UTC (permalink / raw)
To: Stephen Bash; +Cc: David Michael Barr, Dmitry Ivankov, git, Junio C Hamano
In-Reply-To: <27874151.17649.1316095596748.JavaMail.root@mail.hq.genarts.com>
Stephen Bash wrote:
> 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. It's very bare-bones at the moment: it just imports each
revision as a whole tree, with no branch and merge tracking at all.
So it would be very interesting to get this basic stuff out into the
wild and then add some code implementing those things for you to break
on top of it.
^ permalink raw reply
* Re: Problems with format-patch UTF-8 and a missing second empty line
From: Jeff King @ 2011-09-15 20:33 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: Ingo Ruhnke, git
In-Reply-To: <20110916000515.1dfc5665@zappedws>
On Fri, Sep 16, 2011 at 12:05:15AM +0400, Alexey Shumkin wrote:
> 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
OK, that makes sense to me, then. I didn't read Ingo's first message
carefully enough, but your response made me scratch my head and read it
again. Thanks for the sanity check.
-Peff
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.ignorecase for attribute patterns
From: Brandon Casey @ 2011-09-15 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster, sunshine, bharrosh, trast, zapped
In-Reply-To: <20110915181258.GA1227@sigill.intra.peff.net>
On Thu, Sep 15, 2011 at 1:12 PM, Jeff King <peff@peff.net> wrote:
> 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?
This is probably way more detail than this feature deserves, but...
Those tests are making sure that git handles the case where the
.gitignore file resides in a subdirectory and the user supplies a path
that does not match the case in the filesystem. In that
case^H^H^H^Hsituation, part of the path supplied by the user is
effectively interpreted case-insensitively, and part of it is
dependent on the setting of core.ignorecase. git should only be
matching the portion of the path below the directory holding the
.gitignore file according to the setting of core.ignorecase.
Imagine a hierarchy that looks like this:
.gitattributes
a/.gitattributes
On a case-insensitive filesystem, if you supply the path A/B,
regardless of whether ignorecase is true or false, git will read the
a/.gitattributes file and use it.
Then if you have:
$ cat a/.gitattributes
b/c test=a/b/c
then you should get the following results:
# the case of a/ does not affect the attr check
$ git -c core.ignorecase=0 check-attr a/b/c
a/b/c: test: a/b/c
$ git -c core.ignorecase=0 check-attr A/b/c
A/b/c: test: a/b/c
$ git -c core.ignorecase=0 check-attr a/B/c
a/B/c: test: unspecified
$ git -c core.ignorecase=1 check-attr a/B/c
a/B/c: test: a/b/c
$ git -c core.ignorecase=0 check-attr A/B/c
A/B/c: test: unspecified
$ git -c core.ignorecase=1 check-attr A/B/c
A/B/c: test: a/b/c
etc.
On a case-sensitive filesystem, a/.gitattributes would never be read
if A/b/c was supplied, regardless of core.ignorecase.
This is also partly future-proofing. Currently, git builds the attr
stack based on the path supplied by the user, so we don't have to do
anything special (like use strcmp_icase) to handle the parts of that
path that don't match the filesystem with respect to case. If git
instead built the attr stack by scanning the repository, then the
paths in the origin field would not necessarily match the paths
supplied by the user. If someone makes a change like that in the
future, these tests will notice.
> I'm sure there is something subtle that I'm missing. Can you explain it
> either here or in the commit message?
Yeah, that commit message was really just a place-holder. I meant to
add WIP in the subject field of the last patch too. I'll try to
explain some of the above when I reroll.
-Brandon
^ permalink raw reply
* [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
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