From: Johannes Sixt [mailto:j...@kdbg.org]
Sent: Saturday, December 15, 2012 12:17 AM
To: Joachim Schmitz
Cc: gits...@pobox.com; fedora@gmail.com; Git Mailing List
Subject: Re: [PATCH 4/4] Declare that HP NonStop systems require strings.h
Am 14.12.2012 23:46, schrieb Joachim Schmitz:
- Start list with 1 instead of 0 because ASCIIDOC will renumber it anyway
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/technical/api-command.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/technical/api-command.txt
On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Couple of facts first:
a) This code was already merged
b) This code is for a test
c) I'm the only developer so far
Cruft in the codebase is a problem for git *developers* because it makes
the code harder to
On Sat, Dec 15, 2012 at 2:44 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Cruft in the codebase is a problem for git *developers* because it makes
the code harder to maintain and extend.
A problem big
On Sat, Dec 15, 2012 at 10:07:54AM +0700, Nguyen Thai Ngoc Duy wrote:
If get_foo() is not inlined, then when compiling some_fun, gcc sees only
that a pointer to the local variable is passed, and must assume that it
is an out parameter that is initialized after get_foo returns.
However,
Am 14.12.2012 23:09, schrieb Jeff King:
Can anybody think of a clever way to expose the constant return value of
error() to the compiler? We could do it with a macro, but that is also
out for error(), as we do not assume the compiler has variadic macros. I
guess we could hide it behind #ifdef
On Sat, Dec 15, 2012 at 11:49:25AM +0100, Johannes Sixt wrote:
Am 14.12.2012 23:09, schrieb Jeff King:
Can anybody think of a clever way to expose the constant return value of
error() to the compiler? We could do it with a macro, but that is also
out for error(), as we do not assume the
On Friday 14 December 2012 17:11:44 Jeff King wrote:
[...]
We can fix it by returning -1 when no note is found (so on
a zero return, we always found a valid value).
Good fix. Parsing of the note now always fails if the note doesn't contain the
expected string, as it should.
When make is run the python script are created from *.py files that
are changed to use the python given by PYTHON_PATH. And PYTHON_PATH
is set by default to /usr/bin/python on Linux.
This is nice except when you run make another time setting a
different PYTHON_PATH, because, as the python scripts
Mail addresses in documentation are converted into mailto: hyperlinks in
the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is used as an example and is not valid.
Particularly annoying is the example jane@laptop.(none) which appears
in git-shortlog(1)
On Sat, Dec 15, 2012 at 03:03:15PM +, John Keeping wrote:
Mail addresses in documentation are converted into mailto: hyperlinks in
the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is used as an example and is not valid.
Particularly annoying
Christian Couder chrisc...@tuxfamily.org writes:
@@ -2636,6 +2636,18 @@ GIT-GUI-VARS: FORCE
fi
endif
+### Detect Python interpreter path changes
+ifndef NO_PYTHON
+TRACK_VARS = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)')
+
+GIT-PYTHON-VARS: FORCE
+
On Sat, Dec 15, 2012 at 06:09:30AM -0500, Jeff King wrote:
Does
#define error(fmt, ...) (error_impl(fmt, __VA_ARGS__), -1)
cause problems when not used in a return statement?
Thanks, that was the cleverness I was missing.
Here it is as patches. One problem with this method is
When git is compiled with gcc -Wuninitialized -O3, some
inlined calls provide an additional opportunity for the
compiler to do static analysis on variable initialization.
For example, with two functions like this:
int get_foo(int *foo)
{
if (something_that_might_fail() 0)
There are a few error functions that simply wrap error() and
provide a standardized message text. Like error(), they
always return -1; knowing that can help the compiler silence
some false positive -Wuninitialized warnings.
One strategy would be to just declare these as inline in the
header file
The -c and -C options take an existing commit, so let's
complete refs, just as we would for --squash or --fixup.
Signed-off-by: Jeff King p...@peff.net
---
I notice that the existing code just handles the --foo=bar form of most
options. By checking $prev, we can also handle --foo bar form (which
David Michael fedora@gmail.com writes:
On Fri, Dec 14, 2012 at 6:41 PM, Junio C Hamano gits...@pobox.com wrote:
I have this suspicion that nobody would notice if we simply stopped
including the header.
While I'm not aware of any subtleties it could be causing on other
platforms, it does
Jeff King p...@peff.net writes:
I think I'd just render them monospace everywhere. We are very
inconsistent about which form of quotes we use in the documentation (I
think because most of the developers read the source directly and not
the rendered asciidoc). And then we don't have to worry
Manlio Perillo manlio.peri...@gmail.com writes:
Unlike other environment variables (e.g. GIT_WORK_TREE,
GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
environment variable using the command line.
Is this necessary? I'd prefer to see a better reason than just
because others
Currently blame.c::get_acline, pretty.c::pp_user_info() and
shortlog.c::insert_one_record are parsing author name, email, time and
tz themselves.
Use ident.c::split_ident_line for better code reuse.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/blame.c| 59
Remove the hard limit set by mail buffer in map_user and
use the strbuf API to replace it.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
mailmap.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index ea4b471..3bc6491 100644
mailmap.c::map_user() is simplified to take two strbuf parameters
instead of statically allocated buffers.
The buffers are still modified in-place, when mapping is required.
It actually makes things easier for callers:
- Caller must prepare the call by copying author name and email in
strbuf
the mailmap string_list structure filled with mailmap
information is passed along from rev_info to pretty_print_context
to provide mailmap information to pretty print each commits
with the correct username and email.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
commit.h |1 +
Use the mailmap information to display the correct
username and email address in all log commands.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
pretty.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/pretty.c
The new option '--use-mailmap' can be used to make
sure that mailmap file is used to convert name
when running log commands.
The test is simple and checks that the Author line
is correctly replaced when running log.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
t/t4203-mailmap.sh | 14
Add the --use-mailmap option to log commands. It allows
to display names from mailmap file when displaying logs,
whatever the format used.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Documentation/git-log.txt |5 +
builtin/log.c |9 -
2 files changed, 13
Stefano Lattarini stefano.lattar...@gmail.com writes:
And this is clearly stressed by Linus in the COPYING file. So make it
clear in the README as well, to avoid possible misunderstandings.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
I have nothing against this patch,
On Sat, Dec 15, 2012 at 12:20:18PM -0500, Jeff King wrote:
On Sat, Dec 15, 2012 at 03:03:15PM +, John Keeping wrote:
Mail addresses in documentation are converted into mailto: hyperlinks in
the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is
Jeff King p...@peff.net writes:
On Sat, Dec 15, 2012 at 10:23:10AM +0700, Nguyen Thai Ngoc Duy wrote:
On Thu, Dec 13, 2012 at 8:13 PM, Jeff King p...@peff.net wrote:
If you are using --format=%C(red) or similar placeholders,
they are the odd duck by not respecting the auto-color mode.
Junio C Hamano gits...@pobox.com writes:
Stefano Lattarini stefano.lattar...@gmail.com writes:
And this is clearly stressed by Linus in the COPYING file. So make it
clear in the README as well, to avoid possible misunderstandings.
Signed-off-by: Stefano Lattarini
Matt Kraai kr...@ftbfs.org writes:
This series ports Git to QNX. It builds on both QNX 6.3.2 and QNX
6.5.0. The test suite does not pass. Unless the corresponding
software is installed, the following arguments must be passed to Make:
NO_CURL=1 NO_GETTEXT=1 NO_OPENSSL=1 NO_PERL=1
Matt Kraai kr...@ftbfs.org writes:
From: Matt Kraai matt.kr...@amo.abbott.com
lock is only used by fetch_pack, so move it into that function.
Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com
---
fetch-pack.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Eh, did you base
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 15/12/2012 19:02, Junio C Hamano ha scritto:
Manlio Perillo manlio.peri...@gmail.com writes:
Unlike other environment variables (e.g. GIT_WORK_TREE,
GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
environment variable using the
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote:
I said that git reset --keep started out as an ugly workaround for
the lack of git checkout -B $current_branch. Now we have it, so
we can afford to make reset --keep less prominently advertised in
our tool set. As I already said back then,
On 12/15/2012 07:35 PM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Stefano Lattarini stefano.lattar...@gmail.com writes:
And this is clearly stressed by Linus in the COPYING file. So make it
clear in the README as well, to avoid possible misunderstandings.
Hi Junio,
Sorry for being a bit tardy on this; I noticed these test failures
on cygwin close to the start of this cycle, just before I went
into hospital, but have only just got around to looking into it...
In particular, the following tests fail: t0021, t0030, t1410, t3032,
t3304, t3404 and
Since commit 7bc0911d (test-lib: Fix say_color () not to interpret
\a\b\c in the message, 11-10-2012), the --no-color version of
say_color() has been using the (bash builtin) printf function, rather
than echo, to print the testsuite output. Due to an intermittent (and
rare) failure of the printf
The failing tests make use of a POSIX character class, '[:xdigit:]'
in this case, which some versions of the fnmatch() library function
do not support. In the spirit of commit f1cf7b79 (t3070: disable
unreliable fnmatch tests, 15-10-2012), we disable the fnmatch() half
of these tests.
In particular, sparse issues an Using plain integer as NULL pointer
warning (line 214), since an integer zero is passed as the second
actual argument in a strbuf_detach() call. The expected type for
this parameter is 'size_t *'. In order to suppress the warning, we
simply pass a NULL pointer
Junio C Hamano gits...@pobox.com writes:
Matt Kraai kr...@ftbfs.org writes:
From: Matt Kraai matt.kr...@amo.abbott.com
lock is only used by fetch_pack, so move it into that function.
Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com
---
fetch-pack.c | 3 +--
1 file changed, 1
Manlio Perillo manlio.peri...@gmail.com writes:
Il 15/12/2012 19:02, Junio C Hamano ha scritto:
Manlio Perillo manlio.peri...@gmail.com writes:
Unlike other environment variables (e.g. GIT_WORK_TREE,
GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
environment variable using
Stefano Lattarini stefano.lattar...@gmail.com writes:
On 12/15/2012 07:35 PM, Junio C Hamano wrote:
...
-Git is an Open Source project covered by the GNU General Public License.
+Git is an Open Source project covered by the GNU General Public
+License version 2 (some parts of it are under
On 12/15/2012 08:39 PM, Junio C Hamano wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
On 12/15/2012 07:35 PM, Junio C Hamano wrote:
...
-Git is an Open Source project covered by the GNU General Public License.
+Git is an Open Source project covered by the GNU General Public
From: Junio C Hamano gits...@pobox.com
Subject: Re: [PATCH] Makefile: detect when PYTHON_PATH changes
Date: Sat, 15 Dec 2012 09:29:48 -0800
Christian Couder chrisc...@tuxfamily.org writes:
@@ -2636,6 +2636,18 @@ GIT-GUI-VARS: FORCE
fi
endif
+### Detect Python interpreter
Antoine Pelisse apeli...@gmail.com writes:
Implement the feature suggested by Rich Mindwinter and Junio C Hamano
(and following his advices)
Allows git show/log commands to map author and committer
names and emails using the mailmap file.
Updates related to this second series:
- All
A release candidate Git v1.8.1-rc2 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:
0a65a3d203b8d6e320f15abb040e1137e333c967 git-1.8.1.rc2.tar.gz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 15/12/2012 20:36, Junio C Hamano ha scritto:
[...]
Unlike other environment variables (e.g. GIT_WORK_TREE,
GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
environment variable using the command line.
Is this necessary? I'd
On Sat, Dec 15, 2012 at 10:38:30AM -0800, Junio C Hamano wrote:
I do not mind queuing this on 'pu' but do you want to see your
ftbfs.org address in the commit objects, or the other one that you
are not using to interact with us?
Great! I'd prefer to use the amo.abbott.com address in the
This version also fixes the CE_REMOVE bug I mentioned. As a side
effect, the bug fix makes the i-t-a fix cleaner.
Nguyễn Thái Ngọc Duy (4):
cache-tree: remove dead i-t-a code in verify_cache()
cache-tree: replace for loops in update_one with while loops
cache-tree: fix writing cache-tree
This code is added in 331fcb5 (git add --intent-to-add: do not let an
empty blob be committed by accident - 2008-11-28) to forbid committing
when i-t-a entries are present. When we allow that, we forgot to
remove this.
Noticed-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Nguyễn Thái Ngọc
The loops in update_one can be increased in two different ways: step
by one for files and by n for directories. for loop is not
suitable for this as it always steps by one and special handling is
required for directories. Replace them with while loops for clarity.
Signed-off-by: Nguyễn Thái Ngọc
entry_count is used in update_one() for two purposes:
1. to skip through the number of processed entries in in-memory index
2. to record the number of entries this cache-tree covers on disk
Unfortunately when CE_REMOVE is present these numbers are not the same
because CE_REMOVE entries are
Intent-to-add entries used to forbid writing trees so it was not a
problem. After commit 3f6d56d (commit: ignore intent-to-add entries
instead of refusing - 2012-02-07), we can generate trees from an index
with i-t-a entries.
However, the commit forgets to invalidate all paths leading to i-t-a
On Sun, Dec 16, 2012 at 2:19 AM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
The failing tests make use of a POSIX character class, '[:xdigit:]'
in this case, which some versions of the fnmatch() library function
do not support. In the spirit of commit f1cf7b79 (t3070: disable
unreliable
I
Manlio Perillo manlio.peri...@gmail.com writes:
This works with a shell.
I'm using Python to write a custom git command.
I would be very surprised if Python lacked a way to spawn a
subprocess with an environment modified from the current process.
--
To unsubscribe from this list: send the
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..9dcf3c1 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -202,6 +202,15 @@ do
esac
done
+if test -z $GIT_TEST_PRINT
+then
+ GIT_TEST_PRINT=printf %s
+fi
+if test -z
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
entry_count is used in update_one() for two purposes:
1. to skip through the number of processed entries in in-memory index
2. to record the number of entries this cache-tree covers on disk
Unfortunately when CE_REMOVE is present these numbers
57 matches
Mail list logo
