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 having
On Mon, May 27, 2013 at 9:14 AM, Antoine Pelisse apeli...@gmail.com wrote:
On Sun, May 26, 2013 at 10:35 PM, Johannes Sixt j...@kdbg.org 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
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.
Exactly
On Thu, May 30, 2013 at 7:58 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 30, 2013 at 7:17 AM, Thomas Rast tr...@inf.ethz.ch wrote:
diff --git i/t/t7501-commit.sh w/t/t7501-commit.sh
index 195e747..1608254 100755
---
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
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 j...@kdbg.org
---
t/t3100-ls-tree-restrict.sh | 42 +++---
1 file changed, 15
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
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 j...@kdbg.org
---
t/t2100-update-cache-badpath.sh | 81
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,
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
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 j...@kdbg.org
---
t/t3010-ls-files-killed-modified.sh | 123 ++--
1 file changed, 61
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
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
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 didn't
On Thu, May 30, 2013 at 3:32 AM, Karsten Blees karsten.bl...@gmail.com 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
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:
Hello,
Regarding the git-fetch man page (IIUC, in pull-fetch-param.txt), in
particular the refspec 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
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)
+ git
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 for
On Fri, May 17, 2013 at 9:18 PM, Felipe Contreras
felipe.contre...@gmail.com 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',
On Sat, Jun 1, 2013 at 9:03 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
felipe.contre...@gmail.com 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
On Sat, Jun 1, 2013 at 9:06 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 1, 2013 at 9:03 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Nobody is checking for specific error codes; it's the errno
Felipe Contreras felipe.contre...@gmail.com 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
On Sat, Jun 1, 2013 at 9:08 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 9:06 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 1, 2013 at 9:03 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
On Sat, Jun 1, 2013 at 9:19 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Nobody is checking for specific error codes; it's the errno that's
important.
[...]
- /*
- * This return value is chosen so that code 0xff
-
On Sat, Jun 1, 2013 at 9:21 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Nobody is checking for specific error codes; it's the errno that's
important.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
On Sat, Jun 1, 2013 at 9:30 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 1, 2013 at 9:21 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Yeah, and last year we returned a different code. The world
On Sat, Jun 1, 2013 at 9:36 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 9:30 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 1, 2013 at 9:21 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 1, 2013 at 8:51 PM, Felipe Contreras
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_s something and then 'git
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. The
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 majordomo
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 artag...@gmail.com 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
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 ram...@ramsay1.demon.co.uk
---
Hi
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
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 p...@peff.net wrote:
On Sat, Jun 01, 2013 at 09:30:50AM -0500, Felipe Contreras wrote:
commit 709ca730f8e093005cc882bfb86c0ca9c83d345b
Author: Jeff King p...@peff.net
Date: Sat Jan 5 09:49:49 2013 -0500
run-command: encode signal death as a
---
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 stricter
On Sat, Jun 1, 2013 at 12:24 PM, Jeff King p...@peff.net 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
40 matches
Mail list logo
