Re: [PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

Jeff King writes: > The get_sha1() family of functions takes a flags field, but > some of the flags are mutually exclusive. In particular, we > can only handle one disambiguating function, and the flags > quietly override each other. Let's instead detect these as > programming

Re: [PATCH 06/10] get_short_sha1: NUL-terminate hex prefix

Jeff King writes: > We store the hex prefix in a 40-byte buffer with the prefix > itself followed by 40-minus-len "x" characters. These x's > serve no purpose, and the lack of NUL termination makes the > prefix string annoying to use. Let's just terminate it. > Note that this is

Re: Request: Extra case for %G? format

Michael J Gruber writes: >> Then currently %G? results in `N', the same as an unsigned commit. >> >> In this case, could %G? please result in a new character? Perhaps `M' >> for "missing public key"? > > Yes, and no. > > Really, there are many different reasons why a

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

On Sun, Sep 25, 2016 at 11:39 AM, Junio C Hamano wrote: > 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

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

Jeff King writes: > Since it's attached to an error path, I'm guessing nobody will be too > upset about it, so my inclination was to wait and let somebody add the > conditional advice code if they're bothered. Fair enough. At that point of getting an error message, the only

Re: [PATCH] unpack_sha1_header(): detect malformed object header

Jeff King writes: >> diff --git a/streaming.c b/streaming.c >> index 811fcc2..884a8f1 100644 >> --- a/streaming.c >> +++ b/streaming.c >> @@ -347,7 +347,8 @@ static open_method_decl(loose) >> return -1; >> } >> >> -parse_sha1_header(st->u.loose.hdr, >size);

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

On 09/26, Junio C Hamano wrote: > Brandon Williams writes: > > > In a previous email you mentioned that this feature should be completely > > hidden from users, which is why I removed the command line option for > > this latest series. > > I may have said something like that;

Re: [PATCH v8 02/11] pkt-line: extract set_packet_header()

On 24 Sep 2016, at 23:22, Jakub Narębski wrote: > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > >> From: Lars Schneider >> >> Subject: [PATCH v8 02/11] pkt-line: extract set_packet_header() >> >> set_packet_header() converts an

Re: [PATCH] unpack_sha1_header(): detect malformed object header

On Mon, Sep 26, 2016 at 10:33:57AM -0700, Junio C Hamano wrote: > -- >8 -- > From: Junio C Hamano > Date: Mon, 26 Sep 2016 09:23:41 -0700 > Subject: [PATCH 1/2] streaming: make sure to notice corrupt object > > The streaming read interface from a loose object called >

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

Hello, Now that the cause of this issue is identified, i would like to know if there is an impact in the security, so i can request a CVE if necessary. Thanks!

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

Gustavo Grieco writes: > Now that the cause of this issue is identified, i would like to > know if there is an impact in the security, so i can request a CVE > if necessary. I am inclined to say that it has no security implications. You have to be able to write a bogus

Re: [PATCH v2 04/11] i18n: add--interactive: mark plural strings

Vasco Almeida writes: >> > + } elsif ($did eq 'reversed') { >> > + printf(Q__("reversed one path\n", "reversed %d paths\n", > > This should be 'reverted' not 'reversed'. I'll mark v2 of this topic "not to be merged yet"; please send in a corrected version 3

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

Kevin Daudt writes: > 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. > >

Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)

Johannes Schindelin writes: > Also, I found https://tinyurl.com/gitCal very convenient a URL to point > to, do you plan to update that for v2.11.0? Thanks for reminding. I've barely had enough bandwidth to keep up with the list traffic for the past few weeks, and

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

Jeff King writes: > We also restrict the list to those that match any > disambiguation hint. E.g.: > > $ git rev-parse b2e1:foo > error: short SHA1 b2e1 is ambiguous > hint: The candidates are: > hint: b2e1196 tag v2.8.0-rc1 > hint: b2e11d1 tree > hint: b2e1632

Re: [PATCH] unpack_sha1_header(): detect malformed object header

On Mon, Sep 26, 2016 at 10:34:32AM -0700, Junio C Hamano wrote: > And the second one, that no longer checks SP in unpacker, looks like > this. This looks good from a cursory read (but I am about to go to sleep, so might be a bit less careful than usual :) ). -Peff

Re: [PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

Jeff King writes: >> Other than your reinvention of HAS_MULTI_BITS(), which has been with >> us since db7244bd ("parse-options new features.", 2007-11-07), this >> looks like a reasonable thing to do. > > Heh, I _thought_ we had something like that but couldn't find it. I >

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

Fair enough. We are testing our tool to try to find bugs/vulnerabilities in several git implementations. I will report here my results if i can find some other memory issue in this git client. - Original Message - > Gustavo Grieco writes: > > > Now that the

Re: [PATCH v2 04/11] i18n: add--interactive: mark plural strings

A Qua, 31-08-2016 às 12:31 +, Vasco Almeida escreveu: > Mark plural strings for translation.  Unfold each action case in one > entire sentence. > > Pass new keyword for xgettext to extract. > > Update test to include new subrotine Q__() for plural strings handling. > > > Signed-off-by:

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

Brandon Williams writes: > In a previous email you mentioned that this feature should be completely > hidden from users, which is why I removed the command line option for > this latest series. I may have said something like that; I do not recall, though, so a more accurate

Re: [PATCH] unpack_sha1_header(): detect malformed object header

Junio C Hamano writes: > Good that your attempt to signature-changing change caught it. I'll > take a further look. So here are two patch series. The first one makes sure all callers of parse_sha1_header() check the returned status. -- >8 -- From: Junio C Hamano

Re: [PATCH v8 01/11] pkt-line: rename packet_write() to packet_write_fmt()

On 24 Sep 2016, at 23:14, Jakub Narębski wrote: > Hello Lars, > > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > >> From: Lars Schneider >> >> packet_write() should be called packet_write_fmt() as the string >> parameter can be

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Mon, Sep 26, 2016 at 10:30:48AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > We also restrict the list to those that match any > > disambiguation hint. E.g.: > > > > $ git rev-parse b2e1:foo > > error: short SHA1 b2e1 is ambiguous > > hint: The candidates are:

Re: [PATCH] unpack_sha1_header(): detect malformed object header

And the second one, that no longer checks SP in unpacker, looks like this. -- >8 -- Subject: [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

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

Gustavo Grieco writes: > Fair enough. We are testing our tool to try to find > bugs/vulnerabilities in several git implementations. I will report > here my results if i can find some other memory issue in this git > client. Thanks. With or without security implications,

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

Junio C Hamano writes: > I am inclined to say that it has no security implications. You have > to be able to write a bogus loose object in an object store you > already have write access to in the first place, in order to cause > this ... Note that you could social-engineer

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

Brandon Williams writes: > or something along those lines. That way we only need to add the flag > to each command as we go ... Sounds good. Thanks.

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

Kevin Daudt writes: > 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 >

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

Junio C Hamano writes: > Don't these also need to be downcased if you prefer $data over > $DATA, though? For now, I'll queue a SQUASH??? that reverts s/DATA/data/ you did to 1/2 between your 1/2 and 2/2. Thanks.

Re: [PATCH v8 03/11] run-command: move check_pipe() from write_or_die to run_command

> On 25 Sep 2016, at 00:12, Jakub Narębski wrote: > > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> Move check_pipe() to run_command and make it public. This is necessary >> to call the function from

Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish

Jeff King writes: > The treeish disambiguation function tries to peel tags, but > it does so by calling: > > deref_tag(lookup_object(sha1), ...); > > This will only work if we have previously looked at the tag > and created a "struct tag" for it. Since parsing revision >

Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish

On Mon, Sep 26, 2016 at 09:55:20AM -0700, Junio C Hamano wrote: > > Instead, we can use parse_object(). Note that this is the > > same fix done by 94d75d1 (get_short_sha1(): correctly > > disambiguate type-limited abbreviation, 2013-07-01), but > > that commit fixed only the committish

Re: BUG: Git blame provides incorrect previous commit if the line is uncommitted

Eric Amodio writes: > This is the first time I've reported a bug with Git so please forgive > me if this isn't the right place, format, etc. > > If git blame --porcelain (or --line-porcelain or --incremental) is run > on a file that has uncommitted changes any uncommitted

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Mon, Sep 26, 2016 at 5:00 AM, Jeff King wrote: > > This patch teaches get_short_sha1() to list the sha1s of the > objects it found, along with a few bits of information that > may help the user decide which one they meant. This looks very good to me, but I wonder if it couldn't

Re: [PATCH v8 03/11] run-command: move check_pipe() from write_or_die to run_command

On 26 September 2016 at 18:13, Lars Schneider wrote: >> On 25 Sep 2016, at 00:12, Jakub Narębski wrote: >> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >>> From: Lars Schneider >>> >>> Move check_pipe() to

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

On 09/25, Junio C Hamano wrote: > 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

Re: [PATCH 06/10] get_short_sha1: NUL-terminate hex prefix

On Mon, Sep 26, 2016 at 10:10:46AM -0700, Junio C Hamano wrote: > > struct disambiguate_state { > > int len; /* length of prefix in hex chars */ > > - char hex_pfx[GIT_SHA1_HEXSZ]; > > + char hex_pfx[GIT_SHA1_HEXSZ + 1]; > > unsigned char bin_pfx[GIT_SHA1_RAWSZ]; > > > >

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

From: "Junio C Hamano" "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

Re: [PATCH] unpack_sha1_header(): detect malformed object header

Jeff King writes: > This part I don't understand, though. We clearly need to look for the > NUL. But why do we need to look for the space? The loop in > parse_sha1_header() can easily detect this as it looks for the end of > the type name (and if it hits the end-of-string, can

Re: [PATCH 2/2] fsck: handle bad trees like other errors

Junio C Hamano writes: > To prevent further headaches in this directory, can we have > .gitattributes that tells us that everything in there are binary > files? Something like the attached. > > The other object was transferred as a binary patch, but I have no > faith in what

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

On Mon, Sep 26, 2016 at 12:26:13PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > Don't these also need to be downcased if you prefer $data over > > $DATA, though? > > For now, I'll queue a SQUASH??? that reverts s/DATA/data/ you did to > 1/2 between your 1/2 and

Re: [PATCH 2/2] fsck: handle bad trees like other errors

David Turner writes: > @@ -535,7 +536,10 @@ static int fsck_tree(struct tree *item, struct > fsck_options *options) > unsigned o_mode; > const char *o_name; > > - init_tree_desc(, item->buffer, item->size); > + if (init_tree_desc_gently(, item->buffer,

Re: [PATCH 0/2] tree-walk improvements

On Mon, 2016-09-26 at 12:43 -0700, Junio C Hamano wrote: > David Turner writes: > > > The first patch is a re-roll of Peff's patch from 2014 -- here's > > the archive message: > > > >

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

On 25 Sep 2016, at 13:26, Jakub Narębski wrote: > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> ... >> >> +static int packet_write_gently(const int fd_out, const char *buf, size_t >> size) > > I'm not sure

[PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

Currently the section about recursing into submodules is repeated in git-pull word for word as it is in fetch-options. Don't repeat ourselves here and include the --recurse-submodules via fetch options. As a bonus expose the --jobs parameter in git-pull as well as that is declared as a

Re: [PATCH 0/2] tree-walk improvements

On Mon, Sep 26, 2016 at 12:32 PM, David Turner wrote: > The first patch is a re-roll of Peff's patch from 2014 -- here's > the archive message: > > http://git.661346.n2.nabble.com/PATCH-tree-walk-be-more-specific-about-corrupt-tree-errors-td7603558.html > > Not sure why this

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

Stefan Beller writes: > Currently the section about recursing into submodules is repeated in > git-pull word for word as it is in fetch-options. > > Don't repeat ourselves here and include the --recurse-submodules via > fetch options. > > As a bonus expose the --jobs

Re: [PATCH] git-gui: Do not reset author details on amend

Orgad Shaneh writes: > On Sun, Jul 10, 2016 at 7:36 AM, Orgad Shaneh wrote: > >> On Wed, May 18, 2016 at 9:12 AM, Orgad Shaneh wrote: >>> ping? >>> >> It's been over 2 months. Can anyone please review and merge it? >> > 4.5 months and

[PATCH 2/2] fsck: handle bad trees like other errors

From: David Turner Instead of dying when fsck hits a malformed tree object, log the error like any other and continue. Now fsck can tell the user which tree is bad, too. Signed-off-by: David Turner --- fsck.c

[PATCH 1/2] tree-walk: be more specific about corrupt tree errors

From: Jeff King When the tree-walker runs into an error, it just calls die(), and the message is always "corrupt tree file". However, we are actually covering several cases here; let's give the user a hint about what happened. Let's also avoid using the word "corrupt", which

[PATCH 0/2] tree-walk improvements

The first patch is a re-roll of Peff's patch from 2014 -- here's the archive message: http://git.661346.n2.nabble.com/PATCH-tree-walk-be-more-specific-about-corrupt-tree-errors-td7603558.html Not sure why this wasn't applied then, but I thought it looked pretty good, so I added a few tests.

[RFC PATCH v4] 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 0/2] tree-walk improvements

David Turner writes: > Hopefully the encoding works correctly on these patches. If not, you > can fetch from > https://github.com/novalis/git/ > on branch dturner/bad-trees This does not test cleanly here, unfortunately. Specifically, tests 30 and 31 t1007 do fine with 1/2

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

Vegard Nossum writes: > 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^-

git 2.9.2: is RUNTIME_PREFIX supposed to work?

Hi all.  I'm trying to create a relocatable installation of Git 2.9.2, so I can copy it anywhere and it continues to run without any problem. This is on GNU/Linux systems, FWIW. Looking through the code (for some other reason) I discovered the RUNTIME_PREFIX setting which appears to attempt to

Re: [PATCH 0/2] tree-walk improvements

David Turner writes: > The first patch is a re-roll of Peff's patch from 2014 -- here's > the archive message: > > http://git.661346.n2.nabble.com/PATCH-tree-walk-be-more-specific-about-corrupt-tree-errors-td7603558.html > > Not sure why this wasn't applied then, but I

Re: [PATCH] git-gui: Do not reset author details on amend

4.5 months and counting... :( - Orgad On Sun, Jul 10, 2016 at 7:36 AM, Orgad Shaneh wrote: > It's been over 2 months. Can anyone please review and merge it? > > Thanks. > - Orgad > > On Wed, May 18, 2016 at 9:12 AM, Orgad Shaneh wrote: >> ping? >> >> On Thu,

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

On 25 Sep 2016, at 15:46, Jakub Narębski wrote: > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> +{ >> +static char buf[PKTLINE_DATA_MAXLEN]; > > Sidenote: we have LARGE_PACKET_MAX (used in previous

Re: [PATCH 2/2] fsck: handle bad trees like other errors

David Turner writes: > From: David Turner > > Instead of dying when fsck hits a malformed tree object, log the error > like any other and continue. Now fsck can tell the user which tree is > bad, too. > > Signed-off-by: David Turner

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

On Mon, Sep 26, 2016 at 1:29 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Currently the section about recursing into submodules is repeated in >> git-pull word for word as it is in fetch-options. >> >> Don't repeat ourselves here and include the

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

Stefan Beller writes: > After a bit more research, I think 8f0700dd33f (fetch/pull: Add the > 'on-demand' value to the --recurse-submodules option) is the culprit, > where this patch should have been squashed into, as that made the > both locations word for word equal. Hmph,

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

On Mon, Sep 26, 2016 at 1:54 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> After a bit more research, I think 8f0700dd33f (fetch/pull: Add the >> 'on-demand' value to the --recurse-submodules option) is the culprit, >> where this patch should have

[PATCH 4/4 v4] ls-files: add pathspec matching for submodules

Pathspecs can be a bit tricky when trying to apply them to submodules. The main challenge is that the pathspecs will be with respect to the superproject and not with respect to paths in the submodule. The approach this patch takes is to pass in the identical pathspec from the superproject to the

[PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules

Pass through some known-safe options when recursing into submodules. (--cached, --stage, -v, -t, -z, --debug, --eol) Signed-off-by: Brandon Williams --- builtin/ls-files.c | 34 ++ t/t3007-ls-files-recurse-submodules.sh | 17

[PATCH 2/4 v4] ls-files: optionally recurse into submodules

Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Use top-level --submodule_prefix option to pass a path to the submodule which it can use to prepend to

[PATCH 1/4 v4] submodules: make submodule-prefix option

Add a submodule-prefix environment variable 'GIT_INTERNAL_SUBMODULE_PREFIX' which can be used by commands which have --recurse-submodule options to give context to submodules about how they were invoked. This option is only allowed for builtins which have submodule support. Signed-off-by:

[PATCH 0/4 v4] recursive support for ls-files

A couple things have changed in v4: - Restructured the patch series to prevent a breakage mid-way. - Added an additional patch in the middle to pass through safe options. This way the series is structured in a more coherent manor. - Added --submodule-prefix to top-level git.c Hopefully this

Re: [PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

On Mon, Sep 26, 2016 at 09:37:10AM -0700, Junio C Hamano wrote: > > We can do the check easily with some bit-twiddling, and as a > > bonus, the bit-mask of disambiguators will come in handy in > > a future patch. > > > > Signed-off-by: Jeff King > > --- > > Other than your

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

Btw, this other test case will trigger a similar issue, but in another line of code: To reproduce: $ git init ; mkdir -p .git/objects/b2 ; printf 'eJwNwoENgDAIBECkDsII5Z8CHagLGPePXu59zjHGRIOZG3OzI/lnRc4KemXDPdYSml6iQ+4ATIZ+nAEK4g==' | base64 -d >

[PATCH 0/2] Locally alias "latin-1" to "ISO-8859-1"

Some systems do not seem to ship "latin-1" as a valid locale, even though they happilly accept more modern official name "ISO-8859-1". Naturally, "iconv -f iso-8859-1" succeeds while "iconv -f latin-1" fails on such a system. We already have in utf8.c to accomodate overly strict iconv_open() that

[PATCH 1/2] utf8: refactor code to decide fallback encoding

The codepath we use to call iconv_open() has a provision to use a fallback encoding when it fails, hoping that "UTF-8" being spelled differently could be the reason why the library function did not like the encoding names we gave it. Essentially, we turn what we have observed to be used as

[PATCH 2/2] utf8: accept "latin-1" as ISO-8859-1

Even though latin-1 is still seen in e-mail headers, some platforms only install ISO-8859-1. "iconv -f ISO-8859-1" succeeds, while "iconv -f latin-1" fails on such a system. Using the same fallback_encoding() mechanism factored out in the previous step, teach ourselves that "ISO-8859-1" has a

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

Junio C Hamano writes: > I am not opposed to bump the default to 12 or whatever, but I > suspect any lengthening today may need to be accompanied by a tool > support that finds the set of objects that are reachable from a > commit whose names begin with non-unique

[PATCH 10/10] get_short_sha1: list ambiguous objects on error

When the user gives us an ambiguous short sha1, we print an error and refuse to resolve it. In some cases, the next step is for them to feed us more characters (e.g., if they were retyping or cut-and-pasting from a full sha1). But in other cases, that might be all they have. For example, an old

[PATCH 06/10] get_short_sha1: NUL-terminate hex prefix

We store the hex prefix in a 40-byte buffer with the prefix itself followed by 40-minus-len "x" characters. These x's serve no purpose, and the lack of NUL termination makes the prefix string annoying to use. Let's just terminate it. Note that this is in contrast to the binary prefix, which

[PATCH 05/10] get_short_sha1: refactor init of disambiguation code

The disambiguation machinery has two callers: get_short_sha1 and for_each_abbrev. Both need to repeat much of the same setup: declaring buffers, sanity-checking lengths, preparing the prefixes, etc. Let's pull that into a single init function so we can avoid repeating ourselves. Pulling the

[PATCH 07/10] get_short_sha1: mark ambiguity error for translation

This is a human-readable message, and there's no reason it should not be translated. While we're at it, let's drop the period from the end, which is not our usual style. Signed-off-by: Jeff King --- sha1_name.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 09/10] for_each_abbrev: drop duplicate objects

If an object appears multiple times in the object database (e.g., in both loose and packed form, or in two separate packs), the disambiguation machinery may see it more than once. The get_short_sha1() function handles this already, but for_each_abbrev() blindly fires the callback for each instance

[PATCH 08/10] sha1_array: let callbacks interrupt iteration

The callbacks for iterating a sha1_array must have a void return. This is unlike our usual for_each semantics, where a callback may interrupt iteration and have its value propagated. Let's switch it to the usual form, which will enable its use in more places (e.g., where we are replacing an

[PATCH 04/10] get_short_sha1: peel tags when looking for treeish

The treeish disambiguation function tries to peel tags, but it does so by calling: deref_tag(lookup_object(sha1), ...); This will only work if we have previously looked at the tag and created a "struct tag" for it. Since parsing revision arguments typically happens before anything else, this

RE: git-upload-pack hangs

> -Original Message- > From: Jason Pyeron > Sent: Monday, September 26, 2016 01:51 > > git is hanging on clone. I am runnig (cygwin) git 2.8.3 on > IIS7 (windows server 2012 R2). > > Where can I start to perform additional debugging? > Reading this thread, it seems plausible as a

git-upload-pack hangs

git is hanging on clone. I am runnig (cygwin) git 2.8.3 on IIS7 (windows server 2012 R2). Where can I start to perform additional debugging? Selected items I have read, but they did not help: http://unix.stackexchange.com/questions/98959/git-upload-pack-hangs-indefinitely

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

On Mon, Sep 26, 2016 at 3:39 AM, Linus Torvalds wrote: > > The kernel, these days, is at roughly 5 million objects, and while the > seven hex digits are still often enough for uniqueness (and git will > always add digits *until* it is unique), it's long been at the

[PATCH 0/10] helping people resolve ambiguous sha1s

On Sun, Sep 25, 2016 at 09:45:18PM -0700, Junio C Hamano wrote: > 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

[PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

The get_sha1() family of functions takes a flags field, but some of the flags are mutually exclusive. In particular, we can only handle one disambiguating function, and the flags quietly override each other. Let's instead detect these as programming bugs. Technically some of the flags are

[PATCH 03/10] get_sha1: propagate flags to child functions

The get_sha1() function is actually implementation by many sub-functions, but we do not always pass our flags around to all of those functions. As a result, we may forget that our caller asked us to resolve with GET_SHA1_QUIETLY and output messages. The two triggerable cases are: 1. Resolving

[PATCH 02/10] get_sha1: avoid repeating ourselves via ONLY_TO_DIE

When the revision code cannot parse an argument like "HEAD:foo", it will call maybe_die_on_misspelt_object_name(), which re-runs get_sha1() with an extra ONLY_TO_DIE flag. We then spend more effort to generate a better error message. Unfortunately, a side effect is that our second call may repeat

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

On Mon, Sep 26, 2016 at 08:33:52AM +0200, Matthieu Moy wrote: > Junio C Hamano writes: > > > I am not opposed to bump the default to 12 or whatever, but I > > suspect any lengthening today may need to be accompanied by a tool > > support that finds the set of objects that are

BUG: Git blame provides incorrect previous commit if the line is uncommitted

This is the first time I've reported a bug with Git so please forgive me if this isn't the right place, format, etc. If git blame --porcelain (or --line-porcelain or --incremental) is run on a file that has uncommitted changes any uncommitted lines have the wrong previous sha. Instead of the sha

Re: Request: Extra case for %G? format

Alex venit, vidit, dixit 25.09.2016 08:05: > 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

Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish

On Mon, Sep 26, 2016 at 07:59:48AM -0400, Jeff King wrote: > Subject: Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish > > The treeish disambiguation function tries to peel tags, but > it does so by calling: Probably the subject should be "parse tags when...". We already try

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

On Sun, Sep 25, 2016 at 05:10:31PM -0700, Junio C Hamano wrote: > 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

Re: [PATCH] unpack_sha1_header(): detect malformed object header

On Sun, Sep 25, 2016 at 09:29:04PM -0700, Junio C Hamano wrote: > To correct this, do these three things: > > - rename unpack_sha1_header() to unpack_sha1_short_header() and >have unpack_sha1_header_to_strbuf() keep calling that as its >helper function. This will detect and report zlib

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith wrote: > Hi all. I'm trying to create a relocatable installation of Git 2.9.2, > so I can copy it anywhere and it continues to run without any problem. > This is on GNU/Linux systems, FWIW. I had an impression that the setting

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

> > By the way, 7dce19d3 is interesting in another way and worth > > studying in that it adds --submodule-prefix ;-) It may be something > > we want to consider consolidating with what Brandon has been working > > on. > > That's why Brandon is cc'd now. :) Interesting. Once we get something we

[PATCH 1/3] tree-walk: be more specific about corrupt tree errors

From: Jeff King When the tree-walker runs into an error, it just calls die(), and the message is always "corrupt tree file". However, we are actually covering several cases here; let's give the user a hint about what happened. Let's also avoid using the word "corrupt", which

[PATCH 2/3] fsck: handle bad trees like other errors

Instead of dying when fsck hits a malformed tree object, log the error like any other and continue. Now fsck can tell the user which tree is bad, too. Signed-off-by: David Turner --- fsck.c | 18 +++-- t/t1450-fsck.sh

[PATCH 3/3] add David Turner's Two Sigma address

From: David Turner Signed-off-by: David Turner --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 9441a54..9cc33e9 100644 --- a/.mailmap +++ b/.mailmap @@ -48,6 +48,7 @@ David KÃ¥gedal

Re: [PATCH 2/2] fsck: handle bad trees like other errors

On Mon, Sep 26, 2016 at 03:32:45PM -0400, David Turner wrote: > Instead of dying when fsck hits a malformed tree object, log the error > like any other and continue. Now fsck can tell the user which tree is > bad, too. Cool. I think the lack of this is what made me drag my feet on the first

Re: [PATCH 1/2] utf8: refactor code to decide fallback encoding

On Mon, Sep 26, 2016 at 06:22:10PM -0700, Junio C Hamano wrote: > @@ -501,17 +516,9 @@ char *reencode_string_len(const char *in, int insz, > > conv = iconv_open(out_encoding, in_encoding); > if (conv == (iconv_t) -1) { > - /* > - * Some platforms do not have

  1   2   >