* Re: [PATCH 01/14] Fix non-constant array creation
From: Junio C Hamano @ 2009-08-21 21:04 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <40aa078e0908210641m660b003do6f637535293672ae@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
> How about using alloca instead?
I tend to avoid it; historically, alloca has been a worse portability
nightmare.
^ permalink raw reply
* Re: [PATCH 09/14] Avoid including windows.h in winansi.c for MSVC build
From: Junio C Hamano @ 2009-08-21 21:02 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <74ca14c3a691cc9844a0dd806f5db47977317bdb.1250860247.git.mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
> From: Frank Li <lznuaa@gmail.com>
>
> compat/msvc.h includes winsock2.h which conflicts with windows.h.
> msvc.h also defines the oldest Windows API version required.
The first sentence sort-of makes sense; compat/msvc.h will be included by
git-compat-util.h and including <windows.h> here will bring conflicting
definitions, so we avoid doing so when on MSC.
The second sentence does not make any sense to me. It may be correctly
stating a fact (i.e. "defines required WAPI version"), but it is unclear
what relevance it has to this change to stop including <windows.h>.
Having said that, the first sentence hints me that perhaps you guys should
include (conditionally only on windows but not with MSC) <windows.h> not
from this file, but from git-compat-util.h?
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
> ---
> compat/winansi.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/compat/winansi.c b/compat/winansi.c
> index 9217c24..0d79845 100644
> --- a/compat/winansi.c
> +++ b/compat/winansi.c
> @@ -2,7 +2,9 @@
> * Copyright 2008 Peter Harris <git@peter.is-a-geek.org>
> */
>
> +#ifndef _MSC_VER
> #include <windows.h>
> +#endif
> #include "../git-compat-util.h"
>
> /*
> --
> 1.6.3.msysgit.0.18.gef407
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Junio C Hamano @ 2009-08-21 20:55 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <c899c41fdccfdc94ae294f1a50895ba0290a1ec3.1250860247.git.mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
> From: Frank Li <lznuaa@gmail.com>
>
> The Microsoft C runtime's vsnprintf function does not add NUL at
> the end of the buffer.
This contradicts the way I read the comment in compat/snprintf.c from
f4626df (Add target architecture MinGW., 2007-12-01).
As far as I can see, the correction is about the meaning of the size
parameter to the function, namely, that a broken implementation may
mistakenly think that it was told the maximum length of the meat of the
string to write, and it is allowed to append a NUL beyond the limit, when
the caller actually is telling it the size of the buffer.
So if my reading is correct, it is not about "does not add NUL at the end"
at all; it is "adds NUL beyond the end of given output buffer."
^ permalink raw reply
* Re: [PATCH 01/14] Fix non-constant array creation
From: Junio C Hamano @ 2009-08-21 20:39 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <6283b3e1775f43c6fc07e5047f9c99acdc27bc8f.1250860247.git.mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
> MSVC doesn't munge the non-constant expression, so use xmalloc instead.
Thanks.
These things are called variable length array, and MSVC is not the only
one that do not glok vla.
Subject: Avoid use of variable length array
Some compilers unfortunately do not understand these constructs.
In codepaths that are not performance critical, use xmalloc()
and free() instead.
There is another use of vla; I would suggest squashing the following patch
in.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index c433748..5065abd 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1599,7 +1599,7 @@ static void *threaded_find_deltas(void *arg)
static void ll_find_deltas(struct object_entry **list, unsigned list_size,
int window, int depth, unsigned *processed)
{
- struct thread_params p[delta_search_threads];
+ struct thread_params *p;
int i, ret, active_threads = 0;
if (delta_search_threads <= 1) {
@@ -1610,6 +1610,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
fprintf(stderr, "Delta compression using up to %d threads.\n",
delta_search_threads);
+ p = xcalloc(delta_search_threads, sizeof(*p));
+
/* Partition the work amongst work threads. */
for (i = 0; i < delta_search_threads; i++) {
unsigned sub_size = list_size / (delta_search_threads - i);
@@ -1717,6 +1719,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
active_threads--;
}
}
+
+ free(p);
}
#else
^ permalink raw reply related
* hitting home directory's parent
From: Daniel Convissor @ 2009-08-21 20:05 UTC (permalink / raw)
To: Git Mailing List
Hi:
I just installed git in my Cygwin installation for the first time. The
git version is 1.6.1.2, which is the latest version they have. When I
enter one of the following commands:
git --help
git config --global user.name "Daniel Convissor"
I get this error:
fatal: Cannot change to /home/danielc/..: Permission denied
Though "git --version" executes fine.
I've been using Cygwin for many years and no other program has ever
produced this issue for me. For example, svn --help, ls --help, etc work
just fine.
Why is git venturing into to the home directory's parent directory? Is
this a bug? If not, is this really necessary?
Thanks,
--Dan
PS: I'm not subscribed to the list.
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: git-daemon via launchd
From: Alex Riesen @ 2009-08-21 20:24 UTC (permalink / raw)
To: Andrew Keller; +Cc: Git List
In-Reply-To: <D49DB51B-4D25-44CC-B09C-2598EC7FCEE9@kellerfarm.com>
On Fri, Aug 21, 2009 at 19:40, Andrew Keller<andrew@kellerfarm.com> wrote:
> Is it possible to configure launchd to run git-daemon based on an incoming
> connection, rather than having git-daemon listen for connections?
Yes, see inetd and xinetd examples in Documentation/everyday.txt
^ permalink raw reply
* Re: [PATCH] Add tests for rev-list --graph with options that simplify history
From: Junio C Hamano @ 2009-08-21 20:15 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Git Mailing List
In-Reply-To: <20090821182034.GW8147@facebook.com>
Adam Simpkins <simpkins@facebook.com> writes:
> These tests help make sure graph_is_interesting() is doing the right
> thing.
>
> Signed-off-by: Adam Simpkins <simpkins@facebook.com>
> ---
> t/t6016-rev-list-graph-simplify-history.sh | 276 ++++++++++++++++++++++++++++
> 1 files changed, 276 insertions(+), 0 deletions(-)
> create mode 100755 t/t6016-rev-list-graph-simplify-history.sh
>
> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
> new file mode 100755
> index 0000000..5ac8fc9
> --- /dev/null
> +++ b/t/t6016-rev-list-graph-simplify-history.sh
> @@ -0,0 +1,276 @@
> +#!/bin/sh
> +
> +# There's more than one "correct" way to represent the history graphically.
> +# These tests depend on the current behavior of the graphing code. If the
> +# graphing code is ever changed to draw the output differently, these tests
> +# cases will need to be updated to know about the new layout.
An ideal solution to such a problem would be not to write the tests that
way to require _the exact layout_ of the output.
What was the bug you were trying to fix? Was it that in a simplified
history some arcs are not connected whey they should be?
Can you test that without relying on other aspect (say, commits are marked
with '*' right now but a patch might change it to '^' for some commits) of
the output?
I am just wondering how feasible it is the problem you are trying to
solve, not demanding you to solve it.
^ permalink raw reply
* [PATCH v2 05/14] Change regerror() definition from K&R style to ANSI C (C89)
From: Marius Storm-Olsen @ 2009-08-21 20:10 UTC (permalink / raw)
To: lznuaa; +Cc: msysgit, git, Marius Storm-Olsen
In-Reply-To: <07846e22f50dfd5e1b483a02cf550e5373125f1d.1250860247.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
The MSVC headers typedef errcode as int, and thus confused the
compiler in the K&R style definition. ANSI style deconfuses it.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
Frank, like this one better?
compat/regex/regex.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 5ea0075..67d5c37 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -4852,11 +4852,8 @@ regexec (preg, string, nmatch, pmatch, eflags)
from either regcomp or regexec. We don't use PREG here. */
size_t
-regerror (errcode, preg, errbuf, errbuf_size)
- int errcode;
- const regex_t *preg;
- char *errbuf;
- size_t errbuf_size;
+regerror(int errcode, const regex_t *preg,
+ char *errbuf, size_t errbuf_size)
{
const char *msg;
size_t msg_size;
--
1.6.3.msysgit.0.18.gef407
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Junio C Hamano @ 2009-08-21 20:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Mark A Rada, git
In-Reply-To: <200908212006.16333.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> +cat >>gitweb_config.perl <<EOF
>> +
>> +\$feature{'snapshot'}{'override'} = 0;
>> +EOF
>
> A trick: use '\EOF' and you don't need to escape $ against variable
> expansion by shell.
>
> +cat >>gitweb_config.perl <<\EOF
> +
> +$feature{'snapshot'}{'override'} = 0;
> +EOF
It is not a "trick" but is a basic courtesy for reviewers. Even if you do
not have any $ to worry about, _unless_ you actively know you would want
variable substitution to happen, it is easier for readers if you signal
the fact that the here-doc is verbatim by quoting the \EOF marker upfront.
Same thing for use of single quotes vs double quotes when writing strings,
even though they tend to be small and much less of an issue.
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 01/14] Fix non-constant array creation
From: Johan 't Hart @ 2009-08-21 20:06 UTC (permalink / raw)
To: Janos Laube
Cc: Marius Storm-Olsen, Erik Faye-Lund, Johannes.Schindelin, msysgit,
git, lznuaa
In-Reply-To: <9d6091530908210926p61aa5ea6ya6a7b71f940fdf5a@mail.gmail.com>
Janos Laube schreef:
>> MSVC compiles regex.c, so it must handle it. I'm fine with that.
>
> msvc supports alloca, but regex.c doesn't make use of it per default
> (you must define HAVE_ALLOCA_H in order to use it). basically _alloca
> is fine for that task, but be aware that error handling on windows is
> a bit compilicated. when _alloca fails it throws a structured
> exception, you must reset the stack and use traditional memory
> allocation as fallback. see
> http://msdn.microsoft.com/en-us/library/wb1s57t5.aspx. :-)
>
alloca() throws an exception when out of stack memory. But what would
the dynamically alloced array do when it runs out of memory? (Supposing
that those arrays are also created on the stack, which I don't know...)
Is that realy more complicated?
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 01/14] Fix non-constant array creation
From: Marius Storm-Olsen @ 2009-08-21 19:49 UTC (permalink / raw)
To: Janos Laube; +Cc: Erik Faye-Lund, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <9d6091530908210926p61aa5ea6ya6a7b71f940fdf5a@mail.gmail.com>
Janos Laube said the following on 21.08.2009 18:26:
>> MSVC compiles regex.c, so it must handle it. I'm fine with that.
>
> msvc supports alloca, but regex.c doesn't make use of it per default
> (you must define HAVE_ALLOCA_H in order to use it). basically _alloca
> is fine for that task, but be aware that error handling on windows
> is a bit compilicated. when _alloca fails it throws a structured
> exception, you must reset the stack and use traditional memory
> allocation as fallback. see
> http://msdn.microsoft.com/en-us/library/wb1s57t5.aspx. :-)
I must admit that I didn't look much at the surrounding code to know how
large preimage->nr can get. But assuming variable-length array is
handled the same way by the compiler as alloca(), and this code seems to
be performing fine, I guess it's safe to say that this code won't be
triggering any SEH, and thus we won't need to handle it?
So, given my assumptions I think we can just replace that one line with
alloca(), nuke the free(), and everything is ok.
--
.marius
^ permalink raw reply
* git-daemon via launchd
From: Andrew Keller @ 2009-08-21 17:40 UTC (permalink / raw)
To: Git List
Is it possible to configure launchd to run git-daemon based on an
incoming connection, rather than having git-daemon listen for
connections?
Thanks,
Andrew Keller
^ permalink raw reply
* Re: [msysGit] [PATCH 07/14] Fix __stdcall/WINAPI placement and function prototype
From: Marius Storm-Olsen @ 2009-08-21 19:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, Johannes.Schindelin, git, lznuaa
In-Reply-To: <200908211937.18296.j6t@kdbg.org>
Johannes Sixt said the following on 21.08.2009 19:37:
> On Freitag, 21. August 2009, Marius Storm-Olsen wrote:
>> -static __stdcall unsigned ticktack(void *dummy)
>> +static unsigned WINAPI ticktack(void *dummy)
>
>> -static __stdcall unsigned run_thread(void *data)
>> +static unsigned WINAPI run_thread(void *data)
>
> These two are not nice. As I said in an earlier mail: The
> documentation says that the thread function pointer that is passed to
> _beginthreadex must have __stdcall calling convention. Therefore, you
> should not change these to WINAPI.
WINAPI is just a define for __stdcall (since _MSC_VER >= 800 anyways; VC
6.0 being _MSC_VER == 1200), and won't change.
So, IMO the change is not bad, and makes things less convoluted by using
the same convention all over.
(And _beginthreadex actually accepts both __stdcall and __clrcall
calling conventions.)
--
.marius
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Junio C Hamano @ 2009-08-21 19:36 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git
In-Reply-To: <4A8E6485.7040006@gnu.org>
Paolo Bonzini <bonzini@gnu.org> writes:
> On 08/21/2009 04:48 AM, Junio C Hamano wrote:
>> Has been ejected from 'pu' for some time, expecting a reroll.
>
> I've been trying for a while to have push refspecs and tracking
> working together, but haven't come with anything that I like.
>
> I'll let it sleep for a while so that I can look at the problem again
> with a fresh mind when I come back to it.
Thanks.
^ permalink raw reply
* [PATCH] Add tests for rev-list --graph with options that simplify history
From: Adam Simpkins @ 2009-08-21 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7hwzt94p.fsf@alter.siamese.dyndns.org>
These tests help make sure graph_is_interesting() is doing the right
thing.
---
t/t6016-rev-list-graph-simplify-history.sh | 276 ++++++++++++++++++++++++++++
1 files changed, 276 insertions(+), 0 deletions(-)
create mode 100755 t/t6016-rev-list-graph-simplify-history.sh
diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
new file mode 100755
index 0000000..5ac8fc9
--- /dev/null
+++ b/t/t6016-rev-list-graph-simplify-history.sh
@@ -0,0 +1,276 @@
+#!/bin/sh
+
+# There's more than one "correct" way to represent the history graphically.
+# These tests depend on the current behavior of the graphing code. If the
+# graphing code is ever changed to draw the output differently, these tests
+# cases will need to be updated to know about the new layout.
+
+test_description='--graph and simplified history'
+
+. ./test-lib.sh
+
+test_expect_success 'set up rev-list --graph test' '
+ # 3 commits on branch A
+ test_commit A1 foo.txt &&
+ test_commit A2 bar.txt &&
+ test_commit A3 bar.txt &&
+ git branch -m master A &&
+
+ # 2 commits on branch B, started from A1
+ git checkout -b B A1 &&
+ test_commit B1 foo.txt &&
+ test_commit B2 abc.txt &&
+
+ # 2 commits on branch C, started from A2
+ git checkout -b C A2 &&
+ test_commit C1 xyz.txt &&
+ test_commit C2 xyz.txt &&
+
+ # Octopus merge B and C into branch A
+ git checkout A &&
+ git merge B C &&
+ git tag A4
+
+ test_commit A5 bar.txt &&
+
+ # More commits on C, then merge C into A
+ git checkout C &&
+ test_commit C3 foo.txt &&
+ test_commit C4 bar.txt &&
+ git checkout A &&
+ git merge -s ours C &&
+ git tag A6
+
+ test_commit A7 bar.txt &&
+
+ # Store commit names in variables for later use
+ A1=`git rev-list -1 A1` &&
+ A2=`git rev-list -1 A2` &&
+ A3=`git rev-list -1 A3` &&
+ A4=`git rev-list -1 A4` &&
+ A5=`git rev-list -1 A5` &&
+ A6=`git rev-list -1 A6` &&
+ A7=`git rev-list -1 A7` &&
+ B1=`git rev-list -1 B1` &&
+ B2=`git rev-list -1 B2` &&
+ C1=`git rev-list -1 C1` &&
+ C2=`git rev-list -1 C2` &&
+ C3=`git rev-list -1 C3` &&
+ C4=`git rev-list -1 C4`
+ '
+
+test_expect_success '--graph --all' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "| | " >> expected &&
+ echo "| \\ " >> expected &&
+ echo "*-. \\ $A4" >> expected &&
+ echo "|\\ \\ \\ " >> expected &&
+ echo "| | |/ " >> expected &&
+ echo "| | * $C2" >> expected &&
+ echo "| | * $C1" >> expected &&
+ echo "| * | $B2" >> expected &&
+ echo "| * | $B1" >> expected &&
+ echo "* | | $A3" >> expected &&
+ echo "| |/ " >> expected &&
+ echo "|/| " >> expected &&
+ echo "* | $A2" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --all > actual &&
+ test_cmp expected actual
+ '
+
+# Make sure the graph_is_interesting() code still realizes
+# that undecorated merges are interesting, even with --simplify-by-decoration
+test_expect_success '--graph --simplify-by-decoration' '
+ rm -f expected &&
+ git tag -d A4
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "| | " >> expected &&
+ echo "| \\ " >> expected &&
+ echo "*-. \\ $A4" >> expected &&
+ echo "|\\ \\ \\ " >> expected &&
+ echo "| | |/ " >> expected &&
+ echo "| | * $C2" >> expected &&
+ echo "| | * $C1" >> expected &&
+ echo "| * | $B2" >> expected &&
+ echo "| * | $B1" >> expected &&
+ echo "* | | $A3" >> expected &&
+ echo "| |/ " >> expected &&
+ echo "|/| " >> expected &&
+ echo "* | $A2" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --all --simplify-by-decoration > actual &&
+ test_cmp expected actual
+ '
+
+# Get rid of all decorations on branch B, and graph with it simplified away
+test_expect_success '--graph --simplify-by-decoration prune branch B' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "* | $A4" >> expected &&
+ echo "|\\ \\ " >> expected &&
+ echo "| |/ " >> expected &&
+ echo "| * $C2" >> expected &&
+ echo "| * $C1" >> expected &&
+ echo "* | $A3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --simplify-by-decoration --all > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph --full-history -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "* | $A4" >> expected &&
+ echo "|\\ \\ " >> expected &&
+ echo "| |/ " >> expected &&
+ echo "* | $A3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ git rev-list --graph --full-history --all -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "* | $A3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ git rev-list --graph --full-history --simplify-merges --all \
+ -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A3" >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ git rev-list --graph --all -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph --sparse -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A4" >> expected &&
+ echo "* $A3" >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "| * $C2" >> expected &&
+ echo "| * $C1" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --sparse --all -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph ^C4' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A4" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $B2" >> expected &&
+ echo "| * $B1" >> expected &&
+ echo "* $A3" >> expected &&
+ git rev-list --graph --all ^C4 > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph ^C3' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A4" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $B2" >> expected &&
+ echo "| * $B1" >> expected &&
+ echo "* $A3" >> expected &&
+ git rev-list --graph --all ^C3 > actual &&
+ test_cmp expected actual
+ '
+
+# I don't think the ordering of the boundary commits is really
+# that important, but this test depends on it. If the ordering ever changes
+# in the code, we'll need to update this test.
+test_expect_success '--graph --boundary ^C3' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "| | " >> expected &&
+ echo "| \\ " >> expected &&
+ echo "*-. \\ $A4" >> expected &&
+ echo "|\\ \\ \\ " >> expected &&
+ echo "| * | | $B2" >> expected &&
+ echo "| * | | $B1" >> expected &&
+ echo "* | | | $A3" >> expected &&
+ echo "o | | | $A2" >> expected &&
+ echo "|/ / / " >> expected &&
+ echo "o | | $A1" >> expected &&
+ echo " / / " >> expected &&
+ echo "| o $C3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "o $C2" >> expected &&
+ git rev-list --graph --boundary --all ^C3 > actual &&
+ test_cmp expected actual
+ '
+
+test_done
--
1.6.0.4
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Jakub Narebski @ 2009-08-21 18:06 UTC (permalink / raw)
To: Mark A Rada; +Cc: git, Junio Hamano
In-Reply-To: <F4C7A2F3-B030-449A-87AC-B54CA2B647B4@mailservices.uwaterloo.ca>
On Fri, 21 Aug 2009, Mark A Rada wrote:
> On 20-Aug-09, at 10:48 PM, Junio C Hamano wrote:
>
> > Should graduate to 'master' soon.
> >
> > * mr/gitweb-xz (2009-08-06) 3 commits
> > (merged to 'next' on 2009-08-14 at b63b8e6)
> > + gitweb: add support for XZ compressed snapshots
> > + gitweb: update INSTALL regarding specific snapshot settings
> > + gitweb: support to globally disable a snapshot format
> >
>
>
> I never submitted any tests for the patch that adds global snapshot
> disabling functionality to gitweb.
>
> Jakub, I changed the gitweb_run routine to capture STDOUT as well,
> is that ok?
I think it is a good addition to the gitweb tests in git testsuite,
as it might make finding cause of an error easier.
> Unless I missed a case, the tests show that the extra condition check
> that was added in the git_snapshot() routine is never actually
> executed, because a disabled snapshot format is not added to
> @snapshot_fmts, which is checked first.
>
> snippet:
> 5178 } elsif (!grep($_ eq $format, @snapshot_fmts)) {
> 5179 die_error(403, "Unsupported snapshot format");
> 5180 } elsif ($known_snapshot_formats{$format}{'disabled'}) {
> 5181 die_error(403, "Snapshot format not allowed");
> 5182 }
> 5183
So we did check if format is disable twice, once when creating
(generating @snapshot_fmts list, and once (I guess unnecessary;
@snapshot_fmts is generated after reading GITWEB_CONFIG file(s))
when checking if snapshot $format is on the list of possible
(allowed) formats in the snipped above.
Am I right? If it is so, the last part of above snipped wouldn't
be ever exercised, and is not necessary.
> ---
> t/t9500-gitweb-standalone-no-errors.sh | 67 +++++++++++++++++++++++
> ++++++++-
Word-wrapped.
> 1 files changed, 66 insertions(+), 1 deletions(-)
>
> diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-
> standalone-no-errors.sh
> index 6275181..9ce9667 100755
> --- a/t/t9500-gitweb-standalone-no-errors.sh
> +++ b/t/t9500-gitweb-standalone-no-errors.sh
> @@ -57,10 +57,11 @@ gitweb_run () {
> # we are interested only in properly formatted errors/warnings
> rm -f gitweb.log &&
> perl -- "$SCRIPT_NAME" \
> - >/dev/null 2>gitweb.log &&
> + >gitweb.output 2>gitweb.log &&
> if grep "^[[]" gitweb.log >/dev/null 2>&1; then false; else true; fi
>
> # gitweb.log is left for debugging
> + # gitweb.output is used to parse output
> }
This is a good change.
>
> . ./test-lib.sh
> @@ -704,4 +705,68 @@ test_expect_success \
> gitweb_run "p=.git;a=summary"'
> test_debug 'cat gitweb.log'
>
> +
> +#
> ----------------------------------------------------------------------
> +# snapshot settings
> +
> +cat >>gitweb_config.perl <<EOF
> +
> +\$feature{'snapshot'}{'override'} = 0;
> +EOF
A trick: use '\EOF' and you don't need to escape $ against variable
expansion by shell.
+cat >>gitweb_config.perl <<\EOF
+
+$feature{'snapshot'}{'override'} = 0;
+EOF
> +
> +test_expect_success \
> + 'snapshots: tgz only default format enabled' \
> + 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
> + grep "Status: 200 OK" gitweb.output &&
> + gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tbz2" &&
> + grep "403 - Unsupported snapshot format" gitweb.output &&
> + gitweb_run "p=.git;a=snapshot;h=HEAD;sf=txz" &&
> + grep "403 - Unsupported snapshot format" gitweb.output &&
> + gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
> + grep "403 - Unsupported snapshot format" gitweb.output'
> +test_debug 'cat gitweb.output'
I would prefer (but I do not require) that such test were placed in
separate file, named e.g. t9501-gitweb-check-http-status.sh, and leave
t9500-gitweb-standalone-no-errors.sh to be about checking for Perl
errors and warnings only. This would require to extract common
infrastructure (gitweb_init, gitweb_run, checking prerequisites)
into t/lib-gitweb.sh (or t/gitweb-lib.sh ;-)).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 0/6 RFC] Series to correct xutils incomplete line handling.
From: Thell Fowler @ 2009-08-21 17:39 UTC (permalink / raw)
To: Thell Fowler; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.2.00.0908191713070.2012@GWPortableVCS>
Thell Fowler (git@tbfowler.name) wrote on Aug 19, 2009:
> t/t4015-diff-trailing-whitespace.sh | 95 +++++++++++++++++++++++++++++++++++
> t/t4015-diff-whitespace.sh | 33 ++++++++++++
> xdiff/xutils.c | 20 ++++----
> 3 files changed, 138 insertions(+), 10 deletions(-)
> create mode 100755 t/t4015-diff-trailing-whitespace.sh
Don't bother trying this series. I tried it out on live data today and it
does not work. It actually caused regression in the diffs for the
conversion project I'm working on.
What is _REALLY_ odd is that it didn't make any tests fail in the test
dir using master, next, and pu.
Perhaps someone can explain what I did wrong when testing?
git checkout master
make -s clean && make -s all && make -s install && cd t && make
I really did do over 9 hours of testing using the test dir. First with
just the branches with no modification, then with the modified
t4015-diff-whitespace.sh, then with the xutils.c patch. And this was on
each branch at about 40 minutes per run through.
--
Thell
^ permalink raw reply
* Re: [msysGit] [PATCH 07/14] Fix __stdcall/WINAPI placement and function prototype
From: Johannes Sixt @ 2009-08-21 17:37 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: msysgit, Johannes.Schindelin, git, lznuaa
In-Reply-To: <9e8fc158b4d4331d698d1fe4ed33a61fbb011412.1250860247.git.mstormo@gmail.com>
On Freitag, 21. August 2009, Marius Storm-Olsen wrote:
> -static __stdcall unsigned ticktack(void *dummy)
> +static unsigned WINAPI ticktack(void *dummy)
> -static __stdcall unsigned run_thread(void *data)
> +static unsigned WINAPI run_thread(void *data)
These two are not nice. As I said in an earlier mail: The documentation says
that the thread function pointer that is passed to _beginthreadex must have
__stdcall calling convention. Therefore, you should not change these to
WINAPI.
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH v4 04/19] Teach Git to respect skip-worktree bit (reading part)
From: Junio C Hamano @ 2009-08-21 17:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0908210219h1c2a4702i81661ced00f39232@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2009/8/20 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>> grep: turn on --cached for files that is marked skip-worktree
>> ls-files: do not check for deleted file that is marked skip-worktree
>> update-index: ignore update request if it's skip-worktree, while still allows removing
>> diff*: skip worktree version
>
> I kept reminding myself and still managed to miss it. skip-worktree
> bit is not completely independent from assume-unchanged. It shares
> CE_MATCH_IGNORE_VALID flag in ie_match_stat(). Should have mentioned
> that in commit log.
Yeah, that is why I feel uneasy reading your response to my other message:
This series does not fix assume-unchanged bit. I'd like to focus on
skip-worktree bit now. ... I don't know if I understand assume-unchanged
semantics correctly anymore :-)
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 01/14] Fix non-constant array creation
From: Janos Laube @ 2009-08-21 16:26 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Erik Faye-Lund, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <4A8EA53B.9080809@gmail.com>
> MSVC compiles regex.c, so it must handle it. I'm fine with that.
msvc supports alloca, but regex.c doesn't make use of it per default
(you must define HAVE_ALLOCA_H in order to use it). basically _alloca
is fine for that task, but be aware that error handling on windows is
a bit compilicated. when _alloca fails it throws a structured
exception, you must reset the stack and use traditional memory
allocation as fallback. see
http://msdn.microsoft.com/en-us/library/wb1s57t5.aspx. :-)
janos
^ permalink raw reply
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Santi Béjar @ 2009-08-21 15:39 UTC (permalink / raw)
To: Adam Simpkins, Git Mailing List, Junio C Hamano
In-Reply-To: <20090819023433.GP8147@facebook.com>
On Wed, Aug 19, 2009 at 4:34 AM, Adam Simpkins<simpkins@facebook.com> wrote:
> Previously, graph_is_interesting() did not behave quite the same way as
> the code in get_revision(). As a result, it would sometimes think
> commits were uninteresting, even though get_revision() would return
> them. This resulted in incorrect lines in the graph output.
>
> This change creates a get_commit_action() function, which
> graph_is_interesting() and simplify_commit() both now use to determine
> if a commit will be shown. It is identical to the old simplify_commit()
> behavior, except that it never calls rewrite_parents().
>
> This problem was reported by Santi Béjar. The following command
> would exhibit the problem before, but now works correctly:
>
> git log --graph --simplify-by-decoration --oneline v1.6.3.3
>
> Previously git graph did not display the output for this command
> correctly between f29ac4f and 66996ec, among other places.
Thanks, the fix works (no comments about the code, only the behavior).
One more thing Junio. In 99af022 (graph API: fix bug in
graph_is_interesting(), 2009-08-18) in 'pu' my name is mispelled, it
seems it was interpreted as latin1, then recoded as UTF8, interpreted
as latin and recoded to latin1, or in other words the é is 4 bytes
instead of two. I've checked this mail and it is latin1, correctly
specified in the headers.
Thanks,
Santi
^ permalink raw reply
* Re: how to do "git merge --abort"
From: Jeff King @ 2009-08-21 15:37 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200908211726.21593.trast@student.ethz.ch>
On Fri, Aug 21, 2009 at 05:26:19PM +0200, Thomas Rast wrote:
> > It is spelled "git reset --merge" (though --merge was introduced in
> > v1.6.1; prior to that, you had to use "git reset --hard").
>
> Umm, no, you still have to use "git reset --hard".
Ah, sorry, you are right. I have never actually used "--merge", but I
knew based on this thread:
http://article.gmane.org/gmane.comp.version-control.git/102067
that the point was to carry dirty state across a reset. So I assumed you
could use it to reset a failed merge while leaving dirty state in files
unrelated to the merge. But it doesn't actually handle unmerged entries
at all.
Thanks for correcting me.
The downside, of course, of "git reset --hard" is that it kills off any
dirty state you may have wanted to keep.
-Peff
^ permalink raw reply
* Re: how to do "git merge --abort"
From: Thomas Rast @ 2009-08-21 15:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090821151926.GE6850@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Aug 21, 2009 at 10:51:57PM +0800, bill lam wrote:
>
> > How to abort a merge if it said there are conflicts but I do not want
> > to (or can not) resolve it for the moment. I can not find the --abort
> > option as that for git-rebase.
>
> It is spelled "git reset --merge" (though --merge was introduced in
> v1.6.1; prior to that, you had to use "git reset --hard").
Umm, no, you still have to use "git reset --hard".
"git reset --merge cmt" is a rough equivalent for
git stash
git reset --hard cmt
git stash pop
and fills the case where you merged with (unrelated) unstaged changes,
and want to discard the merge while keeping the changes.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: how to do "git merge --abort"
From: Jeff King @ 2009-08-21 15:19 UTC (permalink / raw)
To: git
In-Reply-To: <20090821145157.GA6471@debian.b2j>
On Fri, Aug 21, 2009 at 10:51:57PM +0800, bill lam wrote:
> How to abort a merge if it said there are conflicts but I do not want
> to (or can not) resolve it for the moment. I can not find the --abort
> option as that for git-rebase.
It is spelled "git reset --merge" (though --merge was introduced in
v1.6.1; prior to that, you had to use "git reset --hard").
I don't know if it is worth adding "git merge --abort" as syntactic
sugar.
-Peff
^ permalink raw reply
* Re: [PATCH 05/14] Change regerror() declaration from K&R style to ANSI C (C89)
From: Marius Storm-Olsen @ 2009-08-21 14:54 UTC (permalink / raw)
To: Frank Li; +Cc: Johannes.Schindelin, msysgit, git
From: Frank Li <lznuaa@gmail.com>
> size_t
> -regerror (errcode, preg, errbuf, errbuf_size)
> - int errcode;
> - const regex_t *preg;
> - char *errbuf;
> - size_t errbuf_size;
> +regerror(int errcode, const regex_t *preg,
> + char *errbuf, size_t errbuf_size)
> {
>
> The true reason is MSVC type define errcode as int.
Ok, will reword it.. Thanks.
--
.marius @ phone
^ 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