* [PATCH v1 43/45] pathspec: make --literal-pathspecs disable pathspec magic
From: Nguyễn Thái Ngọc Duy @ 2013-03-15 6:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1363327620-29017-1-git-send-email-pclouds@gmail.com>
--literal-pathspecs and its equivalent environment variable are
probably used for scripting. In that setting, pathspec magic may be
unwanted. Disabling globbing in individual pathspec can be done via
:(literal) magic.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git.txt | 4 ++--
pathspec.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 7efaa59..3bbbbdc 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -439,8 +439,8 @@ help ...`.
linkgit:git-replace[1] for more information.
--literal-pathspecs::
- Treat pathspecs literally, rather than as glob patterns. This is
- equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
+ Treat pathspecs literally (i.e. no globbing, no pathspec magic).
+ This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
variable to `1`.
diff --git a/pathspec.c b/pathspec.c
index e57196d..61a47b8 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -103,7 +103,7 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
if (literal_global)
global_magic |= PATHSPEC_LITERAL;
- if (elt[0] != ':') {
+ if (elt[0] != ':' || literal_global) {
; /* nothing to do */
} else if (elt[1] == '(') {
/* longhand */
--
1.8.0.rc0.19.g7bbb31d
^ permalink raw reply related
* [PATCH v1 44/45] pathspec: support :(glob) syntax
From: Nguyễn Thái Ngọc Duy @ 2013-03-15 6:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1363327620-29017-1-git-send-email-pclouds@gmail.com>
:(glob)path differs from plain pathspec that it uses wildmatch with
WM_PATHNAME while the other uses fnmatch without FNM_PATHNAME. The
difference lies in how '*' (and '**') is processed.
With the introduction of :(glob) and :(literal) and their global
options --[no]glob-pathspecs, the user can:
- make everything literal by default via --noglob-pathspecs
--literal-pathspecs cannot be used for this purpose as it
disables _all_ pathspec magic.
- individually turn on globbing with :(glob)
- make everything globbing by default via --glob-pathspecs
- individually turn off globbing with :(literal)
The implication behind this is, there is no way to gain the default
matching behavior (i.e. fnmatch without FNM_PATHNAME). You either get
new globbing or literal. The old fnmatch behavior is considered
deprecated and discouraged to use.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git.txt | 19 +++++++++++++++++
Documentation/glossary-content.txt | 29 +++++++++++++++++++++++++
builtin/add.c | 9 ++++++--
builtin/ls-tree.c | 2 +-
cache.h | 2 ++
dir.c | 28 ++++++++++++++-----------
dir.h | 9 ++++----
git.c | 8 +++++++
pathspec.c | 43 +++++++++++++++++++++++++++++++++-----
pathspec.h | 4 +++-
tree-walk.c | 9 ++++----
11 files changed, 131 insertions(+), 31 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3bbbbdc..d96df8d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -443,6 +443,17 @@ help ...`.
This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
variable to `1`.
+--glob-pathspecs:
+ Add "glob" magic to all pathspec. This is equivalent to setting
+ the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(literal)"
+
+--noglob-pathspecs:
+ Add "literal" magic to all pathspec. This is equivalent to setting
+ the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(glob)"
GIT COMMANDS
------------
@@ -834,6 +845,14 @@ GIT_LITERAL_PATHSPECS::
literal paths to Git (e.g., paths previously given to you by
`git ls-tree`, `--raw` diff output, etc).
+GIT_GLOB_PATHSPECS::
+ Setting this variable to `1` will cause git to treat all
+ pathspecs as glob patterns (aka "glob" magic).
+
+GIT_NOGLOB_PATHSPECS::
+ Setting this variable to `1` will cause git to treat all
+ pathspecs as literal (aka "literal" magic).
+
Discussion[[Discussion]]
------------------------
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 8b91aeb..40f2d29 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -327,6 +327,35 @@ top `/`;;
literal;;
Wildcards in the pattern such as `*` or `?` are treated
as literal characters.
+
+glob;;
+ Git treats the pattern as a shell glob suitable for
+ consumption by fnmatch(3) with the FNM_PATHNAME flag:
+ wildcards in the pattern will not match a / in the pathname.
+ For example, "Documentation/{asterisk}.html" matches
+ "Documentation/git.html" but not "Documentation/ppc/ppc.html"
+ or "tools/perf/Documentation/perf.html".
++
+Two consecutive asterisks ("`**`") in patterns matched against
+full pathname may have special meaning:
+
+ - A leading "`**`" followed by a slash means match in all
+ directories. For example, "`**/foo`" matches file or directory
+ "`foo`" anywhere, the same as pattern "`foo`". "**/foo/bar"
+ matches file or directory "`bar`" anywhere that is directly
+ under directory "`foo`".
+
+ - A trailing "/**" matches everything inside. For example,
+ "abc/**" matches all files inside directory "abc", relative
+ to the location of the `.gitignore` file, with infinite depth.
+
+ - A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, "`a/**/b`"
+ matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on.
+
+ - Other consecutive asterisks are considered invalid.
++
+Glob magic is incompatible with literal magic.
--
+
Currently only the slash `/` is recognized as the "magic signature",
diff --git a/builtin/add.c b/builtin/add.c
index 8bc6b45..d07cd1b 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -426,11 +426,16 @@ int cmd_add(int argc, const char **argv, const char *prefix)
/*
* file_exists() assumes exact match
*/
- GUARD_PATHSPEC(&pathspec, PATHSPEC_FROMTOP | PATHSPEC_LITERAL);
+ GUARD_PATHSPEC(&pathspec,
+ PATHSPEC_FROMTOP |
+ PATHSPEC_LITERAL |
+ PATHSPEC_GLOB);
for (i = 0; i < pathspec.nr; i++) {
const char *path = pathspec.items[i].match;
- if (!seen[i] && !file_exists(path)) {
+ if (!seen[i] &&
+ ((pathspec.items[i].magic & PATHSPEC_GLOB) ||
+ !file_exists(path))) {
if (ignore_missing) {
int dtype = DT_UNKNOWN;
if (is_path_excluded(&check, path, -1, &dtype))
diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
index bdb03f3..1056634 100644
--- a/builtin/ls-tree.c
+++ b/builtin/ls-tree.c
@@ -173,7 +173,7 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
* cannot be lifted until it is converted to use
* match_pathspec_depth() or tree_entry_interesting()
*/
- parse_pathspec(&pathspec, 0,
+ parse_pathspec(&pathspec, PATHSPEC_GLOB,
PATHSPEC_PREFER_CWD,
prefix, argv + 1);
for (i = 0; i < pathspec.nr; i++)
diff --git a/cache.h b/cache.h
index 17e0b26..bdc98e2 100644
--- a/cache.h
+++ b/cache.h
@@ -365,6 +365,8 @@ static inline enum object_type object_type(unsigned int mode)
#define GIT_NOTES_REWRITE_REF_ENVIRONMENT "GIT_NOTES_REWRITE_REF"
#define GIT_NOTES_REWRITE_MODE_ENVIRONMENT "GIT_NOTES_REWRITE_MODE"
#define GIT_LITERAL_PATHSPECS_ENVIRONMENT "GIT_LITERAL_PATHSPECS"
+#define GIT_GLOB_PATHSPECS_ENVIRONMENT "GIT_GLOB_PATHSPECS"
+#define GIT_NOGLOB_PATHSPECS_ENVIRONMENT "GIT_NOGLOB_PATHSPECS"
/*
* Repository-local GIT_* environment variables
diff --git a/dir.c b/dir.c
index 8d9ed24..77cd427 100644
--- a/dir.c
+++ b/dir.c
@@ -38,26 +38,28 @@ int fnmatch_icase(const char *pattern, const char *string, int flags)
return fnmatch(pattern, string, flags | (ignore_case ? FNM_CASEFOLD : 0));
}
-inline int git_fnmatch(const char *pattern, const char *string,
- int flags, int prefix)
+inline int git_fnmatch(const struct pathspec_item *item,
+ const char *pattern, const char *string,
+ int prefix)
{
- int fnm_flags = 0;
- if (flags & GFNM_PATHNAME)
- fnm_flags |= FNM_PATHNAME;
if (prefix > 0) {
if (strncmp(pattern, string, prefix))
return FNM_NOMATCH;
pattern += prefix;
string += prefix;
}
- if (flags & GFNM_ONESTAR) {
+ if (item->flags & PATHSPEC_ONESTAR) {
int pattern_len = strlen(++pattern);
int string_len = strlen(string);
return string_len < pattern_len ||
strcmp(pattern,
string + string_len - pattern_len);
}
- return fnmatch(pattern, string, fnm_flags);
+ if (item->magic & PATHSPEC_GLOB)
+ return wildmatch(pattern, string, WM_PATHNAME, NULL);
+ else
+ /* wildmatch has not learned no FNM_PATHNAME mode yet */
+ return fnmatch(pattern, string, 0);
}
static size_t common_prefix_len(const struct pathspec *pathspec)
@@ -68,7 +70,8 @@ static size_t common_prefix_len(const struct pathspec *pathspec)
GUARD_PATHSPEC(pathspec,
PATHSPEC_FROMTOP |
PATHSPEC_MAXDEPTH |
- PATHSPEC_LITERAL);
+ PATHSPEC_LITERAL |
+ PATHSPEC_GLOB);
for (n = 0; n < pathspec->nr; n++) {
size_t i = 0, len = 0;
@@ -163,8 +166,7 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
}
if (item->nowildcard_len < item->len &&
- !git_fnmatch(match, name,
- item->flags & PATHSPEC_ONESTAR ? GFNM_ONESTAR : 0,
+ !git_fnmatch(item, match, name,
item->nowildcard_len - prefix))
return MATCHED_FNMATCH;
@@ -195,7 +197,8 @@ int match_pathspec_depth(const struct pathspec *ps,
GUARD_PATHSPEC(ps,
PATHSPEC_FROMTOP |
PATHSPEC_MAXDEPTH |
- PATHSPEC_LITERAL);
+ PATHSPEC_LITERAL |
+ PATHSPEC_GLOB);
if (!ps->nr) {
if (!ps->recursive ||
@@ -1347,7 +1350,8 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const stru
GUARD_PATHSPEC(pathspec,
PATHSPEC_FROMTOP |
PATHSPEC_MAXDEPTH |
- PATHSPEC_LITERAL);
+ PATHSPEC_LITERAL |
+ PATHSPEC_GLOB);
if (has_symlink_leading_path(path, len))
return dir->nr;
diff --git a/dir.h b/dir.h
index 13da62c..da67237 100644
--- a/dir.h
+++ b/dir.h
@@ -208,10 +208,9 @@ extern int fnmatch_icase(const char *pattern, const char *string, int flags);
/*
* The prefix part of pattern must not contains wildcards.
*/
-#define GFNM_PATHNAME 1 /* similar to FNM_PATHNAME */
-#define GFNM_ONESTAR 2 /* there is only _one_ wildcard, a star */
-
-extern int git_fnmatch(const char *pattern, const char *string,
- int flags, int prefix);
+struct pathspec_item;
+extern int git_fnmatch(const struct pathspec_item *item,
+ const char *pattern, const char *string,
+ int prefix);
#endif
diff --git a/git.c b/git.c
index 39ba6b1..65c386a 100644
--- a/git.c
+++ b/git.c
@@ -143,6 +143,14 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
setenv(GIT_LITERAL_PATHSPECS_ENVIRONMENT, "0", 1);
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--glob-pathspecs")) {
+ setenv(GIT_GLOB_PATHSPECS_ENVIRONMENT, "1", 1);
+ if (envchanged)
+ *envchanged = 1;
+ } else if (!strcmp(cmd, "--noglob-pathspecs")) {
+ setenv(GIT_NOGLOB_PATHSPECS_ENVIRONMENT, "1", 1);
+ if (envchanged)
+ *envchanged = 1;
} else {
fprintf(stderr, "Unknown option: %s\n", cmd);
usage(git_usage_string);
diff --git a/pathspec.c b/pathspec.c
index 61a47b8..7ddcf55 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -57,7 +57,6 @@ char *find_pathspecs_matching_against_index(const struct pathspec *pathspec)
*
* Possible future magic semantics include stuff like:
*
- * { PATHSPEC_NOGLOB, '!', "noglob" },
* { PATHSPEC_ICASE, '\0', "icase" },
* { PATHSPEC_RECURSIVE, '*', "recursive" },
* { PATHSPEC_REGEXP, '\0', "regexp" },
@@ -71,6 +70,7 @@ static struct pathspec_magic {
} pathspec_magic[] = {
{ PATHSPEC_FROMTOP, '/', "top" },
{ PATHSPEC_LITERAL, 0, "literal" },
+ { PATHSPEC_GLOB, '\0', "glob" },
};
/*
@@ -93,6 +93,8 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
const char *elt)
{
static int literal_global = -1;
+ static int glob_global = -1;
+ static int noglob_global = -1;
unsigned magic = 0, short_magic = 0, global_magic = 0;
const char *copyfrom = elt, *long_magic_end = NULL;
char *match;
@@ -103,6 +105,22 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
if (literal_global)
global_magic |= PATHSPEC_LITERAL;
+ if (glob_global < 0)
+ glob_global = git_env_bool(GIT_GLOB_PATHSPECS_ENVIRONMENT, 0);
+ if (glob_global)
+ global_magic |= PATHSPEC_GLOB;
+
+ if (noglob_global < 0)
+ noglob_global = git_env_bool(GIT_NOGLOB_PATHSPECS_ENVIRONMENT, 0);
+
+ if (glob_global && noglob_global)
+ die(_("global 'glob' and 'noglob' pathspec settings are incompatible"));
+
+ if ((global_magic & PATHSPEC_LITERAL) &&
+ (global_magic & ~PATHSPEC_LITERAL))
+ die(_("global 'literal' pathspec setting is incompatiable "
+ "with all other global pathspec settings"));
+
if (elt[0] != ':' || literal_global) {
; /* nothing to do */
} else if (elt[1] == '(') {
@@ -166,12 +184,20 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
magic |= short_magic;
*p_short_magic = short_magic;
+
+ /* --noglob-pathspec adds :(literal) _unless_ :(glob) is specifed */
+ if (noglob_global && !(magic & PATHSPEC_GLOB))
+ global_magic |= PATHSPEC_LITERAL;
+
magic |= global_magic;
if (pathspec_prefix >= 0 &&
(prefixlen || (prefix && *prefix)))
die("BUG: 'prefix' magic is supposed to be used at worktree's root");
+ if ((magic & PATHSPEC_LITERAL) && (magic & PATHSPEC_GLOB))
+ die("%s: 'literal' and 'glob' are incompatible", elt);
+
if (pathspec_prefix >= 0) {
match = xstrdup(copyfrom);
prefixlen = pathspec_prefix;
@@ -247,10 +273,17 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
item->nowildcard_len = prefixlen;
}
item->flags = 0;
- if (item->nowildcard_len < item->len &&
- item->match[item->nowildcard_len] == '*' &&
- no_wildcard(item->match + item->nowildcard_len + 1))
- item->flags |= PATHSPEC_ONESTAR;
+ if (magic & PATHSPEC_GLOB) {
+ /*
+ * FIXME: should we enable ONESTAR in _GLOB for
+ * pattern "* * / * . c"?
+ */
+ } else {
+ if (item->nowildcard_len < item->len &&
+ item->match[item->nowildcard_len] == '*' &&
+ no_wildcard(item->match + item->nowildcard_len + 1))
+ item->flags |= PATHSPEC_ONESTAR;
+ }
return magic;
}
diff --git a/pathspec.h b/pathspec.h
index d5db7d5..9a0c5d5 100644
--- a/pathspec.h
+++ b/pathspec.h
@@ -5,10 +5,12 @@
#define PATHSPEC_FROMTOP (1<<0)
#define PATHSPEC_MAXDEPTH (1<<1)
#define PATHSPEC_LITERAL (1<<2)
+#define PATHSPEC_GLOB (1<<3)
#define PATHSPEC_ALL_MAGIC \
(PATHSPEC_FROMTOP | \
PATHSPEC_MAXDEPTH | \
- PATHSPEC_LITERAL)
+ PATHSPEC_LITERAL | \
+ PATHSPEC_GLOB)
#define PATHSPEC_ONESTAR 1 /* the pathspec pattern sastisfies GFNM_ONESTAR */
diff --git a/tree-walk.c b/tree-walk.c
index 676bd7f..a44f528 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -639,7 +639,8 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
GUARD_PATHSPEC(ps,
PATHSPEC_FROMTOP |
PATHSPEC_MAXDEPTH |
- PATHSPEC_LITERAL);
+ PATHSPEC_LITERAL |
+ PATHSPEC_GLOB);
if (!ps->nr) {
if (!ps->recursive ||
@@ -685,8 +686,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
return entry_interesting;
if (item->nowildcard_len < item->len) {
- if (!git_fnmatch(match + baselen, entry->path,
- item->flags & PATHSPEC_ONESTAR ? GFNM_ONESTAR : 0,
+ if (!git_fnmatch(item, match + baselen, entry->path,
item->nowildcard_len - baselen))
return entry_interesting;
@@ -727,8 +727,7 @@ match_wildcards:
strbuf_add(base, entry->path, pathlen);
- if (!git_fnmatch(match, base->buf + base_offset,
- item->flags & PATHSPEC_ONESTAR ? GFNM_ONESTAR : 0,
+ if (!git_fnmatch(item, match, base->buf + base_offset,
item->nowildcard_len)) {
strbuf_setlen(base, base_offset + baselen);
return entry_interesting;
--
1.8.0.rc0.19.g7bbb31d
^ permalink raw reply related
* [PATCH v1 45/45] Rename field "raw" to "_raw" in struct pathspec
From: Nguyễn Thái Ngọc Duy @ 2013-03-15 6:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1363327620-29017-1-git-send-email-pclouds@gmail.com>
This patch is essentially no-op. It helps catching new use of this
field though. This field is introduced as an intermediate step for the
pathspec conversion and will be removed eventually. At this stage no
more access sites should be introduced.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/ls-tree.c | 2 +-
dir.c | 4 ++--
pathspec.c | 6 +++---
pathspec.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
index 1056634..7882352 100644
--- a/builtin/ls-tree.c
+++ b/builtin/ls-tree.c
@@ -36,7 +36,7 @@ static int show_recursive(const char *base, int baselen, const char *pathname)
if (ls_options & LS_RECURSIVE)
return 1;
- s = pathspec.raw;
+ s = pathspec._raw;
if (!s)
return 0;
diff --git a/dir.c b/dir.c
index 77cd427..e52c899 100644
--- a/dir.c
+++ b/dir.c
@@ -115,7 +115,7 @@ int fill_directory(struct dir_struct *dir, const struct pathspec *pathspec)
len = common_prefix_len(pathspec);
/* Read the directory and prune it */
- read_directory(dir, pathspec->nr ? pathspec->raw[0] : "", len, pathspec);
+ read_directory(dir, pathspec->nr ? pathspec->_raw[0] : "", len, pathspec);
return len;
}
@@ -1356,7 +1356,7 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const stru
if (has_symlink_leading_path(path, len))
return dir->nr;
- simplify = create_simplify(pathspec ? pathspec->raw : NULL);
+ simplify = create_simplify(pathspec ? pathspec->_raw : NULL);
if (!len || treat_leading_path(dir, path, len, simplify))
read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
diff --git a/pathspec.c b/pathspec.c
index 7ddcf55..9640d88 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -365,7 +365,7 @@ void parse_pathspec(struct pathspec *pathspec,
raw[0] = prefix;
raw[1] = NULL;
pathspec->nr = 1;
- pathspec->raw = raw;
+ pathspec->_raw = raw;
return;
}
@@ -375,7 +375,7 @@ void parse_pathspec(struct pathspec *pathspec,
pathspec->nr = n;
pathspec->items = item = xmalloc(sizeof(*item) * n);
- pathspec->raw = argv;
+ pathspec->_raw = argv;
prefixlen = prefix ? strlen(prefix) : 0;
for (i = 0; i < n; i++) {
@@ -436,7 +436,7 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
~(PATHSPEC_FROMTOP | PATHSPEC_LITERAL),
PATHSPEC_PREFER_CWD,
prefix, pathspec);
- return ps.raw;
+ return ps._raw;
}
void copy_pathspec(struct pathspec *dst, const struct pathspec *src)
diff --git a/pathspec.h b/pathspec.h
index 9a0c5d5..84f279d 100644
--- a/pathspec.h
+++ b/pathspec.h
@@ -15,7 +15,7 @@
#define PATHSPEC_ONESTAR 1 /* the pathspec pattern sastisfies GFNM_ONESTAR */
struct pathspec {
- const char **raw; /* get_pathspec() result, not freed by free_pathspec() */
+ const char **_raw; /* get_pathspec() result, not freed by free_pathspec() */
int nr;
unsigned int has_wildcard:1;
unsigned int recursive:1;
--
1.8.0.rc0.19.g7bbb31d
^ permalink raw reply related
* SSH version on Git 1.8.1.2 for Windows is outdated.
From: Kristof Mattei @ 2013-03-15 10:05 UTC (permalink / raw)
To: git
We're having issues with the version of SSH included in git version
1.8.1.msysgit.1 (Git-1.8.1.2-preview20130201.exe)
The included version of SSH is from 2007:
C:\Program Files (x86)\Git\bin - Old>ssh -V
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
Updating the OpenSSH component (downloaded with Cygwin, cumbersome!!!)
resolves the issue:
C:\Program Files (x86)\Git\bin>ssh -V
OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013
Is there any way you can incorporate this update in the installer?
Thanks,
-Kristof
--
Kristof Mattei
Human Compiler
Blog: www.kristofmattei.be
Twitter: KristofMattei
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Daniel Stenberg @ 2013-03-15 10:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, kusmabite, git, msysgit
In-Reply-To: <7vk3p9wqh5.fsf@alter.siamese.dyndns.org>
On Thu, 14 Mar 2013, Junio C Hamano wrote:
> As to ALL vs DEFAULT, given that its manual page is riddled with a scary
> warning:
>
> This function must be called at least once within a program (a
> program is all the code that shares a memory space) before the
> program calls any other function in libcurl. The environment it sets
> up is constant for the life of the program and is the same for every
> program, so multiple calls have the same effect as one call. ... In
> normal operation, you must specify CURL_GLOBAL_ALL. Don't use any
> other value unless you are familiar with it and mean to control
> internal operations of libcurl.
(speaking from a libcurl perspective)
The "warning" is just there to scare people into actually consider what they
want and understand that removing bits will change behavior. I would say
that's exactly what you've done and I don't think people here need to be
scared anymore! :-)
As for how ALL vs DEFAULT will act or differ in the future, I suspect that we
will end up having them being the same (even when we add bits) as we've
encouraged "ALL" in the documentation like this for quite some time.
--
/ daniel.haxx.se
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: Bug: git web--browse doesn't recognise browser on OS X
From: Christian Couder @ 2013-03-15 11:19 UTC (permalink / raw)
To: Timo Sand; +Cc: git
In-Reply-To: <CAMxBVStw-b3J_Fm9x=h3==9ebdLUkpjBSQ9-W4+zJ9N20ojfxg@mail.gmail.com>
Hi,
On Thu, Mar 14, 2013 at 12:39 PM, Timo Sand <timo.j.sand@gmail.com> wrote:
> Hi
>
> I tried to open a website by runnin 'git web--browse http://google.com'
> and it replied 'No known browser available'.
First git web--browse is a plumbing shell script to display
documentation on a web browser when you type something like "git help
-w log".
It is not really supposed to be used directly by the user. On OS X it
might be simpler to just type "open http://google.com".
That said there is the following in it to make it work on OS X:
# SECURITYSESSIONID indicates an OS X GUI login session
if test -n "$SECURITYSESSIONID" \
-o "$TERM_PROGRAM" = "Apple_Terminal" ; then
browser_candidates="open $browser_candidates"
fi
So I guess that you don't have SECURITYSESSIONID set in your terminal
and you are not using Apple Terminal.
As I am not using OS X, I have no idea how to improve the script in this case.
> I also tried with '--browser=chrome' and '--browser=google-chrome' but
> the responded with 'The browser chrome is not available as 'chrome'.'
Could you try something like: "chromium http://google.com" or
"chromium-browser http://google.com"
If it works, then using 'git web--browse' with '--browser=chromium' or
'--browser=chromium-browser' should work.
Otherwise did you try "chrome http://google.com" and "google-chrome
http://google.com"?
> I expected the command to open a new tab in my browser in each of the 3 tries.
> This has worked for my system before.
>
> OS X 10.8.2, git 1.8.2, Google Chrome 27.0.1438.7 dev
Thanks,
Christian.
^ permalink raw reply
* [BUG?] google code http auth weirdness
From: Jeff King @ 2013-03-15 11:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
I tried pushing to a repository at Google Code for the first time today,
and I encountered some weird behavior with respect to asking for
credentials.
If I use the url "https://code.google.com/r/repo/", everything works; I
get prompted for my username/password.
But if I instead use the url "https://myuser@code.google.com/r/repo/",
it doesn't work. I get:
$ git push
fatal: remote error: Invalid username/password.
You may need to use your generated googlecode.com password; see
https://code.google.com/hosting/settings
without any prompt at all. I bisected it to 986bbc0 (http: don't always
prompt for password, 2011-11-04), but I think that is a red herring. It
worked before that commit because we always asked for the password,
before we even talked to the server.
After that commit, we should be reacting to an HTTP 401. But it seems that
Google Code's 401 behavior is odd. When t5540 checks this, the
conversation goes something like:
1. We do a GET with no "Authorization" header.
2. The server returns a 401, asking for credentials.
3. Curl repeats the GET request, putting the username into the
Authorization header.
4. The server returns a 401, again, as our credential is not
sufficient.
5. Curl returns the 401 to git; git prompts for the credential, feeds
it to curl, and then repeats the request. It works.
But with Google Code, the first three steps are identical. But then for
step 4, the server returns this:
< HTTP/1.1 200 OK
< Content-Type: application/x-git-receive-pack-advertisement
< X-Content-Type-Options: nosniff
< Date: Fri, 15 Mar 2013 11:43:14 GMT
< Server: git_frontend
< Content-Length: 175
< X-XSS-Protection: 1; mode=block
<
* Connection #0 to host code.google.com left intact
packet: git< # service=git-receive-pack
packet: git< 0000
packet: git< ERR Invalid username/password [...]
That seems kind of crazy to me. It's generating an HTTP 200 just to tell
us the credentials are wrong. Which kind of makes sense; it's the only
way to convince the git client to show a custom message when it aborts
(rather than producing its own client-side "authorization failed"
message). But it takes the retry decision out of the client's hands. And
in this case, it is wrong; the failed credential is a result of curl
trying the username only, and git never even gets a chance to provide
the real credential.
Technically this did work before 986bbc0, so it could be considered a
regression in git, but I really think that Google Code is in the wrong
here. It should either:
1. Always return a 401 for bad credentials. This means it would lose
the custom message. But I think that is a good indication that the
client should be putting more effort into showing the body of the
401. Probably not all the time, as we do not want to spew HTML at
the user, but we could perhaps relay error bodies if the
content-type is "application/x-git-error" or something.
The downside is that even if we make such a client change and the
the Google Code server change sit's behavior, people on older git
clients will lose the benefit of the message.
2. Treat a credential with a non-empty username and an empty password
specially, and return a 401. This covers the specific case of
https://user@host/, but continues to show the custom message when
the user provides a wrong password. It does mean that the custom
message will not be shown if the user actually enters a blank
password at the prompt (but it will still be shown if they get
prompted for both username and password and leave both blank).
So it's a little hacky, but I think it would work OK in practice.
What do you think?
-Peff
^ permalink raw reply
* building git ; need suggestion
From: Joydeep Bakshi @ 2013-03-15 12:24 UTC (permalink / raw)
To: git
Hello list,
Greetings !!!
I'm building a git repo on a dedicated server; hence need some kind guidelines from you.
[1] the server will have different git repo with branches
[2] there will be a web-based GUI which must be flexible to show just a specific branch of a repo based on user authentication
[3] the web-based GUI should also have the flexibility to show a single repo based on the authentication
[4] the web-based GUI should have an admin account to supervise and configure all repos along with their branches
[3] there must be a control mechanism in the repo/web based GUI which have ACL on branches i.e.
some specific users should see some specific/ or just a branch and able to commit there only.
based on the above scenario could anyone suggest the best available solution ?
There are many like gitolike/github etc…. but don't know whig one has much finer granular
control/ACL/web-based GUI…
Thanks in advanced for your kind response.
^ permalink raw reply
* Re: [PATCH] status: hint the user about -uno if read_directory takes too long
From: Duy Nguyen @ 2013-03-15 12:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: tboegi, git, artagnon, robert.allan.zeh, finnag
In-Reply-To: <7vmwu6yqbd.fsf@alter.siamese.dyndns.org>
On Thu, Mar 14, 2013 at 10:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> "to speed up by stopping displaying untracked files" does not look
>>> like giving a balanced suggestion. It is increasing the risk of
>>> forgetting about newly created files the user may want to add, but
>>> the risk is not properly warned.
>>
>> How about "It took X ms to collect untracked files.\nCheck out the
>> option -u for a potential speedup"? I deliberately hide "no" so that
>> the user cannot blindly type and run it without reading document
>> first. We can give full explanation and warning there in the document.
>
> But it makes the advise much less useful to introduce more levels of
> indirections, no?
To me the message's value is the pointer to -uno that not many people
know about. And I don't want it to be too verbose as there'll be false
positives (cold cache, busy disks, low memory..), 2-3 lines should be
max. So indirections are not a concern. You want to speed up, you need
to pay some time. Anyway how do you put it to suggest -uno in
git-status with all the implications?
--
Duy
^ permalink raw reply
* Re: building git ; need suggestion
From: Fredrik Gustafsson @ 2013-03-15 12:44 UTC (permalink / raw)
To: Joydeep Bakshi; +Cc: git
In-Reply-To: <868B103B-690E-477B-BF75-8F954F893E6F@infoservices.in>
On Fri, Mar 15, 2013 at 05:54:05PM +0530, Joydeep Bakshi wrote:
> [1] the server will have different git repo with branches
> [2] there will be a web-based GUI which must be flexible to show just a specific branch of a repo based on user authentication
> [3] the web-based GUI should also have the flexibility to show a single repo based on the authentication
> [4] the web-based GUI should have an admin account to supervise and configure all repos along with their branches
> [3] there must be a control mechanism in the repo/web based GUI which have ACL on branches i.e.
> some specific users should see some specific/ or just a branch and able to commit there only.
>
> based on the above scenario could anyone suggest the best available solution ?
> There are many like gitolike/github etc…. but don't know whig one has much finer granular
> control/ACL/web-based GUI…
gitolite have a more fine ACL. Check it out. However it doesn't really
meet your needs with web-interface (and I'm not even sure about the ACL
thing is fine enough for you). You can read more about ACL in the git
book: http://git-scm.com/book/ch7-4.html
The webgui that's most populair is cgit and git-web. They don't do ACL
afaik.
Why would you need ACL? Why not don't share the branches that are going
to be secret? Or are you looking for some branches to be read only?
When we did this, we did a simple gitolite implementation ourself and
integrated cgit on our website wich already had ACL. It works well.
Howerver we do ACL on repo-level, not on branch level.
You can also look into git-submodules which will make it possible for
you to do repo-wide ACL.
However I'm not sure you will be using git in the way git is designed
too and even if it will work, maybe an other solution is better for you.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iveqy@iveqy.com
^ permalink raw reply
* Re: building git ; need suggestion
From: Joydeep Bakshi @ 2013-03-15 12:43 UTC (permalink / raw)
To: git
In-Reply-To: <868B103B-690E-477B-BF75-8F954F893E6F@infoservices.in>
forgot to mention:
------------------------
a code review system like gerrit is also helpful, but don't know if gerrit
has such fine control mechanism.
On 15-Mar-2013, at 5:54 PM, Joydeep Bakshi <joydeep.bakshi@infoservices.in> wrote:
> Hello list,
>
> Greetings !!!
>
> I'm building a git repo on a dedicated server; hence need some kind guidelines from you.
>
> [1] the server will have different git repo with branches
> [2] there will be a web-based GUI which must be flexible to show just a specific branch of a repo based on user authentication
> [3] the web-based GUI should also have the flexibility to show a single repo based on the authentication
> [4] the web-based GUI should have an admin account to supervise and configure all repos along with their branches
> [3] there must be a control mechanism in the repo/web based GUI which have ACL on branches i.e.
> some specific users should see some specific/ or just a branch and able to commit there only.
>
> based on the above scenario could anyone suggest the best available solution ?
> There are many like gitolike/github etc…. but don't know whig one has much finer granular
> control/ACL/web-based GUI…
>
> Thanks in advanced for your kind response.
>
> --
> 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: building git ; need suggestion
From: Joydeep Bakshi @ 2013-03-15 12:52 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: git
In-Reply-To: <20130315124415.GA23122@paksenarrion.iveqy.com>
On 15-Mar-2013, at 6:14 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> On Fri, Mar 15, 2013 at 05:54:05PM +0530, Joydeep Bakshi wrote:
>> [1] the server will have different git repo with branches
>> [2] there will be a web-based GUI which must be flexible to show just a specific branch of a repo based on user authentication
>> [3] the web-based GUI should also have the flexibility to show a single repo based on the authentication
>> [4] the web-based GUI should have an admin account to supervise and configure all repos along with their branches
>> [3] there must be a control mechanism in the repo/web based GUI which have ACL on branches i.e.
>> some specific users should see some specific/ or just a branch and able to commit there only.
>>
>> based on the above scenario could anyone suggest the best available solution ?
>> There are many like gitolike/github etc…. but don't know whig one has much finer granular
>> control/ACL/web-based GUI…
>
> gitolite have a more fine ACL. Check it out. However it doesn't really
> meet your needs with web-interface (and I'm not even sure about the ACL
> thing is fine enough for you). You can read more about ACL in the git
> book: http://git-scm.com/book/ch7-4.html
>
> The webgui that's most populair is cgit and git-web. They don't do ACL
> afaik.
>
> Why would you need ACL? Why not don't share the branches that are going
> to be secret? Or are you looking for some branches to be read only?
Actually the branches have to be dedicated to a group of users.
developer branch ---> developers
bug fixed branch --- > bug fixer
and specific group don't need to RW permission on other branch.
Obviously the admin must have the full permission on all these branches
and merge as per requirement.
The web-interface is required for checking the history by the users themselves
and for code review. I don't know any web interface which can show repo/branch
based on authentication. I have tried gitweb but it can handle a single repo or multiple
repo with single authentication. NO ACL
^ permalink raw reply
* Re: building git ; need suggestion
From: Magnus Bäck @ 2013-03-15 13:14 UTC (permalink / raw)
To: Joydeep Bakshi; +Cc: Fredrik Gustafsson, git
In-Reply-To: <00107242-04EB-423F-90FE-A6DCDEE7E262@infoservices.in>
On Friday, March 15, 2013 at 08:52 EDT,
Joydeep Bakshi <joydeep.bakshi@infoservices.in> wrote:
> On 15-Mar-2013, at 6:14 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
>
> > gitolite have a more fine ACL. Check it out. However it doesn't
> > really meet your needs with web-interface (and I'm not even sure
> > about the ACL thing is fine enough for you). You can read more about
> > ACL in the git book: http://git-scm.com/book/ch7-4.html
> >
> > The webgui that's most populair is cgit and git-web. They don't do
> > ACL afaik.
> >
> > Why would you need ACL? Why not don't share the branches that are
> > going to be secret? Or are you looking for some branches to be read
> > only?
>
> Actually the branches have to be dedicated to a group of users.
> developer branch ---> developers
> bug fixed branch --- > bug fixer
>
> and specific group don't need to RW permission on other branch.
> Obviously the admin must have the full permission on all these branches
> and merge as per requirement.
Right, but that's R/W permissions. Almost any piece of Git hosting
software supports restriction of pushes. Discriminating *read* access
between developers and maintenance people sounds like a disaster if it's
the same organization. Well, it sounds like a disaster even if there are
two different organizations working on development and maintenance, but
at least it's a reason.
Anyway, Gerrit supports per-branch read ACLs. As long as all changes go
through code review, perhaps Gerrit web interface works sufficiently
well as a repository viewer? Pushes that bypass code review won't show
up there.
http://gerrit-documentation.googlecode.com/svn/Documentation/2.5/access-control.html#category_read
> The web-interface is required for checking the history by the users
> themselves and for code review. I don't know any web interface which
> can show repo/branch based on authentication. I have tried gitweb but
> it can handle a single repo or multiple repo with single
> authentication. NO ACL
If you just have two levels of access you could have two separate
Gitweb sites and use Gerrit to replicate a subset of the branches
to each site. You could e.g. have gitweb-dev.example.com and
gitweb-maint.example.com and grant access to those sites accordingly.
--
Magnus Bäck
baeck@google.com
^ permalink raw reply
* Re: building git ; need suggestion
From: Konstantin Khomoutov @ 2013-03-15 13:56 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: Joydeep Bakshi, git
In-Reply-To: <20130315124415.GA23122@paksenarrion.iveqy.com>
On Fri, 15 Mar 2013 13:44:15 +0100
Fredrik Gustafsson <iveqy@iveqy.com> wrote:
[...]
> The webgui that's most populair is cgit and git-web. They don't do ACL
> afaik.
gitweb passes around branch names using a specific parameter in the
GET queries it operates on, like
http://gitweb.domain.local/?p=repo.git;a=shortlog;h=refs/heads/master
So I think it should be possible to somehow implement different
access rules in the front-end web server based on the qieries.
^ permalink raw reply
* Re: [PATCH] status: hint the user about -uno if read_directory takes too long
From: Torsten Bögershausen @ 2013-03-15 15:52 UTC (permalink / raw)
To: Duy Nguyen
Cc: Junio C Hamano, tboegi, git, artagnon, robert.allan.zeh, finnag
In-Reply-To: <CACsJy8BruzR=EGnwA5nc_aCJ5pO4FHyQKxd-9_36U48Ci_FFew@mail.gmail.com>
On 03/15/2013 01:30 PM, Duy Nguyen wrote:
> On Thu, Mar 14, 2013 at 10:05 PM, Junio C Hamano<gitster@pobox.com> wrote:
>>>> "to speed up by stopping displaying untracked files" does not look
>>>> like giving a balanced suggestion. It is increasing the risk of
>>>> forgetting about newly created files the user may want to add, but
>>>> the risk is not properly warned.
>>> How about "It took X ms to collect untracked files.\nCheck out the
>>> option -u for a potential speedup"? I deliberately hide "no" so that
>>> the user cannot blindly type and run it without reading document
>>> first. We can give full explanation and warning there in the document.
>> But it makes the advise much less useful to introduce more levels of
>> indirections, no?
> To me the message's value is the pointer to -uno that not many people
> know about. And I don't want it to be too verbose as there'll be false
> positives (cold cache, busy disks, low memory..), 2-3 lines should be
> max. So indirections are not a concern. You want to speed up, you need
> to pay some time. Anyway how do you put it to suggest -uno in
> git-status with all the implications?
I was thinking about the documentation, the best patch so far may look
like this:
What we think?
/Torsten
-- >8 --
[PATCH] git status: Document that git status -uno is faster
In some repostories users expere that "git status" command takes long time.
The command spends some time searching the file system for untracked files.
Document that searching for untracked file may take some time, and docuemnt
the option -uno better.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
Documentation/git-status.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 0412c40..fd36bbd 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -58,6 +58,13 @@ The possible options are:
The default can be changed using the status.showUntrackedFiles
configuration variable documented in linkgit:git-config[1].
++
+Note: Searching the file system for untracked files may take some time.
+git status -uno is faster than git status -uall.
+There is a trade-off around the use of -uno between safety and performance.
+The default is not to use -uno so that you will not forget to add a
file you newly created (i.e safety).
+You would pay for the safety with the cost to find such untracked files
(i.e. performance).
+
--ignore-submodules[=<when>]::
Ignore changes to submodules when looking for changes. <when> can be
either "none", "untracked", "dirty" or "all", which is the default.
--
1.8.2.rc3.16.gce432ca
^ permalink raw reply related
* Re: [PATCH] status: hint the user about -uno if read_directory takes too long
From: Ramkumar Ramachandra @ 2013-03-15 15:57 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Duy Nguyen, Junio C Hamano, git, robert.allan.zeh, finnag
In-Reply-To: <514343BA.3030405@web.de>
Torsten Bögershausen wrote:
> [PATCH] git status: Document that git status -uno is faster
Yes. I like this patch.
> In some repostories users expere that "git status" command takes long time.
> The command spends some time searching the file system for untracked files.
> Document that searching for untracked file may take some time, and docuemnt
> the option -uno better.
Please correct the typos in the commit message.
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> Documentation/git-status.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index 0412c40..fd36bbd 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -58,6 +58,13 @@ The possible options are:
> The default can be changed using the status.showUntrackedFiles
> configuration variable documented in linkgit:git-config[1].
>
> ++
> +Note: Searching the file system for untracked files may take some time.
> +git status -uno is faster than git status -uall.
> +There is a trade-off around the use of -uno between safety and performance.
> +The default is not to use -uno so that you will not forget to add a file
> you newly created (i.e safety).
> +You would pay for the safety with the cost to find such untracked files
> (i.e. performance).
Good writeup. What -uno does is already documented, so you've
explained the trade-off.
Why didn't you just wrap the paragraph to 80 columns though?
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Junio C Hamano @ 2013-03-15 15:59 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Johannes Schindelin, kusmabite, git, msysgit
In-Reply-To: <alpine.DEB.2.00.1303151054130.32216@tvnag.unkk.fr>
Daniel Stenberg <daniel@haxx.se> writes:
> (speaking from a libcurl perspective)
>
> As for how ALL vs DEFAULT will act or differ in the future, I suspect
> that we will end up having them being the same (even when we add bits)
> as we've encouraged "ALL" in the documentation like this for quite
> some time.
Thanks, then we should stick to starting from ALL like everybody
else who followed the suggestion in the documentation. Do you have
recommendations on the conditional dropping of SSL?
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Daniel Stenberg @ 2013-03-15 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, kusmabite, git, msysgit
In-Reply-To: <7v4ngcwt4w.fsf@alter.siamese.dyndns.org>
On Fri, 15 Mar 2013, Junio C Hamano wrote:
>> As for how ALL vs DEFAULT will act or differ in the future, I suspect that
>> we will end up having them being the same (even when we add bits) as we've
>> encouraged "ALL" in the documentation like this for quite some time.
>
> Thanks, then we should stick to starting from ALL like everybody else who
> followed the suggestion in the documentation. Do you have recommendations
> on the conditional dropping of SSL?
Not really, no.
SSL initing is as has been mentioned alredy only relevant with libcurl if an
SSL powered protocol is gonna be used, so if checking the URL for the protocol
is enough to figure this out then sure that should work fine.
--
/ daniel.haxx.se
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline
From: Pete Wyckoff @ 2013-03-15 16:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Karsten Blees, Duy Nguyen, Ramkumar Ramachandra, Git List,
Torsten Bögershausen, Robert Zeh, Jeff King, Erik Faye-Lund,
Drew Northup
In-Reply-To: <7vtxof146d.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Wed, 13 Mar 2013 12:38 -0700:
> Karsten Blees <karsten.blees@gmail.com> writes:
>
> > However, AFAIK inotify doesn't work recursively, so the daemon
> > would at least have to track the directory structure to be able to
> > register / unregister inotify handlers as directories come and go.
>
> Yes, and you would need one inotify per directory but you do not
> have an infinite supply of outstanding inotify watch (wasn't the
> limit like 8k per a single uid or something?), so the daemon must be
> prepared to say "I'll watch this, that and that directories, but the
> consumers should check other directories themselves."
fanotify is an option here too; it can watch an entire file
system.
-- Pete
^ permalink raw reply
* Re: Tag peeling peculiarities
From: Junio C Hamano @ 2013-03-15 16:28 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jeff King, git discussion list
In-Reply-To: <5142ADAA.6050503@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> What is stored in ref_value.peeled? Is it the peeled version of
> ref_value.sha1, or is it the peeled version of the associated refname?
> Because they are not necessarily the same thing: an entry in the packed
> ref_cache *might* be overridden by a loose reference with the same
> refname but a different SHA1 which peels to a different value.
The way it should work is that we look for loose ones first and then
only if we do not find a loose one we use packed one, when asked for
a ref by name. The .sha1 and .peeled fields for a single ref_entry
struct must be consistent with each other, even though you might
have got a ref_value by reading the packed-refs file and another
ref_value by reading loose one and have both in core. When you have
both packed and loose, the former should not be used at all, and it
certainly should not be pointed by current_ref.
Stepping back a bit, I suspect that it may be worth evaluating to
see if it still makes sense to keep the current_ref optimization
that was introduced in 0ae91be0e1fa (Optimize peel_ref for the
current ref of a for_each_ref callback, 2008-02-24). Back then, it
was fairly expensive to find a cached_ref entry by name, because it
was implemented as two linked lists (one for loose, one for packed)
and we would have had to traverse them to answer the question.
Since then, e9c4c11165e4 (refs: Use binary search to lookup refs
faster, 2011-09-29) introduced ref_array to make it more efficient
to find a ref_entry by name, and your more recent series that
includes bc5fd6d3c29f (refs.c: reorder definitions more logically,
2012-04-10) further touched that codepath for enumeration in a
subtree.
I am not sure if that last change helped or hurt the performance of
a single ref lookup, but we can certainly say that the performance
characteristics of read_ref_full() is very different in today's code
and the current_ref optimization may no longer be of much value.
^ permalink raw reply
* Re: [PATCH] status: hint the user about -uno if read_directory takes too long
From: Junio C Hamano @ 2013-03-15 16:53 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Duy Nguyen, git, artagnon, robert.allan.zeh, finnag
In-Reply-To: <514343BA.3030405@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> [PATCH] git status: Document that git status -uno is faster
>
> In some repostories users expere that "git status" command takes long time.
expere??? Certainly you did not mean "expect". "observe",
"experience", or "see", perhaps?
> The command spends some time searching the file system for untracked files.
> Document that searching for untracked file may take some time, and docuemnt
> the option -uno better.
Good intentions.
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> Documentation/git-status.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index 0412c40..fd36bbd 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -58,6 +58,13 @@ The possible options are:
> The default can be changed using the status.showUntrackedFiles
> configuration variable documented in linkgit:git-config[1].
>
> ++
> +Note: Searching the file system for untracked files may take some time.
> +git status -uno is faster than git status -uall.
> +There is a trade-off around the use of -uno between safety and performance.
> +The default is not to use -uno so that you will not forget to add a
> file you newly created (i.e safety).
> +You would pay for the safety with the cost to find such untracked
> files (i.e. performance).
> +
The second sentence looks out of flow, and the last sentence, while
technically not incorrect, is unclear what it is trying to convey in
the larger picture.
Perhaps it is just me.
In any case, I think it is a good idea to explain the reason why the
user might want to use a non-default setting, and the criteria the
user may want to base the choice on (which is the gist of your
addition), and it is a good idea to do so _before_ saying "The
default can be changed using ...".
How about this?
Documentation/git-status.txt | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 0412c40..9046df9 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -46,15 +46,21 @@ OPTIONS
Show untracked files.
+
The mode parameter is optional (defaults to 'all'), and is used to
-specify the handling of untracked files; when -u is not used, the
-default is 'normal', i.e. show untracked files and directories.
+specify the handling of untracked files.
+
The possible options are:
+
- - 'no' - Show no untracked files
- - 'normal' - Shows untracked files and directories
+ - 'no' - Show no untracked files.
+ - 'normal' - Shows untracked files and directories.
- 'all' - Also shows individual files in untracked directories.
+
+When `-u` option is not used, untracked files and directories are
+shown (i.e. the same as specifying `normal`), to help you avoid
+forgetting to add newly created files. Because it takes extra work
+to find untracked files in the filesystem, this mode may take some
+time in a large working tree. You can use `no` to have `git status`
+return more quickly without showing untracked files.
++
The default can be changed using the status.showUntrackedFiles
configuration variable documented in linkgit:git-config[1].
^ permalink raw reply related
* Re: SSH version on Git 1.8.1.2 for Windows is outdated.
From: Konstantin Khomoutov @ 2013-03-15 17:03 UTC (permalink / raw)
To: Kristof Mattei; +Cc: git
In-Reply-To: <CAJ5Q6vXTyaegQq2uMoK7QQVYiYS9GcJhCefkQs9tXxqU=M10Vg@mail.gmail.com>
On Fri, 15 Mar 2013 11:05:11 +0100
Kristof Mattei <kristof@kristofmattei.be> wrote:
> We're having issues with the version of SSH included in git version
> 1.8.1.msysgit.1 (Git-1.8.1.2-preview20130201.exe)
>
> The included version of SSH is from 2007:
>
> C:\Program Files (x86)\Git\bin - Old>ssh -V
> OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
>
> Updating the OpenSSH component (downloaded with Cygwin, cumbersome!!!)
> resolves the issue:
>
> C:\Program Files (x86)\Git\bin>ssh -V
> OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013
>
> Is there any way you can incorporate this update in the installer?
Yes, you should grab the msysGit (the Git for Windows build
environment) [2], tweak it to include the new OpenSSH binary, ensure it
builds and works OK and then send a pull request (or post your patchset
to the msysgit mailing list [3].
A sort of crash course on how to get started is [1].
The main page for the msysGit/Git for Windows development is [4].
Note that there should be no Cygwin involved, of course.
Git for Windows is built completely from the sources of all the
components it includes, using MinGW/MSYS so no component of Git for
Windows depends on the Cygwin runtime DLL.
1. https://github.com/msysgit/msysgit/issues/102#issuecomment-13572331
2. http://github.com/msysgit/msysgit
3. http://groups.google.com/group/msysgit
4. http://msysgit.github.com/
^ permalink raw reply
* Re: building git ; need suggestion
From: Paul Campbell @ 2013-03-15 17:25 UTC (permalink / raw)
To: Joydeep Bakshi; +Cc: Fredrik Gustafsson, git
In-Reply-To: <00107242-04EB-423F-90FE-A6DCDEE7E262@infoservices.in>
On Fri, Mar 15, 2013 at 12:52 PM, Joydeep Bakshi
<joydeep.bakshi@infoservices.in> wrote:
>
> On 15-Mar-2013, at 6:14 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
>
>> On Fri, Mar 15, 2013 at 05:54:05PM +0530, Joydeep Bakshi wrote:
>>> [1] the server will have different git repo with branches
>>> [2] there will be a web-based GUI which must be flexible to show just a specific branch of a repo based on user authentication
>>> [3] the web-based GUI should also have the flexibility to show a single repo based on the authentication
>>> [4] the web-based GUI should have an admin account to supervise and configure all repos along with their branches
>>> [3] there must be a control mechanism in the repo/web based GUI which have ACL on branches i.e.
>>> some specific users should see some specific/ or just a branch and able to commit there only.
>>>
>>> based on the above scenario could anyone suggest the best available solution ?
>>> There are many like gitolike/github etc…. but don't know whig one has much finer granular
>>> control/ACL/web-based GUI…
>>
>> gitolite have a more fine ACL. Check it out. However it doesn't really
>> meet your needs with web-interface (and I'm not even sure about the ACL
>> thing is fine enough for you). You can read more about ACL in the git
>> book: http://git-scm.com/book/ch7-4.html
>>
>> The webgui that's most populair is cgit and git-web. They don't do ACL
>> afaik.
>>
>> Why would you need ACL? Why not don't share the branches that are going
>> to be secret? Or are you looking for some branches to be read only?
>
> Actually the branches have to be dedicated to a group of users.
> developer branch ---> developers
> bug fixed branch --- > bug fixer
>
> and specific group don't need to RW permission on other branch.
> Obviously the admin must have the full permission on all these branches
> and merge as per requirement.
>
> The web-interface is required for checking the history by the users themselves
> and for code review. I don't know any web interface which can show repo/branch
> based on authentication. I have tried gitweb but it can handle a single repo or multiple
> repo with single authentication. NO ACL
I think you would need to have a separate repo for each group. Then
only push the appropriate branches to each repo.
--
Paul [W] Campbell
^ permalink raw reply
* Re: [PATCH] status: hint the user about -uno if read_directory takes too long
From: Torsten Bögershausen @ 2013-03-15 17:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Torsten Bögershausen, Duy Nguyen, git, artagnon,
robert.allan.zeh, finnag
In-Reply-To: <7vvc8svc2r.fsf@alter.siamese.dyndns.org>
On 03/15/2013 05:53 PM, Junio C Hamano wrote:
> Torsten Bögershausen<tboegi@web.de> writes:
>
>> [PATCH] git status: Document that git status -uno is faster
>>
>> In some repostories users expere that "git status" command takes long time.
> expere??? Certainly you did not mean "expect". "observe",
> "experience", or "see", perhaps?
>
>> The command spends some time searching the file system for untracked files.
>> Document that searching for untracked file may take some time, and docuemnt
>> the option -uno better.
> Good intentions.
>
>> Signed-off-by: Torsten Bögershausen<tboegi@web.de>
>> ---
>> Documentation/git-status.txt | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
>> index 0412c40..fd36bbd 100644
>> --- a/Documentation/git-status.txt
>> +++ b/Documentation/git-status.txt
>> @@ -58,6 +58,13 @@ The possible options are:
>> The default can be changed using the status.showUntrackedFiles
>> configuration variable documented in linkgit:git-config[1].
>>
>> ++
>> +Note: Searching the file system for untracked files may take some time.
>> +git status -uno is faster than git status -uall.
>> +There is a trade-off around the use of -uno between safety and performance.
>> +The default is not to use -uno so that you will not forget to add a
>> file you newly created (i.e safety).
>> +You would pay for the safety with the cost to find such untracked
>> files (i.e. performance).
>> +
> The second sentence looks out of flow, and the last sentence, while
> technically not incorrect, is unclear what it is trying to convey in
> the larger picture.
>
> Perhaps it is just me.
>
> In any case, I think it is a good idea to explain the reason why the
> user might want to use a non-default setting, and the criteria the
> user may want to base the choice on (which is the gist of your
> addition), and it is a good idea to do so _before_ saying "The
> default can be changed using ...".
>
> How about this?
>
> Documentation/git-status.txt | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index 0412c40..9046df9 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -46,15 +46,21 @@ OPTIONS
> Show untracked files.
> +
> The mode parameter is optional (defaults to 'all'), and is used to
> -specify the handling of untracked files; when -u is not used, the
> -default is 'normal', i.e. show untracked files and directories.
> +specify the handling of untracked files.
> +
> The possible options are:
> +
> - - 'no' - Show no untracked files
> - - 'normal' - Shows untracked files and directories
> + - 'no' - Show no untracked files.
> + - 'normal' - Shows untracked files and directories.
> - 'all' - Also shows individual files in untracked directories.
> +
> +When `-u` option is not used, untracked files and directories are
> +shown (i.e. the same as specifying `normal`), to help you avoid
> +forgetting to add newly created files. Because it takes extra work
> +to find untracked files in the filesystem, this mode may take some
> +time in a large working tree. You can use `no` to have `git status`
(Small nit: extra space before the "You" in the line above)
Thanks, I like that much better than mine
(and expere is probably a word not yet invented)
/Torsten
^ permalink raw reply
* Re: [PATCH v1 00/45] nd/parse-pathspec and :(glob) pathspec magic
From: Junio C Hamano @ 2013-03-15 17:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1363327620-29017-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Probably not much to say. A big portion of this series is the
> conversion to struct pathspec, which enables more use of pathspec
> magic. :(glob) magic is added to verify that the conversion makes
> sense.
I haven't read any of these patches, but there remains only one user
of the _raw field in dir.c (read_directory) and get_pathspec() is
called by nobody other than builtin/mv.c after this series.
Very encouraging.
> Andrew Wong (1):
> setup.c: check that the pathspec magic ends with ")"
>
> Nguyễn Thái Ngọc Duy (44):
> clean: remove unused variable "seen"
> Move struct pathspec and related functions to pathspec.[ch]
> pathspec: i18n-ize error strings in pathspec parsing code
> pathspec: add copy_pathspec
> Add parse_pathspec() that converts cmdline args to struct pathspec
> parse_pathspec: save original pathspec for reporting
> parse_pathspec: add PATHSPEC_PREFER_{CWD,FULL}
> Convert some get_pathspec() calls to parse_pathspec()
> parse_pathspec: a special flag for max_depth feature
> parse_pathspec: support stripping submodule trailing slashes
> parse_pathspec: support stripping/checking submodule paths
> parse_pathspec: support prefixing original patterns
> Guard against new pathspec magic in pathspec matching code
> clean: convert to use parse_pathspec
> commit: convert to use parse_pathspec
> status: convert to use parse_pathspec
> rerere: convert to use parse_pathspec
> checkout: convert to use parse_pathspec
> rm: convert to use parse_pathspec
> ls-files: convert to use parse_pathspec
> archive: convert to use parse_pathspec
> check-ignore: convert to use parse_pathspec
> add: convert to use parse_pathspec
> reset: convert to use parse_pathspec
> Convert read_cache_preload() to take struct pathspec
> Convert run_add_interactive to use struct pathspec
> Convert unmerge_cache to take struct pathspec
> checkout: convert read_tree_some to take struct pathspec
> Convert report_path_error to take struct pathspec
> Convert refresh_index to take struct pathspec
> Convert {read,fill}_directory to take struct pathspec
> Convert add_files_to_cache to take struct pathspec
> Convert common_prefix() to use struct pathspec
> Remove diff_tree_{setup,release}_paths
> Remove init_pathspec() in favor of parse_pathspec()
> Remove match_pathspec() in favor of match_pathspec_depth()
> tree-diff: remove the use of pathspec's raw[] in follow-rename codepath
> parse_pathspec: make sure the prefix part is wildcard-free
> parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN
> Kill limit_pathspec_to_literal() as it's only used by parse_pathspec()
> pathspec: support :(literal) syntax for noglob pathspec
> pathspec: make --literal-pathspecs disable pathspec magic
> pathspec: support :(glob) syntax
> Rename field "raw" to "_raw" in struct pathspec
>
> Documentation/git.txt | 23 +-
> Documentation/glossary-content.txt | 33 +++
> archive.c | 18 +-
> archive.h | 4 +-
> builtin/add.c | 156 ++++++--------
> builtin/blame.c | 14 +-
> builtin/check-ignore.c | 34 +--
> builtin/checkout.c | 46 ++--
> builtin/clean.c | 24 +--
> builtin/commit.c | 37 ++--
> builtin/diff-files.c | 2 +-
> builtin/diff-index.c | 2 +-
> builtin/diff.c | 6 +-
> builtin/grep.c | 10 +-
> builtin/log.c | 2 +-
> builtin/ls-files.c | 75 +++----
> builtin/ls-tree.c | 13 +-
> builtin/mv.c | 13 +-
> builtin/rerere.c | 8 +-
> builtin/reset.c | 33 +--
> builtin/rm.c | 24 +--
> builtin/update-index.c | 6 +-
> cache.h | 34 +--
> commit.h | 2 +-
> diff-lib.c | 3 +-
> diff.h | 3 +-
> dir.c | 261 +++++-----------------
> dir.h | 18 +-
> git.c | 8 +
> merge-recursive.c | 2 +-
> notes-merge.c | 4 +-
> path.c | 15 +-
> pathspec.c | 431 +++++++++++++++++++++++++++++++++----
> pathspec.h | 59 ++++-
> preload-index.c | 21 +-
> read-cache.c | 5 +-
> rerere.c | 7 +-
> rerere.h | 4 +-
> resolve-undo.c | 4 +-
> resolve-undo.h | 2 +-
> revision.c | 11 +-
> setup.c | 157 +-------------
> t/t0008-ignores.sh | 8 +-
> t/t6130-pathspec-noglob.sh | 18 ++
> tree-diff.c | 48 +++--
> tree-walk.c | 21 +-
> tree.c | 4 +-
> tree.h | 2 +-
> wt-status.c | 18 +-
> wt-status.h | 2 +-
> 50 files changed, 983 insertions(+), 772 deletions(-)
^ 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