[PATCH 4/5] t6036, t6042: prefer test_cmp to sequences of test

Signed-off-by: Elijah Newren --- t/t6036-recursive-corner-cases.sh| 109 +-- t/t6042-merge-rename-corner-cases.sh | 94 ++- 2 files changed, 130 insertions(+), 73 deletions(-) diff --git a/t/t6036-recursive-corner-cases.sh

[PATCH 1/5] t6036, t6042: use test_create_repo to keep tests independent

These tests used pretty strong measures to get a clean slate: git rm -rf . && git clean -fdqx && rm -rf .git && git init && It's easier, safer (what if a previous test has a bug and accidentally changes into a directory outside the test path?), and allows

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

Signed-off-by: Elijah Newren --- t/t6036-recursive-corner-cases.sh| 102 ++- t/t6042-merge-rename-corner-cases.sh | 99 +- 2 files changed, 134 insertions(+), 67 deletions(-) diff --git a/t/t6036-recursive-corner-cases.sh

[PATCH 3/5] t6036, t6042: prefer test_path_is_file, test_path_is_missing

Signed-off-by: Elijah Newren --- t/t6036-recursive-corner-cases.sh| 4 +-- t/t6042-merge-rename-corner-cases.sh | 40 ++-- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/t/t6036-recursive-corner-cases.sh

[PATCH 5/5] t6036: prefer test_when_finished to manual cleanup in following test

Manually cleaning up from former tests in subsequent ones breaks the ability to select which tests we want to run. Use test_when_finished to avoid this problem. Signed-off-by: Elijah Newren --- t/t6036-recursive-corner-cases.sh | 22 -- 1 file changed, 12

Re: [RFC/PATCH 2/7] rerere: mark strings for translation

Thomas Gummerer writes: > if (write_in_full(out_fd, buf.buf, buf.len) < 0) > - die("unable to write rerere record"); > + die(_("unable to write rerere record")); As we'd be adding these new strings to the .po file,

[PATCH v2] rev-parse: check lookup'ed commit references for NULL

Commits 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax", 2008-07-26) and 3dd4e7320d ("Teach rev-parse the ... syntax.", 2006-07-04) taught rev-parse new syntax, and used lookup_commit_reference() as part of their logic. Neither usage checked the returned commit to see if it was

Re: What's cooking in git.git (May 2018, #03; Wed, 23)

Hi Junio, On Wed, May 23, 2018 at 5:02 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 >

[PATCH 0/5] Modernize some testcases for merge-recursive corner cases

I have about a dozen more testcases I want to add to the testsuite, in order to document additional situations that merge-recursive handles suboptimally. To avoid sending an excessively long series, I am splitting this up. This series just aims to modernize a pair of testfiles in which several

Re: [RFC/PATCH 3/7] rerere: add some documentation

Thomas Gummerer writes: > +Conflict normalization > +-- > + > +To try and re-do a conflict resolution, even when different merge > +strategies are used, 'rerere' computes a conflict ID for each > +conflict in the file. > + > +This is done by discarding

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

On Thu, May 24, 2018 at 12:05 PM, SZEDER Gábor wrote: > >> Signed-off-by: Elijah Newren >> --- >> t/t6036-recursive-corner-cases.sh| 102 ++- >> t/t6042-merge-rename-corner-cases.sh | 99 +- >> 2 files

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

> Signed-off-by: Elijah Newren > --- > t/t6036-recursive-corner-cases.sh| 102 ++- > t/t6042-merge-rename-corner-cases.sh | 99 +- > 2 files changed, 134 insertions(+), 67 deletions(-) > > diff --git

Re: [RFC/PATCH 7/7] rerere: teach rerere to handle nested conflicts

Thomas Gummerer writes: > No automated test for this yet. As mentioned in the cover letter as > well, I'm not sure if this is common enough for us to actually > consider this use case. I don't know how nested conflicts could > actually be created apart from committing a

Re: [RFC/PATCH 5/7] rerere: only return whether a path has conflicts or not

Thomas Gummerer writes: > We currently return the exact number of conflict hunks a certain path > has from the 'handle_paths' function. However all of its callers only > care whether there are conflicts or not or if there is an error. > Return only that information, and

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

> -Original Message- > From: Junio C Hamano On Behalf Of Junio C Hamano > Sent: Thursday, May 24, 2018 12:55 AM > To: Jameson Miller > Cc: git@vger.kernel.org; pclo...@gmail.com; jonathanta...@google.com; > sbel...@google.com; peart...@gmail.com

why do "git log -h" and "git show -h" print the same thing?

maybe this is deliberate, but it's confusing that, with git 2.17.0, the output of both "git log -h" and "git show -h" is exactly the same: $ git log -h usage: git log [] [] [[--] ...] or: git show [] ... -q, --quiet suppress diff output --source show source

Re: [PATCH v2] rev-parse: check lookup'ed commit references for NULL

[Added Florian to Cc] Elijah Newren wrote: > Commits 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax", > 2008-07-26) and 3dd4e7320d ("Teach rev-parse the ... syntax.", 2006-07-04) > taught rev-parse new syntax, and used lookup_commit_reference() as part of > their logic. Neither

jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

On Thursday 17 May 2018 07:06 PM, Jeff King wrote: > But because git-branch does not kick in the pager until later > (because it only wants to do it for list-mode), that happens _after_ > we've emitted the message. > I observe exactly the consequence of this behaviour. First, the error is

Re: [PATCH v2] rev-parse: check lookup'ed commit references for NULL

On Wed, May 23, 2018 at 11:27:33PM -0700, Elijah Newren wrote: > Commits 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax", > 2008-07-26) and 3dd4e7320d ("Teach rev-parse the ... syntax.", 2006-07-04) > taught rev-parse new syntax, and used lookup_commit_reference() as part of >

[PATCH v3 00/20] Integrate commit-graph into 'fsck' and 'gc'

Thanks for all the feedback on v2. I've tried to make this round's review a bit easier by splitting up the commits into smaller pieces. Also, the test script now has less boilerplate and uses variables and clear arithmetic to explain which bytes are being modified. One other change worth

[PATCH v3 06/20] commit-graph: add 'verify' subcommand

If the commit-graph file becomes corrupt, we need a way to verify that its contents match the object database. In the manner of 'git fsck' we will implement a 'git commit-graph verify' subcommand to report all issues with the file. Add the 'verify' subcommand to the 'commit-graph' builtin and its

[PATCH v3 11/20] commit-graph: verify root tree OIDs

The 'verify' subcommand must compare the commit content parsed from the commit-graph and compare it against the content in the object database. Use lookup_commit() and parse_commit_in_graph_one() to parse the commits from the graph and compare against a commit that is loaded separately and parsed

[PATCH v3 10/20] commit-graph: verify objects exist

In the 'verify' subcommand, load commits directly from the object database to ensure they exist. Parse by skipping the commit-graph. Signed-off-by: Derrick Stolee --- commit-graph.c | 20 t/t5318-commit-graph.sh | 7 +++ 2 files changed,

[PATCH v3 19/20] gc: automatically write commit-graph files

The commit-graph file is a very helpful feature for speeding up git operations. In order to make it more useful, write the commit-graph file by default during standard garbage collection operations. Add a 'gc.commitGraph' config setting that triggers writing a commit-graph file after any

[PATCH v3 16/20] commit-graph: verify contents match checksum

The commit-graph file ends with a SHA1 hash of the previous contents. If a commit-graph file has errors but the checksum hash is correct, then we know that the problem is a bug in Git and not simply file corruption after-the-fact. Compute the checksum right away so it is the first error that

[PATCH v3 02/20] commit-graph: fix GRAPH_MIN_SIZE

The GRAPH_MIN_SIZE macro should be the smallest size of a parsable commit-graph file. However, the minimum number of chunks was wrong. It is possible to write a commit-graph file with zero commits, and that violates this macro's value. Rewrite the macro, and use extra macros to better explain the

[PATCH v3 05/20] commit-graph: load a root tree from specific graph

When lazy-loading a tree for a commit, it will be important to select the tree from a specific struct commit_graph. Create a new method that specifies the commit-graph file and use that in get_commit_tree_in_graph(). Signed-off-by: Derrick Stolee --- commit-graph.c | 12

[PATCH v3 12/20] commit-graph: verify parent list

The commit-graph file stores parents in a two-column portion of the commit data chunk. If there is only one parent, then the second column stores 0x to indicate no second parent. The 'verify' subcommand checks the parent list for the commit loaded from the commit-graph and the one parsed

[PATCH v3 01/20] commit-graph: UNLEAK before die()

