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 ar
} 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
to
Hi Stefan,
Stefan Beller wrote:
> On 22.12.2014 13:22, Junio C Hamano wrote:
>> Loic Dachary 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 the
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 propo
(sorry for the repost, I use gmail and it send html mails by default).
On 22 December 2014 at 11:48, Thomas Rast 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 fairly
> succ
On 22.12.2014 13:22, Junio C Hamano wrote:
> Loic Dachary 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
>> dele
On 22.12.2014 14:52, Eric Sunshine wrote:
> On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller wrote:
>> From: Ronnie Sahlberg
>>
>> 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-
Junio C Hamano writes:
> Jim Hill 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 becomes unwanted only wh
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 propo
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller 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 disruption
> as possible
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 22.12.14 19:02, Junio C Hamano wrote:
> dev+...@drbeat.li writes:
>
>> From: Beat Bolli
>>
>> 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 spea
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 repo
Junio C Hamano wrote:
> Junio C Hamano writes:
>> From: Ben Walton
>>
>> 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
>> a
Junio C Hamano writes:
> From: Ben Walton
>
> 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
>
>
Junio C Hamano writes:
> From: Ben Walton
>
> 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
>
>
From: Ben Walton
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
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
Johannes Schindelin 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) \
> F(MISSING_SOMETHING_VITAL, FATAL_
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 22 Dec 2014, Junio C Hamano wrote:
>
>> Johannes Schindelin 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
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller wrote:
> From: Ronnie Sahlberg
>
> 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: Ronnie Sahlberg
> Signed-off-by:
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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,
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Mon, 22 Dec 2014, Junio C Hamano wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> >> In other words, at some point wouldn't we be better off with
> >> >> something like this
> >> >>
> >> >>
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller wrote:
> From: Ronnie Sahlberg
>
> 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 atomic push back.
>
> There is cu
Johannes Schindelin 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 configuration variable
names, s
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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-
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 22 Dec 2014, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> >> In other words, at some point wouldn't we be better off with
>> >> something like this
>> >>
>> >> struct {
>> >> enum id;
>> >> const ch
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 10 Dec 2014, Junio C Hamano wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > The 'invalid tag name' and 'missing tagger entry' warnings can now be
> >> > upgraded to errors by setting recei
Johannes Schindelin 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, but looks slightly
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 e
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Ben Walton 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 c
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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, by
> > allowing
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 receive-pack` when `recei
Junio C Hamano 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 to find and
ex
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 10 Dec 2014, Junio C Hamano wrote:
>
>> Johannes Schindelin 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-ta
Junio C Hamano wrote:
> Ben Walton 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
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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'.
>
> Hmm, why can'
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 ()
Johannes Schindelin 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 };
>> } possible_f
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 the patch makes
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 problem specifically.
>
Ben Walton 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 -v c=0
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 last level of
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 object that has been h
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 partial strings becau
Loic Dachary 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 c0633abdc531135
Tony Finch 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 (master) 0
Yi EungJun writes:
> From: Yi EungJun
>
> 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
Junio C Hamano wrote:
> Eric Wong 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
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 wit
Eric Wong 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
inapplicab
William Throwe 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: external filte
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
Stefan Beller 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 decide betwe
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 (
dev+...@drbeat.li writes:
> From: Beat Bolli
>
> 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 to
preve
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
Stefan Beller 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
> ---
>
> Notes:
> I'll also try to send it upstream to linux.
Thanks.
Stefan Beller writes:
> This adds an explanation of why you want to have the --notes option
> given to git format-patch.
>
> Signed-off-by: Stefan Beller
> ---
>
> Notes:
> > with optionally update Documentation/SubmittingPatches
> > to point at the file.
>
> That file actually
Johannes Schindelin 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 seem like a mist
Johannes Schindelin 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 in fact,
> fsck_wal
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin 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.
>
> fsck: introdu
Tony Finch writes:
> Signed-off-by: Tony Finch
> ---
> 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
>
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] withou
Signed-off-by: Johannes Schindelin
---
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 set-url origin newurl oldurl
Anastas Dancha reported that it is not possible to add a remote when
there is already a url..insteadOf = 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 adding a rem
From: Yi EungJun
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 -> "Accept-Language: ko, *;
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
Mike Hommey 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 line "unsubscri
On Mon, Dec 22, 2014 at 3:04 PM, Andreas Schwab 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: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linu
Signed-off-by: Tony Finch
---
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
+++ b/contrib/completion/git-prompt.sh
@@
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: [b2776bf71
On Sun, Dec 21, 2014 at 8:12 PM, brian m. carlson
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 tedious on older platforms
Patrick Reynolds 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 only one
>
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 do
[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
76 matches
Mail list logo
