[PATCH RFC 2/2] diff: teach diff to expand tabs in output

From: Jacob Keller When creating a diff for contents, we prepend a single character to represent the state of that line. This character can offset how the tabs in the real content are displayed, which may result in weird alignment issues when viewing the diffs. Teach the

[PATCH RFC 1/2] strbuf: move strbuf_add_tabexpand into strbuf.c

From: Jacob Keller In commit 7cc13c717b52 ("pretty: expand tabs in indented logs to make things line up properly", 2016-03-16) a new function was added to insert a line into a strbuf while expanding the tabs into spaces. This functionality was used to help show the log

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 03:31:59AM -0400, Jeff King wrote: > I read through the whole series and didn't find anything objectionable. > The pointer-arithmetic fix should perhaps graduate separately. Junio's welcome to take that patch separately if he likes. > I suggested an additional cleanup

Re: Re: Re: Re: GSoC Project | Convert interactive rebase to C

On Mon, Mar 27, 2017 at 6:31 PM, Pickfire wrote: > Johannes Schindelin wrote: > >> On Sat, 25 Mar 2017, Ivan Tham wrote: >> >> > Johannes Schindelin wrote: >> > > On Tue, 21 Mar 2017, Ivan Tham wrote: >> > > > Stefan

Re: [PATCH v2 16/21] Make sha1_array_append take a struct object_id *