Signed-off-by: Derrick Stolee --- builtin/commit-graph.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c index 37420ae0fd..f0875b8bf3 100644 --- a/builtin/commit-graph.c +++ b/builtin/commit-graph.c @@

[PATCH v3 04/20] commit: force commit to parse from object database

In anticipation of verifying commit-graph file contents against the object database, create parse_commit_internal() to allow side-stepping the commit-graph file and parse directly from the object database. Due to the use of generation numbers, this method should not be called unless the intention

[PATCH v3 14/20] commit-graph: verify commit date

Signed-off-by: Derrick Stolee --- commit-graph.c | 6 ++ t/t5318-commit-graph.sh | 6 ++ 2 files changed, 12 insertions(+) diff --git a/commit-graph.c b/commit-graph.c index ead92460c1..d2b291aca2 100644 --- a/commit-graph.c +++ b/commit-graph.c @@ -981,6

[PATCH v3 09/20] commit-graph: verify corrupt OID fanout and lookup

In the commit-graph file, the OID fanout chunk provides an index into the OID lookup. The 'verify' subcommand should find incorrect values in the fanout. Similarly, the 'verify' subcommand should find out-of-order values in the OID lookup. Signed-off-by: Derrick Stolee

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

On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote: > When I do: > > git -c fetch.fsckObjects=true clone > g...@github.com:robbyrussell/oh-my-zsh.git > > I get: > > error: object 2b7227859263b6aabcc28355b0b994995b7148b6: > zeroPaddedFilemode: contains zero-padded

[PATCH v3 13/20] commit-graph: verify generation number

While iterating through the commit parents, perform the generation number calculation and compare against the value stored in the commit-graph. The tests demonstrate that having a different set of parents affects the generation number calculation, and this value propagates to descendants. Hence,

Re: [PATCH v2 03/12] commit-graph: test that 'verify' finds corruption

On 5/21/2018 2:53 PM, Jakub Narebski wrote: +corrupt_data() { + file=$1 + pos=$2 + data="${3:-\0}" + printf "$data" | dd of="$file" bs=1 seek="$pos" conv=notrunc +} First, if we do this that way (and not by adding a test helper), the use of this function should be, I

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

On Thu, May 24, 2018 at 3:05 AM, SZEDER Gábor wrote: >> --- a/t/t6036-recursive-corner-cases.sh >> +++ b/t/t6036-recursive-corner-cases.sh >> @@ -65,9 +65,12 @@ test_expect_success 'merge simple rename+criss-cross with >> no modifications' ' >> >>

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

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 > * unresolved merge conflict (line 27) >

BUG: No way to set fsck. when cloning

When I do: git -c fetch.fsckObjects=true clone g...@github.com:robbyrussell/oh-my-zsh.git I get: error: object 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes fatal: Error in object fatal: index-pack failed The docs

[PATCH v3 15/20] commit-graph: test for corrupted octopus edge

The commit-graph file has an extra chunk to store the parent int-ids for parents beyond the first parent for octopus merges. Our test repo has a single octopus merge that we can manipulate to demonstrate the 'verify' subcommand detects incorrect values in that chunk. Signed-off-by: Derrick Stolee

[PATCH v3 17/20] fsck: verify commit-graph

If core.commitGraph is true, verify the contents of the commit-graph during 'git fsck' using the 'git commit-graph verify' subcommand. Run this check on all alternates, as well. We use a new process for two reasons: 1. The subcommand decouples the details of loading and verifying a

[PATCH v3 08/20] commit-graph: verify required chunks are present

The commit-graph file requires the following three chunks: * OID Fanout * OID Lookup * Commit Data If any of these are missing, then the 'verify' subcommand should report a failure. This includes the chunk IDs malformed or the chunk count is truncated. Signed-off-by: Derrick Stolee

[PATCH v3 20/20] commit-graph: update design document

The commit-graph feature is now integrated with 'fsck' and 'gc', so remove those items from the "Future Work" section of the commit-graph design document. Also remove the section on lazy-loading trees, as that was completed in an earlier patch series. Signed-off-by: Derrick Stolee

[PATCH v3 18/20] commit-graph: add '--reachable' option

When writing commit-graph files, it can be convenient to ask for all reachable commits (starting at the ref set) in the resulting file. This is particularly helpful when writing to stdin is complicated, such as a future integration with 'git gc' which will call write_commit_graph_reachable() after

Re: [PATCH v2] rev-parse: check lookup'ed commit references for NULL

