* [PATCH v3 02/22] git check-ref-format: add options --allow-onelevel and --refspec-pattern
From: Michael Haggerty @ 2011-09-15 21:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, cmn, A Large Angry SCM, Daniel Barkalow,
Sverre Rabbelier, Michael Haggerty
In-Reply-To: <1316121043-29367-1-git-send-email-mhagger@alum.mit.edu>
Also add tests of the new options. (Actually, one big reason to add
the new options is to make it easy to test check_ref_format(), though
the options should also be useful to other scripts.)
Interpret the result of check_ref_format() based on which types of
refnames are allowed. However, because check_ref_format() can only
return a single value, one test case is still broken. Specifically,
the case "git check-ref-format --onelevel '*'" incorrectly succeeds
because check_ref_format() returns CHECK_REF_FORMAT_ONELEVEL for this
refname even though the refname is also CHECK_REF_FORMAT_WILDCARD.
The type of check that leads to this failure is used elsewhere in
"real" code and could lead to bugs; it will be fixed over the next few
commits.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/git-check-ref-format.txt | 29 +++++++++--
builtin/check-ref-format.c | 56 +++++++++++++++++---
t/t1402-check-ref-format.sh | 88 +++++++++++++++++++++++++++++---
3 files changed, 152 insertions(+), 21 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index c9fdf84..dcb8cc3 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -8,8 +8,8 @@ git-check-ref-format - Ensures that a reference name is well formed
SYNOPSIS
--------
[verse]
-'git check-ref-format' <refname>
-'git check-ref-format' --print <refname>
+'git check-ref-format' [--print]
+ [--[no-]allow-onelevel] [--refspec-pattern] <refname>
'git check-ref-format' --branch <branchname-shorthand>
DESCRIPTION
@@ -32,14 +32,18 @@ git imposes the following rules on how references are named:
. They must contain at least one `/`. This enforces the presence of a
category like `heads/`, `tags/` etc. but the actual names are not
- restricted.
+ restricted. If the `--allow-onelevel` option is used, this rule
+ is waived.
. They cannot have two consecutive dots `..` anywhere.
. They cannot have ASCII control characters (i.e. bytes whose
values are lower than \040, or \177 `DEL`), space, tilde `~`,
- caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
- or open bracket `[` anywhere.
+ caret `{caret}`, or colon `:` anywhere.
+
+. They cannot have question-mark `?`, asterisk `{asterisk}`, or open
+ bracket `[` anywhere. See the `--refspec-pattern` option below for
+ an exception to this rule.
. They cannot end with a slash `/` nor a dot `.`.
@@ -78,6 +82,21 @@ were on. This option should be used by porcelains to accept this
syntax anywhere a branch name is expected, so they can act as if you
typed the branch name.
+OPTIONS
+-------
+--allow-onelevel::
+--no-allow-onelevel::
+ Controls whether one-level refnames are accepted (i.e.,
+ refnames that do not contain multiple `/`-separated
+ components). The default is `--no-allow-onelevel`.
+
+--refspec-pattern::
+ Interpret <refname> as a reference name pattern for a refspec
+ (as used with remote repositories). If this option is
+ enabled, <refname> is allowed to contain a single `{asterisk}`
+ in place of a one full pathname component (e.g.,
+ `foo/{asterisk}/bar` but not `foo/bar{asterisk}`).
+
EXAMPLES
--------
diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
index 0723cf2..7295954 100644
--- a/builtin/check-ref-format.c
+++ b/builtin/check-ref-format.c
@@ -8,7 +8,7 @@
#include "strbuf.h"
static const char builtin_check_ref_format_usage[] =
-"git check-ref-format [--print] <refname>\n"
+"git check-ref-format [--print] [options] <refname>\n"
" or: git check-ref-format --branch <branchname-shorthand>";
/*
@@ -45,27 +45,65 @@ static int check_ref_format_branch(const char *arg)
return 0;
}
-static int check_ref_format_print(const char *arg)
+static void refname_format_print(const char *arg)
{
char *refname = xmalloc(strlen(arg) + 1);
- if (check_ref_format(arg))
- return 1;
collapse_slashes(refname, arg);
printf("%s\n", refname);
- return 0;
}
+#define REFNAME_ALLOW_ONELEVEL 1
+#define REFNAME_REFSPEC_PATTERN 2
+
int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
{
+ int i;
+ int print = 0;
+ int flags = 0;
+
if (argc == 2 && !strcmp(argv[1], "-h"))
usage(builtin_check_ref_format_usage);
if (argc == 3 && !strcmp(argv[1], "--branch"))
return check_ref_format_branch(argv[2]);
- if (argc == 3 && !strcmp(argv[1], "--print"))
- return check_ref_format_print(argv[2]);
- if (argc != 2)
+
+ for (i = 1; i < argc && argv[i][0] == '-'; i++) {
+ if (!strcmp(argv[i], "--print"))
+ print = 1;
+ else if (!strcmp(argv[i], "--allow-onelevel"))
+ flags |= REFNAME_ALLOW_ONELEVEL;
+ else if (!strcmp(argv[i], "--no-allow-onelevel"))
+ flags &= ~REFNAME_ALLOW_ONELEVEL;
+ else if (!strcmp(argv[i], "--refspec-pattern"))
+ flags |= REFNAME_REFSPEC_PATTERN;
+ else
+ usage(builtin_check_ref_format_usage);
+ }
+ if (! (i == argc - 1))
usage(builtin_check_ref_format_usage);
- return !!check_ref_format(argv[1]);
+
+ switch (check_ref_format(argv[i])) {
+ case CHECK_REF_FORMAT_OK:
+ break;
+ case CHECK_REF_FORMAT_ERROR:
+ return 1;
+ case CHECK_REF_FORMAT_ONELEVEL:
+ if (!(flags & REFNAME_ALLOW_ONELEVEL))
+ return 1;
+ else
+ break;
+ case CHECK_REF_FORMAT_WILDCARD:
+ if (!(flags & REFNAME_REFSPEC_PATTERN))
+ return 1;
+ else
+ break;
+ default:
+ die("internal error: unexpected value from check_ref_format()");
+ }
+
+ if (print)
+ refname_format_print(argv[i]);
+
+ return 0;
}
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index dc43171..f551eef 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -5,25 +5,38 @@ test_description='Test git check-ref-format'
. ./test-lib.sh
valid_ref() {
- test_expect_success "ref name '$1' is valid" \
- "git check-ref-format '$1'"
+ if test "$#" = 1
+ then
+ test_expect_success "ref name '$1' is valid" \
+ "git check-ref-format '$1'"
+ else
+ test_expect_success "ref name '$1' is valid with options $2" \
+ "git check-ref-format $2 '$1'"
+ fi
}
invalid_ref() {
- test_expect_success "ref name '$1' is not valid" \
- "test_must_fail git check-ref-format '$1'"
+ if test "$#" = 1
+ then
+ test_expect_success "ref name '$1' is invalid" \
+ "test_must_fail git check-ref-format '$1'"
+ else
+ test_expect_success "ref name '$1' is invalid with options $2" \
+ "test_must_fail git check-ref-format $2 '$1'"
+ fi
}
invalid_ref ''
invalid_ref '/'
-valid_ref 'heads/foo'
-invalid_ref 'foo'
+invalid_ref '/' --allow-onelevel
valid_ref 'foo/bar/baz'
valid_ref 'refs///heads/foo'
invalid_ref 'heads/foo/'
valid_ref '/heads/foo'
valid_ref '///heads/foo'
-invalid_ref '/foo'
invalid_ref './foo'
+invalid_ref './foo/bar'
+invalid_ref 'foo/./bar'
+invalid_ref 'foo/bar/.'
invalid_ref '.refs/foo'
invalid_ref 'heads/foo..bar'
invalid_ref 'heads/foo?bar'
@@ -38,6 +51,67 @@ invalid_ref 'heads/foo\bar'
invalid_ref "$(printf 'heads/foo\t')"
invalid_ref "$(printf 'heads/foo\177')"
valid_ref "$(printf 'heads/fu\303\237')"
+invalid_ref 'heads/*foo/bar' --refspec-pattern
+invalid_ref 'heads/foo*/bar' --refspec-pattern
+invalid_ref 'heads/f*o/bar' --refspec-pattern
+
+ref='foo'
+invalid_ref "$ref"
+valid_ref "$ref" --allow-onelevel
+invalid_ref "$ref" --refspec-pattern
+valid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='foo/bar'
+valid_ref "$ref"
+valid_ref "$ref" --allow-onelevel
+valid_ref "$ref" --refspec-pattern
+valid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='foo/*'
+invalid_ref "$ref"
+invalid_ref "$ref" --allow-onelevel
+valid_ref "$ref" --refspec-pattern
+valid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='*/foo'
+invalid_ref "$ref"
+invalid_ref "$ref" --allow-onelevel
+valid_ref "$ref" --refspec-pattern
+valid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='foo/*/bar'
+invalid_ref "$ref"
+invalid_ref "$ref" --allow-onelevel
+valid_ref "$ref" --refspec-pattern
+valid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='*'
+invalid_ref "$ref"
+
+#invalid_ref "$ref" --allow-onelevel
+test_expect_failure "ref name '$ref' is invalid with options --allow-onelevel" \
+ "test_must_fail git check-ref-format --allow-onelevel '$ref'"
+
+invalid_ref "$ref" --refspec-pattern
+valid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='foo/*/*'
+invalid_ref "$ref" --refspec-pattern
+invalid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='*/foo/*'
+invalid_ref "$ref" --refspec-pattern
+invalid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='*/*/foo'
+invalid_ref "$ref" --refspec-pattern
+invalid_ref "$ref" '--refspec-pattern --allow-onelevel'
+
+ref='/foo'
+invalid_ref "$ref"
+valid_ref "$ref" --allow-onelevel
+invalid_ref "$ref" --refspec-pattern
+valid_ref "$ref" '--refspec-pattern --allow-onelevel'
test_expect_success "check-ref-format --branch @{-1}" '
T=$(git write-tree) &&
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 00/22] Clean up refname checks and normalization
From: Michael Haggerty @ 2011-09-15 21:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, cmn, A Large Angry SCM, Daniel Barkalow,
Sverre Rabbelier, Michael Haggerty
This patch series cleans up refname checks and normalization in a
different way than v1 and v2. (Unnormalized refnames are those that
have extra leading slashes or runs of repeated slashes between
components, like "//refs/heads///master".)
As discussed on the mailing list [1], adding consistent support for
unnormalized refnames everywhere was becoming a bottomless pit, so
instead I am taking the opposite approach--only accept normalized
refnames. Support for unnormalized refnames was broken anyway, so it
shouldn't be missed.
There is only one command that is now meant to accept unnormalized
refnames:
$ git check-ref-format --normalize //refs/heads///master
refs/heads/master
$
This command can be used to normalize refnames for use elsewhere.
I have added a few internal checks that refnames have the correct
format; more tests should still be added. But this patch series is
getting quite long already, so I would like to submit it.
During the development of this patch series, I discovered that
fetch_with_import() in remote-helper.c sometimes passes NULL to
read_ref(), and thereby to resolve_ref(). The two commits labeled
"remote: *" fix this in a naive way. But somebody more familiar with
this code should check whether the fix is OK and more specifically
whether this is a symptom of a bigger problem in the remote-helper
code.
I should mention that this cleanup is preparation for my main goal:
storing ref caches hierarchically. But there is still a lot of
tangled up and seemingly redundant code in refs.c, so it might be a
while before I get to the main project.
[1] http://permalink.gmane.org/gmane.comp.version-control.git/181268
Michael Haggerty (22):
t1402: add some more tests
git check-ref-format: add options --allow-onelevel and
--refspec-pattern
Change bad_ref_char() to return a boolean value
Change check_ref_format() to take a flags argument
Refactor check_refname_format()
Do not allow ".lock" at the end of any refname component
Make collapse_slashes() allocate memory for its result
Inline function refname_format_print()
Change check_refname_format() to reject unnormalized refnames
resolve_ref(): explicitly fail if a symlink is not readable
resolve_ref(): use prefixcmp()
resolve_ref(): only follow a symlink that contains a valid,
normalized refname
resolve_ref(): turn buffer into a proper string as soon as possible
resolve_ref(): extract a function get_packed_ref()
resolve_ref(): do not follow incorrectly-formatted symbolic refs
remote: use xstrdup() instead of strdup()
remote: avoid passing NULL to read_ref()
resolve_ref(): verify that the input refname has the right format
resolve_ref(): emit warnings for improperly-formatted references
resolve_ref(): also treat a too-long SHA1 as invalid
resolve_ref(): expand documentation
add_ref(): verify that the refname is formatted correctly
Documentation/git-check-ref-format.txt | 53 ++++++--
builtin/check-ref-format.c | 61 ++++++---
builtin/checkout.c | 2 +-
builtin/fetch-pack.c | 2 +-
builtin/receive-pack.c | 2 +-
builtin/replace.c | 2 +-
builtin/show-ref.c | 2 +-
builtin/tag.c | 4 +-
cache.h | 34 +++++-
connect.c | 2 +-
environment.c | 2 +-
fast-import.c | 7 +-
git_remote_helpers/git/git.py | 2 +-
notes-merge.c | 5 +-
pack-refs.c | 2 +-
refs.c | 222 +++++++++++++++++++-------------
refs.h | 21 +++-
remote.c | 55 ++------
sha1_name.c | 4 +-
t/t1402-check-ref-format.sh | 120 +++++++++++++++--
transport-helper.c | 10 +-
transport.c | 16 +--
walker.c | 2 +-
23 files changed, 408 insertions(+), 224 deletions(-)
--
1.7.6.8.gd2879
^ permalink raw reply
* Re: zealous git convert determined to set up git server
From: Luke Diamand @ 2011-09-15 20:59 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Jakub Narebski, Git List
In-Reply-To: <CAOZxsTqtW=DD7zFwQLjknJR8g0nnh0WPUPna6_np4bVoGnSntQ@mail.gmail.com>
On 15/09/11 12:38, Joshua Stoutenburg wrote:
> Breaking away from previous conversation "Anybody home?"
>
> I totally didn't see "The Git Community Book". There's no link for it
> where I was looking: http://git-scm.com/documentation
>
> As for setting up a work station, I found a pretty good guide at GitHub:
> Windows: http://help.github.com/win-set-up-git/
> Linux: http://help.github.com/linux-set-up-git/
>
> Question 1: With both "Pro Git" and "The Git Community Book", has
> anybody noticed any major discrepancies between the pdf and online
> versions? I'd like to place the pdf versions on my mobile device for
> travel reading.
>
> Question 2: It seems gitolite is the popular choice for git user
> management. Any reason why?
I use it. Seems good to me:
- Very easy to install (might just be apt-get install gitolite)
- Git users don't need to have real user accounts on the server machine
- Can do quite sophisticated things with permissions
>
> Question 3: So, Gitorious is more than just a repository hosting
> website? It's also an open source repository hosting platform, which
> powers the Gitorious website? That's pretty cool.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 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
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