On Sun, Mar 26, 2017 at 04:01:38PM +, brian m. carlson wrote: > diff --git a/transport.c b/transport.c > index 8a90b0c29b..e492757726 100644 > --- a/transport.c > +++ b/transport.c > @@ -1027,7 +1027,8 @@ int transport_push(struct transport *transport, > > for (; ref;

Re: [PATCH v2 00/21] object_id part 7

On Sun, Mar 26, 2017 at 04:01:22PM +, brian m. carlson wrote: > This is part 7 in the continuing transition to use struct object_id. > > This series focuses on two main areas: adding two constants for the > maximum hash size we'll be using (which will be suitable for allocating > memory) and

Re: [PATCH v2 07/21] builtin/receive-pack: convert portions to struct object_id

On Sun, Mar 26, 2017 at 04:01:29PM +, brian m. carlson wrote: > Convert some hardcoded constants into uses of parse_oid_hex. > Additionally, convert all uses of struct command, and miscellaneous > other functions necessary for that. This work is necessary to be able > to convert

Re: What's cooking in git.git (Mar 2017, #11; Mon, 27)

> On 28 Mar 2017, at 00:35, Junio C Hamano wrote: > ... > > * ls/filter-process-delayed (2017-03-06) 1 commit > - convert: add "status=delayed" to filter process protocol > > What's the status of this one??? > cf. I was

Re: [PATCH v2 06/21] builtin/receive-pack: fix incorrect pointer arithmetic

On Sun, Mar 26, 2017 at 04:01:28PM +, brian m. carlson wrote: > If we had already processed the last newline in a push certificate, we > would end up subtracting NULL from the end-of-certificate pointer when > computing the length of the line. This would have resulted in an > absurdly large

Re: [PATCH v2 15/21] sha1-array: convert internal storage for struct sha1_array to object_id

On Sun, Mar 26, 2017 at 04:01:37PM +, brian m. carlson wrote: > Make the internal storage for struct sha1_array use an array of struct > object_id internally. Update the users of this struct which inspect its > internals. Yay. I'm happy to see all those gross (*sha1)[20] bits go away.

Re: Microproject | Add more builtin patterns for userdiff

On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote: > While I was working buildins shell patterns for user diffs. I noticed that > the tests t4034 passes but I can reproduce it manually with: > > mkdir cpp/ && cd cpp/ && git init > > cat > pre < Foo():x(0&&1){} >

[PATCH/RFC v2] WIP configurable options facility

--- FWIW here's the current state of this WIP hack which I worked a bit on yesterday. I converted it to use a hashmap and got rid of the need to s/const // the options struct. I've either converted options that read the config to this already, or left TODO comments on those that are candidates

Re: [PATCH v2 1/2] read-cache: skip index SHA verification

On 3/27/2017 6:44 PM, Jeff King wrote: On Mon, Mar 27, 2017 at 09:09:38PM +, g...@jeffhostetler.com wrote: From: Jeff Hostetler Teach git to skip verification of the index SHA in read_index(). This is a performance optimization. The index file SHA verification

Re: [PATCHv2 08/14] completion: let 'for-each-ref' and 'ls-remote' filter matching refs

On Fri, Mar 24, 2017 at 8:42 PM, Jeff King wrote: > On Thu, Mar 23, 2017 at 04:29:18PM +0100, SZEDER Gábor wrote: >> case "$cur_" in >> refs|refs/*) >> format="refname" >> - refs="${cur_%/*}" >> +

Re: [GSoC] Proposal Discussion

On Tue, Mar 28, 2017 at 07:52:42AM +0200, Christian Couder wrote: > Hi, > > On Tue, Mar 28, 2017 at 12:17 AM, Devin Lehmacher wrote: > > Hello everyone, > > > > I am a student studying Computer Science at Cornell University. I > > already completed a microproject, Move

Re: [PATCH v2 0/2] read-cache: call verify_hdr() in a background thread

On 3/27/2017 6:45 PM, Jeff King wrote: On Mon, Mar 27, 2017 at 09:09:37PM +, g...@jeffhostetler.com wrote: From: Jeff Hostetler Version 2 of this patch series simplifies this to just turn off the hash verification. Independent comments from Linus and Peff

Re: [PATCH v2 1/2] read-cache: skip index SHA verification

On Tue, Mar 28, 2017 at 11:27:19AM -0400, Jeff Hostetler wrote: > > Hrm, there shouldn't be any dependency of the config on the index (and > > there are a handful of options which impact the index already). Did you > > try it and run into problems? > > Yeah, I tried adding a new

Re: [PATCH v2 00/21] object_id part 7

Jeff King writes: > Here's that minor tweak, in case anybody is interested. It's less useful > without that follow-on that touches "eol" more, but perhaps it increases > readability on its own. Yup, the only thing that the original (with Brian's fix) appears to be more careful

[PATCH 0/18] snprintf cleanups

Our code base calls snprintf() into a fixed-size buffer in a bunch of places. Sometimes we check the result, and sometimes we accept a silent truncation. In some cases an overflow is easy given long input. In some cases it's impossible. And in some cases it depends on how big PATH_MAX is on your

[PATCH 02/18] odb_mkstemp: write filename into strbuf

The odb_mkstemp() function expects the caller to provide a fixed buffer to write the resulting tempfile name into. But it creates the template using snprintf without checking the return value. This means we could silently truncate the filename. In practice, it's unlikely that the truncation would

[PATCH 01/18] do not check odb_mkstemp return value for errors

The odb_mkstemp function does not return an error; it dies on failure instead. But many of its callers compare the resulting descriptor against -1 and die themselves. Mostly this is just pointless, but it does raise a question when looking at the callers: if they show the results of the

[PATCH 03/18] odb_mkstemp: use git_path_buf

Since git_path_buf() is smart enough to replace "objects/" with the correct object path, we can use it instead of manually assembling the path. That's slightly shorter, and will clean up any non-canonical bits in the path. Signed-off-by: Jeff King --- environment.c | 6 ++ 1

[PATCH 13/18] replace unchecked snprintf calls with heap buffers

We'd prefer to avoid unchecked snprintf calls because truncation can lead to unexpected results. These are all cases where truncation shouldn't ever happen, because the input to snprintf is fixed in size. That makes them candidates for xsnprintf(), but it's simpler still to just use the heap, and

[PATCH 06/18] fetch: use heap buffer to format reflog

Part of the reflog content comes from the environment, which can be much larger than our fixed buffer. Let's use a heap buffer so we avoid truncating it. Signed-off-by: Jeff King --- builtin/fetch.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH 07/18] avoid using fixed PATH_MAX buffers for refs

Many functions which handle refs use a PATH_MAX-sized buffer to do so. This is mostly reasonable as we have to write loose refs into the filesystem, and at least on Linux the 4K PATH_MAX is big enough that nobody would care. But: 1. The static PATH_MAX is not always the filesystem limit. 2.

[PATCH 15/18] convert unchecked snprintf into xsnprintf

These calls to snprintf should always succeed, because their input is small and fixed. Let's use xsnprintf to make sure this is the case (and to make auditing for actual truncation easier). These could be candidates for turning into heap buffers, but they fall into a few broad categories that

[PATCH 08/18] avoid using mksnpath for refs

Like the previous commit, we'd like to avoid the assumption that refs fit into PATH_MAX-sized buffers. These callsites have an extra twist, though: they write the refnames using mksnpath. This does two things beyond a regular snprintf: 1. It quietly writes "/bad-path/" when truncation occurs.

[PATCH 11/18] name-rev: replace static buffer with strbuf

When name-rev needs to format an actual name, we do so into a fixed-size buffer. That includes the actual ref tip, as well as any traversal information. Since refs can exceed 1024 bytes, this means you can get a bogus result. E.g., doing: git tag $(perl -e 'print join("/", 1..1024)') git

[PATCH 04/18] diff: avoid fixed-size buffer for patch-ids

To generate a patch id, we format the diff header into a fixed-size buffer, and then feed the result to our sha1 computation. The fixed buffer has size '4*PATH_MAX + 20', which in theory accomodates the four filenames plus some extra data. Except: 1. The filenames may not be constrained to

[PATCH 10/18] create_branch: use xstrfmt for reflog message

We generate a reflog message that contains some fixed text plus a branch name, and use a buffer of size PATH_MAX + 20. This mostly works if you assume that refnames are shorter than PATH_MAX, but: 1. That's not necessarily true. PATH_MAX is not always the filesystem's limit. 2. The "20"

[PATCH 05/18] tag: use strbuf to format tag header

We format the tag header into a fixed 1024-byte buffer. But since the tag-name and tagger ident can be arbitrarily large, we may unceremoniously die with "tag header too big". Let's just use a strbuf instead. Note that it looks at first glance like we can just format this directly into the "buf"

[PATCH 09/18] create_branch: move msg setup closer to point of use

In create_branch() we write the reflog msg into a buffer in the main function, but then use it only inside a conditional. If you carefully follow the logic, you can confirm that we never use the buffer uninitialized nor write when it would not be used. But we can make this a lot more obvious by

[PATCH 12/18] receive-pack: print --pack-header directly into argv array

After receive-pack reads the pack header from the client, it feeds the already-read part to index-pack and unpack-objects via their --pack-header command-line options. To do so, we format it into a fixed buffer, then duplicate it into the child's argv_array. Our buffer is long enough to handle

[PATCH 17/18] gc: replace local buffer with git_path

We probe the "17/" loose object directory for auto-gc, and use a local buffer to format the path. We can just use git_path() for this. It handles paths of any length (reducing our error handling). And because we feed the result straight to a system call, we can just use the static variant. Note

[PATCH 14/18] combine-diff: replace malloc/snprintf with xstrfmt

There's no need to use the magic "100" when a strbuf can do it for us. Signed-off-by: Jeff King --- combine-diff.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/combine-diff.c b/combine-diff.c index 59501db99..d3560573a 100644 --- a/combine-diff.c +++

[PATCH 18/18] daemon: use an argv_array to exec children

Our struct child_process already has its own argv_array. Let's use that to avoid having to format options into separate buffers. Note that we'll need to declare the child process outside of the run_service_command() helper to do this. But that opens up a further simplification, which is that the

[PATCH 16/18] transport-helper: replace checked snprintf with xsnprintf

We can use xsnprintf to do our truncation check with less code. The error message isn't as specific, but the point is that this isn't supposed to trigger in the first place (because our buffer is big enough to handle any int). Signed-off-by: Jeff King --- transport-helper.c | 5

Re: [PATCH v3 0/2] read-cache: call verify_hdr() in a background thread

On 3/28/2017 3:16 PM, Jeff King wrote: On Tue, Mar 28, 2017 at 07:07:30PM +, g...@jeffhostetler.com wrote: From: Jeff Hostetler Version 3 of this patch series simplifies this effort to just turn on/off the hash verification using a "core.checksumindex" config

Re: [PATCH 04/18] diff: avoid fixed-size buffer for patch-ids

On Tue, Mar 28, 2017 at 03:46:18PM -0400, Jeff King wrote: > As a result, the data we feed to the sha1 computation may be > truncated, and it's possible that a commit with a very long > filename could erroneously collide in the patch-id space > with another commit. For instance, if one commit

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 12:40:29PM -0700, Junio C Hamano wrote: > > Here's that minor tweak, in case anybody is interested. It's less useful > > without that follow-on that touches "eol" more, but perhaps it increases > > readability on its own. > > Yup, the only thing that the original (with

Re: [PATCH RFC 2/2] diff: teach diff to expand tabs in output

On Tue, Mar 28, 2017 at 12:03 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> I'm really not a fan of how the ws code ended up. It seems pretty ugly >> and weird to hack in the expand_tabs stuff here. However, I'm really not >> sure how else I

Re: [PATCH v3 0/2] read-cache: call verify_hdr() in a background thread

On Tue, Mar 28, 2017 at 03:50:34PM -0400, Jeff Hostetler wrote: > It was a convenient way to isolate, average, and compare > read_index() times, but I suppose we could do something > like that. > > I did confirm that a ls-files does show a slight 0.008 > second difference on the 58K file Linux

Re: [PATCH v2 06/21] builtin/receive-pack: fix incorrect pointer arithmetic

Jeff King writes: > The patch itself is obviously an improvement. It may be worth graduating > separately from the rest of the series. Yup, I will split it out to bc/push-cert-receive-fix that builds directly on an ancient jc/push-cert topic that was merged at v2.2.0-rc0~64.

Re: What's cooking in git.git (Mar 2017, #11; Mon, 27)

> * sb/submodule-short-status (2017-03-27) 7 commits > - submodule.c: correctly handle nested submodules in is_submodule_modified > - short status: improve reporting for submodule changes > - submodule.c: stricter checking for submodules in is_submodule_modified > - submodule.c: port

Re: [PATCH v3 0/2] [GSoC] remove_subtree(): reimplement using iterators

On Sat, Mar 25, 2017 at 11:12 AM, Daniel Ferreira wrote: > This is the third version of the GSoC microproject > of refactoring remove_subtree() from recursively using > readdir() to use dir_iterator. Below are the threads for > other versions: > > v1: >

Re: [PATCH v2 16/21] Make sha1_array_append take a struct object_id *

"brian m. carlson" writes: > Convert the callers to pass struct object_id by changing the function > declaration and definition and applying the following semantic patch: > > @@ > expression E1, E2, E3; > @@ > - sha1_array_append(E1, E2[E3].hash) > +

Re: [PATCH v2 16/21] Make sha1_array_append take a struct object_id *

On Tue, Mar 28, 2017 at 10:27:41AM -0700, Junio C Hamano wrote: > "brian m. carlson" writes: > > > Convert the callers to pass struct object_id by changing the function > > declaration and definition and applying the following semantic patch: > > > > @@ > >

Re: [PATCH 0/18] snprintf cleanups

Jeff King writes: > It's a lot of patches, but hopefully they're all pretty straightforward > to read. Yes, quite a lot of changes. I didn't see anything questionable in there. As to the "patch-id" thing, I find the alternate one slightly easier to read. Also, exactly because

Git fails to build on Ubuntu Server 16.04

I configured with --enable-pthreads, and LIBS included -lpthread. $ make V=1 gcc -I/usr/local/include -g -O2 -I. -DHAVE_ALLOCA_H -I/usr/local/include -DUSE_CURL_FOR_IMAP_SEND -I/usr/local/include -I/usr/local/include -DHAVE_PATHS_H -DHAVE_STRINGS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME

Re: [PATCH 2/2] submodule.c: correctly handle nested submodules in is_submodule_modified

Stefan Beller wrote: > Suppose I have a superproject 'super', with two submodules 'super/sub' > and 'super/sub1'. 'super/sub' itself contains a submodule > 'super/sub/subsub'. Now suppose I run, from within 'super': > > echo hi >sub/subsub/stray-file > echo hi >sub1/stray-file > >

Re: Proposal for "fetch-any-blob Git protocol" and server design

+cc Ben Peart, who sent "[RFC] Add support for downloading blobs on demand" to the list recently. This proposal here seems like it has the same goal, so maybe your review could go a long way here? Thanks, Stefan On Tue, Mar 14, 2017 at 3:57 PM, Jonathan Tan wrote: > As

[PATCH 2/2] submodule.c: correctly handle nested submodules in is_submodule_modified

Suppose I have a superproject 'super', with two submodules 'super/sub' and 'super/sub1'. 'super/sub' itself contains a submodule 'super/sub/subsub'. Now suppose I run, from within 'super': echo hi >sub/subsub/stray-file echo hi >sub1/stray-file Currently we get would see the following

[PATCH v8 0/7] short status: improve reporting for submodule changes

v8: * This is a resend of the last two patches, i.e. these two patches apply at 5c896f7c3ec (origin/sb/submodule-short-status^^) * below is a diff of this patch series against origin/sb/submodule-short-status * add tests showing the subtle bug fix in case of nesting. * add a bit of documentation

[PATCH 1/2] short status: improve reporting for submodule changes

If I add an untracked file to a submodule or modify a tracked file, currently "git status --short" treats the change in the same way as changes to the current HEAD of the submodule: $ git clone --quiet --recurse-submodules https://gerrit.googlesource.com/gerrit $ echo hello

Re: [PATCH v3 2/5] setup: allow for prefix to be passed to git commands

On Mon, Mar 20, 2017 at 3:34 PM, Brandon Williams wrote: > That the gist of how I'm hoping to solve the problem. Hopefully that was > clear enough to get some feedback on. Junio wrote in "What's cooking in git.git (Mar 2017, #10; Fri, 24)" > I saw no particular issues

[PATCH v4 2/5] dir_iterator: iterate over dir after its contents

Create an option for the dir_iterator API to iterate over subdirectories only after having iterated through their contents. This feature was predicted, although not implemented by 0fe5043 ("dir_iterator: new API for iterating over a directory tree", 2016-06-18). Add the "flags" parameter to

[PATCH v4 5/5] files_reflog_iterator: amend use of dir_iterator

Amend a call to dir_iterator_begin() to pass the flags parameter introduced in 3efb5c0 ("dir_iterator: iterate over dir after its contents", 2017-28-03). Signed-off-by: Daniel Ferreira --- refs/files-backend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v4 1/5] dir_iterator: add helpers to dir_iterator_advance

Create inline helpers to dir_iterator_advance(). Make dir_iterator_advance()'s code more legible and allow some behavior to be reusable. Signed-off-by: Daniel Ferreira --- dir-iterator.c | 65 +- 1 file changed, 42

[PATCH v4 3/5] remove_subtree(): reimplement using iterators

Use dir_iterator to traverse through remove_subtree()'s directory tree, avoiding the need for recursive calls to readdir(). Simplify remove_subtree()'s code. A conversion similar in purpose was previously done at 46d092a ("for_each_reflog(): reimplement using iterators", 2016-05-21).

Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote: > FreeBSD implements getcwd(3) as a syscall, but falls back to a version > based on readdir(3) if it fails for some reason. The latter requires > permissions to read and execute path components, while the former does > not. That

Git hackathon New York / London - call for mentors

Bloomberg would like to host a Git hackathon over a weekend in both New York and London, towards the end of April or the beginning of May. Crucial to the success of the weekend will be having mentors available in both locations who can guide people on the project. Mentors should have some

[PATCH v4 0/5] [GSoC] remove_subtree(): reimplement using iterators

Hi there, This is the fourth version of the GSoC microproject of refactoring remove_subtree() from recursively using readdir() to use dir_iterator. Below are the threads for other versions: v1: https://public-inbox.org/git/CAGZ79kZwT-9mHTiOJ5CEjk2wDFkn6+NcogjX0=vjhsah16a...@mail.gmail.com/T/#t

[PATCH v4 4/5] remove_subtree(): test removing nested directories

Test removing a nested directory when an attempt is made to restore the index to a state where it does not exist. A similar test could be found previously in t/t2000-checkout-cache-clash.sh, but it did not check for nested directories, which could allow a faulty implementation of remove_subtree()

Re: [PATCH 7/7] submodule.c: correctly handle nested submodules in is_submodule_modified

On Mon, Mar 27, 2017 at 2:46 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> When a nested submodule has untracked files, it would be reported as >> "modified submodule" in the superproject, because submodules are not >> parsed correctly in

Re: Git fails to build on Ubuntu Server 16.04

On Tue, Mar 28, 2017 at 07:17:16PM -0400, Jeffrey Walton wrote: > I configured with --enable-pthreads, and LIBS included -lpthread. > > $ make V=1 > gcc -I/usr/local/include -g -O2 -I. -DHAVE_ALLOCA_H > -I/usr/local/include -DUSE_CURL_FOR_IMAP_SEND -I/usr/local/include > -I/usr/local/include

Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

On Tue, Mar 28, 2017 at 2:15 PM, Christian Couder wrote: > On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote: >> FreeBSD implements getcwd(3) as a syscall, but falls back to a version >> based on readdir(3) if it fails for some reason. The latter

Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

On Tue, Mar 28, 2017 at 11:24 PM, Stefan Beller wrote: > On Tue, Mar 28, 2017 at 2:15 PM, Christian Couder > wrote: >> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote: >>> FreeBSD implements getcwd(3) as a syscall, but falls back

Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

On Tue, Mar 28, 2017 at 11:49 PM, Jeff King wrote: > On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote: > >> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote: >> > FreeBSD implements getcwd(3) as a syscall, but falls back to a version >> > based on

Can't locate ExtUtils/MakeMaker.pm in @INC

This looks like the last issue with Git 2.12.2. This time the machine is Fedora 25. I configured with PERL_PATH=/usr/local/bin/perl. The local Perl was built specifically for this error, and it includes ExtUtils/MakeMaker.pm: $ find /usr/local -name MakeMaker.pm

Re: Can't locate ExtUtils/MakeMaker.pm in @INC

On Tue, Mar 28, 2017 at 09:03:43PM -0400, Jeffrey Walton wrote: > This looks like the last issue with Git 2.12.2. This time the machine > is Fedora 25. > > I configured with PERL_PATH=/usr/local/bin/perl. The local Perl was > built specifically for this error, and it includes >

Re: [PATCH 0/18] snprintf cleanups

On Tue, Mar 28, 2017 at 03:33:48PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > It's a lot of patches, but hopefully they're all pretty straightforward > > to read. > > Yes, quite a lot of changes. I didn't see anything questionable in > there. > > As to the

Re: [PATCH v4 1/5] dir_iterator: add helpers to dir_iterator_advance

On 03/29/2017 02:32 AM, Daniel Ferreira wrote: > Create inline helpers to dir_iterator_advance(). Make > dir_iterator_advance()'s code more legible and allow some behavior to > be reusable. Thanks for breaking up the patches. That makes them a lot easier to review. > Signed-off-by: Daniel

Re: Re: Microproject | Add more builtin patterns for userdiff

Stefan Beller wrote: > On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote: > > > EOF > > > > echo '* diff="cpp"' > .gitmodules > > Did you mean .gitattributes? Yeah, that's a spelling error.

Re: Re: Re: Microproject | Add more builtin patterns for userdiff

Jacob Keller wrote: > On Tue, Mar 28, 2017 at 10:53 AM, Pickfire wrote: > > > > Yes, I can't reproduce it outside the test suite. I have added the builtin > > and yet the test fails. test_decode_color gets same output as expect but > > still it

Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote: > On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote: > > FreeBSD implements getcwd(3) as a syscall, but falls back to a version > > based on readdir(3) if it fails for some reason. The latter requires > >

Re: [PATCH 1/2] short status: improve reporting for submodule changes

Hi, Stefan Beller wrote: [...] > +++ b/t/t7506-status-submodule.sh [...] > @@ -287,4 +311,82 @@ test_expect_success 'diff --submodule with merge > conflict in .gitmodules' ' > test_cmp diff_submodule_actual diff_submodule_expect > ' > > +test_expect_success 'setup superproject with

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 11:13:15AM +, brian m. carlson wrote: > > I suggested an additional cleanup around "linelen" in one patch. In the > > name of keeping the number of re-rolls sane, I'm OK if we skip that for > > now (the only reason I mentioned it at all is that you have to justify > >

Re: Re: Microproject | Add more builtin patterns for userdiff

Jacob Keller wrote: > On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote: > > While I was working buildins shell patterns for user diffs. I noticed that > > the tests t4034 passes but I can reproduce it manually with: > > > > mkdir cpp/ && cd cpp/

Re: [GSoC] Proposal: turn git-add--interactive.perl into a builtin

On Sat, Mar 25, 2017 at 8:15 PM, Daniel Ferreira (theiostream) wrote: > SYNOPSIS > There are many advantages to converting parts of git that are still > scripts to C builtins, among which execution speed, improved > compatibility and code deduplication. agreed. >

Re: Re: Microproject | Add more builtin patterns for userdiff

On Tue, Mar 28, 2017 at 10:53 AM, Pickfire wrote: > > Yes, I can't reproduce it outside the test suite. I have added the builtin > and yet the test fails. test_decode_color gets same output as expect but > still it fails, should I send in the patch? You also need to ensure

Re: UNS: Re: cherry-pick --message?

Andreas Krey wrote: > On Tue, 21 Mar 2017 13:33:35 +, Jeff King wrote: >> Probably "format-patch | sed | am -3" is your best bet if you want to >> modify the patches in transit _and_ have the user just use normal git >> tools. > > Except that 'git am' doesn't have --no-commit like cherry-pick

Re: [PATCH v2 00/21] object_id part 7

Jeff King writes: > On Sun, Mar 26, 2017 at 04:01:22PM +, brian m. carlson wrote: > >> This is part 7 in the continuing transition to use struct object_id. >> >> This series focuses on two main areas: adding two constants for the >> maximum hash size we'll be using (which

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 01:35:36PM -0400, Jeff King wrote: > I thought I'd knock this out quickly before I forgot about it. But it > actually isn't so simple. > > The main caller in read_head_info() does indeed just pass strlen(line) > as the length in each case. But the cert parser really does

Re: Microproject | Add more builtin patterns for userdiff

On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote: > EOF > > echo '* diff="cpp"' > .gitmodules Did you mean .gitattributes?

Re: [PATCH] [GSOC] get_non_kept_pack_filenames(): reimplement using iterators

On Mon, Mar 27, 2017 at 6:39 PM, Robert Stanca wrote: > Replaces recursive traversing of opendir with dir_iterator. > > Signed-off-by: Robert Stanca > --- > builtin/repack.c | 15 ++- > 1 file changed, 6 insertions(+), 9

[RFC] should these two topics graduate to 'master' soon?

There are two topics that are marked as "Will cook in 'next'" for practically forever in the "What's cooking" reports. The world may have become ready for one or both of them, in which case we should do the merge not too late in the cycle. * jc/merge-drop-old-syntax (2015-04-29) 1 commit This

Re: [RFC] should these two topics graduate to 'master' soon?

Hi Junio, Junio C Hamano wrote: > There are two topics that are marked as "Will cook in 'next'" for > practically forever in the "What's cooking" reports. The world may > have become ready for one or both of them, in which case we should > do the merge not too late in the cycle. > > *

Re: [RFC] should these two topics graduate to 'master' soon?

On Tue, Mar 28, 2017 at 11:35 AM, Junio C Hamano wrote: > There are two topics that are marked as "Will cook in 'next'" for > practically forever in the "What's cooking" reports. The world may > have become ready for one or both of them, in which case we should > do the merge

Re: [PATCH RFC 2/2] diff: teach diff to expand tabs in output

Jacob Keller writes: > I'm really not a fan of how the ws code ended up. It seems pretty ugly > and weird to hack in the expand_tabs stuff here. However, I'm really not > sure how else I could handle this. Additionally, I'm not 100% sure > whether this interacts with

Re: [RFC] should these two topics graduate to 'master' soon?

On Tue, Mar 28, 2017 at 11:51:49AM -0700, Jonathan Nieder wrote: > > * jc/merge-drop-old-syntax (2015-04-29) 1 commit > > > > This topic stops "git merge HEAD " syntax that > > has been deprecated since October 2007 (and we have issued a > > warning message since around v2.5.0 when the

[PATCH v3 1/2] read-cache: core.checksumindex

From: Jeff Hostetler Teach git to skip verification of the index SHA in verify_hdr() in read_index(). This is a performance optimization. The index file SHA verification can be considered an ancient relic from the early days of git and only useful for detecting disk

[PATCH v3 2/2] test-core-checksum-index: core.checksumindex test helper

From: Jeff Hostetler Created test helper to measure read_index() with and without core.checksumindex set and report performance. Signed-off-by: Jeff Hostetler --- Makefile| 1 + t/helper/.gitignore |

[PATCH v3 0/2] read-cache: call verify_hdr() in a background thread

From: Jeff Hostetler Version 3 of this patch series simplifies this effort to just turn on/off the hash verification using a "core.checksumindex" config variable. I've preserved the original checksum validation code so that we can force it on in fsck if desired. It

Re: [PATCH v3 0/2] read-cache: call verify_hdr() in a background thread

On Tue, Mar 28, 2017 at 07:07:30PM +, g...@jeffhostetler.com wrote: > From: Jeff Hostetler > > Version 3 of this patch series simplifies this effort to just turn > on/off the hash verification using a "core.checksumindex" config variable. > > I've preserved the

Re: [PATCH RFC 2/2] diff: teach diff to expand tabs in output

On Tue, Mar 28, 2017 at 01:05:40PM -0700, Jacob Keller wrote: > On Tue, Mar 28, 2017 at 12:03 PM, Junio C Hamano wrote: > > Jacob Keller writes: > > > >> I'm really not a fan of how the ws code ended up. It seems pretty ugly > >> and weird to hack in

Re: [PATCH RFC 2/2] diff: teach diff to expand tabs in output

Jeff King writes: > That also means an option to something like "expand" is tough, because > "first character" really means "first non-ANSI-code character". That is true, but once you commit to the mindset that you are extending "expand", then that becomes a mere part of what