On 05/24/2018 04:04 PM, Todd Zullinger wrote: I added Florian to Cc, in case he wants to provide a preferred address. Sorry, using this address is fine. Thanks, Florian

[PATCH v3 07/20] commit-graph: verify catches corrupt signature

This is the first of several commits that add a test to check that 'git commit-graph verify' catches corruption in the commit-graph file. The first test checks that the command catches an error in the file signature. This is a check that exists in the existing commit-graph reading code. Add a

[PATCH v3 03/20] commit-graph: parse commit from chosen graph

Before verifying a commit-graph file against the object database, we need to parse all commits from the given commit-graph file. Create parse_commit_in_graph_one() to target a given struct commit_graph. Signed-off-by: Derrick Stolee --- commit-graph.c | 18

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

On Thu, May 24 2018, Kevin Daudt wrote: > On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote: >> When I do: >> >> git -c fetch.fsckObjects=true clone >> g...@github.com:robbyrussell/oh-my-zsh.git >> >> I get: >> >> error: object

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

On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote: > When I do: > > git -c fetch.fsckObjects=true clone > g...@github.com:robbyrussell/oh-my-zsh.git > > I get: > > error: object 2b7227859263b6aabcc28355b0b994995b7148b6: > zeroPaddedFilemode: contains zero-padded

Re: [RFC/PATCH 7/7] rerere: teach rerere to handle nested conflicts

On 05/24, Junio C Hamano wrote: > Thomas Gummerer writes: > > > No automated test for this yet. As mentioned in the cover letter as > > well, I'm not sure if this is common enough for us to actually > > consider this use case. I don't know how nested conflicts could > >

Re: What's cooking in git.git (May 2018, #03; Wed, 23)

> * sb/diff-color-move-more (2018-05-21) 8 commits > - diff: color-moved white space handling options imply color-moved > - diff.c: add --color-moved-ignore-space-delta option > - diff.c: decouple white space treatment from move detection algorithm > - diff.c: add a blocks mode for moved code

Re: jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote: > > On the other hand, I'm not sure this is that big a deal. The point of > > the deprecation warning is to catch people who are actually trying to > > use "-l" as "--create-reflog", and that case does not page. The people > >

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

On Thu, May 24, 2018 at 3:35 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: Weird revision walk behaviour

On 23/05/2018 20:35, Jeff King wrote: There's more discussion in the thread at: https://public-inbox.org/git/1366658602-12254-1-git-send-email-ke...@bracey.fi/ I haven't absorbed it all yet, but I'm adding Junio to the cc. Just to ack that I've seen the discussion, but I can't identify

Re: is the standard "[]", and not "[options]" or other?

On Thu, May 24, 2018 at 4:45 AM, Robert P. J. Day wrote: > > but should the man pages be updated similarly? i can whip up a patch > for that unless someone wants to comment on this further. Yes, please! I think [] are the best, as they are pedantically correct.

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

The existing documentation led the user to believe that all we were doing were basic readability 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 0/4] fsck: doc fixes & fetch.fsck.* implementation

On Thu, May 24, 2018 at 9:02 PM, Jeff King wrote: > On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> That doesn't work, because that's for the server-side, but I need the >> fetch.fsck.* that doesn't exist. This works (I'll send a better patch >> with

Re: What's cooking in git.git (May 2018, #03; Wed, 23)

On Thu, May 24 2018, Junio C Hamano wrote: > * ab/fetch-tags-noclobber (2018-05-16) 9 commits > - fixup! push tests: assert re-pushing annotated tags > - fetch: stop clobbering existing tags without --force > - fetch tests: add a test clobbering tag behavior > - fetch tests: correct a

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

Introduce a checkout.implicitRemote setting which can be used to designate a remote to prefer (via checkout.implicitRemote=origin) when running e.g. "git checkout master" to mean origin/master, even though there's other remotes that have the "master" branch. I want this because it's very handy to

[PATCH] Use proper syntax for replaceables in command docs

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. Signed-off-by: Robert P. J. Day ---

Re: [RFC/PATCH 4/7] rerere: fix crash when conflict goes unresolved

On 05/24, Junio C Hamano wrote: > Thomas Gummerer writes: > > > To fix this, remove the rerere ID from the MERGE_RR file in case we > > can't handle it, and remove the folder for the ID. Removing it > > unconditionally is fine here, because if the user would have resolved

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

