Re: [PATCH v2 2/2] mailinfo: unescape quoted-pair in header fields

On Mon, Sep 26, 2016 at 12:38:42AM +0200, Jakub Narębski wrote: > W dniu 25.09.2016 o 22:17, Kevin Daudt pisze: > > On Fri, Sep 23, 2016 at 12:15:41AM -0400, Jeff King wrote: > > >> Oops, yes. It is beginning to make the "strbuf_swap()" look less > >> convoluted. :) > >> > > > > I've switched to

Re: Changing the default for "core.abbrev"?

On Sun, Sep 25, 2016 at 9:34 PM, Jeff King wrote: > > An easier (but less automatic) tool would be to improve our error > message for the ambiguous case, and actually report details of the > candidates. I'm working up a patch now. That sounds like a fun little lunch-break project.

Re: Changing the default for "core.abbrev"?

On Sun, Sep 25, 2016 at 08:46:39PM -0700, Junio C Hamano wrote: > Linus Torvalds writes: > > > I can just keep reminding kernel maintainers and developers to update > > their git config, but maybe it would be a good idea to just admit that > > the defaults picked

[PATCH] unpack_sha1_header(): detect malformed object header

When opening a loose object file, we often do this sequence: - prepare a short buffer for the object header (on stack) - call unpack_sha1_header() and have early part of the object data inflated, enough to fill the buffer - parse that data in the short buffer, assuming that the first part

Re: Changing the default for "core.abbrev"?

Linus Torvalds writes: > I can just keep reminding kernel maintainers and developers to update > their git config, but maybe it would be a good idea to just admit that > the defaults picked in 2005 weren't necessarily the best ones > possible, and those could be

Changing the default for "core.abbrev"?

The default value for commit abbreviation (environment.c: 19) is seven: int minimum_abbrev = 4, default_abbrev = 7; which back in the dark early days of git was fairly reasonable. It's probably still a perfectly fine default for lots of projects, since 7 hex digits is a few hundred million

Re: [RFC PATCH v2] revision: new rev^-n shorthand for rev^n..rev

"Philip Oakley" writes: > From: "Vegard Nossum" >>I use rev^..rev daily, and I'm surely not the only one. > > Not everyone knows the 'trick' and may not use it daily. > > Consider stating what it is useful for (e.g. "useful to get the > commits

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Gustavo Grieco writes: > We found a stack read out-of-bounds parsing object files using git 2.10.0. It > was tested on ArchLinux x86_64. To reproduce, first recompile git with ASAN > support and then execute: > > $ git init ; mkdir -p .git/objects/b2 ; printf 'x' > >

Re: [PATCH 1/3 v3] submodules: make submodule-prefix option an envvar

Brandon Williams writes: > Add a submodule-prefix enviorment variable environment? > 'GIT_INTERNAL_SUBMODULE_PREFIX' which can be used by commands which have > --recurse-submodule options. > > Signed-off-by: Brandon Williams > --- > cache.h | 1 + >

Re: [PATCH v2 00/11] Mark strings in perl script for translation

Junio C Hamano writes: > Vasco Almeida writes: > >> Mark messages in some perl scripts for translation. >> >> Since v1, adds brackets so parameter grouping of sprintf parameters is easier >> to see. >> >> Interdiff included below. > > Thanks; it is way

Re: [PATCH v2 11/11] i18n: difftool: mark warnings for translation

Vasco Almeida writes: > - warn << 'EOF'; > + warn __ <<'EOF'; > Combined diff formats ('-c' and '--cc') are not supported in > directory diff mode ('-d' and '--dir-diff'). > EOF Wow, didn't imagine gettext would pick this up.

Re: [PATCH v2 08/11] i18n: send-email: mark strings for translation

