* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 16:38 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <20100108162404.GA5799@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Try this:
>
> git init
> touch base-cruft
> mkdir subdir
> touch subdir/cruft
> echo subdir >.gitignore
> git status ;# shows gitignore and base-cruft
> git ls-files -o --exclude-standard ;# ditto
> cd subdir
> git status . ;# shows nothing, since everything in subdir is ignored
> git ls-files -o --exclude-standard ;# BUG: shows cruft
>
> Yes, ls-files operates in the subdirectory, which means it should not
> show cruft from the root (and it does not). But it should respect
> .gitignore directives going all the way back to the root, and it
> doesn't.
Shouldn't the ls-files be run from the root with subdir/ as pathspec, if
you wanted to do apples-to-apples comparison between it and status?
^ permalink raw reply
* [PATCH] base85: encode_85() does not use the decode table
From: Andreas Gruenbacher @ 2010-01-08 16:22 UTC (permalink / raw)
To: git; +Cc: Andreas Gruenbacher
In-Reply-To: <7v3a2giobm.fsf@alter.siamese.dyndns.org>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
base85.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/base85.c b/base85.c
index 1d165d9..7204ce2 100644
--- a/base85.c
+++ b/base85.c
@@ -84,8 +84,6 @@ int decode_85(char *dst, const char *buffer, int len)
void encode_85(char *buf, const unsigned char *data, int bytes)
{
- prep_base85();
-
say("encode 85");
while (bytes) {
unsigned acc = 0;
--
1.6.6.75.g37bae
^ permalink raw reply related
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 16:24 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jon Schewe, spearce, git
In-Reply-To: <4B4751EA.8060707@drmicha.warpmail.net>
On Fri, Jan 08, 2010 at 04:40:26PM +0100, Michael J Gruber wrote:
> Jon Schewe venit, vidit, dixit 08.01.2010 16:17:
> > If I create a directory "build" at the top of my git repository and then
> > add it to .gitignore, git behaves as expected and ignores the build
> > directory when checking status. Now git-completion.sh has some issues. I
> > have GIT_PS1_SHOWUNTRACKEDFILES to "1", so that I will be notified when
> > there are untracked files in my working directory. When I'm in the
> > top-level directory my prompt looks like expected, no '%'. However if I
> > change to the build directory I get a '%', even though git status shows
> > no untracked files. I see that git-completion.sh is using git ls-files
> > to check this and that function does indeed show output when in my build
> > directory. So the question here: Is git-completion.sh using ls-files
> > improperly or is ls-files behaving improperly?
> >
>
> Neither, but: output between status and ls-files is inconsistent. More
> specifically, different commands behave differently with respect to the
> treatment of subdirs. ls-files assumes "." implicitly, status does not.
> "git status ." should give you the same behavior is "git ls-files" in
> this regard.
It doesn't, and I think there is a bug in ls-files.
Try this:
git init
touch base-cruft
mkdir subdir
touch subdir/cruft
echo subdir >.gitignore
git status ;# shows gitignore and base-cruft
git ls-files -o --exclude-standard ;# ditto
cd subdir
git status . ;# shows nothing, since everything in subdir is ignored
git ls-files -o --exclude-standard ;# BUG: shows cruft
Yes, ls-files operates in the subdirectory, which means it should not
show cruft from the root (and it does not). But it should respect
.gitignore directives going all the way back to the root, and it
doesn't.
-Peff
^ permalink raw reply
* [PATCH] base85: encode85() does not use the decode table
From: Andreas Gruenbacher @ 2010-01-08 16:17 UTC (permalink / raw)
To: git; +Cc: Andreas Gruenbacher
In-Reply-To: <7v3a2giobm.fsf@alter.siamese.dyndns.org>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
base85.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/base85.c b/base85.c
index 1d165d9..7204ce2 100644
--- a/base85.c
+++ b/base85.c
@@ -84,8 +84,6 @@ int decode_85(char *dst, const char *buffer, int len)
void encode_85(char *buf, const unsigned char *data, int bytes)
{
- prep_base85();
-
say("encode 85");
while (bytes) {
unsigned acc = 0;
--
1.6.6.75.g37bae
^ permalink raw reply related
* [RFC PATCH 3/3] ident.c: treat $EMAIL as giving user.email identity explicitly
From: Junio C Hamano @ 2010-01-08 16:08 UTC (permalink / raw)
To: git, Matt Kraai, Pierre Habouzit, Josh Triplett; +Cc: Adam Megacz
In-Reply-To: <7vskagh9fg.fsf@alter.siamese.dyndns.org>
The environment variable EMAIL has been honored since 28a94f8 (Fall back
to $EMAIL for missing GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL,
2007-04-28) as the end-user's wish to use the address as the identity.
When we use it, we should say we are explicitly given email by the user.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is an RFC as some people would feel strongly about _not_ using
$EMAIL as their commit identity and would rather override it explicitly
with user.email; if they weren't told about git using their $EMAIL,
they will complain.
ident.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index e67c5ad..d4f6145 100644
--- a/ident.c
+++ b/ident.c
@@ -85,10 +85,11 @@ static void setup_ident(void)
if (!git_default_email[0]) {
const char *email = getenv("EMAIL");
- if (email && email[0])
+ if (email && email[0]) {
strlcpy(git_default_email, email,
sizeof(git_default_email));
- else {
+ user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ } else {
if (!pw)
pw = getpwuid(getuid());
if (!pw)
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [PATCH 2/3] ident.c: check explicit identity for name and email separately
From: Junio C Hamano @ 2010-01-08 16:04 UTC (permalink / raw)
To: git, Santi Béjar; +Cc: Adam Megacz
In-Reply-To: <7vskagh9fg.fsf@alter.siamese.dyndns.org>
bb1ae3f (commit: Show committer if automatic, 2008-05-04) added a logic to
check both name and email were given explicitly by the end user, but it
assumed that fmt_ident() is never called before git_default_user_config()
is called, which was fragile. The former calls setup_ident() and fills
the "default" name and email, so the check in the config parser would have
mistakenly said both are given even if only user.name was provided.
Make the logic more robust by keeping track of name and email separately.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit.c | 2 +-
cache.h | 3 +++
config.c | 6 ++----
ident.c | 7 ++++---
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 073fe90..f4974b5 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -624,7 +624,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
author_ident);
free(author_ident);
- if (!user_ident_explicitly_given)
+ if (user_ident_explicitly_given != IDENT_ALL_GIVEN)
fprintf(fp,
"%s"
"# Committer: %s\n",
diff --git a/cache.h b/cache.h
index bf468e5..16c8e8d 100644
--- a/cache.h
+++ b/cache.h
@@ -925,6 +925,9 @@ extern const char *config_exclusive_filename;
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
extern char git_default_name[MAX_GITNAME];
+#define IDENT_NAME_GIVEN 01
+#define IDENT_MAIL_GIVEN 02
+#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
extern int user_ident_explicitly_given;
extern const char *git_commit_encoding;
diff --git a/config.c b/config.c
index 37385ce..fa1a0c0 100644
--- a/config.c
+++ b/config.c
@@ -528,8 +528,7 @@ static int git_default_user_config(const char *var, const char *value)
if (!value)
return config_error_nonbool(var);
strlcpy(git_default_name, value, sizeof(git_default_name));
- if (git_default_email[0])
- user_ident_explicitly_given = 1;
+ user_ident_explicitly_given |= IDENT_NAME_GIVEN;
return 0;
}
@@ -537,8 +536,7 @@ static int git_default_user_config(const char *var, const char *value)
if (!value)
return config_error_nonbool(var);
strlcpy(git_default_email, value, sizeof(git_default_email));
- if (git_default_name[0])
- user_ident_explicitly_given = 1;
+ user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return 0;
}
diff --git a/ident.c b/ident.c
index e6c1798..e67c5ad 100644
--- a/ident.c
+++ b/ident.c
@@ -249,9 +249,10 @@ const char *git_author_info(int flag)
const char *git_committer_info(int flag)
{
- if (getenv("GIT_COMMITTER_NAME") &&
- getenv("GIT_COMMITTER_EMAIL"))
- user_ident_explicitly_given = 1;
+ if (getenv("GIT_COMMITTER_NAME"))
+ user_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ if (getenv("GIT_COMMITTER_EMAIL"))
+ user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return fmt_ident(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"),
getenv("GIT_COMMITTER_DATE"),
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [PATCH 1/3] ident.c: remove unused variables
From: Junio C Hamano @ 2010-01-08 16:03 UTC (permalink / raw)
To: git; +Cc: Adam Megacz
In-Reply-To: <7vskagh9fg.fsf@alter.siamese.dyndns.org>
d5cc2de (ident.c: Trim hint printed when gecos is empty., 2006-11-28)
reworded the message used as printf() format and dropped "%s" from it;
these two variables that hold the names of GIT_{AUTHOR,COMMITTER}_NAME
environment variables haven't been used since then.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is an independent clean-up
ident.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/ident.c b/ident.c
index 26409b2..e6c1798 100644
--- a/ident.c
+++ b/ident.c
@@ -168,8 +168,6 @@ static int copy(char *buf, size_t size, int offset, const char *src)
return offset;
}
-static const char au_env[] = "GIT_AUTHOR_NAME";
-static const char co_env[] = "GIT_COMMITTER_NAME";
static const char *env_hint =
"\n"
"*** Please tell me who you are.\n"
@@ -204,7 +202,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
- fprintf(stderr, env_hint, au_env, co_env);
+ fprintf(stderr, env_hint);
env_hint = NULL; /* warn only once */
}
if (error_on_no_name)
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Junio C Hamano @ 2010-01-08 16:02 UTC (permalink / raw)
To: Adam Megacz; +Cc: git
In-Reply-To: <xuu28wc9xd42.fsf@nowhere.com>
Adam Megacz <adam@megacz.com> writes:
> I propose instead that "git commit -e" cause the metadata headers to be
> provided to $EDITOR. People who care about the metadata can simply get
> in the habit of always passing that option when invoking "git commit".
That is already done by bb1ae3f (commit: Show committer if automatic,
2008-05-04), so there is no need to propose anything.
I see a bit of room for tightening logic in that ancient commit, though.
^ permalink raw reply
* Re: [PATCH 2/3] base85: No need to initialize the decode table in encode_85
From: Junio C Hamano @ 2010-01-08 15:55 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Andreas Gruenbacher, git
In-Reply-To: <4B475361.60506@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Andreas Gruenbacher venit, vidit, dixit 08.01.2010 14:39:
>> Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
>> ---
>
> For the less informed it may be worthwhile to have an explanation in the
> commit message why encode_85() does not need to initialize the table. (I
> strongly suspect it's a matter of de vs. en, i.e. "because it only
> encodes but does not decode."...)
The title can be reworded to
base85: encode85() does not use the decode table
^ permalink raw reply
* Re: [PATCH 2/3] base85: No need to initialize the decode table in encode_85
From: Michael J Gruber @ 2010-01-08 15:46 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <1262958000-27181-2-git-send-email-agruen@suse.de>
Andreas Gruenbacher venit, vidit, dixit 08.01.2010 14:39:
> Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
> ---
For the less informed it may be worthwhile to have an explanation in the
commit message why encode_85() does not need to initialize the table. (I
strongly suspect it's a matter of de vs. en, i.e. "because it only
encodes but does not decode."...)
> base85.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/base85.c b/base85.c
> index 1d165d9..7204ce2 100644
> --- a/base85.c
> +++ b/base85.c
> @@ -84,8 +84,6 @@ int decode_85(char *dst, const char *buffer, int len)
>
> void encode_85(char *buf, const unsigned char *data, int bytes)
> {
> - prep_base85();
> -
> say("encode 85");
> while (bytes) {
> unsigned acc = 0;
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Michael J Gruber @ 2010-01-08 15:40 UTC (permalink / raw)
To: Jon Schewe; +Cc: spearce, git
In-Reply-To: <4B474C73.8080100@mtu.net>
Jon Schewe venit, vidit, dixit 08.01.2010 16:17:
> If I create a directory "build" at the top of my git repository and then
> add it to .gitignore, git behaves as expected and ignores the build
> directory when checking status. Now git-completion.sh has some issues. I
> have GIT_PS1_SHOWUNTRACKEDFILES to "1", so that I will be notified when
> there are untracked files in my working directory. When I'm in the
> top-level directory my prompt looks like expected, no '%'. However if I
> change to the build directory I get a '%', even though git status shows
> no untracked files. I see that git-completion.sh is using git ls-files
> to check this and that function does indeed show output when in my build
> directory. So the question here: Is git-completion.sh using ls-files
> improperly or is ls-files behaving improperly?
>
Neither, but: output between status and ls-files is inconsistent. More
specifically, different commands behave differently with respect to the
treatment of subdirs. ls-files assumes "." implicitly, status does not.
"git status ." should give you the same behavior is "git ls-files" in
this regard.
Michael
^ permalink raw reply
* Re: [PATCH] Document git-blame triple -C option
From: Michael J Gruber @ 2010-01-08 15:36 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <f3271551001080610p62ef6abfge1c96648d1ea948f@mail.gmail.com>
Ramkumar Ramachandra venit, vidit, dixit 08.01.2010 15:10:
> The git-blame -CCC option is undocumented. This patch fixes that.
Above you see why it is difficult to comment on attached patches.
They're not included!
You re-wrapped the existing documentation. Please don't do that, because
it makes it difficult to spot what you really changed.
It seems you added one sentence. Please don't use "thrice" for "three
times", that is very old English and sounds funny.
Michael
^ permalink raw reply
* Possible bug in git-completion.sh
From: Jon Schewe @ 2010-01-08 15:17 UTC (permalink / raw)
To: spearce; +Cc: git
If I create a directory "build" at the top of my git repository and then
add it to .gitignore, git behaves as expected and ignores the build
directory when checking status. Now git-completion.sh has some issues. I
have GIT_PS1_SHOWUNTRACKEDFILES to "1", so that I will be notified when
there are untracked files in my working directory. When I'm in the
top-level directory my prompt looks like expected, no '%'. However if I
change to the build directory I get a '%', even though git status shows
no untracked files. I see that git-completion.sh is using git ls-files
to check this and that function does indeed show output when in my build
directory. So the question here: Is git-completion.sh using ls-files
improperly or is ls-files behaving improperly?
--
Jon Schewe | http://mtu.net/~jpschewe
If you see an attachment named signature.asc, this is my digital
signature. See http://www.gnupg.org for more information.
For I am convinced that neither death nor life, neither angels nor
demons, neither the present nor the future, nor any powers,
neither height nor depth, nor anything else in all creation, will
be able to separate us from the love of God that is in Christ
Jesus our Lord. - Romans 8:38-39
^ permalink raw reply
* Re: [StGit PATCH 1/3] Populate the cached config options with the defaults
From: Karl Wiberg @ 2010-01-08 14:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b8197bcb1001080630i6daad79anf8323f8001d38db3@mail.gmail.com>
On Fri, Jan 8, 2010 at 3:30 PM, Karl Wiberg <kha@treskal.com> wrote:
> Hmm. What's the point of this rewrite?
Ah, never mind, patch 2/3 made it clear. Though it would have been
nice to read about it in the commit message. ;-)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH 1/3] Populate the cached config options with the defaults
From: Karl Wiberg @ 2010-01-08 14:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20100108123559.24161.14842.stgit@pc1117.cambridge.arm.com>
Hmm. What's the point of this rewrite?
On Fri, Jan 8, 2010 at 1:35 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> + try:
> + return self.__cache[name][-1]
> + except KeyError:
> + return None
You could write this as
return self.__cache.get(name, [None])[-1]
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Nguyen Thai Ngoc Duy @ 2010-01-08 14:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <fcaeb9bf1001071009m11a7adfehdad485a4baeeb958@mail.gmail.com>
On 1/8/10, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 1/8/10, Junio C Hamano <gitster@pobox.com> wrote:
> > I think the code for columnar output used in producing "git help -a"
> > output should be reusable (if not, should be made reusable and reused
> > here).
>
>
> I saw that and even exported term_columns() but was too lazy to make
> pretty_print_string_list() something reusable. Will think of it again
> when I see this command is worth pushing forward.
I think again. There are a few places that may benefit from column
display: git tag -l, git grep -l, git branch (if you have lots of
branches) and probably untracked part of "git status". Moreover, I
have to implement it anyway because Solaris does not have command
"column". How about an external "git-column"? This way we don't have
to modify lots of code for columnized output. We may want to name it
"git-pager" if we want an internal pager someday ;)
--
Duy
^ permalink raw reply
* [PATCH] Document git-blame triple -C option
From: Ramkumar Ramachandra @ 2010-01-08 14:10 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 66 bytes --]
The git-blame -CCC option is undocumented. This patch fixes that.
[-- Attachment #2: 0001-Document-git-blame-triple-C-option.patch --]
[-- Type: text/x-patch, Size: 2251 bytes --]
From 2732bf40f7607941ce1d65ce4d0effc0e8a0a593 Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Fri, 8 Jan 2010 19:29:02 +0530
Subject: [PATCH] Document git-blame triple -C option
git-blame -CCC is explained in builin-blame.c line 2171, but is
unexplained in the documentation. This patch fixes that.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/blame-options.txt | 13 +++++++------
Documentation/git-blame.txt | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 1625ffc..e1abf1e 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -94,12 +94,13 @@ within a file for it to associate those lines with the parent
commit.
-C|<num>|::
- In addition to `-M`, detect lines copied from other
- files that were modified in the same commit. This is
- useful when you reorganize your program and move code
- around across files. When this option is given twice,
- the command additionally looks for copies from all other
- files in the parent for the commit that creates the file.
+ In addition to `-M`, detect lines copied from other files that
+ were modified in the same commit. This is useful when you
+ reorganize your program and move code around across files.
+ When this option is given twice, the command additionally
+ looks for copies from other files in the commit that creates
+ the file. When this option is given thrice, the command
+ additionally looks for copies from other files in any commit.
+
<num> is optional but it is the lower bound on the number of
alphanumeric characters that git must detect as moving
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 8c7b7b0..25bc416 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
- [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
+ [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[<rev> | --contents <file> | --reverse <rev>] [--] <file>
DESCRIPTION
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] mingw: disable Python
From: Erik Faye-Lund @ 2010-01-08 13:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, msysgit, git
In-Reply-To: <7vpr5kpvmh.fsf@alter.siamese.dyndns.org>
On Fri, Jan 8, 2010 at 2:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@googlemail.com> writes:
>
>>> On Fri, 8 Jan 2010, Johannes Sixt wrote:
>>>
>>>> Erik Faye-Lund schrieb:
>>>> > Python is not commonly installed on Windows machines, so
>>>> > we should disable it there by default.
>>>> >
>>>> > --- a/Makefile
>>>> > +++ b/Makefile
>>>> > @@ -1027,6 +1027,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>>>> > + NO_PYTHON = YesPlease
>>>>
>>>> I'm worried that with this solution it is impossible to re-enable Python
>>>> in config.mak (how do you undefine a Makefile variable?);
>>
>>> How about
>>>
>>> NO_PYTHON=
>>>
>>> in config.mak?
>>
>> That doesn't work for me, at least not out of the box. NO_PYTHON is
>> still defined, it's just defined to an empty string.
>
> I think Dscho is right. "ifdef FOO" yields (and should yield) false if
> FOO is set to empty.
>
In that case I guess I messed up my test. I'll retest.
Yes, I messed up. "NO_PYTHON=" works like a charm.
So, no repost :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] mingw: disable Python
From: Johannes Sixt @ 2010-01-08 13:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: kusmabite, Johannes Schindelin, msysgit, git
In-Reply-To: <7vpr5kpvmh.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Erik Faye-Lund <kusmabite@googlemail.com> writes:
>>> On Fri, 8 Jan 2010, Johannes Sixt wrote:
>>>> (how do you undefine a Makefile variable?);
>>> How about
>>>
>>> NO_PYTHON=
>>>
>>> in config.mak?
>> That doesn't work for me, at least not out of the box. NO_PYTHON is
>> still defined, it's just defined to an empty string.
>
> I think Dscho is right. "ifdef FOO" yields (and should yield) false if
> FOO is set to empty.
Indeed. Strange. It didn't work when I tested it a few hours ago, but no
it works as you say. According to the docs, 'ifdef' actually does not test
defined-ness, but emptyness. So, Erik's original version is fine:
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* [PATCH 1/3] base85 debug code: Fix length byte calculation
From: Andreas Gruenbacher @ 2010-01-08 13:39 UTC (permalink / raw)
To: git; +Cc: Andreas Gruenbacher
In-Reply-To: <alpine.LFD.2.00.1001071253400.21025@xanadu.home>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
base85.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/base85.c b/base85.c
index b417a15..1d165d9 100644
--- a/base85.c
+++ b/base85.c
@@ -118,7 +118,7 @@ int main(int ac, char **av)
int len = strlen(av[2]);
encode_85(buf, av[2], len);
if (len <= 26) len = len + 'A' - 1;
- else len = len + 'a' - 26 + 1;
+ else len = len + 'a' - 26 - 1;
printf("encoded: %c%s\n", len, buf);
return 0;
}
--
1.6.6.75.g37bae
^ permalink raw reply related
* [PATCH 3/3] base85: Make the code more obvious instead of explaining the non-obvious
From: Andreas Gruenbacher @ 2010-01-08 13:40 UTC (permalink / raw)
To: git; +Cc: Andreas Gruenbacher
In-Reply-To: <alpine.LFD.2.00.1001071253400.21025@xanadu.home>
Here is another cleanup ...
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
base85.c | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/base85.c b/base85.c
index 7204ce2..e459fee 100644
--- a/base85.c
+++ b/base85.c
@@ -57,14 +57,8 @@ int decode_85(char *dst, const char *buffer, int len)
de = de85[ch];
if (--de < 0)
return error("invalid base85 alphabet %c", ch);
- /*
- * Detect overflow. The largest
- * 5-letter possible is "|NsC0" to
- * encode 0xffffffff, and "|NsC" gives
- * 0x03030303 at this point (i.e.
- * 0xffffffff = 0x03030303 * 85).
- */
- if (0x03030303 < acc ||
+ /* Detect overflow. */
+ if (0xffffffff / 85 < acc ||
0xffffffff - de < (acc *= 85))
return error("invalid base85 sequence %.5s", buffer-5);
acc += de;
--
1.6.6.75.g37bae
^ permalink raw reply related
* [PATCH 2/3] base85: No need to initialize the decode table in encode_85
From: Andreas Gruenbacher @ 2010-01-08 13:39 UTC (permalink / raw)
To: git; +Cc: Andreas Gruenbacher
In-Reply-To: <alpine.LFD.2.00.1001071253400.21025@xanadu.home>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
base85.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/base85.c b/base85.c
index 1d165d9..7204ce2 100644
--- a/base85.c
+++ b/base85.c
@@ -84,8 +84,6 @@ int decode_85(char *dst, const char *buffer, int len)
void encode_85(char *buf, const unsigned char *data, int bytes)
{
- prep_base85();
-
say("encode 85");
while (bytes) {
unsigned acc = 0;
--
1.6.6.75.g37bae
^ permalink raw reply related
* Re: [PATCH] mingw: disable Python
From: Junio C Hamano @ 2010-01-08 13:35 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Schindelin, Johannes Sixt, msysgit, git
In-Reply-To: <40aa078e1001080249t16b0ee01i5ceb8e7ad2426e70@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
>> On Fri, 8 Jan 2010, Johannes Sixt wrote:
>>
>>> Erik Faye-Lund schrieb:
>>> > Python is not commonly installed on Windows machines, so
>>> > we should disable it there by default.
>>> >
>>> > --- a/Makefile
>>> > +++ b/Makefile
>>> > @@ -1027,6 +1027,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>>> > + NO_PYTHON = YesPlease
>>>
>>> I'm worried that with this solution it is impossible to re-enable Python
>>> in config.mak (how do you undefine a Makefile variable?);
>
>> How about
>>
>> NO_PYTHON=
>>
>> in config.mak?
>
> That doesn't work for me, at least not out of the box. NO_PYTHON is
> still defined, it's just defined to an empty string.
I think Dscho is right. "ifdef FOO" yields (and should yield) false if
FOO is set to empty.
-- >8 -- cut here and try it for yourself -- >8 --
#!/bin/sh
rm -f config.mk
cat >Makefile <<\EOF
# The default is...
all::
FROTZ = NITFOL
-include config.mk
ifdef FROTZ
all::
echo FROTZ is $(FROTZ)
else
all::
echo FROTZ is not defined
endif
EOF
make
# says "NITFOL"
echo "FROTZ =" >config.mk
make
# says "not defined"
exit
-- 8< --
^ permalink raw reply
* Re: [RESEND PATCH] french translation of gitk
From: Emmanuel Trillaud @ 2010-01-08 13:22 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Paul Mackerras, Maximilien Noal, Matthieu Moy, Nicolas Pitre,
Git Mailing List, Thomas Moulard, Junio C Hamano, Guy Brand
In-Reply-To: <20091229223758.GB12965@vidovic>
Hi all,
Thank Nicolas for beeing the ambassador this translation :-)
Le Tue, 29 Dec 2009 23:39:39 +0100,
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> a écrit :
> Hi,
>
> I may be wrong but I think this patch wasn't merged and I didn't see any
> comment on it.
>
> Could you please merge this patch?
>
>
> -- >8 --
> Subject: [PATCH] gitk: french translation
> From: Emmanuel Trillaud <etrillaud@gmail.com>
>
> Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
> Signed-off-by: Thomas Moulard <thomas.moulard@gmail.com>
> Signed-off-by: Guy Brand <gb@unistra.fr>
> Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
> ---
[snip]
I got the following errors when trying to 'make' gitk with your latest patch :
$ LANG=C make
Generating catalog po/fr.msg
msgfmt --statistics --tcl po/fr.po -l fr -d po/
po/fr.po:23:24: invalid multibyte sequence
po/fr.po:23:28: invalid multibyte sequence
po/fr.po:23:66: invalid multibyte sequence
po/fr.po:27:38: invalid multibyte sequence
po/fr.po:31:16: invalid multibyte sequence
po/fr.po:31:22: invalid multibyte sequence
po/fr.po:36:17: invalid multibyte sequence
po/fr.po:36:26: invalid multibyte sequence
po/fr.po:36:40: invalid multibyte sequence
po/fr.po:36:44: invalid multibyte sequence
po/fr.po:37:9: invalid multibyte sequence
po/fr.po:46:17: invalid multibyte sequence
po/fr.po:46:26: invalid multibyte sequence
po/fr.po:46:40: invalid multibyte sequence
po/fr.po:46:44: invalid multibyte sequence
po/fr.po:46:76: invalid multibyte sequence
po/fr.po:51:16: invalid multibyte sequence
po/fr.po:51:22: invalid multibyte sequence
po/fr.po:63:23: invalid multibyte sequence
po/fr.po:63:32: invalid multibyte sequence
msgfmt: too many errors, aborting
make: *** [po/fr.msg] Error 1
This is obviously an encoding problem.
My LANG is 'fr_FR.UTF-8' if it is relevant.
The file generate by :
iconv --from-code ISO_8859-1 --to-code UTF-8 --output po/fr.po po/fr.po
work as expected.
Don't the *.po files need to be in utf8?
Best regards
Emmanuel
^ permalink raw reply
* Re: base85: Two tiny fixes
From: Andreas Gruenbacher @ 2010-01-08 13:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.1001071253400.21025@xanadu.home>
On Thursday 07 January 2010 18:58:01 Nicolas Pitre wrote:
> ACK. Please post them to this list.
Okay, done.
> On Thu, 7 Jan 2010, Andreas Gruenbacher wrote:
> > There is another little oddity in the way the de85 table is set up: 0
> > indicates an invalid entry; to avoid this from clashing with a valid entry,
> > valid entries are incremented by one and decremented again while decoding.
> > This leads to slightly worse code than using a negative number to indicate
> > invalid values (and avoiding to increment/decrement).
>
> You can make a patch to modify that as well if you wish.
Nah, it's not worth the noise.
> And in that case don't forget to make de85 explicitly signed as a char is
> unsigned by default on some platforms.
I would have forgotten this; thanks for pointing it out!
Thanks,
Andreas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox