On Fri, Mar 14, 2014 at 01:02:13AM +0100, Uwe Storbeck wrote:
When your system shell (/bin/sh) is a dash control sequences in
strings get interpreted by the echo command. A commit message
which ends with the string '\n' may result in a garbage line in
the todo list of an interactive rebase
On Fri, Mar 07, 2014 at 08:23:05AM +0100, Johannes Sixt wrote:
No, I meant lines like
static double var;
-static int old;
+static int new;
The motivation is to show hints where in a file the change is located:
Anything that could be of significance for the author should be
On Tue, Mar 11, 2014 at 09:49:33PM +0530, karthik nayak wrote:
On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
karthik nayak karthik@gmail.com writes:
Currently we have multiple invocation of git_config() in an
individual invocation of git() which
On Wed, Mar 12, 2014 at 04:19:23PM +0800, Yuxuan Shui wrote:
I'm Yuxuan Shui, a undergraduate student from China. I'm applying for
GSoC 2014, and here is my proposal:
I found this idea on the ideas page, and did some research about it.
The pack bitmap patchset add a new .bitmap file for
On Sat, Mar 01, 2014 at 12:01:44PM +0100, Matthieu Moy wrote:
Jeff King p...@peff.net writes:
If we had the keys in-memory, we could reverse this: config code asks
for keys it cares about, and we can do an optimized lookup (binary
search, hash, etc).
I'm actually dreaming of a system
On Wed, Mar 12, 2014 at 11:33:50PM -0400, Quint Guvernator wrote:
It is _not_ my goal to make the code harder to maintain down the road.
So, at this point, which hunks (if any) are worth patching?
This discussion ended up encompassing a lot of other related cleanups. I
hope we didn't scare you
On Fri, Mar 14, 2014 at 05:21:59PM +0700, Duy Nguyen wrote:
On Fri, Mar 14, 2014 at 4:43 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Would it be practical to change it to a percentage of bytes written?
Then we'd have progress info that is both convenient *and* truthful.
I agreed
On Fri, Mar 14, 2014 at 10:18:32PM +0100, Jens Lehmann wrote:
Since 83d842dc8 make test using prove fails for some setups in t5541
with:
Parse errors: No plan found in TAP output
Running t5541 on its own fails with:
error: Can't use skip_all after running some tests
This
their dependency on TTY. However, we still
cover the case (see the in-code comment for details).
Reported-by: Jens Lehmann jens.lehm...@web.de
Signed-off-by: Jeff King p...@peff.net
---
t/lib-terminal.sh | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/t
On Fri, Mar 14, 2014 at 03:05:45PM -0700, Junio C Hamano wrote:
Actually, we don't need to do this, as of 94221d2 (t: use perl instead
of $PERL_PATH where applicable, 2013-10-28). If only the author of
that commit were here to correct me...
Yuck. I forgot all about that, too.
I wonder
Here are patches to make the pack-objects progress meters behave the
same both with and without pack reuse. The first one is basically the
patch I posted earlier.
The second one drops the Reusing existing pack, and just rolls those
numbers into Counting objects. I have mixed feelings on it. _I_
). But it would also be more complex and
annoying to the user; rather than seeing one progress meter
counting up to 100%, they would finish one meter, then start
another one at zero.
Signed-off-by: Jeff King p...@peff.net
---
builtin/pack-objects.c | 19 ---
1 file changed, 16
), and then continue to add
to it as we traverse.
Signed-off-by: Jeff King p...@peff.net
---
builtin/pack-objects.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 12aa94c..4ca3946 100644
--- a/builtin/pack-objects.c
. We do not waste time partially generating bitmaps only
to find out that some object deep in the history is not
being packed.
Signed-off-by: Jeff King p...@peff.net
---
I posted this earlier here:
http://article.gmane.org/gmane.comp.version-control.git/240969
The discussion resulted
On Sat, Mar 15, 2014 at 06:19:08AM +0530, Shubham Chaudhary wrote:
From c422507408824403ed18e89ec0bbc32b8764e09c Mon Sep 17 00:00:00 2001
You can drop this line; it's just part of the mbox format.
From: Shubham Chaudhary shubham.chaudh...@kdemail.net
Date: Sat, 15 Mar 2014 05:56:18 +0530
no update.
3. Process A commits the lockfile.
4. Process B takes the lock, then overwrite's process A's
changes.
We can fix this by doing our check while we hold the lock.
Signed-off-by: Jeff King p...@peff.net
---
This is a repost of:
http://article.gmane.org/gmane.comp.version
On Sat, Mar 15, 2014 at 05:05:29PM +0100, Thomas Rast wrote:
diff --git a/builtin/mv.c b/builtin/mv.c
index f99c91e..b20cd95 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -230,6 +230,11 @@ int cmd_mv(int argc, const char **argv, const char
*prefix)
On Sat, Mar 15, 2014 at 06:56:52PM +, brian m. carlson wrote:
We shrink the source and destination arrays, but not the modes or
submodule_gitfile arrays, resulting in potentially mismatched data. Shrink
all the arrays at the same time to prevent this. Add tests to ensure the
problem
command-line option into the
$prefix shell variable. However, if we do not see such an
option, the variable is left with whatever value it had in
the environment. We should initialize it to a known value,
like we do for other variables.
Signed-off-by: Jeff King p...@peff.net
---
I checked
On Mon, Mar 17, 2014 at 04:08:50PM -0400, Eric Sunshine wrote:
On Mon, Mar 17, 2014 at 3:59 PM, Jeff King p...@peff.net wrote:
On Mon, Mar 17, 2014 at 01:58:00PM +0100, Gilles Filippini wrote:
Test 21 from contrib/subtree/t/t7900-subtree.sh fails when an
environment variable 'prefix
On Mon, Mar 17, 2014 at 03:06:02PM -0400, Eric Sunshine wrote:
On Mon, Mar 17, 2014 at 11:07 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
On 03/17/2014 07:33 AM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Would it make sense to go one step further to introduce
On Mon, Mar 17, 2014 at 03:52:51PM -0700, Junio C Hamano wrote:
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 3e1d5c3..4135980 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -193,7 +193,7 @@ static int verify_format(const char *format)
On Mon, Mar 17, 2014 at 04:07:00PM -0700, Junio C Hamano wrote:
-if (!memcmp(used_atom[at], color:, 6))
+if (starts_with(used_atom[at], color:))
need_color_reset_at_eol =
!!strcmp(used_atom[at], color_reset);
[...]
What if
On Fri, Mar 14, 2014 at 05:09:45PM -0700, Shawn Pearce wrote:
On Fri, Mar 14, 2014 at 4:30 PM, Duy Nguyen pclo...@gmail.com wrote:
On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce spea...@spearce.org wrote:
You missed the SSH case. It doesn't have this slot to hide the data into.
Right
On Sat, Mar 15, 2014 at 08:23:08AM +0700, Duy Nguyen wrote:
The default would start at false, and people who know their server is
very up-to-date can turn it on. And then when many server
implementations support it, flip the default to auto. And either leave
it there forever, or
On Sun, Mar 16, 2014 at 06:30:49PM -, Philip Oakley wrote:
* jk/branch-at-publish-rebased (2014-01-17) 5 commits
- t1507 (rev-parse-upstream): fix typo in test title
- implement @{publish} shorthand
- branch_get: provide per-branch pushremote pointers
- branch_get: return early on error
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
significantly. Notice that people usually work on recent history only,
we could keep recent history
On Tue, Mar 18, 2014 at 12:50:50AM -0400, Jeff King wrote:
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
significantly. Notice that people
On Tue, Mar 18, 2014 at 12:00:48PM +0700, Duy Nguyen wrote:
On Tue, Mar 18, 2014 at 11:50 AM, Jeff King p...@peff.net wrote:
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250
On Fri, Mar 14, 2014 at 07:56:46AM +0100, Johannes Sixt wrote:
Consider this code:
void above()
{}
static int Y;
static int A;
int bar()
{
return X;
}
void below()
{}
Thanks, this example is very helpful.
When you 'git grep --function-context X', then you get
On Tue, Mar 18, 2014 at 01:37:39PM -0700, Junio C Hamano wrote:
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index c9c426c..3e3f77b 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -974,24 +974,15 @@ test_expect_success SYMLINKS 'symlinked
On Tue, Mar 18, 2014 at 03:16:27PM -0700, Junio C Hamano wrote:
Isn't GIT_CONFIG here another way of saying:
test_must_fail git config -f doesnotexist --list
Perhaps that is shorter and more readable still (and there are a few
similar cases in this patch.
Surely, but are we
On Wed, Mar 19, 2014 at 10:28:46AM -0700, Junio C Hamano wrote:
[git config --file versus GIT_CONFIG=]
Thanks. Then I think it makes sense to do such a conversion but it
probably should be done on top of this patch (we could do it before
this patch), not as a part of this patch.
Here's a
.
This is insufficient for running the tests outside of the
Makefile, however, and 8565d2d (Make tests independent of
global config files, 2007-02-15) later set GIT_CONFIG
directly in test-lib.sh. At that point the Makefile setting
was redundant, but we never removed it. Let's do so now.
Signed-off-by: Jeff King p
This is already handled by the mass GIT_* unsetting added by
95a1d12 (tests: scrub environment of GIT_* variables,
2011-03-15).
Signed-off-by: Jeff King p...@peff.net
---
t/test-lib.sh | 1 -
1 file changed, 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 1531c24..625f06e 100644
. And in
t1000, we unset GIT_TEMPLATE_DIR, which is explicitly
initialized by test-lib.sh.
Signed-off-by: Jeff King p...@peff.net
---
I suppose one could make an argument that test-lib.sh may later change
the set of variables it clears, and these unsets are documenting an
explicit need of each test. I'd find
This lets us get rid of an extra env invocation in the
middle, and is slightly more readable.
Signed-off-by: Jeff King p...@peff.net
---
The case that started this all...
This is also the only reason this series needs to go on top of David's
patch.
t/t1300-repo-config.sh | 8
1 file
one case in t1300 which checks
the same operation on both GIT_CONFIG and git config
--file. They are equivalent in the code these days, but
this will make sure it remains so.
Signed-off-by: Jeff King p...@peff.net
---
Unlike the last patch, this one has no tangible benefits besides Peff
thinks
t0001 predates the test_path_is_* helpers, and uses test
-f and test -d directly. Using the helpers provides
better debugging output, and are a little more robust.
As opposed to ! test -d, test_path_is_missing will
actually makes sure the path does not exist at all.
Signed-off-by: Jeff King p
in this area more
obvious.
Signed-off-by: Jeff King p...@peff.net
---
t/t0001-init.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 9b05fdf..5245711 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -402,8 +402,8
We hand-set several config options using :
git config -f $HOME/.gitconfig ...
Instead, we can use test_config_global. Not only is this
more readable, but it cleans up for us so that subsequent
tests aren't polluted by our settings.
Signed-off-by: Jeff King p...@peff.net
---
t/t0001-init.sh
.
Signed-off-by: Jeff King p...@peff.net
---
I'm pretty sure we can actually drop the mkdir in each of
these cases, too, but I was trying to leave things as close
to the original as possible.
t/t0001-init.sh | 38 +++---
1 file changed, 11 insertions(+), 27 deletions
Many tests use subshells, but don't actually change the
shell environment. They were probably cargo-culted from
earlier tests which did need subshells. Drop the useless
ones.
Signed-off-by: Jeff King p...@peff.net
---
These ones should produce no behavior change at all; they're purely
mechanical
Many tests do something like:
(
mkdir foo
cd foo
git init
)
You can do the same these days with git init foo, which
makes the tests shorter and simpler to read.
Signed-off-by: Jeff King p...@peff.net
---
Unlike the last patch, this one _could_ have an affect. I
On Wed, Mar 19, 2014 at 10:34:29PM +, Dragos Foianu wrote:
The name_rev function recursively calls itself which is why the backtrace is
so big. Unfortunately, for repos with long histories it can lead to Stack
Overflows. This is pretty much what happened in your case.
I tested it on my
On Fri, Mar 21, 2014 at 03:51:16AM +1100, Chris Angelico wrote:
1. I would say yes. git config is made to be extended and doesn't
require a config item to be known.
2. Namespacing the config items like you did is a good thing to do so
it won't interfere with other options.
Excellent!
On Wed, Mar 19, 2014 at 01:38:32PM +0100, David Kastrup wrote:
The default of 16MiB causes serious thrashing for large delta chains
combined with large files.
Does it make much sense to bump this without also bumping
MAX_DELTA_CACHE in sha1_file.c? In my measurements of linux.git, bumping
the
On Wed, Mar 19, 2014 at 03:39:42PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Mar 07, 2014 at 08:08:37AM +0100, Christian Couder wrote:
Be it graft or replace, I do not think we want to invite people to
use these mechansims too lightly to locally rewrite
On Fri, Mar 21, 2014 at 10:46:15AM +1100, Chris Angelico wrote:
oohh. Heh. I thought the porcelain sections of git were the
lower-level or machine-readable versions of other tools, and didn't
really think of mine as fitting into that.
The term sometimes gets used confusingly. The
On Thu, Mar 20, 2014 at 05:25:22PM +, Tanay Abhra wrote:
I have gone through commit.c, builtin/commit.c and api-config.txt but one
thing I cannot find is which functions handle writing config file to disk
after adding a new variable,value pair(for example git config my.option
true) . It
On Thu, Mar 20, 2014 at 10:56:58PM -, Philip Oakley wrote:
This is by design. Git-log does not calculate or show merge diffs
unless
-c or --cc is specified, and thus no diff-filter can match.
This is hard to discern from the log(1) man page as this conflates
commit inclusion
On Thu, Mar 20, 2014 at 02:15:29PM -0400, Brian Bourn wrote:
Going through the annals of the listserve thus far I've found a few
discussions which provide some insight towards this process as well as
some experimental patches that never seem to have made it
through[1][2][3][4]
Reading the
On Thu, Mar 20, 2014 at 11:35:03AM +0200, George Papanikolaou wrote:
Hi again guys,
I forgot to add the signed-of line to the tiny patch I sent earlier for GSOC.
Any ideas about the changes?
Thanks...
You don't give any detail on the inefficiencies, or what specific
benchmark is made faster.
On Fri, Mar 21, 2014 at 02:03:41PM -0400, Brian Bourn wrote:
What do they do, what does the caller expect to see (do they get
something as return values? do they expect some side effects?)?
so something like this would be better I'm assuming?
Some basic sample API calls are found
On Fri, Mar 21, 2014 at 10:31:59AM -0700, Junio C Hamano wrote:
-- 8 --
From: Chris Angelico ros...@gmail.com
Date: Fri, 21 Mar 2014 15:07:08 +1100
Subject: [PATCH] config.txt: third-party tools may and do use their own
variables
[...]
+Other git-related tools may and do use their own
On Fri, Mar 21, 2014 at 07:58:55PM -0700, Siddharth Agarwal wrote:
At Facebook we've found that fetch speed is a bottleneck for our Git repos,
so we've been looking to deploy bitmaps to speed up fetches. We've been
trying out git-next with the top two patches from
On Mon, Mar 24, 2014 at 11:25:32AM +0100, Ephrim Khong wrote:
Thank you for the explanation, I now understand why this is happening from a
technical point of view. From a usability perspective, it is a bit confusing
that a flag that should intuitively increase the number of shown commits
On Mon, Mar 24, 2014 at 11:22:30AM -0700, Junio C Hamano wrote:
+test_log_icase() {
+ test_log $@ --regexp-ignore-case
+ test_log $@ -i
-cascade broken? Will squash in an obvious fix.
I don't think so. This is happening outside of test_expect_success,
which is run by test_log. So
On Mon, Mar 24, 2014 at 11:22:58AM -0700, Junio C Hamano wrote:
René Scharfe l@web.de writes:
-test_expect_success 'log --grep -i' '
- git log -i --grep=InItial --format=%H actual
- test_cmp expect_initial actual
-'
+test_log expect_initial --grep initial
+test_log
On Sat, Mar 22, 2014 at 06:15:58PM +0100, René Scharfe wrote:
pickaxe() calls pickaxe_match(); moving the definition of the former
those after the latter allows us to do without an explicit function
declaration.
s/those //
-Peff
--
To unsubscribe from this list: send the line unsubscribe git
On Sat, Mar 22, 2014 at 06:15:50PM +0100, René Scharfe wrote:
This series allows the options -i/--regexp-ignore-case, --pickaxe-regex,
and -S to be used together and work as expected to perform a pickaxe
search using case-insensitive regular expression matching. Its first
half refactors the
On Sat, Mar 22, 2014 at 10:32:37AM +0100, René Scharfe wrote:
This test is of questionable portability, since we are depending on
gmtime's arbitrary point to decide that our input is crazy and return
NULL. The value is sufficiently large that I'd expect most to do so,
though, so it may be
On Fri, Mar 21, 2014 at 10:07:15PM +0100, Johannes Sixt wrote:
Add an infrastructure that simplifies adding new tests of the hunk
header regular expressions.
To add new tests, a file with the syntax to test can be dropped in the
directory t4018. The README file explains how a test file must
On Mon, Mar 24, 2014 at 05:36:59PM -0400, Jeff King wrote:
+How to write RIGHT test cases
+=
+
+Insert the word ChangeMe (exactly this form) at a distance of
+at least two lines from the line that must appear in the hunk header.
The existing tests use -U1
On Fri, Mar 21, 2014 at 10:07:12PM +0100, Johannes Sixt wrote:
Here is a series that makes the hunk header pattern for C and C++ even
simpler than suggested by Peff in [1] to catch a lot more C++ functions
and two more C patterns.
As a preparatory work, the test cases are totally rewritten
On Fri, Mar 21, 2014 at 02:24:31PM -0700, Junio C Hamano wrote:
Unsetting these is not only useless, but can be confusing to
a reader, who may wonder why some tests in a script unset
them and others do not (t0001 is particularly guilty of this
inconsistency, probably because many of its
On Fri, Mar 21, 2014 at 02:26:02PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Some tests want to check or set config in another
repository. E.g., t1000 creates repositories and makes sure
that their core.bare and core.worktree settings are what we
expect. We can do
On Mon, Mar 24, 2014 at 11:03:42PM +0100, René Scharfe wrote:
If the result is all-zeroes, can we check for that case instead? I
suppose that will eventually create a trap at midnight on January 1st
of the year 0 (though I am not sure such a date is even meaningful,
given the history of our
On Mon, Mar 24, 2014 at 10:16:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
error: Ref refs/heads/master is at
4584c1f34e07cea2df6abc8e0d407fe016017130 but expected
61b79b6d35b066d054fb3deab550f1c51598cf5f
remote: error: failed to lock refs/heads/master
I also see this error once in a
On Mon, Mar 24, 2014 at 03:18:14PM -0400, Scott Sandler wrote:
I've noticed that a few times in the past several weeks, we've had
events where pushes have been lost when two people pushed at just
about the same time. The scenario is that two users both have commits
based on commit A, call
On Mon, Mar 24, 2014 at 01:49:44AM -0700, Ilya Bobyr wrote:
Here are some examples of how functionality added by the patch
could be used. In order to run setup tests and then only a
specific test (use case 1) one can do:
$ ./t-init.sh --run='1 2 25'
or:
$ ./t-init.sh
On Tue, Mar 25, 2014 at 09:45:20AM -0400, Scott Sandler wrote:
Version of git on the server? git version 1.8.3-rc0
There was significant work done between v1.8.3 and v1.8.4 on handling
races in the ref code. As I said before, I don't think the symptoms you
are describing are anything we have
About half of test_perf() is boilerplate, and half is
actually related to running the perf test. Let's split it
into two functions, so that we can reuse the boilerplate in
future commits.
Signed-off-by: Jeff King p...@peff.net
---
t/perf/perf-lib.sh | 61
time for the operation.
Signed-off-by: Jeff King p...@peff.net
---
t/perf/p5311-pack-bitmaps-fetch.sh | 45 ++
1 file changed, 45 insertions(+)
create mode 100755 t/perf/p5311-pack-bitmaps-fetch.sh
diff --git a/t/perf/p5311-pack-bitmaps-fetch.sh
b/t/perf/p5311
[tl;dr the patch is the same as before, but there is a script to measure
its effects; please try it out on your repos]
This is a continuation of the discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/239647
I'll summarize the story so far.
Basically, the problem
from the test and shows it in the aggregated
output (with pretty printing and relative size comparison).
Signed-off-by: Jeff King p...@peff.net
---
t/perf/README | 20
t/perf/aggregate.perl | 48 +++-
t/perf/perf-lib.sh
This will let us reuse the code when we add new values to
aggregate besides times.
Signed-off-by: Jeff King p...@peff.net
---
t/perf/aggregate.perl | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl
index
it.
Signed-off-by: Jeff King p...@peff.net
---
pack-bitmap.c | 21 -
pack-bitmap.h | 2 ++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index a31e529..f7d417b 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -86,6 +86,9 @@ static
the delta-search window.
However, there is no reason we cannot reuse an on-disk delta
against such a deep have base, avoiding the delta search
for that object altogether.
Signed-off-by: Jeff King p...@peff.net
---
builtin/pack-objects.c | 16 +++-
1 file changed, 15 insertions(+), 1
On Wed, Mar 26, 2014 at 10:33:41AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
2. When considering whether a delta can be reused, check the bitmaps
to see if the client has the base. If so, allow reuse.
...
The implementation I'm including here is the one I've
On Wed, Mar 26, 2014 at 11:05:59AM +, Charles Bailey wrote:
On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
+# date is within 2^63-1, but enough to choke glibc's gmtime
+test_expect_success 'absurdly far-in-future dates produce sentinel' '
+ commit=$(munge_author_date HEAD
(and presumably filled
with our leather-clad horseback-riding ape descendants).
Let's allow the test to match either the sentinel value
(i.e., what we want when gmtime gives up) or any reasonable
value returned by known implementations.
Reported-by: Charles Bailey cbaile...@bloomberg.net
Signed-off-by: Jeff
On Wed, Mar 26, 2014 at 11:58:49AM -0700, Junio C Hamano wrote:
Unlike the FreeBSD thing that René brought up, this is not a problem in
the code, but just in the test. So I think our options are basically:
1. Scrap the test as unportable.
2. Hard-code a few expected values. I'd be
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed that it was vaguely right. But:
99 / (86400 * 365)
is something like 31 billion years in the future, not 160
On Wed, Mar 26, 2014 at 08:36:18PM +, Charles Bailey wrote:
On Wed, Mar 26, 2014 at 03:40:43PM -0400, Jeff King wrote:
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed
On Wed, Mar 26, 2014 at 02:01:21PM -0700, Junio C Hamano wrote:
I don't know how important that is. This is such a minor feature that it
is not worth a lot of maintenance headache in the test. But I also do
not know if this is going to be the last report, or we will have a bunch
of other
On Wed, Mar 26, 2014 at 09:22:27PM +, Charles Bailey wrote:
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed that it was vaguely right. But:
99 / (86400
On Wed, Mar 26, 2014 at 03:31:41PM -0700, Junio C Hamano wrote:
I think we could still add the objects from the tip of the client's HAVE
list.
That should make the result at least per to the non-bitmap case,
right?
That's my expectation.
2. Measure the reused deltas become
On Wed, Mar 26, 2014 at 02:13:00PM -0400, Jeff King wrote:
So I think the next steps are probably:
1. Measure the all objects are preferred bases approach and confirm
that it is bad.
Below is a very rough patch to accomplish this. It just traverses the
have bitmap and adds every
On Thu, Mar 27, 2014 at 03:45:34PM +0100, Siggi wrote:
and git version
git:amd64/saucy 1:1.8.3.2-1 uptodate
my remote repository is on a Chiliprojekt server (a fork of Redmine).
cloning the repo over http results in following error:
sneher@sneher-XPS:~/Dokumente/test$ git clone
On Thu, Mar 27, 2014 at 02:50:46PM -0400, David A. Dalrymple (and Bhushan G.
Lodha) wrote:
This series introduces a --function-name=pattern option for git-log,
intended
to search for commits which touch a function matching a certain pattern (a
feature we've seen requested and are interested
On Thu, Mar 27, 2014 at 03:16:48PM -0700, Junio C Hamano wrote:
I wasn't looking at the caller (and I haven't). I agree that, if
you have to compare case-insensitive user input against known set of
tokens, using strcasecmp() would be saner than making a downcased
copy and the set of
On Wed, Mar 26, 2014 at 10:46:16PM +, Charles Bailey wrote:
On Wed, Mar 26, 2014 at 05:57:41PM -0400, Jeff King wrote:
Hmm, so the year you got is actually: 1623969404. That still seems off
to me by a factor 20. I don't know if this is really worth digging into
that much further, but I
On Thu, Mar 27, 2014 at 03:47:01PM -0700, Junio C Hamano wrote:
Actually, I think it ends up being hostile to the users to accept
random cases without a good reason. If you see two trailer elements
whose where are specified as after and AFTER in somebody's
configuration file, wouldn't that
On Thu, Mar 06, 2014 at 10:16:47PM +0100, Maurice Bos wrote:
I have no clue why git diff --cached isn't used instead of git diff-index.
I was wondering about it, but I decided I don't know enough about git and
there are probably valid reasons for doing it this way. Though, replacing
it with
On Thu, Mar 27, 2014 at 10:37:07AM -0300, Thiago Farina wrote:
Do we leak the context we allocate in imap-send.c:280 intentionally?
It was never mentioned on the mailing list when the patches came
originally, so I suspect is just an omission.
Presumably the SSL_CTX is needed by the connection
On Fri, Mar 28, 2014 at 09:14:07AM +, Marat Radchenko wrote:
Jeff King peff at peff.net writes:
The write_or_die function will always die on an error,
including EPIPE. However, it currently treats EPIPE
specially by suppressing any error message, and by exiting
with exit
-by: Siddharth Agarwal s...@fb.com
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
I believe this should solve the problem you're seeing, and I think any
solution is going to be along these lines.
This covers all code paths that can be triggered by pack-objects
On Fri, Mar 28, 2014 at 10:07:22AM +, Marat Radchenko wrote:
What
happens if git is still writing data to the pager and the pager exits?
Does it receive a signal of some sort?
I'm not sure what you mean, sorry. check_pipe properly detects pager exit.
The problem is with the way it
On Fri, Mar 28, 2014 at 09:41:53AM -0700, Junio C Hamano wrote:
Offhand, the three possible failure modes this thread identified
sounds to me like the only plausible ones, and I think the best way
forward might be to
- teach the is the result sane, even though we may have got a
401 - 500 of 13736 matches
Mail list logo
