[PATCH] packfile: free packed_git memory when closing object store

Signed-off-by: Mike Hommey --- packfile.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Note, I'm not sure this is the right place to do it. diff --git a/packfile.c b/packfile.c index fc43a6c52c..b0cb84adda 100644 --- a/packfile.c +++ b/packfile.c @@ -339,13 +339,16 @@ void

[PATCH 06/11] hashmap_add takes "struct hashmap_entry *"

This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- attr.c | 2 +- blame.c | 2 +- builtin/describe.c | 2 +- builtin/difftool.c | 6 +++--- builtin/fetch.c | 2 +- config.c

[PATCH 11/11] hashmap_get_next returns "struct hashmap_entry *"

This is a step towards removing the requirement for hashmap_entry being the first field of a struct. Signed-off-by: Eric Wong --- diff.c | 19 --- diffcore-rename.c | 11 +++ hashmap.c | 2 +- hashmap.h | 12

[PATCH 10/11] introduce container_of macro

This macro is popular within the Linux kernel for supporting intrusive data structures such as linked lists, red-black trees, and chained hash tables while allowing the compiler to do type checking. I intend to use this to remove the limitation of "hashmap_entry" being location-dependent and to al

[PATCH 09/11] hashmap_put takes "struct hashmap_entry *"

This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- builtin/fast-export.c | 2 +- hashmap.c | 2 +- hashmap.h | 2 +- merge-recursive.c | 4 ++-- oidmap.c| 2 +- refs.c

[PATCH 07/11] hashmap_get takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- attr.c| 2 +- blame.c | 6 +++--- builtin/difftool.c| 5 +++-- builtin/fast-export.c | 2 +- config.c | 2 +- diff.c

[PATCH 01/11] diff: use hashmap_entry_init on moved_entry.ent

Otherwise, the hashmap_entry.next field appears to remain uninitialized, which can lead to problems when add_lines_to_move_detection calls hashmap_add. I found this through manual inspection when converting hashmap_add callers to take "struct hashmap_entry *". Signed-off-by: Eric Wong --- diff.

[PATCH 00/11] hashmap: bugfixes, safety fixes, and WIP improvements

This started out as yak-shaving exercise to introduce the "container_of" macro to make hashmap more flexible and less error-prone. So far I've ended up finding and fixing two real bugs in patches 1/11 and 2/11 which should be fast-tracked. Patches 3-9 are straightforward safety fixes to prevent f

[PATCH 08/11] hashmap_remove takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- blame.c| 2 +- hashmap.c | 3 ++- hashmap.h | 2 +- merge-recursive.c | 2 +- name-hash.c| 4 ++-- packfile.c | 2 +- r

[PATCH 02/11] packfile: use hashmap_entry in delta_base_cache_entry

This hashmap_entry_init function is intended to take a hashmap_entry struct pointer, not a hashmap struct pointer. This was not noticed because hashmap_entry_init takes a "void *" arg instead of "struct hashmap_entry *", and the hashmap struct is larger and can be cast into a hashmap_entry struct

[PATCH 04/11] hashmap_entry: detect improper initialization

By renaming the "hash" field to "_hash", it's easy to spot improper initialization of hashmap_entry structs which can leave "hashmap_entry.next" uninitialized. Signed-off-by: Eric Wong --- builtin/fast-export.c | 5 +++-- hashmap.c | 9 + hashmap.h

[PATCH 03/11] hashmap_entry_init takes "struct hashmap_entry *"

C compilers do type checking to make life easier for us. So rely on that and update all hashmap_entry_init callers to take "struct hashmap_entry *" to avoid future bugs while improving safety and readability. Signed-off-by: Eric Wong --- attr.c | 4 ++-- blame.c

[PATCH 05/11] hashmap_get_next takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- diff.c | 5 +++-- diffcore-rename.c | 2 +- hashmap.c | 5 +++-- hashmap.h | 3 ++- name-hash.c | 2 +-

[PATCH] commit: free the right buffer in release_commit_memory

The index field in the commit object is used to find the buffer corresponding to that commit in the buffer_slab. Resetting it first means free_commit_buffer is not going to free the right buffer. Signed-off-by: Mike Hommey --- commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH] notes: avoid leaking duplicate entries

