Jeff King wrote:
> I wonder if simply sticking
> the reflog entries into a big GRAVEYARD reflog wouldn't be a great deal
> simpler and accomplish the "keep deleted reflogs" goal, which is what
> people actually want.
Exactly what I was thinking when I read your proposal. What is the
point of havi
On Mon, May 27, 2013 at 9:14 AM, Antoine Pelisse wrote:
> On Sun, May 26, 2013 at 10:35 PM, Johannes Sixt wrote:
>> I'm thinking of diffs of files with CRLF
>
> Good you did, because I didn't ;-)
>
>> line breaks, where the CR would count as whitespace in the line, I think.
>
> With the current i
On Sat, Jun 01, 2013 at 01:29:07PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > I wonder if simply sticking
> > the reflog entries into a big GRAVEYARD reflog wouldn't be a great deal
> > simpler and accomplish the "keep deleted reflogs" goal, which is what
> > people actually want.
>
On Thu, May 30, 2013 at 7:58 PM, Thomas Rast wrote:
> Felipe Contreras writes:
>
>> On Thu, May 30, 2013 at 7:17 AM, Thomas Rast wrote:
> diff --git i/t/t7501-commit.sh w/t/t7501-commit.sh
> index 195e747..1608254 100755
> --- i/t/t7501-commit.sh
> +++ w/t/t7501-commit.sh
> @@ -524,4 +524,16 @@
The test cases include many corner-cases of merge-recursive's behavior,
some of them involve type changes and symbolic links. All cases, including
those that are protected by SYMLINKS check only whether the result of
merge-recursive is correctly stored in the database and the index; the
file system
This undoes the special casing introduced in this test by 704a3143
(Use prerequisite tags to skip tests that depend on symbolic links,
2009-03-04).
Signed-off-by: Johannes Sixt
---
t/t3100-ls-tree-restrict.sh | 42 +++---
1 file changed, 15 insertions(+), 27 d
MinGW's bash does not recognize an exit code -1 as failure. See also
47e3de0e (MinGW: truncate exit()'s argument to lowest 8 bits) and 2488df84
(builtin run_command: do not exit with -1). Exit code 1 is good enough.
Signed-off-by: Johannes Sixt
---
test-chmtime.c | 8
1 file changed, 4
Many tests that involve symbolic links actually check only whether our
algorithms are correct by investigating the contents of the object
database and the index. Only some of them check the filesystem.
This series introduces a function test_ln_s_add that inserts a symbolic
link in the index even i
In particular, move all test preparations inside test_expect_success.
In a subsequent patch, we are going to move test case path3 out of the
loop of test cases. Use this opportunity to linearize the tests.
Signed-off-by: Johannes Sixt
---
t/t2100-update-cache-badpath.sh | 81 +++
Add new functions that create symbolic links and add them to the index to
be used in cases where a symbolic link is not required on the file system.
We will use them to remove many SYMLINKS prerequisites from test cases.
Signed-off-by: Johannes Sixt
---
t/README| 17 +
In t4023 and t4114, we have to remove the entries using 'git rm' because
otherwise the entries that must turn from symbolic links to regular files
would stay symbolic links in the index. For the same reason, we have to
use 'git mv' instead of plain 'mv' in t3509.
Signed-off-by: Johannes Sixt
---
There are many instances where the treatment of symbolic links in the
object model and the algorithms are tested, but where it is not
necessary to actually have a symbolic link in the worktree. Make
adjustments to the tests and remove the SYMLINKS prerequisite when
appropriate in trivial cases, whe
One converted case expects 'git update-index' to fail. We cannot use
'test_must_fail test_ln_s_add ...', because that would mistakenly pass
if a command other than the final git-update-index of test_ln_s_add
failed. Hence, use test_ln_s to create the symbolic link and keep
the explicit 'test_must_f
In particular:
- move test preparations inside test_expect_success
- place test description on the test_expect_success line
- indent with a tab
Signed-off-by: Johannes Sixt
---
t/t3010-ls-files-killed-modified.sh | 123 ++--
1 file changed, 61 insertions(+), 62
t-basic hard-codes many object IDs. To cater to file systems that do
not support symbolic links, different IDs are used depending on the
SYMLINKS prerequisite. But we can observe the symbolic links are only
needed to generate index entries. Use test_ln_s_add to generate the
index entries and ge
All tests in t6035 are protected by SYMLINKS. But that is not necessary,
because a lot of the functionality can be tested provided symbolic link
entries enter the index and object data base. Use test_ln_s_add for this
purpose.
Some test cases do test the presence of symbolic links on the file syst
Jeff King wrote:
> Why don't the branch names have significance? If I deleted branch "foo"
> yesterday evening, wouldn't I want to be able to say "show me foo from
> 2pm yesterday" or even "show me all logs for foo, so that I can pick the
> useful bit from the list"?
Oh, I misunderstood then. I d
On Thu, May 30, 2013 at 3:32 AM, Karsten Blees wrote:
> As of 95c6f271 "dir.c: unify is_excluded and is_path_excluded APIs", the
> is_excluded API no longer recurses into directories that match an ignore
> pattern, and returns the directory's ignored state for all contained paths.
>
> This is OK f
There are some index handling subtleties in 'commit --only' that are
best tested when we have an existing index, but an unborn or empty
HEAD. These circumstances are easily produced by 'checkout --orphan',
but we did not previously have a test for it.
The main expected failure mode would be: erro
Hello,
Regarding the git-fetch man page (IIUC, in pull-fetch-param.txt), in
particular the explanation, I feel that two facts are missing:
- A '*' can be used both in src and dest, and it matches any name,
including subdirectories, but not partial names (i.e. refs/heads/foo*
is invalid).
- m
Johannes Sixt wrote:
> +test_ln_s_add () {
> + if test_have_prereq SYMLINKS
> + then
> + ln -s "$1" "$2" &&
> + git update-index --add "$2"
> + else
> + printf '%s' "$1" >"$2" &&
> + ln_s_obj=$(git hash-object -w "$2") &&
> +
Nicolas Richard wrote:
> - A '*' can be used both in src and dest, and it matches any name,
> including subdirectories, but not partial names (i.e. refs/heads/foo*
> is invalid).
> - multiple fetch lines can be given in .git/config, each of them will be
> obeyed
>
> These are probably obvious
Nobody is checking for specific error codes; it's the errno that's
important.
Signed-off-by: Felipe Contreras
---
run-command.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/run-command.c b/run-command.c
index 1b32a12..e54e943 100644
--- a/run-command.c
+++
On Wed, May 29, 2013 at 2:44 AM, SZEDER Gábor wrote:
> On Tue, May 28, 2013 at 10:20:48PM -0500, Felipe Contreras wrote:
>> It's _very_ slow in many cases, and there's really no point in fetching
>> *everything* from the remote just for completion. In many cases it might
>> be faster for the user
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
wrote:
> Nobody is checking for specific error codes; it's the errno that's
> important.
Have you just disregarded the in-code comment you just removed with
one statement? Did you check all its callers?
>
> Signed-off-by: Felipe Contreras
> ---
>
On Fri, May 17, 2013 at 9:18 PM, Felipe Contreras
wrote:
> When the user has an upstream branch configured to track a remote
> tracking branch:
>
> % git checkout --set-upstream-to github/master
>
> Doing a 'git fetch' without any arguments would try to fetch 'github',
> because it's configured
On Sat, Jun 1, 2013 at 9:03 AM, Duy Nguyen wrote:
> On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
> wrote:
>> Nobody is checking for specific error codes; it's the errno that's
>> important.
>
> Have you just disregarded the in-code comment you just removed with
> one statement?
Who cares abo
On Sat, Jun 1, 2013 at 9:06 PM, Felipe Contreras
wrote:
> On Sat, Jun 1, 2013 at 9:03 AM, Duy Nguyen wrote:
>> On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
>> wrote:
>>> Nobody is checking for specific error codes; it's the errno that's
>>> important.
>>
>> Have you just disregarded the in-c
Felipe Contreras writes:
> Nobody is checking for specific error codes; it's the errno that's
> important.
[...]
> - /*
> - * This return value is chosen so that code & 0xff
> - * mimics the exit code that a POSIX shell would report for
> - * a p
On Sat, Jun 1, 2013 at 9:08 AM, Duy Nguyen wrote:
> On Sat, Jun 1, 2013 at 9:06 PM, Felipe Contreras
> wrote:
>> On Sat, Jun 1, 2013 at 9:03 AM, Duy Nguyen wrote:
>>> On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
>>> wrote:
Nobody is checking for specific error codes; it's the errno tha
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
wrote:
> Nobody is checking for specific error codes; it's the errno that's
> important.
>
> Signed-off-by: Felipe Contreras
> ---
> run-command.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/run-command
On Sat, Jun 1, 2013 at 9:19 AM, Thomas Rast wrote:
> Felipe Contreras writes:
>
>> Nobody is checking for specific error codes; it's the errno that's
>> important.
> [...]
>> - /*
>> - * This return value is chosen so that code & 0xff
>> - * mimics the exit c
On Sat, Jun 1, 2013 at 9:21 AM, Duy Nguyen wrote:
> On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
> wrote:
>> Nobody is checking for specific error codes; it's the errno that's
>> important.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> run-command.c | 14 ++
>> 1 file changed,
On Sat, Jun 1, 2013 at 9:30 PM, Felipe Contreras
wrote:
> On Sat, Jun 1, 2013 at 9:21 AM, Duy Nguyen wrote:
>> On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
>> wrote:
> Yeah, and last year we returned a different code. The world didn't
> end, because nobody is checking for the specific code.
On Sat, Jun 1, 2013 at 9:36 AM, Duy Nguyen wrote:
> On Sat, Jun 1, 2013 at 9:30 PM, Felipe Contreras
> wrote:
>> On Sat, Jun 1, 2013 at 9:21 AM, Duy Nguyen wrote:
>>> On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
>>> wrote:
>> Yeah, and last year we returned a different code. The world didn'
Am 01.06.2013 13:11, schrieb Ramkumar Ramachandra:
> Johannes Sixt wrote:
>> +test_ln_s () {
>> + if test_have_prereq SYMLINKS
>> + then
>> + ln -s "$1" "$2"
>> + else
>> + printf '%s' "$1" >"$2"
>> + fi
>> +}
>
> What is this? We can't test_ln_
On Sat, Jun 01, 2013 at 09:30:50AM -0500, Felipe Contreras wrote:
> > The original commit that introduces this says
> >
> > run_command: encode deadly signal number in the return value
> >
> > We now write the signal number in the error message if the program
> > terminated by a signal
Johannes Sixt wrote:
> # - Use test_ln_s instead of "ln -s x y" when y has been added as a
> # symbolic link entry earlier.
Ah, sorry I skipped over the comments.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
On Sat, Jun 01, 2013 at 10:01:49AM -0500, Felipe Contreras wrote:
> Anyway, if you care so much about the current behavior, why isn't
> there any tests that check for this?
>
> My patch passes *all* the tests.
The test suite has never been (and probably never will be) a complete
specification of
On Sat, Jun 1, 2013 at 3:17 PM, Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> Why don't the branch names have significance? If I deleted branch "foo"
>> yesterday evening, wouldn't I want to be able to say "show me foo from
>> 2pm yesterday" or even "show me all logs for foo, so that I can pic
Sparse issues an "'object_array_slopbuf' not declared. Should it be
static?" warning. In order to suppress the warning, since this
symbol does not need more than file visibility, we simply add the
static modifier to its declaration.
Signed-off-by: Ramsay Jones
---
Hi Michael,
If you need to re
Sitaram Chamarty wrote:
> I think I'd have to be playing with *several* branches simultaneously
> before I got to the point of forgetting the branch name!
Yeah, I work on lots of small unrelated things: the patch-series I
send in are usually the result of few hours of work (upto a few days).
I ke
Felipe Contreras wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 1c35eef..2ce4f7d 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -427,14 +427,8 @@ __git_refs ()
>
On Sat, Jun 1, 2013 at 12:01 PM, Jeff King wrote:
> On Sat, Jun 01, 2013 at 09:30:50AM -0500, Felipe Contreras wrote:
>> commit 709ca730f8e093005cc882bfb86c0ca9c83d345b
>> Author: Jeff King
>> Date: Sat Jan 5 09:49:49 2013 -0500
>>
>> run-command: encode signal death as a positive integer
---
> The reason is that this check is incomplete:
>
>test_revision_subjects 'd i e u' HEAD~2 HEAD^2 HEAD^ HEAD
Nice catch! This should fix it. I couldn't use the method you
suggested because of how test_revision_subjects works (repeated
revisions are ignored), but this makes the check strict
On Sat, Jun 1, 2013 at 12:24 PM, Jeff King wrote:
> On Sat, Jun 01, 2013 at 10:01:49AM -0500, Felipe Contreras wrote:
>
>> Anyway, if you care so much about the current behavior, why isn't
>> there any tests that check for this?
>>
>> My patch passes *all* the tests.
>
> The test suite has never b
On 06/01/2013 07:46 PM, Ramsay Jones wrote:
>
> Sparse issues an "'object_array_slopbuf' not declared. Should it be
> static?" warning. In order to suppress the warning, since this
> symbol does not need more than file visibility, we simply add the
> static modifier to its declaration.
>
> Signed
47 matches
Mail list logo
