[PATCH v2 10/37] help: rename 'new' variables

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- builtin/help.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/help.c b/builtin/help.c index

[PATCH v2 11/37] pack-redundant: rename 'new' variables

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- builtin/pack-redundant.c | 54 1 file changed, 27 insertions(+), 27 deletions(-) diff --git

[PATCH v2 12/37] reflog: rename 'new' variables

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- builtin/reflog.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/reflog.c b/builtin/reflog.c

[PATCH v2 03/37] blame: rename 'this' variables

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- blame.c | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/blame.c b/blame.c

[PATCH v2 05/37] rev-parse: rename 'this' variable

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- builtin/rev-parse.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git

[PATCH v2 02/37] object: rename function 'typename' to 'type_name'

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- builtin/cat-file.c | 2 +- builtin/diff-tree.c| 2 +- builtin/fast-export.c

[PATCH v2 04/37] pack-objects: rename 'this' variables

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- builtin/pack-objects.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/pack-objects.c

[PATCH v2 01/37] object_info: change member name from 'typename' to 'type_name'

Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams --- builtin/cat-file.c | 2 +- cache.h| 2 +- packfile.c | 6 +++--- sha1_file.c| 10 +- 4 files

[PATCH v2 00/37] removal of some c++ keywords

One person was interested enough for me to go back through and also rename all the paired 'old' variables to match the new names for the variables which were named 'new'. Brandon Williams (37): object_info: change member name from 'typename' to 'type_name' object: rename function 'typename'

[PATCH v8 25/29] merge-recursive: fix overwriting dirty files involved in renames

This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a

[PATCH v8 28/29] merge-recursive: avoid spurious rename/rename conflict from dir renames

If a file on one side of history was renamed, and merely modified on the other side, then applying a directory rename to the modified side gives us a rename/rename(1to2) conflict. We should only apply directory renames to pairs representing either adds or renames. Making this change means that a

[PATCH v8 21/29] merge-recursive: check for file level conflicts then get new name

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the file level either. If there aren't any, then get the new name from any directory renames. Reviewed-by: Stefan Beller Signed-off-by: Elijah

[PATCH v8 10/29] directory rename detection: tests for handling overwriting untracked files

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 367 1 file changed, 367 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 24/29] merge-recursive: avoid clobbering untracked files with directory renames

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- merge-recursive.c | 42 +++-- t/t6043-merge-rename-directories.sh | 6 +++--- 2 files changed, 43 insertions(+), 5 deletions(-) diff --git

[PATCH v8 08/29] directory rename detection: testcases exploring possibly suboptimal merges

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 404 1 file changed, 404 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 27/29] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier patch series, but

[PATCH v8 14/29] merge-recursive: fix leaks of allocated renames and diff_filepairs

get_renames() has always zero'ed out diff_queued_diff.nr while only manually free'ing diff_filepairs that did not correspond to renames. Further, it allocated struct renames that were tucked away in the return string_list. Make sure all of these are deallocated when we are done with them.

[PATCH v8 20/29] merge-recursive: add computation of collisions due to dir rename & merging

directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths.

[PATCH v8 23/29] merge-recursive: apply necessary modifications for directory renames

This commit hooks together all the directory rename logic by making the necessary changes to the rename struct, it's dst_entry, and the diff_filepair under consideration. Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- merge-recursive.c

[PATCH v8 07/29] directory rename detection: more involved edge/corner testcases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 396 1 file changed, 396 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 13/29] merge-recursive: introduce new functions to handle rename logic

The amount of logic in merge_trees() relative to renames was just a few lines, but split it out into new handle_renames() and cleanup_renames() functions to prepare for additional logic to be added to each. No code or logic changes, just a new place to put stuff for when the rename detection

[PATCH v8 03/29] directory rename detection: testcases to avoid taking detection too far

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 153 1 file changed, 153 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 29/29] merge-recursive: ensure we write updates for directory-renamed file

When a file is present in HEAD before the merge and the other side of the merge does not modify that file, we try to avoid re-writing the file and making it stat-dirty. However, when a file is present in HEAD before the merge and was in a directory that was renamed by the other side of the merge,