On Sun, Aug 25, 2019 at 02:18:18PM +0900, Mike Hommey wrote: > When add_note is called multiple times with the same key/value pair, the > leaf_node it creates is leaked by notes_tree_insert. For completeness, since I realized it was missing: Signed-off-by: Mike Hommey Mike

[PATCH v2 12/14] t4000: make hash size independent

Use $ZERO_OID instead of hard-coding a fixed size all-zeros object ID. Signed-off-by: brian m. carlson --- t/t4000-diff-format.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t4000-diff-format.sh b/t/t4000-diff-format.sh index 8de36b7d12..e5116a76a1 100755 --- a/t/t4000-

[PATCH v2 10/14] t3800: make hash-size independent

Replace references to several hard-coded object IDs with a variable referring to the generated commit. Avoid matching on exact character positions, which will be different depending on the hash in use. In the test for a valid object ID, use an obviously invalid one from the lookup table. Signed-

[PATCH v2 07/14] t3430: avoid hard-coded object IDs

Compute the object IDs used in the todo list instead of hard-coding them. Signed-off-by: brian m. carlson --- t/t3430-rebase-merges.sh | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh index 7b6c4847ad

[PATCH v2 09/14] t3600: make hash size independent

Instead of hard-coding a fixed length invalid object ID in the test, compute one using the lookup tables. Signed-off-by: brian m. carlson --- t/t3600-rm.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 66282a720e..8c8cca5bfb 100755 ---

[PATCH v2 14/14] t4009: make hash size independent

Instead of hard-coding object IDs, compute them and use those in the comparison. Note that the comparison code ignores the actual object IDs, but does check that they're the right size, so computing them is the easiest way to ensure that they are. Signed-off-by: brian m. carlson --- t/t4009-dif

[PATCH v2 11/14] t3903: abstract away SHA-1-specific constants

Abstract away the SHA-1-specific constants by sanitizing diff output to remove the index lines, since it's clear from the assertions in question that we are not interested in the specific object IDs. Signed-off-by: brian m. carlson --- t/t3903-stash.sh | 32 ++-- 1 fi

[PATCH v2 05/14] t3306: abstract away SHA-1-specific constants

Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. Convert some single-line heredocs into inline uses of echo now that they can be expressed succinctly. Signed-off-by: brian m. carlson --- t/t3306-notes-prune.sh | 45

[PATCH v2 04/14] t3305: make hash size independent

Instead of hard-coding 40-character shell patterns, use grep to determine if all of the paths have either zero or one levels of fanout, as appropriate. Note that the final test is implicitly dependent on the hash algorithm. Depending on the algorithm in use, the fanout may or may not completely co

[PATCH v2 00/14] Hash-independent tests, part 5

This is the fifth series of test fixes for SHA-256 compatibility. It consists of 15 patches fixing various tests from t3201 through t4009 and has only test fixes: no test helper changes are included. Changes from v1: * Add sanity-checking to the sed invocation. * Remove whitespace between redirec

[PATCH v2 03/14] t3301: abstract away SHA-1-specific constants

Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. Move some invocations of test_commit around so that we can compute the object IDs for these commits. Compute several object IDs in the tests instead of using hard-coded values so that the test works w

[PATCH v2 06/14] t3404: abstract away SHA-1-specific constants

Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. Add a use of $EMPTY_TREE instead of a hard-coded value. Remove a comment about hard-coded hashes which is no longer applicable. Signed-off-by: brian m. carlson --- t/t3404-rebase-interactive.sh | 2

[PATCH v2 13/14] t4002: make hash independent

Factor out the hard-coded object IDs and use test_oid to provide values for both SHA-1 and SHA-256. Signed-off-by: brian m. carlson --- t/t4002-diff-basic.sh | 367 +- 1 file changed, 258 insertions(+), 109 deletions(-) diff --git a/t/t4002-diff-basic.sh

[PATCH v2 01/14] t3201: abstract away SHA-1-specific constants

Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. Signed-off-by: brian m. carlson --- t/t3201-branch-contains.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t3201-branch-contains.sh b/t/t3201-branch-contains.sh inde

[PATCH v2 08/14] t3506: make hash independent

This test uses a hard-coded object ID to ensure that the result of cherry-pick --ff is correct. Use test_oid to make this work for both SHA-1 and SHA-256. Signed-off-by: brian m. carlson --- t/t3506-cherry-pick-ff.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/t/

