Re: [PATCH] Documentation: indent-with-non-tab uses tabwidth setting, not just 8
Junio C Hamano gits...@pobox.com writes: @@ -559,8 +559,8 @@ core.whitespace:: * `space-before-tab` treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default). -* `indent-with-non-tab` treats a line that is indented with 8 or more - space characters as an error (not enabled by default). +* `indent-with-non-tab` treats a line that is indented with `tabwidth` space + characters or more as an error (not enabled by default). I would rather see this part left untouched. Your new text will force people who are not interested in using non-standard tab width to read through the bulletted list, only to find The default tab width is 8. I think that is a regression in the documentation for more common readers. When somebody wants to use `indent-with-non-tab` and gets offended by the seemingly hardcoded 8 in the description, the reader has incentive to find out if there is a way to change that 8, and will find `tabwidth=n` in the same bulletted list described, with the effect it has on both `indent-with-non-tab` and `tab-in-indent`. I think that should be sufficient for people who do use non-standard tab width using tabwidth=n. An alternative would be to lose the 8 (or `tabwidth`) from that description. I've always thought that the description of `tabwidth` is clear enough that 8 in the patch is not a hardcoded non-overridable value but is merely a default, but after reading that section a few more times, I no longer think that is the case. I originally wrote 8 or more space but that wasn't because I thought it was important to stress 8 is the default, but because I didn't think of a better way to say what I wanted to say, which was if you are filling the indentation with spaces when you could have just typed a tab with a few spaces, this error triggers, in other words use of this is to encourage indenting with tabs. -- 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/3] rebase -i: Teach --edit-todo action
On Sun, Sep 16, 2012 at 8:17 AM, Andrew Wong andrew.k...@gmail.com wrote:
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index fd535b0..da067ec 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -12,7 +12,7 @@ SYNOPSIS
[upstream] [branch]
'git rebase' [-i | --interactive] [options] [--exec cmd] [--onto newbase]
--root [branch]
-'git rebase' --continue | --skip | --abort
+'git rebase' --continue | --skip | --abort | --edit-todo
I guess you should add --edit-todo to OPTIONS_SPEC in git-rebase.sh as
well. The OPTIONS_SPEC needs another little update too. I have
included a patch at the end of this email that you include in a
re-roll.
+ git_sequence_editor $todo ||
+ die_abort Could not execute editor
die_abort seems a little harsh -- it will discard the rebase state.
Plain die would be better, I think.
Also, if you even need to break the line after the || operator, you
might want to indent the remainder by one tab. This file is quite
consistent in using that style, although I don't know what the
preferred style is in general in git.
git var GIT_COMMITTER_IDENT /dev/null ||
diff --git a/git-rebase.sh b/git-rebase.sh
index 15da926..e5a289c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -194,6 +195,10 @@ do
test $total_argc -eq 2 || usage
action=${1##--}
;;
+ --edit-todo)
+ test $total_argc -eq 2 || usage
+ action=${1##--}
+ ;;
It looks like this could be trivially combined with the previous case
arm, making the match --continue|--skip|--abort|--edit-todo).
--8--
Author: Martin von Zweigbergk martinv...@gmail.com
rebase usage: subcommands can not be combined with -i
Since 95135b0 (rebase: stricter check of standalone sub command,
2011-02-06), git-rebase has not allowed to use -i together with
e.g. --continue. Yet, when rebase started using OPTIONS_SPEC in
45e2acf (rebase: define options in OPTIONS_SPEC, 2011-02-28), the
usage message included
git-rebase [-i] --continue | --abort | --skip
Remove the [-i] from this line.
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
diff --git a/git-rebase.sh b/git-rebase.sh
index 15da926..e6b43a2 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -8,7 +8,7 @@ OPTIONS_KEEPDASHDASH=
OPTIONS_SPEC=\
git rebase [-i] [options] [--exec cmd] [--onto newbase]
[upstream] [branch]
git rebase [-i] [options] [--exec cmd] [--onto newbase] --root [branch]
-git-rebase [-i] --continue | --abort | --skip
+git-rebase --continue | --abort | --skip
--
Available options are
v,verbose! display a diffstat of what changed upstream
--
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 v6 0/4] Support non-WIN32 systems lacking poll()
Here's now my updated series of patches to make the win32 implementation of poll() available to other platforms: 1 - make poll available for other platforms lacking it by moving it into a separate directory and adjusting Makefile 2 - fix some win32 specific dependencies in poll.c by #ifdef the inclusion of two header files 3 - poll() exits too early with EFAULT if 1st arg is NULL, as fixed in gnulib recently 4 - make poll() work on platforms that can't recv() on a non-socket, namely HP NonStop, as fixed in gnulib recently Bye, Jojo -- 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] git-jump: ignore (custom) prefix in diff mode
Mischa POSLAWSKY g...@shiar.nl wrote: ... I would argue against diff options creating non-standard patches. Seems to me it might depend on what one means by non-standard. I can envision cases in which increasing the number of context lines would result in the patch being more robust WRT applying correctly to a recipient's version that might be a bit different than the one against which it was created. OTOH one most likely does not want to create a patch with -b unless the apply tool also supports such and there is a way to communicate to the apply tool that -b was used in creating the 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
[PATCH v6 1/4] make poll available for other platforms lacking it
move poll.[ch] out of compat/win32/ into compat/poll/ and adjust
Makefile with the changed paths. Adding comments to Makefile about how/when
to enable it and add logic for this
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
Makefile | 20 +++-
compat/{win32 = poll}/poll.c | 0
compat/{win32 = poll}/poll.h | 0
3 files changed, 15 insertions(+), 5 deletions(-)
rename compat/{win32 = poll}/poll.c (100%)
rename compat/{win32 = poll}/poll.h (100%)
diff --git a/Makefile b/Makefile
index ac49320..7893297 100644
--- a/Makefile
+++ b/Makefile
@@ -152,6 +152,11 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_SYS_POLL_H if you don't have sys/poll.h.
+#
+# Define NO_POLL if you do not have or don't want to use poll().
+# This also implies NO_SYS_POLL_H.
+#
# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
@@ -598,10 +603,10 @@ LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
+LIB_H += compat/poll/poll.h
LIB_H += compat/precompose_utf8.h
LIB_H += compat/terminal.h
LIB_H += compat/win32/dirent.h
-LIB_H += compat/win32/poll.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
LIB_H += connected.h
@@ -1220,7 +1225,7 @@ ifeq ($(uname_S),Windows)
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
NO_UNIX_SOCKETS = YesPlease
@@ -1261,7 +1266,7 @@ ifeq ($(uname_S),Windows)
BASIC_CFLAGS
= -nologo -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE
-DHAVE_STRING_H
-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
COMPAT_OBJS = compat/msvc.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
COMPAT_CFLAGS
= -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/regex
-Icompat/win32
-DSTRIP_EXTENSION=\.exe\
BASIC_LDFLAGS
= -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
@@ -1316,7 +1321,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_UNIX_SOCKETS = YesPlease
NO_SETENV = YesPlease
@@ -1351,7 +1356,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\.exe\
COMPAT_OBJS += compat/mingw.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
EXTLIBS += -lws2_32
PTHREAD_LIBS =
X = .exe
@@ -1605,6 +1610,11 @@ ifdef NO_GETTEXT
BASIC_CFLAGS += -DNO_GETTEXT
USE_GETTEXT_SCHEME ?= fallthrough
endif
+ifdef NO_POLL
+ NO_SYS_POLL_H = YesPlease
+ COMPAT_CFLAGS += -DNO_POLL -Icompat/poll
+ COMPAT_OBJS += compat/poll/poll.o
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/compat/win32/poll.c b/compat/poll/poll.c
similarity index 100%
rename from compat/win32/poll.c
rename to compat/poll/poll.c
diff --git a/compat/win32/poll.h b/compat/poll/poll.h
similarity index 100%
rename from compat/win32/poll.h
rename to compat/poll/poll.h
--
1.7.12
--
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 v6 2/4] fix some win32 specific dependencies in poll.c
In order for non-win32 platforms to be able to use poll.c, #ifdef the inclusion of two header files in the same manner as it's done elsewhere in git. Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- compat/poll/poll.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index 9e7a25c..e4b8319 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -24,7 +24,9 @@ # pragma GCC diagnostic ignored -Wtype-limits #endif -#include malloc.h +#if defined(WIN32) +# include malloc.h +#endif #include sys/types.h @@ -48,7 +50,9 @@ #else # include sys/time.h # include sys/socket.h -# include sys/select.h +# ifndef NO_SYS_SELECT_H +# include sys/select.h +# endif # include unistd.h #endif -- 1.7.12 -- 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 v6 3/4] poll() exits too early with EFAULT if 1st arg is NULL
If poll() is used as a milli-second sleep, like in help.c, by passing a NULL
in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be fixed
like
in this commit, which is not to exit if the 2nd arg is 0. It got fixed in
gnulib in the same manner the other day.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
compat/poll/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/poll/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -349,7 +349,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd nfd)
{
errno = EFAULT;
return -1;
--
1.7.12
--
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: What's cooking in git.git (Sep 2012, #05; Fri, 14)
From: Joachim Schmitz [mailto:j...@schmitz-digital.de] Sent: Saturday, September 15, 2012 7:15 PM To: 'Junio C Hamano' Cc: 'git@vger.kernel.org' Subject: RE: What's cooking in git.git (Sep 2012, #05; Fri, 14) From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Saturday, September 15, 2012 7:01 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: What's cooking in git.git (Sep 2012, #05; Fri, 14) Joachim Schmitz j...@schmitz-digital.de writes: Junio C Hamano wrote: I think we can start thinking about feature freeze once the topics in 'next' that are scheduled to graduate to 'master' already are fully cooked. For any late-coming topic, there always is the next cycle ;-) I've not hear anything about my poll patches and I'd really like them to into 1.8.x. I've seen some patches on poll posted, were discussed and had threads titled Re: [PATCH] But I didn't see a rerolled [PATCH v2 n/m] ... series that states that it is a rerolled hopefully final version that addresses all the points that were brought up during the discussion that need to be addressed. I do not necessarily follow all the minute details of all discussion threads. For this particular series, I not know which ones of your poll patches turned out to be unneeded, which ones turned out to be fine as posted originally and which ones needed updating. There were several iterations up to [PATCH v4 n/4] and only one foreign comment to it (and to some commented code) and one self- comment about the order of patches, but none about technical correctness, none that I remember at least. I can post a v5 series which will Actually v6, seems I got myself confused in what I send already, one part of the series was on v5 already, aother on v4 and yet another still on v3. - move compat/win32/poll.[ch] to compat/poll/ and adjust Makefile - #ifdef some WIN32 specific #include (should this be done in one step with the above?) Decided for 2 patches - fix the 2 bugs in poll.c just like they got fixed in gnulib's version (would you want this in one or two steps?) Likewise Bye, Jojo -- 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 01/12] git p4 test: remove bash-ism of combined export/assignment
On 17/09/12 05:50, Junio C Hamano wrote: Luke Diamandl...@diamand.org writes: On 16/09/12 07:05, Junio C Hamano wrote: Luke Diamandl...@diamand.org writes: Looks good to me, ack. Thanks; is this an ack for the entire series, or are you expecting further back-and-forth with Pete before the whole thing is ready? An ack for the whole series. I'm just going through the rest of the patches now but I don't expect to find any issues. As long as the parties involved in the part of the system can agree that this series is basically sound, I'd be happy to merge it down. Minor issues can be fixed up as follow-up patches. Basically sound as far as I'm concerned. Thanks. Will merge it to 'next'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] Make Git::SVN use accessors internally for path.
Hi Eric et al,
Michael G. Schwern wrote:
Then later it can be canonicalized automatically rather than everywhere
its used.
Later patch will make other things use it.
Wow am I slow. I've finally got around to starting to parse these
patches to apply to a 1.7.10.y tree so they can (hopefully) be part of
Debian 7.0 when it comes out.
Do I understand correctly that this patch splits logically into the
following steps? The result is only cosmetically different from the
original patch --- interdiff below the shortlog.
The completeness of the conversion to accessors is checked by renaming
the underlying variable in patch 5.
Jonathan Nieder (1):
Git::SVN: rename private path field
Michael G. Schwern (4):
Git::SVN: introduce path accessor
Git::SVN: use accessor to read path
Git::SVN: use accessor to write path
Git::SVN::_new: use accessor to write path field
git-svn.perl| 12 +++
perl/Git/SVN.pm | 84 ---
perl/Git/SVN/Fetcher.pm |2 +-
perl/Git/SVN/Ra.pm |8 ++---
4 files changed, 62 insertions(+), 44 deletions(-)
---
diff --git c/git-svn.perl w/git-svn.perl
index 5711c571..af7d5308 100755
--- c/git-svn.perl
+++ w/git-svn.perl
@@ -1195,7 +1195,7 @@ sub cmd_show_ignore {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
$gs ||= Git::SVN-new;
my $r = (defined $_revision ? $_revision : $gs-ra-get_latest_revnum);
- $gs-prop_walk($gs-{path}, $r, sub {
+ $gs-prop_walk($gs-path, $r, sub {
my ($gs, $path, $props) = @_;
print STDOUT \n# $path\n;
my $s = $props-{'svn:ignore'} or return;
@@ -1211,7 +1211,7 @@ sub cmd_show_externals {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
$gs ||= Git::SVN-new;
my $r = (defined $_revision ? $_revision : $gs-ra-get_latest_revnum);
- $gs-prop_walk($gs-{path}, $r, sub {
+ $gs-prop_walk($gs-path, $r, sub {
my ($gs, $path, $props) = @_;
print STDOUT \n# $path\n;
my $s = $props-{'svn:externals'} or return;
@@ -1226,7 +1226,7 @@ sub cmd_create_ignore {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
$gs ||= Git::SVN-new;
my $r = (defined $_revision ? $_revision : $gs-ra-get_latest_revnum);
- $gs-prop_walk($gs-{path}, $r, sub {
+ $gs-prop_walk($gs-path, $r, sub {
my ($gs, $path, $props) = @_;
# $path is of the form /path/to/dir/
$path = '.' . $path;
@@ -1294,7 +1294,7 @@ sub get_svnprops {
$path = $cmd_dir_prefix . $path;
fatal(No such file or directory: $path) unless -e $path;
my $is_dir = -d $path ? 1 : 0;
- $path = $gs-{path} . '/' . $path;
+ $path = $gs-path . '/' . $path;
# canonicalize the path (otherwise libsvn will abort or fail to
# find the file)
@@ -1396,7 +1396,7 @@ sub cmd_commit_diff {
the command-line\n, $usage);
}
$url = $gs-{url};
- $svn_path = $gs-{path};
+ $svn_path = $gs-path;
}
unless (defined $_revision) {
fatal(-r|--revision is a required argument\n, $usage);
@@ -1670,7 +1670,7 @@ sub complete_url_ls_init {
wanted to set to: $gs-{url}\n;
}
command_oneline('config', $k, $gs-{url}) unless $orig_url;
- my $remote_path = $gs-{path}/$repo_path;
+ my $remote_path = $gs-path . /$repo_path;
$remote_path =~ s{%([0-9A-F]{2})}{chr hex($1)}ieg;
$remote_path =~ s#/+#/#g;
$remote_path =~ s#^/##g;
diff --git c/perl/Git/SVN.pm w/perl/Git/SVN.pm
index a93ac61b..3aa20109 100644
--- c/perl/Git/SVN.pm
+++ w/perl/Git/SVN.pm
@@ -437,22 +437,19 @@ sub new {
}
}
my $self = _new($class, $repo_id, $ref_id, $path);
- if (!defined $self-path || !length $self-path) {
+ $path = $self-path;
+ if (!defined $path || !length $path) {
my $fetch = command_oneline('config', '--get',
svn-remote.$repo_id.fetch,
:$ref_id\$) or
die Failed to read \svn-remote.$repo_id.fetch\ ,
\:$ref_id\$\ in config\n;
- my($path) = split(/\s*:\s*/, $fetch);
- $self-path($path);
- }
- {
- my $path = $self-path;
- $path =~ s{/+}{/}g;
- $path =~ s{\A/}{};
- $path =~ s{/\z}{};
- $self-path($path);
+ ($path, undef) = split(/\s*:\s*/, $fetch);
}
+ $path =~ s{/+}{/}g;
+ $path =~ s{\A/}{};
+ $path =~ s{/\z}{};
+ $self-path($path);
$self-{url} = command_oneline('config', '--get',
svn-remote.$repo_id.url) or
[FYI/PATCH 2/5] Git::SVN: use accessor to read path
From: Michael G. Schwern schw...@pobox.com
Date: Fri, 27 Jul 2012 13:00:48 -0700
This patch only touches the simplest cases that simply read the
Git::SVN field rather than assigning to or applying a substitution to
it.
Code to change found by searching for the term {path}.
[jn: extracted from a larger patch]
Signed-off-by: Eric Wong normalper...@yhbt.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
git-svn.perl| 12 ++--
perl/Git/SVN.pm | 44 ++--
perl/Git/SVN/Fetcher.pm |2 +-
perl/Git/SVN/Ra.pm |8
4 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 5711c571..af7d5308 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1195,7 +1195,7 @@ sub cmd_show_ignore {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
$gs ||= Git::SVN-new;
my $r = (defined $_revision ? $_revision : $gs-ra-get_latest_revnum);
- $gs-prop_walk($gs-{path}, $r, sub {
+ $gs-prop_walk($gs-path, $r, sub {
my ($gs, $path, $props) = @_;
print STDOUT \n# $path\n;
my $s = $props-{'svn:ignore'} or return;
@@ -1211,7 +1211,7 @@ sub cmd_show_externals {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
$gs ||= Git::SVN-new;
my $r = (defined $_revision ? $_revision : $gs-ra-get_latest_revnum);
- $gs-prop_walk($gs-{path}, $r, sub {
+ $gs-prop_walk($gs-path, $r, sub {
my ($gs, $path, $props) = @_;
print STDOUT \n# $path\n;
my $s = $props-{'svn:externals'} or return;
@@ -1226,7 +1226,7 @@ sub cmd_create_ignore {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
$gs ||= Git::SVN-new;
my $r = (defined $_revision ? $_revision : $gs-ra-get_latest_revnum);
- $gs-prop_walk($gs-{path}, $r, sub {
+ $gs-prop_walk($gs-path, $r, sub {
my ($gs, $path, $props) = @_;
# $path is of the form /path/to/dir/
$path = '.' . $path;
@@ -1294,7 +1294,7 @@ sub get_svnprops {
$path = $cmd_dir_prefix . $path;
fatal(No such file or directory: $path) unless -e $path;
my $is_dir = -d $path ? 1 : 0;
- $path = $gs-{path} . '/' . $path;
+ $path = $gs-path . '/' . $path;
# canonicalize the path (otherwise libsvn will abort or fail to
# find the file)
@@ -1396,7 +1396,7 @@ sub cmd_commit_diff {
the command-line\n, $usage);
}
$url = $gs-{url};
- $svn_path = $gs-{path};
+ $svn_path = $gs-path;
}
unless (defined $_revision) {
fatal(-r|--revision is a required argument\n, $usage);
@@ -1670,7 +1670,7 @@ sub complete_url_ls_init {
wanted to set to: $gs-{url}\n;
}
command_oneline('config', $k, $gs-{url}) unless $orig_url;
- my $remote_path = $gs-{path}/$repo_path;
+ my $remote_path = $gs-path . /$repo_path;
$remote_path =~ s{%([0-9A-F]{2})}{chr hex($1)}ieg;
$remote_path =~ s#/+#/#g;
$remote_path =~ s#^/##g;
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 268e0e84..02d5abc0 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -314,7 +314,7 @@ sub init_remote_config {
print STDERR Using higher level of URL: ,
$url = $min_url\n;
}
- my $old_path = $self-{path};
+ my $old_path = $self-path;
$self-{path} = $url;
$self-{path} =~ s!^\Q$min_url\E(/|$)!!;
if (length $old_path) {
@@ -347,7 +347,7 @@ sub init_remote_config {
$self-{path} =~ s{%([0-9A-F]{2})}{chr hex($1)}ieg;
command_noisy('config', '--add',
svn-remote.$self-{repo_id}.fetch,
- $self-{path}:.$self-refname);
+ $self-path.:.$self-refname);
}
$self-{url} = $url;
}
@@ -435,7 +435,7 @@ sub new {
}
}
my $self = _new($class, $repo_id, $ref_id, $path);
- if (!defined $self-{path} || !length $self-{path}) {
+ if (!defined $self-path || !length $self-path) {
my $fetch = command_oneline('config', '--get',
svn-remote.$repo_id.fetch,
:$ref_id\$) or
@@ -567,7 +567,7 @@ sub _set_svm_vars {
}
my $r = $ra-get_latest_revnum;
- my $path = $self-{path};
+ my $path = $self-path;
my %tried;
while (length $path) {
unless ($tried{$self-{url}/$path}) {
@@ -728,7 +728,7 @@ sub prop_walk {
$path =~ s#^/*#/#g;
my $p = $path;
[FYI/PATCH 4/5] Git::SVN::_new: use accessor to write path field
From: Michael G. Schwern schw...@pobox.com
Date: Fri, 27 Jul 2012 13:00:48 -0700
If some day the setter is taught to canonicalize paths, make sure the
path gets canonicalized at construction time, too.
[jn: split from a larger patch]
Signed-off-by: Eric Wong normalper...@yhbt.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
perl/Git/SVN.pm |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 826a7fa6..3aa20109 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -2280,10 +2280,12 @@ sub _new {
$_[3] = $path = '' unless (defined $path);
mkpath([$dir]);
- bless {
+ my $obj = bless {
ref_id = $ref_id, dir = $dir, index = $dir/index,
- path = $path, config = $ENV{GIT_DIR}/svn/config,
+ config = $ENV{GIT_DIR}/svn/config,
map_root = $dir/.rev_map, repo_id = $repo_id }, $class;
+ $obj-path($path);
+ return $obj;
}
sub path {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failing svn imports from apache.org
Hi Enrico, Repositories as old and large as ASF are the reason I created svn-fe. git-svn is known to choke on these repositories. If you have plenty of bandwidth, it might well be faster to: * Grab an ASF archive (16GB) * Use svn-fe to import the entire tree into git. * Use a simple script to extract the standard layout into a new repo. * Use git-svn to keep the new repo up-to-date. -- David Michael Barr On Saturday, 15 September 2012 at 8:07 PM, Enrico Weigelt wrote: Does anyone have an idea, what might be wrong here / how to fix it ? Here: git svn --version git-svn version 1.7.12.592.g41e7905 (svn 1.6.18) What's yours? 1.7.9.5 (ubuntu precise) I'm getting Initialized empty Git repository in /tmp/discovery/.git/ Using higher level of URL: http://svn.apache.org/repos/asf/commons/proper/discovery = http://svn.apache.org/repos/asf W: Ignoring error from SVN, path probably does not exist: (160013): Dateisystem hat keinen Eintrag: File not found: revision 100, path '/commons/proper/discovery' W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. This may take a while on large repositories and then it checks the revisions. I didn't want to wait for r1301705... Does your git svn abort earlier or after checking all revs? It also scanned through thousands of revisions and then failed: W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. This may take a while on large repositories mkdir .git: No such file or directory at /usr/lib/git-core/git-svn line 3669 cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de (http://www.vnc.de) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org (mailto:majord...@vger.kernel.org) More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add missing -z to git check-attr usage text for consistency with man page
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/check-attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index e1ff575..075d01d 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -9,7 +9,7 @@ static int cached_attrs;
static int stdin_paths;
static const char * const check_attr_usage[] = {
N_(git check-attr [-a | --all | attr...] [--] pathname...),
-N_(git check-attr --stdin [-a | --all | attr...] list-of-paths),
+N_(git check-attr --stdin [-z] [-a | --all | attr...] list-of-paths),
NULL
};
--
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] Make test output coloring more intuitive
1. Change the color of individual known breakages from bold green to
bold yellow. This seems more appropriate 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.
2. 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.
3. Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test is wrong or the
semantics of the code being tested have changed. Either way this
is an error which is arguably as bad as a failing test, and as such
is now counted in the totals too.
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.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 7 ---
t/test-lib.sh| 13 -
2 files changed, 12 insertions(+), 8 deletions(-)
mode change 100644 = 100755 t/test-lib.sh
diff --git a/t/t-basic.sh b/t/t-basic.sh
index ae6a3f0..4e111b4 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -81,9 +81,10 @@ test_expect_success 'pretend we have fixed a known breakage
(run in sub test-lib
./passing-todo.sh out 2err
! test -s err
sed -e 's/^ //' expect -\\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
+# fixed 1 known breakage(s); please update test(s)
+# still have 1 known breakage(s)
+# passed all remaining 0 test(s)
1..1
EOF
test_cmp expect out)
diff --git a/t/test-lib.sh b/t/test-lib.sh
old mode 100644
new mode 100755
index f8e3733..9907035
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -183,10 +183,12 @@ 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)
- tput setaf 3;;# brown
+ tput setaf 3;;# yellow/brown
*)
test -n $quiet return;;
esac
@@ -276,12 +278,13 @@ test_failure_ () {
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
- say_color ok $test_count - $@ # TODO known breakage
+ test_broken=$(($test_broken+1))
+ say_color error ok $test_count - $@ # TODO known breakage vanished
}
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 () {
@@ -371,11 +374,11 @@ test_done () {
if test $test_fixed != 0
then
- say_color pass # fixed $test_fixed known breakage(s)
+ say_color error # fixed $test_fixed known breakage(s); please
update test(s)
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
Re: [PATCHv4] clone --single: limit the fetch refspec to fetched branch
On Sun, Sep 16, 2012 at 3:13 PM, Ralf Thielow ralf.thie...@gmail.com wrote:
+ if (option_mirror || !option_bare) {
+ strbuf_reset(value);
I think we should use a new strbuf local variable here to avoid
resetting this. At least reviewers don't have to check if this
statememt causes any effect later on because value's value is gone.
+ if (option_single_branch) {
+ if (option_branch)
+ strbuf_addf(value, +%s%s:%s%s,
+ src_ref_prefix, option_branch,
+ 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/));
+ /*
+* otherwise, the next git fetch will
+* simply fetch from HEAD without updating
+* any remote tracking branch, which is what
+* we want.
+*/
Maybe document updates too? Though if it's obvious that
--single-branch should prepare refspec so that only one branch is
fetched later on, then maybe not.
+ } else {
+ strbuf_addf(value, +%s*:%s*, src_ref_prefix,
branch_top.buf);
+ }
--mirror --single-branch combination does not look right. The heads/
part is missing..
$ git branch
master * wildmatch
$ LANG=C ./git clone --mirror --single-branch .git abc
Cloning into bare repository 'abc'...
done.
$ grep fetch abc/config
fetch = +refs/heads/wildmatch:refs/wildmatch
$ rm -rf abc
$ LANG=C ./git clone --mirror --single-branch --branch=master .git abc
Cloning into bare repository 'abc'...
done.
$ grep fetch abc/config
fetch = +refs/master:refs/master
--
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: [PATCH v3 05/14] Change fetch_pack() and friends to take string_list arguments
On 09/10/2012 10:56 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
diff --git a/fetch-pack.h b/fetch-pack.h
index 1dbe90f..a6a8a73 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -1,6 +1,8 @@
#ifndef FETCH_PACK_H
#define FETCH_PACK_H
+#include string-list.h
+
struct fetch_pack_args {
const char *uploadpack;
int unpacklimit;
@@ -21,8 +23,7 @@ struct ref *fetch_pack(struct fetch_pack_args *args,
int fd[], struct child_process *conn,
const struct ref *ref,
const char *dest,
- int nr_heads,
- char **heads,
+ struct string_list *sought,
char **pack_lockfile);
This is a tangent, but I _think_ our header files ignore the dogma
some other projects follow that insists on each header file to be
self sufficient, i.e.
gcc fetch-pack.h
should pass. Instead, our *.c files that include fetch-pack.h are
responsible for including everything the headers they include need.
So even though fetch-pack.h does not include run-command.h, it
declares a function that takes struct child_process * in its
arguments. The new struct string_list * falls into the same camp.
Given that, I'd prefer to see the scope of this patch series shrunk
and have the caller include string-list.h, not here.
Updating the headers and sources so that each to be self sufficient
is a different topic, and I do not think there is a consensus yet if
we want to go that route.
The include line can just be deleted, because the three files that
include it already get string-list.h from somewhere:
* builtin/clone.c, builtin/fetch-pack.c
includes builtin.h
includes notes.h
includes string-list.h
* transport.c
includes string-list.h
Patch forthcoming.
But how far should this policy be taken? It seems to me that strict
adherence to the policy would dictate that *.h files should *never*
include other git project files.
For example, while working on this, I noticed that notes.h includes
string-list.h and also contains a forward declaration for struct
string_list. Obviously, the latter could be deleted. Alternatively,
both could probably be deleted by ensuring that the relevant *.c files
include string-list.h before including notes.h.
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: Using Format/export-subst Howto.
-Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Friday, September 14, 2012 4:24 PM To: Michael J Gruber Cc: Johannes Sixt; Mestnik, Michael J - Eagan, MN - Contractor; git@vger.kernel.org Subject: Re: Using Format/export-subst Howto. Michael J Gruber g...@drmicha.warpmail.net writes: you need to rm file git checkout file). If the user has to update $Id$ to match the current sha1 (by remembering to do a more forceful checkout than checkout -f) then one half of that feature is useless. As if there is any value in $Id$ _feature_. It's a checkbox item, nothing more ;-). I agree here, $Id$ is much more useful in rcs/cvs. That's why I chose to dive into export-subst, because I wanted my output to not only contain the uniq Id of the script but also the time and user of the last edit. I'm going to read up on export today. Just for context I'm using git to manage daily cron scripts, run on about 1,000 hosts, located on NFS. I've moved the editing of the scripts into user's home directories as I'm a fan of not using editors on live data. The key point is that when sudoing to the shared user who manages the files the commands run should be minimal and pushd; ln -s ... .git; git pull; rm .git; popd; works well. If I can replace this with something that would populate these fields that would be awesome. Cheers. Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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 4/5] Integrate wildmatch to git
On Sun, Sep 16, 2012 at 10:54:57PM -0700, Junio C Hamano wrote:
Yeah, popt.h it is. It is a bit distasteful that we have a build
dependency only to build test-* helper on something that we do not
even have runtime dependency on.
Perhaps this squash-in? It kills libpopt and removes the #include
wildmatch.c. Now we really do test what libgit.a carries.
-- 8 --
diff --git a/Makefile b/Makefile
index 745e88c..093ab9c 100644
--- a/Makefile
+++ b/Makefile
@@ -2589,9 +2589,6 @@ test-svn-fe$X: vcs-svn/lib.a
test-%$X: test-%.o GIT-LDFLAGS $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^)
$(filter %.a,$^) $(LIBS)
-test-wildmatch$X: test-wildmatch.o GIT-LDFLAGS
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^)
-lpopt
-
check-sha1:: test-sha1$X
./test-sha1.sh
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 828188a..b94921b 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -19,17 +19,18 @@
/*#define COMPARE_WITH_FNMATCH*/
-#define WILD_TEST_ITERATIONS
-#include wildmatch.c
+#include cache.h
+#include parse-options.h
+#include wildmatch.h
+#ifndef MAXPATHLEN
#define MAXPATHLEN 1024
+#endif
#ifdef NO_STRLCPY
#include compat/strlcpy.c
#define strlcpy gitstrlcpy
#endif
-#include popt.h
-
#ifdef COMPARE_WITH_FNMATCH
#include fnmatch.h
@@ -41,18 +42,16 @@ char number_separator = ',';
typedef char bool;
-int output_iterations = 0;
int explode_mod = 0;
int empties_mod = 0;
int empty_at_start = 0;
int empty_at_end = 0;
+char *empties;
-static struct poptOption long_options[] = {
- /* longName, shortName, argInfo, argPtr, value, descrip, argDesc */
- {iterations, 'i', POPT_ARG_NONE, output_iterations, 0, 0, 0},
- {empties,'e', POPT_ARG_STRING, 0, 'e', 0, 0},
- {explode,'x', POPT_ARG_INT,explode_mod, 0, 0, 0},
- {0,0,0,0, 0, 0, 0}
+static struct option options[] = {
+ OPT_STRING('e', empties, empties, , ),
+ OPT_INTEGER('x', explode, explode_mod, ),
+ OPT_END(),
};
/* match just at the start of string (anchored tests) */
@@ -106,51 +105,33 @@ run_test(int line, bool matches,
fnmatch_errors++;
}
#endif
-if (output_iterations) {
- printf(%d: \%s\ iterations = %d\n, line, pattern,
- wildmatch_iteration_count);
-}
}
int
main(int argc, char **argv)
{
char buf[2048], *s, *string[2], *end[2];
-const char *arg;
FILE *fp;
-int opt, line, i, flag[2];
-poptContext pc = poptGetContext(wildtest, argc, (const char**)argv,
- long_options, 0);
-
-while ((opt = poptGetNextOpt(pc)) != -1) {
- switch (opt) {
- case 'e':
- arg = poptGetOptArg(pc);
- empties_mod = atoi(arg);
- if (strchr(arg, 's'))
- empty_at_start = 1;
- if (strchr(arg, 'e'))
- empty_at_end = 1;
- if (!explode_mod)
- explode_mod = 1024;
- break;
- default:
- fprintf(stderr, %s: %s\n,
- poptBadOption(pc, POPT_BADOPTION_NOALIAS),
- poptStrerror(opt));
- exit(1);
- }
+int line, i, flag[2];
+const char *help[] = { NULL };
+
+argc = parse_options(argc, (const char **)argv, , options, help, 0);
+if (argc != 1)
+ die(redundant options);
+if (empties) {
+ const char *arg = empties;
+ empties_mod = atoi(arg);
+ if (strchr(empties, 's'))
+ empty_at_start = 1;
+ if (strchr(arg, 'e'))
+ empty_at_end = 1;
+ if (!explode_mod)
+ explode_mod = 1024;
}
if (explode_mod !empties_mod)
empties_mod = 1024;
-argv = (char**)poptGetArgs(pc);
-if (!argv || argv[1]) {
- fprintf(stderr, Usage: wildtest [OPTIONS] TESTFILE\n);
- exit(1);
-}
-
if ((fp = fopen(*argv, r)) == NULL) {
fprintf(stderr, Unable to open %s\n, *argv);
exit(1);
diff --git a/wildmatch.c b/wildmatch.c
index 625cb0c..f153f8a 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -59,10 +59,6 @@ typedef unsigned char uchar;
#define ISUPPER(c) (ISASCII(c) isupper(c))
#define ISXDIGIT(c) (ISASCII(c) isxdigit(c))
-#ifdef WILD_TEST_ITERATIONS
-int wildmatch_iteration_count;
-#endif
-
/* Match pattern p against the a virtually-joined string consisting
* of text and any strings in array a. */
static int dowild(const uchar *p, const uchar *text,
@@ -70,10 +66,6 @@ static int dowild(const uchar *p, const uchar *text,
{
uchar p_ch;
-#ifdef WILD_TEST_ITERATIONS
-wildmatch_iteration_count++;
-#endif
-
for ( ; (p_ch = *p) != '\0'; text++, p++) {
int matched, special;
uchar t_ch, prev_ch;
@@ -295,9 +287,6 @@ static const uchar *trailing_N_elements(const uchar*const
**a_ptr, int count)
int wildmatch(const char *pattern, const char *text)
{
static const uchar *nomore[1]; /* A NULL pointer. */
-#ifdef
Re: [PATCH v3 00/14] Clean up how fetch_pack() handles the heads list
On 09/11/2012 12:10 AM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: OK. As long as the sort order matches the order string-list internally uses for its bisection search, it won't be a problem, then. The sorting is crucial but there is no bisection involved. The sorted linked-list of references available from the remote and the sorted string_list of requested references are iterated through in parallel. What I meant was that the order used by string-list is pretty much internal to string-list implementation for its quickly locate where to insert bisection. It happens to be the byte value order, I think, but the point is whatever order it is, that has to match the order we keep references in the other data source you walk in parallel to match (i.e. the linked list of references). Yes, your point is good that the two sort orders have to agree. Currently, they both use strcmp() order, so the situation is OK. It is interesting that you consider the sort order of string_list to be somewhat of an internal implementation detail. I had thought of its current behavior as being the obvious thing and considered it part of the API's contract. For example, the current sort order is already observable via the API through iteration or by calling print_string_list(). Therefore I think that we should document the strcmp() sort order as part of the string_list contract. Patch coming soon. If, at some future time, somebody wants a string_list that is sorted by a different criterion, then the order should be determined via a callback function specified by the user. The callback function could even be stored in the string_list header, to allow such lists to be used in combination with the functions for sorted lists only. 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
Test failure: Test #3 in t1304-default-acl
Hi,
The following test in t1304-default-acl.sh fails for me on the latest master:
test_expect_success SETFACL 'Objects creation does not break ACLs with
restrictive umask' '
# SHA1 for empty blob
check_perms_and_acl
.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
'
It fails in the `grep -q user:${LOGNAME}:rwx actual` step, because
actual contains:
# file: .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
# owner: ramkum
# group: domain^users
user::r--
user:root:rwx #effective:r--
user:kseygold:rwx #effective:r--
group::---
mask::r--
other::---
I'm not sure who or what kseygold is. I haven't dug any deeper.
Thanks.
Ram
--
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: Using Format/export-subst Howto.
-Original Message- From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] Sent: Monday, September 17, 2012 9:21 AM To: Mestnik, Michael J - Eagan, MN - Contractor Cc: Junio C Hamano; Johannes Sixt; git@vger.kernel.org Subject: Re: Using Format/export-subst Howto. Mestnik, Michael J - Eagan, MN - Contractor venit, vidit, dixit 17.09.2012 16:08: -Original Message- From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] Sent: Monday, September 17, 2012 8:45 AM To: Mestnik, Michael J - Eagan, MN - Contractor Cc: Junio C Hamano; Johannes Sixt; git@vger.kernel.org Subject: Re: Using Format/export-subst Howto. Mestnik, Michael J - Eagan, MN - Contractor venit, vidit, dixit 17.09.2012 14:12: -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Friday, September 14, 2012 4:24 PM To: Michael J Gruber Cc: Johannes Sixt; Mestnik, Michael J - Eagan, MN - Contractor; git@vger.kernel.org Subject: Re: Using Format/export-subst Howto. Michael J Gruber g...@drmicha.warpmail.net writes: you need to rm file git checkout file). If the user has to update $Id$ to match the current sha1 (by remembering to do a more forceful checkout than checkout -f) then one half of that feature is useless. As if there is any value in $Id$ _feature_. It's a checkbox item, nothing more ;-). I agree here, $Id$ is much more useful in rcs/cvs. That's why I chose to dive into export-subst, because I wanted my output to not only contain the uniq Id of the script but also the time and user of the last edit. I'm going to read up on export today. Just for context I'm using git to manage daily cron scripts, run on about 1,000 hosts, located on NFS. I've moved the editing of the scripts into user's home directories as I'm a fan of not using editors on live data. The key point is that when sudoing to the shared user who manages the files the commands run should be minimal and pushd; ln -s ... .git; git pull; rm .git; popd; works well. If I can replace this with something that would populate these fields that would be awesome. I'm not completely sure about the setup, but something like GIT_DIR=fromthisrepo git archive usethisbranchortag | git tar -xf- -C thereyougo Yes, that's about what the man page says. I though I could pass --keep-newer-files to tar and that would prevent files from being re-created, but a git archive --format=tar HEAD | tar -tvv indicates that every file has the current date/time and not, for example, the time of the last commit that modified that file. Not only would pushing every file be undesirable it would also cause every server to pull every file and that's unacceptable. Another down side, or perhaps this is the downside, to this method is that it lacks any form of merge capability and will destroy local changes. I thought it's only a few files and you don't care about merging (in sudo), only about deploying a checkout, since you're removing the git dir. Allow me to explain. There was an issue with copying the .git folder to every host, we literally don't have the space for that and I wonder what happens when these files grow by a few hundred k. I had put in the symlink, but our replicator script was chocking on it. Thus I've resorted to not only using a symlink, but also removing it when not in use. Correcting these issues is lower priority then making the logs have all the information they need. Merging has been done when edits are needed ASAP and git becomes an after thought. I've done pushes from the live files too, though it is something that happens after an emergency. I know I've got a rather strange environment, most of it surprises me as well. It looks like I'll be doing this in a hook. BTW: I couldn't find git tar, if it exists that might be the way for me... Depending on what it would do. Oh yeah. Done too much git work lately. I know I keep using git help foo rather than man foo, but this one is new :) I just meant tar. Michael Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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: Test failure: Test #3 in t1304-default-acl
Matthieu Moy matthieu@grenoble-inp.fr writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Hi again,
Matthieu Moy wrote:
Does this user have the same UID as your usual user
(id kseygold; id $LOGNAME)?
Yes. What do you propose we do about the test?
On a GNU system, something like this should do the trick:
...
but it seems FreeBSD's getfacl doesn't have --numeric
(http://www.unix.com/man-page/FreeBSD/1/getfacl/), so to be portable, we
need some more surgery, like this:
--- a/t/t1304-default-acl.sh
+++ b/t/t1304-default-acl.sh
@@ -33,7 +33,10 @@ check_perms_and_acl () {
test -r $1
getfacl $1 actual
grep -q user:root:rwx actual
- grep -q user:${LOGNAME}:rwx actual
+ grep user:.*:rwx actual | grep -v 'user:root:' | \
+ cut -d : -f 2 | xargs id -u acl-uid
+ id -u actual-uid
+ test_cmp acl-uid actual-uid
egrep mask::?r-- actual /dev/null 21
grep -q group::--- actual || false
}
Can you check that this second patch fixes your problem?
I'm a bit hesitant to submit it to git.git, as I find it a bit too
hacky. What do other people think?
I haven't been paying attention, but does that mean on that system,
a total stranger kseygold can write, modify, and remove whatever Ram
owns? I am hoping that is not the case.
--
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: How do I run tests under Valgrind?
On Mon, Sep 17, 2012 at 07:55:24PM +0200, Johannes Sixt wrote: Am 17.09.2012 19:44, schrieb Jeff King: Oh, bleh. Stupid automatic --tee for valgrind. Try this: SHELL=/usr/bin/zsh -x ./t-basic.sh --valgrind I am also doing my tests with dash as my shell. You might try setting your SHELL to /bin/sh to see if it makes a difference. Shouldn't -v be used as well? Or is --valgrind different? It turns -v on automatically. -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: Test failure: Test #3 in t1304-default-acl
Matthieu Moy wrote: Junio C Hamano gits...@pobox.com writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram owns? I am hoping that is not the case. I can see two reasons for having the same UID for two login names: 1) the sysadmin really messed up, and as you say, a total stranger has complete ownership of your files. Ramkumar, you should check that this is not your case. 2) the sysadmin explicitely gave two login names to the same physical person, as kinds of aliases for the same UID (e.g. the person got married, changed her name and login, but expects ~oldlogin to continue working). I'm not sure how common this is, and to which extend we want to support this in our test scripts. On HP NonStop it is very common to have a user (form: GROUP.USER, case insensitiv) and one or more aliases to them (form: user, case sensitiv) the latter are very commonly used in the POSIX part of HP NonStop (call OSS), the one git runs in, the other are more commonly used in the proprietary part of the OS (called Guardian), althoug this is not a strict requirement. The only thing they share is the UID. Bye, Jojo -- 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
Parallel make failed in perl/perl.mak
mv: cannot stat `perl.mak': No such file or directory mv: cannot move `perl.mak' to `perl.mak.old': No such file or directory Writing perl.mak for Git Writing MYMETA.yml Writing perl.mak for Git Writing MYMETA.yml Writing perl.mak for Git Writing MYMETA.yml make[2]: *** [perl.mak] Error 1 make[1]: *** [instlibdir] Error 2 make: *** [git-difftool] Error 2 make: *** Waiting for unfinished jobs make[2]: *** [perl.mak] Error 1 make[1]: *** [instlibdir] Error 2 make: *** [git-archimport] Error 2 make[2]: *** [perl.mak] Error 1 make[1]: *** [instlibdir] Error 2 make: *** [git-add--interactive] Error 2 I wasn't able to reproduce it, so this message is the only thing I have. It was the first compilation after I merged the current master (v1.7.12-464-g83379df). Yes, I tried to jump back and forth in time, removing and touching perl.mak, generating it with previous releases and build with the current. No luck. Probably the old perl.mak is the problem, and the only thing I can think for reasons why it wasn't regenerated is this: diff --git a/perl/Makefile b/perl/Makefile index 15d96fc..766d02a 100644 --- a/perl/Makefile +++ b/perl/Makefile @@ -79,7 +79,7 @@ $(makfile): ../GIT-CFLAGS Makefile echo instlibdir: $@ echo ' echo $(instdir_SQ)' $@ else -$(makfile): Makefile.PL ../GIT-CFLAGS +$(makfile): Makefile.PL ../GIT-CFLAGS Makefile $(PERL_PATH) $ PREFIX='$(prefix_SQ)' INSTALL_BASE='' --localedir='$(localedir_SQ)' endif Could someone please take a look at it? -- 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
[PATCHv5] 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.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
changes in v5:
- extract a function to write refspec config
- handle --mirror option (test added)
- install correct refspec if the value of --branch is a tag (test added)
Thanks to Junio for:
- refactor tests
- add tests for created refs
I'm not happy about using our_head_points_to for the remote
part of the refspec. Junio already complaint about that. As far
as I can see it's the only way of getting the information that
it's a tag. Also the condition is this a tag might not be the
best way.
builtin/clone.c | 66 +++-
t/t5709-clone-refspec.sh | 156 +++
2 files changed, 208 insertions(+), 14 deletions(-)
create mode 100755 t/t5709-clone-refspec.sh
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/));
+ }
+ /*
+* otherwise, the next git fetch will
+* simply fetch from HEAD without updating
+* any remote tracking branch, which is what
+* we want.
+*/
+ } else {
+ strbuf_addf(value, +%s*:%s*, src_ref_prefix,
branch_top-buf);
+ }
+ /* Configure the remote */
+ if (value.len) {
+ strbuf_reset(key);
+ strbuf_addf(key, remote.%s.fetch, option_origin);
+ git_config_set_multivar(key.buf, value.buf, ^$, 0);
+ strbuf_reset(key);
+
+ if (option_mirror) {
+ strbuf_addf(key, remote.%s.mirror,
option_origin);
+ git_config_set(key.buf, true);
+ strbuf_reset(key);
+ }
+ }
+ }
+
+ strbuf_release(key);
+ strbuf_release(value);
+}
+
int cmd_clone(int argc, const char **argv, const char *prefix)
{
int is_bundle = 0, is_local;
@@ -755,20 +804,6 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
}
strbuf_addf(value, +%s*:%s*, src_ref_prefix, branch_top.buf);
-
- if (option_mirror || !option_bare) {
- /* Configure the remote */
- strbuf_addf(key, remote.%s.fetch, option_origin);
- git_config_set_multivar(key.buf, value.buf, ^$, 0);
- strbuf_reset(key);
-
- if (option_mirror) {
- strbuf_addf(key, remote.%s.mirror, option_origin);
- git_config_set(key.buf, true);
- strbuf_reset(key);
- }
- }
-
strbuf_addf(key, remote.%s.url, option_origin);
git_config_set(key.buf, repo);
strbuf_reset(key);
@@ -853,6 +888,9 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
refs/heads/master);
}
+ write_refspec_config(src_ref_prefix, our_head_points_at,
+ remote_head_points_at, branch_top);
+
if (is_local)
clone_local(path, git_dir);
else if (refs complete_refs_before_fetch)
diff --git
Re: Unable to clone GIT project
On Sun, Sep 16, 2012 at 09:48:43PM +0200, Erik Faye-Lund wrote: git-upload-pack: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory fatal: The remote end hung up unexpectedly [...] No. This is not a Git for Windows issue. The remote end is the one who isn't able to load libiconv, you can tell from the fact that it complains about libiconv.so.2, not libiconv-2.dll, and from the fact that the client informs us that the remote end hung up. Yeah, it is definitely a problem on the remote system. Ankush: There's something wrong with the setup on your Linux machine; most likely something related to the library path set up. What protocol are you cloning over? If I had to guess, I'd say it was ssh, the library is installed in a non-standard place (e.g., because he built them as a regular user and put them in his home directory), and LD_LIBRARY_PATH does not get set properly by ssh for the incoming ssh session. If that is the case, you can fix it with an entry in ~/.ssh/environment, or by telling git that the remote side needs to do more than just run git-upload-pack, like: git clone -u '. $HOME/.profile git-upload-pack' ... But I am just guessing. We need more information on how the remote system is set up to really know. -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] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Elia Pinto gitter.spi...@gmail.com writes: - That 165 thing I mentioned earlier. Thank you so much for the comments, that's fine. A single consideration for MALLOC_PERTURB. You can use any value between 1..255 for MALLOC_PERTURB_ That chooses the byte that glibc will use to memset all freed buffers. In general it is defined as export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) (as drepper pointed out http://udrepper.livejournal.com/11429.html) Drepper never recommends RANDOM there. Using a random value is slightly better than using a fixed one in case your fixed value is someday just the right/wrong value to mask a problem. Quite the contrary. When you use a fixed pattern, it is easy which other pieces of memory has uninitailized contents. When you use a random value, you sometimes get an error and sometimes the test mysteriously pass, which does not help debugging. openSUSE folks seem to use a fixed value for this exact reason of repeatability of tests. http://jaegerandi.blogspot.com/2012/01/finding-subtile-malloc-bugs.html So OK per the original expression? No. I am not convinced 165 is the perfect value, but I am fairly certain any fixed value is better than using a random to deliberately worsen repeatability of the tests. -- 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: Test failure: Test #3 in t1304-default-acl
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram owns? I am hoping that is not the case. I can see two reasons for having the same UID for two login names: 1) the sysadmin really messed up, and as you say, a total stranger has complete ownership of your files. Ramkumar, you should check that this is not your case. 2) the sysadmin explicitely gave two login names to the same physical person, as kinds of aliases for the same UID (e.g. the person got married, changed her name and login, but expects ~oldlogin to continue working). I'm not sure how common this is, and to which extend we want to support this in our test scripts. I've only been assuming (1), but (2) feels like a legitimate (if confusing) way to configure your system. It is a separate issue if it is worth bending backwards to support it in the test, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to clone GIT project
If I had to guess, I'd say it was ssh, the library is installed in a non-standard place (e.g., because he built them as a regular user and put them in his home directory), and LD_LIBRARY_PATH does not get set properly by ssh for the incoming ssh session. This would be my guess as well. If LD_LIBRARY_PATH is being relied upon though, a more stable solution would be to rebuild git with -Wl,-rpath /path/containing/libiconv in the LD_OPTIONS environment. That would remove the need for LD_LIBRARY_PATH at runtime. Any other libraries linked in non-standard locations should also have a similar option if the path to the library differs. HTH. Thanks -Ben -- --- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --- -- 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: status of git interop with other VCS
Ramkumar Ramachandra artag...@gmail.com writes: Hi Paul, Paul Wise wrote: svn: there was a gsoc project for this but it was never merged: http://git.wiki.kernel.org/index.php/SoC2011Projects#Remote_helper_for_Subversion_and_git-svn I wouldn't give up on that yet. What is the status of fa/remote-helper? An excerpt from recent What's cooking: * fa/remote-svn (2012-08-28) 16 commits - Add a test script for remote-svn - remote-svn: add marks-file regeneration - Add a svnrdump-simulator replaying a dump file for testing - remote-svn: add incremental import - remote-svn: Activate import/export-marks for fast-import - Create a note for every imported commit containing svn metadata - vcs-svn: add fast_export_note to create notes - Allow reading svn dumps from files via file:// urls - remote-svn, vcs-svn: Enable fetching to private refs - When debug==1, start fast-import with --stats instead of --quiet - Add documentation for the 'bidi-import' capability of remote-helpers - Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability - Add argv_array_detach and argv_array_free_detached - Add svndump_init_fd to allow reading dumps from arbitrary FDs - Add git-remote-testsvn to Makefile and .gitignore - Implement a remote helper for svn in C (this branch is used by fa/vcs-svn.) A GSoC project. Looked promising. Waiting for comments from mentors and stakeholders. * fa/vcs-svn (2012-08-28) 4 commits - vcs-svn: remove repo_tree - vcs-svn/svndump: rewrite handle_node(), begin|end_revision() - vcs-svn/svndump: restructure node_ctx, rev_ctx handling - svndump: move struct definitions to .h (this branch uses fa/remote-svn.) A GSoC project. Looked promising. Waiting for comments from mentors and stakeholders. -- 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] Add missing -z to git check-attr usage text for consistency with man page
Adam Spiers g...@adamspiers.org writes:
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/check-attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index e1ff575..075d01d 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -9,7 +9,7 @@ static int cached_attrs;
static int stdin_paths;
static const char * const check_attr_usage[] = {
N_(git check-attr [-a | --all | attr...] [--] pathname...),
-N_(git check-attr --stdin [-a | --all | attr...] list-of-paths),
+N_(git check-attr --stdin [-z] [-a | --all | attr...] list-of-paths),
NULL
};
I think this deserves to go to 'maint' that does not yet
have the i18n on this part, so I'll wiggle the patch to apply there
and merge it up.
Thanks.
--
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
Adam Spiers g...@adamspiers.org writes:
1. Change the color of individual known breakages from bold green to
bold yellow. This seems more appropriate 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.
2. 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.
3. Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test is wrong or the
semantics of the code being tested have changed. Either way this
is an error which is arguably as bad as a failing test, and as such
is now counted in the totals too.
I agree with Peff's comments.
The point #3 above wants to be a separate patch; we may even want to
consider a follow-up change to add an option to make a test that is
expected to fail did not fail case a failure.
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
- say_color ok $test_count - $@ # TODO known breakage
+ test_broken=$(($test_broken+1))
+ say_color error ok $test_count - $@ # TODO known breakage vanished
}
Also I wonder if this is still a TODO. # TODO fixed known breakage,
meaning that it is something that must be looked at by whoever happened
to have fixed the known breakage by accident, might be a better wording.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t/test-lib: print pretty msg when git isn't built
Ramkumar Ramachandra artag...@gmail.com writes: When tests were run without building git, the following error message was displayed: .: 54: Can't open /path/to/git/source/t/../GIT-BUILD-OPTIONS Change this to display a more user-friendly error message: error: you do not seem to have built git yet. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t-basic.sh | 10 -- t/test-lib.sh|6 ++ 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/t/t-basic.sh b/t/t-basic.sh index ae6a3f0..08677df 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -18,16 +18,6 @@ swapping compression and hashing order, the person who is making the modification *should* take notice and update the test vectors here. ' - -# It appears that people try to run tests without building... - -../git /dev/null -if test $? != 1 -then - echo 2 'You do not seem to have built git yet.' - exit 1 -fi - . ./test-lib.sh diff --git a/t/test-lib.sh b/t/test-lib.sh index f8e3733..c00452a 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -51,6 +51,12 @@ then fi GIT_BUILD_DIR=$TEST_DIRECTORY/.. +if ! test -r $GIT_BUILD_DIR/GIT-BUILD-OPTIONS +then + echo 'error: you do not seem to have built git yet.' 2 + exit 1 +fi + Is this a sufficient replacement for what you removed from ? Can the BUILD-OPTIONS file exist when your build of git failed? . $GIT_BUILD_DIR/GIT-BUILD-OPTIONS export PERL_PATH SHELL_PATH -- 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 v6 0/4] Support non-WIN32 systems lacking poll()
I really wanted to take a look at this series, but with the broken patches I cannot. Try again, please, perhaps first sending patches to yourself and make sure they come out without losing leading SP for context lines and such. Thanks. -- 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: [PATCHv5] clone --single: limit the fetch refspec to fetched branch
On Mon, Sep 17, 2012 at 10:18 PM, Junio C Hamano gits...@pobox.com wrote: Ralf Thielow ralf.thie...@gmail.com writes: - handle --mirror option (test added) Handle how? I personally think erroring out is the right way to handle it, but if we care about people who have been misusing the combination of single and mirror, the second best way would be to imply mirror and single combination as bare and single without mirror. With this patch it would be bare and single, and with the next fetch a mirror. However, the combination of single and mirror doesn't really make sense so I also think we should error it out. - install correct refspec if the value of --branch is a tag (test added) What is the definition of correct? I see the documentation says --branch can also take tags and treat them like detached HEAD, and even though I _think_ allowing tags was a huge mistake, if we claim we treat it like detached HEAD, we should do the same when coming up with the refspec used for the follow-up fetch. This patch would install the refspec +refs/tags/v1.7.10:refs/tags/v1.7.10, so we would do the same with the follow-up fetch, not? This can be seen as it's not a bug, it's a feature. Why not cloning a tag of a repo if someone just want to build a tag without having anything else. Whatever we decide to do, the semantics we decided to use at least need to be described in the commit log message, not just in the changes from the previous iteration. Updating the Documentation/git-clone.txt would also be necessary. Ok. +test_expect_success 'refspec contains all branches by default' ' + echo +refs/heads/*:refs/remotes/origin/* expect + git --git-dir=dir_all/.git config --get remote.origin.fetch actual + test_cmp expect actual +' I still think these checks that know the current implementation details (i.e. what exact configuration variables get what exact values) are wrong thing to have in the longer term. If the desired behaviour (i.e. later fetch do not screw up) can be tested directly like the later parts of the test in this patch does, how that desired behaviour is implemented should not have to be cast in stone with these tests. You wrote I'll let it pass for now, though. so I haven't removed them yet. I'll delete them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/4] Support non-WIN32 systems lacking poll()
Here's now my updated series of patches to make the win32 implementation of poll() available to other platforms: 1 - make poll available for other platforms lacking it by moving it into a separate directory and adjusting Makefile 2 - fix some win32 specific dependencies in poll.c by #ifdef the inclusion of two header files 3 - poll() exits too early with EFAULT if 1st arg is NULL, as fixed in gnulib recently 4 - make poll() work on platforms that can't recv() on a non-socket, namely HP NonStop, as fixed in gnulib recently Hopefully without whitespace issues... Bye, Jojo -- 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.
Michael Haggerty mhag...@alum.mit.edu writes: Junio pointed out that the sort order currently used by string_list could be considered to be an implementation detail internal to string_list. But the sort order is already visible to the outside world (e.g., via iteration or via print_string_list()), so it shouldn't be changed willy-nilly. Therefore, document the current sort order as part of the API's contract. (If, at some future time, somebody wants a string_list that is sorted by a different criterion, then the order should be made specifiable via a callback function specified by the user.) As I said in a separate message, we do not give any documented guarantee on the order the strings comes out of print_string_list(), other than if you are using the unsorted list function to insert or append strings, we won't muck with the order of the items and you will get your strings back in the order you gave us. Until we add a callback that the user can specify at the time of string list initialization, I do not think it is wise to cast it in stone and declare it as shouldn't be changed willy-nilly, unnecessarily painting us into a corner that we need to expend extra effort to get out of. Besides, nobody calls print_string_list() in the first place. I have always considered it as a debugging aid. -- 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 v7 2/4] fix some win32 specific dependencies in poll.c
In order for non-win32 platforms to be able to use poll.c, #ifdef the inclusion of two header files properly Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- compat/poll/poll.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index 9e7a25c..e4b8319 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -24,7 +24,9 @@ # pragma GCC diagnostic ignored -Wtype-limits #endif -#include malloc.h +#if defined(WIN32) +# include malloc.h +#endif #include sys/types.h @@ -48,7 +50,9 @@ #else # include sys/time.h # include sys/socket.h -# include sys/select.h +# ifndef NO_SYS_SELECT_H +# include sys/select.h +# endif # include unistd.h #endif -- 1.7.12 -- 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 v7 3/4] poll() exits too early with EFAULT if 1st arg is NULL
If poll() is used as a milli-second sleep, like in help.c, by passing a NULL
in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be fixed
Like in this commit, which is not to exit if the 2nd arg is 0. It got fixed
In gnulib in the same manner the other day.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
compat/poll/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/poll/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -357,7 +357,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd nfd)
{
errno = EFAULT;
return -1;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t/perf: add trash directory to .gitignore
Ramkumar Ramachandra artag...@gmail.com writes: Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/perf/.gitignore |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/t/perf/.gitignore b/t/perf/.gitignore index 50f5cc1..0061cbc 100644 --- a/t/perf/.gitignore +++ b/t/perf/.gitignore @@ -1,2 +1,3 @@ -build/ -test-results/ +/build +/test-results +/trash directory* Thanks. I _think_ you still want to make sure these are directories, so instead of losing the trailing slash, you would want to keep it and add a leading slash to anchor them to the t/perf directory, i.e. /build/ /test-results/ /trash directory*/ -- 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: [PATCHv5] clone --single: limit the fetch refspec to fetched branch
Ralf Thielow ralf.thie...@gmail.com writes: - install correct refspec if the value of --branch is a tag (test added) What is the definition of correct? I see the documentation says --branch can also take tags and treat them like detached HEAD, and even though I _think_ allowing tags was a huge mistake, if we claim we treat it like detached HEAD, we should do the same when coming up with the refspec used for the follow-up fetch. This patch would install the refspec +refs/tags/v1.7.10:refs/tags/v1.7.10, so we would do the same with the follow-up fetch, not? This can be seen as it's not a bug, it's a feature. Why not cloning a tag of a repo if someone just want to build a tag without having anything else. Even though I did say I thought allowing tags was a huge mistake, I was not suggesting to break existing users by making such a clone into an error. But the main point of the discussion is what should happen upon the next git fetch in the repository, no? Shouldn't the refspec be the same as the case where you clone --single a repository whose HEAD is detached at v1.7.10 in that example, instead of saying fetch the same tag over and over? After all that is the way I expect that most people would read treat them line detached HEAD in the documentation. Subsequent git fetch would fetch from the HEAD of the upstream just like a clone from a repository with a detached HEAD. The above is *not* a rhetorical question; I just do not think of a sensible reason why we want a refspec that says keep updating the v1.7.10 tag, as it might change on the other end, and do not bother what other things that happen in that upstream repository. What sensible workflow would benefit from such a refspec? -- 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 3/8] Doc: Improve shallow depth wording
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: Avoid confusion in compound sentence about the start of the commit set and the depth measure. Use two sentences. Dropping the first ',' after positive depth does not seem to make it any easier to read (I personally think it makes it a lot harder to read). Accepted. My mistake - will correct. Splitting the tail-end of the sentence into a separate sentence does make it easier to read, though. 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: [PATCH v3 05/14] Change fetch_pack() and friends to take string_list arguments
On Mon, Sep 17, 2012 at 03:10:07PM -0700, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: But how far should this policy be taken? It seems to me that strict adherence to the policy would dictate that *.h files should *never* include other git project files. I wouldn't call that a policy. It's something we think about when adding a new #include to see if it is worth adding and/or if it is the right place to add it to reduce code churn. As I said, what policy to pick and stick to is open to discussion, and I wanted to leave it outside the scope of this series. As it has been cooking in 'next', I do not think it is worth reverting the inclusion of string-list.h to delay this topic. It is something that can and should be cleaned up when we decide to pick the inclusion policy and enforce it. If we choose to go in the other direction, we would end up adding it back, so let's keep it as-is for now. I will admit that I usually follow the opposite policy of what you have suggested, and include dependent headers in the .h files. Mostly just because it makes things simpler for the user of the header file, and there aren't really downsides (yes, you can have weird dependency-order issues, but in practice those are rare, and they generate very obvious compile-time errors). What I think would be much more productive is breaking apart gigantic includes like cache.h into more reasonable modules, which would mean less frequent recompilation when an uninteresting part of the header changes. But git is reasonably fast to compile as it is, so I have never quite decided that it is worth the human effort to go in that direction. -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 7/8] Doc clean: add See Also links
From: Junio C Hamano gits...@pobox.com Matthieu Moy matthieu@grenoble-inp.fr writes: Philip Oakley philipoak...@iee.org writes: --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -63,6 +63,12 @@ OPTIONS Remove only files ignored by git. This may be useful to rebuild everything from scratch, but keep manually created files. +SEE ALSO + +linkgit:gitignore[5] +linkgit:gitrepository-layout[5] +The optional configuration variable `core.excludesfile` linkgit:git-config[1] I think linkgit:gitignore[5] is enough. linkgit:gitrepository-layout[5] is a very general documentation, it's not clear to the reader which part is intended to be read in complement to git-clean, and indeed, the relevant information is already in linkgit:gitignore[5]. Same for core.excludesfile which is already documented in linkgit:gitignore[5]. Otherwise, I suspect we'll end-up having the transitive closure of SEE ALSO in each manpage ... Concurred. Thanks. -- The improved layout of gitignore in patch 5/8 should cover it. The three links came about because of the initial 'git add' patch 6/8. I'll update (though probably tomorrow night..). -- 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] mailinfo: do not concatenate charset= attribute values from mime headers
Content-type: text/plain; charset=UTF-8 header should not appear
twice in the input, but it is always better to gracefully deal with
such a case. The current code concatenates the value to the values
we have seen previously, producing nonsense such as utf8UTF-8.
Instead of concatenating, forget the previous value and use the last
value we see.
Reported-by: Tomas Cohen Arazi
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* I think this is the right thing to do after all. Thanks for
bringing the issue up, Tomas.
builtin/mailinfo.c | 5 ++---
t/t5100-mailinfo.sh | 2 +-
t/t5100/info0017| 5 +
t/t5100/msg0017 | 2 ++
t/t5100/patch0017 | 6 ++
t/t5100/sample.mbox | 16
6 files changed, 32 insertions(+), 4 deletions(-)
create mode 100644 t/t5100/info0017
create mode 100644 t/t5100/msg0017
create mode 100644 t/t5100/patch0017
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index eaf9e15..dd8b67c 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -160,10 +160,9 @@ static int slurp_attr(const char *line, const char *name,
struct strbuf *attr)
const char *ends, *ap = strcasestr(line, name);
size_t sz;
- if (!ap) {
- strbuf_setlen(attr, 0);
+ strbuf_setlen(attr, 0);
+ if (!ap)
return 0;
- }
ap += strlen(name);
if (*ap == '') {
ap++;
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 81904d9..3e64a7a 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. $TEST_DIRECTORY/t5100/sample.mbox last
last=`cat last`
echo total is $last
- test `cat last` = 16'
+ test `cat last` = 17'
check_mailinfo () {
mail=$1 opt=$2
diff --git a/t/t5100/info0017 b/t/t5100/info0017
new file mode 100644
index 000..d2bc89f
--- /dev/null
+++ b/t/t5100/info0017
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.t...@example.com
+Subject: A E I O U
+Date: Mon, 17 Sep 2012 14:23:44 -0700
+
diff --git a/t/t5100/msg0017 b/t/t5100/msg0017
new file mode 100644
index 000..2ee0900
--- /dev/null
+++ b/t/t5100/msg0017
@@ -0,0 +1,2 @@
+New content here
+
diff --git a/t/t5100/patch0017 b/t/t5100/patch0017
new file mode 100644
index 000..35cf84c
--- /dev/null
+++ b/t/t5100/patch0017
@@ -0,0 +1,6 @@
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
b/foo
+@@ -0,0 +1 @@
++New content
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index de10312..fcc0e0d 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -683,3 +683,19 @@ index e69de29..d95f3ad 100644
@@ -0,0 +1 @@
+content
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor a.u.t...@example.com
+Subject: A E I O U
+Date: Mon, 17 Sep 2012 14:23:44 -0700
+MIME-Version: 1.0
+Content-Type: text/plain; charset=iso-2022-jp
+Content-type: text/plain; charset=UTF-8
+
+New content here
+
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
b/foo
+@@ -0,0 +1 @@
++New content
--
1.7.12.556.gb90bb19
--
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 v7 1/4] make poll available for other platforms lacking it
Joachim Schmitz j...@schmitz-digital.de writes:
move poll.[ch] out of compat/win32/ into compat/poll/ and adjust
Makefile with the changed paths. Adding comments to Makefile about
how/when to enable it and add logic for this
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
Makefile | 20 +++-
compat/{win32 = poll}/poll.c | 0
compat/{win32 = poll}/poll.h | 0
3 files changed, 15 insertions(+), 5 deletions(-)
rename compat/{win32 = poll}/poll.c (100%)
rename compat/{win32 = poll}/poll.h (100%)
diff --git a/Makefile b/Makefile
index ac49320..7893297 100644
--- a/Makefile
+++ b/Makefile
@@ -152,6 +152,11 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_SYS_POLL_H if you don't have sys/poll.h.
+#
+# Define NO_POLL if you do not have or don't want to use poll().
+# This also implies NO_SYS_POLL_H.
Sensible.
@@ -1220,7 +1225,7 @@ ifeq ($(uname_S),Windows)
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
Should this be NO_POLL, not NO_POLL_H?
-DSTRIP_EXTENSION=\.exe\
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE
-NODEFAULTLIB:MSVCRT.lib
EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
@@ -1316,7 +1321,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
Likewise.
@@ -1605,6 +1610,11 @@ ifdef NO_GETTEXT
BASIC_CFLAGS += -DNO_GETTEXT
USE_GETTEXT_SCHEME ?= fallthrough
endif
+ifdef NO_POLL
+ NO_SYS_POLL_H = YesPlease
+ COMPAT_CFLAGS += -DNO_POLL -Icompat/poll
+ COMPAT_OBJS += compat/poll/poll.o
+endif
I think my guesses above are correct, so will queue with the trivial
and obvious fixup.
Thanks.
--
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: How to create the [PATCH 0/5] first email?
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: Typically it will be placed in a MUA’s drafts folder, edited to add timely commentary that should not go in the changelog after the three dashes, and then sent as a message whose body, in our example, starts with arch/arm config files were…. On the receiving end, readers can save interesting patches in a UNIX mailbox and apply them with git-am(1). hides a multitude of implicit knowledge steps. Is there an extended description of what that would mean from a platform independent viewpoint? e.g. if the patches are separte files and an mbox is one consolidated file, how to get from one to the other so that 'it' can be sent by 'git send-mail'. If you plan to use git send-email to send the final results out, you should consider git send-email as your MUA in the quoted paragraph. And that will be very platform independent viewpoint to see things from. On git for windows (msysgit)n there were a couple of other steps I had to do https://git.wiki.kernel.org/index.php/MSysGit:UsingSendEmail as Outlooklook Express isn't really a suitable MUA ;-) [noted for other list readers] git format-patch -o my-series/ --cover-letter ... would treat my-series/ directory as MUA's drafts folder and prepares the messages you would want to send out, and you can proof-read and edit the files in there before telling your MUA to send them out, with git send-email ... my-series/*.patch or something. I hadn't picked up from the man page that the --cover-letter would do the [PATCH 0/n] - should it? I'm also missing an understanding of the preparation stage where one tries to tidy up the various commit messages becaue they weren't explicit, specfic nor concise enough,... Many people usually do rebase -i until perfection and then a single final invocation of format-patch. Of course, the final can and should further be proof-read and it is fine to do typofixes in the format-patch output files without going back to the commits before sending them out. I did an initial rebase to correct a few obvious mistakes (e.g. an extra file that had crept in), but then, after some false starts, used git format-patch pu --stdout fix_Docs.patch to get a single file I could inspect and refine for both the commit messages and content. I then applied it (using git am) to a temp branch to see what it produced, and could repeat the cycle until the patches looked right. ...so I suspect that there is an implicit `git format-patch` - `git am` loop of sharpening the mbox patches before submission to the list that I'm missing. Has this described somewhere? -- However, when it came to creating the series, with comments, I couldn't see a way of having my comments within my local commits, but preparing a patch series that would properly include the '---' separator. Is there a way of getting format-patch to change some line break sequence (within the commit message) to the '---' three dashes patch break suitable for submission to the list? 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
[PATCH] Allow fancy globs in git-svn init branches
Branches passed to 'git-svn init' via the -b/--branches flag
automatically had a /* appended to them. When the branch contained
a fancy glob with a {} pattern, this is incorrect behaviour, and
leads to odd branches being created in the git repository.
Signed-off-by: Ammon Riley ammon.ri...@gmail.com
---
git-svn.perl | 2 +-
t/t9141-git-svn-multiple-branches.sh | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0d77ffb..f8e8558 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1678,7 +1678,7 @@ sub complete_url_ls_init {
my $remote_path = join_paths( $gs-path, $repo_path );
$remote_path =~ s{%([0-9A-F]{2})}{chr hex($1)}ieg;
$remote_path =~ s#^/##g;
- $remote_path .= /* if $remote_path !~ /\*/;
+ $remote_path .= /* if $remote_path !~ m#\*|\{[^/]+\}#;
my ($n) = ($switch =~ /^--(\w+)/);
if (length $pfx $pfx !~ m#/$#) {
die --prefix='$pfx' must have a trailing slash '/'\n;
diff --git a/t/t9141-git-svn-multiple-branches.sh
b/t/t9141-git-svn-multiple-branches.sh
index 3cd0671..1b872a9 100755
--- a/t/t9141-git-svn-multiple-branches.sh
+++ b/t/t9141-git-svn-multiple-branches.sh
@@ -119,4 +119,16 @@ test_expect_success 'create new branches and tags' '
svn_cmd up test -e tags_B/Tag2/a.file )
'
+test_expect_success 'clone multiple branch paths using fancy glob' '
+ git svn clone -T trunk \
+ -b b_one/{first} --branches b_two \
+ $svnrepo/project git_project2
+ ( cd git_project2
+ git rev-parse refs/remotes/first
+ test_must_fail git rev-parse refs/remotes/second
+ git rev-parse refs/remotes/1
+ git rev-parse refs/remotes/2
+ )
+'
+
test_done
--
1.7.12.465.gb319926
--
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: How to create the [PATCH 0/5] first email?
Philip Oakley philipoak...@iee.org writes: I then applied it (using git am) to a temp branch to see what it produced, and could repeat the cycle until the patches looked right. That's another obvious and valid way to prepare your series. It all depends on how comfortable you are to directly edit patches. Some people fear it. Some don't. Some can do it with their eyes closed ;-). However, when it came to creating the series, with comments, I couldn't see a way of having my comments within my local commits, but preparing a patch series that would properly include the '---' separator. An unofficial trick that works is to write the --- * This is an additional comment yourself when running git commit. That will be propagated to the output from format-patch. You will have another --- in front of the diffstat, but nobody is hurt by that. But when doing a big series that deserves a cover letter [PATCH 0/n], you will use editor on the output from format-patch anyway, and I find it simpler to do the follow-on comments at that point myself. Personal preferences vary, so whatever makes you feel comfortable with and works well for you is good. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to create the [PATCH 0/5] first email?
Jeff King p...@peff.net writes: On Mon, Sep 17, 2012 at 04:49:39PM -0700, Junio C Hamano wrote: However, when it came to creating the series, with comments, I couldn't see a way of having my comments within my local commits, but preparing a patch series that would properly include the '---' separator. An unofficial trick that works is to write the --- * This is an additional comment yourself when running git commit. That will be propagated to the output from format-patch. You will have another --- in front of the diffstat, but nobody is hurt by that. But note that using format-patch -s will break; it puts the sign-off below the ---. I think format-patch -s is a workflow mistake in the first place. You should be doing the sign-off the commit when you commit in the first place. It is not like I cannot sign off because I think it is still iffy or anything. But your point still stands; commit -s will not see through that official trick either ;-). But when doing a big series that deserves a cover letter [PATCH 0/n], you will use editor on the output from format-patch anyway, and I find it simpler to do the follow-on comments at that point myself. Me too (actually, I load it all into mutt and then comment on each as I send them out, but it amounts to the same thing, seeing as how my MUA just invokes $EDITOR when I edit a mail). -- 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: [PATCHv4] clone --single: limit the fetch refspec to fetched branch
On Tue, Sep 18, 2012 at 3:08 AM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: --mirror --single-branch combination does not look right. The heads/ part is missing.. What does it supposed to do in the first place? mirror is primarily about grabbing everything without leaving stuff out, and single is about grabbing only one thing without other stuff. It smells like a nonsense case we didn't even bother to catch and diagnose as an error to me. Besides, mirror implies bare, so we would expect to see refs/heads/$single:refs/heads/$single and that matches what the single gives us without mirror, no? Yes that's what I think it should do too. How about explicitly forbidding that combination, or ignoring mirror when single is given? I see nothing wrong with mirroring just one branch. But if handling it is too complex than forbidding it is fine. -- 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
[PATCH v3 0/4] rebase -i: Teach --edit-todo action
Made the fixes as suggested by Martin. Martin: Good points. Thanks! Andrew Wong (3): rebase -i: Refactor help messages for todo file rebase -i: Teach --edit-todo action rebase -i: Add tests for --edit-todo Martin von Zweigbergk (1): rebase usage: subcommands can not be combined with -i Documentation/git-rebase.txt | 5 - git-rebase--interactive.sh| 48 +-- git-rebase.sh | 13 ++-- t/t3404-rebase-interactive.sh | 18 4 files changed, 70 insertions(+), 14 deletions(-) -- 1.7.12.318.g79683ba.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] rebase usage: subcommands can not be combined with -i
From: Martin von Zweigbergk martinv...@gmail.com Since 95135b0 (rebase: stricter check of standalone sub command, 2011-02-06), git-rebase has not allowed to use -i together with e.g. --continue. Yet, when rebase started using OPTIONS_SPEC in 45e2acf (rebase: define options in OPTIONS_SPEC, 2011-02-28), the usage message included git-rebase [-i] --continue | --abort | --skip Remove the [-i] from this line. Signed-off-by: Martin von Zweigbergk martinv...@gmail.com Signed-off-by: Andrew Wong andrew.k...@gmail.com --- git-rebase.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase.sh b/git-rebase.sh index 15da926..e6b43a2 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -8,7 +8,7 @@ OPTIONS_KEEPDASHDASH= OPTIONS_SPEC=\ git rebase [-i] [options] [--exec cmd] [--onto newbase] [upstream] [branch] git rebase [-i] [options] [--exec cmd] [--onto newbase] --root [branch] -git-rebase [-i] --continue | --abort | --skip +git-rebase --continue | --abort | --skip -- Available options are v,verbose! display a diffstat of what changed upstream -- 1.7.12.318.g79683ba.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] rebase -i: Refactor help messages for todo file
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--interactive.sh | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a09e842..4d57e50 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -115,6 +115,23 @@ mark_action_done () {
fi
}
+append_todo_help () {
+ cat $todo EOF
+#
+# Commands:
+# p, pick = use commit
+# r, reword = use commit, but edit the commit message
+# e, edit = use commit, but stop for amending
+# s, squash = use commit, but meld into previous commit
+# f, fixup = like squash, but discard this commit's log message
+# x, exec = run command (the rest of the line) using shell
+#
+# These lines can be re-ordered; they are executed from top to bottom.
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+EOF
+}
+
make_patch () {
sha1_and_parents=$(git rev-list --parents -1 $1)
case $sha1_and_parents in
@@ -901,18 +918,10 @@ test -n $cmd add_exec_commands $todo
cat $todo EOF
# Rebase $shortrevisions onto $shortonto
+EOF
+append_todo_help
+cat $todo EOF
#
-# Commands:
-# p, pick = use commit
-# r, reword = use commit, but edit the commit message
-# e, edit = use commit, but stop for amending
-# s, squash = use commit, but meld into previous commit
-# f, fixup = like squash, but discard this commit's log message
-# x, exec = run command (the rest of the line) using shell
-#
-# These lines can be re-ordered; they are executed from top to bottom.
-#
-# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
EOF
--
1.7.12.318.g79683ba.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git diff across submodules
Hello, Is there any nice way to get a diff and/or diffstat of both a project and its submodules between two revisions of the main project? Something like 'git diff --stat tag_a tag_b' but also including the diffstat on the submodule from the revision tied to in tag_a to the revision tied to tag_b. A few shell backflips will do it, but this seems like I'm missing something. thanks, -Kenny -- 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 4/4] rebase -i: Add tests for --edit-todo
On Mon, Sep 17, 2012 at 10:23 PM, Andrew Wong andrew.k...@gmail.com wrote: On 09/18/12 00:58, Martin von Zweigbergk wrote: On Mon, Sep 17, 2012 at 6:28 PM, Andrew Wong andrew.k...@gmail.com wrote: + test M = $(git cat-file commit HEAD^ | sed -ne \$p) + test L = $(git cat-file commit HEAD | sed -ne \$p) I couldn't find $ (match last line) in the POSIX man page for sed. Besides, I think $(git show -s --format=%s HEAD) reads better. It's under Addresses in sed: ... a '$' character that addresses the last line of input ... Ah, I just didn't look hard enough; sorry. Good to know. FWIW, Acked-by: Martin von Zweigbergk martinv...@gmail.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