[PATCH v8 22/29] merge-recursive: when comparing files, don't include trees

get_renames() would look up stage data that already existed (populated in get_unmerged(), taken from whatever unpack_trees() created), and if it didn't exist, would call insert_stage_data() to create the necessary entry for the given file. The insert_stage_data() fallback becomes much more

[PATCH v8 06/29] directory rename detection: testcases checking which side did the rename

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 336 1 file changed, 336 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 09/29] directory rename detection: miscellaneous testcases to complete coverage

I came up with the testcases in the first eight sections before coding up the implementation. The testcases in this section were mostly ones I thought of while coding/debugging, and which I was too lazy to insert into the previous sections because I didn't want to re-label with all the testcase

[PATCH v8 04/29] directory rename detection: partially renamed directory testcase/discussion

Add a long note about why we are not considering "partial directory renames" for the current directory rename detection implementation. Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 115

[PATCH v8 15/29] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Reviewed-by: Stefan Beller Signed-off-by:

[PATCH v8 12/29] merge-recursive: move the get_renames() function

Move this function so it can re-use some others (without either moving all of them or adding an annoying split between function declarations and definitions). Cheat slightly by adding a blank line for readability, and in order to silence checkpatch.pl. Reviewed-by: Stefan Beller

[PATCH v8 16/29] merge-recursive: split out code for determining diff_filepairs

Create a new function, get_diffpairs() to compute the diff_filepairs between two trees. While these are currently only used in get_renames(), I want them to be available to some new functions. No actual logic changes yet. Reviewed-by: Stefan Beller Signed-off-by: Elijah

[PATCH v8 11/29] directory rename detection: tests for handling overwriting dirty files

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 458 1 file changed, 458 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 01/29] directory rename detection: basic testcases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 442 1 file changed, 442 insertions(+) create mode 100755 t/t6043-merge-rename-directories.sh diff --git

[PATCH v8 05/29] directory rename detection: files/directories in the way of some renames

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 330 1 file changed, 330 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 18/29] merge-recursive: add get_directory_renames()

This populates a set of directory renames for us. The set of directory renames is not yet used, but will be in subsequent commits. Note that the use of a string_list for possible_new_dirs in the new dir_rename_entry struct implies an O(n^2) algorithm; however, in practice I expect the number of

[PATCH v8 26/29] merge-recursive: fix remaining directory rename + dirty overwrite cases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- merge-recursive.c | 25 ++--- t/t6043-merge-rename-directories.sh | 8 2 files changed, 26 insertions(+), 7 deletions(-) diff --git

[PATCH v8 19/29] merge-recursive: check for directory level conflicts

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the directory level. There will be additional checks at the individual file level too, which will be added later. Reviewed-by: Stefan Beller

[PATCH v8 00/29] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive. See https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ for the first series (including design considerations, etc.) This series continues to depend on en/merge-recursive-fixes in next, at least

[PATCH v8 02/29] directory rename detection: directory splitting testcases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 143 1 file changed, 143 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v8 17/29] merge-recursive: make a helper function for cleanup for handle_renames

In anticipation of more involved cleanup to come, make a helper function for doing the cleanup at the end of handle_renames. Rename the already existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new helper initial_cleanup_rename(), and leave the big comment in the code about why

Re: [PATCH 0/6] minor test-hashmap fixes

On Wed, Feb 14, 2018 at 10:41:35AM -0800, Stefan Beller wrote: > I have lost track of the hashmap improvements lately, but with > such a good test helper, we could reduce the amount of > commented code in hashmap.h and just link to the test helper? > (as an extra step after this series, I thought

Re: [PATCH 1/6] test-hashmap: use ALLOC_ARRAY rather than bare malloc

Jeff, Thanks for the feedback! Most of our users find CodeAI's fixes useful, even if they are not exactly correct. However, we are constantly working on improving the quality of CodeAI's fixes. The more people who use it, the more we can improve it. We would love for you to try the system

Re: [PATCH 0/6] minor test-hashmap fixes

On Wed, Feb 14, 2018 at 10:03 AM, Jeff King wrote: > This series started with me fixing the sizeof() mismatch discussed in > > https://public-inbox.org/git/20180214164628.ga...@sigill.intra.peff.net/ > > but I found a number of minor irritations. Most of them are cosmetic in >

"git add" with several pathspecS and one doesn't match

Hi All, I am facing this issue: I am ADDing some file with several pathspec, and one of these fails. The results is that no file is added at all. Simple test case: $ git init . $ touch 123.txt $ git add "*.txt" "*.doc" fatal: pathspec '*.doc' did not match any files $ git status [...]

Re: [PATCH v3 00/14] Serialized Git Commit Graph

On Wed, Feb 14, 2018 at 10:15 AM, Derrick Stolee wrote: > There has been a lot of interesting discussion on this topic. Some of that > involves some decently significant changes from v3, so I wanted to summarize > my understanding of the feedback and seek out more feedback from

Re: [PATCH v1] fsmonitor: update documentation to remove reference to invalid config settings

Ben Peart writes: > Remove the reference to setting core.fsmonitor to `true` (or `false`) as those > are not valid settings. > > Signed-off-by: Ben Peart > --- Thanks. It is a bit embarrassing that nobody caught it for this long. Will apply. >

Re: [PATCH 1/2] parse-options: expand $HOME on filename options

Jeff King writes: >> Support $HOME expansion for all filename options. There are about seven >> of them. > > I think this probably makes sense. > >> parse-options.c | 9 ++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) > > Should this be mentioned in the comment

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

On Wed, Feb 14, 2018 at 10:11 AM, Brandon Williams wrote: > On 02/13, Junio C Hamano wrote: >> >> * bw/c-plus-plus (2018-01-30) 37 commits >> - replace: rename 'new' variables >> - trailer: rename 'template' variables >> - tempfile: rename 'template' variables >> - wrapper:

Re: [PATCH v3 00/14] Serialized Git Commit Graph

There has been a lot of interesting discussion on this topic. Some of that involves some decently significant changes from v3, so I wanted to summarize my understanding of the feedback and seek out more feedback from reviewers before rolling v4. If we have consensus on these topics, then I'll

Re: linux-next: unnecessary merge in the v4l-dvb tree

Linus Torvalds writes: > On Tue, Feb 13, 2018 at 9:18 AM, Junio C Hamano wrote: >> >> That makes me wonder if another heuristic I floated earlier is more >> appropriate. When merging a tag object T, if refs/tags/T exists and >> it is that tag

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

On 02/13, Junio C Hamano wrote: > > * bw/c-plus-plus (2018-01-30) 37 commits > - replace: rename 'new' variables > - trailer: rename 'template' variables > - tempfile: rename 'template' variables > - wrapper: rename 'template' variables > - environment: rename 'namespace' variables > -

Re: [PATCH v3 11/14] commit: integrate commit graph with commit parsing

On 2/13/2018 7:12 PM, Jonathan Tan wrote: On Thu, 8 Feb 2018 15:37:35 -0500 Derrick Stolee wrote: | Command | Before | After | Rel % | |--|||---| | log --oneline --topo-order -1000 | 5.9s |

[PATCH 6/6] test-hashmap: use "unsigned int" for hash storage

The hashmap API always use an unsigned value for storing and comparing hashes. Whereas this test code uses "int". This works out in practice since one can typically round-trip between "int" and "unsigned int". But since this is essentially reference code for the hashmap API, we should model using

[PATCH 5/6] test-hashmap: simplify alloc_test_entry

This function takes two ptr/len pairs, which implies that they can be arbitrary buffers. But internally, it assumes that each "ptr" is NUL-terminated at "len" (because we memcpy an extra byte to pick up the NUL terminator). In practice this works because each caller only ever passes strlen(ptr)

Re: [PATCH 14/26] sha1_file: allow prepare_alt_odb to handle arbitrary repositories