[PATCH v2 02/14] t3206: abstract away hash size constants

The various short object IDs in the range-diff output differ between hash algorithms. Use test_oid_cache to look up values for both SHA-1 and SHA-256. Signed-off-by: brian m. carlson --- t/t3206-range-diff.sh | 227 +++--- 1 file changed, 167 insertions(+), 6

Re: [PATCH 08/13] t4014: let sed open its own files

On Sat, Aug 24, 2019 at 4:27 AM Denton Liu wrote: > In some cases, we were using a redirection operator to feed input into > sed. However, since sed is capable of opening its own files and provides > better error messages on IO failure, make sed open its own files instead > of redirecting input in

[PATCH v5 2/2] am: reload .gitattributes after patching it

When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes applied, the file will be written out with the attribute

[PATCH v5 1/2] path: add a function to check for path suffix

We have a function to strip the path suffix from a commit, but we don't have one to check for a path suffix. For a plain filename, we can use basename, but that requires an allocation, since POSIX allows it to modify its argument. Refactor strip_path_suffix into a helper function and a new function

[PATCH v5 0/2] Honor .gitattributes with rebase --am

This series makes rebase --am honor the .gitattributes file for subsequent patches when a patch changes it. Note that there are two places we load attributes in ll-merge.c, but this code only handles the one that git am uses. The two cannot be unified because the one in ll_merge_marker_size inten

Re: [PATCH v9 9/9] rebase: teach rebase --keep-base

On 25/08/2019 10:12, Denton Liu wrote: A common scenario is if a user is working on a topic branch and they wish to make some changes to intermediate commits or autosquash, they would run something such as git rebase -i --onto master... master in order to preserve the merge base. This i

Re: [Feature Request] Option to make .git not read-only in cloned repos

On 25/08/2019 20:58, Albert Vaca Cintora wrote: On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote: Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: However, I'm sure that a large percentage of developers out there will agree with me that having to use force (-f) to delete every cloned repo

Re: [PATCH] t7300-clean: demonstrate deleting nested repo with an ignored file breakage

Hi Szeder, On 25/08/2019 19:59, SZEDER Gábor wrote: 'git clean -fd' must not delete an untracked directory if it belongs s/untracked// I don't believe it should matter either way for a sub-module (sub-directory). to a different Git repository or worktree. msybr split the assertion from the f

Re: [PATCH v2 20/23] .gitignore: touch up the entries regarding Visual Studio

Hi Szeder, On 25/08/2019 20:09, SZEDER Gábor wrote: On Sun, Aug 25, 2019 at 02:20:32PM +0100, Philip Oakley wrote: Hi Szeder, On 25/08/2019 13:07, SZEDER Gábor wrote: On Mon, Jul 29, 2019 at 01:08:14PM -0700, Philip Oakley via GitGitGadget wrote: Add the Microsoft .manifest pattern, and do n

Re: [PATCH] git-gui: Update in-memory config when changing config options

Junio, This patch hasn't got any comments, but it looks correct to me, and fit for merging IMO. I updated the commit subject from 'git-gui: Update...' to 'git-gui: update...' to match with the style of other commit messages, as you suggested in the other series. You can pull the updated commi

Re: [PATCH] t7300-clean: demonstrate deleting nested repo with an ignored file breakage

On Sun, Aug 25, 2019 at 08:59:18PM +0200, SZEDER Gábor wrote: > 'git clean -fd' must not delete an untracked directory if it belongs > to a different Git repository or worktree. Unfortunately, if a > '.gitignore' rule in the outer repository happens to match a file in a > nested repository or work

Re: [Feature Request] Option to make .git not read-only in cloned repos

On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote: > > Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: > > However, I'm sure that a large percentage of developers out there will > > agree with me that having to use force (-f) to delete every cloned > > repo is annoying, and even worse, it crea

[PATCH] banned.h: fix vsprintf()'s ban message

In cc8fdaee1e (banned.h: mark sprintf() as banned, 2018-07-24), both 'sprintf()' and 'vsprintf()' were marked as banned functions. The non-variadic macro to ban 'vsprintf' has a typo which says that 'sprintf', not 'vsprintf' is banned. The variadic version does not have the same typo. Fix this by

Re: [PATCH v2 20/23] .gitignore: touch up the entries regarding Visual Studio

