Re: [PATCH 0/5] Fix msvc build
Am 2/25/2013 7:54, schrieb Junio C Hamano: Ramsay Jones ram...@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 j...@kdbg.org but if you don't have the patches around, I can resend them. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve QNX support in GIT
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Fix date checking in case if time was not initialized.
Fix is_date() function failings in detection of correct date in case
if time was not properly initialized.
From: Mike Gorchak mike.gorchak@gmail.com
Signed-off-by: Mike Gorchak mike.gorchak@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
From: Johannes Sixt j...@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 j...@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)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected. From: Mike Gorchak mike.gorchak@gmail.com Signed-off-by: Mike Gorchak mike.gorchak@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: On 02/20/2013 01:28 PM, Matthieu Moy wrote: Michael Haggerty mhag...@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/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@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 = q...@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 = s...@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 = s...@example.com refchangelist = ot...@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/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
[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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On 02/25/2013 10:54 AM, Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: On 02/20/2013 01:28 PM, Matthieu Moy wrote: Michael Haggerty mhag...@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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git 1.8.2 l10n round 3
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] diff-lib: drop return value from do_diff_cache()
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 pclo...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
On Mon, Feb 25, 2013 at 09:37:50AM +0100, Johannes Sixt wrote:
From: Johannes Sixt j...@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 j...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Certificate validation vulnerability in Git
On Mon, Feb 25, 2013 at 8:46 AM, Jeff King p...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7] Add contrib/credentials/netrc with GPG support
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 t...@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 000..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 000..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
Re: [PATCHv6] Add contrib/credentials/netrc with GPG support
On Fri, 8 Feb 2013 01:18:55 -0500 Jeff King p...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Merging submodules - best merge-base
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible regression in ref advertisement
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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/WIP PATCH 1/3] teach config parsing to read from strbuf
Hi Junio,
On Sun, Feb 24, 2013 at 09:54:43PM -0800, Junio C Hamano wrote:
Heiko Voigt hvo...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
Mike Gorchak mike.gorchak@gmail.com writes: Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected. From: Mike Gorchak mike.gorchak@gmail.com Signed-off-by: Mike Gorchak mike.gorchak@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.em...@address.xz Subject: [PATCH] title of the patch ... your e-mail body ... From: A U Thor real.aut...@address.xz The first line of the commit log message and the second line of it. Signed-off-by: A U Thor real.aut...@address.xz Signed-off-by: Mike Gorchak your.em...@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@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@gmail.com Signed-off-by: Junio C Hamano gits...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Florian Achleitner florian.achleitner2.6...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git 1.8.2 l10n round 3
Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git 1.8.2 l10n round 3
Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crashes while trying to show tag objects with bad timestamps
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
Mike Gorchak mike.gorchak@gmail.com writes:
Fix is_date() function failings in detection of correct date in case
if time was not properly initialized.
Please explain why this patch is needed and what problem this patch
is trying to fix (if any) a bit better in the proposed log message.
For example, on what input do we call this function with partially
filled *r, and is that an error in the code, or is it an indication
that the input has only been consumed partially?
tm_to_time_t() is designed to reject underspecified date input, and
its callers call is_date() starting with partially filled tm on
purpose to reject such input. Doesn't fixing partially filled tm
before calling tm_to_time_t() inside is_date() break that logic?
From: Mike Gorchak mike.gorchak@gmail.com
Signed-off-by: Mike Gorchak mike.gorchak@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crashes while trying to show tag objects with bad timestamps
On Fri, Feb 22, 2013 at 03:20:10PM -0800, Junio C Hamano wrote: As pp_user_info() is called from very few places, I do not think it is unreasonable to add an output parameter (i.e. unsigned *) to let the caller know that we made a best guess given malformed input and handle the error in the caller. The make_cover_letter() caller may look like: pp_user_info(pp, NULL, sb, committer, encoding, errors); if (errors PP_CORRUPT_DATE) warning(unparsable datestamp in '%s', committer); although it is unlikely to see this error in practice, given that committer is coming from git_committer_info(0) and would have the current timestamp. Sadly that is not quite enough for the object-parsing cases (which are the ones we _really_ want to add context to, because they are buried inside other pp_* calls. Probably adding an object context field (or an error return) to the pretty-print context would make sense. But I don't relish the thought of annotating each pretty-print caller. I think we're OK to be silent and just react in an appropriate way; having looked over the other callers of split_ident_line, we already do so in some places. See my patch 1 below for details. Once fsck is taught to note this, then the warning is a lot less important (my patch 3 below). The whole cat-file -p is a historical wart, aka poor-man's show. I do not even consider it a part of the plumbing. It is a fair game for Porcelainisque improvement ;-) Good, that's how I feel, too. See my patch 4. :) Here are the patches I'd like to do: [1/4]: handle malformed dates in ident lines [2/4]: skip_prefix: return a non-const pointer [3/4]: fsck: check tagger lines [4/4]: cat-file: print tags raw for cat-file -p The first one is solid, and should probably go to maint and/or the -rc track, as it fixes a segfault on bogus input. It's hopefully a no-brainer, as the existing behavior is obviously unacceptable. We may change our mind later about exactly what to print for such bogus input, but whatever we print in such a case is just trying to be nice to the user, and anybody who depends on our particular handling of malformed objects is crazy. The rest can wait, as they are about improving output when fed bogus input, or tightening fsck. Moreover, they have some problems which make them not suitable for applying yet. I'll give details in each patch. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in ref advertisement
Carlos Martín Nieto c...@elego.de writes:
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.
Interesting. git ls-remote . | grep 1.8.0- for maint, master,
next and pu produce identical results for me, all showing peeled
ones correctly.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Add getpagesize() function detection to configure script
Add detection of getpagesize() function in libc. Declare empty NO_GETPAGESIZE macro in case if getpagesize() exists and NO_GETPAGESIZE=YesPlease if no. Signed-off-by: Mike Gorchak mike.gorchak@gmail.com --- configure.ac | 5 + 1 file changed, 5 insertions(+) diff --git a/configure.ac b/configure.ac index d0e82c1..3963429 100644 --- a/configure.ac +++ b/configure.ac @@ -993,6 +993,11 @@ GIT_CHECK_FUNC(initgroups, [NO_INITGROUPS=YesPlease]) GIT_CONF_SUBST([NO_INITGROUPS]) # +# Define NO_GETPAGESIZE if you don't have getpagesize in the C library. +GIT_CHECK_FUNC(getpagesize, +[NO_GETPAGESIZE=], +[NO_GETPAGESIZE=YesPlease]) +GIT_CONF_SUBST([NO_GETPAGESIZE]) # # Define NO_MMAP if you want to avoid mmap. # -- 1.8.2-rc0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] handle malformed dates in ident lines
The split_ident_line function is used by many code paths to
find the name, mail, and date fields of an identity line.
It will return failure when the output is completely
unparseable, but may return success (along with a NULL date
field) if the date is empty or malformed. Callers that care
about the date need to handle this situation explicitly, or
they will end up segfaulting as they feed the NULL date to
strtoul or similar.
There are basically three options:
1. Reject the ident line entirely (i.e., do the same thing
we would do if the name or email were missing). We
already use this strategy in git-commit's
determine_author_info.
2. Process the name and email, but refuse to work on any
date portions. format_person_part does this, and a
commit with such an ident would yield an empty string
for --format=%at.
3. Proceed with some obviously bogus sentinel value for
the time (e.g., the start of the epoch).
Only two of the existing callers read the date but do not
handle this case at all: pp_user_info and git-blame's
get_ac_line. This patch modifies both to use option (3). The
hope is that this is friendly (we still produce some output)
but the epoch start date will give the user a clue that the
date is not valid.
Signed-off-by: Jeff King p...@peff.net
---
Having written that, I feel like the case for doing (3) is somewhat
flimsy. I don't know that it really matters that much either way, but
I'd be just as happy to do any of the others.
In fact, I really wonder if split_ident_line shouldn't simply be
returning error in such a case. The comment above it claims that reflogs
do not have such a timestamp, but they do. I suspect it is a weird
interaction of the reflog walker on format_person_part, but I haven't
checked. I wonder if we can simply fix the reflog code to pass a string
with the date in the usual way (since we _should_ have it at some
point). If not, then we can perhaps make things safer for other callers
with a wrapper like:
/* safe default version */
int split_ident_line(...)
{
/* calls less safe but more flexible version; i.e., the
* existing one */
if (split_ident_line_date_optional(...) 0)
return -1;
if (!ident.date_begin)
return -1;
return 0;
}
builtin/blame.c | 13 +
pretty.c| 15 ---
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 86100e9..2edff25 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1375,10 +1375,15 @@ static void get_ac_line(const char *inbuf, const char
*what,
maillen = ident.mail_end - ident.mail_begin;
mailbuf = ident.mail_begin;
- *time = strtoul(ident.date_begin, NULL, 10);
-
- len = ident.tz_end - ident.tz_begin;
- strbuf_add(tz, ident.tz_begin, len);
+ if (ident.date_begin) {
+ *time = strtoul(ident.date_begin, NULL, 10);
+ len = ident.tz_end - ident.tz_begin;
+ strbuf_add(tz, ident.tz_begin, len);
+ }
+ else {
+ *time = 0;
+ strbuf_addstr(tz, -);
+ }
/*
* Now, convert both name and e-mail using mailmap
diff --git a/pretty.c b/pretty.c
index eae57ad..4b19908 100644
--- a/pretty.c
+++ b/pretty.c
@@ -391,7 +391,7 @@ void pp_user_info(const struct pretty_print_context *pp,
struct strbuf mail;
struct ident_split ident;
int linelen;
- char *line_end, *date;
+ char *line_end;
const char *mailbuf, *namebuf;
size_t namelen, maillen;
int max_length = 78; /* per rfc2822 */
@@ -428,8 +428,17 @@ void pp_user_info(const struct pretty_print_context *pp,
strbuf_add(name, namebuf, namelen);
namelen = name.len + mail.len + 3; /* ' ' + '' + '' */
- time = strtoul(ident.date_begin, date, 10);
- tz = strtol(date, NULL, 10);
+
+ if (ident.date_begin) {
+ char *date;
+ time = strtoul(ident.date_begin, date, 10);
+ tz = strtol(date, NULL, 10);
+ }
+ else {
+ /* ident has missing or malformed date */
+ time = 0;
+ tz = 0;
+ }
if (pp-fmt == CMIT_FMT_EMAIL) {
strbuf_addstr(sb, From: );
--
1.8.1.4.4.g265d2fa
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 2/4] skip_prefix: return a non-const pointer
The const rules in C are such that one cannot write a
function that takes a const or non-const pointer and returns
a pointer that matches the input in const-ness. Instead, you
must take a const pointer (because you are promising not to
modify it), and then either return a const pointer (which is
safer, but annoying to callers who originally had a
non-const pointer) or a non-const pointer (less safe, as you
may accidentally drop constness, but less annoying).
This is a well-known problem, and the standard string
functions like strchr take the less annoying approach.
Let's mimic them. Even though this is technically less safe,
skip_prefix tends to be used alongside standard string
manipulation functions already, so it is not really
introducing a new problem.
Signed-off-by: Jeff King p...@peff.net
---
I have mixed feelings on this. It _is_ less safe, and this is a known
bug in the C standard. Still, it seems like the more idiomatic C thing
to do.
My main motivation is to avoid a bunch of casts in the next patch.
builtin/commit.c | 2 +-
git-compat-util.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 3348aa1..bb6890b 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -895,7 +895,7 @@ static int template_untouched(struct strbuf *sb)
return 0;
stripspace(tmpl, cleanup_mode == CLEANUP_ALL);
- start = (char *)skip_prefix(sb-buf, tmpl.buf);
+ start = skip_prefix(sb-buf, tmpl.buf);
if (!start)
start = sb-buf;
strbuf_release(tmpl);
diff --git a/git-compat-util.h b/git-compat-util.h
index b7eaaa9..56c066b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -320,10 +320,10 @@ static inline const char *skip_prefix(const char *str,
const char *prefix)
extern int prefixcmp(const char *str, const char *prefix);
extern int suffixcmp(const char *str, const char *suffix);
-static inline const char *skip_prefix(const char *str, const char *prefix)
+static inline char *skip_prefix(const char *str, const char *prefix)
{
size_t len = strlen(prefix);
- return strncmp(str, prefix, len) ? NULL : str + len;
+ return strncmp(str, prefix, len) ? NULL : (char *)(str + len);
}
#if defined(NO_MMAP) || defined(USE_WIN32_MMAP)
--
1.8.1.4.4.g265d2fa
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
Fix is_date() function failings in detection of correct date in case if time was not properly initialized. Please explain why this patch is needed and what problem this patch is trying to fix (if any) a bit better in the proposed log message. For example, on what input do we call this function with partially filled *r, and is that an error in the code, or is it an indication that the input has only been consumed partially? function is_date() must not fail if time fields are not set. Currently is_date() invokes tm_to_time_t() which perform check of time fields. With these fixes t0006-date.sh test is no longer fail on these tests: check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500' check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015' check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -5:' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500' check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500' By the way following test is always fails due to absence of EST5 timezone in timezones array in date.c module. check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5 tm_to_time_t() is designed to reject underspecified date input, and its callers call is_date() starting with partially filled tm on purpose to reject such input. Doesn't fixing partially filled tm before calling tm_to_time_t() inside is_date() break that logic? According to logic is_date() have no any relations with time (hours/mins/secs). In the tests described above date is defined first, before time, so at the point when date is checked for correctness time is not defined yet. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] fsck: check tagger lines
The fsck_tag function does not check very much about tags at
all; it just makes sure that we were able to load the
pointed-to object during the parse_tag phase. This does
check some basic things (the object line is OK, and the
pointed-to object exists with the expected type).
We did not, however, check the tagger line at all; if they
exist, we should feed them to fsck_ident (and it is OK if
they do not, as early versions of git did not include them).
This patch runs through the whole tag object during
fsck_tag, similar to what we do in fsck_commit. Some of
these checks are technically redundant with just checking
that parse_tag filled in the tag-tagged field. However:
1. We have to parse through those lines anyway to get to
the tagger line, so we need to sanity check our
parsing.
2. We can give more specific errors (e.g., report a
malformed object line).
3. Previously we depended on implementation details of
parse_tag for our fsck (e.g., that it would never fill
in tagged if the types did not match). Now our
exhaustive checks are in one place, which makes it
easier to verify exactly what fsck is checking.
Signed-off-by: Jeff King p...@peff.net
---
Unfortunately, this causes t1050 to fail in an interesting way. It runs
index-pack --strict while setting GIT_DIR=nonexistent. As a result,
when we try to read the tag object from disk, we can't find it. We
don't run into the same problem verifying commits and trees, because
those objects leave the raw object data in their buffer field.
I'm tempted to call what that test is doing insane, but I wonder if
there is another corner case with running index-pack --strict as part
of an incoming push or fetch. I haven't investigated that yet.
fsck.c | 62 -
t/t1450-fsck.sh | 43 +++
2 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/fsck.c b/fsck.c
index 99c0497..20d55c4 100644
--- a/fsck.c
+++ b/fsck.c
@@ -340,15 +340,75 @@ static int fsck_tag(struct tag *tag, fsck_error
error_func)
return 0;
}
-static int fsck_tag(struct tag *tag, fsck_error error_func)
+static int fsck_tag_buffer(char *buf, struct tag *tag, fsck_error error_func)
{
struct object *tagged = tag-tagged;
+ unsigned char sha1[20];
+ char *eol;
+
+ buf = skip_prefix(buf, object );
+ if (!buf)
+ return error_func(tag-object, FSCK_ERROR, invalid format -
expected 'object' line);
+ if (get_sha1_hex(buf, sha1) || buf[40] != '\n')
+ return error_func(tag-object, FSCK_ERROR, invalid 'object'
line format - bad sha1);
+ buf += 41;
+ /*
+* We already called parse_tag, so we don't have to bother looking up
+* the sha1 again.
+*/
if (!tagged)
return error_func(tag-object, FSCK_ERROR, could not load
tagged object);
+
+ buf = skip_prefix(buf, type );
+ if (!buf)
+ return error_func(tag-object, FSCK_ERROR, invalid format -
expected 'type' line);
+ eol = strchr(buf, '\n');
+ if (!eol)
+ return error_func(tag-object, FSCK_ERROR, invalid format -
truncation at 'type' line);
+ *eol = '\0';
+ if (type_from_string(buf) != tagged-type)
+ return error_func(tag-object, FSCK_ERROR, 'type' line does
not match type of tagged object);
+ *eol = '\n';
+
+ buf = skip_prefix(eol + 1, tag );
+ if (!buf)
+ return error_func(tag-object, FSCK_ERROR, invalid format -
expected 'tag' line);
+ eol = strchr(buf, '\n');
+ if (!eol)
+ return error_func(tag-object, FSCK_ERROR, invalid format -
truncation at 'tag' line);
+
+ /*
+* A missing tagger is OK, as very old versions of git did not produce
+* such a line. But if we do have it, we should verify its contents.
+*/
+ buf = skip_prefix(eol + 1, tagger );
+ if (buf) {
+ int err = fsck_ident(buf, tag-object, error_func);
+ if (err)
+ return err;
+ }
+
return 0;
}
+static int fsck_tag(struct tag *tag, fsck_error error_func)
+{
+ char *buf;
+ unsigned long size;
+ enum object_type type;
+ int err;
+
+ buf = read_sha1_file(tag-object.sha1, type, size);
+ if (!buf)
+ return error_func(tag-object, FSCK_ERROR, could not read tag
object);
+
+ err = fsck_tag_buffer(buf, tag, error_func);
+
+ free(buf);
+ return err;
+}
+
int fsck_object(struct object *obj, int strict, fsck_error error_func)
{
if (!obj)
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index d730734..3a3bce6 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -180,6 +180,49 @@ test_expect_success 'tag pointing to something else than
its type' '
test_must_fail git fsck --tags
'
+test_expect_success 'tag
[PATCH 4/4] cat-file: print tags raw for cat-file -p
When cat-file -p prints commits, it shows them in their
raw format, since git's format is already human-readable.
For tags, however, we print the whole thing raw except for
one thing: we convert the timestamp on the tagger line into a
human-readable date.
This dates all the way back to a0f15fa (Pretty-print tagger
dates, 2006-03-01). At that time there was no way to
pretty-print a tag. These days git show does this already,
and is the normal tool for showing a pretty-printed output
(cat-file tag $tag remains the preferred method for
showing porcelain output).
Let's drop this. It makes us more consistent with cat-file's
commit pretty-printer, and it means we can drop a whole
bunch of hand-rolled tag parsing code (which happened to
behave inconsistently with the tag pretty-printing code
elsewhere).
Note that git verify-tag and git tag -v depend on
cat-file -p to show the tag. This means they will start
showing the raw timestamp. We may want to adjust them to
use the pretty-printing code from git show.
Signed-off-by: Jeff King p...@peff.net
---
I don't use git tag -v much, so I'm not sure what is sane there. But
this seems like it would be a regression for people who want to check
the human-readable date given by GPG against the date in the tag object.
I still think dropping this hand-rolled parsing is a good thing. The
most sane thing to me would be to move the parsing from git show into
the pretty-print code, then have both it and verify-tag use it.
Probably for-each-ref could stand to use it as well, as it has its own
home-grown parser.
builtin/cat-file.c | 71 -
t/t1006-cat-file.sh | 5 +---
2 files changed, 1 insertion(+), 75 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 00528dd..b195edf 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -16,73 +16,6 @@
#define BATCH 1
#define BATCH_CHECK 2
-static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned
long size)
-{
- /* the parser in tag.c is useless here. */
- const char *endp = buf + size;
- const char *cp = buf;
-
- while (cp endp) {
- char c = *cp++;
- if (c != '\n')
- continue;
- if (7 = endp - cp !memcmp(tagger , cp, 7)) {
- const char *tagger = cp;
-
- /* Found the tagger line. Copy out the contents
-* of the buffer so far.
-*/
- write_or_die(1, buf, cp - buf);
-
- /*
-* Do something intelligent, like pretty-printing
-* the date.
-*/
- while (cp endp) {
- if (*cp++ == '\n') {
- /* tagger to cp is a line
-* that has ident and time.
-*/
- const char *sp = tagger;
- char *ep;
- unsigned long date;
- long tz;
- while (sp cp *sp != '')
- sp++;
- if (sp == cp) {
- /* give up */
- write_or_die(1, tagger,
-cp - tagger);
- break;
- }
- while (sp cp
- !('0' = *sp *sp = '9'))
- sp++;
- write_or_die(1, tagger, sp - tagger);
- date = strtoul(sp, ep, 10);
- tz = strtol(ep, NULL, 10);
- sp = show_date(date, tz, 0);
- write_or_die(1, sp, strlen(sp));
- xwrite(1, \n, 1);
- break;
- }
- }
- break;
- }
- if (cp endp *cp == '\n')
- /* end of header */
- break;
- }
- /* At this point, we have copied out the header up to the end of
-* the tagger line and cp points at one past \n. It could be the
-* next header line after the tagger line, or it could be another
-* \n that marks the end of the headers. We need to copy out the
-* remainder as is.
-*/
- if (cp endp)
- write_or_die(1,
Re: [RFC] git rm -u
I must say that I'm not very interested in the feature. In my opinion, there are already many different ways to stage changes. Assuming that the feature would be needed, I would keep it under the scope of git-add, as it's the reference for staging. I would suggest something like: git add -r Stage removal of deleted files. On Mon, Feb 25, 2013 at 7:54 AM, Junio C Hamano gits...@pobox.com wrote: Eric James Michael Ritz lobbyjo...@gmail.com writes: On 01/19/2013 04:49 PM, Antoine Pelisse wrote: I think `git add -u` would be closer. It would stage removal of files, but would not stage untracked files. It would stage other type of changes though. On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky Does `git add -A` do what you want? Thank you Tomas and Antoine. Both of these commands do what I want: stage deleted files on the index. But does the idea of a `git rm -u` still sound useful since these commands also stage changes besides deleted files? Even though I am not sure how often I would use it myself, reflect only the removals in the working tree to the index, but exclude any other kind of changes might turn out to be a useful addition to the toolchest in certain cases. I however am not yet convinced that git rm -u is a good way to express the feature at the UI. git add -u is update the index with modification and removal but ignore new files because we won't know if they are garbage or assets. What the same -u option means in the context of git rm is not very clear, at least to me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
On 25.02.13 09:37, Johannes Sixt wrote:
From: Johannes Sixt j...@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 j...@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
'
Hej,
(beside that I couldn't find t4210 somewhere),
is it something like the following you are tinking of?
(Not sure if my cut-and-paste stuff applies, its's rather for review)
-- 8 --
[PATCH] iconv_open(): Use UTF-8 if UTF8 failes
When iconv_open() failes with EINVAL, it may be that UTF-8
is spelled wrong by mistake.
For example, UTF8 is used instead of UTF-8.
Some iconv implementations tolerate UTF8 or utf8.
If not, iconv_open() fails.
If is_encoding_utf8() is true change the string to the
offical string UTF-8 with uppercase letters.
Reported-By: Johannes Sixt j...@kdbg.org
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
utf8.c | 4
1 file changed, 4 insertions(+)
diff --git a/utf8.c b/utf8.c
index a4ee665..e9850d0 100644
--- a/utf8.c
+++ b/utf8.c
@@ -487,6 +487,10 @@ char *reencode_string(const char *in, const char
*out_encoding, const char *in_e
if (!in_encoding)
return NULL;
conv = iconv_open(out_encoding, in_encoding);
+ if (conv == (iconv_t) -1 errno == EINVAL) {
+ conv = iconv_open(is_encoding_utf8(out_encoding) ? UTF-8 :
out_encoding,
+
is_encoding_utf8(in_encoding) ? UTF-8 : in_encoding);
+ }
if (conv == (iconv_t) -1)
return NULL;
out = reencode_string_iconv(in, strlen(in), conv);
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Fix msvc build
Hi Hannes, On Mon, 25 Feb 2013, Johannes Sixt wrote: Am 2/25/2013 7:54, schrieb Junio C Hamano: Ramsay Jones ram...@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 j...@kdbg.org but if you don't have the patches around, I can resend them. Can you please send a pull request on GitHub? Thanks, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
Mike Gorchak mike.gorchak@gmail.com writes: Fix is_date() function failings in detection of correct date in case if time was not properly initialized. Please explain why this patch is needed and what problem this patch is trying to fix (if any) a bit better in the proposed log message. For example, on what input do we call this function with partially filled *r, and is that an error in the code, or is it an indication that the input has only been consumed partially? function is_date() must not fail if time fields are not set. Currently is_date() invokes tm_to_time_t() which perform check of time fields. With these fixes t0006-date.sh test is no longer fail on these tests: The thing that puzzles me is that nobody reported that the following fail on their platforms (and they do not fail for me on platforms I have to test in my real/virtual boxes). check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500' check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015' check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -5:' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500' check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +' check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500' So there must be something _else_ going on, and I cannot tell what that something else is from your code change nor from the log message. I'd like to see that explained. Still puzzled... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
Jeff King p...@peff.net writes: ... 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. Yeah, if this is confirmed to work OK (from eyeballing I do not see a reason why not...) I agree this is the cleanest way forward. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
Antoine Pelisse apeli...@gmail.com writes: I must say that I'm not very interested in the feature. In my opinion, there are already many different ways to stage changes. Assuming that the feature would be needed, I would keep it under the scope of git-add, as it's the reference for staging. I would suggest something like: git add -r Stage removal of deleted files. Would add -r stand for add --remove? That would be weird ... git rm really seems to be a better place for removing files from the index. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in ref advertisement
On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote:
Carlos Martín Nieto c...@elego.de writes:
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.
Interesting. git ls-remote . | grep 1.8.0- for maint, master,
next and pu produce identical results for me, all showing peeled
ones correctly.
Bisection leads me to Peff's 435c8332 (2012-10-04; upload-pack: use
peel_ref for ref advertisements) and reverting that commit brings the
-rc3^{} back.
cmn
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in ref advertisement
Carlos Martín Nieto c...@elego.de writes:
On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote:
...
Interesting. git ls-remote . | grep 1.8.0- for maint, master,
next and pu produce identical results for me, all showing peeled
ones correctly.
Bisection leads me to Peff's 435c8332 (2012-10-04; upload-pack: use
peel_ref for ref advertisements) and reverting that commit brings the
-rc3^{} back.
A shot in the dark, as I do not seem to be able to reproduce the issue
with anything that contains the commit. Perhaps your .git/packed-refs
is corrupt?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
On Mon, Feb 25, 2013 at 8:07 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Antoine Pelisse apeli...@gmail.com writes: I must say that I'm not very interested in the feature. In my opinion, there are already many different ways to stage changes. Assuming that the feature would be needed, I would keep it under the scope of git-add, as it's the reference for staging. I would suggest something like: git add -r Stage removal of deleted files. Would add -r stand for add --remove? That would be weird ... Yes (for --remove), It would not be weird if you consider the opposite of add to be reset (and not rm). git rm really seems to be a better place for removing files from the index. Then, I don't exactly understand the meaning of git-rm but being a _shortcut_ for remove and stage. Here the files are already removed, we only need to stage and the best command to stage changes is add. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.2-rc1
The first release candidate Git v1.8.2-rc1 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 44172a71a711b83b4cfaa8e41dd24d05068b0887 git-1.8.2.rc1.tar.gz fd23a6fd099bf13f897675f727a91633537eaa29 git-htmldocs-1.8.2.rc1.tar.gz f10f04741401e273ac6a8c7e54c96e1d915f6486 git-manpages-1.8.2.rc1.tar.gz Also the following public repositories all have a copy of the v1.8.2-rc1 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.2 Release Notes (draft) Backward compatibility notes In the next major release Git 2.0 (not *this* one), we will change the behavior of the git push command. When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will use the simple semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable push.default to change this. git push $there tag v1.2.3 used to allow replacing a tag v1.2.3 that already exists in the repository $there, if the rewritten tag you are pushing points at a commit that is a descendant of a commit that the old tag v1.2.3 points at. This was found to be error prone and starting with this release, any attempt to update an existing ref under refs/tags/ hierarchy will fail, without --force. When git add -u and git add -A, that does not specify what paths to add on the command line, is run from inside a subdirectory, the scope of the operation has always been limited to the subdirectory. Many users found this counter-intuitive, given that git commit -a and other commands operate on the entire tree regardless of where you are. In this release, these commands give warning in such a case and encourage the user to say git add -u/-A . instead when restricting the scope to the current directory. At Git 2.0 (not *this* one), we plan to change these commands without pathspec to operate on the entire tree, and training your fingers to type . will protect you against the future change. Updates since v1.8.1 UI, Workflows Features * Initial ports to QNX and z/OS UNIX System Services have started. * Output from the tests is coloured using green is okay, yellow is questionable, red is bad and blue is informative scheme. * Mention of GIT/Git/git in the documentation have been updated to be more uniform and consistent. The name of the system and the concept it embodies is Git; the command the users type is git. All-caps GIT was merely a way to imitate Git typeset in small caps in our ASCII text only documentation and to be avoided. * The completion script (in contrib/completion) used to let the default completer to suggest pathnames, which gave too many irrelevant choices (e.g. git add would not want to add an unmodified path). It learnt to use a more git-aware logic to enumerate only relevant ones. * In bare repositories, git shortlog and other commands now read mailmap files from the tip of the history, to help running these tools in server settings. * Color specifiers, e.g. %C(blue)Hello%C(reset), used in the --format= option of git log and friends can be disabled when the output is not sent to a terminal by prefixing them with auto,, e.g. %C(auto,blue)Hello%C(auto,reset). * Scripts can ask Git that wildcard patterns in pathspecs they give do not have any significance, i.e. take them as literal strings. * The patterns in .gitignore and .gitattributes files can have **/, as a pattern that matches 0 or more levels of subdirectory. E.g. foo/**/bar matches bar in foo itself or in a subdirectory of foo. * When giving arguments without -- disambiguation, object names that come earlier on the command line must not be interpretable as pathspecs and pathspecs that come later on the command line must not be interpretable as object names. This disambiguation rule has been tweaked so that :/ (no other string before or after) is always interpreted as a pathspec; git cmd -- :/ is no longer needed, you can just say git cmd :/. * Various hint lines Git gives when it asks the user to edit messages in the editor are commented out with '#' by default. The core.commentchar configuration variable can be used to customize this '#' to a different character. * git add -u and git add -A without pathspec issues warning to make users aware that they are
[PATCH] git-compat-util.h: Provide missing netdb.h definitions
Some platforms may lack the NI_MAXHOST and NI_MAXSERV values in their system headers, so ensure they are available. Signed-off-by: David Michael fedora@gmail.com --- NI_MAXHOST is missing from my platform, and it has no compatibility definition anywhere. $ grep -FIR NI_MAXHOST imap-send.c:char addr[NI_MAXHOST]; connect.c:static char addr[NI_MAXHOST]; I've been defining it in CFLAGS, but I noticed there is precedence for this type of definition in git-compat-util.h. This patch adds a definition for compatibility. In addition, all the documentation I've seen mentions NI_MAXHOST and NI_MAXSERV together, so this also moves the NI_MAXSERV definition to git-compat-util.h for consistency. daemon.c | 4 git-compat-util.h | 11 +++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/daemon.c b/daemon.c index 4602b46..df8c0ab 100644 --- a/daemon.c +++ b/daemon.c @@ -9,10 +9,6 @@ #define HOST_NAME_MAX 256 #endif -#ifndef NI_MAXSERV -#define NI_MAXSERV 32 -#endif - #ifdef NO_INITGROUPS #define initgroups(x, y) (0) /* nothing */ #endif diff --git a/git-compat-util.h b/git-compat-util.h index b7eaaa9..2580c6b 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -213,6 +213,17 @@ extern char *gitbasename(char *); #include openssl/err.h #endif +/* On most systems netdb.h would have given us this, but + * not on some systems (e.g. z/OS). + */ +#ifndef NI_MAXHOST +#define NI_MAXHOST 1025 +#endif + +#ifndef NI_MAXSERV +#define NI_MAXSERV 32 +#endif + /* On most systems limits.h would have given us this, but * not on some systems (e.g. GNU/Hurd). */ -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
The thing that puzzles me is that nobody reported that the following fail on their platforms (and they do not fail for me on platforms I have to test in my real/virtual boxes). Ok, check_parse calls function parse_date(), it calls parse_date_basic(), where following code is present: memset(tm, 0, sizeof(tm)); tm.tm_year = -1; tm.tm_mon = -1; tm.tm_mday = -1; tm.tm_isdst = -1; tm.tm_hour = -1; tm.tm_min = -1; tm.tm_sec = -1; Almost all fields are set to -1. A bit later match_multi_number() is called. It parses the date and calls is_date() with partially filled tm structure, where all time fields: tm_hour, tm_min, tm_sec are set to -1. tm_to_time_t() function is called by is_date() and has special check: if (tm-tm_hour 0 || tm-tm_min 0 || tm-tm_sec 0) return -1; So is_date() always return negative result for the text string where date is placed before time like '2008-02-14 20:30:45'. It must fail on other platforms as well. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] cat-file: print tags raw for cat-file -p
On Mon, Feb 25, 2013 at 8:50 PM, Jeff King p...@peff.net wrote: Note that git verify-tag and git tag -v depend on cat-file -p to show the tag. This means they will start showing the raw timestamp. We may want to adjust them to use the pretty-printing code from git show. Signed-off-by: Jeff King p...@peff.net --- I don't use git tag -v much, so I'm not sure what is sane there. But this seems like it would be a regression for people who want to check the human-readable date given by GPG against the date in the tag object. Personally, I've found it quite confusing that commits (incl. merged tags) can be verified with `git show --show-signature`, but for tags I must use `git tag -v`... took me a while to find the latter. (`git show --verify` might be even better, but that's just me.) -- Mantas Mikulėnas graw...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
Mike Gorchak mike.gorchak@gmail.com writes: if (tm-tm_hour 0 || tm-tm_min 0 || tm-tm_sec 0) return -1; So is_date() always return negative result for the text string where date is placed before time like '2008-02-14 20:30:45'. Yes, it returns this -1 on other platforms, but... It must fail on other platforms as well. ... the input '2008-02-14 20:30:45' still parses fine for others (including me). That is what is puzzling. A shot in the dark: perhaps your time_t is unsigned? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
Antoine Pelisse apeli...@gmail.com writes: git rm really seems to be a better place for removing files from the index. Then, I don't exactly understand the meaning of git-rm but being a _shortcut_ for remove and stage. git rm --cached is exactly remove from index. And even without --cached, as you notice yourself, it does a remove and stage [removal], so why would it be inappropriate to stage a removal? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
Matthieu Moy matthieu@grenoble-inp.fr writes: Antoine Pelisse apeli...@gmail.com writes: git rm really seems to be a better place for removing files from the index. Then, I don't exactly understand the meaning of git-rm but being a _shortcut_ for remove and stage. git rm --cached is exactly remove from index. And even without --cached, as you notice yourself, it does a remove and stage [removal], so why would it be inappropriate to stage a removal? I do not think git rm is a bad place to add the feature; I was questioning if -u is an appropriate option. The option -u given to git add is internally called take worktree changes, and we would need the option to git rm with that internal meaning. The superficial meaning updated that -u in add -u stands for does not really match what git rm --take-worktree-changes wants to do, as we obviously do not want to remove all updated/modified files. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
On Sun, Feb 24, 2013 at 10:15 AM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@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.
Good catch, this would probably be better:
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, instead of a/b/{ = b}/c
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?
Yes, at least that's what I expected.
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?
I can easily understand why that was missed.
I will try to resubmit with tests very soon.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in ref advertisement
On Mon, 2013-02-25 at 11:27 -0800, Junio C Hamano wrote:
Carlos Martín Nieto c...@elego.de writes:
On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote:
...
Interesting. git ls-remote . | grep 1.8.0- for maint, master,
next and pu produce identical results for me, all showing peeled
ones correctly.
Bisection leads me to Peff's 435c8332 (2012-10-04; upload-pack: use
peel_ref for ref advertisements) and reverting that commit brings the
-rc3^{} back.
A shot in the dark, as I do not seem to be able to reproduce the issue
with anything that contains the commit. Perhaps your .git/packed-refs
is corrupt?
My packed-refs file did not end with LF. It seems it must or the parser
won't consider the last tag in the file to have a peeled target and mine
didn't. I don't how the ended up this way but it looks like there's is a
bug in the parser (or does the format force you to have LF at the end?)
cmn
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in ref advertisement
Carlos Martín Nieto c...@elego.de writes: A shot in the dark, as I do not seem to be able to reproduce the issue with anything that contains the commit. Perhaps your .git/packed-refs is corrupt? My packed-refs file did not end with LF. It seems it must or the parser won't consider the last tag in the file to have a peeled target and mine didn't. I don't how the ended up this way but it looks like there's is a bug in the parser (or does the format force you to have LF at the end?) It is unclear what kind of corruption your packed-refs file had, as there are multiple ways for a file not to end with LF, but anyway. As packed-refs file is expected to be a text file, it is not surprising to get an undefined result if the it ends with an incomplete line. I do not offhand recall if we tolerate lines with CRLF endings; as far as I know we do not _write_ CRLF out, and because we do not expect people to muck directly with editor bypassing pack-refs, I would not be surprised if we didn't do anything special for people who make the lines end with with CRLF the file, either. I'd be more worried about the possibly lost entries after that incomplete line (and also possibly truncated end part of the tagname on the last, incomplete line). Perhaps fsck should diagnose such an anomaly as repository corruption? Perhaps we should enhance the file format a bit (right now, the first capability line should say something like # pack-refs with: peeled to say it was created with the version of pack-refs that can record peeled tags, but we can add other capabilities to extend the format) to add checksums to detect corruption? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-compat-util.h: Provide missing netdb.h definitions
Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
On Mon, Feb 25, 2013 at 11:06:37AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... 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.
Yeah, if this is confirmed to work OK (from eyeballing I do not see
a reason why not...) I agree this is the cleanest way forward.
The only reason I can think of is that you specify utf8, your platform
understands utf8 but not UTF-8, and we rewrite it silently to
UTF-8. That seems somewhat unlikely, but to be on the safe side, why
don't we do it as a fallback? That should be fine performance-wise, as
it only triggers on the error case.
Like this:
-- 8 --
Subject: [PATCH] utf8: accept alternate spellings of UTF-8
The iconv implementation on many platforms will accept
variants of UTF-8, including UTF8, utf-8, and utf8,
but some do not. We make allowances in our code to treat
them all identically, but we sometimes hand the string from
the user directly to iconv. In this case, the platform iconv
may or may not work.
There are really four levels of platform iconv support for
these synonyms:
1. All synonyms understood (e.g., glibc).
2. Only the official UTF-8 understood (e.g., Windows).
3. Official UTF-8 not understood, but some other synonym
understood (it's not known whether such a platform exists).
4. Neither UTF-8 nor any synonym understood (e.g.,
ancient systems, or ones without utf8 support
installed).
This patch teaches git to fall back to using the official
UTF-8 spelling when iconv_open fails (and the encoding was
one of the synonym spellings). This makes things more
convenient to users of type 2 systems, as they can now use
any of the synonyms for the log output encoding.
Type 1 systems are not affected, as iconv already works on
the first try.
Type 4 systems are not affected, as both attempts already
fail.
Type 3 systems will not benefit from the feature, but
because we only use UTF-8 as a fallback, they will not be
regressed (i.e., you can continue to use utf8 if your
platform supports it). We could try all the various
synonyms, but since such systems are not even known to
exist, it's not worth the effort.
Signed-off-by: Jeff King p...@peff.net
---
JSixt, can you double-check that this passes t4210 for you?
utf8.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/utf8.c b/utf8.c
index 1087870..8f6e84b 100644
--- a/utf8.c
+++ b/utf8.c
@@ -507,9 +507,25 @@ char *reencode_string(const char *in, const char
*out_encoding, const char *in_e
if (!in_encoding)
return NULL;
+
conv = iconv_open(out_encoding, in_encoding);
- if (conv == (iconv_t) -1)
- return NULL;
+ if (conv == (iconv_t) -1) {
+ /*
+* Some platforms do not have the variously spelled variants of
+* UTF-8, so let's fall back to trying the most official
+* spelling. We do so only as a fallback in case the platform
+* does understand the user's spelling, but not our official
+* one.
+*/
+ 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;
+ }
+
out = reencode_string_iconv(in, strlen(in), conv);
iconv_close(conv);
return out;
--
1.8.1.4.4.g265d2fa
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in ref advertisement
On Mon, 2013-02-25 at 12:07 -0800, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: A shot in the dark, as I do not seem to be able to reproduce the issue with anything that contains the commit. Perhaps your .git/packed-refs is corrupt? My packed-refs file did not end with LF. It seems it must or the parser won't consider the last tag in the file to have a peeled target and mine didn't. I don't how the ended up this way but it looks like there's is a bug in the parser (or does the format force you to have LF at the end?) It is unclear what kind of corruption your packed-refs file had, as there are multiple ways for a file not to end with LF, but anyway. I mean that the file ended at the end of the peeled id. It was missing the last empty line. As packed-refs file is expected to be a text file, it is not surprising to get an undefined result if the it ends with an incomplete line. I guess that depends on what you mean by incomplete. All the data is there, just that it had tag id SP refname LF ^peeled id as the last entry instead of tag id SP refname LF ^peeled id LF The parser skips the last entry if there is no trailing LF (the same happens for lightweight tags, though here it simply doesn't report them). I do not offhand recall if we tolerate lines with CRLF endings; as far as I know we do not _write_ CRLF out, and because we do not expect people to muck directly with editor bypassing pack-refs, I would not be surprised if we didn't do anything special for people who make the lines end with with CRLF the file, either. I wouldn't expect it to work. It would probably skip over those entries. I'd be more worried about the possibly lost entries after that incomplete line (and also possibly truncated end part of the tagname on the last, incomplete line). Perhaps fsck should diagnose such an anomaly as repository corruption? Perhaps we should enhance the file format a bit (right now, the first capability line should say something like # pack-refs with: peeled to say it was created with the version of pack-refs that can record peeled tags, but we can add other capabilities to extend the format) to add checksums to detect corruption? I just tested and the parser ignores any malformed lines. The ones after it are fine. Nothing complains though, ls-remote just shows the next entry. I'd expect at least fsck to complain, but it doesn't say anything. Presumably they all use the same parser that just ignores anything it doesn't like. cmn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Makefile: make mandir, htmldir and infodir absolute
John Keeping j...@keeping.me.uk writes:
This matches the use of the variables with the same names in autotools,
reducing the potential for user surprise.
Using relative paths in these variables also causes issues if they are
exported from the Makefile, as discussed in commit c09d62f (Makefile: do
not export mandir/htmldir/infodir, 2013-02-12).
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Tue, Feb 12, 2013 at 03:09:53PM -0800, Junio C Hamano wrote:
A longer term fix is to introduce runtime_{man,html,info}dir variables
to hold these funny values, and make {man,html,info}dir variables
to have real paths whose default values begin with $(prefix), but
as a first step, stop exporting them from the top-level Makefile.
Here's an attempt at doing that.
If this is sensible, should bindir_relative be calculated in the same
way?
Thanks for taking the cue from existing bindir_relative, which I
overlooked. Calling these *dir_relative, not runtime_*dir as I
hinted, makes a lot more sense and overall makes things consistent.
As most people would want to say bindir=/usr/local/bin and not
bindir_relative=bin from the command line (and I suspect that people
coming from ./configure would not even have a way to specify the
latter), I think your suggestion to make bindir the primary one and
derive bindir_relative from it makes sense.
What do Windows folks think?
[patch unsnipped for others' reference]
Makefile | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/Makefile b/Makefile
index 7c75e3b..087eec4 100644
--- a/Makefile
+++ b/Makefile
@@ -360,33 +360,39 @@ STRIP ?= strip
# Among the variables below, these:
# gitexecdir
# template_dir
-# mandir
-# infodir
-# htmldir
# sysconfdir
# can be specified as a relative path some/where/else;
# this is interpreted as relative to $(prefix) and git at
# runtime figures out where they are based on the path to the executable.
+# Additionally, the following will be treated as relative by git if they
+# begin with $(prefix)/:
+# mandir
+# infodir
+# htmldir
# This can help installing the suite in a relocatable way.
prefix = $(HOME)
bindir_relative = bin
bindir = $(prefix)/$(bindir_relative)
-mandir = share/man
-infodir = share/info
+mandir = $(prefix)/share/man
+infodir = $(prefix)/share/info
gitexecdir = libexec/git-core
mergetoolsdir = $(gitexecdir)/mergetools
sharedir = $(prefix)/share
gitwebdir = $(sharedir)/gitweb
localedir = $(sharedir)/locale
template_dir = share/git-core/templates
-htmldir = share/doc/git-doc
+htmldir = $(prefix)/share/doc/git-doc
ETC_GITCONFIG = $(sysconfdir)/gitconfig
ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
lib = lib
# DESTDIR =
pathsep = :
+mandir_relative = $(patsubst $(prefix)/%,%,$(mandir))
+infodir_relative = $(patsubst $(prefix)/%,%,$(infodir))
+htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir))
+
export prefix bindir sharedir sysconfdir gitwebdir localedir
CC = cc
@@ -1548,12 +1554,12 @@ ETC_GITATTRIBUTES_SQ = $(subst
','\'',$(ETC_GITATTRIBUTES))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
bindir_relative_SQ = $(subst ','\'',$(bindir_relative))
-mandir_SQ = $(subst ','\'',$(mandir))
-infodir_SQ = $(subst ','\'',$(infodir))
+mandir_relative_SQ = $(subst ','\'',$(mandir_relative))
+infodir_relative_SQ = $(subst ','\'',$(infodir_relative))
localedir_SQ = $(subst ','\'',$(localedir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
-htmldir_SQ = $(subst ','\'',$(htmldir))
+htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
prefix_SQ = $(subst ','\'',$(prefix))
gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
@@ -1685,9 +1691,9 @@ strip: $(PROGRAMS) git$X
git.sp git.s git.o: GIT-PREFIX
git.sp git.s git.o: EXTRA_CPPFLAGS = \
- '-DGIT_HTML_PATH=$(htmldir_SQ)' \
- '-DGIT_MAN_PATH=$(mandir_SQ)' \
- '-DGIT_INFO_PATH=$(infodir_SQ)'
+ '-DGIT_HTML_PATH=$(htmldir_relative_SQ)' \
+ '-DGIT_MAN_PATH=$(mandir_relative_SQ)' \
+ '-DGIT_INFO_PATH=$(infodir_relative_SQ)'
git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
@@ -1697,9 +1703,9 @@ help.sp help.s help.o: common-cmds.h
builtin/help.sp builtin/help.s builtin/help.o: common-cmds.h GIT-PREFIX
builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
- '-DGIT_HTML_PATH=$(htmldir_SQ)' \
- '-DGIT_MAN_PATH=$(mandir_SQ)' \
- '-DGIT_INFO_PATH=$(infodir_SQ)'
+ '-DGIT_HTML_PATH=$(htmldir_relative_SQ)' \
+ '-DGIT_MAN_PATH=$(mandir_relative_SQ)' \
+ '-DGIT_INFO_PATH=$(infodir_relative_SQ)'
version.sp version.s version.o: GIT-VERSION-FILE GIT-USER-AGENT
version.sp version.s version.o: EXTRA_CPPFLAGS = \
--
To unsubscribe from
Re: [PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
On Mon, Feb 25, 2013 at 07:54:47PM +0100, Torsten Bögershausen wrote:
(beside that I couldn't find t4210 somewhere),
It's newly added in 04deccd.
diff --git a/utf8.c b/utf8.c
index a4ee665..e9850d0 100644
--- a/utf8.c
+++ b/utf8.c
@@ -487,6 +487,10 @@ char *reencode_string(const char *in, const char
*out_encoding, const char *in_e
if (!in_encoding)
return NULL;
conv = iconv_open(out_encoding, in_encoding);
+ if (conv == (iconv_t) -1 errno == EINVAL) {
+ conv = iconv_open(is_encoding_utf8(out_encoding) ? UTF-8 :
out_encoding,
+
is_encoding_utf8(in_encoding) ? UTF-8 : in_encoding);
+ }
Yeah, I think this is pretty close to the patch I just sent. You do the
fallback, which I think is sane to prevent any possible regression (for
type 3 systems, as I called them in my commit). I don't know if it is
worth checking errno; we should get the same failure either way, and I'd
worry slightly about some odd iconv implementation does not use EINVAL.
And of course, I like my indentation and commit message better. :)
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
On 25.02.13 16:19, Jeff King wrote:
On Mon, Feb 25, 2013 at 09:37:50AM +0100, Johannes Sixt wrote:
From: Johannes Sixt j...@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 j...@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
--
Thanks, I'm OK with your version.
And a test on cygwin was OK for the new t4210.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in ref advertisement
Carlos Martín Nieto c...@elego.de writes: As packed-refs file is expected to be a text file, it is not surprising to get an undefined result if the it ends with an incomplete line. I guess that depends on what you mean by incomplete. I used that word in the POSIX sense, i.e. http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_67 Unless the user edited the file, an incomplete line may indicate that the file has been truncated when (or after) it was written, and we have to suspect not just that the last line may have been truncated (in this case, not having the full 40-hex object name), but other records that should have been after that line were lost. We may want to detect such corruption at runtime, at least at strategic places; making it a hard runtime error will make it difficult to use Git itself to recover from such an corruption (e.g. you may have a healty mirror from which you can recover refs with fetch --mirror). We should at least refrain from running repack/gc to make things worse, for example. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
So is_date() always return negative result for the text string where date is placed before time like '2008-02-14 20:30:45'. Yes, it returns this -1 on other platforms, but... It must fail on other platforms as well. It also fails under Linux, but real problem is not here, it is just an unoptimal date parser. ... the input '2008-02-14 20:30:45' still parses fine for others (including me). That is what is puzzling. A shot in the dark: perhaps your time_t is unsigned? Yeah, it was a headshot :) It really due to unsigned time_t. I will send two patches right now with fixes regarding unsigned time_t comparison. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Fix unsigned time_t comparison
Do not compare time_t (less comparison) with -1. If time_t is unsigned this leads to always true comparison. Signed-off-by: Mike Gorchak mike.gorchak@gmail.com --- date.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/date.c b/date.c index 57331ed..1ac28e5 100644 --- a/date.c +++ b/date.c @@ -383,7 +383,7 @@ static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, * sense to specify timestamp way into the future. Make * sure it is not later than ten days from now... */ - if (now + 10*24*3600 specified) + if ((specified != -1) (now + 10*24*3600 specified)) return 0; tm-tm_mon = r-tm_mon; tm-tm_mday = r-tm_mday; -- 1.8.2-rc0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Fix time offset calculation in case of unsigned time_t
Fix time offset calculation expression in case if time_t
is unsigned. This code works fine for signed and
unsigned time_t.
Signed-off-by: Mike Gorchak mike.gorchak@gmail.com
---
date.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/date.c b/date.c
index 1ac28e5..11ee7b4 100644
--- a/date.c
+++ b/date.c
@@ -648,6 +648,7 @@ int parse_date_basic(const char *date, unsigned
long *timestamp, int *offset)
struct tm tm;
int tm_gmt;
unsigned long dummy_timestamp;
+ time_t temp_time;
int dummy_offset;
if (!timestamp)
@@ -694,8 +695,14 @@ int parse_date_basic(const char *date, unsigned
long *timestamp, int *offset)
/* mktime uses local timezone */
*timestamp = tm_to_time_t(tm);
- if (*offset == -1)
- *offset = ((time_t)*timestamp - mktime(tm)) / 60;
+ if (*offset == -1) {
+ temp_time = mktime(tm);
+ if ((time_t)*timestamp temp_time) {
+ *offset = ((time_t)*timestamp - temp_time) / 60;
+ } else {
+ *offset = -(int)((temp_time - (time_t)*timestamp) / 60);
+ }
+ }
if (*timestamp == -1)
return -1;
--
1.8.2-rc0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] dir.c: Make git-status --ignored even more consistent
The new git-status --ignored handling introduced with 721ac4ed dir.c:
Make git-status --ignored more consistent and a45fb697 status: always
report ignored tracked directories still has a few flaws in the
--untracked-files=normal case:
- It lists directories that match the exclude pattern, even if they are
tracked, instead of the untracked files and directories that are
_affected_ by the exclude pattern. This is inconsistent with the listing
of untracked files and directories. Additionally, an entire (tracked)
directory may be listed as ignored while contained files are listed as
modified.
- With an untracked directory between the ignored directory and files, the
directory is dropped.
- With a tracked directory between the ignored directory and files, both
the directory and the individual files are listed as ignored.
Change git-status --ignored --untracked-files=normal so that it no longer
lists tracked directories. This is already in line with gitignore(5) and
api-directory-listing.txt, so we don't need to update documentation.
In the git-status case, always use is_path_excluded() instead of
is_excluded(). The latter doesn't check if one of the parent directories
is excluded, and we need the full picture when recursing into ignored
directories. As is_path_excluded() is even more complex, only do this for
untracked files and directories. Keep the original is_excluded() check in
the DIR_COLLECT_IGNORED case so that git-add is not affected.
In read_directory_recursive, pass along the check_only parameter when
recursing into sub directories, so that we don't accidentally call
dir_add_name in the check_only case.
Signed-off-by: Karsten Blees bl...@dcon.de
---
See also: https://github.com/kblees/git/commits/kb/git-status-ignored
Revisiting dir.c, I noticed that the added complexity in .gitignore
processing was just recently introduced by these two changes:
- a45fb697 status: always report ignored tracked directories
- 721ac4ed dir.c: Make git-status --ignored more consistent
Instead of skipping gitignore checks under very special 'safe'
circumstances, this patch focuses on fixing pre-existing bugs
first. The correctness of lazy gitignore checks is then obvious (I
hope) by the very definition of gitignore(5):
gitignore - Specifies intentionally *untracked* files to ignore
[emphasis added].
There's still lots of room for improvement, e.g.:
- prevent git-status --ignored from scanning everything twice
- integrate struct path_exclude_check into struct dir_struct to
save setup costs of is_path_excluded
Cheers,
Karsten
dir.c | 138 -
t/t7061-wtstatus-ignore.sh | 65 +++--
wt-status.c| 2 +-
3 files changed, 123 insertions(+), 82 deletions(-)
diff --git a/dir.c b/dir.c
index 57394e4..1a5440f 100644
--- a/dir.c
+++ b/dir.c
@@ -884,6 +884,17 @@ int is_path_excluded(struct path_exclude_check *check,
return 0;
}
+static int check_path_excluded(struct dir_struct *dir,
+ const char *name, int namelen, int *dtype)
+{
+ struct path_exclude_check check;
+ int excluded;
+ path_exclude_check_init(check, dir);
+ excluded = is_path_excluded(check, name, namelen, dtype);
+ path_exclude_check_clear(check);
+ return excluded;
+}
+
static struct dir_entry *dir_entry_new(const char *pathname, int len)
{
struct dir_entry *ent;
@@ -897,8 +908,7 @@ static struct dir_entry *dir_entry_new(const char
*pathname, int len)
static struct dir_entry *dir_add_name(struct dir_struct *dir, const char
*pathname, int len)
{
- if (!(dir-flags DIR_SHOW_IGNORED)
- cache_name_exists(pathname, len, ignore_case))
+ if (cache_name_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
@@ -1000,9 +1010,8 @@ static enum exist_status directory_exists_in_index(const
char *dirname, int len)
* traversal routine.
*
* Case 1: If we *already* have entries in the index under that
- * directory name, we recurse into the directory to see all the files,
- * unless the directory is excluded and we want to show ignored
- * directories
+ * directory name, we always recurse into the directory to see
+ * all the files.
*
* Case 2: If we *already* have that directory name as a gitlink,
* we always continue to see it as a gitlink, regardless of whether
@@ -1016,9 +1025,9 @@ static enum exist_status directory_exists_in_index(const
char *dirname, int len)
* just a directory, unless hide_empty_directories is
* also true and the directory is empty, in which case
* we just ignore it entirely.
- * if we are looking for ignored directories, look if it
- * contains only ignored files to decide if it must be shown as
- * ignored or not.
+ * if we are looking for ignored directories, we also hide
+ * directories with
Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
Mike Gorchak mike.gorchak@gmail.com writes: So is_date() always return negative result for the text string where date is placed before time like '2008-02-14 20:30:45'. Yes, it returns this -1 on other platforms, but... It must fail on other platforms as well. It also fails under Linux, but real problem is not here, it is just an unoptimal date parser. The test does _not_ fail. That if condition does return -1 on Linux and BSD, and making tm_to_time_t() return a failure, but the caller goes on, ending up with the right values in year/month/date in the tm struct, which is the primary thing the function is used for. As you said, what is_date() wants to see is if the caller guessed the order of three combinations of year/month/date correctly, it cannot necessarily assume the caller already has seen the hour/minutes/seconds yet, so _temporarily_ feeding a valud set of values to hour/minutes/seconds when calling tm_to_time_t() is a good workaround. So the change in your patch sounds correct and use of a temporary tm to avoid contaminating the hour/minutes/seconds passed to the is_date() function while doing so looks good. ... the input '2008-02-14 20:30:45' still parses fine for others (including me). That is what is puzzling. A shot in the dark: perhaps your time_t is unsigned? Yeah, it was a headshot :) It really due to unsigned time_t. I will send two patches right now with fixes regarding unsigned time_t comparison. If your time_t is unsigned, the error returned from tm_to_time_t() will appear to be a time in a distant future, which will prevent is_date() to return Yeah, you guessed the order of year, month, and date correctly to its caller. The code would need to pick a safer mechanism to signal a failure from tm_to_time_t() to its callers. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix unsigned time_t comparison
Mike Gorchak mike.gorchak@gmail.com writes: Do not compare time_t (less comparison) with -1. If time_t is unsigned this leads to always true comparison. Signed-off-by: Mike Gorchak mike.gorchak@gmail.com --- date.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/date.c b/date.c index 57331ed..1ac28e5 100644 --- a/date.c +++ b/date.c @@ -383,7 +383,7 @@ static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, * sense to specify timestamp way into the future. Make * sure it is not later than ten days from now... */ - if (now + 10*24*3600 specified) + if ((specified != -1) (now + 10*24*3600 specified)) return 0; tm-tm_mon = r-tm_mon; tm-tm_mday = r-tm_mday; This is good enough band-aid for now (as it won't change the semantics for anybody), but I suspect in the longer term we would want to pick a different mechanims to signal errors, so that we can specify timestamp that is before 1970. Thanks, will queue. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix unsigned time_t comparison
Mike Gorchak mike.gorchak@gmail.com writes: Do not compare time_t (less comparison) with -1. If time_t is unsigned this leads to always true comparison. Signed-off-by: Mike Gorchak mike.gorchak@gmail.com --- date.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/date.c b/date.c index 57331ed..1ac28e5 100644 --- a/date.c +++ b/date.c @@ -383,7 +383,7 @@ static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, Line-wrapped. Will manually fix while applying. Thanks. * sense to specify timestamp way into the future. Make * sure it is not later than ten days from now... */ - if (now + 10*24*3600 specified) + if ((specified != -1) (now + 10*24*3600 specified)) return 0; tm-tm_mon = r-tm_mon; tm-tm_mday = r-tm_mday; -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
On 25/02/13 19:50, Antoine Pelisse wrote:
On Sun, Feb 24, 2013 at 10:15 AM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@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.
Good catch, this would probably be better:
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, instead of a/b/{ = b}/c
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?
Yes, at least that's what I expected.
Surely it would be a/b/{b = }/c, that is, we have reduced the number
of b's by one. Or am I misunderstanding something?
(I'm guessing it was an all too obvious typo that was misread)
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?
I can easily understand why that was missed.
I will try to resubmit with tests very soon.
Philip
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
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?
Yes, at least that's what I expected.
Surely it would be a/b/{b = }/c, that is, we have reduced the number of
b's by one. Or am I misunderstanding something?
(I'm guessing it was an all too obvious typo that was misread)
Indeed, read to fast and reproduced in suggested new message.
a/b/b/c = a/b/c is equivalent to a/b/{b = }/c
Thank you for proof-reading.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] user-manual: Standardize backtick quoting
From: W. Trevor King wk...@tremily.us I tried to always use backticks for: * Paths and filenames (e.g. `.git/config`) * Compound refs (e.g. `origin/HEAD`) * Git commands (e.g. `git log`) * Command arguments (e.g. `--pretty`) * URLs (e.g. `git://`), as a subset of command arguments * Special characters (e.g. `+` in diffs). * Config options (e.g. `branch.name.remote`) Branch and tag names are sometimes set off with double quotes, sometimes set off with backticks, and sometimes left bare. I tried to judge when the intention was introducing new terms or conventions (double quotes), to reference a recently used command argument (backticks), or to reference the abstract branch/commit (left bare). Obviously these are not particularly crisp definitions, so my decisions are fairly arbitrary ;). When a reference had already been introduced, I changed further double-quoted instances to backticked instances. When new backticks increased the length of a line beyond others in that block, I re-wrapped blocks to 72 columns. Signed-off-by: W. Trevor King wk...@tremily.us --- This patch was not present in v4. Changes from v3: * Rebased onto v1.8.2-rc1, after both my earlier cleanups and the git/Git/GIT standardization from 2de9b71 (Documentation: the name of the system is 'Git', not 'git', 2013-01-21). It's probably easier to review this if you just apply the patch and then go back through with --word-diff ;). Documentation/user-manual.txt | 286 +- 1 file changed, 144 insertions(+), 142 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 5f36f81..0170a23 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -19,7 +19,7 @@ Further chapters cover more specialized topics. Comprehensive reference documentation is available through the man pages, or linkgit:git-help[1] command. For example, for the command -git clone repo, you can either use: +`git clone repo`, you can either use: $ man git-clone @@ -66,11 +66,11 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git The initial clone may be time-consuming for a large project, but you will only need to clone once. -The clone command creates a new directory named after the project (git -or linux-2.6 in the examples above). After you cd into this +The clone command creates a new directory named after the project (`git` +or `linux-2.6` in the examples above). After you cd into this directory, you will see that it contains a copy of the project files, called the def_working_tree,working tree, together with a special -top-level directory named .git, which contains all the information +top-level directory named `.git`, which contains all the information about the history of the project. [[how-to-check-out]] @@ -188,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they did, and why. Every commit has a 40-hexdigit id, sometimes called the object name or the -SHA-1 id, shown on the first line of the git show output. You can usually +SHA-1 id, shown on the first line of the `git show` output. You can usually refer to a commit by a shorter name, such as a tag or a branch name, but this longer name can also be useful. Most importantly, it is a globally unique name for this commit: so if you tell somebody else the object name (for @@ -268,35 +268,35 @@ Manipulating branches Creating, deleting, and modifying branches is quick and easy; here's a summary of the commands: -git branch:: +`git branch`:: list all branches -git branch branch:: - create a new branch named branch, referencing the same +`git branch branch`:: + create a new branch named `branch`, referencing the same point in history as the current branch -git branch branch start-point:: - create a new branch named branch, referencing - start-point, which may be specified any way you like, +`git branch branch start-point`:: + create a new branch named `branch`, referencing + `start-point`, which may be specified any way you like, including using a branch name or a tag name -git branch -d branch:: - delete the branch branch; if the branch you are deleting +`git branch -d branch`:: + delete the branch `branch`; if the branch you are deleting points to a commit which is not reachable from the current branch, this command will fail with a warning. -git branch -D branch:: +`git branch -D branch`:: even if the branch points to a commit not reachable from the current branch, you may know that that commit is still reachable from some other branch or tag. In that case it is safe to use this command to force Git to delete the branch. -git checkout branch:: - make the current branch branch, updating the working - directory to reflect the
Re: [PATCH 12/13] Documentation/Makefile: update git guide links
On 25/02/13 05:29, Junio C Hamano wrote: Philip Oakley philipoak...@iee.org writes: @@ -35,6 +37,8 @@ MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT)) OBSOLETE_HTML = git-remote-helpers.html +OBSOLETE_HTML = everyday.html +OBSOLETE_HTML = user-manual.html DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML) If you are keeping track of inventory of guides in a new static array, do you still need to look up giteveryday or gituser-manual when the user asks for guide documents? I'm only keeping track in the new static array of the 'common guides' and I'd hoped that these two could be included. In other words, can't you change the side that launches the document viewer so that we do not have to rename anything in the first place? The current help code will only show either 'git-cmd' man pages, or 'gitguide' pages so the current everyday and user-manual pages aren't served by the existing help code. $ git help everyday No manual entry for giteveryday Hence the need for the rename and 'obsolete page' entries. I'm guessing that serving any old .txt or .html page from the Documentation directories isn't sensible (rather than being prefix based), but it is a possibility. Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/13] Help.c: add list_common_guides_help() function
On 25/02/13 05:24, Junio C Hamano wrote:
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Sent: Sunday, February 24, 2013 9:01 AM
Philip Oakley philipoak...@iee.org writes:
diff --git a/common-guides.h b/common-guides.h
new file mode 100644
index 000..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?
The first comment line fortells of patch 6 which can generate this .h
file.
The Huh? was about that one, not about reuse. I do not want to see
a build artifact kept in the history without a good reason.
I'd copied it from generate-cmdlist.sh which is a common-cmd.h
dependency and was introduced by
commit a87cd02ce02e97083eb76eb8b9bfeb2e46800fd7
Author: Fredrik Kuivinen freku...@student.liu.se
Date: Thu Mar 9 17:24:19 2006 +0100
Nicer output from 'git'
[jc: with suggestions by Jan-Benedict Glaw]
Signed-off-by: Fredrik Kuivinen freku...@student.liu.se
Signed-off-by: Junio C Hamano jun...@cox.net
The reason in this (my) case, as then, is that it states how the file is
generated so that it can be regenerated later. If the patches are
successful then I'd want the generate-guidelist and generate-cmdlist to
be joined together as an integral part of generating the help system data.
Mind you each review point turns over another stone that needs to be
considered, such as the Makefile link of common-commands.h and similarly
for the Documentation/Makefile - I'm thinking of the issues around
'gitk' and its ilk which isn't a common command (because it has no
hyphen) yet is in the command list, so can be confused with the support
documentation, however I don't mark it as a common guide, so that's OK.
('git help k' does offer the gitk man page ;-)
I'll tidy up the series over the next few days to include the points so far
Philip
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] improve-wincred-compatibility
Karsten Blees karsten.bl...@gmail.com writes: Am 25.02.2013 07:43, schrieb Junio C Hamano: Erik Faye-Lund kusmab...@gmail.com writes: ... I'm in the marking leftover bits mode today, and noticed that nothing happened for this topic in my tree. Did msysgit folks expect me to pick this up directly, or did you guys want to feed this series to me (with possibly other changes you worked on outside this list)? The second patch changes the credential format in a backward-incompatible way, so I think this should be in git.git, too (better than having two incompatible versions around). I am a bit confused by that comment, as it was my understanding that the credential format only refers to what is stored in the Windows specific credential storage and relevant only to users of msysgit (and I expected folks who are using Git natively on Windows to be using msysgit, not git.git), but in any case, of course we would want a single version and format. My question was if msysgit folks want me to take your patch (which I cannot test myself) and then merge my tree to the msysgit tree as part of their regular updates to catch up with 1.8.2 (and future releases), or they want to test your patches in their tree first, and then either throw me a pull request or send me a patch series with Acked-by:. I can obviously go either way, but if they expect the former (i.e. I first apply and they pull) while I expect the latter (i.e. they first apply and I pull), then nothing will happen, and if we go the other way around, we would end up getting two copies of the same series. The question was primarily to avoid these possibilities. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/13] Help.c: add list_common_guides_help() function
Philip Oakley philipoak...@iee.org writes: The first comment line fortells of patch 6 which can generate this .h file. The Huh? was about that one, not about reuse. I do not want to see a build artifact kept in the history without a good reason. I'd copied it from generate-cmdlist.sh which is a common-cmd.h dependency and was introduced by commit a87cd02ce02e97083eb76eb8b9bfeb2e46800fd7 Author: Fredrik Kuivinen freku...@student.liu.se Date: Thu Mar 9 17:24:19 2006 +0100 Nicer output from 'git' [jc: with suggestions by Jan-Benedict Glaw] Signed-off-by: Fredrik Kuivinen freku...@student.liu.se Signed-off-by: Junio C Hamano jun...@cox.net Looking at the change again, I do not see us adding a build artifact (in the case of that patch, common-cmd.h) to our history. Only the recipe to generate that file exists there, which is the right thing to do. Why do we want common-guides.h which is clearly marked as A generated file at its top in our history? That was what made me say Huh?. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] improve-wincred-compatibility
Am 25.02.2013 07:43, schrieb Junio C Hamano: Erik Faye-Lund kusmab...@gmail.com writes: On Thu, Jan 10, 2013 at 1:10 PM, Karsten Blees karsten.bl...@gmail.com wrote: Changes since initial version (see attached diff for details): - split in two patches - removed unused variables - improved the dll error message - changed ?: to if else - added comments Also available here: https://github.com/kblees/git/tree/kb/improve-wincred-compatibility-v2 git pull git://github.com/kblees/git.git kb/improve-wincred-compatibility-v2 Karsten Blees (2): wincred: accept CRLF on stdin to simplify console usage wincred: improve compatibility with windows versions .../credential/wincred/git-credential-wincred.c| 206 - 1 file changed, 75 insertions(+), 131 deletions(-) Wonderful! Acked-by: Erik Faye-Lund kusmab...@gmail.com I'm in the marking leftover bits mode today, and noticed that nothing happened for this topic in my tree. Did msysgit folks expect me to pick this up directly, or did you guys want to feed this series to me (with possibly other changes you worked on outside this list)? The second patch changes the credential format in a backward-incompatible way, so I think this should be in git.git, too (better than having two incompatible versions around). @Pat, Dscho: the rebase-merge script should automatically drop patches found in upstream, correct? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13] Documentation/Makefile: update git guide links
Philip Oakley philipoak...@iee.org writes: On 25/02/13 05:29, Junio C Hamano wrote: ... In other words, can't you change the side that launches the document viewer so that we do not have to rename anything in the first place? The current help code will only show either 'git-cmd' man pages, or gitguide' pages so the current everyday and user-manual pages aren't served by the existing help code. That is exactly what I meant by the side that launches the document viewer. We obviously would not want to type $ git help gituser-manual $ git help giteveryday I was wondering if you can keep document names as-is, register these names without git prefix (i.e. user-manual.html) to the list of guide documents you are generating and compiling into the binary, and let the user ask: $ git help everyday which you would turn into browser %s/%s.html % (GIT_HTML_PATH, 'everyday'), after checking everyday is one of the guides that are available to us. If some guides are already named with git prefix, you can keep them in the compiled-in list with that name. We do not have to worry about redirects and people's bookmarks if we can avoid renaming existing pages, so because grabbing everything with git* glob was easier to write the generate-guidelist script is a false economy. That is the single place we can afford to spend extra effort to make the end result easier to use by the users, no? Or am I misreading the series completely? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: post-receive-email hook with custom_showrev
On Fri, Feb 22, 2013 at 2:57 PM, Adam Mercer ramer...@gmail.com wrote: So it seems as if showrev is being ignored? Can anyone see what I'm doing wrong? Anyone? From looking at the documentation I can't see anything wrong but as it's not displaying anything something is clearly wrong. Cheers Adam -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
On 02/25/2013 01:44 AM, Junio C Hamano wrote: I was in find leftover bits mode today and found this thread hanging. Has anything come out of this thread, or there is nothing to improve in this area? The patch passed my simple tests (build, run a few commands), but I didn't get around to a full test. And of course, I am testing on current Cygwin where git compiles and runs correctly anyway. Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/WIP PATCH 1/3] teach config parsing to read from strbuf
On Mon, Feb 25, 2013 at 02:04:18AM +0100, Heiko Voigt wrote: This can be used to read configuration values directly from gits database. Signed-off-by: Heiko Voigt hvo...@hvoigt.net FWIW, I implemented something quite similar as a 2-patch series here: http://article.gmane.org/gmane.comp.version-control.git/189142 http://article.gmane.org/gmane.comp.version-control.git/189143 but they were never merged as we ended up throwing out the feature built on top (including config from blobs). I didn't look too closely at your implementation, but it looks like you touched the same spots in the same way. Which is probably a good thing, and may give another data point for Junio's what would it look like to read another source comment. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 10:53 PM, Thomas Rast tr...@inf.ethz.ch wrote: * We should prepare an ideas page. Last year, Peff made one on https://github.com/peff/git/wiki/SoC-2012-Ideas [Resending the mail, because the last one failed because of inline html content] One of the proposed ideas last year - 'Use JavaScript library / framework in gitweb' I wanted to work on this project last year, but Git community didn't get a slot for the project from Google. I still worked on it and almost finished it. Sadly I never got time to polish it to merge to master. you can see some of my commits on it here. https://github.com/jaseemabid/git/commits/gitweb Detailed notes on what actually did. https://gist.github.com/jaseemabid/3218461 Gitweb is 1 huge perl script and even though it *works*, it is a poor work in 2013. The code is pretty old and is a hard thing to jump into. Quite a few here helped me to get started and it was a pretty good experience. Jakub was the mentor. Ram and John 'warthog' Hawley occasionally helped with git and general feedback back then. Andrew Sayers andrew-...@pileofstuff.org helped a lot, but he just disappeared one day. I remember John mentioning about splitting the file into smaller ones, rewriting some sections, adding more documentation etc. I'm not sure if any work was done on this. I couldn't follow the project for sometime. I will try to make some time and finish it off in the next week or so. I am having a bad schedule now between school and job, but will try my level best. -- Regards, Jaseem Abid github.com/jaseemabid -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] t4210-log-i18n: spell encoding name UTF-8 correctly
Am 2/25/2013 21:31, schrieb Jeff King:
Subject: [PATCH] utf8: accept alternate spellings of UTF-8
...
JSixt, can you double-check that this passes t4210 for you?
Yes, t4210 and all other *i18n* and *log* tests pass with this patch.
Thanks,
-- Hannes
utf8.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/utf8.c b/utf8.c
index 1087870..8f6e84b 100644
--- a/utf8.c
+++ b/utf8.c
@@ -507,9 +507,25 @@ char *reencode_string(const char *in, const char
*out_encoding, const char *in_e
if (!in_encoding)
return NULL;
+
conv = iconv_open(out_encoding, in_encoding);
- if (conv == (iconv_t) -1)
- return NULL;
+ if (conv == (iconv_t) -1) {
+ /*
+ * Some platforms do not have the variously spelled variants of
+ * UTF-8, so let's fall back to trying the most official
+ * spelling. We do so only as a fallback in case the platform
+ * does understand the user's spelling, but not our official
+ * one.
+ */
+ 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;
+ }
+
out = reencode_string_iconv(in, strlen(in), conv);
iconv_close(conv);
return out;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RelNotes/1.8.1.5: mention correct 'Fixes since'
RelNotes/1.8.1.5.txt mentions 'Fixes since v1.8.1.5' which should obviously be empty. This fixes it. Signed-off-by: Stefan Naewe stefan.na...@gmail.com --- Documentation/RelNotes/1.8.1.5.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/1.8.1.5.txt b/Documentation/RelNotes/1.8.1.5.txt index 92da6b2..0fb94a9 100644 --- a/Documentation/RelNotes/1.8.1.5.txt +++ b/Documentation/RelNotes/1.8.1.5.txt @@ -1,7 +1,7 @@ Git 1.8.1.5 Release Notes = -Fixes since v1.8.1.5 +Fixes since v1.8.1.4 * git apply --summary has been taught to make sure the similarity -- 1.8.1.msysgit.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