On 02/14, Duy Nguyen wrote: > On Tue, Feb 13, 2018 at 8:22 AM, Stefan Beller wrote: > > Signed-off-by: Stefan Beller > > --- > > object-store.h | 3 +-- > > sha1_file.c| 21 +++-- > > 2 files changed, 12 insertions(+), 12 deletions(-)

[PATCH 3/6] test-hashmap: use xsnprintf rather than snprintf

In general, using a bare snprintf can truncate the resulting buffer, leading to confusing results. In this case we know that our buffer is sized large enough to accommodate our loop, so there's no bug. However, we should use xsnprintf() to document (and check) that assumption, and to model good

[PATCH 4/6] test-hashmap: use strbuf_getline rather than fgets

Using fgets() with a fixed-size buffer can lead to lines being accidentally split across two calls if they are larger than the buffer size. As this is just a test helper, this is unlikely to be a problem in practice. But since people may look at test helpers as reference code, it's a good idea

[PATCH 2/6] test-hashmap: check allocation computation for overflow

When we allocate the test_entry flex-struct, we have to add up all of the elements that go into the flex array. If these were to overflow a size_t, this would allocate a too-small buffer, which we would then overflow in our memcpy steps. Since this is just a test-helper, it probably doesn't

[PATCH 1/6] test-hashmap: use ALLOC_ARRAY rather than bare malloc

These two array allocations have several minor flaws: - they use bare malloc, rather than our error-checking xmalloc - they do a bare multiplication to determine the total size (which in theory can overflow, though in this case the sizes are all constants) - they use

[PATCH 0/6] minor test-hashmap fixes

This series started with me fixing the sizeof() mismatch discussed in https://public-inbox.org/git/20180214164628.ga...@sigill.intra.peff.net/ but I found a number of minor irritations. Most of them are cosmetic in practice, but I think it's important for test-helper code like this to model

Re: [PATCH] color.h: document and modernize header

On Tue, Feb 13, 2018 at 11:23 PM, Eric Sunshine wrote: > On Mon, Feb 12, 2018 at 10:55 PM, Eric Sunshine > wrote: >> On Mon, Feb 12, 2018 at 8:41 PM, Stefan Beller wrote: >>> + * Output the formatted string in the specified

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

On 2/14/2018 12:23 PM, Junio C Hamano wrote: Derrick Stolee writes: There have been a few "What's cooking" emails since I submitted v1 of "Serialized Git Commit Graph" and it has not appeared with a tracking branch. Is this a mistake, or is it something about the state of

Re: [PATCH 3/7] worktree move: new command

Duy Nguyen writes: > On Wed, Feb 14, 2018 at 10:16 AM, Jeff King wrote: >> Hmm. That is not too bad, but somehow it feels funny to me to be >> polluting each test script with these annotations. And to be driving it >> from inside the test scripts. >> >> It

Re: Bug? Error during commit