On Sun, Aug 25, 2019 at 02:20:32PM +0100, Philip Oakley wrote: > Hi Szeder, > > On 25/08/2019 13:07, SZEDER Gábor wrote: > >On Mon, Jul 29, 2019 at 01:08:14PM -0700, Philip Oakley via GitGitGadget > >wrote: > >>Add the Microsoft .manifest pattern, and do not anchor the 'Debug' > >>and 'Release' e

[PATCH] t7300-clean: demonstrate deleting nested repo with an ignored file breakage

'git clean -fd' must not delete an untracked directory if it belongs to a different Git repository or worktree. Unfortunately, if a '.gitignore' rule in the outer repository happens to match a file in a nested repository or worktree, then something goes awry and 'git clean -fd' does delete the con

[PATCH 0/2] PCRE1 cleanup

This is a reroll of [1] which is mostly equivalent to the original RFC but rebased on top of ab/pcre-jit-fixes. The first patch fixes an inconsistency from 685668faaa (grep: stop using a custom JIT stack with PCRE v1, 2019-07-26) where NO_LIBPCRE1_JIT will only affect versions of pcre1 >= 8.32, wh

[PATCH 1/2] grep: make sure NO_LIBPCRE1_JIT disable JIT in PCRE1

e87de7cab4 ("grep: un-break building with PCRE < 8.32", 2017-05-25) added a restriction for JIT support that is no longer needed after pcre_jit_exec() calls were removed. Reorganize the definitions in grep.h so that JIT support could be detected early and NO_LIBPCRE1_JIT could be used reliably to

[PATCH 2/2] grep: refactor and simplify PCRE1 support

The code used both a macro and a variable to keep track if JIT support was desired and relied on the fact that a non JIT enabled library will ignore a request for JIT compilation (as defined by the second parameter of the call to pcre_study) Cleanup the multiple levels of macros used and call pcre

Re: [Feature Request] Option to make .git not read-only in cloned repos

Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: > However, I'm sure that a large percentage of developers out there will > agree with me that having to use force (-f) to delete every cloned > repo is annoying, and even worse, it creates the bad habit of always > force-deleting everything. IMO, t

[PATCH] trace2: use warning() directly in tr2_dst_malformed_warning()

Let warning() format the message instead of using an intermediate strbuf for that. This is shorter, easier to read and avoids an allocation. Signed-off-by: René Scharfe --- trace2/tr2_dst.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/trace2/tr2_dst.c b/trace2/tr

Re: [Feature Request] Option to make .git not read-only in cloned repos

On Sun, Aug 25, 2019 at 1:59 PM Kevin Daudt wrote: > > On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote: > > Hi git folks, > > > > Honestly I'm not aware of the reason behind .git being read-only, but > > I'm sure there is one. > > > > However, I'm sure that a large percentage o

Re: [PATCH 2/2] fast-import: duplicate into history rather than passing ownership

Am 25.08.19 um 12:02 schrieb Mike Hommey: > On Sun, Aug 25, 2019 at 04:10:55AM -0400, Jeff King wrote: >> diff --git a/fast-import.c b/fast-import.c >> index ee7258037a..1f9160b645 100644 >> --- a/fast-import.c >> +++ b/fast-import.c >> @@ -1763,7 +1763,6 @@ static int read_next_command(void) >>

[PATCH] grep: use return value of strbuf_detach()

Append the strbuf buffer only after detaching it. There is no practical difference here, as the strbuf is not empty and no strbuf_ function is called between storing the pointer to the still attached buffer and calling strbuf_detach(), so that pointer is valid, but make sure to follow the standard

Re: [PATCH v2 20/23] .gitignore: touch up the entries regarding Visual Studio

