Hi guys,
for whatever reason my git has started acting up with
sta...@vger.kernel.org addresses. It doesn't manage to extract a valid
adress from the string:
Cc: # v3.4 v3.5 v3.6
Removing the comment at the end of the line makes things work again. I
do remember, however, seeing this working si
On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
> Hi guys,
>
> for whatever reason my git has started acting up with
> sta...@vger.kernel.org addresses. It doesn't manage to extract a valid
> adress from the string:
>
> Cc: # v3.4 v3.5 v3.6
>
> Removing the comment at the end of
Hi,
On Mon, Nov 19, 2012 at 04:18:45PM +0100, Krzysztof Mazur wrote:
> On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
> > Hi guys,
> >
> > for whatever reason my git has started acting up with
> > sta...@vger.kernel.org addresses. It doesn't manage to extract a valid
> > adress fro
On Mon, Nov 19, 2012 at 6:08 AM, Nguyen Thai Ngoc Duy wrote:
> Changes around this code in history is a bit unclear. User format
> learns to get log encoding from a field in 177b29d (pretty.c: teach
> format_commit_message() to reencode the output - 2010-11-02), but this
> field is only set for --
Felipe Contreras writes:
> The second patch is new, in order for users to get the same features when
> sourcing the bash script (they don't need to change anything). They'll get a
> warning suggesting to check the new script git-completion.zsh. Eventually,
> that
> support would be dropped from
Krzysztof Mazur writes:
> On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
>> Hi guys,
>>
>> for whatever reason my git has started acting up with
>> sta...@vger.kernel.org addresses. It doesn't manage to extract a valid
>> adress from the string:
>>
>> Cc: # v3.4 v3.5 v3.6
>>
>
Francis Moreau writes:
> Inside the kernel repository, I tried this:
>
> $ git describe --dirty --match 'v[0-9]*' --abbrev=4 HEAD
> fatal: --dirty is incompatible with committishes
>
> If 'HEAD' is removed then git-describe works as expected.
>
> Is that expected ?
I would say so, at least in mo
Chris Rorvick writes:
> References are allowed to update from one commit-ish to another if the
> former is a ancestor of the latter. This behavior is oriented to
> branches which are expected to move with commits. Tag references are
> expected to be static in a repository, though, thus an updat
Felipe Contreras writes:
> These started from a discussion with SZEDER, but then I realized there were
> many improvements possible.
Thanks; I'd loop him in and wait for his acks/reviews.
>
> Changes since v2:
>
> * Updated comments and commit messages
>
> Changes since v1:
>
> * A lot more c
On Mon, Nov 19, 2012 at 8:36 PM, Junio C Hamano wrote:
> Francis Moreau writes:
>
>> Inside the kernel repository, I tried this:
>>
>> $ git describe --dirty --match 'v[0-9]*' --abbrev=4 HEAD
>> fatal: --dirty is incompatible with committishes
>>
>> If 'HEAD' is removed then git-describe works as
On Sa 17 Nov 2012 20:35:09 CET, Junio C Hamano wrote:
Patrick Lehner writes:
But just because mv's error essage isnt very good, does that mean git
mv's error message mustn't be better?
Did I say the error message from 'mv' was not very good in the
message you are responding to (by the way, t
Nguyễn Thái Ngọc Duy writes:
> We marks pathspec with wildcards with the field use_wildcard. We could
s/marks/mark;
> do better by saving the length of the non-wildcard part, which can be
> for optimizations such as f9f6e2c (exclude: do strcmp as much as
s/for /used &/;
> possible before fnm
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> dir.c | 18 +-
> dir.h | 8
> tree-walk.c | 6 --
> 3 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/dir.c b/dir.c
> index c391d46..e4e6ca1 100644
> --- a/dir
Nguyễn Thái Ngọc Duy writes:
> -O2 build on linux-2.6, without the patch:
Before the result, can you briefly explain what '"*.c" optimization
from exclude' the title talks about is?
When a pattern contains only a single asterisk, e.g. "foo*bar",
after literally comparing the leading pa
On Mon, Nov 19, 2012 at 7:55 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> The second patch is new, in order for users to get the same features when
>> sourcing the bash script (they don't need to change anything). They'll get a
>> warning suggesting to check the new script git-comple
On Mon, Nov 19, 2012 at 8:27 PM, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
>> On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
>>> Hi guys,
>>>
>>> for whatever reason my git has started acting up with
>>> sta...@vger.kernel.org addresses. It doesn't manage to extract a valid
> >> How would the broken repository be sure of what it is missing to
> >> request it from the other side?
> >
> > fsck will find missing objects.
>
> And what about the objects referred to by objects that are missing?
Will be fetched after multiple iterations.
We could even introduce some 'fsck
On Mon, Nov 19, 2012 at 9:34 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> These started from a discussion with SZEDER, but then I realized there were
>> many improvements possible.
>
> Thanks; I'd loop him in and wait for his acks/reviews.
I thought my series-cc-cmd would add him. M
On Mon, Nov 19, 2012 at 11:27:45AM -0800, Junio C Hamano wrote:
> Given that the problematic line
>
> Stable Kernel Maintainance Track # vX.Y
>
> is not even a valid e-mail address, doesn't this new logic belong to
> sanitize_address() conceptually?
Yes, it's much better to do it in the s
According to the man page for git-config, the --git-all option is not
supposed to return an error code:
--get-all
Like get, but does not fail if the number of values for the key is
not exactly one.
IMHO, zero is also "not exactly one", but I still get a 1 exit code if the
key does
Felipe Contreras writes:
> On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur
> wrote:
>
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -924,6 +924,10 @@ sub quote_subject {
>> # use the simplest quoting being able to handle the recipient
>> sub sanitize_address {
>> m
Krzysztof Mazur writes:
> On Mon, Nov 19, 2012 at 11:27:45AM -0800, Junio C Hamano wrote:
>> Given that the problematic line
>>
>> Stable Kernel Maintainance Track # vX.Y
>>
>> is not even a valid e-mail address, doesn't this new logic belong to
>> sanitize_address() conceptually?
>
> Yes
Timur Tabi writes:
> According to the man page for git-config, the --git-all option is not
> supposed to return an error code:
>
> --get-all
> Like get, but does not fail if the number of values for the key is
> not exactly one.
>
> IMHO, zero is also "not exactly one",...
It should
The wording "... is not exactly one." incorrectly hinted as if
having no value is not an error, but that was not what was
intended. Clarify what similarity it wants to mention by
elaborating the "Like get" part of the description.
Signed-off-by: Junio C Hamano
---
Documentation/git-config.txt |
Jeff King writes:
> On Tue, Nov 13, 2012 at 03:13:19PM -0800, Junio C Hamano wrote:
>
>> > static int has_changes(struct diff_filepair *p, struct diff_options *o,
>> > regex_t *regexp, kwset_t kws)
>> > {
>> > + struct userdiff_driver *textconv_one = get_textconv(p->one);
>>
Junio C Hamano writes:
>> Exact renames are the obvious one, but they are not handled here.
>
> That is half true. Before this change, we will find the same number
> of needles and this function would have said "no differences" in a
> very inefficient way. After this change, we may apply differ
Ramkumar Ramachandra writes:
> diff --git a/t/t4041-diff-submodule-option.sh
> b/t/t4041-diff-submodule-option.sh
> index 6c01d0c..e401814 100755
> --- a/t/t4041-diff-submodule-option.sh
> +++ b/t/t4041-diff-submodule-option.sh
> @@ -33,6 +33,7 @@ test_create_repo sm1 &&
> add_file . foo >/dev/
"W. Trevor King" writes:
>> From what I have heard of projects using this: They usually still have
>> something that records the SHA1s on a regular basis. Thinking further,
>> why not record them in git? We could add an option to update which
>> creates such a commit.
>
> I think it's best to hav
On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
>
> >> From what I have heard of projects using this: They usually still have
> >> something that records the SHA1s on a regular basis. Thinking further,
> >> why not record them in git? We could add an opt
On Tue, Nov 20, 2012 at 12:55 AM, Junio C Hamano wrote:
> * fc/remote-testgit-feature-done (2012-10-29) 1 commit
> - remote-testgit: properly check for errors
Pinging Sverre again.
I now think that we need a better solution with waitpid() to check the
status of the process, so that both import
On Mon, Nov 19, 2012 at 2:23 PM, Junio C Hamano wrote:
> Chris Rorvick writes:
>> The object referenced by is used to update the reference
>> -on the remote side, but by default this is only allowed if the
>> -update can fast-forward . By having the optional leading `+`,
>> -you can tell git
"W. Trevor King" writes:
> On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
>> "W. Trevor King" writes:
>> ...
>> > I think it's best to have users craft their own commit messages
>> > explaining why the branch was updated. That said, an auto-generated
>> > hint (a la "git merge"
Chris Rorvick writes:
> On Mon, Nov 19, 2012 at 2:23 PM, Junio C Hamano wrote:
>
> Yeah, this was one of a few stupid mistakes. Previously I used
> 'forwardable' throughout, but that is awkward except in the last
> commit since until then everything is allowed to fast-forward and the
> flag is
From: Nguyễn Thái Ngọc Duy
The MSYS bash mangles arguments that begin with a forward slash
when they are passed to test-wildmatch. This causes tests to fail.
Avoid mangling by prepending "XXX", which is removed by
test-wildmatch before further processing.
[J6t: reworded commit message]
Reported
Am 11/11/2012 11:13, schrieb Nguyễn Thái Ngọc Duy:
> Character class "xdigit" is the only one that hits 6 character limit
> defined by CHAR_CLASS_MAX_LENGTH. All other character classes are 5
> character long and therefore never caught by this.
>
> This should make xdigit tests in t3070 pass on Wi
On Mon, Nov 19, 2012 at 04:00:09PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > On Mon, Nov 19, 2012 at 11:27:45AM -0800, Junio C Hamano wrote:
> >> Given that the problematic line
> >>
> >>Stable Kernel Maintainance Track # vX.Y
> >>
> >> is not even a valid e-mail address
On Mon, Nov 19, 2012 at 03:57:36PM -0800, Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur
> > wrote:
> >
> >> --- a/git-send-email.perl
> >> +++ b/git-send-email.perl
> >> @@ -924,6 +924,10 @@ sub quote_subject {
> >> # use the simplest
Hi,
on reading the docs of "git-svn", I stumbled across this paragraph:
> --follow-parent
> This is especially helpful when we’re tracking a directory that has been
> moved around within the repository, or if we started tracking a branch
> and never tracked the trunk it was descended from. This
On Tue, Nov 20, 2012 at 08:31:00AM +0100, Krzysztof Mazur wrote:
> On Mon, Nov 19, 2012 at 03:57:36PM -0800, Junio C Hamano wrote:
> > Felipe Contreras writes:
> >
> > > On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur
> > > wrote:
> > >
> > >> --- a/git-send-email.perl
> > >> +++ b/git-send-e
39 matches
Mail list logo
