* Re: Crashes while trying to show tag objects with bad timestamps
From: Jeff King @ 2013-02-25 18:21 UTC (permalink / raw)
To: Mantas Mikulėnas; +Cc: Junio C Hamano, git
In-Reply-To: <CAPWNY8UMkxvLPk2TxCz+BAat1sNXitjhv=yqcdY0yZ1OLjgd0w@mail.gmail.com>
On Sat, Feb 23, 2013 at 01:14:40AM +0200, Mantas Mikulėnas wrote:
> > Then I think it would make sense to allow the very specific no-date tag,
> > but not allow arbitrary crud. I wonder if there's an example in the
> > kernel or in git.git.
>
> I couldn't find any such examples. However, I did find several tags
> with no "tagger" line at all: git.git has "v0.99" and linux.git has
> many such tags starting with "v2.6.11" ending with "v2.6.13-rc3".
Yes, I think Junio was mis-remembering the exact condition. It looks
like we added tagger lines in c818566 ([PATCH] Update tags to record who
made them, 2005-07-14), which pulls the identity straight from "git var
GIT_COMMITTER_IDENT". I double-checked to be sure that we included the
date stamp at that time, and we did.
When parsing such a tag, we put a "0" in the date field of the "struct
tag", and I suspect that is what caused the memory confusion.
So I think we are fine to fsck tagger lines as we do ordinary
author/committer ident lines; the only exception is that we should not
complain if they do not exist.
> It seems that `git cat-file -p` doesn't like such tags too – if there
> is no "tagger", it doesn't display *any* header lines. More bugs?
Yeah, I think we should just rid of that parser entirely. It is very
inconsistent with the pretty-printer used by "git show", as well as the
one used by "git for-each-ref", not to mention parse_tag (ugh, how many
tag parsers do we have?).
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
From: Mike Gorchak @ 2013-02-25 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhal0z4a5.fsf@alter.siamese.dyndns.org>
> Also, please leave the "autodetection" out. If it is common to have
> strcasestr (or any other) on a newer QNX, then not defining the
> symbol NO_STRCASESTR in this file may still be the right thing to
> do, but the justification for such a change should not be because we
> rely on "autodetection". The defaults given in config.mak.uname is
> primarily for people who do not use the optional ./configure script,
> so pick the default to help the most common configuration for the
> platform.
I see. I thought configure is the only legal way to build the git and
config.mak.uname is used to override settings produced by configure.
But it works vice versa configure settings override config.mak.uname
settings. Please do not commit this patch. This patch brokes QNX 6.3.2
build.
> I'd rewrite the patch like the attached, and tentatively queue the
> patch to 'pu', but I do not use or have access to QNX myself, so you
> may have to adjust the default set of symbols and the log message
> and in such a case, please do re-submit a fixed version.
I will re-do the patch.
> Specifically, I do not know if "... and others are also supported"
> is universally true with QNX 6; if not, we need to define NO_* for
> them to help people who build without using the ./configure script.
Ok.
^ permalink raw reply
* Re: Git 1.8.2 l10n round 3
From: Junio C Hamano @ 2013-02-25 17:47 UTC (permalink / raw)
To: Jiang Xin; +Cc: Git List, Tran Ngoc Quan, Peter Krefting, Ralf Thielow
In-Reply-To: <CANYiYbHPtW0u80ojHt9xoADVS8S8mVkubb6dUDN_1uwkcTZTww@mail.gmail.com>
Thanks.
^ permalink raw reply
* Re: Git 1.8.2 l10n round 3
From: Junio C Hamano @ 2013-02-25 17:45 UTC (permalink / raw)
To: Jiang Xin; +Cc: Git List, Tran Ngoc Quan, Peter Krefting, Ralf Thielow
In-Reply-To: <CANYiYbHPtW0u80ojHt9xoADVS8S8mVkubb6dUDN_1uwkcTZTww@mail.gmail.com>
Thanks.
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Junio C Hamano @ 2013-02-25 17:44 UTC (permalink / raw)
To: Florian Achleitner
Cc: git, Jeff King, Thomas Rast, Shawn Pearce, Jakub Narebski,
Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, Ramkumar Ramachandra,
Jens Lehmann, Nguyen Thai Ngoc Duy, David Barr
In-Reply-To: <453931856.Va6j4WpQCl@flomedio>
Florian Achleitner <florian.achleitner2.6.31@gmail.com> writes:
> For a student one aspect of GSOC is also quite important: It is a cool and
> demanding summer job during the holidays, but it has to ramp down when the new
> semester starts.
Thanks for sharing.
I think an important lesson is that mentors and reviewers need to
think really hard to limit the initial scope of the assignment to be
not too ambitious. Starting with an ambitious goal and achieving
only small first steps of them _can_ still be a good end result, but
if a mentor wants to go that route, the decision to cut down the
scope of an ambitous assignment needs to be made early enough to
leave sufficient time to wrap up the half-done assignment in a good
shape. Finishing with implementation of only the initial 30% of an
unproven design, that by itself is not useful, does not help our
project at all, and it does not give satisfaction to the student,
either.
^ permalink raw reply
* Re: [PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
From: Junio C Hamano @ 2013-02-25 17:34 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrPTe6Q4BPtsGjiRnfFjZjUjwY6qXSAtZCzzAthODzA6EA@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
> Add pthread support in QNX. Do not declare NO_ macros if they can be
> autodetected.
>
> From: Mike Gorchak <mike.gorchak.qnx@gmail.com>
> Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
One procedural nit. Please drop that "From:" immediately before
S-o-b: from future submissions (I'll remove it locally for this
patch and others you already posted when I apply, so this alone is
not a reason to resend them). If you are forwarding somebody else's
patch, you would want "From:" in body, but the correct place to do
so is before everything else, i.e.
... your e-mail headers ...
From: Mike Gorchak <your.email@address.xz>
Subject: [PATCH] title of the patch
... your e-mail body ...
From: A U Thor <real.author@address.xz>
The first line of the commit log message and
the second line of it.
Signed-off-by: A U Thor <real.author@address.xz>
Signed-off-by: Mike Gorchak <your.email@address.xz>
Also, please leave the "autodetection" out. If it is common to have
strcasestr (or any other) on a newer QNX, then not defining the
symbol NO_STRCASESTR in this file may still be the right thing to
do, but the justification for such a change should not be because we
rely on "autodetection". The defaults given in config.mak.uname is
primarily for people who do not use the optional ./configure script,
so pick the default to help the most common configuration for the
platform.
I'd rewrite the patch like the attached, and tentatively queue the
patch to 'pu', but I do not use or have access to QNX myself, so you
may have to adjust the default set of symbols and the log message
and in such a case, please do re-submit a fixed version.
Specifically, I do not know if "... and others are also supported"
is universally true with QNX 6; if not, we need to define NO_* for
them to help people who build without using the ./configure script.
Thanks.
-- >8 --
From: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Date: Mon, 25 Feb 2013 10:39:27 +0200
Subject: [PATCH] QNX: newer QNX 6.x.x is not so crippled
The initial port to QNX declared that the platform does not have
support for pthreads, getpagesize, strcasestr, mkstemps, mkdtemp,
strlcpy, and iconv, but QNX 6.x.x does support these.
On the other hand, older QNX lack gettext support, so define
NO_GETTEXT for them.
Also newer QNX do not need to link to any special library to enable
pthreads; define PTHREAD_LIBS to an empty string.
Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
config.mak.uname | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 8743a6d..ce2832b 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;
+ # getpagesize and others are also supported.
+ 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
+ NO_STRLCPY = YesPlease
+ NO_ICONV = YesPlease
+ NO_GETTEXT = YesPlease
+ endif
endif
--
1.8.2.rc0.167.gd8ba4de
^ permalink raw reply related
* Re: [RFC/WIP PATCH 1/3] teach config parsing to read from strbuf
From: Heiko Voigt @ 2013-02-25 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7v4nh13plo.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Sun, Feb 24, 2013 at 09:54:43PM -0800, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
>
> > diff --git a/config.c b/config.c
> > index aefd80b..f995e98 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -13,6 +13,9 @@
> > typedef struct config_file {
> > struct config_file *prev;
> > FILE *f;
> > + int is_strbuf;
> > + struct strbuf *strbuf_contents;
> > + int strbuf_pos;
> > const char *name;
> > int linenr;
> > int eof;
>
> The idea to allow more kinds of sources specified for "config_file"
> structure is not bad per-se, but whenever you design an enhancement
> to something that currently supports only on thing to allow taking
> another kind, please consider what needs to be done by the next
> person who adds the third kind. That would help catch design
> mistakes early. For example, will the "string-list" (I am not
> saying use of string-list makes sense as the third kind; just as an
> example off the top of my head) source patch add
>
> int is_string_list;
> struct string_list *string_list_contents;
>
> fields to this structure? Sounds insane for at least two reasons:
>
> * if both is_strbuf and is_string_list are true, what should
> happen?
>
> * is there a good reason to waste storage for the three fields your
> patch adds when sring_list strage (or FILE * storage for that
> matter) is used?
>
> The helper functions like config_fgetc() and config_ftell() sounds
> like you are going in the right direction but may want to do the
> OO-in-C in a similar way transport.c does, keeping a pointer to a
> structure of methods, but I didn't read the remainder of this patch
> very carefully enough to comment further.
Thanks for taking a look. You suggestion sounds reasonable, I will
modify my patch accordingly.
Cheers Heiko
^ permalink raw reply
* Possible regression in ref advertisement
From: Carlos Martín Nieto @ 2013-02-25 16:58 UTC (permalink / raw)
To: git
Hi all,
When testing to see if a different implementation was in shape, I came
across something odd where newer git doesn't advertise one of the refs
in the git repo.
Running `git ls-remote .` or `git-upload-pack` in my git repo, newer git
versions omit peeling the v1.8.0-rc3 tag.
The diff between the command above when ran with 1.7.10.4 (from Debian)
and current 'master'
--- old 2013-02-25 17:31:29.583526606 +0100
+++ new 2013-02-25 17:31:36.783526559 +0100
@@ -1379,7 +1379,6 @@
c15295d7477ccec489953299bd03a8e62f86e611 refs/tags/v1.8.0-rc2
cd46259ebf2e624bcee2aaae05c36663d414e1a2 refs/tags/v1.8.0-rc2^{}
22ed067acc84eac8a0a72d20478a18aee4e25571 refs/tags/v1.8.0-rc3
-87a5461fa7b30f7b7baf27204f10219d61500fbf refs/tags/v1.8.0-rc3^{}
bfeb8b9ae0012cb61e026cbcd29664876abf5389 refs/tags/v1.8.0.1
ed9fe755130891fc878bb2433204faffb534697b refs/tags/v1.8.0.1^{}
63add1fb45e1ab7a76bb38bbb9467c91fdfaaa7e refs/tags/v1.8.0.2
Diffing with the output from next, diff tells me it's binary for some
reason, but looking manually, the peeled v1.8.0-rc3 tag isn't there
either. I haven't had time to bisect this, so I'm putting it out there
in case anybody wants to investigate before I have time to dig into it.
cmn
^ permalink raw reply
* Merging submodules - best merge-base
From: Daniel Bratell @ 2013-02-25 16:44 UTC (permalink / raw)
To: git
I can phrase this in two ways and I'll start with the short way:
Why does a merge of a git submodule use as merge-base the commit that was
active in the merge-base of the parent repo, rather than the merge-base of
the two commits that are being merged?
The long question is:
A submodule change can be merged, but only if the merge is a
"fast-forward" which I think is a fair demand, but currently it checks if
it's a fast-forward from a commit that might not be very interesting
anymore.
If two branches A and B split at a point when they used submodule commit
S1 (based on S), and both then switched to S2 (also based on S) and B then
switched to S21, then it's today not possible to merge B into A, despite
S21 being a descendant of S2 and you get a conflict and this warning:
warning: Failed to merge submodule S (commits don't follow merge-base)
(attempt at ASCII gfx:
Submodule tree:
S ---- S1
\
\ - S2 -- S21
Main tree:
A' (uses S1) --- A (uses S2)
\
\ --- B' (uses S2) -- B (uses S21)
I would like it to end up as:
A' (uses S1) --- A (uses S2) ------------ A+ (uses S21)
\ /
\ --- B' (uses S2) -- B (uses S21)- /
And that should be legal since S21 is a descendant of S2.
/Daniel
^ permalink raw reply
* Re: [PATCHv6] Add contrib/credentials/netrc with GPG support
From: Ted Zlatanov @ 2013-02-25 16:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130208061855.GA11892@sigill.intra.peff.net>
On Fri, 8 Feb 2013 01:18:55 -0500 Jeff King <peff@peff.net> wrote:
>> + # the following check is copied from Net::Netrc, for non-GPG files
>> + # OS/2 and Win32 do not handle stat in a way compatable with this check :-(
JK> s/compatable/compatible/
This is from the Net::Netrc module. Fixed in my commit but eh...
JK> You mention os/2 and Win32 here, but the check has more:
>> + unless ($gpgmode || $options{insecure} ||
>> + $^O eq 'os2'
>> + || $^O eq 'MSWin32'
>> + || $^O eq 'MacOS'
>> + || $^O =~ /^cygwin/) {
JK> Does MacOS really not handle stat? Or is this old MacOS, not OS X?
This is all out of Net::Netrc, and yes, it's pre-Mac OS X. I think it's
safe to leave as is, but I can remove OS/2 and MacOS if you prefer.
JK> So this will convert:
JK> machine foo port smtp
JK> in the netrc into (protocol => "smtp", host => "foo"), but:
JK> machine foo port 25
JK> into (protocol => undef, host => "foo:25"), right? That makes sense to
JK> me.
Yes. test.pl checks that host=foo doesn't find the above, as well.
JK> I don't know if you want to take the hit of relying on Git.pm (it is
JK> nice for the helper to be totally standalone and copy-able), but one
JK> obvious possible refactor would be to use the credential read/write
JK> functions recently added there. I'm OK with not doing that, though.
JK> It may also be worth building on top of the regular git test harness.
JK> It's more work, but the resulting code (and the output) will be much
JK> more readable.
At least for now let's leave it standalone. When and if it moves into
the core, we can change it to use the core's Git.pm and test suite. The
code and the tests are small enough that I think using Perl's Test
module makes the most sense right now.
JK> Printf? Bleh, isn't this supposed to be perl? :P
What? Was I supposed to use formats?!?!
JK> You are depending on whatever the user has in their ~/.netrc, no?
JK> Wouldn't it make more sense to ship a sample netrc and run all of the
JK> tests with "-f netrc.example"?
Yes. See test.netrc.
Thanks
Ted
^ permalink raw reply
* [PATCH v7] Add contrib/credentials/netrc with GPG support
From: Ted Zlatanov @ 2013-02-25 15:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <876226p97h.fsf_-_@lifelogs.com>
This credential helper supports multiple files, returning the first one
that matches. It checks file permissions and owner. For *.gpg files,
it will run GPG to decrypt the file.
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
Changes since PATCHv6:
- change Makefile test to test.pl (using Perl Test module) + test.netrc
* `make test' runs all the tests in the standard Test format
* `make testverbose' runs the tests with -d -v to see what's happening
- fix missing semicolons and minor typos
contrib/credential/netrc/Makefile | 5 +
contrib/credential/netrc/git-credential-netrc | 421 +++++++++++++++++++++++++
contrib/credential/netrc/test.netrc | 13 +
contrib/credential/netrc/test.pl | 106 +++++++
4 files changed, 545 insertions(+), 0 deletions(-)
create mode 100644 contrib/credential/netrc/Makefile
create mode 100755 contrib/credential/netrc/git-credential-netrc
create mode 100644 contrib/credential/netrc/test.netrc
create mode 100755 contrib/credential/netrc/test.pl
diff --git a/contrib/credential/netrc/Makefile b/contrib/credential/netrc/Makefile
new file mode 100644
index 0000000..51b7613
--- /dev/null
+++ b/contrib/credential/netrc/Makefile
@@ -0,0 +1,5 @@
+test:
+ ./test.pl
+
+testverbose:
+ ./test.pl -d -v
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
new file mode 100755
index 0000000..6c51c43
--- /dev/null
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -0,0 +1,421 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use File::Basename;
+
+my $VERSION = "0.1";
+
+my %options = (
+ help => 0,
+ debug => 0,
+ verbose => 0,
+ insecure => 0,
+ file => [],
+
+ # identical token maps, e.g. host -> host, will be inserted later
+ tmap => {
+ port => 'protocol',
+ machine => 'host',
+ path => 'path',
+ login => 'username',
+ user => 'username',
+ password => 'password',
+ }
+ );
+
+# Map each credential protocol token to itself on the netrc side.
+foreach (values %{$options{tmap}}) {
+ $options{tmap}->{$_} = $_;
+}
+
+# Now, $options{tmap} has a mapping from the netrc format to the Git credential
+# helper protocol.
+
+# Next, we build the reverse token map.
+
+# When $rmap{foo} contains 'bar', that means that what the Git credential helper
+# protocol calls 'bar' is found as 'foo' in the netrc/authinfo file. Keys in
+# %rmap are what we expect to read from the netrc/authinfo file.
+
+my %rmap;
+foreach my $k (keys %{$options{tmap}}) {
+ push @{$rmap{$options{tmap}->{$k}}}, $k;
+}
+
+Getopt::Long::Configure("bundling");
+
+# TODO: maybe allow the token map $options{tmap} to be configurable.
+GetOptions(\%options,
+ "help|h",
+ "debug|d",
+ "insecure|k",
+ "verbose|v",
+ "file|f=s@",
+ );
+
+if ($options{help}) {
+ my $shortname = basename($0);
+ $shortname =~ s/git-credential-//;
+
+ print <<EOHIPPUS;
+
+$0 [-f AUTHFILE1] [-f AUTHFILEN] [-d] [-v] [-k] get
+
+Version $VERSION by tzz\@lifelogs.com. License: BSD.
+
+Options:
+
+ -f|--file AUTHFILE : specify netrc-style files. Files with the .gpg extension
+ will be decrypted by GPG before parsing. Multiple -f
+ arguments are OK. They are processed in order, and the
+ first matching entry found is returned via the credential
+ helper protocol (see below).
+
+ When no -f option is given, .authinfo.gpg, .netrc.gpg,
+ .authinfo, and .netrc files in your home directory are used
+ in this order.
+
+ -k|--insecure : ignore bad file ownership or permissions
+
+ -d|--debug : turn on debugging (developer info)
+
+ -v|--verbose : be more verbose (show files and information found)
+
+To enable this credential helper:
+
+ git config credential.helper '$shortname -f AUTHFILE1 -f AUTHFILE2'
+
+(Note that Git will prepend "git-credential-" to the helper name and look for it
+in the path.)
+
+...and if you want lots of debugging info:
+
+ git config credential.helper '$shortname -f AUTHFILE -d'
+
+...or to see the files opened and data found:
+
+ git config credential.helper '$shortname -f AUTHFILE -v'
+
+Only "get" mode is supported by this credential helper. It opens every AUTHFILE
+and looks for the first entry that matches the requested search criteria:
+
+ 'port|protocol':
+ The protocol that will be used (e.g., https). (protocol=X)
+
+ 'machine|host':
+ The remote hostname for a network credential. (host=X)
+
+ 'path':
+ The path with which the credential will be used. (path=X)
+
+ 'login|user|username':
+ The credential’s username, if we already have one. (username=X)
+
+Thus, when we get this query on STDIN:
+
+host=github.com
+protocol=https
+username=tzz
+
+this credential helper will look for the first entry in every AUTHFILE that
+matches
+
+machine github.com port https login tzz
+
+OR
+
+machine github.com protocol https login tzz
+
+OR... etc. acceptable tokens as listed above. Any unknown tokens are
+simply ignored.
+
+Then, the helper will print out whatever tokens it got from the entry, including
+"password" tokens, mapping back to Git's helper protocol; e.g. "port" is mapped
+back to "protocol". Any redundant entry tokens (part of the original query) are
+skipped.
+
+Again, note that only the first matching entry from all the AUTHFILEs, processed
+in the sequence given on the command line, is used.
+
+Netrc/authinfo tokens can be quoted as 'STRING' or "STRING".
+
+No caching is performed by this credential helper.
+
+EOHIPPUS
+
+ exit 0;
+}
+
+my $mode = shift @ARGV;
+
+# Credentials must get a parameter, so die if it's missing.
+die "Syntax: $0 [-f AUTHFILE1] [-f AUTHFILEN] [-d] get" unless defined $mode;
+
+# Only support 'get' mode; with any other unsupported ones we just exit.
+exit 0 unless $mode eq 'get';
+
+my $files = $options{file};
+
+# if no files were given, use a predefined list.
+# note that .gpg files come first
+unless (scalar @$files) {
+ my @candidates = qw[
+ ~/.authinfo.gpg
+ ~/.netrc.gpg
+ ~/.authinfo
+ ~/.netrc
+ ];
+
+ $files = $options{file} = [ map { glob $_ } @candidates ];
+}
+
+my $query = read_credential_data_from_stdin();
+
+FILE:
+foreach my $file (@$files) {
+ my $gpgmode = $file =~ m/\.gpg$/;
+ unless (-r $file) {
+ log_verbose("Unable to read $file; skipping it");
+ next FILE;
+ }
+
+ # the following check is copied from Net::Netrc, for non-GPG files
+ # OS/2 and Win32 do not handle stat in a way compatible with this check :-(
+ unless ($gpgmode || $options{insecure} ||
+ $^O eq 'os2'
+ || $^O eq 'MSWin32'
+ || $^O eq 'MacOS'
+ || $^O =~ /^cygwin/) {
+ my @stat = stat($file);
+
+ if (@stat) {
+ if ($stat[2] & 077) {
+ log_verbose("Insecure $file (mode=%04o); skipping it",
+ $stat[2] & 07777);
+ next FILE;
+ }
+
+ if ($stat[4] != $<) {
+ log_verbose("Not owner of $file; skipping it");
+ next FILE;
+ }
+ }
+ }
+
+ my @entries = load_netrc($file, $gpgmode);
+
+ unless (scalar @entries) {
+ if ($!) {
+ log_verbose("Unable to open $file: $!");
+ } else {
+ log_verbose("No netrc entries found in $file");
+ }
+
+ next FILE;
+ }
+
+ my $entry = find_netrc_entry($query, @entries);
+ if ($entry) {
+ print_credential_data($entry, $query);
+ # we're done!
+ last FILE;
+ }
+}
+
+exit 0;
+
+sub load_netrc {
+ my $file = shift @_;
+ my $gpgmode = shift @_;
+
+ my $io;
+ if ($gpgmode) {
+ my @cmd = (qw(gpg --decrypt), $file);
+ log_verbose("Using GPG to open $file: [@cmd]");
+ open $io, "-|", @cmd;
+ } else {
+ log_verbose("Opening $file...");
+ open $io, '<', $file;
+ }
+
+ # nothing to do if the open failed (we log the error later)
+ return unless $io;
+
+ # Net::Netrc does this, but the functionality is merged with the file
+ # detection logic, so we have to extract just the part we need
+ my @netrc_entries = net_netrc_loader($io);
+
+ # these entries will use the credential helper protocol token names
+ my @entries;
+
+ foreach my $nentry (@netrc_entries) {
+ my %entry;
+ my $num_port;
+
+ if (!defined $nentry->{machine}) {
+ next;
+ }
+ if (defined $nentry->{port} && $nentry->{port} =~ m/^\d+$/) {
+ $num_port = $nentry->{port};
+ delete $nentry->{port};
+ }
+
+ # create the new entry for the credential helper protocol
+ $entry{$options{tmap}->{$_}} = $nentry->{$_} foreach keys %$nentry;
+
+ # for "host X port Y" where Y is an integer (captured by
+ # $num_port above), set the host to "X:Y"
+ if (defined $entry{host} && defined $num_port) {
+ $entry{host} = join(':', $entry{host}, $num_port);
+ }
+
+ push @entries, \%entry;
+ }
+
+ return @entries;
+}
+
+sub net_netrc_loader {
+ my $fh = shift @_;
+ my @entries;
+ my ($mach, $macdef, $tok, @tok);
+
+ LINE:
+ while (<$fh>) {
+ undef $macdef if /\A\n\Z/;
+
+ if ($macdef) {
+ next LINE;
+ }
+
+ s/^\s*//;
+ chomp;
+
+ while (length && s/^("((?:[^"]+|\\.)*)"|((?:[^\\\s]+|\\.)*))\s*//) {
+ (my $tok = $+) =~ s/\\(.)/$1/g;
+ push(@tok, $tok);
+ }
+
+ TOKEN:
+ while (@tok) {
+ if ($tok[0] eq "default") {
+ shift(@tok);
+ $mach = { machine => undef };
+ next TOKEN;
+ }
+
+ $tok = shift(@tok);
+
+ if ($tok eq "machine") {
+ my $host = shift @tok;
+ $mach = { machine => $host };
+ push @entries, $mach;
+ } elsif (exists $options{tmap}->{$tok}) {
+ unless ($mach) {
+ log_debug("Skipping token $tok because no machine was given");
+ next TOKEN;
+ }
+
+ my $value = shift @tok;
+ unless (defined $value) {
+ log_debug("Token $tok had no value, skipping it.");
+ next TOKEN;
+ }
+
+ # Following line added by rmerrell to remove '/' escape char in .netrc
+ $value =~ s/\/\\/\\/g;
+ $mach->{$tok} = $value;
+ } elsif ($tok eq "macdef") { # we ignore macros
+ next TOKEN unless $mach;
+ my $value = shift @tok;
+ $macdef = 1;
+ }
+ }
+ }
+
+ return @entries;
+}
+
+sub read_credential_data_from_stdin {
+ # the query: start with every token with no value
+ my %q = map { $_ => undef } values(%{$options{tmap}});
+
+ while (<STDIN>) {
+ next unless m/^([^=]+)=(.+)/;
+
+ my ($token, $value) = ($1, $2);
+ die "Unknown search token $token" unless exists $q{$token};
+ $q{$token} = $value;
+ log_debug("We were given search token $token and value $value");
+ }
+
+ foreach (sort keys %q) {
+ log_debug("Searching for %s = %s", $_, $q{$_} || '(any value)');
+ }
+
+ return \%q;
+}
+
+# takes the search tokens and then a list of entries
+# each entry is a hash reference
+sub find_netrc_entry {
+ my $query = shift @_;
+
+ ENTRY:
+ foreach my $entry (@_)
+ {
+ my $entry_text = join ', ', map { "$_=$entry->{$_}" } keys %$entry;
+ foreach my $check (sort keys %$query) {
+ if (defined $query->{$check}) {
+ log_debug("compare %s [%s] to [%s] (entry: %s)",
+ $check,
+ $entry->{$check},
+ $query->{$check},
+ $entry_text);
+ unless ($query->{$check} eq $entry->{$check}) {
+ next ENTRY;
+ }
+ } else {
+ log_debug("OK: any value satisfies check $check");
+ }
+ }
+
+ return $entry;
+ }
+
+ # nothing was found
+ return;
+}
+
+sub print_credential_data {
+ my $entry = shift @_;
+ my $query = shift @_;
+
+ log_debug("entry has passed all the search checks");
+ TOKEN:
+ foreach my $git_token (sort keys %$entry) {
+ log_debug("looking for useful token $git_token");
+ # don't print unknown (to the credential helper protocol) tokens
+ next TOKEN unless exists $query->{$git_token};
+
+ # don't print things asked in the query (the entry matches them)
+ next TOKEN if defined $query->{$git_token};
+
+ log_debug("FOUND: $git_token=$entry->{$git_token}");
+ printf "%s=%s\n", $git_token, $entry->{$git_token};
+ }
+}
+sub log_verbose {
+ return unless $options{verbose};
+ printf STDERR @_;
+ printf STDERR "\n";
+}
+
+sub log_debug {
+ return unless $options{debug};
+ printf STDERR @_;
+ printf STDERR "\n";
+}
diff --git a/contrib/credential/netrc/test.netrc b/contrib/credential/netrc/test.netrc
new file mode 100644
index 0000000..ba119a9
--- /dev/null
+++ b/contrib/credential/netrc/test.netrc
@@ -0,0 +1,13 @@
+machine imap login tzz@lifelogs.com port imaps password letmeknow
+machine imap login bob port imaps password bobwillknow
+
+# comment test
+
+machine imap2 login tzz port 1099 password tzzknow
+machine imap2 login bob password bobwillknow
+
+# another command
+
+machine github.com
+ multilinetoken anothervalue
+ login carol password carolknows
diff --git a/contrib/credential/netrc/test.pl b/contrib/credential/netrc/test.pl
new file mode 100755
index 0000000..169b646
--- /dev/null
+++ b/contrib/credential/netrc/test.pl
@@ -0,0 +1,106 @@
+#!/usr/bin/perl
+
+use warnings;
+use strict;
+use Test;
+use IPC::Open2;
+
+BEGIN { plan tests => 15 }
+
+my @global_credential_args = @ARGV;
+my $netrc = './test.netrc';
+print "# Testing insecure file, nothing should be found\n";
+chmod 0644, $netrc;
+my $cred = run_credential(['-f', $netrc, 'get'],
+ { host => 'github.com' });
+
+ok(scalar keys %$cred, 0, "Got 0 keys from insecure file");
+
+print "# Testing missing file, nothing should be found\n";
+chmod 0644, $netrc;
+$cred = run_credential(['-f', '///nosuchfile///', 'get'],
+ { host => 'github.com' });
+
+ok(scalar keys %$cred, 0, "Got 0 keys from missing file");
+
+chmod 0600, $netrc;
+
+print "# Testing with invalid data\n";
+$cred = run_credential(['-f', $netrc, 'get'],
+ "bad data");
+ok(scalar keys %$cred, 4, "Got first found keys with bad data");
+
+print "# Testing netrc file for a missing corovamilkbar entry\n";
+$cred = run_credential(['-f', $netrc, 'get'],
+ { host => 'corovamilkbar' });
+
+ok(scalar keys %$cred, 0, "Got no corovamilkbar keys");
+
+print "# Testing netrc file for a github.com entry\n";
+$cred = run_credential(['-f', $netrc, 'get'],
+ { host => 'github.com' });
+
+ok(scalar keys %$cred, 2, "Got 2 Github keys");
+
+ok($cred->{password}, 'carolknows', "Got correct Github password");
+ok($cred->{username}, 'carol', "Got correct Github username");
+
+print "# Testing netrc file for a username-specific entry\n";
+$cred = run_credential(['-f', $netrc, 'get'],
+ { host => 'imap', username => 'bob' });
+
+ok(scalar keys %$cred, 2, "Got 2 username-specific keys");
+
+ok($cred->{password}, 'bobwillknow', "Got correct user-specific password");
+ok($cred->{protocol}, 'imaps', "Got correct user-specific protocol");
+
+print "# Testing netrc file for a host:port-specific entry\n";
+$cred = run_credential(['-f', $netrc, 'get'],
+ { host => 'imap2:1099' });
+
+ok(scalar keys %$cred, 2, "Got 2 host:port-specific keys");
+
+ok($cred->{password}, 'tzzknow', "Got correct host:port-specific password");
+ok($cred->{username}, 'tzz', "Got correct host:port-specific username");
+
+print "# Testing netrc file that 'host:port kills host' entry\n";
+$cred = run_credential(['-f', $netrc, 'get'],
+ { host => 'imap2' });
+
+ok(scalar keys %$cred, 2, "Got 2 'host:port kills host' keys");
+
+ok($cred->{password}, 'bobwillknow', "Got correct 'host:port kills host' password");
+ok($cred->{username}, 'bob', "Got correct 'host:port kills host' username");
+
+sub run_credential
+{
+ my $args = shift @_;
+ my $data = shift @_;
+ my $pid = open2(my $chld_out, my $chld_in,
+ './git-credential-netrc', @global_credential_args,
+ @$args);
+
+ die "Couldn't open pipe to netrc credential helper: $!" unless $pid;
+
+ if (ref $data eq 'HASH')
+ {
+ print $chld_in "$_=$data->{$_}\n" foreach sort keys %$data;
+ }
+ else
+ {
+ print $chld_in "$data\n";
+ }
+
+ close $chld_in;
+ my %ret;
+
+ while (<$chld_out>)
+ {
+ chomp;
+ next unless m/^([^=]+)=(.+)/;
+
+ $ret{$1} = $2;
+ }
+
+ return \%ret;
+}
--
1.7.9.rc2
^ permalink raw reply related
* Re: Certificate validation vulnerability in Git
From: Zubin Mithra @ 2013-02-25 15:42 UTC (permalink / raw)
To: Jeff King; +Cc: git, Dhanesh K.
In-Reply-To: <20130225031648.GA31988@sigill.intra.peff.net>
On Mon, Feb 25, 2013 at 8:46 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Feb 24, 2013 at 11:01:50PM +0530, Zubin Mithra wrote:
>
>> 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.
>
> I'm not sure what you mean. We use SSL_CTX_set_verify to turn on peer
> certificate verification, which will cause SSL_connect to return
> failure if the certificate signature cannot be traced back to a CA cert
> from our local store.
>
> Is there some case where this does not happen properly? If so, can you
> give an example? The paper you referenced says only that there are some
> special cases where SSL_connect does not notice the error, but then
> gives an example where the application does not turn on SSL_VERIFY_PEER.
> But git does. Are there are other cases that SSL_VERIFY_PEER does not
> handle?
Indeed -- it appears that I was mistaken. I had a quick look at the
openssl source code and it does seem that SSL_VERIFY_PEER is
equivalent to SSL_get_verify_result.
Thank you for your time!
- Zubin
>
> There is a _different_ problem not handled by the code you show above,
> which is that SSL_connect does not verify that the hostname we connected
> to matches the signed certificate. But that was fixed already by b62fb07
> (imap-send: the subject of SSL certificate must match the host,
> 2013-02-15), which is in git v1.8.1.4.
>
> -Peff
^ permalink raw reply
* Re: [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Jeff King @ 2013-02-25 15:19 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Thomas Haller, Git List
In-Reply-To: <512B22DE.9070603@viscovery.net>
On Mon, Feb 25, 2013 at 09:37:50AM +0100, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> iconv on Windows does not know the encoding name "utf8", and does not
> re-encode log messages when this name is given. Request "UTF-8" encoding.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> I'm not sure whether I'm right to say that "UTF-8" is the correct
> spelling. Anyway, 'iconv -l' on my old Linux box lists "UTF8", but on
> Windows it does not.
UTF-8 is correct according to:
https://en.wikipedia.org/wiki/Utf8#Official_name_and_variants
> A more correct fix would probably be to use is_encoding_utf8() in more
> places, but it's outside my time budget look after it.
Yeah, I wonder if this is a symptom of a deeper issue, which is that
utf-8 has many synonyms, and we would prefer to canonicalize the
encoding name before generating an object to avoid inconsistencies (of
course we cannot do so for every imaginable encoding, but utf-8 is a
pretty obvious one we handle already). We _should_ be generating commits
with no encoding header at all for utf-8, though.
And indeed, it looks like that is the case. commit_tree_extended has:
/* Not having i18n.commitencoding is the same as having utf-8 */
encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
[...]
if (!encoding_is_utf8)
strbuf_addf(&buffer, "encoding %s\n", git_commit_encoding);
which makes me think that this first hunk...
> diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
> index 52a7472..b1956e2 100755
> --- a/t/t4210-log-i18n.sh
> +++ b/t/t4210-log-i18n.sh
> @@ -15,7 +15,7 @@ test_expect_success 'create commits in different encodings' '
> t${utf8_e}st
> EOF
> git add msg &&
> - git -c i18n.commitencoding=utf8 commit -F msg &&
> + git -c i18n.commitencoding=UTF-8 commit -F msg &&
> cat >msg <<-EOF &&
> latin1
...should be a no-op; the utf8 there should never be seen by anybody but
git. Can you confirm that is the case?
> @@ -30,7 +30,7 @@ test_expect_success 'log --grep searches in log output encoding (utf8)' '
> latin1
> utf8
> EOF
> - git log --encoding=utf8 --format=%s --grep=$utf8_e >actual &&
> + git log --encoding=UTF-8 --format=%s --grep=$utf8_e >actual &&
> test_cmp expect actual
> '
This one will feed it to iconv, though, because the latin1 commit will
need to be re-encoded. I think the simplest thing would just be:
diff --git a/utf8.c b/utf8.c
index 1087870..8d42b50 100644
--- a/utf8.c
+++ b/utf8.c
@@ -507,6 +507,17 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
if (!in_encoding)
return NULL;
+
+ /*
+ * Some platforms do not have the variously spelled variants of
+ * UTF-8, so let us feed iconv the most official spelling, which
+ * should hopefully be accepted everywhere.
+ */
+ if (is_encoding_utf8(in_encoding))
+ in_encoding = "UTF-8";
+ if (is_encoding_utf8(out_encoding))
+ out_encoding = "UTF-8";
+
conv = iconv_open(out_encoding, in_encoding);
if (conv == (iconv_t) -1)
return NULL;
Does that fix the tests for you? It's a larger change, but I think it
makes git friendlier all around for people on Windows.
-Peff
^ permalink raw reply related
* Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: TJ @ 2013-02-25 14:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vliac2898.fsf@alter.siamese.dyndns.org>
On 25/02/13 06:54, Junio C Hamano wrote:>>> Besides, you would want to differentiate the two kinds of 755 anyway
>>> (I'd prefer INSTALL_PROGRAM to use -m 555 personally, for example).
>>
>> Yes, I think I lost that one in the mists of sed-land when making the changes :)
>>
>> I'll revise the patch based on received comments and post the revision tomorrow.
>
> Did anything come out of this discussion?
Yes - but then I got lost in other projects and forgot about it! I'll revisit it this week and post the latest revision.
^ permalink raw reply
* [PATCH] diff-lib: drop return value from do_diff_cache()
From: Nguyễn Thái Ngọc Duy @ 2013-02-25 14:00 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Since 204ce97 (Also use unpack_trees() in do_diff_cache() -
2008-01-20), do_diff_cache() always returns zero. It does not make
sense to check its return value any more.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I don't know the history behind this function. But it feels not right
to do exit(128) in do_diff_cache (since 203a2fe (Allow callers of
unpack_trees() to handle failure - 2008-02-07) and limit the caller's
control here.
builtin/reset.c | 3 +--
diff-lib.c | 3 +--
diff.h | 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 6032131..843d337 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -140,8 +140,7 @@ static int read_from_tree(const char **pathspec, unsigned char *tree_sha1)
opt.format_callback = update_index_from_diff;
read_cache();
- if (do_diff_cache(tree_sha1, &opt))
- return 1;
+ do_diff_cache(tree_sha1, &opt);
diffcore_std(&opt);
diff_flush(&opt);
diff_tree_release_paths(&opt);
diff --git a/diff-lib.c b/diff-lib.c
index f35de0f..5a5fc94 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -495,7 +495,7 @@ int run_diff_index(struct rev_info *revs, int cached)
return 0;
}
-int do_diff_cache(const unsigned char *tree_sha1, struct diff_options *opt)
+void do_diff_cache(const unsigned char *tree_sha1, struct diff_options *opt)
{
struct rev_info revs;
@@ -505,7 +505,6 @@ int do_diff_cache(const unsigned char *tree_sha1, struct diff_options *opt)
if (diff_cache(&revs, tree_sha1, NULL, 1))
exit(128);
- return 0;
}
int index_differs_from(const char *def, int diff_flags)
diff --git a/diff.h b/diff.h
index 78b4091..aaa9a4e 100644
--- a/diff.h
+++ b/diff.h
@@ -319,7 +319,7 @@ extern const char *diff_unique_abbrev(const unsigned char *, int);
extern int run_diff_files(struct rev_info *revs, unsigned int option);
extern int run_diff_index(struct rev_info *revs, int cached);
-extern int do_diff_cache(const unsigned char *, struct diff_options *);
+extern void do_diff_cache(const unsigned char *, struct diff_options *);
extern int diff_flush_patch_id(struct diff_options *, unsigned char *);
extern int diff_result_code(struct diff_options *, int);
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* Re: Git 1.8.2 l10n round 3
From: Jiang Xin @ 2013-02-25 13:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Tran Ngoc Quan, Peter Krefting, Ralf Thielow
In-Reply-To: <CANYiYbHF1MAEcbhhf+PfawTzTxC06LFuZuccyeQUmtf8xXE8ig@mail.gmail.com>
Hi, Junio
The following changes since commit 20a599e2c18dd5b491257d7f8aeb2d2f02221595:
Merge branch 'jc/mention-tracking-for-pull-default' (2013-02-18
16:05:03 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to c527acebc2071975dffbccf33f4a1c8adfc6f45f:
l10n: vi.po: Updated 5 new messages (2009t0f0u) (2013-02-20 07:17:58 +0700)
----------------------------------------------------------------
Jiang Xin (2):
l10n: git.pot: v1.8.2 round 3 (5 new)
l10n: zh_CN.po: translate 5 new messages
Peter Krefting (2):
l10n: Update Swedish translation (2004t0f0u)
l10n: Update Swedish translation (2009t0f0u)
Tran Ngoc Quan (1):
l10n: vi.po: Updated 5 new messages (2009t0f0u)
po/git.pot | 225 +++++-----
po/sv.po | 1434 +++++++++++++++++++++++++++++++++--------------------------
po/vi.po | 255 ++++++-----
po/zh_CN.po | 234 +++++-----
4 files changed, 1200 insertions(+), 948 deletions(-)
--
Jiang Xin
^ permalink raw reply
* Re: [RFC v2] git-multimail: a replacement for post-receive-email
From: Michael Haggerty @ 2013-02-25 10:50 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: <vpqd2vok9bv.fsf@grenoble-inp.fr>
On 02/25/2013 10:54 AM, Matthieu Moy wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> 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.)
>
> Works for me. One minor knit: you've included 10-characters sha1s (this
> comes from
>
> self.short = read_output(['git', 'rev-parse', '--short=10', sha1])
>
> ), I'd find it better with shorter sha1s. In the case of branch update,
> if the branch name is a bit long, it could be nice to save a few
> characters.
>
> Why not just say "git rev-parse --short", without argument? This way,
> the default is used, ie. AFAICT it uses 7 characters by default, but
> will use more if needed to keep the unicity.
I did this intentionally because the SHA1s appear in columns within the
refchange emails, and having varying-length SHA1s would cause subsequent
columns to be misaligned. I figured that a length of 10, aside from
being a number that I can still count on my fingers, would be long
enough that it would rarely have to be extended.
I guess I will change the code to use $(git rev-parse --short) (i.e.,
shorter SHA1s) but reserving 10 columns in tables for them (which can be
done via Python string formatting in the templates). That should give
the best of both worlds.
Thanks for the feedback!
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Florian Achleitner @ 2013-02-25 9:12 UTC (permalink / raw)
To: git
Cc: Jeff King, Thomas Rast, Shawn Pearce, Jakub Narebski,
Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, Ramkumar Ramachandra,
Jens Lehmann, Nguyen Thai Ngoc Duy, David Barr
In-Reply-To: <20130218174239.GB22832@sigill.intra.peff.net>
[corrected David Barr's address]
On Monday 18 February 2013 12:42:39 Jeff King wrote:
> And I do not want to blame the students here (some of whom are on the cc
> list ). They are certainly under no obligation to stick around after
> GSoC ends, and I know they have many demands on their time. But I am
> also thinking about what Git wants to get out of GSoC (and to my mind,
> the most important thing is contributors).
Just a little comment from another student:
Last year i worked on the 'remote helper for svn'. My official mentor was David
Barr, but I had most interaction with Jonathan Nieder.
>From my point of view I wouldn't say the project was a fail. It was harder
than I originally thought, yes. That happens.
But we have a remote helper in master now, although its far from complete and
it's development is quite stalled. (remote-testsvn)
About sticking around:
As you can see I read the list (I was not on CC), but not very regularly, I
admit. Anyways, I'd respond to mails in CC or on IRC.
During the summer I believe I learned git's development process quite well. I
rerolled my main patch series 8 times until 19th of September, which is well
beyond GSOC deadline. I tried to get it finished before concentrating on my
studies again.
If I would now continue to contribute, it would be a completely new topic
(like branch mapping) and take a lot of time that I don't have during the
year, where I have to push my studies forward.
For a student one aspect of GSOC is also quite important: It is a cool and
demanding summer job during the holidays, but it has to ramp down when the new
semester starts.
Anyways I think GSOC is a great idea and I enjoyed contributing to git a lot,
would immediatly do it again. Keep it goin'!
Thanks.
Florian
^ permalink raw reply
* Re: [RFC v2] git-multimail: a replacement for post-receive-email
From: Matthieu Moy @ 2013-02-25 10:01 UTC (permalink / raw)
To: Michael Haggerty
Cc: git discussion list, Andy Parkins, Sitaram Chamarty,
Junio C Hamano, Marc Branchaud,
Ævar Arnfjörð Bjarmason, Chris Hiestand
In-Reply-To: <5129AAEB.5080007@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> 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
Yes, that would be even better.
> 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.
I'd rather have a simple rule here like "last one wins" or so. Saying
that foo-bar-* is a better match than foo-* may be easy, but you can
hardly avoid having corner-cases like foo-*-boz vs foo-bar-* when
matching foo-bar-boz.
> 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 = ""
Yes, I thougth about that, but it is not only "more general", but also
"less conveinient":
[multimailhook]
mailingList = some@example.com
refchangelist = other@example.com
[multimailhook "refs/heads/user/$USER/*"]
mailingList = ""
# Oops, forgot to override refchangelist, the mail will still
# be sent.
So skipRefs and onlyRefs would still make sense IMHO.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC v2] git-multimail: a replacement for post-receive-email
From: Matthieu Moy @ 2013-02-25 9:54 UTC (permalink / raw)
To: Michael Haggerty
Cc: git discussion list, Andy Parkins, Sitaram Chamarty,
Junio C Hamano, Marc Branchaud,
Ævar Arnfjörð Bjarmason, Chris Hiestand
In-Reply-To: <5129A5B3.7020807@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> 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.)
Works for me. One minor knit: you've included 10-characters sha1s (this
comes from
self.short = read_output(['git', 'rev-parse', '--short=10', sha1])
), I'd find it better with shorter sha1s. In the case of branch update,
if the branch name is a bit long, it could be nice to save a few
characters.
Why not just say "git rev-parse --short", without argument? This way,
the default is used, ie. AFAICT it uses 7 characters by default, but
will use more if needed to keep the unicity.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
From: Mike Gorchak @ 2013-02-25 8:39 UTC (permalink / raw)
To: git
Add pthread support in QNX. Do not declare NO_ macros if they can be
autodetected.
From: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
---
config.mak.uname | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 8743a6d..d33aac6 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -527,14 +527,22 @@ 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/
+ # strlcpy 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
+ NO_STRLCPY = YesPlease
+ NO_ICONV = YesPlease
+ NO_GETTEXT = YesPlease
+ endif
endif
--
1.8.2-rc0
^ permalink raw reply related
* [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Johannes Sixt @ 2013-02-25 8:37 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Thomas Haller, Git List
In-Reply-To: <20130211205958.GA32740@sigill.intra.peff.net>
From: Johannes Sixt <j6t@kdbg.org>
iconv on Windows does not know the encoding name "utf8", and does not
re-encode log messages when this name is given. Request "UTF-8" encoding.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I'm not sure whether I'm right to say that "UTF-8" is the correct
spelling. Anyway, 'iconv -l' on my old Linux box lists "UTF8", but on
Windows it does not.
A more correct fix would probably be to use is_encoding_utf8() in more
places, but it's outside my time budget look after it.
-- Hannes
t/t4210-log-i18n.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
index 52a7472..b1956e2 100755
--- a/t/t4210-log-i18n.sh
+++ b/t/t4210-log-i18n.sh
@@ -15,7 +15,7 @@ test_expect_success 'create commits in different encodings' '
t${utf8_e}st
EOF
git add msg &&
- git -c i18n.commitencoding=utf8 commit -F msg &&
+ git -c i18n.commitencoding=UTF-8 commit -F msg &&
cat >msg <<-EOF &&
latin1
@@ -30,7 +30,7 @@ test_expect_success 'log --grep searches in log output encoding (utf8)' '
latin1
utf8
EOF
- git log --encoding=utf8 --format=%s --grep=$utf8_e >actual &&
+ git log --encoding=UTF-8 --format=%s --grep=$utf8_e >actual &&
test_cmp expect actual
'
@@ -45,7 +45,7 @@ test_expect_success 'log --grep searches in log output encoding (latin1)' '
test_expect_success 'log --grep does not find non-reencoded values (utf8)' '
>expect &&
- git log --encoding=utf8 --format=%s --grep=$latin1_e >actual &&
+ git log --encoding=UTF-8 --format=%s --grep=$latin1_e >actual &&
test_cmp expect actual
'
--
"Atomic objects are neither active nor radioactive." --
Programming Languages -- C++, Final Committee Draft (Doc.N3092)
^ permalink raw reply related
* [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Mike Gorchak @ 2013-02-25 8:36 UTC (permalink / raw)
To: git
Fix is_date() function failings in detection of correct date in case
if time was not properly initialized.
From: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
---
date.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/date.c b/date.c
index 57331ed..ec758f4 100644
--- a/date.c
+++ b/date.c
@@ -357,6 +357,7 @@ static int is_date(int year, int month, int day,
struct tm *now_tm, time_t now,
if (month > 0 && month < 13 && day > 0 && day < 32) {
struct tm check = *tm;
struct tm *r = (now_tm ? &check : tm);
+ struct tm fixed_r;
time_t specified;
r->tm_mon = month - 1;
@@ -377,7 +378,16 @@ static int is_date(int year, int month, int day,
struct tm *now_tm, time_t now,
if (!now_tm)
return 1;
- specified = tm_to_time_t(r);
+ /* Fix tm structure in case if time was not initialized */
+ fixed_r = *r;
+ if (fixed_r.tm_hour==-1)
+ fixed_r.tm_hour=0;
+ if (fixed_r.tm_min==-1)
+ fixed_r.tm_min=0;
+ if (fixed_r.tm_sec==-1)
+ fixed_r.tm_sec=0;
+
+ specified = tm_to_time_t(&fixed_r);
/* Be it commit time or author time, it does not make
* sense to specify timestamp way into the future. Make
--
1.8.2-rc0
^ permalink raw reply related
* Re: [PATCH] Improve QNX support in GIT
From: Mike Gorchak @ 2013-02-25 8:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtxp0zwyn.fsf@alter.siamese.dyndns.org>
Hi Junio,
> Swapping the order between CFLAGS and BASIC_CFLAGS in ALL_CFLAGS may
> be a good change for that reason as well.
This sounds very reasonable.
> In any case, I won't take a patch to rename source files left and
> right only to work around name collisions with random system header
> files we do not even use ourselves, unless/until I know we have
> tried all the other saner approaches first. That's a workaround,
> not a solution.
Ok, no problem, I will create another patch which alter CFLAGS order.
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Johannes Sixt @ 2013-02-25 8:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: GIT Mailing-list, Ramsay Jones, Erik Faye-Lund, Jonathan Nieder,
Johannes Schindelin
In-Reply-To: <7vehg4288w.fsf@alter.siamese.dyndns.org>
Am 2/25/2013 7:54, schrieb Junio C Hamano:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> As I mentioned recently, while discussing a cygwin specific patch
>> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
>> MSVC build is broken for me.
>>
>> The first 4 patches fix the MSVC build for me. The final patch is
>> not really related to fixing the build, but it removed some make
>> warnings which were quite irritating ...
>>
>> Note that I used the Makefile, with the Visual C++ 2008 command
>> line compiler on Windows XP (SP3), to build a vanilla git on MinGW.
>> I'm not subscribed to the msysgit mailing list, nor do I follow the
>> msysgit fork of git, so these patches may conflict with commits in
>> their repository.
>
> Did anything further happen to this topic in the Windows land?
I successfully built with MSVC with these patches (but I am not using the
result anywhere nor did I attempt to run the test suite).
More importantly, I'm using git on Windows ("MinGW flavor") with these
patches in production, so there are no obvious regressions.
Feel free to add my
Tested-by: Johannes Sixt <j6t@kdbg.org>
but if you don't have the patches around, I can resend them.
-- Hannes
^ 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