[redirected from off-list conversation]
On Sun, Dec 21, 2014 at 01:57:55PM -0700, Tim Harper wrote:
I've noticed an issue in the builds script for 2.2.1 in which `make
all` seems to invalidate itself. The first and second invocation of
make all will compile all sources, but the 3rd finally
I have been working with Peff on this and have more results to share.
For background, xdl_hash_record is a hashing function, producing an
unsigned long from an input string terminated by either a newline or
the end of the mmap'd file.
The original xdl_hash_record is essentially DJB hash, which
Patrick Reynolds p...@github.com writes:
The original xdl_hash_record is essentially DJB hash, which does a
multiplication, load, and xor for each byte of the input. Commit
6942efc introduces an XDL_FAST_HASH version of the same function
that is clearly inspired by the DJB hash, but it does
On Sun, Dec 21, 2014 at 8:12 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sun, Dec 21, 2014 at 10:53:35AM -0800, Reuben Hawkins wrote:
CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3
systems being used in production. This change makes compiling git
less
Running git bisect bad should be the same as git bisect bad HEAD,
shouldn't it?
When replaying this bisect log on the Linux kernel tree:
git bisect start
# bad: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linux 3.19-rc1
git bisect bad 97bf6af1f928216fd6c5a66e8a57bfa95a659672
# good:
Signed-off-by: Tony Finch d...@dotat.at
---
contrib/completion/git-prompt.sh | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c5473dc..5fe69d0 100644
--- a/contrib/completion/git-prompt.sh
+++
On Mon, Dec 22, 2014 at 3:04 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Running git bisect bad should be the same as git bisect bad HEAD,
shouldn't it?
Yeah, it should.
When replaying this bisect log on the Linux kernel tree:
git bisect start
# bad:
Mike Hommey m...@glandium.org writes:
1. I think it should, as long as the given sha1 is reachable from the
public heads, but that's offtopic here.
Sounds vaguely familiar:
http://thread.gmane.org/gmane.comp.version-control.git/178814/focus=179007
--
To unsubscribe from this list: send the
Changes since v5
From Junio C Hamano's review:
* The tests use `ls-remote` instead of `clone` for tests; I copied the test
code from ba8e63dc30a80656fddc616f714fb217ad220c04.
* Set cached_accept_langauge to NULL after free it.
From Eric Sunshine's review:
* get_accept_language() returns a
From: Yi EungJun eungjun...@navercorp.com
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
Examples:
LANGUAGE= -
LANGUAGE=ko:en - Accept-Language: ko, en;q=0.9, *;q=0.1
LANGUAGE=ko LANG=en_US.UTF-8 -
Anastas Dancha reported that it is not possible to add a remote when
there is already a url.url.insteadOf = nick setting in
$HOME/.gitconfig.
While it makes sense to prevent surprises when a user adds a remote and
it fetches from somewhere completely different, it makes less sense to
prevent
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t5505-remote.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index ac79dd9..17c6330 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -1113,4 +1113,9 @@ test_extra_arg
When adding a remote, we make sure that the remote does not exist
already.
For convenience, we allow re-adding remotes with the same URLs.
This also handles the case that there is an [url ...] insteadOf
setting in the config.
It might seem like a mistake to compare against remote-url[0] without
Tony Finch d...@dotat.at writes:
Signed-off-by: Tony Finch d...@dotat.at
---
contrib/completion/git-prompt.sh | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index c5473dc..5fe69d0 100644
---
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Subject: Re: [PATCH 01/18] Introduce fsck options
please make it easier to cluster and spot the series in the eventual
shortlog by giving a common prefix to the patches, e.g.
Johannes Schindelin johannes.schinde...@gmx.de writes:
Is it a good idea to allow walker to be strict but obj verifier to
be not (or vice versa)? I am wondering why this is not a single
struct with two callback function pointers.
Unfortunately not. There are two different walkers used, and
Johannes Schindelin johannes.schinde...@gmx.de writes:
When adding a remote, we make sure that the remote does not exist
already.
For convenience, we allow re-adding remotes with the same URLs.
This also handles the case that there is an [url ...] insteadOf
setting in the config.
It might
Stefan Beller sbel...@google.com writes:
This adds an explanation of why you want to have the --notes option
given to git format-patch.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
with optionally update Documentation/SubmittingPatches
to point at the file.
Stefan Beller sbel...@google.com writes:
The Developers Certificate of Origin has a mixture of tabs and white
spaces which is annoying to view if your editor explicitly views white
space characters.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
I'll also try to send it
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dev+...@drbeat.li writes:
From: Beat Bolli dev+...@drbeat.li
The value is the same on both uniset invocations, so Don't Repeat
Yourself applies.
Since we're in a subshell already, there's no need to unset UNICODE_DIR
at the end.
Strictly speaking, you are not introducing your own subshell
If you have a prompt which displays the command exit status,
__git_ps1 without this change corrupts it, although it has
the correct value in the parent shell:
~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(__git_ps1) $? \$ '
~/src/git (master) 0 $ false
~/src/git
Stefan Beller sbel...@google.com writes:
Notes:
This patch is new with v6 of the series
As execute_commands_non_atomic is larger than execute_commands, the diff
is not moving around execute_commands_non_atomic, but execute_commands.
;-)
Next time perhaps try --patience to
Will queue; thanks for a pleasant read.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
William Throwe w...@cornell.edu writes:
In git 2.2.0 (also tested on 2.2.0.65.g9abc44b), if an external
smudge/clean filter is called on an empty file git reports something
like:
error: copy-fd: read returned Bad file descriptor
error: cannot feed the input to external filter cat
error:
Eric Wong normalper...@yhbt.net writes:
Normally I would use -D, but send-email (which normally passes options
to format-patch) interprets the -D as a case-insensitive abbreviation
for --dry-run, preventing format-patch from seeing -D.
Is this nonstandard option that is designed to produce an
The awk statements previously used in this test weren't compatible
with the native versions of awk on Solaris:
echo dir | /bin/awk -v c=0 '$1 {++c} END {print c}'
awk: syntax error near line 1
awk: bailing out near line 1
echo dir | /usr/xpg4/bin/awk -v c=0 '$1 {++c} END {print c}'
0
And with
Junio C Hamano gits...@pobox.com wrote:
Eric Wong normalper...@yhbt.net writes:
Normally I would use -D, but send-email (which normally passes options
to format-patch) interprets the -D as a case-insensitive abbreviation
for --dry-run, preventing format-patch from seeing -D.
Is this
Yi EungJun semtlen...@gmail.com writes:
From: Yi EungJun eungjun...@navercorp.com
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
Examples:
LANGUAGE= -
LANGUAGE=ko:en - Accept-Language: ko, en;q=0.9,
Tony Finch d...@dotat.at writes:
If you have a prompt which displays the command exit status,
__git_ps1 without this change corrupts it, although it has
the correct value in the parent shell:
~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(__git_ps1) $? \$ '
~/src/git
Loic Dachary l...@dachary.org writes:
Hi,
Steps to reproduce:
$ git --version
git version 1.9.1
$ wc -l /tmp/1
9090 /tmp/1
$ head /tmp/1
delete refs/pull/1/head
create refs/heads/pull/1 86b715f346e52920ca7c9dfe65424eb9946ebd61
delete refs/pull/1/merge
create refs/merges/1
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
This function will be used in the next commits to allow the user to
ask fsck to handle specific problems differently, e.g. demoting certain
errors to warnings. It has to handle
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
There are legacy repositories out there whose older commits and tags
have issues that prevent pushing them when 'receive.fsckObjects' is set.
One real-life example is a commit
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
For example, missing emails in commit and tag objects can be demoted to
mere warnings with
git config receive.fsck.missing-email warn
No punctuations in the first and the
Ben Walton bdwal...@gmail.com writes:
The awk statements previously used in this test weren't compatible
with the native versions of awk on Solaris:
echo dir | /bin/awk -v c=0 '$1 {++c} END {print c}'
awk: syntax error near line 1
awk: bailing out near line 1
echo dir | /usr/xpg4/bin/awk
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
This problem has been detected in the wild, and is the primary reason
to introduce an option to demote certain fsck errors to warnings. Let's
offer to ignore this particular
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Some kinds of errors are intrinsically unrecoverable (e.g. errors while
uncompressing objects). It does not make sense to allow demoting them to
mere warnings.
Makes sense, but
Johannes Schindelin johannes.schinde...@gmx.de writes:
In other words, at some point wouldn't we be better off with
something like this
struct {
enum id;
const char *id_string;
enum error_level { FSCK_PASS, FSCK_WARN, FSCK_ERROR };
}
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by setting receive.fsck.invalid-tag-name and
receive.fsck.missing-tagger-entry to 'error'.
Ben Walton wrote:
echo dir | /usr/xpg4/bin/awk -v c=0 '$1 {++c} END {print c}'
0
Thanks. Weird. Does
awk -v c=0 '$1 != {++c} END {print c}'
work better?
[...]
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -22,7 +22,7 @@ generate_expected_cache_tree_rec () {
Junio C Hamano wrote:
Ben Walton bdwal...@gmail.com writes:
echo dir | /usr/xpg4/bin/awk -v c=0 '$1 {++c} END {print c}'
0
And with GNU awk for comparison:
echo dir | /opt/csw/gnu/awk -v c=0 '$1 {++c} END {print c}'
1
Instead of modifying the awk code to work, use wc -w instead as that
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by setting
Junio C Hamano gits...@pobox.com wrote:
Yes. I wouldn't have spent 20 minutes experimenting with various
hypothetical use cases if the above were there in the first place.
Sorry for wasting your time, and thanks for reviewing the patch.
(I am so used to having $? in my prompt it took me ages
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
The optional new config option `receive.fsck.skip-list` specifies the path
to a file listing the names, i.e. SHA-1s, one per line, of objects that
are to be ignored by `git
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
We already have support in `git receive-pack` to deal with some legacy
repositories which have non-fatal issues.
Let's make `git fsck` itself useful with such repositories, too,
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Ben Walton bdwal...@gmail.com writes:
echo dir | /usr/xpg4/bin/awk -v c=0 '$1 {++c} END {print c}'
0
And with GNU awk for comparison:
echo dir | /opt/csw/gnu/awk -v c=0 '$1 {++c} END {print c}'
1
Instead of modifying the
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
In other words, at some point wouldn't we be better off with
something like this
struct {
enum id;
const char *id_string;
Johannes Schindelin johannes.schinde...@gmx.de writes:
Or do you want the error messages to also use camelCased IDs, i.e.
warning in tag $tag: missingTaggerEntry: invalid format ...
instead of
warning in tag $tag: missing-tagger-entry: invalid format ...
? It is easy to do,
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
In other words, at some point wouldn't we be better off with
something like this
struct {
enum id;
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
On Wed, 10 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
The 'invalid tag name' and 'missing tagger entry' warnings can now be
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Or do you want the error messages to also use camelCased IDs, i.e.
warning in tag $tag: missingTaggerEntry: invalid format ...
instead of
warning in tag $tag:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Of course you can say that! ;-) The problem these ugly messages try to
solve is to give the user a hint which setting to change if they want to
override the default behavior, though...
Ahh, OK, then dashed form would not work as a
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller sbel...@google.com wrote:
From: Ronnie Sahlberg sahlb...@google.com
This adds support to the protocol between send-pack and receive-pack to
* allow receive-pack to inform the client that it has atomic push capability
* allow send-pack to request
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
In other words, at some point wouldn't we be better off with
something
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Of course you can say that! ;-) The problem these ugly messages try to
solve is to give the user a hint which setting to change if they want to
override the default behavior,
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller sbel...@google.com wrote:
From: Ronnie Sahlberg sahlb...@google.com
This adds support to send-pack to negotiate and use atomic pushes
iff the server supports it. Atomic pushes are activated by a new command
line flag --atomic.
Signed-off-by:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Of course you can say that! ;-) The problem these ugly messages try to
solve is to give the user a hint which setting to
Johannes Schindelin johannes.schinde...@gmx.de writes:
For example, try to spot the error here:
...
F(ALMOST_HAPPY, INFO) \
F(CANNOT_RECOVER, ERROR) \
F(COFFEE_IS_EMPTY, WARN) \
F(JUST_BEING_CHATTY, INFO) \
F(LIFE_IS_GOOD, INFO) \
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Quite a few topics have been merged to 'master' as the third batch
for this cycle, on top of the recent case sensitive .Git fix that
has been
From: Ben Walton bdwal...@gmail.com
The awk statements previously used in this test weren't compatible
with the native versions of awk on Solaris:
echo dir | /bin/awk -v c=0 '$1 {++c} END {print c}'
awk: syntax error near line 1
awk: bailing out near line 1
echo dir |
Junio C Hamano gits...@pobox.com writes:
From: Ben Walton bdwal...@gmail.com
The awk statements previously used in this test weren't compatible
with the native versions of awk on Solaris:
echo dir | /bin/awk -v c=0 '$1 {++c} END {print c}'
awk: syntax error near line 1
awk:
Junio C Hamano gits...@pobox.com writes:
From: Ben Walton bdwal...@gmail.com
The awk statements previously used in this test weren't compatible
with the native versions of awk on Solaris:
echo dir | /bin/awk -v c=0 '$1 {++c} END {print c}'
awk: syntax error near line 1
awk:
Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
From: Ben Walton bdwal...@gmail.com
The awk statements previously used in this test weren't compatible
with the native versions of awk on Solaris:
echo dir | /bin/awk -v c=0 '$1 {++c} END {print c}'
awk: syntax error
Hi,
There are two major differences between adding notes with fast-import
and git notes, one of which is a serious problem:
- fast-import doesn't want to add notes for non commits, while git notes
does.
- fast-import and git notes have different, conflicting fanouts:
- take e.g. the git
On 22.12.14 19:02, Junio C Hamano wrote:
dev+...@drbeat.li writes:
From: Beat Bolli dev+...@drbeat.li
The value is the same on both uniset invocations, so Don't Repeat
Yourself applies.
Since we're in a subshell already, there's no need to unset UNICODE_DIR
at the end.
Strictly
btw, just FYI, the scheme you lay out here doesn't actually work
as-is. The problem is the config file, which has an entry like:
worktree = ../../../mysubmodule
This depends on the config file living in
./git/modules/mysubmodule/config. But the proposed scheme moves the
config file to
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller sbel...@google.com wrote:
Update receive-pack to use an atomic transaction iff the client negotiated
that it wanted atomic-push. This leaves the default behavior to be the old
non-atomic one ref at a time update. This is to cause as little
Craig Silverstein wrote:
btw, just FYI, the scheme you lay out here doesn't actually work
as-is. The problem is the config file, which has an entry like:
worktree = ../../../mysubmodule
This depends on the config file living in
./git/modules/mysubmodule/config. But the proposed
Junio C Hamano gits...@pobox.com writes:
Jim Hill gjth...@gmail.com writes:
I call it unwanted because the default works fine with the actual
input and explicitly limiting whitespace this way breaks most command
substitution.
OK. I'd call that unnecessary, not unwanted, though.
It
On 22.12.2014 14:52, Eric Sunshine wrote:
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller sbel...@google.com wrote:
From: Ronnie Sahlberg sahlb...@google.com
This adds support to the protocol between send-pack and receive-pack to
* allow receive-pack to inform the client that it has atomic
On 22.12.2014 13:22, Junio C Hamano wrote:
Loic Dachary l...@dachary.org writes:
Hi,
Steps to reproduce:
$ git --version
git version 1.9.1
$ wc -l /tmp/1
9090 /tmp/1
$ head /tmp/1
delete refs/pull/1/head
create refs/heads/pull/1 86b715f346e52920ca7c9dfe65424eb9946ebd61
delete
(sorry for the repost, I use gmail and it send html mails by default).
On 22 December 2014 at 11:48, Thomas Rast t...@thomasrast.ch wrote:
1. hash function throughput
2. quality of the hash values
3. avoiding collision attacks
XDL_FAST_HASH was strictly an attempt to improve throughput, and
Craig Silverstein wrote:
btw, just FYI, the scheme you lay out here doesn't actually work
as-is. The problem is the config file, which has an entry like:
worktree = ../../../mysubmodule
This depends on the config file living in
./git/modules/mysubmodule/config. But the proposed
Hi Stefan,
Stefan Beller wrote:
On 22.12.2014 13:22, Junio C Hamano wrote:
Loic Dachary l...@dachary.org writes:
fatal: Unable to create
/home/gitmirror/repositories/Ceph/ceph/refs/heads/pull/1917.lock': Too many
open files
[...]
Stefan, want to take a look? I think we do need to keep
} This seems like good motivation to try to get that series in good
shape and release it soon.
I was going to spend some time tomorrow (if I can find any :-) )
trying to fix up the contrib script to work with submodules, or at
least the kind that we use. Is that something that's worth the time
Hi.
In order to make some analyses here I had to build certain report
lists of our remote refs, based on various containing and merged
rules. We have more than hundred such refs at a time usually. So my
poor script which tries to make decisions with the help of rev-list
for each ref on each
76 matches
Mail list logo
