* [PATCH v2 12/16] contrib/fast-import/import-zips.py: use spaces instead of tabs
From: David Aguilar @ 2013-02-24 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <1361667024-49776-12-git-send-email-davvid@gmail.com>
Follow the conventional Python style by using 4-space indents
instead of hard tabs.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/fast-import/import-zips.py | 98 +++++++++++++++++++-------------------
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/contrib/fast-import/import-zips.py b/contrib/fast-import/import-zips.py
index b528798..d12c296 100755
--- a/contrib/fast-import/import-zips.py
+++ b/contrib/fast-import/import-zips.py
@@ -14,13 +14,13 @@ from time import mktime
from zipfile import ZipFile
if hexversion < 0x01060000:
- # The limiter is the zipfile module
- stderr.write("import-zips.py: requires Python 1.6.0 or later.\n")
- exit(1)
+ # The limiter is the zipfile module
+ stderr.write("import-zips.py: requires Python 1.6.0 or later.\n")
+ exit(1)
if len(argv) < 2:
- print 'usage:', argv[0], '<zipfile>...'
- exit(1)
+ print 'usage:', argv[0], '<zipfile>...'
+ exit(1)
branch_ref = 'refs/heads/import-zips'
committer_name = 'Z Ip Creator'
@@ -28,51 +28,51 @@ committer_email = 'zip@example.com'
fast_import = popen('git fast-import --quiet', 'w')
def printlines(list):
- for str in list:
- fast_import.write(str + "\n")
+ for str in list:
+ fast_import.write(str + "\n")
for zipfile in argv[1:]:
- commit_time = 0
- next_mark = 1
- common_prefix = None
- mark = dict()
-
- zip = ZipFile(zipfile, 'r')
- for name in zip.namelist():
- if name.endswith('/'):
- continue
- info = zip.getinfo(name)
-
- if commit_time < info.date_time:
- commit_time = info.date_time
- if common_prefix == None:
- common_prefix = name[:name.rfind('/') + 1]
- else:
- while not name.startswith(common_prefix):
- last_slash = common_prefix[:-1].rfind('/') + 1
- common_prefix = common_prefix[:last_slash]
-
- mark[name] = ':' + str(next_mark)
- next_mark += 1
-
- printlines(('blob', 'mark ' + mark[name], \
- 'data ' + str(info.file_size)))
- fast_import.write(zip.read(name) + "\n")
-
- committer = committer_name + ' <' + committer_email + '> %d +0000' % \
- mktime(commit_time + (0, 0, 0))
-
- printlines(('commit ' + branch_ref, 'committer ' + committer, \
- 'data <<EOM', 'Imported from ' + zipfile + '.', 'EOM', \
- '', 'deleteall'))
-
- for name in mark.keys():
- fast_import.write('M 100644 ' + mark[name] + ' ' +
- name[len(common_prefix):] + "\n")
-
- printlines(('', 'tag ' + path.basename(zipfile), \
- 'from ' + branch_ref, 'tagger ' + committer, \
- 'data <<EOM', 'Package ' + zipfile, 'EOM', ''))
+ commit_time = 0
+ next_mark = 1
+ common_prefix = None
+ mark = dict()
+
+ zip = ZipFile(zipfile, 'r')
+ for name in zip.namelist():
+ if name.endswith('/'):
+ continue
+ info = zip.getinfo(name)
+
+ if commit_time < info.date_time:
+ commit_time = info.date_time
+ if common_prefix == None:
+ common_prefix = name[:name.rfind('/') + 1]
+ else:
+ while not name.startswith(common_prefix):
+ last_slash = common_prefix[:-1].rfind('/') + 1
+ common_prefix = common_prefix[:last_slash]
+
+ mark[name] = ':' + str(next_mark)
+ next_mark += 1
+
+ printlines(('blob', 'mark ' + mark[name], \
+ 'data ' + str(info.file_size)))
+ fast_import.write(zip.read(name) + "\n")
+
+ committer = committer_name + ' <' + committer_email + '> %d +0000' % \
+ mktime(commit_time + (0, 0, 0))
+
+ printlines(('commit ' + branch_ref, 'committer ' + committer, \
+ 'data <<EOM', 'Imported from ' + zipfile + '.', 'EOM', \
+ '', 'deleteall'))
+
+ for name in mark.keys():
+ fast_import.write('M 100644 ' + mark[name] + ' ' +
+ name[len(common_prefix):] + "\n")
+
+ printlines(('', 'tag ' + path.basename(zipfile), \
+ 'from ' + branch_ref, 'tagger ' + committer, \
+ 'data <<EOM', 'Package ' + zipfile, 'EOM', ''))
if fast_import.close():
- exit(1)
+ exit(1)
--
1.8.2.rc0.263.g20d9441
^ permalink raw reply related
* [PATCH v2 15/16] templates/hooks--update.sample: use a lowercase "usage:" string
From: David Aguilar @ 2013-02-24 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <1361667024-49776-15-git-send-email-davvid@gmail.com>
Make the usage string consistent with Git.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
templates/hooks--update.sample | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/templates/hooks--update.sample b/templates/hooks--update.sample
index 71ab04e..d847583 100755
--- a/templates/hooks--update.sample
+++ b/templates/hooks--update.sample
@@ -38,7 +38,7 @@ if [ -z "$GIT_DIR" ]; then
fi
if [ -z "$refname" -o -z "$oldrev" -o -z "$newrev" ]; then
- echo "Usage: $0 <ref> <oldrev> <newrev>" >&2
+ echo "usage: $0 <ref> <oldrev> <newrev>" >&2
exit 1
fi
--
1.8.2.rc0.263.g20d9441
^ permalink raw reply related
* [PATCH v2 16/16] Documentation/user-manual.txt: use a lowercase "usage:" string
From: David Aguilar @ 2013-02-24 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <1361667024-49776-16-git-send-email-davvid@gmail.com>
Make the usage string in the example script consistent with Git.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/user-manual.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5f36f81..35a279a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2337,7 +2337,7 @@ origin)
fi
;;
*)
- echo "Usage: $0 origin|test|release" 1>&2
+ echo "usage: $0 origin|test|release" 1>&2
exit 1
;;
esac
@@ -2351,7 +2351,7 @@ pname=$0
usage()
{
- echo "Usage: $pname branch test|release" 1>&2
+ echo "usage: $pname branch test|release" 1>&2
exit 1
}
--
1.8.2.rc0.263.g20d9441
^ permalink raw reply related
* Re: [RFC v2] git-multimail: a replacement for post-receive-email
From: Michael Haggerty @ 2013-02-24 5:31 UTC (permalink / raw)
To: Matthieu Moy
Cc: git discussion list, Andy Parkins, Sitaram Chamarty,
Junio C Hamano, Marc Branchaud,
Ævar Arnfjörð Bjarmason, Chris Hiestand
In-Reply-To: <vpqfw0rb25c.fsf@grenoble-inp.fr>
On 02/20/2013 01:28 PM, Matthieu Moy wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> A while ago, I submitted an RFC for adding a new email notification
>> script to "contrib" [...]
>
> We've discussed offline with Michael, a few patches have been merged,
> and there are still a few pending pull requests. I liked the script
> already, but it's getting even cooler ;-).
>
> A few more random thoughts (not on my personal todo-list):
>
> * It may make sense to add the short sha1 of the new reference in email
> titles (branch foo updated -> branch foo updated to $sha1), so that
> gmail users do not get a single huge thread "branch foo updated".
>
> (Yes, I do know about the Reference field, but gmail uses Subject: for
> threading).
> [...]
I just implemented this in branch sha1s-in-subject [1]. Please let me
know if this works for you then I'll merge it to master. (It depends on
the header-handling branch, which also includes your patch for non-ASCII
header fields.)
Michael
[1] https://github.com/mhagger/git-multimail/tree/sha1s-in-subject
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [RFC v2] git-multimail: a replacement for post-receive-email
From: Michael Haggerty @ 2013-02-24 5:53 UTC (permalink / raw)
To: Matthieu Moy
Cc: git discussion list, Andy Parkins, Sitaram Chamarty,
Junio C Hamano, Marc Branchaud,
Ævar Arnfjörð Bjarmason, Chris Hiestand
In-Reply-To: <vpqfw0rb25c.fsf@grenoble-inp.fr>
On 02/20/2013 01:28 PM, Matthieu Moy wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> A while ago, I submitted an RFC for adding a new email notification
>> script to "contrib" [...]
>
> We've discussed offline with Michael, a few patches have been merged,
> and there are still a few pending pull requests. I liked the script
> already, but it's getting even cooler ;-).
>
> A few more random thoughts (not on my personal todo-list):
>
> [...]
>
> * Perhaps we should allow a per-branch configuration, like
>
> [multimailhook]
> mailingList = some@list.com
> [multimailhook "refs/heads/my-branch"]
> mailingList = some-other@list.com
> <whateverOtherConfig> = <whateverOtherValue>
>
> Branch specific would override value for Config.get(), and
> Config.get_all() should probably list both the branch-specific and the
> other keys.
I wonder whether it would be to far off the beaten path to allow glob
patterns in the branch specification; e.g.,
[multimailhook "refs/heads/release-*"]
mailingList = qa@example.com
For the case of multiple glob patterns matching a branch name, there
would probably have to be a notion of "best match", but that doesn't
seem too difficult. The matching would have to take place when looking
up individual options to avoid having to replicate the full
configuration for each pattern.
This feature could also be used to get the functionality of your
proposal for skipRefs and onlyRefs [1] in a more general way:
[multimailhook]
mailingList = some@example.com
[multimailhook "refs/heads/user/$USER/*"]
mailingList = ""
Michael
[1] Proposed feature to allow certain references to be ignored for the
purpose of notification emails; see
https://github.com/mhagger/git-multimail/pull/15
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Mike Gorchak @ 2013-02-24 7:36 UTC (permalink / raw)
To: git
In-Reply-To: <CAHXAxrMRxKKiEarSQ0fCLt6-zyS=52B+kmZMLDf8SQAGzGbjjQ@mail.gmail.com>
Hello,
> Here is a small patch with QNX build improvements:
>
> 1) Rename tar.h to tar_git.h. Latest QNX versions have system tar.h
> header according to
> http://pubs.opengroup.org/onlinepubs/009696699/basedefs/tar.h.html ,
> to avoid inclusion of another tar.h, original header was renamed.
> 2) Rename fnmatch.h to fnmatch_gnu.h and fnmatch.c to fnmatch_gnu.c to
> avoid inclusion of system fnmatch.h header in case if -I/usr/include
> path is specified before -Icompat/fnmatch. Which is common situation.
> 3) pager.c - default "less" invocation flags were changed for QNX 6,x
> platform, since QNX has incompatible with GNU coreutils version of
> "less" utility.
> 4) config.mak.uname - a) do not override mkdtemp/mkstemps/strcasestr
> detection, since newer QNX version could contain such functions. Let
> to configure decide what is present in the system. b) getpagesize()
> function is existing under QNX, c) QNX has pthread functions in the
> libc, so do not define NO_PTHREAD macro.
Sorry, in the previous post the patch was not inlined.
diff --git a/Makefile b/Makefile
index ba8e243..f6dd2eb 100644
--- a/Makefile
+++ b/Makefile
@@ -726,7 +726,7 @@ LIB_H += streaming.h
LIB_H += string-list.h
LIB_H += submodule.h
LIB_H += tag.h
-LIB_H += tar.h
+LIB_H += tar_git.h
LIB_H += thread-utils.h
LIB_H += transport.h
LIB_H += tree-walk.h
@@ -1256,12 +1256,12 @@ endif
ifdef NO_FNMATCH
COMPAT_CFLAGS += -Icompat/fnmatch
COMPAT_CFLAGS += -DNO_FNMATCH
- COMPAT_OBJS += compat/fnmatch/fnmatch.o
+ COMPAT_OBJS += compat/fnmatch/fnmatch_gnu.o
else
ifdef NO_FNMATCH_CASEFOLD
COMPAT_CFLAGS += -Icompat/fnmatch
COMPAT_CFLAGS += -DNO_FNMATCH_CASEFOLD
- COMPAT_OBJS += compat/fnmatch/fnmatch.o
+ COMPAT_OBJS += compat/fnmatch/fnmatch_gnu.o
endif
endif
ifdef USE_WILDMATCH
diff --git a/archive-tar.c b/archive-tar.c
index 719b629..8e24336 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -2,7 +2,7 @@
* Copyright (c) 2005, 2006 Rene Scharfe
*/
#include "cache.h"
-#include "tar.h"
+#include "tar_git.h"
#include "archive.h"
#include "streaming.h"
#include "run-command.h"
diff --git a/builtin/tar-tree.c b/builtin/tar-tree.c
index 3f1e701..b0e4551 100644
--- a/builtin/tar-tree.c
+++ b/builtin/tar-tree.c
@@ -3,7 +3,7 @@
*/
#include "cache.h"
#include "commit.h"
-#include "tar.h"
+#include "tar_git.h"
#include "builtin.h"
#include "quote.h"
diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch_gnu.c
similarity index 99%
rename from compat/fnmatch/fnmatch.c
rename to compat/fnmatch/fnmatch_gnu.c
index 5ef0685..f9a5e5b 100644
--- a/compat/fnmatch/fnmatch.c
+++ b/compat/fnmatch/fnmatch_gnu.c
@@ -26,7 +26,7 @@
#endif
#include <errno.h>
-#include <fnmatch.h>
+#include <fnmatch_gnu.h>
#include <ctype.h>
#if HAVE_STRING_H || defined _LIBC
diff --git a/compat/fnmatch/fnmatch.h b/compat/fnmatch/fnmatch_gnu.h
similarity index 100%
rename from compat/fnmatch/fnmatch.h
rename to compat/fnmatch/fnmatch_gnu.h
diff --git a/config.mak.uname b/config.mak.uname
index 8743a6d..2d42ffe 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -527,14 +527,21 @@ ifeq ($(uname_S),QNX)
HAVE_STRINGS_H = YesPlease
NEEDS_SOCKET = YesPlease
NO_FNMATCH_CASEFOLD = YesPlease
- NO_GETPAGESIZE = YesPlease
NO_ICONV = YesPlease
NO_MEMMEM = YesPlease
- NO_MKDTEMP = YesPlease
- NO_MKSTEMPS = YesPlease
NO_NSEC = YesPlease
- NO_PTHREADS = YesPlease
NO_R_TO_GCC_LINKER = YesPlease
- NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
+ # All QNX 6.x versions have pthread functions in libc
+ # and getpagesize. Leave mkstemps/mkdtemp/strcasestr for
+ # autodetection.
+ ifeq ($(shell expr "$(uname_R)" : '6\.[0-9]\.[0-9]'),5)
+ PTHREAD_LIBS = ""
+ else
+ NO_PTHREADS = YesPlease
+ NO_GETPAGESIZE = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_MKDTEMP = YesPlease
+ endif
endif
diff --git a/git-compat-util.h b/git-compat-util.h
index b7eaaa9..f59d696 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -113,7 +113,11 @@
#include <time.h>
#include <signal.h>
#ifndef USE_WILDMATCH
+#if defined(NO_FNMATCH) || defined(NO_FNMATCH_CASEFOLD)
+#include <fnmatch_gnu.h>
+#else
#include <fnmatch.h>
+#endif /* NO_FNMATCH */
#endif
#include <assert.h>
#include <regex.h>
diff --git a/pager.c b/pager.c
index c1ecf65..bed627a 100644
--- a/pager.c
+++ b/pager.c
@@ -81,7 +81,11 @@ void setup_pager(void)
pager_process.argv = pager_argv;
pager_process.in = -1;
if (!getenv("LESS")) {
+ #if !defined(__QNXNTO__)
static const char *env[] = { "LESS=FRSX", NULL };
+ #else
+ static const char *env[] = { "LESS=rS", NULL };
+ #endif /* __QNXNTO__ */
pager_process.env = env;
}
if (start_command(&pager_process))
diff --git a/tar.h b/tar_git.h
similarity index 100%
rename from tar.h
rename to tar_git.h
^ permalink raw reply related
* Re: [PATCH v2] Documentation/githooks: Explain pre-rebase parameters
From: Junio C Hamano @ 2013-02-24 8:13 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Thomas Rast
In-Reply-To: <20130223213513.GF1361@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Sat, Feb 23, 2013 at 01:21:59PM -0800, Junio C Hamano wrote:
>> "W. Trevor King" <wking@tremily.us> writes:
>>
>> > +This hook is called by 'git rebase' and can be used to prevent a
>> > +branch from getting rebased. The hook takes two parameters: the
>> > +upstream the series was forked from and the branch being rebased. The
>> > +second parameter will be missing when rebasing the current branch.
>>
>> takes one or two parameters?
>>
>> Other than that, looks good to me, but it took me two readings to
>> notice where these two parameters are described. I have a feeling
>> that a comma s/forked from and/forked from, and/; might make them a
>> bit more spottable, but others may have better suggestions to make
>> them stand out more.
>
> How about:
>
> The hook may be called with one or two parameters. The first
> parameter is the upstream from which the series was forked. The
> second parameter is the branch being rebased, and is not set when
> rebasing the current branch.
Much nicer. Thanks.
^ permalink raw reply
* Re: [PATCH] pkt-line: Fix sparse errors and warnings
From: Junio C Hamano @ 2013-02-24 8:36 UTC (permalink / raw)
To: Jeff King; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <20130223223700.GB2504@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Oddly, you seemed to miss the one in connect.c (which my sparse does
>> detect).
>
> Ah, I saw why as soon as I finished off the rebase: that (NULL, 0) goes
> away in the very next patch,...
Yeah, I noticed that myself while replacing 15. The patch in the
message I am responding to seems to match byte-for-byte with the
result of my rebase, too.
Thanks.
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Junio C Hamano @ 2013-02-24 8:46 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrMgJf2C3dAe1O2DW5qFYFnCDhbQNmpnvK4ZOduJnqwQWg@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
> Hello,
>
>> Here is a small patch with QNX build improvements:
>>
>> 1) Rename tar.h to tar_git.h. Latest QNX versions have system tar.h
>> header according to
>> http://pubs.opengroup.org/onlinepubs/009696699/basedefs/tar.h.html ,
>> to avoid inclusion of another tar.h, original header was renamed.
>> 2) Rename fnmatch.h to fnmatch_gnu.h and fnmatch.c to fnmatch_gnu.c to
>> avoid inclusion of system fnmatch.h header in case if -I/usr/include
>> path is specified before -Icompat/fnmatch. Which is common situation.
>> 3) pager.c - default "less" invocation flags were changed for QNX 6,x
>> platform, since QNX has incompatible with GNU coreutils version of
>> "less" utility.
>> 4) config.mak.uname - a) do not override mkdtemp/mkstemps/strcasestr
>> detection, since newer QNX version could contain such functions. Let
>> to configure decide what is present in the system. b) getpagesize()
>> function is existing under QNX, c) QNX has pthread functions in the
>> libc, so do not define NO_PTHREAD macro.
>
> Sorry, in the previous post the patch was not inlined.
First on the form. The message lacks a proper commit log message
and a sign-off. Please check Documentation/SubmittingPatches and
also compare the message I am responding to with recent patch
submission messages from other people on the list.
As to the substance, I am fairly negative about the approach this
patch takes, especially the rationale it uses for #2 above. It goes
directly against the spirit of having compat/ directory in the first
place to have -I/usr/include _before_ -Icompat/anything and that,
not the names of header files in compat/ directory, is the root
cause of the problem you are seeing, I think.
^ permalink raw reply
* Re: [PATCH 01/13] Use 'Git' in help messages
From: Junio C Hamano @ 2013-02-24 8:59 UTC (permalink / raw)
To: David Aguilar; +Cc: Philip Oakley, GitList
In-Reply-To: <CAJDDKr5VG_c_RRK3Z++RNUev=3swmT0HUDocJE1h1QtSHYrYJA@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> This is referring to "git the command", not "git the system",
> so it should not be changed according to the rule that was
> applied when many "git" strings were changed to "Git".
That sounds like a sensible objection.
> There are scripts, etc. in the wild that parse this output.
> which is another reason we would not want to change this.
Are there? For what purpose?
Especially when these are all _("l10n ready"), I find that somewhat
unlikely.
The bash completion (in contrib/) does read from the command list
IIRC. I do not think it relies on the messages, though.
^ permalink raw reply
* Re: [PATCH 05/13] Help.c: add list_common_guides_help() function
From: Junio C Hamano @ 2013-02-24 9:01 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-6-git-send-email-philipoakley@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
> diff --git a/common-guides.h b/common-guides.h
> new file mode 100644
> index 0000000..a8ad8d1
> --- /dev/null
> +++ b/common-guides.h
> @@ -0,0 +1,12 @@
> +/* Automatically generated by ./generate-guidelist.sh */
> +/* re-use struct cmdname_help in common-commands.h */
Huh?
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Junio C Hamano @ 2013-02-24 9:03 UTC (permalink / raw)
To: git; +Cc: Hilco Wijbenga, Eric Blake, libvir-list, Jeff King
In-Reply-To: <20130111185417.GA12852@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote:
> ...
> More seriously, I agree that re-wording the question is a reasonable
> thing to do. I do not use send-email, either, so I don't have a strong
> opinion on it. The suggestions you made:
>
>> How about "What Message-ID to use as In-Reply-To for the first email?"
>> or "Provide the Message-ID to use as In-Reply-To for the first
>> email:".
>
> seem fine to me. Maybe somebody who has been confused by it can offer
> more. At any rate, patches welcome.
Has anything come out of this discussion? Is the current phrasing
fine as-is?
^ permalink raw reply
* Re: [PATCH] attr: allow pattern escape using backslashes
From: Junio C Hamano @ 2013-02-24 9:15 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1357310809-4771-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Patterns in .gitattributes are separated by whitespaces, which makes
> it impossible to specify exact spaces in the pattern. '?' can be used
> as a workaround, but it matches other characters too. This patch makes
> a space following a backslash part of the pattern, not a pattern
> separator.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>
> A similar patch was posted twice (during freeze time iirc). I think
> this is a good change, so I will keep reposting until someone turns
> it down.
>
> We could use wildmatch for parsing here, which would support patterns
> like "Hello[ ]world". But that's not going to happen until wildmatch
> graduates and somebody brings it up again.
Do people have any comment on this? Do we do something similar in
the .gitignore files already?
Speaking of .gitignore, I recall that there was a hanging discussion
on allowing a pattern to name the directory that the .gitignore file
appears in, which I do not think we currently support. With such a
feature, instead of listing "/junk" in the .gitignore file at the
top-level to say that everything inside the "junk" directory is
ignored by default, we could instead say "<this>" at the beginning
of the .gitignore file in the "junk" directory. I think "* <attr>"
in the .gitattributes file in a directory causes "git check-attr ."
in that directory to report the <attr>, and we may want to have some
way to allow "git check-ignore ." to be affected by the .gitignore
file in the same directory in a similar way, but I do not have a
very strong opinion. Do people have any comment on this?
It is obviously too late for this cycle to do anything on the
'master' front on this topic (or the .gitignore), but it would be
good to reach concensus early so that we know what we want to do in
the next cycle.
> Documentation/gitattributes.txt | 6 +++---
> attr.c | 8 +++++++-
> t/t0003-attributes.sh | 5 +++++
> 3 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 2698f63..113b1f8 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -20,9 +20,9 @@ Each line in `gitattributes` file is of form:
>
> pattern attr1 attr2 ...
>
> -That is, a pattern followed by an attributes list,
> -separated by whitespaces. When the pattern matches the
> -path in question, the attributes listed on the line are given to
> +That is, a pattern followed by an attributes list, separated by
> +whitespaces that are not quoted by a backslash. When the pattern matches
> +the path in question, the attributes listed on the line are given to
> the path.
>
> Each attribute can be in one of these states for a given path:
> diff --git a/attr.c b/attr.c
> index 097ae87..776f34e 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -209,7 +209,13 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
> if (!*cp || *cp == '#')
> return NULL;
> name = cp;
> - namelen = strcspn(name, blank);
> + namelen = 0;
> + while (name[namelen] != '\0' && !strchr(blank, name[namelen])) {
> + if (name[namelen] == '\\' && name[namelen + 1] != '\0')
> + namelen += 2;
> + else
> + namelen++;
> + }
> if (strlen(ATTRIBUTE_MACRO_PREFIX) < namelen &&
> !prefixcmp(name, ATTRIBUTE_MACRO_PREFIX)) {
> if (!macro_ok) {
> diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
> index 807b8b8..6a5d8ab 100755
> --- a/t/t0003-attributes.sh
> +++ b/t/t0003-attributes.sh
> @@ -24,6 +24,7 @@ test_expect_success 'setup' '
> echo "offon -test test"
> echo "no notest"
> echo "A/e/F test=A/e/F"
> + echo "A\\ b test=space"
> ) >.gitattributes &&
> (
> echo "g test=a/g" &&
> @@ -196,6 +197,10 @@ test_expect_success 'root subdir attribute test' '
> attr_check subdir/a/i unspecified
> '
>
> +test_expect_success 'quoting in pattern' '
> + attr_check "A b" space
> +'
> +
> test_expect_success 'negative patterns' '
> echo "!f test=bar" >.gitattributes &&
> test_must_fail git check-attr test -- f
^ permalink raw reply
* Re: [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
From: Junio C Hamano @ 2013-02-24 9:15 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <1361638125-11245-1-git-send-email-apelisse@gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> When considering a rename for two files that have a suffix and a prefix
> that can overlap, a confusing line is shown. As an example, renaming
> "a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c".
This would be vastly more readable if it had "It should show XXX
instead" somewhere in the description, perhaps at the end of this
sentence. It can also be after "thus the { => }" below, but I think
giving the expected output earlier would be more appropriate.
> Currently, what we do is calculate the common prefix ("a/b/"), and the
> common suffix ("/b/c"), but the same "/b/" is actually counted both in
> prefix and suffix. Then when calculating the size of the non-common part,
> we end-up with a negative value which is reset to 0, thus the "{ => }".
In this example, the common prefix would be "a/b/" and the common
suffix that does not overlap with the prefix part would be "/c", so
I am imagining that "a/b/{ => b}/c" would be the desired output?
This is a really old thinko (dating back to June 2005). I'll queue
the patch on maint-1.7.6 (because 1.7.6.6 is slightly more than one
year old while 1.7.5.4 is a lot older) to allow distros that issue
incremental fixes on top of ancient versions of Git to pick up the
fix if they wanted to. Perhaps we would want to add a few tests?
Thanks.
>
> Do not allow the common suffix to overlap the common prefix and stop
> when reaching a "/" that would be in both.
>
> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
> ---
> diff.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/diff.c b/diff.c
> index 156fec4..80f4752 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1290,7 +1290,16 @@ static char *pprint_rename(const char *a, const char *b)
> old = a + len_a;
> new = b + len_b;
> sfx_length = 0;
> - while (a <= old && b <= new && *old == *new) {
> + /*
> + * Note:
> + * if pfx_length is 0, old/new will never reach a - 1 because it
> + * would mean the whole string is common suffix. But then, the
> + * whole string would also be a common prefix, and we would not
> + * have pfx_length equals 0.
> + */
> + while (a + pfx_length - 1 <= old &&
> + b + pfx_length - 1 <= new &&
> + *old == *new) {
> if (*old == '/')
> sfx_length = len_a - (old - a);
> old--;
> --
> 1.7.9.5
^ permalink raw reply
* Re: patch for fix build git on Haiku
From: Andreas Färber @ 2013-02-24 9:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: diger, git, HaikuPorts developers discussion list
In-Reply-To: <20130223204208.GB3222@elie.Belkin>
Hi,
Am 23.02.2013 21:42, schrieb Jonathan Nieder:
> diger wrote:
>
>> This patch fixes build git on Haiku
>
> Lovely. May we have your sign-off? (See
> Documentation/SubmittingPatches for what this means.) Does "make
> test" pass? (Just curious --- it's fine if it doesn't, though in that
> case a list of test failures would be helpful.)
>
> Thanks,
> Jonathan
>
> (patch left unsnipped for reference)
>
>> --- Makefile.orig 2012-10-21 21:32:15.000000000 +0000
>> +++ Makefile
>> @@ -1211,6 +1204,16 @@ ifeq ($(uname_S),HP-UX)
>> endif
>> GIT_TEST_CMP = cmp
>> endif
>> +ifeq ($(uname_S),Haiku)
>> + NO_R_TO_GCC_LINKER = YesPlease
>> + NO_LIBGEN_H = YesPlease
>> + NO_MEMMEM = YesPlease
>> + NO_MKSTEMPS = YesPlease
>> + NEEDS_LIBICONV = YesPlease
>> + DEFAULT_EDITOR = nano
Patch looks okay from what I have from my earlier ones in mind, but I
believe nano is an Optional Package on Haiku and thus not guaranteed to
be installed. CC'ing HaikuPorts.
Regards,
Andreas
>> + PTHREAD_LIBS = -lroot
>> + NO_CROSS_DIRECTORY_HARDLINKS = YesPlease
>> +endif
>> ifeq ($(uname_S),Windows)
>> GIT_VERSION := $(GIT_VERSION).MSVC
>> pathsep = ;
^ permalink raw reply
* Load testing of git
From: Yuri Mikhailov @ 2013-02-24 12:54 UTC (permalink / raw)
To: git
Dear Git community,
I am a Software Developer and I have been using git for a while.
Currently my company is looking for a version control system to use
and we find Git a good candidate for us. But what is important for us
to know is scalability of this VCS. Does anyone performed load testing
of Git? What is the practical maximum number of files and revisions
this system can handle?
Best regards,
Iurii Mykhailov
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Mike Gorchak @ 2013-02-24 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vvc9i5cbw.fsf@alter.siamese.dyndns.org>
>>> 2) Rename fnmatch.h to fnmatch_gnu.h and fnmatch.c to fnmatch_gnu.c to
>>> avoid inclusion of system fnmatch.h header in case if -I/usr/include
>>> path is specified before -Icompat/fnmatch. Which is common situation.
> As to the substance, I am fairly negative about the approach this
> patch takes, especially the rationale it uses for #2 above. It goes
> directly against the spirit of having compat/ directory in the first
> place to have -I/usr/include _before_ -Icompat/anything and that,
> not the names of header files in compat/ directory, is the root
> cause of the problem you are seeing, I think.
It is quite common to pass CPPFLAGS/CFLAGS/CXXFLAGS before configure
script to make a custom build. For example, I have specific set of
headers which belong to another version of libc, so I pass directory
where these headers are located right before configure script:
CFLAGS="-I/usr/qnxVVV/include" LDFLAGS="-I/usr/qnxVVV/lib" ./configure
--prefix=/usr
About this you can read by typing ./configure --help. This approach
works for every autoconf-based project, except for GIT due to headers
collision. I do not know anything about "spirit of compat/ directory",
but if it interferes with the normal build process, it means something
is wrong. But it is up to you.
Thanks.
^ permalink raw reply
* Re: [PATCH 02/13] Show 'git help <guide>' usage, with examples
From: W. Trevor King @ 2013-02-24 14:39 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-3-git-send-email-philipoakley@iee.org>
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
On Sat, Feb 23, 2013 at 11:05:50PM +0000, Philip Oakley wrote:
> + "Examples: 'git help git', 'git help branch', 'git help tutorial'..");
This sentence should end in '.', not '..'.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 06/13] Add guide-list.txt and extraction shell
From: W. Trevor King @ 2013-02-24 14:51 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-7-git-send-email-philipoakley@iee.org>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
On Sat, Feb 23, 2013 at 11:05:54PM +0000, Philip Oakley wrote:
> +# Usage: ./generate-guidelist.sh >>common-guides.h
Following David's recent series, it's probably better to use a
lowercase 'usage' [1]. Also, I'd expect '>common-guides.h' would make
more sense than appending with '>>'.
> +/* re-use struct cmdname_help in common-commands.h */
> +
> +static struct cmdname_help common_guides[] = {"
This is probably just copied from generate-cmdlist.sh, but maybe it
would be a good idea to #include "common-commands.h" here?
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/216961
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 09/13] Rename everyday to giteveryday
From: W. Trevor King @ 2013-02-24 14:55 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-10-git-send-email-philipoakley@iee.org>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On Sat, Feb 23, 2013 at 11:05:57PM +0000, Philip Oakley wrote:
> diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
> index e1fba85..3fc69f6 100644
> --- a/Documentation/everyday.txt
> +++ b/Documentation/everyday.txt
> @@ -1,413 +1,25 @@
> -Everyday Git With 20 Commands Or So
> +Everyday GIT With 20 Commands Or So
> ===================================
This looks like it's opposing 48a8c26 (Documentation: avoid poor-man's
small caps GIT, 2013-01-21). Another reason to use 'Git' over 'GIT'
is to match the page we're redirecting to:
> new file mode 100644
> index 0000000..e1fba85
> --- /dev/null
> +++ b/Documentation/giteveryday.txt
> @@ -0,0 +1,413 @@
> +Everyday Git With 20 Commands Or So
> +===================================
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 12/13] Documentation/Makefile: update git guide links
From: W. Trevor King @ 2013-02-24 14:58 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-13-git-send-email-philipoakley@iee.org>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
On Sat, Feb 23, 2013 at 11:06:00PM +0000, Philip Oakley wrote:
> OBSOLETE_HTML = git-remote-helpers.html
> +OBSOLETE_HTML = everyday.html
> +OBSOLETE_HTML = user-manual.html
> DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)
Should be '+=' instead of '='.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 13/13] Fixup! doc: giteveryday and user-manual man format
From: W. Trevor King @ 2013-02-24 15:01 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-14-git-send-email-philipoakley@iee.org>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Sat, Feb 23, 2013 at 11:06:01PM +0000, Philip Oakley wrote:
> diff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt
> index a4778d7..e991b11 100644
> --- a/Documentation/gituser-manual.txt
> +++ b/Documentation/gituser-manual.txt
> @@ -1,7 +1,12 @@
> Git User's Manual (for version 1.5.3 or newer)
> -______________________________________________
> +==============================================
I'd be happy dropping the parenthetical bit here. It's hard to
imagine someone still running something earlier than 1.5.3. It's even
harder to imagine them installing a modern user manual man page for
their old Git version ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Load testing of git
From: Thomas Koch @ 2013-02-24 16:58 UTC (permalink / raw)
To: Yuri Mikhailov; +Cc: git
In-Reply-To: <CAGjB8pR+uByiJJikBXbaxUZO4rDgyfvJ31agxaQuWrMwSS1N7Q@mail.gmail.com>
Yuri Mikhailov:
> Dear Git community,
>
> I am a Software Developer and I have been using git for a while.
> Currently my company is looking for a version control system to use
> and we find Git a good candidate for us. But what is important for us
> to know is scalability of this VCS. Does anyone performed load testing
> of Git? What is the practical maximum number of files and revisions
> this system can handle?
>
> Best regards,
> Iurii Mykhailov
Have a look at the projects using Git[1]. There are for sure projects that
exceeds the scalability you're thinking about. The linux Kernel might be the
biggest project.
[1] https://git.wiki.kernel.org/index.php/GitProjects
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* Certificate validation vulnerability in Git
From: Zubin Mithra @ 2013-02-24 17:31 UTC (permalink / raw)
To: git; +Cc: Dhanesh K.
Hello,
There seems to be a security issue in the way git uses openssl for
certificate validation. Similar occurrences have been found and
documented in other open source projects, the research can be found at
[1].
-=========]
- imap-send.c
Line 307
307 ret = SSL_connect(sock->ssl);
308 if (ret <= 0) {
309 socket_perror("SSL_connect", sock, ret);
310 return -1;
311 }
312
Certificate validation errors are signaled either through return
values of SSL_connect or by setting internal flags. The internal flags
need to be checked using the SSL_get_verify_result function. This is
not performed.
Kindly fix these issues, file a CVE and credit it to Dhanesh K. and
Zubin Mithra. Thanks.
We are not subscribed to this list, so we'd appreciate it if you could
CC us in the replies.
Hope this helps.
Thanks!
Zubin
[1] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
^ permalink raw reply
* Re: Load testing of git
From: Jeff Epler @ 2013-02-24 17:54 UTC (permalink / raw)
To: Yuri Mikhailov; +Cc: git
In-Reply-To: <CAGjB8pR+uByiJJikBXbaxUZO4rDgyfvJ31agxaQuWrMwSS1N7Q@mail.gmail.com>
In 2012 there was a thread about git's performance on large
repositories. One archive of the discussion begins here:
http://mid.gmane.org/CB5074CF.3AD7A%25joshua.redstone%40fb.com
> The test repo has 4 million commits, linear history and about 1.3
> million files.
I'm not sure to what extent git performance may have changed since then,
e.g., by improving the index format.
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox