On Thu, Jan 16, 2014 at 04:34:01PM -0800, Yuri wrote:
When I run 'git log' on FreeBSD-9.2, I get output like this:
ESC[33mcommit 398e78c62fd507a317de7c2abb8e25c9fac7ac9eESC[m
Merge: 5fb8f6e d2138ba
...
ESC is white on black background.
Why ESC[33m aren't expanded by the terminal? Is
On Thu, Jan 16, 2014 at 06:02:24PM -0800, Yuri wrote:
On 01/16/2014 17:47, Jeff King wrote:
Are you using less as your pager (it is the default in git unless you
have set your PAGER environment variable)? If so, do you have the R
option set to pass through ANSI codes? Git will set
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out fatal: No such
ref: '' if git pull --rebase is run on branches without an upstream.
This is already fixed in bb3f458 (rebase: fix fork-point with zero
arguments, 2014-01-09),
On Thu, Jan 16, 2014 at 06:28:10PM -0800, Yuri wrote:
On 01/16/2014 18:13, Jeff King wrote:
Interesting. I take it that more does not pass through ANSI codes at
all, then.
Actually, 'more -R' also passes colors on FreeBSD. So maybe you can
always add -R if PAGER=more on *BSD (any of them
On Thu, Jan 16, 2014 at 06:29:21PM -0800, Jonathan Nieder wrote:
+ /*
+* We know that more does not pass through colors at all.
+*/
+ if (!strcmp(pager, more))
+ return 0;
I seem to remember that on some systems more is the name of the
full-featured pager that
On Thu, Jan 16, 2014 at 09:35:48PM -0500, Jeff King wrote:
I think we should make an effort to set MORE=R on FreeBSD. We can
perhaps just set it unconditionally, and assume that primitive more
will ignore it. And then assume that more will handle colors (either
because of the R setting
On Thu, Jan 16, 2014 at 09:35:48PM -0500, Jeff King wrote:
I can prepare a patch series, but I happily no longer have any antique
systems to test this kind of stuff on.
Here it is. For those just joining us, the problem is that on some
systems, git log out of the box produces ANSI codes which
MORE (Debian's more is an
example). For this reason, we make the setting a
compile-time option (but turn it on by default on FreeBSD).
Signed-off-by: Jeff King p...@peff.net
---
Makefile | 7 +++
config.mak.uname | 1 +
pager.c | 4
3 files changed, 12 insertions(+)
diff
the memory for the array, but:
1. This function is only called once per program.
2. We're now leaking heap memory instead of wasting BSS on
the static array.
Signed-off-by: Jeff King p...@peff.net
---
I actually think we can free pager_process.env after
start_command is run. You _cannot_ do
-by: Jeff King p...@peff.net
---
cache.h | 3 ++-
color.c | 2 +-
config.c | 2 +-
environment.c | 2 +-
pager.c | 45 +
5 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 83a2726..7fd1977 100644
On Fri, Jan 17, 2014 at 10:46:59AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
diff_filespec has a 2-bit dirty_submodule field and
defines two flags as macros. Originally these were right
next to each other, but a new field was accidentally added
in between in commit
On Fri, Jan 17, 2014 at 11:43:35AM -0800, Junio C Hamano wrote:
Yuri y...@rawbw.com writes:
I think that in a rare case of error this extra-printout wouldn't
hurt.
If the error is rare, extra verbiage does not hurt were a valid
attitude, error is rare, non-zero exit is enough would be
On Fri, Jan 17, 2014 at 03:13:25PM -0500, Jeff King wrote:
On Fri, Jan 17, 2014 at 11:43:35AM -0800, Junio C Hamano wrote:
Yuri y...@rawbw.com writes:
I think that in a rare case of error this extra-printout wouldn't
hurt.
If the error is rare, extra verbiage does not hurt were
On Fri, Jan 17, 2014 at 12:39:39PM -0800, Yuri wrote:
That second line is not adding anything, and IMHO is making things
uglier and more confusing. We_expected_ the helper to hang up; that's
how it signals an error to us. It is not an unexpected condition at all.
The exit(128) we do is
This series fixes a rev-list performance regression in fbd4a70 (list-objects:
mark more commits as edges in mark_edges_uninteresting, 2013-08-16). That
commit is a little tricky because it actually _knows_ it's trading off CPU for
a better packfile, but I think we're performing the tradeoff in
(3.44+0.02)
3.48(3.44+0.03) +0.3%
0001.4: rev-list $commit --not --all 0.04(0.04+0.00)
0.04(0.04+0.00) +0.0%
0001.5: rev-list --objects $commit --not --all 0.04(0.03+0.00)
0.27(0.24+0.02) +575.0%
Signed-off-by: Jeff King p...@peff.net
---
Sorry for the long lines in the commit
+0.00)
0.04(0.04+0.00) +0.0%
0001.5: rev-list --objects $commit --not --all 0.27(0.26+0.01)
0.04(0.04+0.00) -85.2%
Signed-off-by: Jeff King p...@peff.net
---
list-objects.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/list-objects.c b/list
On Mon, Jan 20, 2014 at 04:31:01PM -0500, Jeff King wrote:
diff --git a/t/perf/p0001-rev-list.sh b/t/perf/p0001-rev-list.sh
index 4f71a63..b7258a7 100755
--- a/t/perf/p0001-rev-list.sh
+++ b/t/perf/p0001-rev-list.sh
@@ -14,4 +14,21 @@ test_perf 'rev-list --all --objects' '
git rev
On Mon, Jan 20, 2014 at 04:28:45PM -0500, Jeff King wrote:
[1/2]: t/perf: time rev-list with UNINTERESTING commits
[2/2]: list-objects: only look at cmdline trees with edge_hint
Here's t/perf/p0001 output that shows the problem:
0001.5: rev-list --objects $commit --not --all
On Mon, Jan 20, 2014 at 11:32:12PM +0100, Thomas Rast wrote:
This is bad to be touching the repo and assuming it is non-bare. For
some reason I assumed that the perf suite made a copy of the repo, but
it doesn't. If you point to a bare repo via GIT_PERF_REPO, this part of
the test fails.
On Tue, Jan 21, 2014 at 06:57:08AM +0700, Duy Nguyen wrote:
You must have so much fun (or headache, depending on your view) with
the variety of repos on github :)
It's fun on days like these when the solution is fairly straightforward.
:)
+ if (revs-edge_hint) {
+ for
On Mon, Jan 20, 2014 at 04:28:45PM -0500, Jeff King wrote:
This series fixes a rev-list performance regression in fbd4a70 (list-objects:
mark more commits as edges in mark_edges_uninteresting, 2013-08-16). That
commit is a little tricky because it actually _knows_ it's trading off CPU
(3.44+0.02)
3.48(3.44+0.03) +0.3%
0001.4: rev-list $commit --not --all 0.04(0.04+0.00)
0.04(0.04+0.00) +0.0%
0001.5: rev-list --objects $commit --not --all 0.04(0.03+0.00)
0.27(0.24+0.02) +575.0%
Signed-off-by: Jeff King p...@peff.net
---
t/perf/p0001-rev-list.sh | 12
+0.00)
0.04(0.04+0.00) +0.0%
0001.5: rev-list --objects $commit --not --all 0.27(0.26+0.01)
0.04(0.04+0.00) -85.2%
Signed-off-by: Jeff King p...@peff.net
---
list-objects.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/list-objects.c b/list
On Wed, Jan 15, 2014 at 06:50:33PM -0500, Martin Langhoff wrote:
On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote:
As long as we can reliably determine that it is safe to do so
without risking races, automatically cleaning .lock files is a good
thing to do.
If
On Wed, Jan 15, 2014 at 03:59:42PM -0800, Junio C Hamano wrote:
So this is my second try. The second one now gets rid of the call
to mark_blob_uninteresting() as Peff suggested, because the first
patch makes the function very well aware that it only should mark
the objects that are reachable
On Thu, Jan 16, 2014 at 11:26:50PM -0800, Kyle J. McKay wrote:
--- a/pager.c
+++ b/pager.c
@@ -87,6 +87,10 @@ void setup_pager(void)
argv_array_push(env, LESS=FRSX);
if (!getenv(LV))
argv_array_push(env, LV=-c);
+#ifdef PAGER_MORE_UNDERSTANDS_R
+if
On Fri, Jan 17, 2014 at 11:17:01AM -0800, Junio C Hamano wrote:
+#ifdef PAGER_MORE_UNDERSTANDS_R
+ if (!getenv(MORE))
+ argv_array_push(env, MORE=R);
+#endif
pager_process.env = argv_array_detach(env, NULL);
if (start_command(pager_process))
Let me repeat
On Fri, Jan 17, 2014 at 03:42:32PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Perhaps we can start it like this. Then pager.c can iterate over
the PAGER_ENV string, parse out LESS=, LV=, etc., and do its thing.
We would also need to muck with git-sh-setup.sh
On Wed, Jan 22, 2014 at 11:58:05AM -0800, Junio C Hamano wrote:
These quantities can be larger than an int. Use ulong to express
them like the underlying pack-objects does, and also parse them with
the human-friendly unit suffixes.
Hrm. I think that is a valid strategy, but...
- int
On Wed, Jan 22, 2014 at 08:06:42PM -0500, Jeff King wrote:
But I think there is a subtle problem. Here (and elsewhere) we use the
parsed value of 0 as a sentinel. I think that is OK for
--max-pack-size, where 0 is not a reasonable value. But git-repack(1)
says:
--window-memory=0 makes
When we see --max-pack-size, we accidentally propagated
this to pack-objects as --max_pack_size, which does not
work at all.
Signed-off-by: Jeff King p...@peff.net
---
builtin/repack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index
When we use OPT_STRING to parse an option, we get back a
pointer into the argv array, which should be const char *.
The compiler doesn't notice because it gets passed through a
void * in the option struct.
Signed-off-by: Jeff King p...@peff.net
---
Not a big deal, but just for consistency
all of these by simply passing the strings from
the user along to pack-objects verbatim. This does not
actually fix anything for --depth or --window, but these
are converted, too, for consistency.
Signed-off-by: Jeff King p...@peff.net
---
So we lose the advantage listed above. But I think
On Wed, Jan 22, 2014 at 08:30:13PM -0500, Jeff King wrote:
- OPT_INTEGER(0, window, window,
+ OPT_STRING(0, window, window, N_(n),
N_(size of the window used for delta
compression)),
By the way, the old code with OPT_INTEGER would always
On Wed, Jan 22, 2014 at 01:27:09PM -0800, salmansheikh wrote:
Got it working but then I had some issues with the perl portions of the
install and I subsequently thought I could eliminate those portions and
tried setting export NO_PERL=1 and that installed everything else...and got
pass this
On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote:
Two questions: Does regenerating (e.g. if the tarball has dropped
out of the cache) change its sums (md5sum or similar) ? In (beyond)
linuxfromscratch we use md5sums to verify that a tarball has not
changed.
The tarballs we
On Wed, Jan 22, 2014 at 06:05:36PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
EWAH is a word-aligned compressed variant of a bitset (i.e. a data
structure that acts as a 0-indexed boolean array for many entries).
I suspect that for some callers it's not word-aligned.
Yes
a helper for the ntohll form, and add the
appropriate Makefile knob.
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
Makefile | 7 +++
compat/bswap.h | 28
read-cache.c | 44
3
buffer (which we would do anyway,
but we can move it before fixing the endianness).
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
ewah/ewah_io.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/ewah
On Thu, Jan 23, 2014 at 11:41:18AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
Commit d60c49c (read-cache.c: allow unaligned mapping of the
index file, 2012-04-03) introduced helpers to access
unaligned data. Let's factor them out to make them more
widely available.
While we're
Due to the alignment bug in another thread, I had the pleasure of
visiting my old friend Solaris 9 today. The tests _almost_ all run out
of the box.
This series features two minor fixes:
[1/2]: t7501: fix empty commit test with NO_PERL
[2/2]: t7700: do not use touch -r
I had a few other
simply drop the use of -r.
Signed-off-by: Jeff King p...@peff.net
---
t/t7700-repack.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index d954b84..f9f9014 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -17,7 +17,7
in the test state.
Signed-off-by: Jeff King p...@peff.net
---
t/t7501-commit.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index f04798f..94eec83 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -57,6 +57,7 @@ test_expect_success 'using invalid
On Thu, Jan 23, 2014 at 11:52:06AM -0800, Jonathan Nieder wrote:
After my patches, t5310 runs fine for me. I didn't try your patch, but
mine are similar. Let me know if you still see the problem (there may
simply be a bug in yours, but I didn't see it).
I had left out a cast to unsigned,
On Thu, Jan 23, 2014 at 12:08:04PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
On Thu, Jan 23, 2014 at 11:56:43AM -0800, Jonathan Nieder wrote:
In that case I think git-compat-util.h should include something like
what block-sha1/sha1.c has:
#if !defined(__i386__) !defined
On Thu, Jan 23, 2014 at 12:12:23PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
On Thu, Jan 23, 2014 at 11:52:06AM -0800, Jonathan Nieder wrote:
My main worry about the patches is that they will probably run into
an analagous problem to the one that v1.7.12-rc0~1^2~2
[...]
I think
On Thu, Jan 23, 2014 at 12:14:03PM -0800, Shawn Pearce wrote:
Yes, the mmap'd buffers aren't necessarily word-aligned. I don't think
we can fix that easily without changing the on-disk format (which comes
from JGit anyway).
Ouch, sorry about that. JGit doesn't mmap the file so we didn't
On Thu, Jan 23, 2014 at 12:23:42PM -0800, Jonathan Nieder wrote:
The memcpy solution is taken from read-cache.c, but as we noted, it
probably hasn't been used a lot. The blk_sha1 get_be may be faster, as
it converts as it reads.
I doubt there's much difference either way, especially
On Thu, Jan 23, 2014 at 03:03:11PM -0500, Jeff King wrote:
My main worry about the patches is that they will probably run into
an analagous problem to the one that v1.7.12-rc0~1^2~2 (block-sha1:
avoid pointer conversion that violates alignment constraints,
2012-07-22) solved. By casting
On Thu, Jan 23, 2014 at 12:52:30PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
and assume that it will fail. It doesn't. Solaris happily renames
some-file to a regular file named no-such-dir. So we fail later during
the index-update, complaining about adding the entry
On Thu, Jan 23, 2014 at 01:12:55PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... The test does not care about the timestamp of the
.keep file it creates at all, only that it exists.
Please refrain from using touch for such use cases in the first
place. It appears
On Thu, Jan 23, 2014 at 01:33:20PM -0500, Jeff King wrote:
Here's a patch series (on top of jk/pack-bitmap, naturally) that lets
t5310 pass there. I assume the ARM problem is the same, though seeing
the failure in realloc() is unexpected. Can you try it on both your
platforms
The BLK_SHA1 code has optimized wrappers for doing endian
conversions on memory that may not be aligned. Let's pull
them out so that we can use them elsewhere, especially the
time-tested list of platforms that prefer each strategy.
Signed-off-by: Jeff King p...@peff.net
---
These short names
a get_be16 implementation to the existing
get_be32, but that is very simple to do.
Signed-off-by: Jeff King p...@peff.net
---
This _might_ still suffer from the issue fixed in 5f6a112 (block-sha1:
avoid pointer conversion that violates alignment constraints,
2012-07-22), as we are taking
we would do anyway, but we can
move it before fixing the endianness).
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
Tested on the SPARC I have access to. Please double-check that it also
works fine on ARM.
ewah/ewah_io.c | 33
On Thu, Jan 23, 2014 at 01:24:44PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Agreed. I was making the minimal change, but I think there is no reason
not to fix both while we are there. Do you want to just mark up the
patch in transit?
Let's just queue this instead
On Thu, Jan 23, 2014 at 09:53:26PM +, brian m. carlson wrote:
On Thu, Jan 23, 2014 at 03:26:45PM -0500, Jeff King wrote:
Looking over the format, I think the only thing preventing 4-byte
alignment is the 1-byte XOR-offset and 1-byte flags field for each
bitmap. If we ever have a v2, we
On Thu, Jan 23, 2014 at 02:17:55PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
On Thu, Jan 23, 2014 at 09:53:26PM +, brian m. carlson wrote:
Yes, it will. SPARC requires all loads be naturally aligned (4-byte to
an address that's a multiple of 4, 8-byte to a multiple of 8, and so
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 tried to keep the warning to an 80-character line without making it
too confusing. Suggestions welcome if it doesn't make
On Thu, Jan 23, 2014 at 03:34:16PM -0800, Jonathan Nieder wrote:
Line 1484 looks more problematic:
disk_ce = (struct ondisk_cache_entry *)((char *)mmap +
src_offset);
In v4 indexes, src_offset doesn't have any particular alignment so
this conversion has undefined behavior.
On Fri, Jan 24, 2014 at 12:56:17AM +0100, Vicent Martà wrote:
On Fri, Jan 24, 2014 at 12:45 AM, Siddharth Agarwal s...@fb.com wrote:
Yes, we'd prefer to do that too. How do you actually do this, though? I
don't see a way to pass `--honor-pack-keep` (shouldn't I pass in its
inverse?) down
On Thu, Jan 23, 2014 at 03:53:28PM -0800, Siddharth Agarwal wrote:
On 01/23/2014 03:45 PM, Siddharth Agarwal wrote:
The worry is less certain objects not being packed and more the old
packs being deleted by git repack, isn't it? From the man page for
git-index-pack:
This should probably
On Fri, Jan 24, 2014 at 06:09:09PM +0100, Markus Trippelsdorf wrote:
If you mean ignore in some other scenario you need to be more
specific about what you want.
I want to them when I run git pull.
ignore
I assume you mean that you do not want to fetch them at all, not that
On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
However, you do have to specify each branch individually. You probably
want to say all branches except X, and you cannot currently specify
a negative refspec like that.
Yes, that was the question I wanted to ask (,
On Fri, Jan 24, 2014 at 12:00:16PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
However, you do have to specify each branch individually. You probably
want to say all branches except X, and you
On Thu, Jan 23, 2014 at 04:16:06PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
In a triangular workflow, you may have a distinct
@{upstream} that you pull changes from, but publish by
default (if you typed git push) to a different remote (or
a different branch
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the Releases page of git/git. I
imagine there is a programmatic way to do so via GitHub's
On Fri, Jan 24, 2014 at 01:08:42PM -0800, Junio C Hamano wrote:
Not really. You do not have to view it as 'not refs/heads/foo' is
affecting the previous '+refs/heads/*:refs/remotes/origin/*'.
You can think of two refspecs refs/heads/foo refs/heads/bar are
both affecting the end result; so
On Sat, Jan 25, 2014 at 03:15:42PM +0100, Markus Trippelsdorf wrote:
Many thanks for the patch. It seems to work as advertised, but only if
the negative refspec appears on a separate line. For example:
[remote origin]
url = git://gcc.gnu.org/git/gcc.git
fetch =
On Mon, Jan 27, 2014 at 02:56:28PM -0800, Junio C Hamano wrote:
# replace this with however you store your oauth token
# if you don't have one, make one here:
# https://github.com/settings/tokens/new
token() {
pass -n github.web.oauth
Hmph, what is this pass thing?
It's a poor
On Mon, Jan 27, 2014 at 02:09:52PM -0800, Junio C Hamano wrote:
[Stalled]
* jk/color-for-more-pagers (2014-01-17) 4 commits
- pager: disable colors for some known-bad configurations
- DONOTMERGE: needs matching change to git-sh-setup
- setup_pager: set MORE=R
- setup_pager: refactor
On Sun, Jan 26, 2014 at 09:17:09AM +, Eric Wong wrote:
+use File::HomeDir;
We should probably avoid a new dependency and also remain consistent
with the rest of git handles home directories.
Unfortunately, expand_user_path()/git_config_pathname() isn't currently
On Sat, Jan 25, 2014 at 01:46:50PM +0400, Brilliantov Kirill Vladimirovich
wrote:
+ if (!defined $smtp_server) {
+ my $mailrc = File::HomeDir-my_home . /.mailrc;
The new module dependency has been discussed elsewhere in the thread.
+ if (-e $mailrc) {
+
-by: Jeff King p...@peff.net
---
Most of the callers already check for NULL, so the only way to trigger
this is via an empty include.path. That is addressed separately in the
next patch, so technically this is not needed if we apply that one. But
in that case, the path == NULL check here is useless
: unable to parse command-line config
Signed-off-by: Jeff King p...@peff.net
---
config.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index d969a5a..314d8ee 100644
--- a/config.c
+++ b/config.c
@@ -84,8 +84,12 @@ static int handle_path_include(const char
On Thu, Jan 23, 2014 at 06:44:43PM -0800, Siddharth Agarwal wrote:
On 01/23/2014 06:28 PM, Jeff King wrote:
I think your understanding is accurate here. So we want repack to
respect keep files for deletion, but we _not_ necessarily want
pack-objects to avoid packing an object just because
On Thu, Jan 30, 2014 at 02:55:41PM -0500, Brian Gernhardt wrote:
a201c20 (ewah: support platforms that require aligned reads) added a
reliance on the existence of __BYTE_ORDER and __BIG_ENDIAN. However,
these macros are spelled without the leading __ on some platforms (OS
X at least). In
On Thu, Jan 30, 2014 at 03:45:38PM -0500, Jeff King wrote:
Either way, we should perhaps be more careful in the bitmap code, too,
that the values we get are sensible. It's better to die(your bitmap is
broken) than to read off the end of the array. I can't seem to trigger
the same failure mode
On Thu, Jan 30, 2014 at 02:02:33PM -0800, Jonathan Nieder wrote:
In an ideal world I would prefer to just rely on ntohll when it's
decent (meaning that the '#if __BYTE_ORDER != __BIG_ENDIAN' block
could be written as
if (ntohll(1) != 1) {
...
}
or
if
On Thu, Jan 30, 2014 at 02:12:05PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
I do find the failure mode interesting. The endian-swapping code kicked
in when it did not
Odd --- wouldn't the #if condition expand to '0 != 0'?
I had the same thought. The kicked in when it did
On Fri, Jan 31, 2014 at 09:02:15PM +, brian m. carlson wrote:
At work, we recently upgraded our git version from 1.8.3.4 to 1.8.5.3.
We've noticed a significant performance regression in git fetch. The
numbers below are for an up-to-date branch (that is, no data is actually
being
On Sun, Feb 02, 2014 at 04:15:09PM -0600, Stephen Leake wrote:
I always do 'fetch' and 'merge' separately, never 'pull'. So after a
'fetch', the DVC Emacs front end must determine what needs to happen
next. I think there are three cases:
Doing the two steps separately is common in git, too.
[+cc Joshua Jensen, who wrote 50906e0]
On Sun, Feb 02, 2014 at 07:13:04AM -0600, Reuben Hawkins wrote:
fast-import should not use strncmp_icase.
I am not sure of that. My gut feeling is that core.ignorecase is
completely about the _filesystem_, and that git should generally be
case-sensitive
On Sun, Feb 02, 2014 at 10:15:07AM -0800, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
I usually start splitting a commit with reset @^ then add -p back.
The problem is reset @^ does not keep track of new files added in
HEAD, so I often end up forgetting to add new files
On Sun, Feb 02, 2014 at 11:37:39AM +0100, David Kastrup wrote:
So I mused: refs/heads contains branches, refs/tags contains tags. The
respective information would likely easily enough be stored in refs/bzr
and refs/bugs and in that manner would not pollute the ordinary tag
and branch spaces,
On Sun, Feb 02, 2014 at 09:21:56PM +1030, Adrian Johnson wrote:
- Allow extra space in is new and is separate
[...]
- !^(.*[ \t])?(is new|renames|is separate)([ \t].*)?$\n
+ !^(.*[ \t])?(is[ \t]+new|renames|is[ \t]+separate)([ \t].*)?$\n
I do not know anything about Ada syntax, but
On Tue, Jan 21, 2014 at 11:23:30AM -0800, Junio C Hamano wrote:
does complicate the point of my series, which was to add more intimate
logic about how we handle LESS.
...
return !x || strchr(x, 'R');
[...]
I am not sure if it is even a good idea for us to have so
On Tue, Feb 04, 2014 at 02:17:57PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But there's another set of people that I was intending to help with the
patch, which is people that have set up LESS, and did not necessarily
care about the R flag in the past (e.g., for many
On Tue, Feb 04, 2014 at 02:45:11PM -0800, Yuri wrote:
On 02/04/2014 14:25, Jeff King wrote:
Right. If git just disabled the color, I think that would be sane (and
that is what my patch was shooting for). But somebody who sees:
$ git log
ESC[33mcommit
On Tue, Feb 04, 2014 at 03:40:15PM -0800, Junio C Hamano wrote:
* Somehow this came to my private mailbox without Cc to list, so I
am forwarding it.
I think with 1190a1ac (pack-objects: name pack files after
trailer hash, 2013-12-05), repacking the same set of objects may
have
On Tue, Feb 04, 2014 at 05:24:55PM -0800, Yuri wrote:
I think the 'experimental' approach is simpler and better.
When the git command requiring pager is first run, git would run the
pager with some simple one line escape sequence, and see if sequence
is preserved.
See how? If less's stdout
On Wed, Feb 05, 2014 at 07:55:09AM +0100, Michael Haggerty wrote:
* René Scharfe submitted a patch to use a function parse_prefix()
(originally suggested by Peff) instead of Duy's suggested approach:
http://article.gmane.org/gmane.comp.version-control.git/239569
His patch
On Wed, Feb 05, 2014 at 09:17:47AM -0800, Junio C Hamano wrote:
Adrian Johnson ajohn...@redneon.com writes:
- |[0-9][-+0-9#_.eE]
+ |[-+]?[0-9][0-9#_.aAbBcCdDeEfF]*([eE][+-]?[0-9_]+)?
This would match a lot wider than what I read you said you wanted to
match in your previous
On Wed, Feb 05, 2014 at 08:57:08PM +0400, Kirill Smelkov wrote:
Kirill Smelkov (4):
tree-diff: allow diff_tree_sha1 to accept NULL sha1
tree-diff: convert diff_root_tree_sha1() to just call diff_tree_sha1
with old=NULL
line-log: convert to using diff_tree_sha1()
revision:
On Wed, Feb 05, 2014 at 08:57:12PM +0400, Kirill Smelkov wrote:
Since diff_tree_sha1() can now accept empty trees via NULL sha1, we
could just call it without manually reading trees into tree_desc and
duplicating code.
Besides, that
if (!tree)
return 0;
looked
This started with the desire to move the setting of the LESS and LV
environment variables into a Makefile knob. But there's a fair bit of
infrastructure involved in that, and this is an attempt to factor out
some of that infrastructure to be more easily reusable. And if we like
the approach, we
keeps gitweb as a target so that make gitweb continues
to work, in case anybody is using that.
Signed-off-by: Jeff King p...@peff.net
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 3cd4a92..1f3e5d9 100644
--- a/Makefile
+++ b/Makefile
dependencies.
In practice, this is very unlikely to happen, as the
followup run would have to have changed the variable to
match the truncation exactly. However, it is good hygiene to
use our usual tempfile + mv trick to make sure that the file
is created atomically.
Signed-off-by: Jeff King p
. This
is not generally a problem in practice, since most of the
files always have some boilerplate (even LDFLAGS, because it
is formed with +=, will have a stray space in it). But
this does fix the rare case, and future-proofs us as we add
more similar variables.
Signed-off-by: Jeff King p...@peff.net
101 - 200 of 13736 matches
Mail list logo