Hi Szeder, On 25/08/2019 13:07, SZEDER Gábor wrote: On Mon, Jul 29, 2019 at 01:08:14PM -0700, Philip Oakley via GitGitGadget wrote: Add the Microsoft .manifest pattern, and do not anchor the 'Debug' and 'Release' entries at the top-level directory, to allow for multiple projects (one per target

Re: [PATCH v9 5/9] rebase: refactor can_fast_forward into goto tower

On 25/08/19 05:12AM, Denton Liu wrote: > Before, can_fast_forward was written with an if-else statement. However, > in the future, we may be adding more termination cases which would lead > to deeply nested if statements. > > Refactor to use a goto tower so that future cases can be easily > insert

[PATCH] log-tree: always use return value of strbuf_detach()

strbuf_detach() has been returning a pointer to a buffer even for empty strbufs since 08ad56f3f0 ("strbuf: always return a non-NULL value from strbuf_detach", 2012-10-18). Use that feature in show_log() instead of having it handle empty strbufs specially. Signed-off-by: René Scharfe --- The patc

Re: [PATCH] fast-import: Reinitialize command_buf rather than detach it.

Am 25.08.19 um 06:13 schrieb Mike Hommey: > command_buf.buf is also stored in cmd_hist, so instead of > strbuf_release, the current code uses strbuf_detach in order to > "leak" the buffer as far as the strbuf is concerned. Hmm. > However, strbuf_detach does more than "leak" the strbuf buffer: it

Re: [Feature Request] Option to make .git not read-only in cloned repos

On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote: > Hi git folks, > > Honestly I'm not aware of the reason behind .git being read-only, but > I'm sure there is one. > > However, I'm sure that a large percentage of developers out there will > agree with me that having to use for

Re: [PATCH v2 20/23] .gitignore: touch up the entries regarding Visual Studio

On Mon, Jul 29, 2019 at 01:08:14PM -0700, Philip Oakley via GitGitGadget wrote: > Add the Microsoft .manifest pattern, and do not anchor the 'Debug' > and 'Release' entries at the top-level directory, to allow for > multiple projects (one per target). > > Signed-off-by: Philip Oakley > Signed-off

Re: [PATCH v2 0/4] git-gui: Add ability to revert selected hunks and lines

On 23/08/19 11:12PM, Bert Wesarg wrote: > On Fri, Aug 23, 2019, 18:44 Pratyush Yadav wrote: > > > On 23/08/19 08:04AM, Bert Wesarg wrote: > > > On Fri, Aug 23, 2019 at 12:51 AM Pratyush Yadav > > wrote: > > > > > > > > On 22/08/19 03:34PM, Junio C Hamano wrote: > > [...] > > > as I'm the one who

Re: [PATCH 2/2] fast-import: duplicate into history rather than passing ownership

On Sun, Aug 25, 2019 at 04:10:55AM -0400, Jeff King wrote: > Fast-import's read_next_command() has somewhat odd memory ownership > semantics for the command_buf strbuf. After reading a command, we copy > the strbuf's pointer (without duplicating the string) into our cmd_hist > array of recent comma

[PATCH v9 8/9] rebase tests: test linear branch topology

From: Ævar Arnfjörð Bjarmason Add tests rebasing a linear branch topology to linear rebase tests added in 2aad7cace2 ("add simple tests of consistency across rebase types", 2013-06-06). These tests are duplicates of two surrounding tests that do the same with tags pointing to the same objects. R

[PATCH v9 9/9] rebase: teach rebase --keep-base

A common scenario is if a user is working on a topic branch and they wish to make some changes to intermediate commits or autosquash, they would run something such as git rebase -i --onto master... master in order to preserve the merge base. This is useful when contributing a patch series

[PATCH v9 7/9] rebase: fast-forward --fork-point in more cases

Before, when we rebased with a --fork-point invocation where the fork-point wasn't empty, we would be setting options.restrict_revision. The fast-forward logic would automatically declare that the rebase was not fast-forwardable if it was set. However, this was painting with a very broad brush. Re

[PATCH v9 3/9] t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests

From: Ævar Arnfjörð Bjarmason Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a

[PATCH v9 6/9] rebase: fast-forward --onto in more cases

Before, when we had the following graph, A---B---C (master) \ D (side) running 'git rebase --onto master... master side' would result in D being always rebased, no matter what. However, the desired behavior is that rebase should notice that this is fast-forwarda

[PATCH v9 2/9] t3432: test rebase fast-forward behavior

When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full

[PATCH v9 0/9] rebase: learn --keep-base and improvements on fast-forward behaviour

Hi all, it's been a while but I guess now's a good time as any to resurrect this topic. This is basically a resubmission of Ævar's WIP v8 but I fixed a couple of minor whitespace issues. In addition, I opted to drop patches 9-13 from v8 since I don't think I can do a good enough job polishing them

[PATCH v9 1/9] t3431: add rebase --fork-point tests

Signed-off-by: Denton Liu --- t/t3431-rebase-fork-point.sh | 53 1 file changed, 53 insertions(+) create mode 100755 t/t3431-rebase-fork-point.sh diff --git a/t/t3431-rebase-fork-point.sh b/t/t3431-rebase-fork-point.sh new file mode 100755 index 00..

[PATCH v9 4/9] t3432: test for --no-ff's interaction with fast-forward

From: Ævar Arnfjörð Bjarmason Add more stress tests for the can_fast_forward() case in rebase.c. These tests are getting rather verbose, but now we can see under --ff and --no-ff whether we skip work, or whether we're forced to run the rebase. These tests aren't supposed to endorse the status qu

[PATCH v9 5/9] rebase: refactor can_fast_forward into goto tower

Before, can_fast_forward was written with an if-else statement. However, in the future, we may be adding more termination cases which would lead to deeply nested if statements. Refactor to use a goto tower so that future cases can be easily inserted. Signed-off-by: Denton Liu --- builtin/rebase

[PATCH 2/2] fast-import: duplicate into history rather than passing ownership

Fast-import's read_next_command() has somewhat odd memory ownership semantics for the command_buf strbuf. After reading a command, we copy the strbuf's pointer (without duplicating the string) into our cmd_hist array of recent commands. And then when we're about to read a new command, we clear the

Re: [BUG] You can't have single quote in your username

On Sat, Aug 24, 2019 at 05:49:52PM +, Giuseppe Crinò wrote: > On Fri, Aug 23, 2019 at 10:29:00AM +0200, SZEDER Gábor wrote: > > What I wonder is whether we really have to remove crud from the user > > name if it comes from the configuration. > > Yes. If the primary use of removing crud is to r

[PATCH 1/2] fast-import: duplicate parsed encoding string

We read each line of the fast-import stream into the command_buf strbuf. When reading a commit, we parse a line like "encoding foo" by storing a pointer to "foo", but not making a copy. We may then read an unbounded number of other lines (e.g., one for each modified file in the commit), each of whi

[PATCH 0/2] fast-import input string handling bugs

On Sun, Aug 25, 2019 at 02:57:48AM -0400, Jeff King wrote: > And I think this is actually a real bug in the current code! We keep a > pointer to the encoding string, which survives because of the history. > But that history is bounded, and we could have an indefinite number of > changed files in t

Re: [PATCH] fix segv with corrupt tag object

Am 25.08.19 um 01:09 schrieb Stefan Sperling: > A tag object which lacks newlines won't be parsed correctly. > Git fails to detect this error and crashes due to a NULL deref: > > $ git archive 1.0.0 > Segmentation fault (core dumped) > $ git checkout 1.0.0 > Segmentation fault (core dumped) > $ Go

Re: [PATCH] fast-import: Reinitialize command_buf rather than detach it.

On Sun, Aug 25, 2019 at 04:20:31PM +0900, Mike Hommey wrote: > > I think this is stronger than just "most of the time". It's an invariant > > for strbufs to have a NUL, so the only case where detaching isn't a noop > > is the empty slopbuf case you mention. > > If it's an invariant, why does deta

Re: [PATCH] fast-import: Reinitialize command_buf rather than detach it.

On Sun, Aug 25, 2019 at 02:57:48AM -0400, Jeff King wrote: > On Sun, Aug 25, 2019 at 01:13:48PM +0900, Mike Hommey wrote: > > > command_buf.buf is also stored in cmd_hist, so instead of > > strbuf_release, the current code uses strbuf_detach in order to > > "leak" the buffer as far as the strbuf i

[PATCH] notes: avoid potential use-after-free during insertion

On Sun, Aug 25, 2019 at 03:10:35AM -0400, Jeff King wrote: > Curiously, I think the existing case a few lines below your patch is > wrong, though: > > ret = combine_notes(&l->val_oid, > &entry->val_oid); > if (!ret && is_null_oid(&l->val_oid)) >

Re: [PATCH] notes: avoid leaking duplicate entries

On Sun, Aug 25, 2019 at 02:18:18PM +0900, Mike Hommey wrote: > When add_note is called multiple times with the same key/value pair, the > leaf_node it creates is leaked by notes_tree_insert. Makes sense. > diff --git a/notes.c b/notes.c > index 75c028b300..ec35f5b551 100644 > --- a/notes.c > +++