[RFC/PATCH] commit/status: show the index-worktree with -v -v
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in addition to HEAD index diff. This allows to review unstaged
changes which might be missing from the commit.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Also, the git status man page does not mention -v at all, and the doc
for git status (long format) and the status parts of the git commit
man page should really be the same.
In any case, this may have helped the OP with his amend oversight.
Documentation/git-commit.txt | 4
wt-status.c | 8
2 files changed, 12 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
would be committed at the bottom of the commit message
template. Note that this diff output doesn't have its
lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
-q::
--quiet::
diff --git a/wt-status.c b/wt-status.c
index b54eac5..75674c2 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -874,6 +874,14 @@ static void wt_status_print_verbose(struct wt_status *s)
wt_status_add_cut_line(s-fp);
}
run_diff_index(rev, 1);
+ if (s-verbose 1) {
+ setup_work_tree();
+ if (read_cache_preload(rev.diffopt.pathspec) 0)
+ perror(read_cache_preload);
+ rev.diffopt.a_prefix = 0; /* allow run_diff_files */
+ rev.diffopt.b_prefix = 0; /* to reset the prefixes */
+ run_diff_files(rev, 0);
+ }
}
static void wt_status_print_tracking(struct wt_status *s)
--
2.3.0.rc0.202.g6f441c7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/init-db.txt: minor style and synopsys fixes
On Thu, Jan 15, 2015 at 5:31 AM, Alexander Kuleshov kuleshovm...@gmail.com wrote: Subject: Documentation/init-db.txt: minor style and synopsys fixes Subject is incorrect now that you're modifying git-init-db.txt and git-init.txt. This patch constists of two minor changes: * line-wrap 'git init-db' synopsis * last possible argument '[directory]' was missed Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-init-db.txt | 5 +++-- Documentation/git-init.txt| 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index 648a6cd..2c77aaa 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -9,8 +9,9 @@ git-init-db - Creates an empty Git repository SYNOPSIS [verse] -'git init-db' [-q | --quiet] [--bare] [--template=template_directory] [--separate-git-dir git dir] [--shared[=permissions]] - +'git init-db' [-q | --quiet] [--bare] [--template=template_directory] +[--separate-git-dir git-dir] +[--shared[=permissions]] [directory] DESCRIPTION --- diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 369f889..25412ac 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -10,8 +10,8 @@ SYNOPSIS [verse] 'git init' [-q | --quiet] [--bare] [--template=template_directory] - [--separate-git-dir git dir] - [--shared[=permissions]] [directory] + [--separate-git-dir git-dir] + [--shared[=permissions]] [directory] DESCRIPTION @@ -108,7 +108,7 @@ By default, the configuration flag `receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you provide a 'directory', the command is run inside it. If this directory +If you provide a directory, the command is run inside it. If this directory does not exist, it will be created. -- -- 2.3.0.rc0.314.g170a664.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/init-db.txt: minor style and synopsys fixes
Yes, right, how to do it better? Something like: Documentation, init-db/init:.? Or something else? Thank you 2015-01-15 22:50 GMT+06:00 Eric Sunshine sunsh...@sunshineco.com: On Thu, Jan 15, 2015 at 5:31 AM, Alexander Kuleshov kuleshovm...@gmail.com wrote: Subject: Documentation/init-db.txt: minor style and synopsys fixes Subject is incorrect now that you're modifying git-init-db.txt and git-init.txt. This patch constists of two minor changes: * line-wrap 'git init-db' synopsis * last possible argument '[directory]' was missed Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-init-db.txt | 5 +++-- Documentation/git-init.txt| 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index 648a6cd..2c77aaa 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -9,8 +9,9 @@ git-init-db - Creates an empty Git repository SYNOPSIS [verse] -'git init-db' [-q | --quiet] [--bare] [--template=template_directory] [--separate-git-dir git dir] [--shared[=permissions]] - +'git init-db' [-q | --quiet] [--bare] [--template=template_directory] +[--separate-git-dir git-dir] +[--shared[=permissions]] [directory] DESCRIPTION --- diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 369f889..25412ac 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -10,8 +10,8 @@ SYNOPSIS [verse] 'git init' [-q | --quiet] [--bare] [--template=template_directory] - [--separate-git-dir git dir] - [--shared[=permissions]] [directory] + [--separate-git-dir git-dir] + [--shared[=permissions]] [directory] DESCRIPTION @@ -108,7 +108,7 @@ By default, the configuration flag `receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you provide a 'directory', the command is run inside it. If this directory +If you provide a directory, the command is run inside it. If this directory does not exist, it will be created. -- -- 2.3.0.rc0.314.g170a664.dirty -- _ 0xAX -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] stash: added short option '-p' to git stash usage synopsis
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- git-stash.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-stash.sh b/git-stash.sh index 6e30380..dc101f9 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -7,7 +7,7 @@ USAGE=list [options] or: $dashless drop [-q|--quiet] [stash] or: $dashless ( pop | apply ) [--index] [-q|--quiet] [stash] or: $dashless branch branchname [stash] - or: $dashless [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] + or: $dashless [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [message]] or: $dashless clear or: $dashless create [message] -- 2.3.0.rc0.315.g0e14eda -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] string-list: remove print_string_list from string-list's API
print_string_list routine has no callers anywhere.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
Documentation/technical/api-string-list.txt | 6 --
string-list.c | 10 --
string-list.h | 1 -
3 files changed, 17 deletions(-)
diff --git a/Documentation/technical/api-string-list.txt
b/Documentation/technical/api-string-list.txt
index c08402b..99e12e9 100644
--- a/Documentation/technical/api-string-list.txt
+++ b/Documentation/technical/api-string-list.txt
@@ -87,12 +87,6 @@ Functions
call free() on the util members of any items that have to be
deleted. Preserve the order of the items that are retained.
-`print_string_list`::
-
- Dump a string_list to stdout, useful mainly for debugging purposes. It
- can take an optional header argument and it writes out the
- string-pointer pairs of the string_list, each one in its own line.
-
`string_list_clear`::
Free a string_list. The `string` pointer of the items will be freed in
diff --git a/string-list.c b/string-list.c
index 2a32a3f..ba832da 100644
--- a/string-list.c
+++ b/string-list.c
@@ -182,16 +182,6 @@ void string_list_clear_func(struct string_list *list,
string_list_clear_func_t c
list-nr = list-alloc = 0;
}
-
-void print_string_list(const struct string_list *p, const char *text)
-{
- int i;
- if ( text )
- printf(%s\n, text);
- for (i = 0; i p-nr; i++)
- printf(%s:%p\n, p-items[i].string, p-items[i].util);
-}
-
struct string_list_item *string_list_append_nodup(struct string_list *list,
char *string)
{
diff --git a/string-list.h b/string-list.h
index d3809a1..c417bd5 100644
--- a/string-list.h
+++ b/string-list.h
@@ -20,7 +20,6 @@ struct string_list {
void string_list_init(struct string_list *list, int strdup_strings);
-void print_string_list(const struct string_list *p, const char *text);
void string_list_clear(struct string_list *list, int free_util);
/* Use this function to call a custom clear function on each util pointer */
--
2.3.0.rc0.315.g0e14eda
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] mark private symbols static
Jeff King p...@peff.net writes: On Wed, Jan 14, 2015 at 03:40:45PM -0800, Junio C Hamano wrote: Here are a handful of patches to make symbols that are only used within a .c file as static. This is not the kind of changes we would want to do in the pre-release freeze period, and it is just for reference. I may later come back to them after 2.3 final is tagged. I commented specifically on the ones that are in areas I touch a lot, but all of them look fine to me. Thanks for reviews. The primary reason I sent out this series was to show the reasoning in 00/10 to decide what *not* to touch, by the way, to send a signal to those who may want to throw unnecessary churn at the codebase, by the way ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cosmetic bug: git show --pretty:format produces different output than git show --format
Michael J Gruber g...@drmicha.warpmail.net writes: Unfortunately, --format seems to be parsed as (--pretty and therefore?) --pretty=tformat: which I consider a bug. tformat: was introduced to fix format:, because many people found the latter hard to use, probably because most of the time they wanted to use the feature to show one-line-per-commit and a LF after each record (terminator semantics where 't' in tformat: comes from) made more sense in that context, compared to a LF between each record (delimiter semantics). Of course, format: that uses the delimiter semantics has its uses; after all, the delimiter semantics is what is used for canned formats, other than --oneline. It was a deliberate design decision to make --format=string as a short-hand for --pretty=tformat:string, favouring tformat: over format:, AFAIK. To use the facility to show a break between each (likely multi-line) record, use --pretty=format:string, not --pretty=tformat:string aka --format=string. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] string-list: remove print_string_list from string-list's API
Maybe need to add comments for print_string_list, for preventing patches like this? 2015-01-15 23:56 GMT+06:00 Junio C Hamano gits...@pobox.com: On Thu, Jan 15, 2015 at 9:42 AM, Alexander Kuleshov kuleshovm...@gmail.com wrote: print_string_list routine has no callers anywhere. Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com http://thread.gmane.org/gmane.comp.version-control.git/262439 -- _ 0xAX -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/init-db.txt: minor style and synopsys fixes
Alexander Kuleshov kuleshovm...@gmail.com writes: Yes, right, how to do it better? Something like: Documentation, init-db/init:.? Or something else? Subject: init-db documentation: fix synopsis style +'git init-db' [-q | --quiet] [--bare] [--template=template_directory] s/_/-/ while we are at it, perhaps? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/init-db.txt: minor style and synopsys fixes
On Thu, Jan 15, 2015 at 12:08 PM, Alexander Kuleshov kuleshovm...@gmail.com wrote: Yes, right, Etiquette on this list is to avoid top-posting [1]. how to do it better? Something like: Documentation, init-db/init:.? Or something else? Simplest would be to split it into two patches: one for git-init-db.txt and one for git-init.txt. Also... On Thu, Jan 15, 2015 at 5:31 AM, Alexander Kuleshov kuleshovm...@gmail.com wrote: Subject: Documentation/init-db.txt: minor style and synopsys fixes This patch constists of two minor changes: * line-wrap 'git init-db' synopsis * last possible argument '[directory]' was missed Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- +'git init-db' [-q | --quiet] [--bare] [--template=template_directory] +[--separate-git-dir git-dir] +[--shared[=permissions]] [directory] Taking Alex's review[2] into consideration: s/template_directory/template-directory/ [1]: https://lkml.org/lkml/2005/1/11/111 [2]: http://article.gmane.org/gmane.comp.version-control.git/262427 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Documentation/git-init-db.txt: minor style fixes
* line-wrap 'git init-db' synopsis * last possible argument '[directory]' was missed Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-init-db.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index 648a6cd..b66da6d 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -9,7 +9,9 @@ git-init-db - Creates an empty Git repository SYNOPSIS [verse] -'git init-db' [-q | --quiet] [--bare] [--template=template_directory] [--separate-git-dir git dir] [--shared[=permissions]] +'git init-db' [-q | --quiet] [--bare] [--template=template-directory] +[--separate-git-dir git-dir] +[--shared[=permissions]] [directory] DESCRIPTION -- 2.3.0.rc0.315.g0e14eda -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Documentation/git-init.txt: minor style and synopsis fixes
Signed-off-by: 0xAX kuleshovm...@gmail.com --- Documentation/git-init.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 369f889..f1f0599 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -9,9 +9,9 @@ git-init - Create an empty Git repository or reinitialize an existing one SYNOPSIS [verse] -'git init' [-q | --quiet] [--bare] [--template=template_directory] - [--separate-git-dir git dir] - [--shared[=permissions]] [directory] +'git init' [-q | --quiet] [--bare] [--template=template-directory] + [--separate-git-dir git-dir] + [--shared[=permissions]] [directory] DESCRIPTION @@ -50,12 +50,12 @@ Only print error and warning messages; all other output will be suppressed. Create a bare repository. If GIT_DIR environment is not set, it is set to the current working directory. ---template=template_directory:: +--template=template-directory:: Specify the directory from which templates will be used. (See the TEMPLATE DIRECTORY section below.) ---separate-git-dir=git dir:: +--separate-git-dir=git-dir:: Instead of initializing the repository as a directory to either `$GIT_DIR` or `./.git/`, create a text file there containing the path to the actual @@ -108,7 +108,7 @@ By default, the configuration flag `receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you provide a 'directory', the command is run inside it. If this directory +If you provide a directory, the command is run inside it. If this directory does not exist, it will be created. -- -- 2.3.0.rc0.315.g0e14eda -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: reword --author error message
Michael J Gruber g...@drmicha.warpmail.net writes: If an --author argument is specified but does not contain a '' then git tries to find the argument within the exiting authors; and gives the error message No existing author found with '%s' if there is no match. This is confusing for users who try to specify a valid complete author name. I suspect that you meant s/a valid/an invalid/, as if it is valid, it cannot not contain '' (after all, '' is merely a rough approximation to check if it is Name email format). Rename the error message to make it clearer that the failure has two reasons in this case: Bad --author parameter '%s': neither completely wellformed nor part of an existing one You are trying to help a user who thought Who www.where.com was a valid thing to pass to --author; it is not completely wellformed is not very helpful without making her realize what in that bogus string is not completely well-formed. Perhaps --author '%s' is not 'Name email' and no existing author matches that string or somesuch? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unused #include statements
Jeff King p...@peff.net writes: One of our rules is that git-compat-util.h (or one of the well-known headers which includes, cache.h or builtin.h) is included first in any translation unit. Perhaps by now we can spell it out a bit more explicitly and update CodingGuidelines. We have: - The first #include in C files, except in platform specific compat/ implementations, should be git-compat-util.h or another header file that includes it, such as cache.h or builtin.h. such as might be making things unnecessarily vague; I do not think a valid reason why we should say a .c file that includes advice.h as the first thing satisfies this requirement, for example. Because: - A command that interacts with the object store, config subsystem, the index, or the working tree cannot do anything without using what is declared in cache.h. - A built-in command must be declared in builtin.h, so anything in builtin/*.c must include it. it may be reasonable to say the first *.h file included must be one of git-compat-util.h, cache.h or builtin.h (and then we make sure that compat-util is the first thing included in either of the latter two). While I very much agree with the principle Robert alluded to [*1*], we may want to loosen that for .c files that include builtin.h or cache.h for the sake of brevity. For example, if you are builtin (hence you start by #include builtin.h), it may be reasonable to allow you to take whatever is in cache.h for granted [*2*]. So the rule might be: - The first #include in C files, except in platform specific compat/ implementations, must be either git-compat-util.h, cache.h or builtin.h. - A C file must directly include the header files that declare the functions and the types it uses, except for the functions and types that are made available to it by including one of the header files it must include by the previous rule. Optionally, - A C file must include only one of git-compat-util.h, cache.h or builtin.h; e.g. if you include builtin.h, do not include the other two, but it can consider what is availble in cache.h available to it. Thoughts? I am not looking forward to a torrent of patches whose sole purpose is to make the existing C files conform to any such rule, though. Clean-up patches that trickle in at a low rate is tolerable, but a torrent is too distracting. [Footnote] *1* For example, even though diff.h may include tree-walk.h for its own use, a .c file that includes diff.h without including tree-walk.h that uses update_tree_entry() or anything that is declared in the latter is very iffy from semantic point of view. *2* Because that facility is so widely used inside the codebase, builtin.h includes strbuf.h, so in addition to what are in cache.h, we may want to allow builtin implementations to take strbufs for granted as well. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] l10n: de.po: translate 13 new messages
Translate 13 new messages came from git.pot update in beb691f (l10n: git.pot: v2.3.0 round 1 (13 new, 11 removed)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 39 +++ 1 file changed, 15 insertions(+), 24 deletions(-) diff --git a/po/de.po b/po/de.po index 2fa5832..70ca3ff 100644 --- a/po/de.po +++ b/po/de.po @@ -3129,9 +3129,8 @@ msgid edit the description for the branch msgstr die Beschreibung für den Branch bearbeiten #: builtin/branch.c:851 -#, fuzzy msgid force creation, move/rename, deletion -msgstr Führe Erkennung für ungenaue Umbenennung aus +msgstr Erstellung, Verschiebung/Umbenennung oder Löschung erzwingen #: builtin/branch.c:854 msgid print only not merged branches @@ -4003,7 +4002,7 @@ msgstr nur einen Branch klonen, HEAD oder --branch #: builtin/clone.c:99 msgid use --reference only while cloning -msgstr +msgstr --reference nur während des Klonens benutzen #: builtin/clone.c:100 builtin/init-db.c:502 msgid gitdir @@ -4109,13 +4108,12 @@ msgid unable to checkout working tree msgstr Arbeitsverzeichnis konnte nicht ausgecheckt werden #: builtin/clone.c:746 -#, fuzzy msgid cannot repack to clean up -msgstr Kann Paketdatei %s nicht lesen +msgstr Kann \repack\ zum Aufräumen nicht aufrufen #: builtin/clone.c:748 msgid cannot unlink temporary alternates file -msgstr +msgstr Kann temporäre \alternates\-Datei nicht entfernen #: builtin/clone.c:778 msgid Too many arguments. @@ -4176,7 +4174,7 @@ msgstr Klone nach '%s'...\n #: builtin/clone.c:897 msgid --dissociate given, but there is no --reference -msgstr +msgstr --dissociate ohne --reference angegeben #: builtin/clone.c:912 msgid --depth is ignored in local clones; use file:// instead. @@ -4964,14 +4962,12 @@ msgid open an editor msgstr einen Editor öffnen #: builtin/config.c:72 -#, fuzzy msgid find the color configured: slot [default] -msgstr die konfigurierte Farbe finden: [Standard] +msgstr die konfigurierte Farbe finden: Slot [Standard] #: builtin/config.c:73 -#, fuzzy msgid find the color setting: slot [stdout-is-tty] -msgstr die Farbeinstellung finden: [Standard-Ausgabe-ist-Terminal] +msgstr die Farbeinstellung finden: Slot [Standard-Ausgabe-ist-Terminal] #: builtin/config.c:74 msgid Type @@ -5591,7 +5587,6 @@ msgid quote placeholders suitably for python msgstr Platzhalter als Python-String formatieren #: builtin/for-each-ref.c:1078 -#, fuzzy msgid quote placeholders suitably for Tcl msgstr Platzhalter als Tcl-String formatieren @@ -7618,13 +7613,12 @@ msgid git notes [--ref notes_ref] [list [object]] msgstr git notes [--ref Notiz-Referenz] [list [Objekt]] #: builtin/notes.c:25 -#, fuzzy msgid git notes [--ref notes_ref] add [-f] [--allow-empty] [-m msg | -F file | (-c | -C) object] [object] msgstr -git notes [--ref Notiz-Referenz] add [-f] [-m Nachricht | -F Datei | (- -c | -C) Objekt] [Objekt] +git notes [--ref Notiz-Referenz] add [-f] [--allow-empty] [-m Beschreibung | +-F Datei | (-c | -C) Objekt] [Objekt] #: builtin/notes.c:26 msgid git notes [--ref notes_ref] copy [-f] from-object to-object @@ -7632,18 +7626,16 @@ msgstr git notes [--ref Notiz-Referenz] copy [-f] von-Objekt nach-Objekt #: builtin/notes.c:27 -#, fuzzy msgid git notes [--ref notes_ref] append [--allow-empty] [-m msg | -F file | (-c | -C) object] [object] msgstr -git notes [--ref Notiz-Referenz] append [-m Nachricht | -F Datei | (-c -| -C) Objekt] [Objekt] +git notes [--ref Notiz-Referenz] append [--allow-empty] [-m Beschreibung | +-F Datei | (-c | -C) Objekt] [Objekt] #: builtin/notes.c:28 -#, fuzzy msgid git notes [--ref notes_ref] edit [--allow-empty] [object] -msgstr git notes [--ref Notiz-Referenz] edit [Objekt] +msgstr git notes [--ref Notiz-Referenz] edit [--allow-empty] [Objekt] #: builtin/notes.c:29 msgid git notes [--ref notes_ref] show [object] @@ -7833,7 +7825,7 @@ msgstr Wiederverwendung des angegebenen Notiz-Objektes #: builtin/notes.c:404 builtin/notes.c:567 msgid allow storing empty note -msgstr +msgstr Speichern leerer Notiz erlauben #: builtin/notes.c:405 builtin/notes.c:476 msgid replace existing notes @@ -8124,9 +8116,8 @@ msgid create thin packs msgstr dünnere Pakete erzeugen #: builtin/pack-objects.c:2682 -#, fuzzy msgid create packs suitable for shallow fetches -msgstr Platzhalter als Shell-String formatieren +msgstr Pakete geeignet für Abholung mit unvollständiger Historie (shallow) erzeugen #: builtin/pack-objects.c:2684 msgid ignore packs that have companion .keep file @@ -9846,7 +9837,7 @@ msgstr Grund für die Aktualisierung msgid git tag [-a|-s|-u key-id] [-f] [-m msg|-F file] tagname [head] msgstr -git tag [-a|-s|-u Schlüssel-id] [-f] [-m Nachricht|-F Datei] Tagname +git tag [-a|-s|-u Schlüssel-id] [-f] [-m Beschreibung|-F Datei] Tagname [Commit] #: builtin/tag.c:23 -- 2.3.0.rc0.174.g1e99f79 -- To unsubscribe from this list: send the line unsubscribe git
Re: [PULL] git-svn updates from Ramkumar
Eric Wong normalper...@yhbt.net writes: The following changes since commit 563d4e59bd167fe2eecc5480e3841d878b1c8c2b: Fifth batch for 2.3 cycle (2015-01-14 12:44:03 -0800) are available in the git repository at: git://bogomips.org/git-svn.git for-junio for you to fetch changes up to a94655dcfedc6b266ba32a3d32b0d52a1ce6a928: git-svn: make it play nicely with submodules (2015-01-15 08:35:55 +) Ramkumar Ramachandra (2): Git::SVN: handle missing ref_id case correctly git-svn: make it play nicely with submodules git-svn.perl| 6 ++ perl/Git/SVN.pm | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) Thanks. No tests necessary/feasible? Just being curious. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Advise on a push only repo
I am setting up a continous integration (CI) system for an open source project
and I want to allow forking developers to use the system, but I do not want
anyone to do a clone or fetch from the CI git repo, the repo.
Any advice on limiting the https smart protocol to push only, blocking clone
and fetch?
Looking at http-backend.c
542 static struct service_cmd {
543 const char *method;
544 const char *pattern;
545 void (*imp)(char *);
546 } services[] = {
547 {GET, /HEAD$, get_head},
548 {GET, /info/refs$, get_info_refs},
549 {GET, /objects/info/alternates$, get_text_file},
550 {GET, /objects/info/http-alternates$, get_text_file},
551 {GET, /objects/info/packs$, get_info_packs},
552 {GET, /objects/[0-9a-f]{2}/[0-9a-f]{38}$, get_loose_object},
553 {GET, /objects/pack/pack-[0-9a-f]{40}\\.pack$,
get_pack_file},
554 {GET, /objects/pack/pack-[0-9a-f]{40}\\.idx$, get_idx_file},
555
556 {POST, /git-upload-pack$, service_rpc},
557 {POST, /git-receive-pack$, service_rpc}
558 };
I feel I could just filter /git-receive-pack and /objects/ .
I am going to build my test system now.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: reword --author error message
Jeff King schrieb am 15.01.2015 um 15:31: On Thu, Jan 15, 2015 at 03:23:08PM +0100, Michael J Gruber wrote: If an --author argument is specified but does not contain a '' then git tries to find the argument within the exiting authors; and gives the error message No existing author found with '%s' if there is no match. This is confusing for users who try to specify a valid complete author name. Rename the error message to make it clearer that the failure has two reasons in this case: Bad --author parameter '%s': neither completely wellformed nor part of an existing one I really like the intent of this patch, but I actually find the new message even more confusing. The main observation is that the current error message is given only when both interpretations (complete ident, match ident) fail, and the error message conveys only one when it should do both. I don't care about the wording either. Is this a time when we could use hint() to give a multi-line explanation (and probably a matching advice.* config)? Like: hint: If the --author parameter contains angle brackets (), it hint: is treated as a literal name/email pair to use. If not, then hint: the history is searched for an existing matching author. or something? -Peff Well, this basically copies the man page paragraph for that option. I don't want to set a(nother) precedent for doing this and create yet another config knob. The alternative would be to just say Bad --author parameter '%s' (or Invalid...), as we do in most cases, and force the user to check the man page for the definition of valid. I'm beginning to prefer this minimalistic approach... Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cosmetic bug: git show --pretty:format produces different output than git show --format
Francesc Zacarias schrieb am 15.01.2015 um 14:55: Hi! I noticed that git produces differing output for git show --pretty:format show and git show --format, even though the man page says that both are equivalent. git show --format always appends an empty line at the end. The only way I've found to get rid of that empty line in --format is by adding -s option. So, git show --pretty:format and git show -s --format do produce the same output. I can reproduce this issue in Ubuntu Trusty (git version 1.9.1) and Debian Jessie (git version 2.1.4). The first part of the man page is a bit sloppy, but refers to the FORMAT section. There, it says that --pretty is equivalent to --pretty=tformat: which is different from --pretty=format:. Unfortunately, --format seems to be parsed as (--pretty and therefore?) --pretty=tformat: which I consider a bug. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cosmetic bug: git show --pretty:format produces different output than git show --format
Michael J Gruber g...@drmicha.warpmail.net writes: The first part of the man page is a bit sloppy, but refers to the FORMAT section. There, it says that --pretty is equivalent to --pretty=tformat: which is different from --pretty=format:. It is indeed sloppy. It says --(pretty|format)=format can take these canned formats or 'format:string', but - it does not say it can also take 'tformat:string' at all; and - it does not say a format that is none of the above is dwimmed with 'tformat:' prefixed. Perhaps something like this is needed. Documentation/pretty-options.txt | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt index 8569e29..7e17af9 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -3,9 +3,13 @@ Pretty-print the contents of the commit logs in a given format, where 'format' can be one of 'oneline', 'short', 'medium', - 'full', 'fuller', 'email', 'raw' and 'format:string'. See - the PRETTY FORMATS section for some additional details for each - format. When omitted, the format defaults to 'medium'. + 'full', 'fuller', 'email', 'raw', 'format:string' + and 'tformat:string'. When 'format' is none of the above, + acts as if '--pretty=tformat:format' were given. ++ +See +the PRETTY FORMATS section for some additional details for each +format. When omitted, the format defaults to 'medium'. + Note: you can specify the default pretty format in the repository configuration (see linkgit:git-config[1]). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] init-db: remove unused include
Alexander Kuleshov kuleshovm...@gmail.com writes: cache.h removed, because it's already included at builtin.h Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Let's put this on hold. $ git grep --all-match -l -e cache\\.h -e builtin\\.h -- \*.c shows us there are tons, not just this one. Also I'd like to see this discussion simmer a bit more: http://thread.gmane.org/gmane.comp.version-control.git/262454/focus=262499 builtin/init-db.c | 1 - 1 file changed, 1 deletion(-) diff --git a/builtin/init-db.c b/builtin/init-db.c index 280454a..8edef87 100644 --- a/builtin/init-db.c +++ b/builtin/init-db.c @@ -3,7 +3,6 @@ * * Copyright (C) Linus Torvalds, 2005 */ -#include cache.h #include builtin.h #include exec_cmd.h #include parse-options.h -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation/git-init.txt: minor style and synopsis fixes
Alexander Kuleshov kuleshovm...@gmail.com writes: Signed-off-by: 0xAX kuleshovm...@gmail.com H. @@ -50,12 +50,12 @@ Only print error and warning messages; all other output will be suppressed. Linewrapped? I could apply it after fixing these hunk header lines, but I'd prefer not to, as we wouldn't know where _else_ the mail transport corrupted the patch in a way that git apply would not notice. Create a bare repository. If GIT_DIR environment is not set, it is set to the current working directory. ---template=template_directory:: +--template=template-directory:: Specify the directory from which templates will be used. (See the TEMPLATE DIRECTORY section below.) ---separate-git-dir=git dir:: +--separate-git-dir=git-dir:: Instead of initializing the repository as a directory to either `$GIT_DIR` or `./.git/`, create a text file there containing the path to the actual @@ -108,7 +108,7 @@ By default, the configuration flag receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you provide a 'directory', the command is run inside it. If this directory +If you provide a directory, the command is run inside it. If this directory does not exist, it will be created. -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] commit/status: show the index-worktree with -v -v
Junio C Hamano gits...@pobox.com writes: I do not think that output order is very helpful. Two diffs to the same file next to each other may make it easier to notice, though. ... or it may want to even be like this: diff --git a/A b/A ... diff --git to-be-committed/A left-out-of-the-commit/A ... diff --git a/B b/B ... by using a custom, unusual and easy-to-notice prefixes. FWIW, with such a loud custom prefixes, I think it is OK to have all the changes to be committed first and then everything that is left out at the end. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advise on a push only repo
Jason Pyeron jpye...@pdinc.us writes:
I am setting up a continous integration (CI) system for an open source
project and I want to allow forking developers to use the system, but
I do not want anyone to do a clone or fetch from the CI git repo, the
repo.
Any advice on limiting the https smart protocol to push only, blocking clone
and fetch?
Looking at http-backend.c
542 static struct service_cmd {
...
558 };
Looking at http-backend.c
19 struct rpc_service {
20 const char *name;
21 const char *config_name;
22 signed enabled : 2;
23 };
24
25 static struct rpc_service rpc_service[] = {
26 { upload-pack, uploadpack, 1 },
27 { receive-pack, receivepack, -1 },
28 };
So it would be natural to assume that there must be a way to
enable/disable these two services, no?
Looking at http_config() there, I would guess perhaps:
[http]
uploadpack = false
getanyfile = false
but I am not sure if the latter is needed (or anybody seriously
tested it, for that matter).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] init-db: remove unused #includes
Jeff King p...@peff.net writes: FWIW, the full set of CFLAGS I use (which I specify in config.mak) is: CFLAGS += -Wall -Werror CFLAGS += -Wno-format-zero-length CFLAGS += -Wdeclaration-after-statement CFLAGS += -Wpointer-arith CFLAGS += -Wstrict-prototypes CFLAGS += -Wold-style-declaration -Peff I think I have no-pointer-to-int-cast, old-style-definition and vla in addition to the above. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Introducing different handling for small/large transactions
On Thu, Jan 15, 2015 at 02:36:11PM -0800, Stefan Beller wrote: So for here is my proposal for small transactions: (just one ref [and/or reflog] touched): The implication being that a large transaction is any with more than one update. I think performance may suffer if you do not also take into account the size of the packed-refs file. If you are updating 5 refs and there are 10 in the packed-refs file, rewriting the extra 5 is probably not a big deal. If there are 400,000 in the packed-refs file, it probably is. I'm not sure where the cutoff is (certainly the per-ref cost is less for packed-refs once you have started writing the file, so there is probably some crossover percentage that you could measure). * detect if we transition to a large transaction (by having more than one entry in transaction-updates) if so: * Pack all currently existing refs into the packed refs file, commit the packed refs file and delete all loose refs. This will avoid (d/f) conflicts. * Keep the packed-refs file locked and move the first transaction update into the packed-refs.lock file This increases lock contention, as now independent ref updates all need to take the same packed-refs.lock. This can be a problem on a busy repository, especially because we never retry the packed-refs lock. We already see this problem somewhat on GitHub. Ref deletions need the packed-refs.lock file, which can conflict with another deletion, or with running `git pack-refs`. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] git-svn updates from Ramkumar
Junio C Hamano gits...@pobox.com wrote: Thanks. No tests necessary/feasible? Just being curious. They seemed simple and obvious enough to me, (and most importantly, didn't trigger regressions). If Ramkumar or anybody else has the time, I'd welcome them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Introducing different handling for small/large transactions
On Thu, Jan 15, 2015 at 03:24:15PM -0800, Stefan Beller wrote: I see the performance problem as well as the contention problem you're pointing out. Dealing with loose refs however creates other problems such as directory/file conflicts on renaming. I am trying to think of a way which moves most of the failures to the transaction_update phase, such that the transaction_commit is rather easy and not expected to produce many errors. So I think dealing with a generic large transaction cannot be really solved outside the packed refs file. There could be another special case for mass deleting refs however. Or retries for the packed refs file. Or we first check if we *really* need to lock the packed refs file (just realized we already do that :/) It sounds like there are certain _types_ of transactions that trigger problems (and that we can handle better). E.g., renames. Which must involve a deletion. And we already have to touch the packed-refs file for a deletion. Once we know that we must do that, we might as well write the rest of the ref updates into it for free, right? There is no extra lock contention (there is contention, but we are not making it worse than what is already there, and what is necessary for the on-disk format). Could the rule be something like: if there are deletions in the transaction /* to handle potential D/F conflicts */ update_type = packed else if # of transactions / # of packed-refs entries 0.8 /* * for performance, we are better off just writing the whole file; * extra lock contention probably doesn't matter because a * simultaneous write would probably conflict with one of our * refs anyway. */ update_type = packed else /* * small-ish ref update. Just write out the loose refs. */ update_type = loose I'm not sure I'm completely comfortable with all of the probably's in the second comment, though. May I ask on which kinds of repository you can see packed-refs.lock contention? I'm not sure what you mean by kinds (i.e., how you want me to characterize our repos). Busy ones, certainly. :) And this is all server-side, where the main write operations are client pushes and running git gc. And of course mainly ones that are shared between many users (so many users pushing to a central repo, not each one forking and making pull requests from their own publishing points). Some people do a lot of deletions. E.g., they may be constantly pushing and deleting tags from a CI process that kicks off whenever a real push happens. A lot of our contention is from the pack-refs process itself. It has to take a lock on each of the loose refs it prunes. It's smart enough (since 06839515, anyway) to avoid complaining when a real writer is holding the lock. But when the race goes the other way, the real writer has no idea that the process holding the lock is weak. That is, if it were another push, we would not want to block and wait to acquire the lock. We would only find out then that the sha1 had moved, and we have to abort the operation. But for a weak writer like packed-refs, the ref value is not changing at all, and we could probably succeed if we retried the lock after a delay. I want to improve git atomicity, specially for 'weird' cases as presented in my previous mail[1]. Eventually I even want to have cross repository atomicty in git, so an example could be: ( cd API-Provider edit files # new changes breaking the API git commit -a -m ... ) ( cd API-consumer edit files # use new and shiny API git commit -a -m ... ) git multipush --atomic API-Provider:origin:master API-consumer:origin:master I think that's a reasonable goal, but I am not sure what packed-refs has to do with it. The client sees only the push interface. So you need: 1. Atomic push to each remote (which I think you have already implemented). 2. Some kind of 2-phase commit on each remote. To say take the lock, tell me when you have it, but _don't_ update until I ask you to. And then when you have confirmation from all remotes, send each one the instruction to commit the update. Of course that isn't foolproof if the commit step fails (lost connection, write error on disk, etc), but it's basically what you want (and this kind of commit is well-studied in the literature). The actions that the remote takes to do (1) are not important, and either way it needs to take all of the locks for each ref. Using packed-refs here is just a quality of implementation issue (there are some transactions we can take as a single atomic change that we otherwise would not be able to). Coincidentally, we are looking at something similar at GitHub to (2) for doing repository replication (where you'd want to make sure that each of your replicas moves in lockstep). It hasn't been written yet, but we imagined that the result would be way too gross and too GitHub-specific to make it
Re: [PULL] git-svn updates from Ramkumar
Junio C Hamano wrote: To which a natural reaction was Can the existing breakage demonstrated by a test?. There's a lot to do, if we really want to dig deeper. The second git-svn-basic test onwards doesn't pass for me, so I really can't do much in the way of contributing tests until that's fixed. Couldn't open a repository: Unable to connect to a repository at URL 'file:///Users/artagnon/src/git/t/trash%20directory.t9100-git-svn-basic/svnrepo': Unable to open an ra_local session to URL: Unable to open repository 'file:///Users/artagnon/src/git/t/trash%20directory.t9100-git-svn-basic/svnrepo': Expected FS format between '1' and '4'; found format '6' at /Users/artagnon/src/git/perl/blib/lib/Git/SVN.pm line 148. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5539 broken under Mac OS X
On Thu, Jan 15, 2015 at 02:39:56PM -0800, Junio C Hamano wrote: Before writing that patchlet, I briefly looked at grep output and thought that many that are protected only by SANITY lacked POSIXPERM by mistake: t/t1004-read-tree-m-u-wf.sh:test_expect_success SANITY 'funny symlink in... t/t3600-rm.sh 'Test that git rm -f fails if its rm fails' t/t7300-clean.sh:test_expect_success SANITY 'removal failure' ' t/t7300-clean.sh:test_expect_success SANITY 'git clean -d with an... All of the above relies on a working chmod as far as I can tell, so they should require POSIXPERM,SANITY, not just SANITY. Yeah, skimming the grep output, I had the same feeling. But I did not investigate closely. lib-httpd should, if it cares about the root-ness, be checking that in a more direct way, test_have_prereq RUNNING_AS_ROOT. Making the implementation of that portable is another matter, though. Exactly. I am happy to submit a patch, but I cannot think of any mechanisms besides: 1. Calling `id`, which I suspect is very not portable. 2. Writing a C program to check getuid(). That's portable for most Unixes. It looks like we already have a hacky wrapper on mingw that will always return 1. Is (2) too gross? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] git-svn updates from Ramkumar
Ramkumar Ramachandra artag...@gmail.com wrote: Junio C Hamano wrote: To which a natural reaction was Can the existing breakage demonstrated by a test?. There's a lot to do, if we really want to dig deeper. The second git-svn-basic test onwards doesn't pass for me, so I really can't do much in the way of contributing tests until that's fixed. Couldn't open a repository: Unable to connect to a repository at URL 'file:///Users/artagnon/src/git/t/trash%20directory.t9100-git-svn-basic/svnrepo': Unable to open an ra_local session to URL: Unable to open repository 'file:///Users/artagnon/src/git/t/trash%20directory.t9100-git-svn-basic/svnrepo': Expected FS format between '1' and '4'; found format '6' at /Users/artagnon/src/git/perl/blib/lib/Git/SVN.pm line 148. I haven't seen this before. Which SVN Perl binding version are you using? Perhaps your svnadmin tool is from a different SVN version or installation of SVN than your Perl bindings? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advise on a push only repo
Jason Pyeron jpye...@pdinc.us writes: Looking at http_config() there, I would guess perhaps: [http] uploadpack = false getanyfile = false but I am not sure if the latter is needed (or anybody seriously tested it, for that matter). Perfect! Had to add receivepack=true for the anonymous part. Good. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unused #include statements
On Thu, Jan 15, 2015 at 10:50:45AM -0800, Junio C Hamano wrote: So the rule might be: - The first #include in C files, except in platform specific compat/ implementations, must be either git-compat-util.h, cache.h or builtin.h. - A C file must directly include the header files that declare the functions and the types it uses, except for the functions and types that are made available to it by including one of the header files it must include by the previous rule. Yeah, that makes sense (and is what I took away from the existing rule in CodingGuidelines, but I agree what is there is not very rigorous). Optionally, - A C file must include only one of git-compat-util.h, cache.h or builtin.h; e.g. if you include builtin.h, do not include the other two, but it can consider what is availble in cache.h available to it. Thoughts? I am not looking forward to a torrent of patches whose sole purpose is to make the existing C files conform to any such rule, though. Clean-up patches that trickle in at a low rate is tolerable, but a torrent is too distracting. I don't think the optionally one above is that necessary. Not because I don't agree with it, but because I do not know that we want to get into the business of laying out every minute detail and implication. The CodingGuidelines document is meant to be guidelines, and I do not want to see arguments like well, the guidelines do not explicitly _disallow_ this, so you must accept it or add something to the guideline. That is a waste of everybody's time. A general philosophy + good taste (from the submitter and the maintainer) should ideally be enough. And hopefully would stop a torrent of but this file doesn't conform to the letter of CodingGuidelines!. Maybe it does not, but if there is no tangible benefit besides blindly following some rules, it is not worth the precious time of developers. Which isn't to say we shouldn't clarify the document when need be. But I think what I quoted at the top already is probably a good improvement over what is there. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Introducing different handling for small/large transactions
On Thu, Jan 15, 2015 at 2:46 PM, Jeff King p...@peff.net wrote: On Thu, Jan 15, 2015 at 02:36:11PM -0800, Stefan Beller wrote: So for here is my proposal for small transactions: (just one ref [and/or reflog] touched): The implication being that a large transaction is any with more than one update. Exactly. I think performance may suffer if you do not also take into account the size of the packed-refs file. If you are updating 5 refs and there are 10 in the packed-refs file, rewriting the extra 5 is probably not a big deal. If there are 400,000 in the packed-refs file, it probably is. I'm not sure where the cutoff is (certainly the per-ref cost is less for packed-refs once you have started writing the file, so there is probably some crossover percentage that you could measure). * detect if we transition to a large transaction (by having more than one entry in transaction-updates) if so: * Pack all currently existing refs into the packed refs file, commit the packed refs file and delete all loose refs. This will avoid (d/f) conflicts. * Keep the packed-refs file locked and move the first transaction update into the packed-refs.lock file This increases lock contention, as now independent ref updates all need to take the same packed-refs.lock. This can be a problem on a busy repository, especially because we never retry the packed-refs lock. We already see this problem somewhat on GitHub. Ref deletions need the packed-refs.lock file, which can conflict with another deletion, or with running `git pack-refs`. -Peff I see the performance problem as well as the contention problem you're pointing out. Dealing with loose refs however creates other problems such as directory/file conflicts on renaming. I am trying to think of a way which moves most of the failures to the transaction_update phase, such that the transaction_commit is rather easy and not expected to produce many errors. So I think dealing with a generic large transaction cannot be really solved outside the packed refs file. There could be another special case for mass deleting refs however. Or retries for the packed refs file. Or we first check if we *really* need to lock the packed refs file (just realized we already do that :/) (just curious:) May I ask on which kinds of repository you can see packed-refs.lock contention? I want to improve git atomicity, specially for 'weird' cases as presented in my previous mail[1]. Eventually I even want to have cross repository atomicty in git, so an example could be: ( cd API-Provider edit files # new changes breaking the API git commit -a -m ... ) ( cd API-consumer edit files # use new and shiny API git commit -a -m ... ) git multipush --atomic API-Provider:origin:master API-consumer:origin:master When having such a goal a reliable and easy to use ref transaction API makes life lots more easier. By reliable I mean that there are no sudden problems as pointed out in [1], these kinds of rejections make users unhappy. And by easy to use I mean there are only a few functions I need to know and no proliferation of functions exposed in the API. Internally we can do all we want such as special cases for delete-only transactions. As another unrelated thought (400,000 refs is quite a lot) Would it make sense to have packed-refs files grouped by topic directory, i.e. one packed-ref for topic/1 topic/2 topic/* and another packed ref for feature/a feature/b feature/* This would rather help your problems with contention instead of making things more atomic though. But that would avoid 400,000 refs in one packed refs file, which then may still be easier to handle for larger transactions. Thanks, Stefan [1] http://www.mail-archive.com/git@vger.kernel.org/msg63919.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] git-svn updates from Ramkumar
Eric Wong normalper...@yhbt.net writes:
Junio C Hamano gits...@pobox.com wrote:
Thanks. No tests necessary/feasible? Just being curious.
They seemed simple and obvious enough to me,
(and most importantly, didn't trigger regressions).
I can see that the top-most one is about .git that is a textual
symlink .gitdir: elsewhere and the code after this part needed
to convert it to the real place in order to be able to read/write
${GIT_DIR}/some file, so that is obvious to me.
But the other one just says handle missing ref_id case correctly
without clarifying what is incorrect in the original and how the
desired correct behaviour is different (in other words, what breaks
without this change)
To which a natural reaction was Can the existing breakage
demonstrated by a test?.
If it is obvious for git-svn folks, then I wouldn't complain,
though.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Introducing different handling for small/large transactions
Stefan Beller sbel...@google.com writes: In ref_transaction_commit * commit the .lock file to its destination * in case this is a deletion: * remove the loose ref * and repack the packed refs file if necessary Don't you need to repack and then remove the loose one, though? Otherwise you would expose a stale packed ref in the middle to the other readers, no? The larger transactions would be handled differently by relying on the packed refs file: In ref_transaction_update: * detect if we transition to a large transaction (by having more than one entry in transaction-updates) if so: * Pack all currently existing refs into the packed refs file, commit the packed refs file and delete all loose refs. This will avoid (d/f) conflicts. * Keep the packed-refs file locked and move the first transaction update into the packed-refs.lock file * Any update(delete, create, update) is put into the locked packed refs file. I am not sure if you mean (a) keep updates only in-core, to be flushed at the commit time, or (b) each and every update in the large transaction results in rewriting the entire packed-refs.lock file, only to be renamed to the final name at the commit time. I am hoping it would be the former. * Additionally we need to obtain the .lock for the loose refs file to keep guarantees, though we should close the file descriptor as we don't wand to run out of file descriptors. Yes, this last point is important. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Advise on a push only repo
-Original Message-
From: Junio C Hamano
Sent: Thursday, January 15, 2015 14:31
Jason Pyeron jpye...@pdinc.us writes:
I am setting up a continous integration (CI) system for an
open source
project and I want to allow forking developers to use the
system, but
I do not want anyone to do a clone or fetch from the CI git
repo, the
repo.
Any advice on limiting the https smart protocol to push
only, blocking clone and fetch?
Looking at http-backend.c
542 static struct service_cmd {
...
558 };
Looking at http-backend.c
19 struct rpc_service {
20 const char *name;
21 const char *config_name;
22 signed enabled : 2;
23 };
24
25 static struct rpc_service rpc_service[] = {
26 { upload-pack, uploadpack, 1 },
27 { receive-pack, receivepack, -1 },
28 };
So it would be natural to assume that there must be a way to
enable/disable these two services, no?
Looking at http_config() there, I would guess perhaps:
[http]
uploadpack = false
getanyfile = false
but I am not sure if the latter is needed (or anybody seriously
tested it, for that matter).
Perfect! Had to add receivepack=true for the anonymous part.
root@twenty-one-100 /opt/git/public
# cat /etc/httpd/conf.d/git.conf
SetEnv GIT_PROJECT_ROOT /opt/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
Directory /usr/lib/git-core*
Options ExecCGI Indexes
Order allow,deny
Allow from all
Require all granted
/Directory
root@twenty-one-100 /opt/git/public
# cat /opt/git/public/config
[core]
repositoryformatversion = 0
filemode = true
bare = true
[http]
receivepack = true
uploadpack = false
getanyfile = false
Test get known object...
root@twenty-one-100 /opt/git/public
# dir objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15
-r--r--r--. 1 apache apache 163 Jan 15 16:56
objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15
root@twenty-one-100 /opt/git/public
# curl
http://127.0.0.1/git/public/objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15 -v
* About to connect() to 127.0.0.1 port 80 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
GET /git/public/objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3
Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: 127.0.0.1
Accept: */*
HTTP/1.1 403 Forbidden
Date: Thu, 15 Jan 2015 22:08:48 GMT
Server: Apache/2.2.15 (CentOS)
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=UTF-8
* Closing connection #0
root@twenty-one-100 /opt/git/public
# fg
tail -f /var/log/httpd/*_log(wd: /opt/git)
== /var/log/httpd/error_log ==
[Thu Jan 15 17:08:48 2015] [error] [client 127.0.0.1] Unsupported service:
getanyfile
== /var/log/httpd/access_log ==
127.0.0.1 - - [15/Jan/2015:17:08:48 -0500] GET
/git/public/objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15 HTTP/1.1 403 -
- curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic
ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
^Z
[1]+ Stopped tail -f /var/log/httpd/*_log (wd: /opt/git)
(wd now: /opt/git/public)
root@twenty-one-100 /opt/git/public
#
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5539 broken under Mac OS X
On Thu, Jan 15, 2015 at 12:29:39PM -0800, Junio C Hamano wrote: This should not be the final patch (I think it should become a lazy prereq as it does a lot more), but just for testing, how does this look? t/test-lib.sh | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index bb1402d..cdafab5 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -1033,7 +1033,16 @@ test_lazy_prereq USR_BIN_TIME ' # When the tests are run as root, permission tests will report that # things are writable when they shouldn't be. -test -w / || test_set_prereq SANITY +if test_have_prereq POSIXPERM + ! test -w / + sanitytest + chmod a= sanitytest + ! (sanitytest) 2/dev/null + chmod +w sanitytest + rm -f sanitytest +then + test_set_prereq SANITY +fi The current scheme does not require POSIXPERM. Would this mean that some platforms no longer runs SANITY tests (e.g., Windows)? Many of the SANITY-marked tests already require both, but not all. And certainly lib-httpd actually cares whether you are _truly_ root, not about weird filesystem permissions. Should lib-httpd literally be checking the output of `id` (though I can imagine that is anything but portable)? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] init-db: remove unused #includes
On Thu, Jan 15, 2015 at 12:36:00PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: FWIW, the full set of CFLAGS I use (which I specify in config.mak) is: CFLAGS += -Wall -Werror CFLAGS += -Wno-format-zero-length CFLAGS += -Wdeclaration-after-statement CFLAGS += -Wpointer-arith CFLAGS += -Wstrict-prototypes CFLAGS += -Wold-style-declaration I think I have no-pointer-to-int-cast, old-style-definition and vla in addition to the above. Thanks, I added the latter two to my setup. But what is the purpose of turning off pointer-to-int warnings? It seems like those are a good indication of a sloppy construct (and AFAICT, we do not have any code which triggers on it). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
GitWeb caching of snapshots
Hi, I noticed that GitWeb caches based on the Last-Modified header. Won't this break if somebody force pushes a branch with the new newest commit being older than the previous? The modification date will be older, which makes little sense to HTTP clients, and it would probably break since they use the If-Modified-Since header. Wouldn't it make more sense to use the commit ID as an ETag? This would avoid this bug. Two different archive types would get the same ETag even if the HTTP content body is not equal, but I think this is not in violation of the HTTP standard, since caching is based on URL's AND ETags. Here's a link to git_snapshot which is the relevant function: http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n7314 Looking forward to your feedback. Regards, Janus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5539 broken under Mac OS X
Jeff King p...@peff.net writes: The current scheme does not require POSIXPERM. Would this mean that some platforms no longer runs SANITY tests (e.g., Windows)? Many of the SANITY-marked tests already require both, but not all. Before writing that patchlet, I briefly looked at grep output and thought that many that are protected only by SANITY lacked POSIXPERM by mistake: t/t1004-read-tree-m-u-wf.sh:test_expect_success SANITY 'funny symlink in... t/t3600-rm.sh 'Test that git rm -f fails if its rm fails' t/t7300-clean.sh:test_expect_success SANITY 'removal failure' ' t/t7300-clean.sh:test_expect_success SANITY 'git clean -d with an... All of the above relies on a working chmod as far as I can tell, so they should require POSIXPERM,SANITY, not just SANITY. And certainly lib-httpd actually cares whether you are _truly_ root, not about weird filesystem permissions. Should lib-httpd literally be checking the output of `id` (though I can imagine that is anything but portable)? Even though t/README describes SANITY to require: Test is not run by root user, and an attempt to write to an unwritable file is expected to fail correctly. and it has been that way from day one, c91cfd19 (tests: A SANITY test prereq for testing if we're root, 2010-08-06) is clear that this is about 'chmod -w' is a good way to test unwritable files lib-httpd should, if it cares about the root-ness, be checking that in a more direct way, test_have_prereq RUNNING_AS_ROOT. Making the implementation of that portable is another matter, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unused #include statements
Jeff King p...@peff.net writes: On Thu, Jan 15, 2015 at 10:50:45AM -0800, Junio C Hamano wrote: ... Thoughts? I am not looking forward to a torrent of patches whose sole purpose is to make the existing C files conform to any such rule, though. Clean-up patches that trickle in at a low rate is tolerable, but a torrent is too distracting. I don't think the optionally one above is that necessary. Not because I don't agree with it, but because I do not know that we want to get into the business of laying out every minute detail and implication. The CodingGuidelines document is meant to be guidelines, and I do not want to see arguments like well, the guidelines do not explicitly _disallow_ this, so you must accept it or add something to the guideline. That is a waste of everybody's time. Totally. I know we do not want to get into that business. A general philosophy + good taste (from the submitter and the maintainer) should ideally be enough. Yes, ideally ;-) Which isn't to say we shouldn't clarify the document when need be. But I think what I quoted at the top already is probably a good improvement over what is there. OK, thanks. Let's queue something like this for post 2.3 cycle, then. -- 8 -- Subject: CodingGuidelines: clarify C #include rules Even though advice.h includes git-compat-util.h, it is not sensible to have it as the first #include and indirectly satisify the You must give git-compat-util.h a clean environment to set up feature test macros before including any of the system headers are included, which is the real requirement. Because: - A command that interacts with the object store, config subsystem, the index, or the working tree cannot do anything without using what is declared in cache.h; - A built-in command must be declared in builtin.h, so anything in builtin/*.c must include it; - These two headers both include git-compat-util.h as the first thing; and - Almost all our *.c files (outside compat/ and borrowed files in xdiff/) need some Git-ness from cache.h to do something Git-ish. let's explicitly specify that one of these three header files must be the first thing that is included. Any of our *.c file should include the header file that directly declares what it uses, instead of relying on the fact that some *.h file it includes happens to include another *.h file that declares the necessary function or type. Spell it out as another guideline item. Helped-by: Jeff King p...@peff.net Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/CodingGuidelines | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 894546d..578d07c 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -328,9 +328,14 @@ For C programs: - When you come up with an API, document it. - - The first #include in C files, except in platform specific - compat/ implementations, should be git-compat-util.h or another - header file that includes it, such as cache.h or builtin.h. + - The first #include in C files, except in platform specific compat/ + implementations, must be either git-compat-util.h, cache.h or + builtin.h. You do not have to include more than one of these. + + - A C file must directly include the header files that declare the + functions and the types it uses, except for the functions and types + that are made available to it by including one of the header files + it must include by the previous rule. - If you are planning a new command, consider writing it in shell or perl first, so that changes in semantics can be easily -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5539 broken under Mac OS X
Jeff King p...@peff.net writes: Exactly. I am happy to submit a patch, but I cannot think of any mechanisms besides: 1. Calling `id`, which I suspect is very not portable. 2. Writing a C program to check getuid(). That's portable for most Unixes. It looks like we already have a hacky wrapper on mingw that will always return 1. Is (2) too gross? Not overly gross compared to some existing test-*.c files, I would say. I wondered what 'perl -e 'print $' would say in mingw, and if that is portable enough, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Introducing different handling for small/large transactions
For everyday use we want git to be fast. Creating one commit should not touch the packed refs file. If we do other stuff involving more than one ref, we may accept touching the packed refs file and have a process which takes slightly longer but can handle more complex requests correctly, such as renaming into and from directories (topic/1 - topic and reverse). Renaming is currently not part of the transaction API because of the (D/F) problems. This proposed change would enable having renames being part of the transactions API. A transaction covers creating, deleting and updating a ref and its reflog. Renaming would be a deletion followed by creating a new ref atomically. So for here is my proposal for small transactions: (just one ref [and/or reflog] touched): In ref_transaction_update: * create $REF.lock file * write new content to the lock file In ref_transaction_commit * commit the .lock file to its destination * in case this is a deletion: * remove the loose ref * and repack the packed refs file if necessary The larger transactions would be handled differently by relying on the packed refs file: In ref_transaction_update: * detect if we transition to a large transaction (by having more than one entry in transaction-updates) if so: * Pack all currently existing refs into the packed refs file, commit the packed refs file and delete all loose refs. This will avoid (d/f) conflicts. * Keep the packed-refs file locked and move the first transaction update into the packed-refs.lock file * Any update(delete, create, update) is put into the locked packed refs file. * Additionally we need to obtain the .lock for the loose refs file to keep guarantees, though we should close the file descriptor as we don't wand to run out of file descriptors. In ref_transaction_commit: * We only need to commit the packed refs file * Discard all other lock files as the changes get committed as a whole by the packed refs file Any feedback would be welcome! Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] init-db: remove unused #includes
Jeff King p...@peff.net writes: On Thu, Jan 15, 2015 at 12:36:00PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: FWIW, the full set of CFLAGS I use (which I specify in config.mak) is: CFLAGS += -Wall -Werror CFLAGS += -Wno-format-zero-length CFLAGS += -Wdeclaration-after-statement CFLAGS += -Wpointer-arith CFLAGS += -Wstrict-prototypes CFLAGS += -Wold-style-declaration I think I have no-pointer-to-int-cast, old-style-definition and vla in addition to the above. Thanks, I added the latter two to my setup. But what is the purpose of turning off pointer-to-int warnings? It seems like those are a good indication of a sloppy construct (and AFAICT, we do not have any code which triggers on it). It probably a remnant from olden days; perhaps we used to have a code that stuffs a pointer value to an int field used as a hash key or something. As you said, there is no need for disabling that check in today's code. Thanks for catching. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unused #include statements
On Thu, Jan 15, 2015 at 03:20:09PM -0800, Junio C Hamano wrote: OK, thanks. Let's queue something like this for post 2.3 cycle, then. -- 8 -- Subject: CodingGuidelines: clarify C #include rules [...] Thanks, this looks good to me. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] git-svn updates from Ramkumar
Eric Wong wrote: I haven't seen this before. Which SVN Perl binding version are you using? Perhaps your svnadmin tool is from a different SVN version or installation of SVN than your Perl bindings? I have two installations of Subversion: the system one is at /Library/Developer/CommandLineTools @ version 1.7.17, and the brew installed one is at /usr/local @ version 1.8.10. When I build git from scratch, it links to the dated SVN bindings for some reason. I suspect I have to tweak $PERL5LIB? Can we patch git-svn to link to the Right one on OS X? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On Jan 15, 2015, at 17:32, Jeff King wrote: On Thu, Jan 15, 2015 at 04:04:24PM -0800, Junio C Hamano wrote: I wondered what 'perl -e 'print $' would say in mingw, and if that is portable enough, though. Good thinking. I guess the best way to find out is to convince somebody from msysgit to try this patch. :) We may simply find that nobody there even has apache installed on their box, and they do not run the http tests at all. [...] We implement NOT_ROOT by checking perl's $ variable, since we cannot rely on the id program being available everywhere (and we would rather avoid writing a custom C program to run geteuid if we can). Does it make a difference that id is POSIX [1]? So the test if [ $(id -u) = 0 ] or similar ought to work. id -u works for me in MSYS and cygwin (each appears to have it's own id.exe). + +test_lazy_prereq NOT_ROOT ' + uid=$(perl -e print \$) + test $uid != 0 +' Does NO_PERL affect this? Or is Perl always required to run the tests. Also $ is real user id. Don't you want effective user id ($), that's what the comment says... Both $ and $ work for me in MSYS and cygwin although if I run it from cmd.exe using strawberry perl, both $ and $ give 0. (There's no id.exe for cmd.exe unless it finds the cygwin/msys one.) As long as NO_PERL is not also intended to affect make test either the perl or id version seems fine to me (as long as it's Perl's $) since I doubt the tests would run with just cmd.exe. :) -Kyle [1] http://pubs.opengroup.org/onlinepubs/009604499/utilities/id.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] commit/status: show the index-worktree with -v -v
Michael J Gruber g...@drmicha.warpmail.net writes:
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in addition to HEAD index diff. This allows to review unstaged
changes which might be missing from the commit.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Also, the git status man page does not mention -v at all, and the doc
for git status (long format) and the status parts of the git commit
man page should really be the same.
In any case, this may have helped the OP with his amend oversight.
Hmm, does this show what change relative to HEAD is committed fully
and then after that show what change relative to the index being
commited remains in the working tree at the end?
I do not think that output order is very helpful. Two diffs to the
same file next to each other may make it easier to notice, though.
That is, not like this:
diff --git a/A b/A
...
diff --git a/B b/B
...
diff --git i/A w/A
...
but like this:
diff --git a/A b/A
...
diff --git i/A w/A
...
diff --git a/B b/B
...
or it may want to even be like this:
diff --git a/A b/A
...
diff --git to-be-committed/A left-out-of-the-commit/A
...
diff --git a/B b/B
...
by using a custom, unusual and easy-to-notice prefixes.
Documentation/git-commit.txt | 4
wt-status.c | 8
2 files changed, 12 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in
linkgit:git-config[1].
would be committed at the bottom of the commit message
template. Note that this diff output doesn't have its
lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
-q::
--quiet::
diff --git a/wt-status.c b/wt-status.c
index b54eac5..75674c2 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -874,6 +874,14 @@ static void wt_status_print_verbose(struct wt_status *s)
wt_status_add_cut_line(s-fp);
}
run_diff_index(rev, 1);
+ if (s-verbose 1) {
+ setup_work_tree();
+ if (read_cache_preload(rev.diffopt.pathspec) 0)
+ perror(read_cache_preload);
Hmm, as we have run diff-index already, we must have had the index
loaded, no? What is going on here?
+ rev.diffopt.a_prefix = 0; /* allow run_diff_files */
+ rev.diffopt.b_prefix = 0; /* to reset the prefixes */
This is not just allow to reset the prefixes, but forces the use
of mnemonic prefixes to make sure they look different from the
normal diff --cached output that shows what is going to be
committed. If we were to do this, for consistency, we may want to
use the mnemonic prefix for the to be commited part, no?
+ run_diff_files(rev, 0);
+ }
}
static void wt_status_print_tracking(struct wt_status *s)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] http-push: trim trailing newline from remote symref
Kyle J. McKay mack...@gmail.com writes: On Jan 13, 2015, at 11:58, Jeff King wrote: ... I'm running curl 7.38, and in this context older is anything before 7.40, so that would explain it. curl 7.38 was released 2014-09-10, so it's only 4 months old at this point. 7.40 was only released 5 days ago on 2015-01-08 which is probably why there have not been a whole lot of reports about this so far. After updating to curl 7.40 I get: t5540-http-push-webdav.sh (Wstat: 256 Tests: 19 Failed: 1) Failed test: 10 Non-zero exit status: 1 Anyway. I think my patch is still the right thing. But that does explain why we didn't notice the test failure. And then after applying your patch I'm back to: t5540-http-push-webdav.sh .. ok I see a Ubuntu box I have nearby has this: curl (7.35.0-1ubuntu2.3) trusty-security; urgency=medium * SECURITY UPDATE: URL request injection - debian/patches/CVE-2014-8150.patch: drop bad chars from URL in lib/url.c, added test to tests/data/Makefile.am, tests/data/test1529, tests/libtest/Makefile.inc, tests/libtest/lib1529.c. - CVE-2014-8150 -- Marc Deslauriers marc.deslauri...@ubuntu.com Wed, 14 Jan 2015 08:49:32 -0500 That explains why I started seeing the same on a box with 7.35.x which looks older than 7.40. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] git-svn updates from Ramkumar
Ramkumar Ramachandra artag...@gmail.com wrote: Eric Wong wrote: I haven't seen this before. Which SVN Perl binding version are you using? Perhaps your svnadmin tool is from a different SVN version or installation of SVN than your Perl bindings? I have two installations of Subversion: the system one is at /Library/Developer/CommandLineTools @ version 1.7.17, and the brew installed one is at /usr/local @ version 1.8.10. When I build git from scratch, it links to the dated SVN bindings for some reason. I suspect I have to tweak $PERL5LIB? Adding it to GITPERLLIB should work... Can we patch git-svn to link to the Right one on OS X? You should be able to set up everything in the Makefile, that has special cases for Fink and Darwin ports, at least. Somebody who knows OS X packaging systems might have better advice. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On Thu, Jan 15, 2015 at 04:04:24PM -0800, Junio C Hamano wrote: I wondered what 'perl -e 'print $' would say in mingw, and if that is portable enough, though. Good thinking. I guess the best way to find out is to convince somebody from msysgit to try this patch. :) We may simply find that nobody there even has apache installed on their box, and they do not run the http tests at all. -- 8 -- The SANITY prerequisite is really about whether the filesystem will respect the permissions we set, and being root is only one part of that. But the httpd tests really just care about not being root, as they are trying to avoid weirdness in apache (see a1a3011 for details). Let's switch out SANITY for a new NOT_ROOT prerequisite, which will let us tweak SANITY more freely. We implement NOT_ROOT by checking perl's $ variable, since we cannot rely on the id program being available everywhere (and we would rather avoid writing a custom C program to run geteuid if we can). Note that we cannot just call this ROOT and ask for !ROOT. The possible outcomes are: 1. we know we are root 2. we know we are not root 3. we could not tell, because perl was not installed or barfed showing us $ We should conservatively treat (3) as does not have the prerequisite, which means that a naive negation would not work. Signed-off-by: Jeff King p...@peff.net --- t/lib-httpd.sh | 2 +- t/test-lib.sh | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh index fd53b57..d154d1e 100644 --- a/t/lib-httpd.sh +++ b/t/lib-httpd.sh @@ -37,7 +37,7 @@ then test_done fi -if ! test_have_prereq SANITY; then +if ! test_have_prereq NOT_ROOT; then test_skip_or_die $GIT_TEST_HTTPD \ Cannot run httpd tests as root fi diff --git a/t/test-lib.sh b/t/test-lib.sh index bb1402d..60020ca 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -1040,3 +1040,8 @@ test_lazy_prereq UNZIP ' $GIT_UNZIP -v test $? -ne 127 ' + +test_lazy_prereq NOT_ROOT ' + uid=$(perl -e print \$) + test $uid != 0 +' -- 2.2.1.425.g441bb3c -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Segmentation fault in git apply
On Jan 14, 2015, at 11:09, Michael Blume wrote: On Wed, Jan 14, 2015 at 10:58 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:48 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:44 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:40 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:20 AM, Michael Blume blume.m...@gmail.com wrote: This is a mac with a fresh build of git from pu branch, commit 53b80d0. With my gitconfig looking like [user] email = blume.m...@gmail.com name = Michael Blume [apply] whitespace = fix [core] whitespace = fix,trailing-space,space-before-tab, tab-in- indent, tabwidth=4 If I run git clone g...@github.com:MichaelBlume/clojure.git cd clojure git checkout origin/rebase-start git rebase origin/rebase-base I get [...] Applying: CLJ-1295: Speed up dissoc on array-maps Applying: some throwing Applying: don't pass offset to ArrayChunk Applying: make EMPTY accessible Applying: add handy create methods Applying: regenerate Applying: regenerate /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 Segmentation fault: 11 git apply --index $dotest/patch / dev/null 21 I can reproduce in a 64-bit v2.1.4 as well, but not in a 32-bit v2.1.4 build. My recipe is slightly different to facilitate automation: cd /tmp git clone git://github.com/MichaelBlume/clojure.git cd clojure git config user.email blume.m...@gmail.com git config user.name Michael Blume git config apply.whitespace fix git config core.whitespace \ fix,trailing-space,space-before-tab, tab-in-indent, tabwidth=4 git checkout origin/rebase-start git rebase origin/rebase-base Looks like v1.7.6.6 64-bit works okay. Running git bisect run... 5782..2890..1445..722..361..179..91..44..23..13..7..3..1..0 And the winner is (first appearing in v1.8.2.2): commit 250b3c6c992b3cb04e756eb33bed99442fc55193 Author: Junio C Hamano gits...@pobox.com Date: Fri Mar 22 11:10:03 2013 -0700 apply --whitespace=fix: avoid running over the postimage buffer Originally update-pre-post-images could assume that any whitespace fixing will make the result only shorter by unexpanding runs of leading SPs into HTs and removing trailing whitespaces at the end of lines. Updating the post-image we read from the patch to match the actual result can be performed in-place under this assumption. These days, however, we have tab-in-indent (aka Python) rule whose result can be longer than the original, and we do need to allocate a larger buffer than the input and replace the result. Fortunately the support for lengthening rewrite was already added when we began supporting match while ignoring whitespace differences mode in 86c91f91794c (git apply: option to ignore whitespace differences, 2009-08-04). We only need to correctly count the number of bytes necessary to hold the updated result and tell the function to allocate a new buffer. Signed-off-by: Junio C Hamano gits...@pobox.com And just to confirm, building with 250b3c6c^ (which also happens to be v1.8.0.3) does not fail. And the stack trace from the crash dump of a debug build of 250b3c6c is: Thread 0 Crashed: 0 libSystem.B.dylib 0x7fff8290242a szone_free + 1222 1 git0x00019fe9 apply_one_fragment + 2164 (apply.c:2816) 2 git0x0001a760 apply_fragments + 195 (apply.c:2959) 3 git0x0001b62d apply_data + 96 (apply.c:3340) 4 git0x0001c0b1 check_patch + 869 (apply.c: 3559) 5 git0x0001c157 check_patch_list + 83 (apply.c:3574) 6 git0x0001dc70 apply_patch + 646 (apply.c: 4189) 7 git0x0001ea3a cmd_apply + 2700 (apply.c: 4418) 8 git0x00011ae8 run_builtin + 402 (git.c:306) 9 git0x00011c9a handle_internal_command + 181 (git.c:467) 10 git0x00011dab run_argv + 41 (git.c:516) 11 git0x00011ede main + 258 (git.c:588) 12 git0x00010ee8 start + 52 And the gdb backtrace from the core file: #0 0x7fff8290242a at szone_free + 1222 #1 0x00019fe9 in apply_one_fragment (img=0x7fff5fbfe640, frag=0x100400a60, inaccurate_eof=0, ws_rule=3268, nth_fragment=1) at builtin/apply.c:2815 #2 0x0001a760 in apply_fragments (img=0x7fff5fbfe640, patch=0x1004005e0) at builtin/apply.c:2959 #3 0x0001b62d in apply_data (patch=0x1004005e0, st=0x7fff5fbfe6b0, ce=0x1004072e0) at builtin/apply.c:3340 #4 0x0001c0b1 in check_patch (patch=0x1004005e0) at builtin/ apply.c:3559 #5 0x0001c157 in check_patch_list (patch=0x1004005e0) at builtin/apply.c:3574 #6 0x0001dc70 in apply_patch (fd=3, filename=0x7fff5fbff33a /
Re: Big repo not shrinking on repack or gc?
On Thu, Jan 15, 2015 at 6:43 PM, Andreas Krey a.k...@gmx.de wrote: On Thu, 15 Jan 2015 18:05:46 +, Bryan Turner wrote: ... They do. So it seems it was forked once upon a time, but... /opt/apps/atlassian/stash-data/shared/data/repositories $ grep '' */objects/info/alternates 158/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/20/objects 45/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/33/objects 93/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/91/objects ...there is no trace of a fork still existing (the repo in question is 143). Yes, the system doesn't currently detect when a repository becomes un-forked because it's not a common use case. At this point I think we should probably take this off-list. You can either e-mail me directly (bturner at atlassian dot com), or, better still, raise a ticket on support.atlassian.com. Either way I'll work with you directly to un-fork the repository on disk and allow it to clean itself up. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] git-svn updates from Ramkumar
The following changes since commit 563d4e59bd167fe2eecc5480e3841d878b1c8c2b: Fifth batch for 2.3 cycle (2015-01-14 12:44:03 -0800) are available in the git repository at: git://bogomips.org/git-svn.git for-junio for you to fetch changes up to a94655dcfedc6b266ba32a3d32b0d52a1ce6a928: git-svn: make it play nicely with submodules (2015-01-15 08:35:55 +) Ramkumar Ramachandra (2): Git::SVN: handle missing ref_id case correctly git-svn: make it play nicely with submodules git-svn.perl| 6 ++ perl/Git/SVN.pm | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] init-db: remove unused #includes
On Thu, Jan 15, 2015 at 04:13:00PM +0600, Alexander Kuleshov wrote: yes right, missed system_path usage. But it's strange, code still compiles successfully without exec_cmd.h. Sort of. With your patch I get: builtin/init-db.c: In function ‘copy_templates’: builtin/init-db.c:127:3: warning: implicit declaration of function ‘system_path’ [-Wimplicit-function-declaration] template_dir = to_free = system_path(DEFAULT_GIT_TEMPLATE_DIR); ^ builtin/init-db.c:127:26: warning: assignment makes pointer from integer without a cast template_dir = to_free = system_path(DEFAULT_GIT_TEMPLATE_DIR); Those are just warnings, and on some platforms the resulting code will be fine, but it does violate the C standard to not have a valid declaration in this case (it defaults to an int return type, which is wrong; but simply as a matter of style we do not like implicit declarations even when they are technically correct). If you are going to be doing refactoring, I'd recommend building with -Werror in your CFLAGS to catch such problems. FWIW, the full set of CFLAGS I use (which I specify in config.mak) is: CFLAGS += -Wall -Werror CFLAGS += -Wno-format-zero-length CFLAGS += -Wdeclaration-after-statement CFLAGS += -Wpointer-arith CFLAGS += -Wstrict-prototypes CFLAGS += -Wold-style-declaration -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] init-db: remove unused include
cache.h removed, because it's already included at builtin.h Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- builtin/init-db.c | 1 - 1 file changed, 1 deletion(-) diff --git a/builtin/init-db.c b/builtin/init-db.c index 280454a..8edef87 100644 --- a/builtin/init-db.c +++ b/builtin/init-db.c @@ -3,7 +3,6 @@ * * Copyright (C) Linus Torvalds, 2005 */ -#include cache.h #include builtin.h #include exec_cmd.h #include parse-options.h -- 2.3.0.rc0.256.g2ad8601.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation/init-db.txt: minor style and synopsys fixes
This patch constists of two minor changes: * line-wrap 'git init-db' synopsis * last possible argument '[directory]' was missed Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-init-db.txt | 5 +++-- Documentation/git-init.txt| 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index 648a6cd..2c77aaa 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -9,8 +9,9 @@ git-init-db - Creates an empty Git repository SYNOPSIS [verse] -'git init-db' [-q | --quiet] [--bare] [--template=template_directory] [--separate-git-dir git dir] [--shared[=permissions]] - +'git init-db' [-q | --quiet] [--bare] [--template=template_directory] +[--separate-git-dir git-dir] +[--shared[=permissions]] [directory] DESCRIPTION --- diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 369f889..25412ac 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -10,8 +10,8 @@ SYNOPSIS [verse] 'git init' [-q | --quiet] [--bare] [--template=template_directory] - [--separate-git-dir git dir] - [--shared[=permissions]] [directory] + [--separate-git-dir git-dir] + [--shared[=permissions]] [directory] DESCRIPTION @@ -108,7 +108,7 @@ By default, the configuration flag `receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you provide a 'directory', the command is run inside it. If this directory +If you provide a directory, the command is run inside it. If this directory does not exist, it will be created. -- -- 2.3.0.rc0.314.g170a664.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-svn metadata commands performance issue
On Wed, Jan 14, 2015 at 9:30 PM, Eric Wong normalper...@yhbt.net wrote:
Niluge kiwi kiwi...@gmail.com wrote:
Hi all,
In magit (http://magit.github.io/), a popular git frontend within
emacs, there is a git-svn frontend. With a recent refactoring, it was
discovered that git-svn metadata commands (like git-svn info) are
much slower than git ones:
git svn info: 130-150ms (after warmup): get the svn revision and url.
git svn rebase --dry-run: 150-170ms (after warmup): get the remote
branch.
Whereas in pure git:
git rev-parse --abbrev-ref HEAD@{upstream}: 2-3ms (after warmup): get
the remote branch
Other git commands alike take all less than 10ms after warmup.
Thanks for the bug report. I actually see worse performance from
my old machines, but I'm not a very heavy git-svn user anymore.
100ms is an eternity :
This is an issue for the magit developers and users: just getting a
git-svn status with some metadata easily take ~500ms, which is really
slow for a UI. The equivalent UI with a pure git repository in magit
takes much less than 100ms to generate although more than 30 git
process are forked for it.
How big is the parent process which forks the git commands? On Linux at
least, fork() performance is negatively impacted by parent process
memory size. To avoid spawn performance problems with large parent
processes, vfork() should be used, but there does not seem to be an
easy/portable way to use vfork() from Perl.
My emacs process uses ~500MB in RAM, but all the timings from my first
email come from commands run from bash that uses 8Mo in RAM. I don't
see any significant difference between timings from emacs and bash.
A previous version of magit-svn was much faster because it
re-implemented the logic of git-svn from perl to elisp (the
programming language in emacs), and to get the 3 previously mentioned
values it took less than 10ms.
I've never worked with elisp, but we can probably figure out why it's
faster. Can you give us a pointer to the old elisp code?
The commit that removes the old code and replaces it by simple calls
to git-svn is here:
https://github.com/magit/magit/commit/b583e43a57dee164fdd53e0772220e32c1b3fab3
It may be faster because we don't have to start perl each time...
What could be done about this?
Could git-svn performance be dramatically improved?
Even git svn --version takes ~100ms, is perl the bottleneck?
The Linux 'perf' tool reports much time is spent is from the Perl
parser. So we may implement lazy loading, so simple commands such as
git svn info do not need to load and parse all the Perl code.
Or should each git-svn frontend developer re-implement the git-svn
metadata commands themselves for better performance?
I prefer git-svn be fast enough; but you're free to reimplement
and optimize your own code as you see fit.
The magit maintainer also prefers git-svn to be fast enough, because
it means less code to write and maintain.
Also, wouldn't it be better for those frontend developers if there
were some git-svn porcelain commands like git has? Fast, easy to parse
and stable input output format?
Sure, but we don't know what you'd need beyond the current command set.
Of course we need to be careful about adding even more code to git-svn
as that impacts startup time, too.
I'll ask the magit maintainer to weight in here for the ideal git-svn
command line features.
Also, couldn't the code be split into multiple files to have no global
impact on startup time when adding new features?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] init-db: remove unused #includes
Hello Junio, yes right, missed system_path usage. But it's strange, code still compiles successfully without exec_cmd.h. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-svn: lazy load some modules
Baby steps, pushed to my master on git://bogomips.org/git-svn
--8
Subject: [PATCH] git-svn: lazy load some modules
We can delay loading some modules until we need them for uncommon
code paths. For example, persistent memoization is not often
needed, so we can avoid loading the modules for it until we
encounter svn::mergeinfo during fetch.
This gives a tiny reduction in syscalls (from 15641 to 15305) when
running git svn info and counting via strace -fc. Further,
more invasive work will be needed to noticeably improve performance.
Signed-off-by: Eric Wong normalper...@yhbt.net
---
git-svn.perl| 13 +++--
perl/Git/SVN.pm | 22 +-
perl/Git/SVN/Editor.pm | 3 +--
perl/Git/SVN/Fetcher.pm | 3 +--
perl/Git/SVN/Ra.pm | 5 -
5 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 32d109e..36f7240 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -11,14 +11,10 @@ $AUTHOR = 'Eric Wong normalper...@yhbt.net';
$VERSION = '@@GIT_VERSION@@';
use Carp qw/croak/;
-use Digest::MD5;
-use IO::File qw//;
use File::Basename qw/dirname basename/;
use File::Path qw/mkpath/;
use File::Spec;
-use File::Find;
use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/;
-use IPC::Open3;
use Memoize;
use Git::SVN;
@@ -298,7 +294,6 @@ my %cmd = (
{} ],
);
-use Term::ReadLine;
package FakeTerm;
sub new {
my ($class, $reason) = @_;
@@ -313,6 +308,7 @@ package main;
my $term;
sub term_init {
$term = eval {
+ require Term::ReadLine;
$ENV{GIT_SVN_NOTTY}
? new Term::ReadLine 'git-svn', \*STDIN, \*STDOUT
: new Term::ReadLine 'git-svn';
@@ -1173,6 +1169,7 @@ sub cmd_branch {
}
::_req_svn();
+ require SVN::Client;
my $ctx = SVN::Client-new(
config = SVN::Core::config_get_config(
@@ -1693,11 +1690,13 @@ sub cmd_reset {
}
sub cmd_gc {
+ require File::Find;
if (!can_compress()) {
warn Compress::Zlib could not be found; unhandled.log .
files will not be compressed.\n;
}
- find({ wanted = \gc_directory, no_chdir = 1}, $ENV{GIT_DIR}/svn);
+ File::Find::find({ wanted = \gc_directory, no_chdir = 1},
+$ENV{GIT_DIR}/svn);
}
### utility functions #
@@ -2122,6 +2121,7 @@ sub find_file_type_and_diff_status {
sub md5sum {
my $arg = shift;
my $ref = ref $arg;
+ require Digest::MD5;
my $md5 = Digest::MD5-new();
if ($ref eq 'GLOB' || $ref eq 'IO::File' || $ref eq 'File::Temp') {
$md5-addfile($arg) or croak $!;
@@ -2148,6 +2148,7 @@ sub gc_directory {
$gz-gzwrite($str) or
die Unable to write: .$gz-gzerror().!\n;
}
+ no warnings 'once'; # $File::Find::name would warn
unlink $_ or die unlink $File::Find::name: $!\n;
} elsif (-f $_ basename($_) eq index) {
unlink $_ or die unlink $_: $!\n;
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 8e4af71..afa562c 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -9,10 +9,8 @@ use vars qw/$_no_metadata
$_use_log_author $_add_author_from $_localtime/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
-use File::Copy qw/copy/;
use IPC::Open3;
use Memoize; # core since 5.8.0, Jul 2002
-use Memoize::Storable;
use POSIX qw(:signal_h);
use Git qw(
@@ -32,11 +30,7 @@ use Git::SVN::Utils qw(
add_path_to_url
);
-my $can_use_yaml;
-BEGIN {
- $can_use_yaml = eval { require Git::SVN::Memoize::YAML; 1};
-}
-
+my $memo_backend;
our $_follow_parent = 1;
our $_minimize_url = 'unset';
our $default_repo_id = 'svn';
@@ -1578,7 +1572,16 @@ sub tie_for_persistent_memoization {
my $hash = shift;
my $path = shift;
- if ($can_use_yaml) {
+ unless ($memo_backend) {
+ if (eval { require Git::SVN::Memoize::YAML; 1}) {
+ $memo_backend = 1;
+ } else {
+ require Memoize::Storable;
+ $memo_backend = -1;
+ }
+ }
+
+ if ($memo_backend 0) {
tie %$hash = 'Git::SVN::Memoize::YAML', $path.yaml;
} else {
tie %$hash = 'Memoize::Storable', $path.db, 'nstore';
@@ -2188,8 +2191,9 @@ sub rev_map_set {
# both of these options make our .rev_db file very, very important
# and we can't afford to lose it because rebuild() won't work
if ($self-use_svm_props || $self-no_metadata) {
+ require File::Copy;
$sync = 1;
- copy($db, $db_lock) or die rev_map_set(@_): ,
+ File::Copy::copy($db,
Re: Segmentation fault in git apply
On Jan 15, 2015, at 00:26, Kyle J. McKay wrote: On Jan 14, 2015, at 11:09, Michael Blume wrote: On Wed, Jan 14, 2015 at 10:58 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:48 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:44 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:40 AM, Michael Blume blume.m...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:20 AM, Michael Blume blume.m...@gmail.com wrote: This is a mac with a fresh build of git from pu branch, commit 53b80d0. With my gitconfig looking like [user] email = blume.m...@gmail.com name = Michael Blume [apply] whitespace = fix [core] whitespace = fix,trailing-space,space-before-tab, tab-in- indent, tabwidth=4 If I run git clone g...@github.com:MichaelBlume/clojure.git cd clojure git checkout origin/rebase-start git rebase origin/rebase-base I get [...] Applying: CLJ-1295: Speed up dissoc on array-maps Applying: some throwing Applying: don't pass offset to ArrayChunk Applying: make EMPTY accessible Applying: add handy create methods Applying: regenerate Applying: regenerate /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 Segmentation fault: 11 git apply --index $dotest/patch / dev/null 21 I can reproduce in a 64-bit v2.1.4 as well, but not in a 32-bit v2.1.4 build. My recipe is slightly different to facilitate automation: cd /tmp git clone git://github.com/MichaelBlume/clojure.git cd clojure git config user.email blume.m...@gmail.com git config user.name Michael Blume git config apply.whitespace fix git config core.whitespace \ fix,trailing-space,space-before-tab, tab-in-indent, tabwidth=4 git checkout origin/rebase-start git rebase origin/rebase-base Looks like v1.7.6.6 64-bit works okay. Running git bisect run... 5782..2890..1445..722..361..179..91..44..23..13..7..3..1..0 And the winner is (first appearing in v1.8.2.2): commit 250b3c6c992b3cb04e756eb33bed99442fc55193 Author: Junio C Hamano gits...@pobox.com Date: Fri Mar 22 11:10:03 2013 -0700 apply --whitespace=fix: avoid running over the postimage buffer [...] And just to confirm, building with 250b3c6c^ (which also happens to be v1.8.0.3) does not fail. [...] Running with various MallocCheckHeap and MallocErrorAbort settings leads to: git(12926) malloc: *** error for object 0x10040be80: incorrect checksum for freed object - object was probably modified after being freed. And a new backtrace from the core file: #0 0x7fff82962da6 at __kill + 10 #1 0x7fff829c5af8 at szone_error + 476 #2 0x7fff829c7218 at szone_check + 637 #3 0x7fff829caaf8 at malloc_zone_check + 42 #4 0x7fff829cb11d at internal_check + 14 #5 0x7fff828fc939 at malloc_zone_malloc + 60 #6 0x7fff828fc8e0 at malloc + 44 #7 0x000100131ae4 in xmalloc (size=47378) at wrapper.c:50 #8 0x0001950b in update_image (img=0x7fff5fbfe4a0, applied_pos=1569, preimage=0x7fff5fbfe340, postimage=0x7fff5fbfe310) at builtin/apply.c:2533 #9 0x00019fa7 in apply_one_fragment (img=0x7fff5fbfe4a0, frag=0x100400a60, inaccurate_eof=0, ws_rule=3268, nth_fragment=1) at builtin/apply.c:2808 #10 0x0001a760 in apply_fragments (img=0x7fff5fbfe4a0, patch=0x1004005e0) at builtin/apply.c:2959 #11 0x0001b62d in apply_data (patch=0x1004005e0, st=0x7fff5fbfe510, ce=0x1004072e0) at builtin/apply.c:3340 #12 0x0001c0b1 in check_patch (patch=0x1004005e0) at builtin/ apply.c:3559 #13 0x0001c157 in check_patch_list (patch=0x1004005e0) at builtin/apply.c:3574 #14 0x0001dc70 in apply_patch (fd=9, filename=0x7fff5fbff1e2 /private/tmp/clojure/.git/rebase-apply/patch, options=0) at builtin/apply.c:4189 #15 0x0001ea3a in cmd_apply (argc=1, argv=0x7fff5fbfefe0, prefix_=0x0) at builtin/apply.c:4418 #16 0x00011ae8 in run_builtin (p=0x1001a7070, argc=3, argv=0x7fff5fbfefe0) at git.c:306 #17 0x00011c9a in handle_internal_command (argc=3, argv=0x7fff5fbfefe0) at git.c:467 #18 0x00011dab in run_argv (argcp=0x7fff5fbfef9c, argv=0x7fff5fbfef90) at git.c:513 #19 0x00011ede in main (argc=3, argv=0x7fff5fbfefe0) at git.c:588 I looked at the code a bit, but a fix does not just jump out at me. From the debug info it seems pretty clear that some memory's being stepped on. If I make this change on top of 250b3c6c: diff --git a/builtin/apply.c b/builtin/apply.c index df773c75..8795e830 100644 --- a/builtin/apply.c +++ b/builtin/apply.c @@ -2390,6 +2390,8 @@ static int match_fragment(struct image *img, fixed_buf = strbuf_detach(fixed, fixed_len); if (postlen postimage-len) postlen = 0; + if (postlen) + postlen = 2 * postimage-len; update_pre_post_images(preimage, postimage, fixed_buf, fixed_len, postlen); return 1; Then the problem goes away. That seems to suggest that postlen
Re: git-svn metadata commands performance issue
Eric Wong normalper...@yhbt.net writes: How big is the parent process which forks the git commands? On Linux at least, fork() performance is negatively impacted by parent process memory size. Huh. I thought with the advent of demand-paging, at the very least with copy-on-write, this was supposed to be sort of a non-issue. The old original UNIX version, in contrast, consisted of swapping out the current process without removing the in-memory copy. But since the in-memory copy then did the exec call and since usually the exec call was happy about every page of free memory (we _are_ talking about something like 64kB of total available memory here), that tended to work reasonably well. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cosmetic bug: git show --pretty:format produces different output than git show --format
Hi! I noticed that git produces differing output for git show --pretty:format show and git show --format, even though the man page says that both are equivalent. git show --format always appends an empty line at the end. The only way I've found to get rid of that empty line in --format is by adding -s option. So, git show --pretty:format and git show -s --format do produce the same output. I can reproduce this issue in Ubuntu Trusty (git version 1.9.1) and Debian Jessie (git version 2.1.4). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5539 broken under Mac OS X
Kyle J. McKay mack...@gmail.com writes:
I ran into this problem. It seems like (at least on older Mac OS X)
that the root directory is created like so:
drwxrwxr-t 39 root admin /
And since the first (and likely only user) on Mac OS X is a member of
the admin group, the SANITY test fails and complains even though
you're not running as root (the failure message is misleading).
The design choice Mac OS X makes around filesystems may deserve the
!SANITY label ;-) but we may want to tighten the check for SANITY,
or better yet, rethink the interaction between POSIXPERM and SANITY.
What we want to express with SANITY is:
On this system, if the user who is running the test
does not have write permission to a file, write to such a
file would fail.
So running our tests as a non-root admin user should be labeled as
being sane. We just use a more expedient if you can write into the
root directory, you must be root, asit is crazy to allow non-root
user to 'mv /etc /foo mkdir /etc write /etc/passwd'
heuristics which is old-school.
This should not be the final patch (I think it should become a lazy
prereq as it does a lot more), but just for testing, how does this
look?
t/test-lib.sh | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bb1402d..cdafab5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1033,7 +1033,16 @@ test_lazy_prereq USR_BIN_TIME '
# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
-test -w / || test_set_prereq SANITY
+if test_have_prereq POSIXPERM
+ ! test -w /
+ sanitytest
+ chmod a= sanitytest
+ ! (sanitytest) 2/dev/null
+ chmod +w sanitytest
+ rm -f sanitytest
+then
+ test_set_prereq SANITY
+fi
GIT_UNZIP=${GIT_UNZIP:-unzip}
test_lazy_prereq UNZIP '
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t5543, atomic pushes: test deleting and renaming branches
Add more test coverage to the atomic push option. It turns out there is a
breakage when renaming branches within an atomic push. The breakage occurs
because it cannot lock the refs v/v as well as x.
Signed-off-by: Stefan Beller sbel...@google.com
---
t/t5543-atomic-push.sh | 49 +
1 file changed, 49 insertions(+)
diff --git a/t/t5543-atomic-push.sh b/t/t5543-atomic-push.sh
index 3480b33..96a106b 100755
--- a/t/t5543-atomic-push.sh
+++ b/t/t5543-atomic-push.sh
@@ -191,4 +191,53 @@ test_expect_success 'atomic push is not advertised if
configured' '
test_refs master HEAD@{1}
'
+test_expect_success 'atomic push handles deletes gracefully' '
+ mk_repo_pair
+ (
+ cd workbench
+ git checkout -b todelete
+ test_commit one
+ git push --mirror up
+ )
+ (
+ cd workbench
+ git checkout -b anotherbranch
+ git branch -D todelete
+ git push --mirror --atomic up
+ )
+'
+
+test_expect_failure 'atomic push handles renames gracefully' '
+ # First push to upstream having the following branches:
+ # v, x/x, x/y and y/z. Now rename them and push atomically:
+ # v - v/v (1)
+ # x/x - x (2)
+ # x/y - y (3)
+ # y/z - z (4)
+ # (1) and (2) test (directory/file) conflicts on the branch itself. (3)
+ # is testing the (D/F) conflict with another branch involved which is
+ # freed in (4)
+ mk_repo_pair
+ (
+ cd workbench
+ git checkout -b v
+ test_commit one
+ git checkout -b x/x
+ test_commit two
+ git checkout -b x/y
+ test_commit three
+ git checkout -b y/z
+ test_commit four
+ git push --mirror up
+ )
+ (
+ cd workbench
+ git branch -m y/z z
+ git branch -m x/y y
+ git branch -m x/x x
+ git branch -m v v/v
+ git push --atomic up :v :x/x :x/y :y/z v/v x y z
+ )
+'
+
test_done
--
2.2.1.62.g3f15098
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit --amend --author error
Jeff King schrieb am 14.01.2015 um 13:09: On Tue, Jan 13, 2015 at 12:24:18PM +0100, Michael J Gruber wrote: Gunnar Wagner schrieb am 13.01.2015 um 09:15: I got APGL licensed code from someone else and want to post it on my github (without taking credit for the work) tried git commit --amend --author=Author name, www.website.com but got an error message which said something like original author not found Can it be that the --amen --author only work if the author is on github himself? This has nothing to do with github. The author has be in the form authorname authoremail. The important parts for the format are the . Yes, but the error message is a hint that there is something else going on. When there are no angle brackets, some DWIM magic kicks in: git tries to find a matching author by walking the project history from HEAD. So you can do (in git.git): $ git commit --allow-empty -m foo --author=gruber [detached HEAD 73ef08b] foo Author: Michael J Gruber g...@drmicha.warpmail.net (git commit --allow-almost-empty in the case of that author, hum) Of course that does not work if you do not already have commits from the person in your repository: $ git commit --allow-empty -m foo --author=foobar fatal: No existing author found with 'foobar' -Peff That is the full explanation, yes: Neither can Author name, www.website.com be parsed as a complete valid name email nor can it be matched as part of an existing name email in the repo. The OP clearly tried to do the first and got an error message about the second. Maybe we can do better here? Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] commit: reword --author error message
If an --author argument is specified but does not contain a '' then git tries to find the argument within the exiting authors; and gives the error message No existing author found with '%s' if there is no match. This is confusing for users who try to specify a valid complete author name. Rename the error message to make it clearer that the failure has two reasons in this case: Bad --author parameter '%s': neither completely wellformed nor part of an existing one (This codepath is touched only when we know already that the argument cannot be a completely wellformed author ident.) Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- builtin/commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 7d90c35..851e2c5 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1056,7 +1056,7 @@ static const char *find_author_by_nickname(const char *name) clear_mailmap(mailmap); return strbuf_detach(buf, NULL); } - die(_(No existing author found with '%s'), name); + die(_(Bad --author parameter '%s': neither completely wellformed nor part of an existing one), name); } -- 2.3.0.rc0.202.g6f441c7 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: reword --author error message
Michael J Gruber schrieb am 15.01.2015 um 15:23: If an --author argument is specified but does not contain a '' then git tries to find the argument within the exiting authors; and gives the error message No existing author found with '%s' if there is no match. Oh well, I'm bracing already for the comments on that entertaining typo... Can I buy an 's', please? This is confusing for users who try to specify a valid complete author name. Rename the error message to make it clearer that the failure has two reasons in this case: Bad --author parameter '%s': neither completely wellformed nor part of an existing one (This codepath is touched only when we know already that the argument cannot be a completely wellformed author ident.) Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- builtin/commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 7d90c35..851e2c5 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1056,7 +1056,7 @@ static const char *find_author_by_nickname(const char *name) clear_mailmap(mailmap); return strbuf_detach(buf, NULL); } - die(_(No existing author found with '%s'), name); + die(_(Bad --author parameter '%s': neither completely wellformed nor part of an existing one), name); } -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: reword --author error message
On Thu, Jan 15, 2015 at 03:23:08PM +0100, Michael J Gruber wrote: If an --author argument is specified but does not contain a '' then git tries to find the argument within the exiting authors; and gives the error message No existing author found with '%s' if there is no match. This is confusing for users who try to specify a valid complete author name. Rename the error message to make it clearer that the failure has two reasons in this case: Bad --author parameter '%s': neither completely wellformed nor part of an existing one I really like the intent of this patch, but I actually find the new message even more confusing. Is this a time when we could use hint() to give a multi-line explanation (and probably a matching advice.* config)? Like: hint: If the --author parameter contains angle brackets (), it hint: is treated as a literal name/email pair to use. If not, then hint: the history is searched for an existing matching author. or something? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On Thu, Jan 15, 2015 at 07:27:34PM -0800, Kyle J. McKay wrote: We implement NOT_ROOT by checking perl's $ variable, since we cannot rely on the id program being available everywhere (and we would rather avoid writing a custom C program to run geteuid if we can). Does it make a difference that id is POSIX [1]? I don't know. Do all of the platforms where we run http tests have it (and conforming to POSIX-ish options or output)? It may be OK to guess yes and see if anybody complains (the worst case is skipping http tests). id -u works for me in MSYS and cygwin (each appears to have it's own id.exe). That's comforting. MSYS was the one I was most worried about. What UID do they report? I.e., do they correctly tell us if we are root (or more accurately, if we are not root)? +test_lazy_prereq NOT_ROOT ' +uid=$(perl -e print \$) +test $uid != 0 +' Does NO_PERL affect this? Or is Perl always required to run the tests. No, we use a very limited subset of perl in our tests when necessary (basic enough that any perl5 will do), regardless of the NO_PERL setting. Also $ is real user id. Don't you want effective user id ($), that's what the comment says... Yeah, I bungled this initially and thought I fixed it, but clearly not. :-/ I'll re-roll, but if we can get away with id -u I think that's preferable. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
