[PATCH 5/4] rebase -i: suggest using --edit-todo to fix an unknown instruction
From: Johannes Sixt j...@kdbg.org
We have now an explicit UI to edit the todo sheet and need not disclose
the name of the file.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
git-rebase--interactive.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 2b8f2a9..4b2ef11 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -575,11 +575,12 @@ do_next () {
;;
*)
warn Unknown command: $command $sha1 $rest
+ fixtodo=Please fix this using 'git rebase --edit-todo'.
if git rev-parse --verify -q $sha1 /dev/null
then
- die_with_patch $sha1 Please fix this in the file
$todo.
+ die_with_patch $sha1 $fixtodo
else
- die Please fix this in the file $todo.
+ die $fixtodo
fi
;;
esac
--
1.7.12.1721.gd1d8b74
--
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: [PATCHv2 4/8] Doc: 'git' has a discussion section
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: Highlight there is a further discussion section later in git man page Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git.txt b/Documentation/git.txt index 34d8a1b..d932a3e 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -30,6 +30,7 @@ After you mastered the basic concepts, you can come back to this page to learn what commands git offers. You can learn more about individual git commands with git help command. linkgit:gitcli[7] manual page gives you an overview of the command line command syntax. +See also the Discussion and Further Documentation sections below. Formatted and hyperlinked version of the latest git documentation can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`. I am not sure if this is appropriate. The primary objective of this paragraph is to nudge people who try to dive into the body of this document without understanding the fundamentals (which tends to waste their time) without spending too many words. After they visit these pages, they are armed with sufficient prerequisite knowledge and are free to go directly to documentation for individual subcommands, and this page is one of such pages. I do not think Discussion and Further Documentation sections are such prerequisites they should read before coming back here and looking at the list of subcommands. It was more that _all_ man pages link back here, and these (hopefully useful ;-) Discussion and Further Documentation sections are waaay off the bottom of the screen, so are easy to never see. Actually I would have liked to make it an active link to the section for any html version, but wasn't sure how to achieve that - is there a method to link within a document? Philip -- 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] Support for HP NonStop
On Friday 2012-08-24 22:43, Joachim Schmitz wrote: By the way, is int wide enough [for intptr_t/uintptr_t], or should they be long? int and long have the same size, 32-bit, here on NonStop. But we do have 64-bit types too. Not sure which to take though. intptr_t is supposed to hold a void * pointer, so should be at least as big. -- 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
Add .editorconfig file to source repository to maintain a consistent coding style
Hi all, EditorConfig http://editorconfig.org is a project that helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems. EditorConfig has been used in many large and famous projects, such as Ruby, jQuery, etc. I think the Git community may also find it useful, since there are some inconsistent indentation in the source code. What do you think about this? Best, Hong-- 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 API: document what sorted means.
On 09/18/2012 07:21 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: If another sort order is needed, then we will either have to audit existing string_list users to make sure that they don't rely on strcmp() ordering, or we will have to implement strcmp() ordering *plus* the new ordering. What I was envisioning was to pass in an optional custom comparison when you instantiate a string_list object. Existing callers that rely on (or can live with, because they do not care about the exact order) the default order will continue to use the byte-value ordering, so there is no need for auditing. Only the new callers that want different ordering would set custom comparison routine. But now I wrote it down, I realize that there is no _harm_ in documenting we sort in byte-value order, so expect iterations on sorted string list to give them in that order to you at all. So let's go with your documentation patch as-is. It's not that I'm unwilling to implement 2; it's just that I still don't see any advantage to doing so before there is a demonstrated need for it. As I said, I have this suspicion that the lack of demonstrated need is largely because the existing code that do _not_ use string-list don't do so because the interface is limited, so the argument is sort of self-fulfilling. I've been looking for places in the code where string_list can be used, so hopefully I'll get a feeling for what new functionality will increase its applicability. Now that my string_list enhancements are in master, I will start trickling in patches to convert other code to using string_list when it seems to benefit code length and/or understandability. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: [PATCHv6] clone --single: limit the fetch refspec to fetched branch
On Wed, Sep 19, 2012 at 2:14 AM, Ralf Thielow ralf.thie...@gmail.com wrote: +test_expect_success '--single-branch with explicit --branch tag' ' + ( + cd dir_tag git fetch + git for-each-ref refs/tags ../actual + ) + git for-each-ref refs/tags expect + test_cmp expect actual +' We should have added the tag right after cloning, not until the first git-fetch. Not that I object how you do it in this patch. Just a note to myself that if I'm going to do that, I'll need to update this test to update the change tag before fetching and verify the tag is updated after git-fetch. -- Duy -- 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] Support for HP NonStop
From: Jan Engelhardt [mailto:jeng...@inai.de] Sent: Wednesday, September 19, 2012 9:24 AM To: Joachim Schmitz Cc: 'Junio C Hamano'; git@vger.kernel.org Subject: RE: [RFC] Support for HP NonStop On Friday 2012-08-24 22:43, Joachim Schmitz wrote: By the way, is int wide enough [for intptr_t/uintptr_t], or should they be long? int and long have the same size, 32-bit, here on NonStop. But we do have 64-bit types too. Not sure which to take though. intptr_t is supposed to hold a void * pointer, so should be at least as big. OK, thanks. We are on IA64 but still use the ILP32 model (so 32bit pointers. Support for LP64 has been added recently, but isn't the default. However, long changes from 32bit to 64 bit when changing from ILP32 to LP64, so is the save bet here, right? -- 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: [PATCHv6] clone --single: limit the fetch refspec to fetched branch
On Wed, Sep 19, 2012 at 9:36 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Wed, Sep 19, 2012 at 2:14 AM, Ralf Thielow ralf.thie...@gmail.com wrote: +test_expect_success '--single-branch with explicit --branch tag' ' + ( + cd dir_tag git fetch + git for-each-ref refs/tags ../actual + ) + git for-each-ref refs/tags expect + test_cmp expect actual +' We should have added the tag right after cloning, not until the first git-fetch. Not that I object how you do it in this patch. Just a note to myself that if I'm going to do that, I'll need to update this test to update the change tag before fetching and verify the tag is updated after git-fetch. -- Duy Right. I'll create two tests to replace this one. The first test verifys that the tag has been added after cloning. And in the second test, the tag gets updated in the cloned repository and we verify that the next fetch updates the tag, which catches my delivery tag example. -- 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] gitk: Synchronize highlighting in file view when scrolling diff
Whenever the diff pane scrolls, highlight the corresponding file in the
file list on the right. For a large commit with many files and long
per-file diffs, this makes it easier to keep track of what you're looking
at.
This allows simplifying the prevfile and nextfile functions, because
all they have to do is scroll the diff pane.
Signed-off-by: Stefan Haller ste...@haller-berlin.de
---
The only change from v1 is the addition of the $difffilestart eq {}
condition, this should fix the flickering problem reported by Peter.
I didn't do anything about the search problem yet, will look into this
next. (Personally though, I think this is acceptable the way it is.)
gitk | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/gitk b/gitk
index d93bd99..8095806 100755
--- a/gitk
+++ b/gitk
@@ -7947,10 +7947,9 @@ proc changediffdisp {} {
$ctext tag conf dresult -elide [lindex $diffelide 1]
}
-proc highlightfile {loc cline} {
-global ctext cflist cflist_top
+proc highlightfile {cline} {
+global cflist cflist_top
-$ctext yview $loc
$cflist tag remove highlight $cflist_top.0 $cflist_top.0 lineend
$cflist tag add highlight $cline.0 $cline.0 lineend
$cflist see $cline.0
@@ -7962,17 +7961,15 @@ proc prevfile {} {
if {$cmitmode eq tree} return
set prev 0.0
-set prevline 1
set here [$ctext index @0,0]
foreach loc $difffilestart {
if {[$ctext compare $loc = $here]} {
- highlightfile $prev $prevline
+ $ctext yview $prev
return
}
set prev $loc
- incr prevline
}
-highlightfile $prev $prevline
+$ctext yview $prev
}
proc nextfile {} {
@@ -7980,11 +7977,9 @@ proc nextfile {} {
if {$cmitmode eq tree} return
set here [$ctext index @0,0]
-set line 1
foreach loc $difffilestart {
- incr line
if {[$ctext compare $loc $here]} {
- highlightfile $loc $line
+ $ctext yview $loc
return
}
}
@@ -8138,7 +8133,17 @@ proc searchmarkvisible {doall} {
}
proc scrolltext {f0 f1} {
-global searchstring
+global searchstring cmitmode
+global ctext cflist cflist_top difffilestart
+
+if {$cmitmode ne tree [info exists difffilestart]} {
+ set top [lindex [split [$ctext index @0,0] .] 0]
+ if {$difffilestart eq {} || $top [lindex $difffilestart 0]} {
+ highlightfile 0
+ } else {
+ highlightfile [expr {[bsearch $difffilestart $top] + 2}]
+ }
+}
.bleft.bottom.sb set $f0 $f1
if {$searchstring ne {}} {
--
1.7.12.517.g4c1112f
--
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] Port to HP NonStop
Includes the addition of some new defines and their description for others to
use.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
This needs my 4 compat-poll patches posted earlier, which are in pu currently
Makefile | 67 +++
git-compat-util.h | 17 +-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e022fc4..3823968 100644
--- a/Makefile
+++ b/Makefile
@@ -145,6 +145,12 @@ all::
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
#
+# Define NEEDS_LIBINTL_BEFORE_LIBICONV if you need libintl before libiconv.
+#
+# Define NO_INTPTR_T if you don't have intptr_t nor uintptr_t.
+#
+# Define NO_UINTMAX_T if you don't have uintmax_t.
+#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
#
@@ -1327,6 +1333,61 @@ ifeq ($(uname_S),Minix)
NO_CURL =
NO_EXPAT =
endif
+ifeq ($(uname_S),NONSTOP_KERNEL)
+ # Needs some C99 features, inline is just one of them.
+ # INLINE='' would just replace one set of warnings with another and
+ # still not compile in c89 mode, due to non-const array initializations.
+ CC = cc -c99
+ # Disable all optimization, seems to result in bad code, with -O or -O2
+ # or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
+ # abends on git push. Needs more investigation.
+ CFLAGS = -g -O0
+ # We'd want it to be here.
+ prefix = /usr/local
+ # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
+ PERL_PATH = ${prefix}/bin/perl
+ PYTHON_PATH = ${prefix}/bin/python
+
+ # As detected by './configure'.
+ # Missdetected, hence commented out, see below.
+ #NO_CURL = YesPlease
+ # Added manually, see above.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ HAVE_LIBCHARSET_H = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
+ NO_SYS_SELECT_H = UnfortunatelyYes
+ NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_HSTRERROR = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ # Currently libiconv-1.9.1.
+ OLD_ICONV = UnfortunatelyYes
+ NO_REGEX = YesPlease
+ NO_PTHREADS = UnfortunatelyYes
+
+ # Not detected (nor checked for) by './configure'.
+ # We don't have SA_RESTART on NonStop, unfortunalety.
+ COMPAT_CFLAGS += -DSA_RESTART=0
+ # Apparently needed in compat/fnmatch/fnmatch.c.
+ COMPAT_CFLAGS += -DHAVE_STRING_H=1
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ NO_PREAD = YesPlease
+ NO_MMAP = YesPlease
+ NO_POLL = YesPlease
+ NO_INTPTR_T = UnfortunatelyYes
+ # Bug report 10-120822-4477 submitted to HP NonStop development.
+ MKDIR_WO_TRAILING_SLASH = YesPlease
+ # RFE 10-120912-4693 submitted to HP NonStop development.
+ NO_SETITIMER = UnfortunatelyYes
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
@@ -1563,6 +1624,9 @@ ifdef NEEDS_LIBICONV
else
ICONV_LINK =
endif
+ ifdef NEEDS_LIBINTL_BEFORE_LIBICONV
+ ICONV_LINK += -lintl
+ endif
EXTLIBS += $(ICONV_LINK) -liconv
endif
ifdef NEEDS_LIBGEN
@@ -1723,6 +1787,9 @@ endif
ifdef NO_IPV6
BASIC_CFLAGS += -DNO_IPV6
endif
+ifdef NO_INTPTR_T
+ COMPAT_CFLAGS += -DNO_INTPTR_T
+endif
ifdef NO_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t=uint32_t
endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 24b5432..2fbf1fd 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -74,7 +74,8 @@
# define _XOPEN_SOURCE 500
# endif
#elif !defined(__APPLE__) !defined(__FreeBSD__) !defined(__USLC__) \
- !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__)
+ !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__) \
+ !defined(__TANDEM)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600
for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
@@ -98,6 +99,9 @@
#include stdlib.h
#include stdarg.h
#include string.h
+#ifdef __TANDEM /* or HAVE_STRINGS_H or !NO_STRINGS_H? */
+#include strings.h /* for strcasecmp() */
+#endif
#include errno.h
#include limits.h
#include sys/param.h
@@ -141,6 +145,17 @@
#else
#include stdint.h
#endif
+#ifdef NO_INTPTR_T
+/*
+ * On I16LP32, ILP32 and LP64 long is the save bet, however
+ * on LLP86, IL33LLP64 and P64 it needs to be long long,
+ * while on IP16 and IP16L32 it is int (resp. short)
+ * Size needs to match (or exceed) 'sizeof(void *)'.
+ * We can't take long long here as not everybody
Changes to ignore patterns in version 1.7.12.1?
Hi, I have the following ignore pattern in my .gitignore */auto/ to ignore the auto directories generated by emacs in the root and also in subdirectories. I just installed version 1.7.12.1 and know the top auto/ directory is not ignored anymore, but lower ones are. Did the ignore patterns change in this version? Thanks and best regards, Björn -- 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: Changes to ignore patterns in version 1.7.12.1?
On Wed, Sep 19, 2012 at 6:44 PM, Björn Steffen bjoern.stef...@inf.ethz.ch wrote: Hi, I have the following ignore pattern in my .gitignore */auto/ to ignore the auto directories generated by emacs in the root and also in subdirectories. I just installed version 1.7.12.1 and know the top auto/ directory is not ignored anymore, but lower ones are. What version works for you? I don't think that pattern should match the top auto though. I tried with a few git versions back to 1.7.0 but I don't see any differences. Maybe you could demonstrate that with a few commands? -- Duy -- 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: Changes to ignore patterns in version 1.7.12.1?
Hi Duy, What version works for you? I don't think that pattern should match the top auto though. I tried with a few git versions back to 1.7.0 but I don't see any differences. Maybe you could demonstrate that with a few commands? I went back to version 1.7.12 and the top auto directory was still visible. So it must have been something different or I was doing something wrong. So nevermind. Sorry. I guess I'll have to use both patterns to ignore all auto directories: auto/ */auto/ Thanks anyway, Björn -- 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: The GitTogether
On 07/27/2012 12:28 AM, Scott Chacon wrote: [...] I would like to see two different gatherings this year - one that would be user-centric to gather people that use Git together with some of the developers and talk about Git from a user's perspective. The other event I would like to see would be a gathering of many of the core Git developers in a sort of hacker summit. GitHub would like to volunteer to organize and pay for these events this year. I would like to hold the developer-centric one in Berlin in early October (a few weeks before the Mentor Summit this time) and the user one in January or February of next year. [...] Is there any news about the proposed gatherings? I would be quite interested in attending the developer meeting. October is just around the corner...what's up? Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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] gitk: Synchronize highlighting in file view when scrolling diff
On 12-09-18 07:46 PM, Paul Mackerras wrote: On Tue, Sep 18, 2012 at 07:57:54AM +0200, Stefan Haller wrote: Whenever the diff pane scrolls, highlight the corresponding file in the file list on the right. For a large commit with many files and long per-file diffs, this makes it easier to keep track of what you're looking at. I like this as far as it goes, but the one criticism I would have is that when you find a string (using the Search button), the filename that gets highlighted is often not the file in which the string was found (because the highlighting is based on the top line visible in the text window), which could be confusing. Well, gitk currently doesn't highlight the matching file (or files -- there can be more than one). Stefan's patch isn't changing anything with how string matching already works. Can you think of a way to solve that too? Perhaps make the highlighting based on the currently highlighted instance of the search string, if there is one, otherwise based on the top line visible? I think you're asking for a new feature. Highlight-files-with-string-matches is different from Stefan's consistently-highlight-currently-displayed-file, so it should be done differently. Perhaps use a different highlight colour, or overlay the matching files with an icon. M. -- 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 v8 01/16] Implement a remote helper for svn in C
Enable basic fetching from subversion repositories. When processing
remote URLs starting with testsvn::, git invokes this remote-helper.
It starts svnrdump to extract revisions from the subversion repository
in the 'dump file format', and converts them to a git-fast-import stream
using the functions of vcs-svn/.
Imported refs are created in a private namespace at
refs/svn/remote-name/master. The revision history is imported
linearly (no branch detection) and completely, i.e. from revision 0 to
HEAD.
The 'bidi-import' capability is used. The remote-helper expects data
from fast-import on its stdin. It buffers a batch of 'import' command
lines in a string_list before starting to process them.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff:
- style
- use seperate strbufs instead of sharing one in main.
remote-testsvn.c | 176 ++
1 file changed, 176 insertions(+)
create mode 100644 remote-testsvn.c
diff --git a/remote-testsvn.c b/remote-testsvn.c
new file mode 100644
index 000..c30ffcd
--- /dev/null
+++ b/remote-testsvn.c
@@ -0,0 +1,176 @@
+#include cache.h
+#include remote.h
+#include strbuf.h
+#include url.h
+#include exec_cmd.h
+#include run-command.h
+#include vcs-svn/svndump.h
+#include notes.h
+#include argv-array.h
+
+static const char *url;
+static const char *private_ref;
+static const char *remote_ref = refs/heads/master;
+
+static int cmd_capabilities(const char *line);
+static int cmd_import(const char *line);
+static int cmd_list(const char *line);
+
+typedef int (*input_command_handler)(const char *);
+struct input_command_entry {
+ const char *name;
+ input_command_handler fn;
+ unsigned char batchable;/* whether the command starts or is
part of a batch */
+};
+
+static const struct input_command_entry input_command_list[] = {
+ { capabilities, cmd_capabilities, 0 },
+ { import, cmd_import, 1 },
+ { list, cmd_list, 0 },
+ { NULL, NULL }
+};
+
+static int cmd_capabilities(const char *line)
+{
+ printf(import\n);
+ printf(bidi-import\n);
+ printf(refspec %s:%s\n\n, remote_ref, private_ref);
+ fflush(stdout);
+ return 0;
+}
+
+static void terminate_batch(void)
+{
+ /* terminate a current batch's fast-import stream */
+ printf(done\n);
+ fflush(stdout);
+}
+
+static int cmd_import(const char *line)
+{
+ int code;
+ int dumpin_fd;
+ unsigned int startrev = 0;
+ struct argv_array svndump_argv = ARGV_ARRAY_INIT;
+ struct child_process svndump_proc;
+
+ memset(svndump_proc, 0, sizeof(struct child_process));
+ svndump_proc.out = -1;
+ argv_array_push(svndump_argv, svnrdump);
+ argv_array_push(svndump_argv, dump);
+ argv_array_push(svndump_argv, url);
+ argv_array_pushf(svndump_argv, -r%u:HEAD, startrev);
+ svndump_proc.argv = svndump_argv.argv;
+
+ code = start_command(svndump_proc);
+ if (code)
+ die(Unable to start %s, code %d, svndump_proc.argv[0], code);
+ dumpin_fd = svndump_proc.out;
+
+ svndump_init_fd(dumpin_fd, STDIN_FILENO);
+ svndump_read(url, private_ref);
+ svndump_deinit();
+ svndump_reset();
+
+ close(dumpin_fd);
+ code = finish_command(svndump_proc);
+ if (code)
+ warning(%s, returned %d, svndump_proc.argv[0], code);
+ argv_array_clear(svndump_argv);
+
+ return 0;
+}
+
+static int cmd_list(const char *line)
+{
+ printf(? %s\n\n, remote_ref);
+ fflush(stdout);
+ return 0;
+}
+
+static int do_command(struct strbuf *line)
+{
+ const struct input_command_entry *p = input_command_list;
+ static struct string_list batchlines = STRING_LIST_INIT_DUP;
+ static const struct input_command_entry *batch_cmd;
+ /*
+* commands can be grouped together in a batch.
+* Batches are ended by \n. If no batch is active the program ends.
+* During a batch all lines are buffered and passed to the handler
function
+* when the batch is terminated.
+*/
+ if (line-len == 0) {
+ if (batch_cmd) {
+ struct string_list_item *item;
+ for_each_string_list_item(item, batchlines)
+ batch_cmd-fn(item-string);
+ terminate_batch();
+ batch_cmd = NULL;
+ string_list_clear(batchlines, 0);
+ return 0; /* end of the batch, continue reading
other commands. */
+ }
+ return 1; /* end of command stream, quit */
+ }
+ if (batch_cmd) {
+ if (prefixcmp(batch_cmd-name, line-buf))
+ die(Active %s batch interrupted by %s,
batch_cmd-name, line-buf);
+ /* buffer batch
[PATCH v8 06/16] Add documentation for the 'bidi-import' capability of remote-helpers
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- no diff Documentation/git-remote-helpers.txt | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index f5836e4..5ce4cda 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -98,6 +98,20 @@ advertised with this capability must cover all refs reported by the list command. If no 'refspec' capability is advertised, there is an implied `refspec *:*`. +'bidi-import':: + The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers + to retrieve information about blobs and trees that already exist in + fast-import's memory. This requires a channel from fast-import to the + remote-helper. + If it is advertised in addition to import, git establishes a pipe from + fast-import to the remote-helper's stdin. + It follows that git and fast-import are both connected to the + remote-helper's stdin. Because git can send multiple commands to + the remote-helper it is required that helpers that use 'bidi-import' + buffer all 'import' commands of a batch before sending data to fast-import. + This is to prevent mixing commands and fast-import responses on the + helper's stdin. + Capabilities for Pushing 'connect':: @@ -286,7 +300,12 @@ terminated with a blank line. For each batch of 'import', the remote helper should produce a fast-import stream terminated by a 'done' command. + -Supported if the helper has the import capability. +Note that if the 'bidi-import' capability is used the complete batch +sequence has to be buffered before starting to send data to fast-import +to prevent mixing of commands and fast-import responses on the helper's +stdin. ++ +Supported if the helper has the 'import' capability. 'connect' service:: Connects to given service. Standard input and standard output -- 1.7.9.5 -- 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 v8 08/16] remote-svn, vcs-svn: Enable fetching to private refs
The reference to update by the fast-import stream is hard-coded. When
fetching from a remote the remote-helper shall update refs in a
private namespace, i.e. a private subdir of refs/. This namespace is
defined by the 'refspec' capability, that the remote-helper advertises
as a reply to the 'capabilities' command.
Extend svndump and fast-export to allow passing the target ref.
Update svn-fe to be compatible.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff:
- remove glitch in function declaration.
contrib/svn-fe/svn-fe.c |2 +-
test-svn-fe.c |2 +-
vcs-svn/fast_export.c |4 ++--
vcs-svn/fast_export.h |2 +-
vcs-svn/svndump.c | 12 ++--
vcs-svn/svndump.h |2 +-
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/contrib/svn-fe/svn-fe.c b/contrib/svn-fe/svn-fe.c
index 35db24f..c796cc0 100644
--- a/contrib/svn-fe/svn-fe.c
+++ b/contrib/svn-fe/svn-fe.c
@@ -10,7 +10,7 @@ int main(int argc, char **argv)
{
if (svndump_init(NULL))
return 1;
- svndump_read((argc 1) ? argv[1] : NULL);
+ svndump_read((argc 1) ? argv[1] : NULL, refs/heads/master);
svndump_deinit();
svndump_reset();
return 0;
diff --git a/test-svn-fe.c b/test-svn-fe.c
index 83633a2..cb0d80f 100644
--- a/test-svn-fe.c
+++ b/test-svn-fe.c
@@ -40,7 +40,7 @@ int main(int argc, char *argv[])
if (argc == 2) {
if (svndump_init(argv[1]))
return 1;
- svndump_read(NULL);
+ svndump_read(NULL, refs/heads/master);
svndump_deinit();
svndump_reset();
return 0;
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index 1f04697..11f8f94 100644
--- a/vcs-svn/fast_export.c
+++ b/vcs-svn/fast_export.c
@@ -72,7 +72,7 @@ static char gitsvnline[MAX_GITSVN_LINE_LEN];
void fast_export_begin_commit(uint32_t revision, const char *author,
const struct strbuf *log,
const char *uuid, const char *url,
- unsigned long timestamp)
+ unsigned long timestamp, const char *local_ref)
{
static const struct strbuf empty = STRBUF_INIT;
if (!log)
@@ -84,7 +84,7 @@ void fast_export_begin_commit(uint32_t revision, const char
*author,
} else {
*gitsvnline = '\0';
}
- printf(commit refs/heads/master\n);
+ printf(commit %s\n, local_ref);
printf(mark :%PRIu32\n, revision);
printf(committer %s %s@%s %ld +\n,
*author ? author : nobody,
diff --git a/vcs-svn/fast_export.h b/vcs-svn/fast_export.h
index 8823aca..17eb13b 100644
--- a/vcs-svn/fast_export.h
+++ b/vcs-svn/fast_export.h
@@ -11,7 +11,7 @@ void fast_export_delete(const char *path);
void fast_export_modify(const char *path, uint32_t mode, const char *dataref);
void fast_export_begin_commit(uint32_t revision, const char *author,
const struct strbuf *log, const char *uuid,
- const char *url, unsigned long timestamp);
+ const char *url, unsigned long timestamp, const char
*local_ref);
void fast_export_end_commit(uint32_t revision);
void fast_export_data(uint32_t mode, off_t len, struct line_buffer *input);
void fast_export_blob_delta(uint32_t mode,
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index d81a078..c8a5b7e 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -299,13 +299,13 @@ static void handle_node(void)
node_ctx.text_length, input);
}
-static void begin_revision(void)
+static void begin_revision(const char *remote_ref)
{
if (!rev_ctx.revision) /* revision 0 gets no git commit. */
return;
fast_export_begin_commit(rev_ctx.revision, rev_ctx.author.buf,
rev_ctx.log, dump_ctx.uuid.buf, dump_ctx.url.buf,
- rev_ctx.timestamp);
+ rev_ctx.timestamp, remote_ref);
}
static void end_revision(void)
@@ -314,7 +314,7 @@ static void end_revision(void)
fast_export_end_commit(rev_ctx.revision);
}
-void svndump_read(const char *url)
+void svndump_read(const char *url, const char *local_ref)
{
char *val;
char *t;
@@ -353,7 +353,7 @@ void svndump_read(const char *url)
if (active_ctx == NODE_CTX)
handle_node();
if (active_ctx == REV_CTX)
- begin_revision();
+ begin_revision(local_ref);
if (active_ctx != DUMP_CTX)
end_revision();
active_ctx = REV_CTX;
@@ -366,7 +366,7 @@ void svndump_read(const char *url)
if (active_ctx == NODE_CTX)
[PATCH v8 11/16] Create a note for every imported commit containing svn metadata
To provide metadata from svn dumps for further processing, e.g.
branch detection, attach a note to each imported commit that stores
additional information. The notes are currently hard-coded in
refs/notes/svn/revs. Currently the following lines from the svn dump
are directly accumulated in the note. This can be refined as needed.
- Revision-number
- Node-path
- Node-kind
- Node-action
- Node-copyfrom-path
- Node-copyfrom-rev
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
vcs-svn/fast_export.c | 14 --
vcs-svn/fast_export.h |2 ++
vcs-svn/svndump.c | 21 +++--
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index 1ecae4b..df51c59 100644
--- a/vcs-svn/fast_export.c
+++ b/vcs-svn/fast_export.c
@@ -3,8 +3,7 @@
* See LICENSE for details.
*/
-#include git-compat-util.h
-#include strbuf.h
+#include cache.h
#include quote.h
#include fast_export.h
#include repo_tree.h
@@ -68,6 +67,17 @@ void fast_export_modify(const char *path, uint32_t mode,
const char *dataref)
putchar('\n');
}
+void fast_export_begin_note(uint32_t revision, const char *author,
+ const char *log, unsigned long timestamp)
+{
+ size_t loglen = strlen(log);
+ printf(commit refs/notes/svn/revs\n);
+ printf(committer %s %s@%s %ld +\n, author, author, local,
timestamp);
+ printf(data %PRIuMAX\n, (uintmax_t)loglen);
+ fwrite(log, loglen, 1, stdout);
+ fputc('\n', stdout);
+}
+
void fast_export_note(const char *committish, const char *dataref)
{
printf(N %s %s\n, dataref, committish);
diff --git a/vcs-svn/fast_export.h b/vcs-svn/fast_export.h
index 9b32f1e..c2f6f11 100644
--- a/vcs-svn/fast_export.h
+++ b/vcs-svn/fast_export.h
@@ -10,6 +10,8 @@ void fast_export_deinit(void);
void fast_export_delete(const char *path);
void fast_export_modify(const char *path, uint32_t mode, const char *dataref);
void fast_export_note(const char *committish, const char *dataref);
+void fast_export_begin_note(uint32_t revision, const char *author,
+ const char *log, unsigned long timestamp);
void fast_export_begin_commit(uint32_t revision, const char *author,
const struct strbuf *log, const char *uuid,
const char *url, unsigned long timestamp, const char
*local_ref);
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index c8a5b7e..7ec1a5b 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -48,7 +48,7 @@ static struct {
static struct {
uint32_t revision;
unsigned long timestamp;
- struct strbuf log, author;
+ struct strbuf log, author, note;
} rev_ctx;
static struct {
@@ -77,6 +77,7 @@ static void reset_rev_ctx(uint32_t revision)
rev_ctx.timestamp = 0;
strbuf_reset(rev_ctx.log);
strbuf_reset(rev_ctx.author);
+ strbuf_reset(rev_ctx.note);
}
static void reset_dump_ctx(const char *url)
@@ -310,8 +311,15 @@ static void begin_revision(const char *remote_ref)
static void end_revision(void)
{
- if (rev_ctx.revision)
+ struct strbuf mark = STRBUF_INIT;
+ if (rev_ctx.revision) {
fast_export_end_commit(rev_ctx.revision);
+ fast_export_begin_note(rev_ctx.revision, remote-svn,
+ Note created by remote-svn.,
rev_ctx.timestamp);
+ strbuf_addf(mark, :%PRIu32, rev_ctx.revision);
+ fast_export_note(mark.buf, inline);
+ fast_export_buf_to_data(rev_ctx.note);
+ }
}
void svndump_read(const char *url, const char *local_ref)
@@ -358,6 +366,7 @@ void svndump_read(const char *url, const char *local_ref)
end_revision();
active_ctx = REV_CTX;
reset_rev_ctx(atoi(val));
+ strbuf_addf(rev_ctx.note, %s\n, t);
break;
case sizeof(Node-path):
if (constcmp(t, Node-))
@@ -369,10 +378,12 @@ void svndump_read(const char *url, const char *local_ref)
begin_revision(local_ref);
active_ctx = NODE_CTX;
reset_node_ctx(val);
+ strbuf_addf(rev_ctx.note, %s\n, t);
break;
}
if (constcmp(t + strlen(Node-), kind))
continue;
+ strbuf_addf(rev_ctx.note, %s\n, t);
if (!strcmp(val, dir))
node_ctx.type = REPO_MODE_DIR;
else if (!strcmp(val, file))
@@ -383,6 +394,7 @@ void svndump_read(const char *url, const char *local_ref)
case sizeof(Node-action):
[PATCH v8 13/16] remote-svn: add incremental import
Search for a note attached to the ref to update and read it's
'Revision-number:'-line. Start import from the next svn revision.
If there is no next revision in the svn repo, svnrdump terminates with
a message on stderr an non-zero return value. This looks a little
weird, but there is no other way to know whether there is a new
revision in the svn repo.
On the start of an incremental import, the parent of the first commit
in the fast-import stream is set to the branch name to update. All
following commits specify their parent by a mark number. Previous mark
files are currently not reused.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff:
- style
- improve error detection while reading notes
- strtol instead of atol
- seperate strbufs in main
contrib/svn-fe/svn-fe.c |3 +-
remote-testsvn.c| 79 ---
test-svn-fe.c |2 +-
vcs-svn/fast_export.c | 10 --
vcs-svn/fast_export.h |6 ++--
vcs-svn/svndump.c | 10 +++---
vcs-svn/svndump.h |2 +-
7 files changed, 95 insertions(+), 17 deletions(-)
diff --git a/contrib/svn-fe/svn-fe.c b/contrib/svn-fe/svn-fe.c
index c796cc0..f363505 100644
--- a/contrib/svn-fe/svn-fe.c
+++ b/contrib/svn-fe/svn-fe.c
@@ -10,7 +10,8 @@ int main(int argc, char **argv)
{
if (svndump_init(NULL))
return 1;
- svndump_read((argc 1) ? argv[1] : NULL, refs/heads/master);
+ svndump_read((argc 1) ? argv[1] : NULL, refs/heads/master,
+ refs/notes/svn/revs);
svndump_deinit();
svndump_reset();
return 0;
diff --git a/remote-testsvn.c b/remote-testsvn.c
index 45eba9f..b741f6d 100644
--- a/remote-testsvn.c
+++ b/remote-testsvn.c
@@ -12,7 +12,8 @@ static const char *url;
static int dump_from_file;
static const char *private_ref;
static const char *remote_ref = refs/heads/master;
-static const char *marksfilename;
+static const char *marksfilename, *notes_ref;
+struct rev_note { unsigned int rev_nr; };
static int cmd_capabilities(const char *line);
static int cmd_import(const char *line);
@@ -48,14 +49,79 @@ static void terminate_batch(void)
fflush(stdout);
}
+/* NOTE: 'ref' refers to a git reference, while 'rev' refers to a svn
revision. */
+static char *read_ref_note(const unsigned char sha1[20])
+{
+ const unsigned char *note_sha1;
+ char *msg = NULL;
+ unsigned long msglen;
+ enum object_type type;
+
+ init_notes(NULL, notes_ref, NULL, 0);
+ if (!(note_sha1 = get_note(NULL, sha1)))
+ return NULL;/* note tree not found */
+ if (!(msg = read_sha1_file(note_sha1, type, msglen)))
+ error(Empty notes tree. %s, notes_ref);
+ else if (!msglen || type != OBJ_BLOB) {
+ error(Note contains unusable content.
+ Is something else using this notes tree? %s,
notes_ref);
+ free(msg);
+ msg = NULL;
+ }
+ free_notes(NULL);
+ return msg;
+}
+
+static int parse_rev_note(const char *msg, struct rev_note *res)
+{
+ const char *key, *value, *end;
+ size_t len;
+
+ while (*msg) {
+ end = strchr(msg, '\n');
+ len = end ? end - msg : strlen(msg);
+
+ key = Revision-number: ;
+ if (!prefixcmp(msg, key)) {
+ long i;
+ char *end;
+ value = msg + strlen(key);
+ i = strtol(value, end, 0);
+ if (end == value || i 0 || i UINT32_MAX)
+ return -1;
+ res-rev_nr = i;
+ }
+ msg += len + 1;
+ }
+ return 0;
+}
+
static int cmd_import(const char *line)
{
int code;
int dumpin_fd;
- unsigned int startrev = 0;
+ char *note_msg;
+ unsigned char head_sha1[20];
+ unsigned int startrev;
struct argv_array svndump_argv = ARGV_ARRAY_INIT;
struct child_process svndump_proc;
+ if (read_ref(private_ref, head_sha1))
+ startrev = 0;
+ else {
+ note_msg = read_ref_note(head_sha1);
+ if(note_msg == NULL) {
+ warning(No note found for %s., private_ref);
+ startrev = 0;
+ } else {
+ struct rev_note note = { 0 };
+ if (parse_rev_note(note_msg, note))
+ die(Revision number couldn't be parsed from
note.);
+ startrev = note.rev_nr + 1;
+ free(note_msg);
+ }
+ }
+
if (dump_from_file) {
dumpin_fd = open(url, O_RDONLY);
if(dumpin_fd 0)
@@ -79,7 +145,7 @@ static int cmd_import(const char *line)
Re: t1450-fsck (sometimes/often) failes on Mac OS X
On 07/15/2012 11:08 AM, Jeff King wrote: On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote: I saw the problem first on pu, some time ago, but it dissappeared after cloning git.git into another directory. Now it appeared on next as well, so it's time to look a little bit deeper. This test case of t1450 fails: test_expect_success 'tag pointing to something else than its type' ' I can't reproduce this failure; I tried both pu or next, on Linux and OS X (10.7). Linux: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object Mac OS X: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing That seems very broken. That sha1 can have only one type, so OS X is actually mis-parsing the object type? Weird. I would suggest a memory error or race condition, but the test is valgrind-clean, and fsck should not be threaded at all. What does git show 63499e4 show when the test has failed? If you re-run git fsck --tags, does it reproduce reliably (i.e., is it bogus data that something wrote to the object db, or is it good data being ruined during the reading process)? I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help Looking into the trash directory and looking at the files, we can see that the .git/index is different between Linux and Mac OS X. Is there a good way to debug the index file? git ls-files -s will dump the entries. But I'd expect them not to be byte-equivalent, because the index will contain things like mtimes for each entry, which will vary from run to run. Plus the error message above indicates something much more broken. After some time, the problem is still there When I make a fresh clone of git.git under Mac OS, 1450 passes. After a while, running things like git fetch git checkout origin/next make clean make test, it starts to fail. (currently I have a couple of git repo-copies, t1450 fails in git.pu and passes in git.next. But that has nothing to do with next or pu) When I run ssh into the Mac OS X machine, the test case passes even in pu. Very strange, but reproducable. Now things become more puzzled: I managed to re-produce it on a Linux machine as well. Using v1.7.12 and applying my i18.pathencoding patch, t1450 fails on Linux, regardless if I use ssh or sit locally at the machine. I make a new version of t1450-fsck.sh, called t1450-fsck2.sh That uses git fsck --verbose, I add the log file here. The short version: - I can re-run the git fsck, all files on disk have the same md5. - The 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 has the same md5 as well I added lots of printouts in git code, according to my understanding 63499 is checked/fsck'ed after being loaded into RAM, is that right? For some reasons it is classified as is a blob, not a commit when it passes and is a commit, not a blob when it fails. I want to debug when it is loaded into RAM, so that code is in read-cache.c, isn't it? Does anybody have a tool to debug the contents of the index file? Even offline could help, I can send a bunch of files ;-) And why doesn't fsck find the broken link? Other ideas are welcome, thanks everybody for reading/helping. /Torsten out after running git fsck --verbose --tags, t1450 failed (no broken link) Checking HEAD link Checking object directory Checking directory .git/objects/13 Checking directory .git/objects/15 Checking directory .git/objects/1b Checking directory .git/objects/30 Checking directory .git/objects/35 Checking directory .git/objects/44 Checking directory .git/objects/56 Checking directory .git/objects/63 Checking directory .git/objects/66 Checking directory .git/objects/af Checking directory .git/objects/b6 Checking directory .git/objects/bd Checking directory .git/objects/c4 Checking directory .git/objects/c9 Checking directory .git/objects/f7 Checking tag 66f6581d549f70e05ca586bc2df5c15a95662c36 Checking commit 134756353796a5439d93586be27999eea3807a34 Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171 error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing Checking tree bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7 Checking commit c9145d6720f85544cc4bb6009a2e541660aa156b Checking tree c9176b0dd1a95c80ad8de21784b1eeffd3681f49 Checking blob f719efd430d52bcfc8566a43b2eb655688d38871 Checking cache tree Checking connectivity (32 objects) Checking 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 Checking 66f6581d549f70e05ca586bc2df5c15a95662c36 Checking c9145d6720f85544cc4bb6009a2e541660aa156b Checking c9176b0dd1a95c80ad8de21784b1eeffd3681f49 Checking 134756353796a5439d93586be27999eea3807a34 Checking
[PATCHv7] clone --single: limit the fetch refspec to fetched branch
After running git clone --single, the resulting repository has the
usual default +refs/heads/*:refs/remotes/origin/* wildcard fetch
refspec installed, which means that a subsequent git fetch will
end up grabbing all the other branches.
Update the fetch refspec to cover only the singly cloned ref instead
to correct this.
That means:
If --single is used without --branch or --mirror, the
fetch refspec covers the branch on which remote's HEAD points to.
If --single is used with --branch, it'll cover only the branch
specified in the --branch option.
If --single is combined with --mirror, then it'll cover all
refs of the cloned repository.
If --single is used with --branch that specifies a tag, then
it'll cover only the ref for this tag.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Changes in v7:
- remove a test which has shown that after the next git fetch
the tags will be the same (was actually a bit senseless)
- add a test to show that the initial clone with --single fetches tags
- add a test to show when using --single with --branch
which points to a tag, then the next git fetch will update
this tag if it was updated in the cloned repository
- update documentation of git clone (Thanks to Junio)
Documentation/git-clone.txt | 15 +++--
builtin/clone.c | 66 +++
t/t5709-clone-refspec.sh| 155
3 Dateien geändert, 218 Zeilen hinzugefügt(+), 18 Zeilen entfernt(-)
create mode 100755 t/t5709-clone-refspec.sh
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index c1ddd4c..6d98ef3 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -29,7 +29,8 @@ currently active branch.
After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
arguments will in addition merge the remote master branch into the
-current master branch, if any.
+current master branch, if any (this is untrue when --single-branch
+is given; see below).
This default configuration is achieved by creating references to
the remote branch heads under `refs/remotes/origin` and
@@ -152,9 +153,10 @@ objects from the source repository into a pack in the
cloned repository.
-b name::
Instead of pointing the newly created HEAD to the branch pointed
to by the cloned repository's HEAD, point to `name` branch
- instead. `--branch` can also take tags and treat them like
- detached HEAD. In a non-bare repository, this is the branch
- that will be checked out.
+ instead. In a non-bare repository, this is the branch that will
+ be checked out.
+ `--branch` can also take tags and detaches the HEAD at that commit
+ in the resulting repository.
--upload-pack upload-pack::
-u upload-pack::
@@ -193,6 +195,11 @@ objects from the source repository into a pack in the
cloned repository.
clone with the `--depth` option, this is the default, unless
`--no-single-branch` is given to fetch the histories near the
tips of all branches.
+ Further fetches into the resulting repository will only update the
+ remote tracking branch for the branch this option was used for the
+ initial cloning. If the HEAD at the remote did not point at any
+ branch when `--single-branch` clone was made, no remote tracking
+ branch is created.
--recursive::
--recurse-submodules::
diff --git a/builtin/clone.c b/builtin/clone.c
index 5e8f3ba..431635c 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -610,6 +610,55 @@ static void write_config(struct string_list *config)
}
}
+static void write_refspec_config(const char* src_ref_prefix,
+ const struct ref* our_head_points_at,
+ const struct ref* remote_head_points_at, struct strbuf*
branch_top)
+{
+ struct strbuf key = STRBUF_INIT;
+ struct strbuf value = STRBUF_INIT;
+
+ if (option_mirror || !option_bare) {
+ if (option_single_branch !option_mirror) {
+ if (option_branch) {
+ if (strstr(our_head_points_at-name,
refs/tags/))
+ strbuf_addf(value, +%s:%s,
our_head_points_at-name,
+ our_head_points_at-name);
+ else
+ strbuf_addf(value, +%s:%s%s,
our_head_points_at-name,
+ branch_top-buf, option_branch);
+ } else if (remote_head_points_at) {
+ strbuf_addf(value, +%s:%s%s,
remote_head_points_at-name,
+ branch_top-buf,
+
skip_prefix(remote_head_points_at-name, refs/heads/));
+ }
+ /*
+*
[PATCH] Documentation/Makefile: Allow custom XMLTO binary
From: Dave Borowitz dborow...@google.com Signed-off-by: Dave Borowitz dborow...@google.com --- Documentation/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index cf5916f..b045628 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -47,6 +47,7 @@ man7dir=$(mandir)/man7 ASCIIDOC=asciidoc ASCIIDOC_EXTRA = MANPAGE_XSL = manpage-normal.xsl +XMLTO=xmlto XMLTO_EXTRA = INSTALL?=install RM ?= rm -f @@ -245,7 +246,7 @@ manpage-base-url.xsl: manpage-base-url.xsl.in %.1 %.5 %.7 : %.xml manpage-base-url.xsl $(QUIET_XMLTO)$(RM) $@ \ - xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $ + $(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $ %.xml : %.txt $(QUIET_ASCIIDOC)$(RM) $@+ $@ \ -- 1.7.12.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: possible bug in autocompletion
On Tue, Jul 17, 2012 at 2:12 PM, Jeff King p...@peff.net wrote:
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -261,7 +261,12 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
+ local words=$1
+ words=${words//\\/}
+ words=${words//\$/\\\$}
+ words=${words//\'/\\\'}
+ words=${words//\/\\\}
+ COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words --
${3-$cur}))
}
What about something like this?
local words
printf -v words %q $w
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words -- ${3-$cur}))
Cheers.
--
Felipe Contreras
--
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 1/6] Change the color of individual known breakages
Bold yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where green
conveys the impression that everything's OK, and amber that
something's not quite right.
Likewise, change the color of the summarized total number of known
breakages from bold red to bold yellow to be less alarmist and more
consistent with the above.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/test-lib.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f8e3733..426820e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -183,6 +183,8 @@ then
tput bold; tput setaf 1;; # bold red
skip)
tput bold; tput setaf 2;; # bold green
+ warn)
+ tput bold; tput setaf 3;; # bold yellow
pass)
tput setaf 2;;# green
info)
@@ -281,7 +283,7 @@ test_known_broken_ok_ () {
test_known_broken_failure_ () {
test_broken=$(($test_broken+1))
- say_color skip not ok $test_count - $@ # TODO known breakage
+ say_color warn not ok $test_count - $@ # TODO known breakage
}
test_debug () {
@@ -375,7 +377,7 @@ test_done () {
fi
if test $test_broken != 0
then
- say_color error # still have $test_broken known breakage(s)
+ say_color warn # still have $test_broken known breakage(s)
msg=remaining $(($test_count-$test_broken)) test(s)
else
msg=$test_count test(s)
--
1.7.12.147.g6d168f4
--
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 4/6] Refactor mechanics of testing in a sub test-lib
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index c6b42de..662cd2f 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -55,39 +55,49 @@ test_expect_failure 'pretend we have a known breakage' '
false
'
-test_expect_success 'pretend we have fixed a known breakage (run in sub
test-lib)'
- mkdir passing-todo
- (cd passing-todo
- cat passing-todo.sh -EOF
+run_sub_test_lib_test () {
+ name=$1 descr=$2 # stdin is body of test code
+ mkdir $name
+ (cd $name
+ cat $name.sh -EOF
#!$SHELL_PATH
- test_description='A passing TODO test
+ test_description='$descr (run in sub test-lib)
This is run in a sub test-lib so that we do not get incorrect
passing metrics
'
# Point to the t/test-lib.sh, which isn't in ../ as usual
- TEST_DIRECTORY=\$TEST_DIRECTORY\
- . \\$TEST_DIRECTORY\/test-lib.sh
-
- test_expect_failure 'pretend we have fixed a known breakage' '
- :
- '
+ TEST_DIRECTORY=$TEST_DIRECTORY
+ . \$TEST_DIRECTORY/test-lib.sh
+ EOF
+ cat $name.sh
+ chmod +x $name.sh
+ ./$name.sh out 2err)
+}
+
+check_sub_test_lib_test () {
+ name=$1 # stdin is test's expected stdout
+ (cd $name
+ ! test -s err
+ sed -e 's/^ //' expect
+ test_cmp expect out)
+}
+test_expect_success 'pretend we have fixed a known breakage'
+ run_sub_test_lib_test passing-todo 'A passing TODO test' -EOF
+ test_expect_failure 'pretend we have fixed a known breakage' 'true'
test_done
EOF
- chmod +x passing-todo.sh
- ./passing-todo.sh out 2err
- ! test -s err
- sed -e 's/^ //' expect -\\EOF
+ check_sub_test_lib_test passing-todo -EOF
ok 1 - pretend we have fixed a known breakage # TODO known breakage
# fixed 1 known breakage(s)
# passed all 1 test(s)
1..1
EOF
- test_cmp expect out)
+
test_set_prereq HAVEIT
haveit=no
test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
@@ -166,7 +176,7 @@ test_expect_success 'tests clean up even on failures'
test_must_fail ./failing-cleanup.sh out 2err
! test -s err
! test -f \trash directory.failing-cleanup/clean-after-failure\
- sed -e 's/Z$//' -e 's/^ //' expect -\\EOF
+ sed -e 's/Z$//' -e 's/^ //' expect -EOF
not ok 1 - tests clean up even after a failure
# Z
# touch clean-after-failure
--
1.7.12.147.g6d168f4
--
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 6/6] Treat unexpectedly fixed known breakages more seriously
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this
is an error which is potentially as bad as a failing test, and as
such is no longer portrayed as a pass in the output.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 29 +++--
t/test-lib.sh| 13 +
2 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 644cc2c..459d0c7 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -148,13 +148,30 @@ test_expect_success 'pretend we have fixed a known
breakage'
test_done
EOF
check_sub_test_lib_test passing-todo -EOF
-ok 1 - pretend we have fixed a known breakage # TODO known breakage
-# fixed 1 known breakage(s)
-# passed all 1 test(s)
+ok 1 - pretend we have fixed a known breakage # TODO known breakage
vanished
+# 1 known breakage(s) vanished; please update test(s)
1..1
EOF
+test_expect_success 'pretend we have fixed one of two known breakages (run in
sub test-lib)'
+ run_sub_test_lib_test partially-passing-todos '2 TODO tests, one
passing' -EOF
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_success 'pretend we have a passing test' 'true'
+ test_expect_failure 'pretend we have fixed another known breakage'
'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partially-passing-todos -EOF
+not ok 1 - pretend we have a known breakage # TODO known breakage
+ok 2 - pretend we have a passing test
+ok 3 - pretend we have fixed another known breakage # TODO known
breakage vanished
+# 1 known breakage(s) vanished; please update test(s)
+# still have 1 known breakage(s)
+# passed all remaining 1 test(s)
+1..3
+ EOF
+
+
test_expect_success 'pretend we have a pass, fail, and known breakage'
run_sub_test_lib_test_expecting_failures mixed-results1 'mixed results
#1' -EOF
test_expect_success 'passing test' 'true'
@@ -200,10 +217,10 @@ test_expect_success 'pretend we have a mix of all
possible results'
# false
not ok 8 - pretend we have a known breakage # TODO known breakage
not ok 9 - pretend we have a known breakage # TODO known breakage
-ok 10 - pretend we have fixed a known breakage # TODO known breakage
-# fixed 1 known breakage(s)
+ok 10 - pretend we have fixed a known breakage # TODO known breakage
vanished
+# 1 known breakage(s) vanished; please update test(s)
# still have 2 known breakage(s)
-# failed 3 among remaining 8 test(s)
+# failed 3 among remaining 7 test(s)
1..10
EOF
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7028ba8..b403e85 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -278,7 +278,7 @@ test_failure_ () {
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
- say_color ok $test_count - $@ # TODO known breakage
+ say_color error ok $test_count - $@ # TODO known breakage vanished
}
test_known_broken_failure_ () {
@@ -373,13 +373,18 @@ test_done () {
if test $test_fixed != 0
then
- say_color pass # fixed $test_fixed known breakage(s)
+ say_color error # $test_fixed known breakage(s) vanished;
please update test(s)
fi
if test $test_broken != 0
then
say_color warn # still have $test_broken known breakage(s)
- msg=remaining $(($test_count-$test_broken)) test(s)
+ fi
+ if test $test_broken != 0 || test $test_fixed != 0
+ then
+ test_remaining=$(( $test_count - $test_broken - $test_fixed ))
+ msg=remaining $test_remaining test(s)
else
+ test_remaining=$test_count
msg=$test_count test(s)
fi
case $test_failure in
@@ -393,7 +398,7 @@ test_done () {
if test $test_external_has_tap -eq 0
then
- if test $test_count -gt 0
+ if test $test_remaining -gt 0
then
say_color pass # passed all $msg
fi
--
1.7.12.147.g6d168f4
--
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] Questions for Git User's Survey 2011
Hi, On Wed, Sep 14, 2011 at 7:39 PM, Jakub Narebski jna...@gmail.com wrote: P.S. Would you be interested in running the next survey? I haven't seen any news regarding the 2012 survey. I'm interested in running the survey this time, but I would like to know what that entails :) I think the surveys should continue. Cheers. -- Felipe Contreras -- 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: Add .editorconfig file to source repository to maintain a consistent coding style
Hong Xu d...@hong.me writes: EditorConfig has been used in many large and famous projects, such as Ruby, jQuery, etc. I see jQuery swallowed it and has been using it for 6 months, but citing Ruby as an example makes you look somewhat dishonest. As far as I can see, they just added one a few days ago, which means they haven't had a chance to evaluate how it affects their developer's workflow and possibly realize that it is bad for their project and revert it, or find it very useful and give a raving blog about it. Throwing [Ruby EditorConfig] at my search engine gives mostly what you wrote and not much else, so it does not help me to judge the merit of using it objectively, either. I dunno. -- 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: possible bug in autocompletion
On Wed, Sep 19, 2012 at 07:08:09PM +0200, Felipe Contreras wrote:
On Tue, Jul 17, 2012 at 2:12 PM, Jeff King p...@peff.net wrote:
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -261,7 +261,12 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
+ local words=$1
+ words=${words//\\/}
+ words=${words//\$/\\\$}
+ words=${words//\'/\\\'}
+ words=${words//\/\\\}
+ COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words --
${3-$cur}))
}
What about something like this?
local words
printf -v words %q $w
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words -- ${3-$cur}))
Thanks, I didn't know about bash's internal printf magic. That is a much
more elegant solution.
Care to wrap it up in a patch?
-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] Port to HP NonStop
On Wednesday 2012-09-19 12:03, Joachim Schmitz wrote: +#ifdef NO_INTPTR_T +/* + * On I16LP32, ILP32 and LP64 long is the save bet, however + * on LLP86, IL33LLP64 and P64 it needs to be long long, + * while on IP16 and IP16L32 it is int (resp. short) + * Size needs to match (or exceed) 'sizeof(void *)'. + * We can't take long long here as not everybody has it. Are you trying to port git to DOS or why would you mention IP16? :-) -- 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 2/6] Make 'not ok $count - $message' consistent with 'ok $count - $message'
On Wed, Sep 19, 2012 at 06:15:11PM +0100, Adam Spiers wrote:
test_failure_ () {
test_failure=$(($test_failure + 1))
- say_color error not ok - $test_count $1
+ say_color error not ok $test_count - $1
Interesting. I wondered what TAP had to say about this, and in fact we
were doing it wrong before. However, since the test numbers are optional
in TAP, a harness is supposed to keep its own counter when we fail to
provide a number.
So it happened to work, but this change in fact makes us more
TAP-compliant. Good.
-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] Port to HP NonStop
From: Jan Engelhardt [mailto:jeng...@inai.de] Sent: Wednesday, September 19, 2012 7:48 PM To: Joachim Schmitz Cc: 'Junio C Hamano'; git@vger.kernel.org Subject: Re: [PATCH] Port to HP NonStop On Wednesday 2012-09-19 12:03, Joachim Schmitz wrote: +#ifdef NO_INTPTR_T +/* + * On I16LP32, ILP32 and LP64 long is the save bet, however + * on LLP86, IL33LLP64 and P64 it needs to be long long, + * while on IP16 and IP16L32 it is int (resp. short) + * Size needs to match (or exceed) 'sizeof(void *)'. + * We can't take long long here as not everybody has it. Are you trying to port git to DOS or why would you mention IP16? :-) Just for completness, nothing else ;-) -- 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: possible bug in autocompletion
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Jul 17, 2012 at 2:12 PM, Jeff King p...@peff.net wrote:
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -261,7 +261,12 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
+ local words=$1
+ words=${words//\\/}
+ words=${words//\$/\\\$}
+ words=${words//\'/\\\'}
+ words=${words//\/\\\}
+ COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words --
${3-$cur}))
}
What about something like this?
local words
printf -v words %q $w
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words -- ${3-$cur}))
Both printf -v and %q are brilliant ;-)
--
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] Documentation/Makefile: Allow custom XMLTO binary
dborow...@google.com writes: From: Dave Borowitz dborow...@google.com Signed-off-by: Dave Borowitz dborow...@google.com --- Thanks; the patch sort-of makes sense but makes me wonder what your use case is. Do you have xmlto2 program you want to use in place of xmlto or you have xmlto but not on your $PATH? Documentation/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index cf5916f..b045628 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -47,6 +47,7 @@ man7dir=$(mandir)/man7 ASCIIDOC=asciidoc ASCIIDOC_EXTRA = MANPAGE_XSL = manpage-normal.xsl +XMLTO=xmlto XMLTO_EXTRA = INSTALL?=install RM ?= rm -f @@ -245,7 +246,7 @@ manpage-base-url.xsl: manpage-base-url.xsl.in %.1 %.5 %.7 : %.xml manpage-base-url.xsl $(QUIET_XMLTO)$(RM) $@ \ - xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $ + $(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $ %.xml : %.txt $(QUIET_ASCIIDOC)$(RM) $@+ $@ \ -- 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: possible bug in autocompletion
On Wed, Sep 19, 2012 at 7:43 PM, Jeff King p...@peff.net wrote:
On Wed, Sep 19, 2012 at 07:08:09PM +0200, Felipe Contreras wrote:
On Tue, Jul 17, 2012 at 2:12 PM, Jeff King p...@peff.net wrote:
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -261,7 +261,12 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 --
${3-$cur}))
+ local words=$1
+ words=${words//\\/}
+ words=${words//\$/\\\$}
+ words=${words//\'/\\\'}
+ words=${words//\/\\\}
+ COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words --
${3-$cur}))
}
What about something like this?
local words
printf -v words %q $w
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $words -- ${3-$cur}))
Thanks, I didn't know about bash's internal printf magic. That is a much
more elegant solution.
Care to wrap it up in a patch?
I'm trying to, but unfortunately \n gets converted to \\n, so it
doesn't get separated to words. Any ideas?
--
Felipe Contreras
--
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] log --oneline: put decoration at the end of the line
On Wed, Sep 19, 2012 at 06:52:20PM +0700, Nguyen Thai Ngoc Duy wrote: I find it easier to read git log --oneline when the subject lines align, which they don't when the log is decorated because the decoration stands before the subject line. I like it. I turned on log.decorate some time ago, and I always felt that --oneline was a little bit messy. But for some reason I never thought of this simple change. I'm on colored output so moving decoration to the end of line does not make it harder to recognize refs. What about black-and-white people? Like you, I use colors. I think the decorations would be much harder to see if not for the color. We should also consider briefly whether anybody is relying on --oneline for machine parsing. I think log --oneline is fair game, but I wonder if people calling rev-list --decorate --oneline should be considered. It seems kind of unlikely to me, considering that the decorate output is ambiguous to parse anyway (if you see parentheses, you cannot tell if it is decorate output or part of the commit subject). I did not look too carefully at your patch, but I did notice an odd behavior with it. Try git log --graph --oneline in git.git. With stock git, I see this several lines down (apologies for the long lines): * | | | | | | | | | | | | | | | | | | | | | | | | b1379ba Merge branch 'sb/send-email-reconfirm-fix' |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | | |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | * | | | | | | | | | | | | | | | | | | | | | | | 6183749 (origin/sb/send-email-reconfirm-fix) send-email: initial_to and initial_reply_to are both optional In other words, 6183749 looks fine: graph, decorations, then subject, all on the same line. But with your patch, I see: * | | | | | | | | | | | | | | | | | | | | | | | | b1379ba Merge branch 'sb/send-email-reconfirm-fix' |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | | |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | * | | | | | | | | | | | | | | | | | | | | | | | 6183749 send-email: initial_to and initial_reply_to are both optional | | |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | (origin/sb/send-email-reconfirm-fix) The decoration is broken onto a separate line (with a newline in between). Oddly, if I start my log right at b1379ba, it looks OK. Which makes me think we are hitting some kind of line-wrapping code related to the width of the graph. -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] Documentation/git-blame.txt: --follow is a NO-OP
On Tue, Sep 18, 2012 at 09:38:32PM -0700, Junio C Hamano wrote:
That is a totally wrong message to send. You failed to teach the
reader that there is no need to do anything special to tell the
command to follow per-line origin across renames.
So if anything, I would phrase it this way instead:
--follow::
This option is accepted but silently ignored. git blame
follows per-line origin across renames without any special
options, and there is no reason to use this option.
I think that is much better than Drew's text. But I really wonder if the
right solution is to simply disallow --follow. It does not do anything,
and it is not documented. There is no special reason to think that it
would do anything, except by people who try it. So perhaps that is the
right time to say no, this is not a valid option.
Like this (totally untested) patch:
diff --git a/builtin/blame.c b/builtin/blame.c
index 0e102bf..412d6dd 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2365,6 +2365,10 @@ int cmd_blame(int argc, const char **argv, const char
*prefix)
ctx.argv[0] = --children;
reverse = 1;
}
+ else if (!strcmp(ctx.argv[0], --follow)) {
+ error(unknown option `--follow`);
+ usage_with_options(blame_opt_usage, options);
+ }
parse_revision_opt(revs, ctx, options, blame_opt_usage);
}
parse_done:
-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 v3 5/6] Test the test framework more thoroughly
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory in order to disrupt the metrics for
the parent tests.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 104 +++
1 file changed, 104 insertions(+)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 029e3bd..65f578f 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -85,6 +85,55 @@ check_sub_test_lib_test () {
test_cmp expect out)
}
+test_expect_success 'pretend we have a fully passing test suite'
+ run_sub_test_lib_test full-pass '3 passing tests' -\\EOF
+ for i in 1 2 3; do
+ test_expect_success \passing test #\$i\ 'true'
+ done
+ test_done
+ EOF
+ check_sub_test_lib_test full-pass -\\EOF
+ok 1 - passing test #1
+ok 2 - passing test #2
+ok 3 - passing test #3
+# passed all 3 test(s)
+1..3
+ EOF
+
+
+test_expect_success 'pretend we have a partially passing test suite'
+ test_must_fail run_sub_test_lib_test \
+ partial-pass '2/3 tests passing' -\\EOF
+ test_expect_success 'passing test #1' 'true'
+ test_expect_success 'failing test #2' 'false'
+ test_expect_success 'passing test #3' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partial-pass -\\EOF
+ok 1 - passing test #1
+not ok 2 - failing test #2
+ # false
+ok 3 - passing test #3
+# failed 1 among 3 test(s)
+1..3
+ EOF
+
+
+test_expect_success 'pretend we have a known breakage'
+ run_sub_test_lib_test failing-todo 'A failing TODO test' -\\EOF
+ test_expect_success 'passing test' 'true'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test failing-todo -\\EOF
+ok 1 - passing test
+not ok 2 - pretend we have a known breakage # TODO known breakage
+# still have 1 known breakage(s)
+# passed all remaining 1 test(s)
+1..2
+ EOF
+
+
test_expect_success 'pretend we have fixed a known breakage'
run_sub_test_lib_test passing-todo 'A passing TODO test' -\\EOF
test_expect_failure 'pretend we have fixed a known breakage' 'true'
@@ -98,6 +147,61 @@ test_expect_success 'pretend we have fixed a known
breakage'
EOF
+test_expect_success 'pretend we have a pass, fail, and known breakage'
+ test_must_fail run_sub_test_lib_test \
+ mixed-results1 'mixed results #1' -\\EOF
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results1 -\\EOF
+ok 1 - passing test
+not ok 2 - failing test
+# false
+not ok 3 - pretend we have a known breakage # TODO known breakage
+# still have 1 known breakage(s)
+# failed 1 among remaining 2 test(s)
+1..3
+ EOF
+
+
+test_expect_success 'pretend we have a mix of all possible results'
+ test_must_fail run_sub_test_lib_test \
+ mixed-results2 'mixed results #2' -\\EOF
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have fixed a known breakage' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results2 -\\EOF
+ok 1 - passing test
+ok 2 - passing test
+ok 3 - passing test
+ok 4 - passing test
+not ok 5 - failing test
+# false
+not ok 6 - failing test
+# false
+not ok 7 - failing test
+# false
+not ok 8 - pretend we have a known breakage # TODO known breakage
+not ok 9 - pretend we have a known breakage # TODO known breakage
+ok 10 - pretend we have fixed a known breakage # TODO known breakage
+# fixed 1 known breakage(s)
+# still have 2 known breakage(s)
+# failed 3 among remaining 8 test(s)
+1..10
+ EOF
+
+
test_set_prereq HAVEIT
haveit=no
test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
--
1.7.12.147.g6d168f4
--
To unsubscribe from this list: send the line unsubscribe git in
[PATCH v3 6/6] Treat unexpectedly fixed known breakages more seriously
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this
is an error which is potentially as bad as a failing test, and as
such is no longer portrayed as a pass in the output.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 30 --
t/test-lib.sh| 13 +
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 65f578f..ed44f7d 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -140,13 +140,31 @@ test_expect_success 'pretend we have fixed a known
breakage'
test_done
EOF
check_sub_test_lib_test passing-todo -\\EOF
-ok 1 - pretend we have fixed a known breakage # TODO known breakage
-# fixed 1 known breakage(s)
-# passed all 1 test(s)
+ok 1 - pretend we have fixed a known breakage # TODO known breakage
vanished
+# 1 known breakage(s) vanished; please update test(s)
1..1
EOF
+test_expect_success 'pretend we have fixed one of two known breakages (run in
sub test-lib)'
+ run_sub_test_lib_test partially-passing-todos \
+ '2 TODO tests, one passing' -\\EOF
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_success 'pretend we have a passing test' 'true'
+ test_expect_failure 'pretend we have fixed another known breakage'
'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partially-passing-todos -\\EOF
+not ok 1 - pretend we have a known breakage # TODO known breakage
+ok 2 - pretend we have a passing test
+ok 3 - pretend we have fixed another known breakage # TODO known
breakage vanished
+# 1 known breakage(s) vanished; please update test(s)
+# still have 1 known breakage(s)
+# passed all remaining 1 test(s)
+1..3
+ EOF
+
+
test_expect_success 'pretend we have a pass, fail, and known breakage'
test_must_fail run_sub_test_lib_test \
mixed-results1 'mixed results #1' -\\EOF
@@ -194,10 +212,10 @@ test_expect_success 'pretend we have a mix of all
possible results'
# false
not ok 8 - pretend we have a known breakage # TODO known breakage
not ok 9 - pretend we have a known breakage # TODO known breakage
-ok 10 - pretend we have fixed a known breakage # TODO known breakage
-# fixed 1 known breakage(s)
+ok 10 - pretend we have fixed a known breakage # TODO known breakage
vanished
+# 1 known breakage(s) vanished; please update test(s)
# still have 2 known breakage(s)
-# failed 3 among remaining 8 test(s)
+# failed 3 among remaining 7 test(s)
1..10
EOF
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7028ba8..b403e85 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -278,7 +278,7 @@ test_failure_ () {
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
- say_color ok $test_count - $@ # TODO known breakage
+ say_color error ok $test_count - $@ # TODO known breakage vanished
}
test_known_broken_failure_ () {
@@ -373,13 +373,18 @@ test_done () {
if test $test_fixed != 0
then
- say_color pass # fixed $test_fixed known breakage(s)
+ say_color error # $test_fixed known breakage(s) vanished;
please update test(s)
fi
if test $test_broken != 0
then
say_color warn # still have $test_broken known breakage(s)
- msg=remaining $(($test_count-$test_broken)) test(s)
+ fi
+ if test $test_broken != 0 || test $test_fixed != 0
+ then
+ test_remaining=$(( $test_count - $test_broken - $test_fixed ))
+ msg=remaining $test_remaining test(s)
else
+ test_remaining=$test_count
msg=$test_count test(s)
fi
case $test_failure in
@@ -393,7 +398,7 @@ test_done () {
if test $test_external_has_tap -eq 0
then
- if test $test_count -gt 0
+ if test $test_remaining -gt 0
then
say_color pass # passed all $msg
fi
--
1.7.12.147.g6d168f4
--
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] Document conventions on static initialization and else cuddling
Signed-off-by: Adam Spiers g...@adamspiers.org
---
I have begun work on fixing existing code to adhere to these
guidelines on braces, but there are currently a lot of violations,
which means any patches to fix them would be large. So before I spend
any more time on it, I would like to check whether such patches would
be welcomed? And if so, should I be doing that on the master branch?
I have also added some simple rules such as `check-brace-before-else'
to the top-level Makefile which perform appropriate `grep -n' commands
to detect violations and for example easily fix them via emacs' M-x
grep. These rules can be invoked together via a `check-style' target.
Would this also be welcomed? If so, should the checks all be
introduced in a single commit, or each check along with the code which
was fixed with its help?
BTW I briefly tried to find an existing tool out there which could
already do the checking for us, but only found ones like uncrustify
which rewrite code rather than warning on inconsistencies. I also saw
that the kernel's scripts/checkpatch.pl only worked with patches and
was also extremely kernel-specific in the nature of its checks.
Documentation/CodingGuidelines | 42 +-
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 57da6aa..1a2851d 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -117,17 +117,49 @@ For C programs:
char * string. This makes it easier to understand code
like char *string, c;.
+ - We avoid unnecessary explicit initialization of BSS-allocated vars
+ (static and globals) to zero or NULL:
+
+ static int n;
+ static char **ch;
+
+ rather than:
+
+ static int n = 0;
+ static char **ch = NULL;
+
+ These are superfluous according to ISO/IEC 9899:1999 (a.k.a. C99);
+ see item 10 in section 6.7.8 (Initialization) of WG14 N1256 for
+ the exact text:
+
+ http://open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
+
- We avoid using braces unnecessarily. I.e.
if (bla) {
x = 1;
}
- is frowned upon. A gray area is when the statement extends
- over a few lines, and/or you have a lengthy comment atop of
- it. Also, like in the Linux kernel, if there is a long list
- of else if statements, it can make sense to add braces to
- single line blocks.
+ is frowned upon. A gray area is when the statement extends over a
+ few lines, and/or you have a lengthy comment atop of it. Also,
+ like in the Linux kernel, it can make sense to add braces to single
+ line blocks if there are already braces in another branch of the
+ same conditional, and/or there is long list of else if
+ statements.
+
+ - When braces are required, we cuddle else and else if, so the
+ preceding closing brace appears on the same line, e.g.
+
+ if (foo) {
+ ...;
+ } else if (bar) {
+ ...;
+ ...;
+ } else {
+ ...;
+ }
+
+ following Linux kernel style, unless there is a good reason not to.
- We try to avoid assignments inside if().
--
1.7.12.147.g6d168f4
--
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] Make test output coloring more intuitive
On 09/17/2012 10:11 PM, Jeff King wrote: On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote: The end result of these changes is that: - red is _only_ used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures with the framework, - yellow is _only_ used for known breakages, and - green is _only_ used for things which have gone to plan and require no further work to be done. Sounds reasonable, and I think the new output looks nice. I notice that skipped tests are still in green. I wonder if they should be in yellow, too. What about blue instead? This would keep the colouring scheme more consistent with the one used by prove: http://search.cpan.org/~ovid/Test-Harness/bin/prove by autotest: http://www.gnu.org/software/autoconf/manual/autoconf.html#Using-Autotest and by the Automake-generated test harness: http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites Just my 2 cents, Stefano -- 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] log --oneline: put decoration at the end of the line
On Wed, Sep 19, 2012 at 12:57:28PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: We should also consider briefly whether anybody is relying on --oneline for machine parsing. I think log --oneline is fair game, but I wonder if people calling rev-list --decorate --oneline should be considered. It seems kind of unlikely to me, considering that the decorate output is ambiguous to parse anyway (if you see parentheses, you cannot tell if it is decorate output or part of the commit subject). Yeah, I do not think it is likely. Among the in-tree scripts, git-stash does use rev-list --oneline but the purpose of the call exactly is to grab a human readable one line summary, and it will be happy with any change to make --oneline more human readble. Yeah, that makes sense. t4202 has many invocations of log --oneline --decorate, though; these things do get tested. I think it is just trying to compare the log.decorate variable to the --decorate command-line option. Notice that it generates the expected output by running the latter. So I think it would be OK (and if not, I think it would make sense to update the test, as it does not care about the specific format). Google Code Search doesn't show anything interesting, though I suppose its results are getting continually out of date (they claim to have shut it down, though you can still query it if you use the right URL). -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] Make test output coloring more intuitive
On Wed, Sep 19, 2012 at 10:02:52PM +0200, Stefano Lattarini wrote: On 09/17/2012 10:11 PM, Jeff King wrote: On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote: The end result of these changes is that: - red is _only_ used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures with the framework, - yellow is _only_ used for known breakages, and - green is _only_ used for things which have gone to plan and require no further work to be done. Sounds reasonable, and I think the new output looks nice. I notice that skipped tests are still in green. I wonder if they should be in yellow, too. What about blue instead? This would keep the colouring scheme more consistent with the one used by prove: http://search.cpan.org/~ovid/Test-Harness/bin/prove by autotest: http://www.gnu.org/software/autoconf/manual/autoconf.html#Using-Autotest and by the Automake-generated test harness: http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites Sounds good to me! Blue is the conventional color for informational signs, so seems like a natural fit for skipped tests. Not sure whether it should be bold or not though? I'll wait for a more solid group consensus before re-rolling yet another patch :-) -- 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] Make test output coloring more intuitive
On Wed, Sep 19, 2012 at 09:12:01PM +0100, Adam Spiers wrote: Sounds reasonable, and I think the new output looks nice. I notice that skipped tests are still in green. I wonder if they should be in yellow, too. What about blue instead? This would keep the colouring scheme more consistent with the one used by prove: http://search.cpan.org/~ovid/Test-Harness/bin/prove by autotest: http://www.gnu.org/software/autoconf/manual/autoconf.html#Using-Autotest and by the Automake-generated test harness: http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites Sounds good to me! Blue is the conventional color for informational signs, so seems like a natural fit for skipped tests. Not sure whether it should be bold or not though? I'll wait for a more solid group consensus before re-rolling yet another patch :-) Blue would be fine with me. No strong opinion on bold or not (my gut is that most things should not be bold unless there is a good reason, but that is just a feeling). -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] Enable info/refs gzip decompression in HTTP client
Shawn O. Pearce spea...@spearce.org writes: From: Shawn O. Pearce spea...@spearce.org Some HTTP servers try to use gzip compression on the /info/refs request to save transfer bandwidth. Repositories with many tags may find the /info/refs request can be gzipped to be 50% of the original size due to the few but often repeated bytes used (hex SHA-1 and commonly digits in tag names). For most HTTP requests enable Accept-Encoding: gzip ensuring the /info/refs payload can use this encoding format. Disable the Accept-Encoding header on probe RPCs as response bodies are supposed to be exactly 4 bytes long, . The HTTP headers requesting and indicating compression use more space than the data transferred in the body. All of the above sounds very convincing, but ... diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh index 2db5c35..380c175 100755 --- a/t/t5551-http-fetch.sh +++ b/t/t5551-http-fetch.sh @@ -32,13 +32,14 @@ setup_askpass_helper cat exp EOF GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1 Accept: */* + Accept-Encoding: gzip Pragma: no-cache HTTP/1.1 200 OK Pragma: no-cache Cache-Control: no-cache, max-age=0, must-revalidate Content-Type: application/x-git-upload-pack-advertisement POST /smart/repo.git/git-upload-pack HTTP/1.1 - Accept-Encoding: deflate, gzip + Accept-Encoding: gzip ... was loss of deflate intended? If so why? Could you explain it in the log message? Content-Type: application/x-git-upload-pack-request Accept: application/x-git-upload-pack-result Content-Length: xxx -- 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] Improve legibility of test_expect_code output
On Thu, Sep 20, 2012 at 1:35 AM, Junio C Hamano gits...@pobox.com wrote: If it were ..., we wanted 128 from 'git foo bar', then I would, but otherwise, not really. That's fine by me. Both are better than the status quo. -- 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] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0
From: Shawn O. Pearce spea...@spearce.org
If the user doesn't want to use the dumb HTTP protocol, she may
set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
protocol operation. This is mostly useful when testing against
servers that are known to not support the dumb protocol. If the
smart service detection fails the client should not continue with
dumb behavior, but instead provide accurate HTTP failure data.
Signed-off-by: Shawn O. Pearce spea...@spearce.org
---
remote-curl.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 4a0927e..2f91128 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -17,7 +17,8 @@ struct options {
unsigned progress : 1,
followtags : 1,
dry_run : 1,
- thin : 1;
+ thin : 1,
+ fallback : 1;
};
static struct options options;
@@ -115,7 +116,8 @@ static struct discovery* discover_refs(const char *service)
http_ret = http_get_strbuf(refs_url, buffer, HTTP_NO_CACHE);
/* try again with plain url (no ? or appended) */
- if (http_ret != HTTP_OK http_ret != HTTP_NOAUTH) {
+ if (options.fallback http_ret != HTTP_OK
+http_ret != HTTP_NOAUTH) {
free(refs_url);
strbuf_reset(buffer);
@@ -868,6 +870,12 @@ int main(int argc, const char **argv)
options.verbosity = 1;
options.progress = !!isatty(2);
options.thin = 1;
+ options.fallback = 1;
+
+ if (getenv(GIT_CURL_FALLBACK)) {
+ char *fb = getenv(GIT_CURL_FALLBACK);
+ options.fallback = *fb != '0';
+ }
remote = remote_get(argv[1]);
--
1.7.12.1.512.g9b230e6
--
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] Enable info/refs gzip decompression in HTTP client
On Wed, Sep 19, 2012 at 5:43 PM, Junio C Hamano gits...@pobox.com wrote: - Accept-Encoding: deflate, gzip + Accept-Encoding: gzip ... was loss of deflate intended? If so why? Could you explain it in the log message? Yes. I would add the following to the end of the commit message as a new paragraph, please amend this for me: --8-- Only request gzip encoding from servers. Although deflate is supported by libcurl, most servers have standardized on gzip encoding for compression as that is what most browsers support. Asking for deflate increases request sizes by a few bytes, but is unlikely to ever be used by a server. --8-- -- 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] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0
On Wed, Sep 19, 2012 at 7:55 PM, Shawn O. Pearce spea...@spearce.org wrote: From: Shawn O. Pearce spea...@spearce.org I can't explain why git send-email did this. I obviously didn't need the extra From header here. format-patch didn't write it to the patch file, it was injected by send-email. My .git/config is pretty simple, the name/email are derived from there: [user] name = Shawn O. Pearce email = spea...@spearce.org Ick. I really don't want to debug this right now so I'm just going to pretend it wasn't written. -- 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] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0
On Wed, Sep 19, 2012 at 07:55:53PM -0700, Shawn O. Pearce wrote:
From: Shawn O. Pearce spea...@spearce.org
If the user doesn't want to use the dumb HTTP protocol, she may
set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
protocol operation. This is mostly useful when testing against
servers that are known to not support the dumb protocol. If the
smart service detection fails the client should not continue with
dumb behavior, but instead provide accurate HTTP failure data.
I have been looking into this recently, as well. GitHub does not allow
dumb http at all these days, so transient errors on the initial smart
contact can cause us to fall back to dumb, and end up reporting a
totally useless 403 Forbidden error. I guess Google Code has a similar
issue.
Note that it is not really do not fall back to dumb; we detect the
dumb nature from the response. It is really fall back to trying the URL
without the query string, because there are some servers that cannot
handle it. With your patch, we might still end up performing a dumb
transfer.
I think what you're doing here is sane, because you have to turn it on
manually, and thus there are no possible backwards compatibility issues.
But it might be nice to make things work better out of the box. Here are
two client-side changes I've been toying with:
1. If both smart and dumb requests fail, report the error for the
smart request. Now that smart-http clients are common, I'd expect
most http servers to be smart these days. Of course I don't have
any sort of numbers to back this up (nor am I sure how to get them;
obviously big sites like GitHub and Google Code do a lot of
traffic, but who knows how many one-off repo-on-a-generic-web-host
sites still exist?).
An alternative would be to simply be more verbose, and mention that
we tried to fallback and list both failures (or we could do this
with just fetch -v).
2. Be more discerning about which errors will cause a fallback.
Something like 504 Gateway Timeout should not give a fallback.
The problem is that you are really guessing at what kinds of http
errors you are going to get from a dumb server when you try the
smart URL. I dug back into the list thread that spawned the retry
without query string patch (703e6e7).
The thread is here:
http://thread.gmane.org/gmane.comp.version-control.git/137609
If you read the thread, it turns out that the problem in this case
(which is the only reported case I could find in the archive) is
that the server was misconfigured to treat _anything_ with a query
string as a gitweb URL. And then it got fixed pretty much
immediately.
So as far as we know, there may be zero servers for which this
fallback is actually doing anything useful.
I'm tempted to just reverse the logic. Try the request with the query
string and immediately fail if it doesn't work. For the few (if any)
people who are hitting a server that will not serve the dumb file in
that case, add a remote.*.dumbhttp setting that will turn off smart
completely as a workaround.
That would serve the (presumed) majority who are using smart http,
everyone using dumb http on a reasonably-configured server, and still
allow an easy workaround for people with badly configured servers.
What do you think?
---
remote-curl.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
If we do go this route, the patch itself looks fairly obvious, although:
@@ -868,6 +870,12 @@ int main(int argc, const char **argv)
options.verbosity = 1;
options.progress = !!isatty(2);
options.thin = 1;
+ options.fallback = 1;
+
+ if (getenv(GIT_CURL_FALLBACK)) {
+ char *fb = getenv(GIT_CURL_FALLBACK);
+ options.fallback = *fb != '0';
+ }
This can just be:
options.fallback = git_env_bool(GIT_CURL_FALLBACK, 1);
Fewer lines, and you get all of the true/false parsing for free.
-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] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0
On Wed, Sep 19, 2012 at 08:22:58PM -0700, Shawn O. Pearce wrote: On Wed, Sep 19, 2012 at 7:55 PM, Shawn O. Pearce spea...@spearce.org wrote: From: Shawn O. Pearce spea...@spearce.org I can't explain why git send-email did this. I obviously didn't need the extra From header here. format-patch didn't write it to the patch file, it was injected by send-email. My .git/config is pretty simple, the name/email are derived from there: [user] name = Shawn O. Pearce email = spea...@spearce.org Ick. I really don't want to debug this right now so I'm just going to pretend it wasn't written. I was looking at the send-email author comparison code a month or three ago, and I remember noticing that it totally fails to canonicalize before comparing. Without even looking at it again, I'm fairly sure that it thinks 'Shawn O. Pearce' and 'Shawn O. Pearce' (i.e., with and without the quotes) are different, and therefore author != committer. In your case it is particularly egregious because the quotes are introduced (correctly) by format-patch, so it is not even like you have configured two different versions of your name. I think the same bug exists for different rfc2047 encodings of a name with non-ascii characters. Fixing both would involve canonicalizing the names before comparing. I wonder if it would be simpler to just compare the email addresses and ignore the names entirely. -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] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0
Shawn O. Pearce spea...@spearce.org writes: From: Shawn O. Pearce spea...@spearce.org If the user doesn't want to use the dumb HTTP protocol, she may set GIT_CURL_FALLBACK=0 in the environment before invoking a Git protocol operation. This is mostly useful when testing against servers that are known to not support the dumb protocol. If the smart service detection fails the client should not continue with dumb behavior, but instead provide accurate HTTP failure data. Signed-off-by: Shawn O. Pearce spea...@spearce.org --- remote-curl.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) I can see how this feature may be useful, but I have to say the external interface triply sucks. - If it is primarily for debugging smart HTTP, a solution with an environment variable without more permanent configuration variable would be sufficient, but then the environment variable is better named GIT_SMART_HTTP_DEBUG, or something no? - If it is useful outside the context of debugging, perhaps a per remote configuration variable remote.$name.$variable (or http.$prefix_of_server_url.$variable) might be necessary? - I do not see this as fallback (to) curl; you still talk your smart protocol over curl library. fallback to dumb http is more understandable. In any case, I think CURL_FALLBACK was named with CURL in its name primarily because the environment applies only to remote-curl, but that means we cannot have any fallback logic other than the current smart does not work, fall back on dumb in the future. Here is a bit of rewrite. [1/2] is yours but with a bit more sensible name. [2/2] is entirely optional. Junio C Hamano (1): remote-curl: make dumb-http fallback configurable per URL Shawn O. Pearce (1): Disable dumb HTTP fallback with GIT_DUMB_HTTP_FALLBACK=false remote-curl.c | 55 +-- 1 file changed, 53 insertions(+), 2 deletions(-) -- 1.7.12.1.389.g3dff30b -- 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] remote-curl: make dumb-http fallback configurable per URL
Introduce http.$url_prefix.dumbhttpfallback configuration variables
so that users do not have to set GIT_DUMB_HTTP_FALLBACK environment
depending on which remote they are talking with.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
remote-curl.c | 53 +++--
1 file changed, 47 insertions(+), 6 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index f25cf3c..44544c7 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -855,6 +855,46 @@ static void parse_push(struct strbuf *buf)
free(specs);
}
+struct dumb_fallback_cb {
+ const char *url;
+ int value;
+};
+
+static int dumb_fallback_cb(const char *key, const char *value, void *cb_)
+{
+ struct dumb_fallback_cb *cb = cb_;
+ int i, len;
+
+ /* Is this http.$url.dumbHttpFallback? */
+ if (prefixcmp(key, http.))
+ return 0;
+ len = strrchr(key, '.') - key;
+ if (len = 5)
+ /* we found the dot at the end of http. */
+ return 0;
+ key += 5; /* skip over http. part */
+ len -= 5;
+ if (strcmp(key + len, .dumbhttpfallback))
+ return 0;
+
+ /* Does the $url part match? */
+ for (i = 0; i len; i++)
+ if (cb-url[i] != key[i])
+ return 0;
+ cb-value = git_config_bool(key, value);
+ return 0;
+}
+
+static int dumb_fallback_config(const char *url)
+{
+ struct dumb_fallback_cb cb;
+
+ cb.url = url;
+ cb.value = 1; /* defaults to true */
+ git_config(dumb_fallback_cb, cb);
+ return cb.value;
+}
+
static const char DUMB_HTTP_FALLBACK_ENV[] = GIT_DUMB_HTTP_FALLBACK;
int main(int argc, const char **argv)
@@ -872,12 +912,6 @@ int main(int argc, const char **argv)
options.verbosity = 1;
options.progress = !!isatty(2);
options.thin = 1;
- options.fallback = 1;
-
- if (getenv(DUMB_HTTP_FALLBACK_ENV)) {
- char *fb = getenv(DUMB_HTTP_FALLBACK_ENV);
- options.fallback = git_config_bool(DUMB_HTTP_FALLBACK_ENV, fb);
- }
remote = remote_get(argv[1]);
@@ -889,6 +923,13 @@ int main(int argc, const char **argv)
url = strbuf_detach(buf, NULL);
+ if (getenv(DUMB_HTTP_FALLBACK_ENV)) {
+ char *fb = getenv(DUMB_HTTP_FALLBACK_ENV);
+ options.fallback = git_config_bool(DUMB_HTTP_FALLBACK_ENV, fb);
+ } else {
+ options.fallback = dumb_fallback_config(url);
+ }
+
http_init(remote, url, 0);
do {
--
1.7.12.1.389.g3dff30b
--
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] Disable dumb HTTP fallback with GIT_DUMB_HTTP_FALLBACK=false
From: Shawn O. Pearce spea...@spearce.org
If the user doesn't want to use the dumb HTTP protocol, she may set
GIT_DUMB_HTTP_FALLBACK=false in the environment before invoking a
Git protocol operation. This is mostly useful when testing against
servers that are known to not support the dumb protocol. If the
smart service detection fails the client should not continue with
dumb behavior, but instead provide accurate HTTP failure data.
Signed-off-by: Shawn O. Pearce spea...@spearce.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
remote-curl.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 3ec474f..f25cf3c 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -17,7 +17,8 @@ struct options {
unsigned progress : 1,
followtags : 1,
dry_run : 1,
- thin : 1;
+ thin : 1,
+ fallback : 1;
};
static struct options options;
@@ -115,7 +116,8 @@ static struct discovery* discover_refs(const char *service)
http_ret = http_get_strbuf(refs_url, buffer, HTTP_NO_CACHE);
/* try again with plain url (no ? or appended) */
- if (http_ret != HTTP_OK http_ret != HTTP_NOAUTH) {
+ if (options.fallback http_ret != HTTP_OK
+http_ret != HTTP_NOAUTH) {
free(refs_url);
strbuf_reset(buffer);
@@ -853,6 +855,8 @@ static void parse_push(struct strbuf *buf)
free(specs);
}
+static const char DUMB_HTTP_FALLBACK_ENV[] = GIT_DUMB_HTTP_FALLBACK;
+
int main(int argc, const char **argv)
{
struct strbuf buf = STRBUF_INIT;
@@ -868,6 +872,12 @@ int main(int argc, const char **argv)
options.verbosity = 1;
options.progress = !!isatty(2);
options.thin = 1;
+ options.fallback = 1;
+
+ if (getenv(DUMB_HTTP_FALLBACK_ENV)) {
+ char *fb = getenv(DUMB_HTTP_FALLBACK_ENV);
+ options.fallback = git_config_bool(DUMB_HTTP_FALLBACK_ENV, fb);
+ }
remote = remote_get(argv[1]);
--
1.7.12.1.389.g3dff30b
--
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 v4 3/6] Color skipped tests blue
Am 9/19/2012 22:24, schrieb Adam Spiers: skip) - tput bold; tput setaf 2;; # bold green + tput setaf 4;;# blue It's unreadable on black background. Keep it bold; that works on both black and white background. -- Hannes -- 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] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0
On Wed, Sep 19, 2012 at 8:48 PM, Jeff King p...@peff.net wrote:
On Wed, Sep 19, 2012 at 07:55:53PM -0700, Shawn O. Pearce wrote:
If the user doesn't want to use the dumb HTTP protocol, she may
set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
protocol operation. This is mostly useful when testing against
servers that are known to not support the dumb protocol. If the
smart service detection fails the client should not continue with
dumb behavior, but instead provide accurate HTTP failure data.
I have been looking into this recently, as well. GitHub does not allow
dumb http at all these days,
Interesting that GitHub doesn't support dumb transfer either.
so transient errors on the initial smart
contact can cause us to fall back to dumb,
Transient errors is actually what is leading me down this path. We see
about 0.0455% of our requests to the Android hosting service as these
dumb fallbacks. This means the client never got a proper smart service
reply. Server logs suggest we sent a valid response, so I am
suspecting transient proxy errors, but its hard to debug because
clients discard the error.
and end up reporting a
totally useless 403 Forbidden error.
Today I posted a change to JGit [1] to make this 406 Not Acceptable as
I think it better matches the description of the failure. It also no
longer reuses the common 403 Forbidden error that a server might
choose to return if a request was given with invalid credentials.
[1] https://git.eclipse.org/r/7847
I guess Google Code has a similar
issue.
Yes, and {android,kernel,gerrit}.googlesource.com also only support
the smart protocol.
Note that it is not really do not fall back to dumb; we detect the
dumb nature from the response. It is really fall back to trying the URL
without the query string, because there are some servers that cannot
handle it. With your patch, we might still end up performing a dumb
transfer.
Yes, the server could ignore the parameter and return a dumb info/refs
response on the initial request, forcing the client to a dumb
transfer. I forgot this case being common on a dumb server. I have
only been working with or worrying about smart servers, whose
transient failures have this info/refs request that they always
fail... giving a poor user experience.
I think what you're doing here is sane, because you have to turn it on
manually, and thus there are no possible backwards compatibility issues.
But it might be nice to make things work better out of the box. Here are
two client-side changes I've been toying with:
1. If both smart and dumb requests fail, report the error for the
smart request. Now that smart-http clients are common, I'd expect
most http servers to be smart these days. Of course I don't have
any sort of numbers to back this up (nor am I sure how to get them;
obviously big sites like GitHub and Google Code do a lot of
traffic, but who knows how many one-off repo-on-a-generic-web-host
sites still exist?).
I suspect there are still a number of servers that rely on dumb
protocol to host repositories because its very simple to setup.
Breaking support for this wouldn't be a good idea.
kernel.org and eclipse.org both support the smart protocol, but I
think this is a common trend. Sites that host a lot of Git
repositories take the time to setup the smart protocol. Everyone else,
its hit-or-miss, mostly miss.
An alternative would be to simply be more verbose, and mention that
we tried to fallback and list both failures (or we could do this
with just fetch -v).
I would bet the big hosting providers would appreciate having the
failure listed in non-verbose mode. Many Git users are going to use a
hosting service like GitHub or Google Code, or work with their
organization like kernel.org for central Git hosting. Consumers of
hosted projects that are less familiar with Git will be accessing
these sites often enough.
I considered logging this failure to stderr, but didn't.
2. Be more discerning about which errors will cause a fallback.
Something like 504 Gateway Timeout should not give a fallback.
The problem is that you are really guessing at what kinds of http
errors you are going to get from a dumb server when you try the
smart URL.
I dug back into the list thread that spawned the retry
without query string patch (703e6e7).
The thread is here:
http://thread.gmane.org/gmane.comp.version-control.git/137609
If you read the thread, it turns out that the problem in this case
(which is the only reported case I could find in the archive) is
that the server was misconfigured to treat _anything_ with a query
string as a gitweb URL. And then it got fixed pretty much
immediately.
So as far as we know, there may be zero servers for which this
fallback is actually doing anything useful.
I'm tempted to just reverse the logic.
After re-reading
[PATCH] Revert retry request without query when info/refs?query fails
From: Shawn O. Pearce spea...@spearce.org
This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7.
Retrying without the query parameter was added as a workaround
for a single broken HTTP server at git.debian.org[1]. The server
was misconfigured to route every request with a query parameter
into gitweb.cgi. Admins fixed the server's configuration within
16 hours of the bug report to the Git mailing list, but we still
patched Git with this fallback and have been paying for it since.
Most Git hosting services configure the smart HTTP protocol and the
retry logic confuses users when there is a transient HTTP error as
Git dropped the real error from the smart HTTP request. Removing the
retry makes root causes easier to identify.
[1] http://thread.gmane.org/gmane.comp.version-control.git/137609
Signed-off-by: Shawn O. Pearce spea...@spearce.org
---
remote-curl.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 3ec474f..2359f59 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -95,7 +95,7 @@ static struct discovery* discover_refs(const char *service)
struct strbuf buffer = STRBUF_INIT;
struct discovery *last = last_discovery;
char *refs_url;
- int http_ret, is_http = 0, proto_git_candidate = 1;
+ int http_ret, is_http = 0;
if (last !strcmp(service, last-service))
return last;
@@ -113,19 +113,6 @@ static struct discovery* discover_refs(const char *service)
refs_url = strbuf_detach(buffer, NULL);
http_ret = http_get_strbuf(refs_url, buffer, HTTP_NO_CACHE);
-
- /* try again with plain url (no ? or appended) */
- if (http_ret != HTTP_OK http_ret != HTTP_NOAUTH) {
- free(refs_url);
- strbuf_reset(buffer);
-
- proto_git_candidate = 0;
- strbuf_addf(buffer, %sinfo/refs, url);
- refs_url = strbuf_detach(buffer, NULL);
-
- http_ret = http_get_strbuf(refs_url, buffer, HTTP_NO_CACHE);
- }
-
switch (http_ret) {
case HTTP_OK:
break;
@@ -144,8 +131,7 @@ static struct discovery* discover_refs(const char *service)
last-buf_alloc = strbuf_detach(buffer, last-len);
last-buf = last-buf_alloc;
- if (is_http proto_git_candidate
-5 = last-len last-buf[4] == '#') {
+ if (is_http 5 = last-len last-buf[4] == '#') {
/* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
--
1.7.12.1.512.g9b230e6
--
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