On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote: > That doesn't work, because that's for the server-side, but I need the > fetch.fsck.* that doesn't exist. This works (I'll send a better patch > with tests / docs etc. soon): Yeah, I think this is the right direction. >

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

On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote: > On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote: > > > > On the other hand, I'm not sure this is that big a deal. The point of > > > the deprecation warning is to catch people who are actually trying to > > > use "-l"

[PATCH 4/4] 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 2/4] 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 1/4] config doc: don't describe *.fetchObjects twice

Change the copy/pasted description of the fetch.fsckObjects and receive.fsckObjects variables to refer to transfer.fsckObjects instead. 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

Re: What's cooking in git.git (May 2018, #03; Wed, 23)

On 24 May 2018 at 01:02, 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

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

On Thu, May 24, 2018 at 3:54 PM, Robert P. J. Day wrote: > 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

RE: [PATCH v3 2/7] block alloc: add lifecycle APIs for cache_entry structs

> -Original Message- > From: Junio C Hamano On Behalf Of Junio C Hamano > Sent: Thursday, May 24, 2018 12:52 AM > To: Jameson Miller > Cc: git@vger.kernel.org; pclo...@gmail.com; jonathanta...@google.com; > sbel...@google.com; peart...@gmail.com

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

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] [-m | -F ] [-e] [ | ] so i tried it and, sure enough, i

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

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 level directory of the working tree/, perhaps? >> also,

Re: [PATCH v2] rev-parse: check lookup'ed commit references for NULL

Elijah Newren writes: > I would have used a Reported-by tag for Florian and Todd, but looking at > the bugzilla.redhat.com bug report doesn't show me Florian's email > address. I grepped through git logs and found two associated with that > name, but didn't know if they were

Re: [RFC/PATCH 4/7] rerere: fix crash when conflict goes unresolved

Thomas Gummerer writes: > Sorry I botched the description here, and failed to describe what the > code is actually doing. We're actually only removing the variant in > the MERGE_RR file, whose path we are now no longer able to handle. Oh, that's absolutely fine, then.

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

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) && > > Here 'git ls-files -o' should have listed two untracked files ... > >> +

BUG: No way to set fsck. when cloning

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: > zeroPaddedFilemode: contains zero-padded file modes >

[PATCH] submodule: do not pass null OID to setup_revisions