Jeff King writes: > Here's the patch to make "show -B --stat" work. I'll give some more > thought to whether this is a good idea and prepare a series. > > One downside is that in the common case it causes us to look up each > object twice (once to get its size, and then again to

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

Derrick Stolee writes: > There have been a few "What's cooking" emails since I submitted v1 of > "Serialized Git Commit Graph" and it has not appeared with a tracking > branch. Is this a mistake, or is it something about the state of the > review? The latter. Once I pick up a

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

Duy Nguyen writes: >> Will see another reroll. >> cf.

Re: [PATCH] CodeAI fixes 1 Allocator sizeof() operand mismatch, 2 Null Pointer Dereference, and 2 Dead Code

On Wed, Feb 14, 2018 at 10:50:12AM -0500, Code AI wrote: > Hi my name is Benjamin Bales. > > I am the founder and creator of CodeAI, > the first non-human contributor to your software project. CodeAI finds > and fixes security defects for you. It fixed 18. It wants to merge 5 > commits - 1

[PATCH] CodeAI fixes 1 Allocator sizeof() operand mismatch, 2 Null Pointer Dereference, and 2 Dead Code

Hi my name is Benjamin Bales. I am the founder and creator of CodeAI, the first non-human contributor to your software project. CodeAI finds and fixes security defects for you. It fixed 18. It wants to merge 5 commits - 1 Allocator sizeof() operand mismatch, 2 Null Pointer Dereference issues and

[PATCH v1] fsmonitor: update documentation to remove reference to invalid config settings

Remove the reference to setting core.fsmonitor to `true` (or `false`) as those are not valid settings. Signed-off-by: Ben Peart --- Notes: Base Ref: master Web-Diff: https://github.com/benpeart/git/commit/4b7ec2c11e Checkout: git fetch

Re: [PATCH v3 04/42] git-completion.bash: introduce __gitcomp_builtin

Thanks for working on this. I anticipated that the completion script lack some options, but wow, I didn't expect that there are so many missing. On Fri, Feb 9, 2018 at 12:01 PM, Nguyễn Thái Ngọc Duy wrote: > This is a __gitcomp wrapper that will execute > > git ...

Re: [PATCH v3 29/42] completion: use __gitcomp_builtin in _git_notes

On Fri, Feb 9, 2018 at 12:02 PM, Nguyễn Thái Ngọc Duy wrote: > diff --git a/contrib/completion/git-completion.bash > b/contrib/completion/git-completion.bash > index c7b8b37f19..60127daebf 100644 > --- a/contrib/completion/git-completion.bash > +++

Re: [PATCH v2 1/3] send-email: add and use a local copy of Mail::Address

On Fri, Jan 5, 2018 at 7:36 PM, Matthieu Moy wrote: > create mode 100644 perl/Git/FromCPAN/Mail/Address.pm > create mode 100755 perl/Git/Mail/Address.pm I didn't notice this in my initial review, but just now when it's landed in master and it's shiny-green in my

RE: git-bashe.exe fails to launch

This appears to be covered by https://github.com/git-for-windows/git/issues/1473. In particular, avih's comment about git-bash working without a .minttyrc file applies to me. Apologize for the noise; should have fully reading bug reporting instructions. -Original Message- From:

git-bashe.exe fails to launch

Resending as Plain Text. After upgrading to 2.16.1.windows.4, I have been unable to launch “C:\Program Files\Git\git-bash.exe” from installed shortcut or from command line (cmd). In both cases, the bash console flashes and closes immediately. I am able to invoke “C:\Program

Re: [PATCH v3 29/42] completion: use __gitcomp_builtin in _git_notes

On Fri, Feb 9, 2018 at 12:02 PM, Nguyễn Thái Ngọc Duy wrote: > diff --git a/contrib/completion/git-completion.bash > b/contrib/completion/git-completion.bash > index c7b8b37f19..60127daebf 100644 > --- a/contrib/completion/git-completion.bash > +++

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

On 2/13/2018 8:51 PM, Junio C Hamano wrote: 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

Re: [PATCH 2/2] init-db: change --template type to OPTION_FILENAME

On Wed, Feb 14, 2018 at 05:51:49PM +0700, Nguyễn Thái Ngọc Duy wrote: > OPTION_FILENAME has some magic behind the scene, like prefixing which is > useless for init-db. The $HOME expansion though does come handy and > makes --template more consistent with the rest (both env and config var > get

Re: [PATCH 1/2] parse-options: expand $HOME on filename options

On Wed, Feb 14, 2018 at 05:51:48PM +0700, Nguyễn Thái Ngọc Duy wrote: > When you specify "--path ~/foo", the shell will automatically expand > ~/foo to $HOME/foo before it's passed to git. The expansion is not done > on "--path=~/foo". An experienced user sees the difference but it could > still

Re: Regression in memory consumption of git fsck

On Wed, Feb 14, 2018 at 01:48:28PM +0100, SZEDER Gábor wrote: > > If I revert that commit (on top of current master) the memory > > consumption goes down to 2GB again. The change looks relatively harmless > > to me, so does anyone know what's going on here? > > I could reproduce the increased

Re: [PATCH v6 5/7] convert: add 'working-tree-encoding' attribute

> On 10 Feb 2018, at 10:48, Torsten Bögershausen wrote: > > On Fri, Feb 09, 2018 at 02:28:28PM +0100, lars.schnei...@autodesk.com wrote: >> From: Lars Schneider >> >> ... >> >> +Please note that using the `working-tree-encoding` attribute may have a

Re: [PATCH v3 06/42] completion: use __gitcomp_builtin in _git_am

On Fri, Feb 9, 2018 at 12:01 PM, Nguyễn Thái Ngọc Duy wrote: > The new completable options are: > > --directory > --exclude > --gpg-sign > --include > --keep-cr > --keep-non-patch > --message-id > --no-keep-cr > --patch-format > --quiet > --reject > --resolvemsg= > >

Re: Regression in memory consumption of git fsck

> I've noticed that recent versions of git consume a lot of memory during > "git fsck", to the point where I've regularly had git fall victim to > Linux's OOM killer. > > For example, if I clone torvalds/linux.git, and then run "git fsck > --connectivity-only" in the newly cloned repository, git

ipad air 2

Sent from my iPad

[PATCH] am: support --quit

Among the "in progress" commands, only git-am and git-merge do not support --quit. Support --quit in git-am too. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-am.txt | 6 +- builtin/am.c | 12 ++--

[PATCH 2/2] init-db: change --template type to OPTION_FILENAME

OPTION_FILENAME has some magic behind the scene, like prefixing which is useless for init-db. The $HOME expansion though does come handy and makes --template more consistent with the rest (both env and config var get $HOME expansion). Noticed-by: Doron Behar Signed-off-by:

[PATCH 1/2] parse-options: expand $HOME on filename options

When you specify "--path ~/foo", the shell will automatically expand ~/foo to $HOME/foo before it's passed to git. The expansion is not done on "--path=~/foo". An experienced user sees the difference but it could still be confusing for others (especially when tab-completion still works on

Regression in memory consumption of git fsck

Hi, I've noticed that recent versions of git consume a lot of memory during "git fsck", to the point where I've regularly had git fall victim to Linux's OOM killer. For example, if I clone torvalds/linux.git, and then run "git fsck --connectivity-only" in the newly cloned repository, git will

[BUG] git init doesn't respect `--template` like configuration variable init.templateDir and $GIT_TEMPLATE_DIR

The title says it all. If I run `git init --template=~/path/to/my/template` I get the following message: warning: templates not found ~/path/to/my/template But, if I run: $ env GIT_TEMPLATE_DIR=~/path/to/my/template git init I don't get a warning and the template is used just

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

On Wed, Feb 14, 2018 at 8:51 AM, Junio C Hamano wrote: > * nd/parseopt-completion (2018-02-09) 42 commits > - git-completion.bash: add GIT_COMPLETION_OPTIONS=all config > - completion: use __gitcomp_builtin in _git_worktree > - completion: use __gitcomp_builtin in _git_tag >

Re: [PATCH 3/7] worktree move: new command

On Wed, Feb 14, 2018 at 10:16 AM, Jeff King wrote: > Hmm. That is not too bad, but somehow it feels funny to me to be > polluting each test script with these annotations. And to be driving it > from inside the test scripts. > > It seems like: > > make SANITIZE=leak test

[PATCH] t/: correct obvious typo "detahced"

Signed-off-by: Robert P. J. Day --- diff --git a/t/t7409-submodule-detached-work-tree.sh b/t/t7409-submodule-detached-work-tree.sh index c20717181..fc018e363 100755 --- a/t/t7409-submodule-detached-work-tree.sh +++ b/t/t7409-submodule-detached-work-tree.sh @@ -6,7 +6,7

Re: [PATCH v2] dir.c: ignore paths containing .git when invalidating untracked cache

On Tue, Feb 13, 2018 at 5:24 PM, Duy Nguyen wrote: > I am worried that always doing the right thing may carry performance > penalty (this is based purely on reading verify_path() code, no actual > benchmarking). For safety, you can always set safe_path to zero. But > if you do

<    1   2