Signed-off-by: Elijah Newren
---
merge-recursive.c | 18 +-
merge-recursive.h | 1 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index f110e1c5ec..bf3cb03d3a 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2843,
Let's say you have the following three trees, where Base is from one commit
behind either master or branch:
Base : bar_v1, foo/{file1, file2, file3}
branch: bar_v2, foo/{file1, file2}, goo/file3
master: bar_v3, foo/{file1, file2, file3}
Using git-am (or am-based rebase) to apply t
Similar to commit 16346883ab ("t3401: add directory rename testcases for
rebase and am", 2018-06-27), add another testcase for directory rename
detection. This new testcase differs in that it showcases a situation
where no directory rename was performed, but which some backends
incorrectly detect.
On Tue, Aug 28, 2018 at 9:58 AM Junio C Hamano wrote:
> Elijah Newren writes:
>
> > - Add a flag to turn off directory rename detection, and set the
> > flag for every call from am.c in order to avoid problems like this.
>
> I'd say this is the only practical solution, before you deprecate
> th
On Tue, 28 Aug 2018 12:37:40 -0700, Junio C Hamano
wrote:
> "H.Merijn Brand" writes:
>
> > So, my wish would be to have an option, possibly using -- to pass
> > additional command line arguments to git difftool, so that
> >
> > $ git difftool $commit~1..$commit -- -m -v2
> >
> > would pass the
On Wed, Aug 29 2018, brian m. carlson wrote:
> Generally, one gets better performance out of cryptographic routines
> written in assembly than C, and this is also true for SHA-256
It makes sense to have a libgcrypt implementation...
> In addition, most Linux distributions cannot distribute Git
On Fri, Aug 24 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>>> git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}
>>
>> How is this going to interact with other peel syntax? I.e. now we have
>> ^{commit} ^{tag} etc. It seems to me we'll need not ^{sha1}
>>
On Wed, Aug 29 2018, brian m. carlson wrote:
> SHA-1 is weak and we need to transition to a new hash function. For
> some time, we have referred to this new function as NewHash.
>
> The selection criteria for NewHash specify that it should (a) be 256
> bits in length, (b) have high quality impl
On Wed, Aug 29 2018, brian m. carlson wrote:
> If libgit2 would like to import this SHA-256 implementation, they're
> welcome to do so under their normal license terms. If not, that's fine,
> too.
For them and anyone else interested in such re-use, can you elaborate on
which parts?
It seems t
A here-doc tag can be quoted ('EOF'/"EOF") or escaped (\EOF) to suppress
interpolation within the body. chainlint recognizes single-quoted and
escaped tags, but does not know about double-quoted tags. For
completeness, teach it to recognize double-quoted tags, as well.
Signed-off-by: Eric Sunshine
Jeff King wrote:
> I've thought about mirroring it to a public server as well, just for
> redundancy. But without the same domain, I'm not sure it would be all
> that useful as a community resource.
I wouldn't get too attached to the domain, "public-inbox.org" is
too long for my tastes anyways.
On 8/28/2018 5:59 PM, Eric Sunshine wrote:
On Tue, Aug 28, 2018 at 5:31 PM Derrick Stolee wrote:
On 8/28/2018 4:41 PM, Stefan Beller wrote:
On Tue, Aug 28, 2018 at 1:33 PM Derrick Stolee via GitGitGadget
wrote:
+ GIT_TEST_COMMIT_GRAPH=0 &&
+ test_must_fail git mer
On 8/28/2018 8:56 PM, brian m. carlson wrote:
+ rawsz="$(test_oid rawsz)" &&
+ hexsz="$(test_oid hexsz)" &&
These are neat helpers! The 'git commit-graph verify' tests in
t5318-commit-graph.sh should automatically work if we use these for
HASH_LEN instead of 20. I'll use a similar
From: Derrick Stolee
The commit-graph feature is tested in isolation by
t5318-commit-graph.sh and t6600-test-reach.sh, but there are many
more interesting scenarios involving commit walks. Many of these
scenarios are covered by the existing test suite, but we need to
maintain coverage when the op
The commit-graph (and multi-pack-index) features are optional data
structures that can make Git operations faster. Since they are optional, we
do not enable them in most Git tests. The commit-graph is tested in
t5318-commit-graph.sh (and t6600-test-reach.sh in ds/reachable), but that
one script can
On 8/28/2018 8:58 PM, brian m. carlson wrote:
Instead of using hard-coded constants for object sizes, use
the_hash_algo to look them up. In addition, use a function call to look
up the object ID version and produce the correct value.
The C code in this patch looks good to me. The only issue is
Hi Elijah,
On Wed, 29 Aug 2018, Elijah Newren wrote:
> Let's say you have the following three trees, where Base is from one commit
> behind either master or branch:
>
>Base : bar_v1, foo/{file1, file2, file3}
>branch: bar_v2, foo/{file1, file2}, goo/file3
>master: bar_v3, foo/
Hi Elijah,
On Wed, 29 Aug 2018, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> merge-recursive.c | 18 +-
> merge-recursive.h | 1 +
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index f110e1c5ec..bf3c
On 8/28/2018 8:58 PM, brian m. carlson wrote:
SHA-256 is somewhat slower to compute than SHA-1 in software. However,
since our default SHA-1 implementation is collision-detecting, a
reasonable cryptographic library implementation of SHA-256 will actually
be faster than SHA-256.
Nit: do you mea
Hi Jonathan,
On Tue, 28 Aug 2018, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
> > On Thu, 23 Aug 2018, Jonathan Nieder wrote:
> > > Ævar Arnfjörð Bjarmason wrote:
>
> >>> Are we going to need a midx version of these mapping files? How does
> >>> midx fit into this picture? Perhaps it's t
On Tue, Aug 28 2018, Jeff King wrote:
> The Outreachy application period is set to begin on September 10th for
> interns participating in the December-March program. Do we want to
> participate?
>
> Details on the program are here:
>
> https://www.outreachy.org/communities/cfp/
>
> If we want
Hi Junio,
On Tue, 28 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I do recall discouraging you from including irrelevant rant/whine in
> >> the log message a few times in the recent past, and also I do recall
> >> you never listening to me. Don't make me an excuse.
> >
On 8/29/2018 9:09 AM, Johannes Schindelin wrote:
Hi Jonathan,
On Tue, 28 Aug 2018, Jonathan Nieder wrote:
Johannes Schindelin wrote:
On Thu, 23 Aug 2018, Jonathan Nieder wrote:
Ævar Arnfjörð Bjarmason wrote:
Are we going to need a midx version of these mapping files? How does
midx fit into
Previously, the sed command for generating manpage-base-url.xsl
was printed to the console when being run.
Make the console output for this rule similiar to all the
other rules by printing a short status message instead of
the whole command.
Signed-off-by: Tim Schumacher
---
To Junio C Hamano:
Hi Jonathan,
On Tue, 28 Aug 2018, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
> > On Mon, 27 Aug 2018, Junio C Hamano wrote:
> >> Johannes Schindelin writes:
> >>> Jonathan Nieder wrote:
>
> Please include this information in the commit message. It's super
> helpful to find t
From: Johannes Schindelin
The builtin rebase and the builtin interactive rebase have been
developed independently, on purpose: Google Summer of Code rules
specifically state that students have to work on independent projects,
they cannot collaborate on the same project.
One fallout is that the r
The builtin rebase and the builtin interactive rebase have been developed
independently, on purpose: Google Summer of Code rules specifically state
that students have to work on independent projects, they cannot collaborate
on the same project.
The reason is probably the very fine tradition in aca
Hi Jonathan,
On Tue, 28 Aug 2018, Jonathan Nieder wrote:
> [... talking about the IRC channel ...]
>
> My offer to +v anyone affected by the channel's current settings still
> stands (just /msg me). Zero people have taken me up on this offer so
> far.
I did have problems seeing any private mes
On 8/29/2018 9:27 AM, Derrick Stolee wrote:
On 8/29/2018 9:09 AM, Johannes Schindelin wrote:
What I meant was to leverage the midx code, not the .midx files.
My comment was motivated by my realizing that both the SHA-1 <-> SHA-256
mapping and the MIDX code have to look up (in a *fast* way) inf
Hi Peff,
On Wed, 29 Aug 2018, Jeff King wrote:
> On Mon, Aug 27, 2018 at 03:22:39PM +0200, Johannes Schindelin wrote:
>
> > Having said that, I believe that we core contributors can learn to have a
> > fruitful online meeting. With 30+ participants, too.
> >
> > Learning from my past life in ac
Hi Peff,
On Wed, 29 Aug 2018, Jeff King wrote:
> On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:
>
> > Rather than have a "hack day", I would actually prefer to work with
> > other contributors in a way that we have not done before, but which I
> > had the pleasure of "test
Team,
the corresponding Git for Windows v2.19.0-rc1 (most notably with the
Experimental Options page in the installer letting you opt into using the
built-in `stash` and `rebase`) was built by Jameson Miller (and me) last
night and can be found here:
https://github.com/git-for-windows/git/release
This patch helps address the CPU cost of loading the index by loading
the cache extensions on a worker thread in parallel with loading the cache
entries.
This is possible because the current extensions don't access the cache
entries in the index_state structure so are OK that they don't all exist
- strbuf_remove() in expand_name_field() is not exactly a good fit
for stripping a part at the end, _setlen() would do the same job
and is much cheaper.
- the open-coded loop to find the end of the string in
expand_name_field() can't beat an optimized strlen()
I used p0002-read-cache.s
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It accomplishes this by having the primary thread loop across the index file
tracking the offset and (for V4 indexe
The big changes in this itteration are:
- Switched to index.threads to provide control over the use of threading
- Added another worker thread to load the index extensions in parallel
- Applied optimization expand_name_field() suggested by Duy
The net result of these optimizations is a savings
On 2018-08-29 12:02, Eric Wong wrote:
> Anyways I hope to teach public-inbox to auto-linkify Message-ID-looking
> strings "" into URLs for domain-portability,
> (but it's ambiguous with email addresses). But yeah, I don't
> like things being tied to domain names.
This would be very useful for peo
Previously, the sed command for generating manpage-base-url.xsl
was printed to the console when being run.
Make the console output for this rule similiar to all the
other rules by printing a short status message instead of
the whole command.
Signed-off-by: Tim Schumacher
---
Documentation/Makef
Hi Ulrich,
On Tue, 28 Aug 2018, Ulrich Gemkow wrote:
> A trivial enhancement request:
>
> All commands which require that the author is set (and complain if
> it is not set) should accept the option --author.
>
> At least the command stash does not accept this option. We are using
> git version
On Wed, Aug 29 2018, Andrei Rybak wrote:
> On 2018-08-29 12:02, Eric Wong wrote:
>> Anyways I hope to teach public-inbox to auto-linkify Message-ID-looking
>> strings "" into URLs for domain-portability,
>> (but it's ambiguous with email addresses). But yeah, I don't
>> like things being tied t
Hello all,
I have recently joined a team there seems to be a couple of issue
with the git repositories:
1- A branch created from development cannot be merged into the
production branch.
(production)
git merge development_feature_branch
fatal: refusing to merge unrelated histories
2-
Tim Schumacher wrote:
> Subject: doc: Don't echo sed command for manpage-base-url.xsl
At first glance, I thought this was going to change the rendered
documentation in some way. Maybe this should say
Makefile: make 'sed' commands quieter
? That led me to look in the Makefile, where it
Tim Schumacher wrote:
> Subject: doc: Don't echo sed command for manpage-base-url.xsl
Cribbing from my review of v2: a description like
Documentation/Makefile: make manpage-base-url.xsl generation quieter
would make it more obvious what this does when viewed in "git log
--oneline".
> P
Ben Peart writes:
> This is possible because the current extensions don't access the cache
> entries in the index_state structure so are OK that they don't all exist
> yet.
>
> The CACHE_EXT_TREE, CACHE_EXT_RESOLVE_UNDO, and CACHE_EXT_UNTRACKED
> extensions don't even get a pointer to the index s
Duy Nguyen writes:
> Yeah I kinda hated dummy_entry too but the feeling wasn't strong
> enough to move towards the index->version check. I guess I'm going to
> do it now.
Sounds like a plan. Thanks again for a pleasant read.
Ben Peart writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 1c42364988..79f8296d9c 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2391,6 +2391,12 @@ imap::
> The configuration variables in the 'imap' section are described
>
Stefan Beller writes:
> Not quite, as this is ...
>
> Looking at the test in the previous patch, I would think a reasonable workflow
> in the test is ...
>
>> The MOVE_HEAD_FORCE codepath that follows this hunk is, eh, already
>> forcing to correct the situation, so there is no need to touch tha
On 29.08.18 18:55, Jonathan Nieder wrote:
Tim Schumacher wrote:
Subject: doc: Don't echo sed command for manpage-base-url.xsl
Cribbing from my review of v2: a description like
Documentation/Makefile: make manpage-base-url.xsl generation quieter
would make it more obvious what this d
On Wed, Aug 29, 2018 at 2:13 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Aug 24 2018, Jonathan Nieder wrote:
>
> > Hi,
> >
> > Ævar Arnfjörð Bjarmason wrote:
> >
> >>> git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}
> >>
> >> How is this going to interact with other peel syntax?
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Aug 24 2018, Jonathan Nieder wrote:
>> Ævar Arnfjörð Bjarmason wrote:
>>> Or is this expected to be chained, as e.g. ^{tag}^{sha256} ?
>>
>> Great question. The latter (well, ^{sha256}^{tag}, not the
>> other way around).
>
> Since nobody's chimed in
Stefan Beller wrote:
> And with that model, ^{sha256}^{tree}
> could mean to obtain the sha256 value of and then derive
> the tree from that object,
What does "the sha256 value of " mean?
For example, in a repository with two objects:
1. an object with sha1-name abcdabcdabcda
On Tue, Aug 28, 2018 at 10:25 PM Jeff King wrote:
>
> On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>
> > 3) (optional) instead of putting it all in modules/, use another
> >directory gitmodules/ for example. this will make sure we can tell
> >if a repository has been conv
On Wed, Aug 29, 2018 at 9:49 AM Tomas Zubiri wrote:
>
> Hello all,
>
> I have recently joined a team there seems to be a couple of issue
> with the git repositories:
>
>
> 1- A branch created from development cannot be merged into the
> production branch.
>
>
>
> (production)
>
> git merge develo
On Wed, Aug 29, 2018 at 10:59 AM Jonathan Nieder wrote:
>
> Stefan Beller wrote:
>
> > And with that model, ^{sha256}^{tree}
> > could mean to obtain the sha256 value of and then derive
> > the tree from that object,
>
> What does "the sha256 value of " mean?
s/hexvalue/hexdigit
On Wed, Aug 29 2018, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> And with that model, ^{sha256}^{tree}
>> could mean to obtain the sha256 value of and then derive
>> the tree from that object,
>
> What does "the sha256 value of " mean?
>
> For example, in a repository wi
Johannes Schindelin writes:
> The `stash` command only incidentally requires that the author is set, as
> it calls `git commit` internally (which records the author). As stashes
> are intended to be local only, that author information was never meant to
> be a vital part of the `stash`.
>
> I cou
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>> what objects would you expect the following to refer to?
>>
>> abcdabcd^{sha1}
>> abcdabcd^{sha256}
>> ef01ef01^{sha1}
>> ef01ef01^{sha256}
>
> I still can't really make any sense of why anyone would even
On Wed, Aug 29 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>
>>> what objects would you expect the following to refer to?
>>>
>>> abcdabcd^{sha1}
>>> abcdabcd^{sha256}
>>> ef01ef01^{sha1}
>>> ef01ef01^{sha256}
>>
>>
Some commands like 'log' default to HEAD if no other revisions are
specified on the command line or otherwise. Unfortunately, excludes
(^) cancel out that default, so when a command only excludes
revisions (e.g., 'git log ^origin/master'), the command will not produce
any result.
If all the speci
Thank you for taking the time to help me Stefan
On Aug 29, 2018 15:15, "Stefan Beller" wrote:
>
> On Wed, Aug 29, 2018 at 9:49 AM Tomas Zubiri wrote:
> >
> > Hello all,
> >
> > I have recently joined a team there seems to be a couple of issue
> > with the git repositories:
> >
> >
> > 1- A bra
+cc the mailing list
> > >
> > > git merge development_feature_branch
> > > fatal: refusing to merge unrelated histories
> > >
> >
> > See the git merge man page for the
> > --allow-unrelated-histories switch.
>
> I have tried that switch, however when merging a small feature branch,
> the merge
Ævar Arnfjörð Bjarmason writes:
> Fix this by removing the redundant quotes. There's no need for them,
> and the resulting code works under all the aforementioned shells. This
> fixes a regression in c2f1d3989 ("t4013: test new output from diff
> --abbrev --raw", 2017-12-03) first released with G
On Wed, Aug 29, 2018 at 10:17 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > Not quite, as this is ...
> >
> > Looking at the test in the previous patch, I would think a reasonable
> > workflow
> > in the test is ...
> >
> >> The MOVE_HEAD_FORCE codepath that follows this hunk is, eh,
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>> In other words, I want the input format and output format completely
>> decoupled. If I pass ^{sha1}, I am indicating the input format. To
>> specify the output format, I'd use --output-format instead.
>
> This
Jonathan Nieder writes:
> In other words, I want the input format and output format completely
> decoupled.
I thought that the original suggestion was to use "hashname:" as a
prefix to specify input format. In other words
sha1:abababab
sha256:abababab
And an unadorned abababab
If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
`memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
into `dst_buf`.
This is not an exploitable bug because triggering the bug increments the
`data` pointer beyond `top`, causing the `data != top` sanity check af
This ensures that any attempts to access memory directly after the input
buffer or delta buffer in a delta test will cause a segmentation fault.
Inspired by vsftpd.
Signed-off-by: Jann Horn
---
t/helper/test-delta.c | 78 +--
1 file changed, 53 insertions
This verifies the changes from commit "patch-delta: fix oob read".
Signed-off-by: Jann Horn
---
t/t5303-pack-corruption-resilience.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/t/t5303-pack-corruption-resilience.sh
b/t/t5303-pack-corruption-resilience.sh
index 3634e
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> In other words, I want the input format and output format completely
>> decoupled.
>
> I thought that the original suggestion was to use "hashname:" as a
> prefix to specify input format. In other words
>
> sha1:abababab
> sha256:aba
On Wed, Aug 29, 2018 at 11:10:51AM -0700, Stefan Beller wrote:
> > Do you care about case-folding issues (e.g., submodules "FOO" and "foo"
> > colliding)?
>
> I do. :(
>
> 2d84f13dcb6 (config: fix case sensitive subsection names on writing,
> 2018-08-08)
> explains the latest episode of case fo
On Mon, Aug 27, 2018 at 03:12:56PM -0700, Stefan Beller wrote:
> When cloning a superproject with the option
> --recurse-submodules='.', it is easy to find yourself wanting
> a submodule active, but not having that submodule present in
> the modules directory.
>
> Signed-off-by: Stefan Beller
>
Jeff King wrote:
> On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>> Yeah, then let's just convert '/' with as little overhead as possible.
>
> Do you care about case-folding issues (e.g., submodules "FOO" and "foo"
> colliding)?
>
> I'm OK if the answer is "no", but if you do want
> Yes, that makes even the capitalized "CON" issues go away. It's not a
> one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
foo_ would map to foo__, and foo- would map to something else.
(foo- as we do not rewrite dashes, yet?)
>
> If we want that, too, I think something like
On Wed, Aug 29, 2018 at 2:09 PM Jonathan Nieder wrote:
>
> Jeff King wrote:
> > On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>
> >> Yeah, then let's just convert '/' with as little overhead as possible.
> >
> > Do you care about case-folding issues (e.g., submodules "FOO" and "fo
Hi,
Stefan Beller wrote:
>> Yes, that makes even the capitalized "CON" issues go away. It's not a
>> one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
>
> foo_ would map to foo__, and foo- would map to something else.
> (foo- as we do not rewrite dashes, yet?)
>
>> If we want
On Wed, Aug 29, 2018 at 10:58:55PM +0200, Jann Horn wrote:
> If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
> `memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
> into `dst_buf`.
>
> This is not an exploitable bug because triggering the bug increments the
On 08/29, Stefan Beller wrote:
> On Wed, Aug 29, 2018 at 2:09 PM Jonathan Nieder wrote:
> >
> > Jeff King wrote:
> > > On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
> >
> > >> Yeah, then let's just convert '/' with as little overhead as possible.
> > >
> > > Do you care about case
On Wed, Aug 29, 2018 at 2:18 PM Jonathan Nieder wrote:
>
> Hi,
>
> Stefan Beller wrote:
>
> >> Yes, that makes even the capitalized "CON" issues go away. It's not a
> >> one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
> >
> > foo_ would map to foo__, and foo- would map to so
On Wed, Aug 29, 2018 at 02:10:37PM -0700, Stefan Beller wrote:
> > Yes, that makes even the capitalized "CON" issues go away. It's not a
> > one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
>
> foo_ would map to foo__, and foo- would map to something else.
> (foo- as we do n
On Wed, Aug 29, 2018 at 02:09:13PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>
> >> Yeah, then let's just convert '/' with as little overhead as possible.
> >
> > Do you care about case-folding issues (e.g., submodules "FOO
On Wed, Aug 29, 2018 at 10:58:56PM +0200, Jann Horn wrote:
> This ensures that any attempts to access memory directly after the input
> buffer or delta buffer in a delta test will cause a segmentation fault.
>
> Inspired by vsftpd.
Neat trick, but it seems funny to protect this one buffer in
non
On 8/29/2018 1:14 PM, Junio C Hamano wrote:
Ben Peart writes:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1c42364988..79f8296d9c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2391,6 +2391,12 @@ imap::
The configuration variables
On Wed, Aug 29, 2018 at 11:34 PM Jeff King wrote:
>
> On Wed, Aug 29, 2018 at 10:58:56PM +0200, Jann Horn wrote:
>
> > This ensures that any attempts to access memory directly after the input
> > buffer or delta buffer in a delta test will cause a segmentation fault.
> >
> > Inspired by vsftpd.
>
On 8/29/2018 1:12 PM, Junio C Hamano wrote:
Ben Peart writes:
This is possible because the current extensions don't access the cache
entries in the index_state structure so are OK that they don't all exist
yet.
The CACHE_EXT_TREE, CACHE_EXT_RESOLVE_UNDO, and CACHE_EXT_UNTRACKED
extensions
On Wed, Aug 29, 2018 at 11:40:41PM +0200, Jann Horn wrote:
> > If we want to detect this kind of thing in tests, we should probably be
> > relying on tools like ASan, which would cover all mmaps.
> >
> > It would be nice if there was a low-cost way to detect this in
> > production use, but it look
On Wed, Aug 29, 2018 at 05:46:21PM -0400, Jeff King wrote:
> > I think even with ASAN, you'd still need read_in_full() or an mmap()
> > wrapper that fiddles with the ASAN shadow, because mmap() always maps
> > whole pages:
> >
> > $ cat mmap-read-asan-blah.c
> > #include
> > #include
> > int ma
On Wed, Aug 29, 2018 at 10:58:57PM +0200, Jann Horn wrote:
> This verifies the changes from commit "patch-delta: fix oob read".
A minor nit, but usually we'd either introduce tests along with the
fix, or introduce them beforehand as test_expect_failure and then flip
them to success along with the
Elijah Newren writes:
> +test_expect_success 'rebase --interactive: NO directory rename' '
> + test_when_finished "git -C no-dir-rename rebase --abort" &&
> + (
> + cd no-dir-rename &&
> +
> + git checkout B^0 &&
> +
> + set_fake_editor &&
> +
On Wed, Aug 29, 2018 at 05:20:25PM -0400, Jeff King wrote:
> Nice catch. The patch looks good to me, but just to lay out my thought
> process looking for other related problems:
>
> We have two types of instructions:
>
> 1. Take N bytes from position P within the source.
>
> 2. Take the nex
On Wed, Aug 29, 2018 at 06:03:53PM -0400, Jeff King wrote:
> Without your second patch applied, this complains about mmap-ing
> /dev/null (or any zero-length file).
>
> Also, \x escapes are sadly not portable (dash, for example, does not
> respect them). You have to use octal instead (which is no
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Git 2.19-rc1 is out. Hopefully th
Jonathan Nieder writes:
> Tim Schumacher wrote:
>
>> Subject: doc: Don't echo sed command for manpage-base-url.xsl
>
> Cribbing from my review of v2: a description like
>
> Documentation/Makefile: make manpage-base-url.xsl generation quieter
>
> would make it more obvious what this does whe
Andreas Gruenbacher writes:
> Some commands like 'log' default to HEAD if no other revisions are
> specified on the command line or otherwise. Unfortunately, excludes
> (^) cancel out that default, so when a command only excludes
> revisions (e.g., 'git log ^origin/master'), the command will not
Thomas Gummerer writes:
> Yeah that makes sense. Maybe something like this?
>
> (replying to here to keep
> the patches in one thread)
>
> Documentation/technical/rerere.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/technical/rerere.txt
> b/Documentation/techn
Eric Sunshine writes:
> This is an extract from v3 of es/chain-lint-more[1] which never got
> picked up. Instead, v2 of that series[2] got merged to 'next' and later
> 'master'. The only change between v2 and v3 was to make 'chainlint' also
> recognize double-quoted here-doc tags. This solo patch
René Scharfe writes:
> Add best-effort support for patches sent using format=flowed (RFC 3676).
> Remove leading spaces ("unstuff"), remove soft line breaks (indicated
> by space + newline), but leave the signature separator (dash dash space
> newline) alone.
>
> Warn in git am when encountering
Ben Peart writes:
> There isn't any change in behavior with unknown extensions and this
> patch. If an unknown extension exists it will just get ignored and
> reported as an "unknown extension" or "die" if it is marked as
> "required."
OK.
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The builtin rebase and the builtin interactive rebase have been
> developed independently, on purpose: Google Summer of Code rules
> specifically state that students have to work on independent projects,
> they cannot
On Wed, Aug 29, 2018 at 08:37:48AM -0400, Derrick Stolee wrote:
> On 8/28/2018 8:56 PM, brian m. carlson wrote:
> > + rawsz="$(test_oid rawsz)" &&
> > + hexsz="$(test_oid hexsz)" &&
>
> These are neat helpers! The 'git commit-graph verify' tests in
> t5318-commit-graph.sh should automatically
On Wed, Aug 29, 2018 at 5:54 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Wed, 29 Aug 2018, Elijah Newren wrote:
>
> > Signed-off-by: Elijah Newren
> > ---
> > merge-recursive.c | 18 +-
> > merge-recursive.h | 1 +
> > 2 files changed, 14 insertions(+), 5 deletions(-)
>
1 - 100 of 124 matches
Mail list logo
