Re: [PATCH] packfile: Correct zlib buffer handling

On Sat, May 26, 2018 at 12:56 AM, Jeremy Linton wrote: > @@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct packed_git > *p, > return NULL; > memset(, 0, sizeof(stream)); > stream.next_out = buffer; > -

Re: [GSoC][PATCH v3 1/4] rebase: duplicate git-rebase--interactive.sh to git-rebase--preserve-merges.sh

Alban Gruin writes: > This duplicates git-rebase--interactive.sh to > git-rebase--preserve-merges.sh. This is done to split -p from -i. No > modifications are made to this file here, but any code that is not used by -p > will be stripped in the next commit. > >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: >> By the way, this is one of these times when I feel that we should >> have a better multi-line message support in die/error/warning/info >> functions. Ideally, I should be able to write >> >> warning(_("the '-l' option is an alias for '--create-reflog'

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano writes: > With these two patches queued on top of jk/branch-l-0-deprecation, > the follow-up patches jk/branch-l-1-removal that makes 'branch -l' > to fail and then jk/branch-l-2-reincarnation that makes 'branch -l' > a synonym to 'branch --list' needs rebasing.

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano writes: > Yup, thanks for being extra explicit. I do imagine there are quite > a few of us who would be puzzled without this update (but with the > previous one to unhide it from behind the pager). With these two patches queued on top of

Re: [PATCH 2/5] t6036, t6042: use test_line_count instead of wc -l

On Thu, May 24, 2018 at 6:17 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >>> -test 2 = $(git ls-files -s | wc -l) && >>> -test 2 = $(git ls-files -u | wc -l) && >>> -test 2 = $(git ls-files -o | wc -l) && >> >>

Re: [PATCH] packfile: Correct zlib buffer handling

Jeremy Linton wrote: > The buffer being passed to zlib includes a null terminator that > git needs to keep in place. unpack_compressed_entry() attempts to > detect the case that the source buffer hasn't been fully consumed > by checking to see if the destination buffer has been over consumed. > >

Re: [PATCH 2/5] t6036, t6042: use test_line_count instead of wc -l

On Thu, May 24, 2018 at 6:17 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >>> -test 2 = $(git ls-files -s | wc -l) && >>> -test 2 = $(git ls-files -u | wc -l) && >>> -test 2 = $(git ls-files -o | wc -l) && >> >>

Re: [PATCH] packfile: Correct zlib buffer handling

On Fri, May 25, 2018 at 7:17 PM, Jeremy Linton wrote: > The buffer being passed to zlib includes a null terminator that > git needs to keep in place. unpack_compressed_entry() attempts to > detect the case that the source buffer hasn't been fully consumed > by checking to

[PATCH] packfile: Correct zlib buffer handling

The buffer being passed to zlib includes a null terminator that git needs to keep in place. unpack_compressed_entry() attempts to detect the case that the source buffer hasn't been fully consumed by checking to see if the destination buffer has been over consumed. This yields two problems, first

[PATCH] packfile: Correct zlib buffer handling

The buffer being passed to zlib includes a null terminator that git needs to keep in place. unpack_compressed_entry() attempts to detect the case that the source buffer hasn't been fully consumed by checking to see if the destination buffer has been over consumed. This yields two problems, first

Re: [PATCH v3 1/7] read-cache: teach refresh_cache_entry() to take istate

On Wed, May 23, 2018 at 7:47 AM, Jameson Miller wrote: > Refactor refresh_cache_entry() to work on a specific index, instead of > implicitly using the_index. This is in preparation for making the > make_cache_entry function work on a specific index. > > Signed-off-by:

Re: [PATCH v3 0/7] allocate cache entries from memory pool

> > The memory pool design makes some tradeoffs. It is not meant to > be completely replace malloc / free as a general purpose > allocator, but rather used in scenarios where the benefit (faster > allocations, lower bookkeeping overhead) is worth the > tradeoffs (not able to free individual

Re: [PATCH v3 0/7] allocate cache entries from memory pool

On Wed, May 23, 2018 at 7:47 AM, Jameson Miller wrote: > Changes from V2: > > - Tweak logic of finding available memory block for memory > allocation > > - Only search head block > > - Tweaked handling of large memory allocations. > >

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Johannes, On IRC you wrote: And BTW this is not bike-shedding to me. Discussing the name of a variable, or indentation, or line wrapping, is. But improving the user experience is important. We *suck* on that, historically, and I do want to break with that habit. ... avar, _ikke_: so a colleague

Re: [PATCH v2 3/5] config doc: elaborate on what transfer.fsckObjects does

On Fri, May 25, 2018 at 3:28 PM, Ævar Arnfjörð Bjarmason wrote: > The existing documentation led the user to believe that all we were > doing were basic reachability sanity checks, but that hasn't been true > for a very long time. Update the description to match reality, and >

Re: [PATCH v2 2/5] config doc: unify the description of fsck.* and receive.fsck.*

On Fri, May 25, 2018 at 3:28 PM, Ævar Arnfjörð Bjarmason wrote: > The documentation for the fsck. and receive.fsck. > variables was mostly duplicated in two places, with fsck. > making no mention of the corresponding receive.fsck., and the > same for fsck.skipList. > [...] >

Re: [PATCH v2 1/5] config doc: don't describe *.fetchObjects twice

On Fri, May 25, 2018 at 3:28 PM, Ævar Arnfjörð Bjarmason wrote: > Let's not duplicate the description of what *.fsckObjects does twice. Nit: "duplicate" and "twice" smell redundant. > instead let's refer to transfer.fsckObjects from both fetch.* and > receive.*.

[RFC PATCH 3/3] usage: translate the "error: "-prefix and others

Translate the "error: ", "fatal: ", "usage: " and "warning: " prefixes that we use for reporting that kind of information. Do not translate "BUG: ". We tend to prefer the messages themselves to be non-translated (and they're not supposed to ever appear anyway) so it makes sense to let the prefix

[RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

advice.c contains a useful code snippet which takes a multi-line string and prints the lines, prefixing and suffixing each line with two constant strings. This was originally added in 23cb5bf3b3 (i18n of multi-line advice messages, 2011-12-22) to produce such output: hint: some multi-line advice

[RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

Teach `vreportf()` to prefix all lines with the given prefix, not only the first line. This matches how "hint: " is being shown, and affects "error: ", "fatal: ", "usage: ", "warning: " and "BUG: " (as well as any out-of-tree and future users). Note that we need to adjust quite a few tests as a

[RFC PATCH 0/3] usage: prefix all lines in `vreportf()`, not just the first

On 25 May 2018 at 11:14, Junio C Hamano wrote: > Junio C Hamano writes: > >>> +warning("the '-l' option is an alias for >>> '--create-reflog' and"); >>> +warning("has no effect in list mode. This option will >>> soon

Re: [PATCH v2 4/5] config doc: mention future aspirations for transfer.fsckObjects

On Fri, May 25, 2018 at 9:28 PM, Ævar Arnfjörð Bjarmason wrote: > > Jeff King has said on at least a couple of occasions (at least one of > Let's note that in the documentation so we don't seem to be claiming > that this is by design. A previous version of this change called the

Re: sb/submodule-move-nested breaks t7411 under GIT_FSMONITOR_TEST

On Fri, May 25, 2018 at 5:28 AM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, May 17 2018, Junio C Hamano wrote: > >> * sb/submodule-move-nested (2018-03-29) 6 commits >> (merged to 'next' on 2018-04-25 at 86b177433a) >> + submodule: fixup nested submodules after moving the

[PATCH v2 3/5] config doc: elaborate on what transfer.fsckObjects does

The existing documentation led the user to believe that all we were doing were basic reachability sanity checks, but that hasn't been true for a very long time. Update the description to match reality, and note the caveat that there's a quarantine for accepting pushes, but not for fetching.

[PATCH v2 5/5] fetch: implement fetch.fsck.*

Implement support for fetch.fsck.* corresponding with the existing receive.fsck.*. This allows for pedantically cloning repositories with specific issues without turning off fetch.fsckObjects. One such repository is https://github.com/robbyrussell/oh-my-zsh.git which before this change will emit

[PATCH v2 0/5] fsck: doc fixes & fetch.fsck.* implementation

This should address all the comments to v1. Inter-diff: 1: a9cd795db5 ! 1: 3d61e44cb8 config doc: don't describe *.fetchObjects twice @@ -1,10 +1,6 @@ Author: Ævar Arnfjörð Bjarmason config doc: don't describe *.fetchObjects

[PATCH v2 2/5] config doc: unify the description of fsck.* and receive.fsck.*

The documentation for the fsck. and receive.fsck. variables was mostly duplicated in two places, with fsck. making no mention of the corresponding receive.fsck., and the same for fsck.skipList. I spent quite a lot of time today wondering why setting the fsck. variant wasn't working to clone a

[PATCH v2 1/5] config doc: don't describe *.fetchObjects twice

Let's not duplicate the description of what *.fsckObjects does twice. instead let's refer to transfer.fsckObjects from both fetch.* and receive.*. I don't think this description of it makes much sense, but for now I'm just moving the existing documentation around. Making it better will be done in

[PATCH v2 4/5] config doc: mention future aspirations for transfer.fsckObjects

Jeff King has said on at least a couple of occasions (at least one of which may have been in person over beer) that leaving corrupt objects in the local object store after a "fetch" that fails transfer.fsckObjects should be fixed, and we should have something like the server-side quarantine

Re: [PATCH v3] checkout & worktree: introduce checkout.implicitRemote

On Fri, May 25 2018, Duy Nguyen wrote: > On Fri, May 25, 2018 at 10:12 AM, Junio C Hamano wrote: >>> +Currently this is used by linkgit:git-checkout[1] when 'git checkout >>> +' will checkout the '' branch on another remote, >>> +and by linkgit:git-worktree[1] when 'git

Re: sb/submodule-move-nested breaks t7411 under GIT_FSMONITOR_TEST

Hi Ævar, On Fri, May 25, 2018 at 5:28 AM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, May 17 2018, Junio C Hamano wrote: > >> * sb/submodule-move-nested (2018-03-29) 6 commits >> (merged to 'next' on 2018-04-25 at 86b177433a) >> + submodule: fixup nested submodules after

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 06:14:16PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > >> - warning("the '-l' alias for '--create-reflog' is deprecated;"); > >> - warning("it will be removed in a future version of Git"); > >> + if (list) { >

Re: [PATCH 1/2] diff: turn --ita-invisible-in-index on by default

On Fri, May 25, 2018 at 6:43 PM, Jonathan Nieder wrote: > I think it should be reverted from 'next' because of the unintended > change to the behavior of "git diff HEAD". Ah. That is indeed unintended. I still don't know how this change affects that (but that's probably why

Re: [PATCH 1/2] diff: turn --ita-invisible-in-index on by default

Hi, Duy Nguyen wrote: > $ echo haha > new; git add -N > $ git diff > diff --git a/new b/new > index e69de29..5ad28e2 100644 > --- a/new > +++ b/new > @@ -0,0 +1 @@ > +haha > > Notice that the diff does not tell you that 'new' is a new file. The > diff with this

Re: [PATCH v9 00/17] rebase -i: offer to recreate commit topology by rebasing merges

This has been sent by mistake, I'm sorry, please disregard. Sergey Organov writes: > Johannes Schindelin writes: > >> Junio, I think this is now ready for `next`. Thank you for your patience >> and help with this. [...]

Re: [PATCH v3] checkout & worktree: introduce checkout.implicitRemote

On Fri, May 25, 2018 at 10:12 AM, Junio C Hamano wrote: >> +Currently this is used by linkgit:git-checkout[1] when 'git checkout >> +' will checkout the '' branch on another remote, >> +and by linkgit:git-worktree[1] when 'git worktree add' refers to a >> +remote branch. This

Re: [PATCH 1/2] diff: turn --ita-invisible-in-index on by default

On Thu, May 24, 2018 at 08:39:42PM -0700, Jonathan Nieder wrote: > Hi Duy, > > Nguyễn Thái Ngọc Duy wrote: > > > Due to the implementation detail of intent-to-add entries. The current > > "git diff" (i.e. no treeish or --cached argument) would show the > > changes in the i-t-a file, but it does

Re: [PATCH v9 00/17] rebase -i: offer to recreate commit topology by rebasing merges

Johannes Schindelin writes: > Junio, I think this is now ready for `next`. Thank you for your patience > and help with this. > > Once upon a time, I dreamed of an interactive rebase that would not > linearize all patches and drop all merge commits, but instead

[PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified

When cherry-picking multiple commits, it's impossible to have both merge- and non-merge commits on the same command-line. Not specifying '-m 1' results in cherry-pick refusing to handle merge commits, while specifying '-m 1' fails on non-merge commits. This patch allows '-m 1' for non-merge

js/empty-config-section-fix, was Re: What's cooking in git.git (May 2018, #03; Wed, 23)

Hi Junio, On Thu, 24 May 2018, Junio C Hamano wrote: > * js/empty-config-section-fix (2018-05-18) 1 commit > - config: a user-provided invalid section is not a BUG > > Error codepath fix. > > Will merge to 'next'. As a hotfix, maybe we can fast-track it to master? Thanks, Dscho

sb/submodule-move-nested breaks t7411 under GIT_FSMONITOR_TEST

On Thu, May 17 2018, Junio C Hamano wrote: > * sb/submodule-move-nested (2018-03-29) 6 commits > (merged to 'next' on 2018-04-25 at 86b177433a) > + submodule: fixup nested submodules after moving the submodule > + submodule-config: remove submodule_from_cache > + submodule-config: add

Re: [PATCH v2] t: make many tests depend less on the refs being files

On Fri, May 25, 2018 at 11:05 AM, Michael Haggerty wrote: > On Fri, May 25, 2018 at 10:59 AM, Jeff King wrote: >> On Fri, May 25, 2018 at 10:48:04AM +0200, Michael Haggerty wrote: >> >>> > test_expect_success "multi-fetch works off a 'clean' repository" '

Re: [PATCH v2] t: make many tests depend less on the refs being files

On Fri, May 25, 2018 at 10:48 AM, Michael Haggerty wrote: > On 05/23/2018 07:25 AM, Christian Couder wrote: >> >> diff --git a/t/t1401-symbolic-ref.sh b/t/t1401-symbolic-ref.sh >> index 9e782a8122..a4ebb0b65f 100755 >> --- a/t/t1401-symbolic-ref.sh >> +++

Re: "git grep" and "working tree" vs "working directory"

On Fri, 25 May 2018, Junio C Hamano wrote: > Stefan Beller writes: > > > There are 2 dimensions to it: > > * (where you are) > > if you run git-grep from a sub directory of the repository, then the > > "sub-working-tree" > > will be searched. > > s/the repository/the top

[PATCH] completion: complete remote names too

"git remote update" accepts both groups and single remotes. Signed-off-by: Łukasz Stelmach --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash

Re: [GSoC][PATCH v3 0/4] rebase: split rebase -p from rebase -i

Hi Alban, On Thu, 24 May 2018, Alban Gruin wrote: > This splits the `rebase --preserve-merges` functionnality from > git-rebase--interactive.sh. All the dead code left by the duplication of > git-rebase--interactive.sh is also removed. This will make it easier to > rewrite > this script in C. >

[PATCH] Clarify that a tag can refer to a non-commit object

Reword "man git-tag" to clarify that a tag can refer directly to an arbitrary object, not just a commit object. Signed-off-by: Robert P. J. Day --- diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 1d17101ba..87c4288ff 100644 ---

Re: "man git-tag" inconsistent about whether you can tag non-commit objects

On Fri, 25 May 2018, Junio C Hamano wrote: > "Robert P. J. Day" writes: > > > embarrassed to admit i had no idea that you could tag non-commit > > objects, only realized that when i was reading the man page and saw: > > > > SYNOPSIS > > git tag [-a | -s | -u ]

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano writes: >> -warning("the '-l' alias for '--create-reflog' is deprecated;"); >> -warning("it will be removed in a future version of Git"); >> +if (list) { >> +warning("the '-l' option is an alias for >>

Re: [PATCH v2] t: make many tests depend less on the refs being files

On Fri, May 25, 2018 at 10:59 AM, Jeff King wrote: > On Fri, May 25, 2018 at 10:48:04AM +0200, Michael Haggerty wrote: > >> > test_expect_success "multi-fetch works off a 'clean' repository" ' >> > - rm -r "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" "$GIT_DIR/logs" && >> > + rm -rf

Re: [PATCH v2] t: make many tests depend less on the refs being files

On Fri, May 25, 2018 at 10:48:04AM +0200, Michael Haggerty wrote: > > test_expect_success "multi-fetch works off a 'clean' repository" ' > > - rm -r "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" "$GIT_DIR/logs" && > > + rm -rf "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" && > > + git reflog expire

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: > People mistakenly use "git branch -l", thinking that it > triggers list mode. It doesn't, but the lack of non-option > arguments in that command does (and the "-l" becomes a > silent noop). > > Since afc968e579 (branch: deprecate "-l" option, 2018-03-26) >

Re: [PATCH v2] t: make many tests depend less on the refs being files

On 05/23/2018 07:25 AM, Christian Couder wrote: > From: David Turner > > Many tests are very focused on the file system representation of the > loose and packed refs code. As there are plans to implement other > ref storage systems, let's migrate these tests to a form

Re: "man git-tag" inconsistent about whether you can tag non-commit objects

Ævar Arnfjörð Bjarmason writes: >> As that sentence talks about a lightweight tag (i.e. a reference in >> refs/tags/ hierarchy that directly points at an object of any kind), >> another possibility would be to say >> >> Otherwise a tag reference that directly points at the

Re: [PATCH v2] Use proper syntax for replaceables in command docs

"Robert P. J. Day" writes: > The standard for command documentation synopses appears to be: > > [...] means optional > <...> means replaceable > [<...>] means both optional and replaceable > > So fix a number of doc pages that use incorrect variations of the > above.

Re: [PATCH v3] checkout & worktree: introduce checkout.implicitRemote

Ævar Arnfjörð Bjarmason writes: > +checkout.implicitRemote:: > + When you run 'git checkout ' and only have one > + remote, it may implicitly fall back on checking out and > + tracking e.g. 'origin/'. Yup, that is quite implicit. It works without configuring

Re: "man git-tag" inconsistent about whether you can tag non-commit objects

On Fri, May 25 2018, Junio C Hamano wrote: > "Robert P. J. Day" writes: > >> embarrassed to admit i had no idea that you could tag non-commit >> objects, only realized that when i was reading the man page and saw: >> >> SYNOPSIS >> git tag [-a | -s | -u ] [-f]

Re: [PATCH v2] Use proper syntax for replaceables in command docs

On Thu, May 24, 2018 at 04:11:39PM -0400, Robert P. J. Day wrote: > diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt > index 37b96c545..f98b7c6ed 100644 > --- a/Documentation/git-cvsserver.txt > +++ b/Documentation/git-cvsserver.txt > @@ -22,7 +22,7 @@ cvspserver

Re: BUG: No way to set fsck. when cloning

On Thu, May 24 2018, Thomas Braun wrote: > Am 24.05.2018 um 17:25 schrieb Ævar Arnfjörð Bjarmason: >> When I do: >> >> git -c fetch.fsckObjects=true clone >> g...@github.com:robbyrussell/oh-my-zsh.git >> >> I get: >> >> error: object 2b7227859263b6aabcc28355b0b994995b7148b6: >>

Re: unexpected "unresolved merge conflict" for a new file

On Thu 24-05-18 13:11:20, Jeff King wrote: > On Thu, May 24, 2018 at 01:36:57PM +0200, Michal Hocko wrote: > > > `git commit' fails on a newly added file with the following > > * > > * You have some suspicious patch lines: > > * > > * In Documentation/core-api/gfp_mask-from-fs-io.rst > > *

Re: git difftool with symlink to readonly jar failed

Hi, same problem with all program, There is a crash before the launch > git difftool --dir-diff 4cb98b4a307ce97d9e6b8e4b03211fa5ca8af7e7 0244799661b993b1f78fa5afb621de3fe4c4a39c -- fatal: could not open '/tmp/git-difftool.g80nLO/left/jenkins.war' for writing: Permission denied > git difftool

Re: commit-graph: change in "best" merge-base when ambiguous

On 05/25/2018 12:08 AM, Jakub Narebski wrote: > Derrick Stolee writes: >> On 5/22/2018 1:39 AM, Michael Haggerty wrote: >>> On 05/21/2018 08:10 PM, Derrick Stolee wrote: [...] >>> This may be beyond the scope of what you are working on, but there are >>> significant