If "git pull --recurse-submodules --rebase" is invoked when the current branch and its corresponding remote-tracking branch have no merge base, a "bad object" fatal error occurs. This issue was introduced with commit a6d7eb2c7a ("pull: optionally rebase submodules (remote submodule changes only)",

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

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. Signed-off-by: Robert P. J. Day ---

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

On Thu, May 24 2018, Eric Sunshine wrote: > On Thu, May 24, 2018 at 3:35 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

git difftool with symlink to readonly jar failed

Hi, In my repo, I have some symlink to readonly jar, I can't make difftool between 2 commit Steps to reproduce : > git --version git version 2.17.0 > id uid=1000(sagoum) gid=1000(sagoum)

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

On Wed, May 23, 2018 at 11:50 AM, Robert P. J. Day wrote: > > more puzzling terminology, this time in the man page for "git grep". > the SYNOPSIS shows, at the very end, the clearly optional > "[...]", > > git grep ... >... snip ... >[--] [...]

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

On Thu, 24 May 2018, Eric Sunshine wrote: > On Thu, May 24, 2018 at 3:54 PM, Robert P. J. Day > wrote: > > The standard for command documentation synopses appears to be: > > > > [...] means optional > > <...> means replaceable > > [<...>] means both optional and

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

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

Re: Weird revision walk behaviour

On 23/05/2018 20:35, Jeff King wrote: On Wed, May 23, 2018 at 01:32:46PM -0400, Jeff King wrote: On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote: $ git log --oneline master..ba95710a3b -- ci/ ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2 I keep

Re: [PATCH v3 00/20] Integrate commit-graph into 'fsck' and 'gc'

On Thu, May 24 2018, Derrick Stolee wrote: > Thanks for all the feedback on v2. I've tried to make this round's > review a bit easier by splitting up the commits into smaller pieces. > Also, the test script now has less boilerplate and uses variables and > clear arithmetic to explain which bytes

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

Eric Sunshine writes: > I see where you're coming from, however, I would think that readers > arriving at this topic (generally) do so as a result of actively > looking for it (as opposed to happening upon it), in which case they > probably are directly seeking

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

On Fri, May 25, 2018 at 10:55:45AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Hmm, actually, I suppose the true value of the warning is to help people > > doing "git branch -l foo", and it would still work there. The "more > > extreme" from your suggested patch would

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

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 not mark the file as new, while > "diff --cached" would mark the file as new

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

"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] [-m | -F ] [-e] > [ | ] >

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

Jeff King writes: > Hmm, actually, I suppose the true value of the warning is to help people > doing "git branch -l foo", and it would still work there. The "more > extreme" from your suggested patch would only affect "branch -l". > Still, I think I prefer the gentler version

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

Eric Sunshine writes: >> +will instead be left unreferenced in the repository. That's considered >> +a bug, and hopefully future git release will implement a quarantine >> +for the "fetch" side as well. > > If this was a "BUGS" section in a man-page, the above might be

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

Ævar Arnfjörð Bjarmason writes: > Change the copy/pasted description of the fetch.fsckObjects and > receive.fsckObjects variables to refer to transfer.fsckObjects > instead. > > Let's not duplicate the description of what *.fsckObjects does twice. > instead let's refer to

Re: Wrong -dirty suffix set by setlocalversion (was: BUG in git diff-index)

On 24/05/2018 16:03, Mike Mason wrote: > diff --git a/scripts/setlocalversion b/scripts/setlocalversion > index 71f39410691b..9da4c5e83285 100755 > --- a/scripts/setlocalversion > +++ b/scripts/setlocalversion > @@ -73,8 +73,10 @@ scm_version() > printf -- '-svn%s' "`git svn

Re: [PATCH 4/4] fetch: implement fetch.fsck.*

Ævar Arnfjörð Bjarmason writes: > fsck.skipList:: > - Like `fsck.` this variable has a corresponding > - `receive.fsck.skipList` variant. > + Like `fsck.` this variable has corresponding > + `receive.fsck.skipList` and `fetch.fsck.skipList` variants. > + >

Re: [PATCH v3 00/20] Integrate commit-graph into 'fsck' and 'gc'

Derrick Stolee writes: > One other change worth mentioning: in "commit-graph: add '--reachable' > option" I put the ref-iteration into a new external > 'write_commit_graph_reachable()' method inside commit-graph.c. This > makes the 'gc: automatically write commit-graph

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

Derrick Stolee writes: > On 5/22/2018 1:39 AM, Michael Haggerty wrote: >> On 05/21/2018 08:10 PM, Derrick Stolee wrote: >>> [...] >>> In the Discussion section of the `git merge-base` docs [1], we have the >>> following: >>> >>>     When the history involves criss-cross merges,

Re: [PATCH v3 01/20] commit-graph: UNLEAK before die()

On Thu, May 24, 2018 at 9:25 AM, Derrick Stolee wrote: > Signed-off-by: Derrick Stolee > --- > builtin/commit-graph.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c >

Re: why do "git log -h" and "git show -h" print the same thing?

On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day wrote: > > maybe this is deliberate, but it's confusing that, with git 2.17.0, > the output of both "git log -h" and "git show -h" is exactly the same: > > $ git log -h > usage: git log [] [] [[--] ...] >or: git show

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

On Thu, May 24, 2018 at 4:12 PM, Ævar Arnfjörð Bjarmason wrote: > On Thu, May 24 2018, Eric Sunshine wrote: >> On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason >> wrote: >>> fsck.skipList:: >>> + Like `fsck.` this variable has a corresponding

Re: why do "git log -h" and "git show -h" print the same thing?

On Thu, 24 May 2018, Stefan Beller wrote: > On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day > wrote: > > > > maybe this is deliberate, but it's confusing that, with git 2.17.0, > > the output of both "git log -h" and "git show -h" is exactly the same: > > > > $ git

Re: Wrong -dirty suffix set by setlocalversion (was: BUG in git diff-index)

How about something like this? It ignores attributes that should have no bearing on whether the kernel is considered dirty. Copied trees with no other changes would no longer be marked with -dirty. Plus it works on read-only media since no index updating is required. Would this also be considered

Re: [PATCH] submodule: do not pass null OID to setup_revisions

Hi Jonathan, On Thu, May 24, 2018 at 1:47 PM, Jonathan Tan wrote: > If "git pull --recurse-submodules --rebase" is invoked when the current > branch and its corresponding remote-tracking branch have no merge base, > a "bad object" fatal error occurs. This issue was

  1   2   >