Vasco Almeida writes: > @@ -1403,7 +1412,7 @@ Message-Id: $message_id > if ($quiet) { > printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject); > } else { > - print (($dry_run ? "Dry-" : "")."OK. Log says:\n"); > + print

Re: [PATCH v2 08/11] i18n: send-email: mark strings for translation

Vasco Almeida writes: > - $_ = ask("What to do with this address? ([q]uit|[d]rop|[e]dit): > ", > + # TRANSLATORS: Make sure to include [q] [d] [e] in your > + # translation. The program will only accept English input > + #

Re: [PATCH v2 06/11] i18n: add--interactive: i18n of help_patch_cmd

Vasco Almeida writes: > sub help_patch_cmd { > - my $verb = lc $patch_mode_flavour{VERB}; > - my $target = $patch_mode_flavour{TARGET}; > - print colored $help_color, < -y - $verb this hunk$target > -n - do not $verb this hunk$target > -q - quit; do not $verb

Re: [PATCH v2 05/11] i18n: add--interactive: mark message for translation

Vasco Almeida writes: > - print colored $prompt_color, $patch_mode_flavour{VERB}, > - ($hunk[$ix]{TYPE} eq 'mode' ? ' mode change' : > -$hunk[$ix]{TYPE} eq 'deletion' ? ' deletion' : > -' this hunk'), > -

Re: [PATCH v2 03/11] i18n: add--interactive: mark strings with interpolation for translation

Vasco Almeida writes: > @@ -1048,7 +1048,7 @@ sub edit_hunk_manually { > my $hunkfile = $repo->repo_path . "/addp-hunk-edit.diff"; > my $fh; > open $fh, '>', $hunkfile > - or die "failed to open hunk edit file for writing: " . $!; > +

Re: [PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation

Vasco Almeida writes: > -Prompt help: > + print colored $help_color, __( > +"Prompt help: > 1 - select a numbered item > foo- select item based on unique prefix > - - (empty) select nothing > -EOF > + - (empty) select nothing"), >

Re: [PATCH v2 01/11] i18n: add--interactive: mark strings for translation

Vasco Almeida writes: > Mark simple strings (without interpolation) for translation. > > Brackets around first parameter of ternary operator is necessary because > otherwise xgettext fails to extract strings marked for translation from > the rest of the file. > >

Re: [PATCH v2 2/2] mailinfo: unescape quoted-pair in header fields

W dniu 25.09.2016 o 22:17, Kevin Daudt pisze: > On Fri, Sep 23, 2016 at 12:15:41AM -0400, Jeff King wrote: >> Oops, yes. It is beginning to make the "strbuf_swap()" look less >> convoluted. :) >> > > I've switched to strbuf_swap now, much better. I've implemented > recursive parsing without

[PATCH v3 2/2] mailinfo: unescape quoted-pair in header fields

rfc2822 has provisions for quoted strings and comments in structured header fields, but also allows for escaping these with so-called quoted-pairs. The only thing git currently does is removing exterior quotes, but quotes within are left alone. Remove exterior quotes and remove escape characters

[PATCH v3 1/2] t5100-mailinfo: replace common path prefix with variable

Many tests need to store data in a file, and repeat the same pattern to refer to that path: "$TEST_DIRECTORY"/t5100/ Create a variable that contains this path, and use that instead. Signed-off-by: Kevin Daudt Signed-off-by: Junio C Hamano --- Changes

Re: [PATCH v2 2/2] mailinfo: unescape quoted-pair in header fields

On Fri, Sep 23, 2016 at 12:15:41AM -0400, Jeff King wrote: > On Thu, Sep 22, 2016 at 03:17:23PM -0700, Junio C Hamano wrote: > > > Jeff King writes: > > > > > On Mon, Sep 19, 2016 at 08:54:40PM +0200, Kevin Daudt wrote: > > > > > >> + ... > > >> +while ((c = *in++) != 0)

[RFC PATCH v3] revision: new rev^-n shorthand for rev^n..rev

I often use rev^..rev to get all the commits in the branch that was merged in by the merge commit 'rev' (including the merge itself). To save typing (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name) we can make rev^- a shorthand for that. The existing syntax rev^! seems

Re: [PATCH] git-gui: stop using deprecated merge syntax

Johannes Sixt writes: > Am 24.09.2016 um 13:30 schrieb René Scharfe: >> Starting with v2.5.0 git merge can handle FETCH_HEAD internally and >> warns when it's called like 'git merge HEAD ' because >> that syntax is deprecated. Use this feature in git-gui and get rid of >> that

Re: [PATCH 0/3] recursive support for ls-files

Brandon Williams writes: > On 09/25, Jeff King wrote: >> On Fri, Sep 23, 2016 at 05:13:31PM -0700, Brandon Williams wrote: >> >> > After looking at the feedback I rerolled a few things, in particular the >> > --submodule_prefix option that existed to give a submodule context

Re: [PATCH v3 0/2] patch-id for merges

Hi Peff, On Fri, 9 Sep 2016, Jeff King wrote: > Frankly, I still like v2 better, but I do not feel like arguing with > Johannes about it anymore. Sorry that I was a pest. I do care deeply about making our code cleaner, though, which in my mind means less of this "let exit() clean everything up

Re: Git garden shears, was Re: [PATCH 13/22] sequencer: remember the onelines when parsing the todo file

Hi Kuba, On Wed, 21 Sep 2016, Jakub Narębski wrote: > W dniu 11.09.2016 o 10:33, Johannes Schindelin napisał: > > On Fri, 9 Sep 2016, Jakub Narębski wrote: > [...] > > >> When preserving merges, there are (as far as I understand it), two > >> problems: > >> - what it means to preserve changes

Re: [PATCH v4 2/2] gitweb: use highlight's shebang detection

W dniu 25.09.2016 o 00:32, Ian Kelling pisze: > The "highlight" binary can, in some cases, determine the language type > by the means of file contents, for example the shebang in the first line > for some scripting languages. Make use of this autodetection for files > which syntax is not known by

Re: [RFC PATCH v2] revision: new rev^-n shorthand for rev^n..rev

From: "Vegard Nossum" I use rev^..rev daily, and I'm surely not the only one. Not everyone knows the 'trick' and may not use it daily. Consider stating what it is useful for (e.g. "useful to get the commits and all commits in the branches that were merged into

Re: [PATCH 0/3] recursive support for ls-files

On 09/25, Jeff King wrote: > On Fri, Sep 23, 2016 at 05:13:31PM -0700, Brandon Williams wrote: > > > After looking at the feedback I rerolled a few things, in particular the > > --submodule_prefix option that existed to give a submodule context about > > where > > it had been invoked from.

Re: [PATCH v8 10/11] convert: make apply_filter() adhere to standard Git error handling

W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > From: Lars Schneider > > apply_filter() returns a boolean that tells the caller if it > "did convert or did not convert". The variable `ret` was used throughout > the function to track errors whereas `1`

Re: [PATCH v8 09/11] convert: modernize tests

W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > From: Lars Schneider > > Use `test_config` to set the config, check that files are empty with > `test_must_be_empty`, compare files with `test_cmp`, and remove spaces > after ">" and "<". That's good. > >

git-pack-objects(1): --honor-pack-keep

Hi All, the option `--honor-pack-keep` is not mentioned in the `SYNOPSIS` of `git-pack-objects(1)` (`Documentation/git-pack-objects.txt`), only below in the `OPTIONS`. The same story with `--include-tag`, `--window-memory`, `--max-pack-size`, `--no-reuse-object`, `--compression`, `--thin`,

Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Hi, We found a stack read out-of-bounds parsing object files using git 2.10.0. It was tested on ArchLinux x86_64. To reproduce, first recompile git with ASAN support and then execute: $ git init ; mkdir -p .git/objects/b2 ; printf 'x' > .git/objects/b2/93584ddd61af21260be75ee9f73e9d53f08cd0

Re: [RFC PATCH v2] revision: new rev^-n shorthand for rev^n..rev

W dniu 25.09.2016 o 10:55, Vegard Nossum pisze: > I use rev^..rev daily, and I'm surely not the only one. To save typing > (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name) > we can make rev^- a shorthand for that. > > The existing syntax rev^! seems like it should do the

Re: Journal of Failed Git Experiments, Volume 1

Hi Peff, On Wed, 14 Sep 2016, Jeff King wrote: > I try a lot of different experiments with git performance, some of them > more hare-brained than others. The ones that succeed end up as real > patches. But I hate for the ones that fail to die a quiet death. Then > nobody learns what _doesn't_

Re: [RFC PATCH v2] revision: new rev^-n shorthand for rev^n..rev

On 25/09/16 09:55, Vegard Nossum wrote: > I use rev^..rev daily, and I'm surely not the only one. To save typing > (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name) > we can make rev^- a shorthand for that. > > The existing syntax rev^! seems like it should do the same,

Re: [PATCH v8 08/11] convert: quote filter names in error messages

W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > From: Lars Schneider > > Git filter driver commands with spaces (e.g. `filter.sh foo`) are hard > to read in error messages. Quote them to improve the readability. > > Signed-off-by: Lars Schneider

Re: [PATCH v4 3/3] regex: use regexec_buf()

Hi Peff, On Wed, 21 Sep 2016, Jeff King wrote: > On Wed, Sep 21, 2016 at 08:24:14PM +0200, Johannes Schindelin wrote: > > > The new regexec_buf() function operates on buffers with an explicitly > > specified length, rather than NUL-terminated strings. > > > > We need to use this function

Re: [PATCH v8 07/11] pkt-line: add functions to read/write flush terminated packet streams

W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > From: Lars Schneider > > write_packetized_from_fd() and write_packetized_from_buf() write a > stream of packets. All content packets use the maximal packet size > except for the last one. After the last

Re: [PATCH v8 06/11] pkt-line: add packet_write_gently()

W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > From: Lars Schneider > > packet_write_fmt_gently() uses format_packet() which lets the caller > only send string data via "%s". That means it cannot be used for > arbitrary data that may contain NULs. > > Add

Re: [PATCH 1/2] ls-files: adding support for submodules

On Sat, Sep 24, 2016 at 12:34 AM, Stefan Beller wrote: > git -C path/to/sub --keep-prefix ls-files Note that the above can also be written like so (and works identically), due to the fact that -C can be given multiple times: git -C path -C to -C sub --keep-prefix

Re: [RFC PATCH v2] revision: new rev^-n shorthand for rev^n..rev

Vegard Nossum writes: > Documentation/revisions.txt | 14 +++ > builtin/rev-parse.c | 28 ++ > revision.c | 91 > + > revision.h | 1 + This would obviously need

Re: [PATCH 1/2] add COPY_ARRAY

Am 25.09.2016 um 09:41 schrieb Jeff King: On Sun, Sep 25, 2016 at 09:15:42AM +0200, René Scharfe wrote: It checks if the multiplication of size and element count overflows. The inferred size is passed first to st_mult, which allows the division there to be done at compilation time. I wonder

[RFC PATCH v2] revision: new rev^-n shorthand for rev^n..rev

I use rev^..rev daily, and I'm surely not the only one. To save typing (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name) we can make rev^- a shorthand for that. The existing syntax rev^! seems like it should do the same, but it doesn't really do the right thing for merge

Re: [PATCH 1/2] add COPY_ARRAY

On Sun, Sep 25, 2016 at 09:15:42AM +0200, René Scharfe wrote: > Add COPY_ARRAY, a safe and convenient helper for copying arrays, > complementing ALLOC_ARRAY and REALLOC_ARRAY. Users just specify source, > destination and the number of elements; the size of an element is > inferred automatically.

Re: [PATCH 6/7] use COPY_ARRAY

Ha, can't count. It should be [PATCH 2/2] of course. René

[PATCH 6/7] use COPY_ARRAY

Add a semantic patch for converting certain calls of memcpy(3) to COPY_ARRAY() and apply that transformation to the code base. The result is shorter and safer code. For now only consider calls where source and destination have the same type, or in other words: easy cases. Signed-off-by: Rene

Re: [PATCH 0/3] recursive support for ls-files

On Fri, Sep 23, 2016 at 05:13:31PM -0700, Brandon Williams wrote: > After looking at the feedback I rerolled a few things, in particular the > --submodule_prefix option that existed to give a submodule context about where > it had been invoked from. People didn't seem to like the idea of

[PATCH 1/2] add COPY_ARRAY

Add COPY_ARRAY, a safe and convenient helper for copying arrays, complementing ALLOC_ARRAY and REALLOC_ARRAY. Users just specify source, destination and the number of elements; the size of an element is inferred automatically. It checks if the multiplication of size and element count overflows.

Request: Extra case for %G? format

Hello all, Could the %G? format differentiate between an unsigned commit and a signed commit that you're missing a public key for? If `git show --format=%GG --no-patch ' produces an output like the following: gpg: Signature made using RSA key ID gpg: Can't check signature: public key not