On Sat, Dec 15, 2012 at 1:09 AM, Michael Haggerty wrote:
> On 12/15/2012 04:14 AM, Felipe Contreras wrote:
>> I'm going to say it one last time; merging this patch series either
>> creates issues for the users, or not. There is a reality out there,
>> independent of what you, Junio, or me think or
On 12/15/2012 04:14 AM, Felipe Contreras wrote:
> I'm going to say it one last time; merging this patch series either
> creates issues for the users, or not. There is a reality out there,
> independent of what you, Junio, or me think or say. And the fact is,
> that if this patch series is going to
Hi,
I have a directory of files that have been copied between different
machines, and then drifted apart.
I was trying to merge the different versions into a single unified
repository.
I succeeded, but I had to navigate though, and recover from, what seems
to me to be counter-intuitive be
On Thu, Dec 13, 2012 at 8:13 PM, Jeff King wrote:
> If you are using --format="%C(red)" or similar placeholders,
> they are the odd duck by not respecting the auto-color mode.
But they should, shouldn't they? Just asking. I may do it to when I
revive nd/pretty-placeholder-with-color-option.
--
D
On Fri, Dec 14, 2012 at 7:11 AM, Max Horn wrote:
> please stop referring to "facts" and "obvious". You pretend to be a being of
> pure reason and that everything you say is logical, drawn from facts. But you
> forget or perhaps do not know that logic by itself proofs nothing, it all
> depends
On Sat, Dec 15, 2012 at 5:09 AM, Jeff King wrote:
> I always compile git with "gcc -Wall -Werror", because it catches a lot
> of dubious constructs, and we usually keep the code warning-free.
> However, I also typically compile with "-O0" because I end up debugging
> a fair bit.
>
> Sometimes, tho
On Thu, Dec 13, 2012 at 9:04 AM, Junio C Hamano wrote:
>> @@ -324,7 +325,14 @@ static int update_one(struct cache_tree *it,
>> if (!sub)
>> die("cache-tree.c: '%.*s' in '%s' not found",
>> entlen, path + baselen,
Hi,
On Fri, Dec 14, 2012 at 6:41 PM, Junio C Hamano 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 seem fine to drop sys/param.h on my test GNU/Linux
system
David Michael writes:
> An option is added to the Makefile to skip the inclusion of sys/param.h.
> The only known platform with this condition thus far is the z/OS UNIX System
> Services environment.
>
> Signed-off-by: David Michael
> ---
Hmm, makes me wonder if we can remove that inclusion eve
Johannes Sixt writes:
> Am 14.12.2012 20:57, schrieb David Michael:
>> This platform previously included strings.h automatically. However, the
>> build system now requires an explicit option to do so.
>>
>> Signed-off-by: David Michael
>> ---
>> Makefile | 1 +
>> 1 file changed, 1 insertion(
Am 14.12.2012 23:46, schrieb Joachim Schmitz:
> Johannes Sixt wrote:
>> Am 14.12.2012 20:57, schrieb David Michael:
>>> This platform previously included strings.h automatically. However,
>>> the build system now requires an explicit option to do so.
>>>
>>> Signed-off-by: David Michael
>>> ---
>
* Javier Domingo [121214 13:20]:
> I think the idea of being preferable to have a blank line at the end
> of the added/deleted block is key in this case.
For symmetry I'd suggest to make it preferable to have blank lines
at the end or the beginning.
{
old
+ }
+
+ {
+ new
}
vs
{
old
Johannes Sixt wrote:
Am 14.12.2012 20:57, schrieb David Michael:
This platform previously included strings.h automatically. However,
the build system now requires an explicit option to do so.
Signed-off-by: David Michael
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefi
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)
The error() function reports an error message to stderr and
returns -1. That makes it handy for returning errors from
functions with a single-line:
return error("something went wrong", ...);
In this case, we know something that the compiler does not,
namely that this is equivalent to:
error(
In remote-test-svn, there is a parse_rev_note function to
parse lines of the form "Revision-number" from notes. If it
finds such a line and parses it, it returns 0, copying the
value into a "struct rev_note". If it finds an entry that is
garbled or out of range, it returns -1 to signal an error.
H
I always compile git with "gcc -Wall -Werror", because it catches a lot
of dubious constructs, and we usually keep the code warning-free.
However, I also typically compile with "-O0" because I end up debugging
a fair bit.
Sometimes, though, I compile with -O3, which yields a bunch of new
"variable
Am 14.12.2012 20:57, schrieb David Michael:
> This platform previously included strings.h automatically. However, the
> build system now requires an explicit option to do so.
>
> Signed-off-by: David Michael
> ---
> Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/M
The header strings.h was formerly only included for a particular platform to
define strcasecmp, but another platform requiring this inclusion has been
found. The build system will now include the file based on its presence
determined by configure.
Signed-off-by: David Michael
---
Makefile
This platform previously included strings.h automatically. However, the
build system now requires an explicit option to do so.
Signed-off-by: David Michael
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index fb78f7f..e84b0cb 100644
--- a/Makefile
+++ b/Mak
NO_GECOS_IN_PWENT was documented with other Makefile variables but was only
enforced by manually defining it to the C preprocessor. This adds support
for detecting the condition with configure and defining the make variable.
Signed-off-by: David Michael
---
Makefile | 3 +++
configure.ac |
An option is added to the Makefile to skip the inclusion of sys/param.h.
The only known platform with this condition thus far is the z/OS UNIX System
Services environment.
Signed-off-by: David Michael
---
Makefile | 5 +
configure.ac | 6 ++
git-compat-util.h | 2 ++
3 file
Hi,
On Fri, Dec 14, 2012 at 2:54 AM, Joachim Schmitz
wrote:
> For what's it worth: I ACK your HP-NonStop patch (as you can see by my
> comment in git-compat-util.h I was thinking along the same line)
> https://github.com/dm0-/git/commit/933d72a5cfdc63fa9c3c68afa2f4899d9c3f791e
> together with its
From: Matt Kraai
lock is only used by fetch_pack, so move it into that function.
Signed-off-by: Matt Kraai
---
fetch-pack.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 099ff4d..9d9762d 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -
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 NO_PYTHON=1 NO_TCLTK=1
[1/2]: Make lock local
From: Matt Kraai
Signed-off-by: Matt Kraai
---
Makefile | 19 +++
git-compat-util.h | 8 ++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 736ecd4..ed2539d 100644
--- a/Makefile
+++ b/Makefile
@@ -78,6 +78,8 @@ all::
#
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 12/12/2012 20:35, Junio C Hamano ha scritto:
> Manlio Perillo writes:
>
>> The Documentation/git.txt file, in the GIT_DIR environment variable
>> section, did not mentioned that this value can also be set using the
>> --git-dir command line option
FYI: It was all down to unexpected dos formatting of one of the files.
Here's how i sorted out my unwanted ^M line endings in case anyone
stumbles on this thread with the same issue i had. (reposted from
http://stackoverflow.com/questions/13799631/why-is-m-being-added-to-a-script-r-after-modifyi
Felipe,
please stop referring to "facts" and "obvious". You pretend to be a being of
pure reason and that everything you say is logical, drawn from facts. But you
forget or perhaps do not know that logic by itself proofs nothing, it all
depends on the axioms you impose. And yours are quite diff
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.
Add a new --index-file command-line option.
Update the t7500-commit test to include --index-file option coverage.
The tests have been
30 matches
Mail list logo
