Re: git difftool with symlink to readonly jar failed

Hi, On Thu, May 24, 2018 at 11:11 PM, Etienne d'Hautefeuille wrote: > > #try a diff > git difftool --dir-diff 4cb98b4a307ce97d9e6b8e4b03211fa5ca8af7e7 > 0244799661b993b1f78fa5afb621de3fe4c4a39c > fatal: impossible d'ouvrir '/tmp/git-difftool.UQ4mqo/left/jenkins.war' en

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: [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: 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 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: [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: [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 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

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: "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 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 ... > >> +

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 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: "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 v3 01/20] commit-graph: UNLEAK before die()

On 5/24/2018 6:47 PM, Stefan Beller wrote: 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

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

On Thu, 24 May 2018 16:07:49 -0700 Stefan Beller wrote: > 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

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

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: 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: [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: [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: 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 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

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: 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: "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 ... >[--] [...]

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)",

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: [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

[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] 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] 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

[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: [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: 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

[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

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 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

[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: 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

[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"

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: 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.

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: [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: 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. >

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: 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) >

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 >

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: 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: [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: [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

[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,

[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

[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 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 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 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 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 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 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

[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 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 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 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 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 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

[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

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

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

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

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 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: [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

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

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: [GSoC][PATCH v3 0/4] rebase: split rebase -p from rebase -i

Hi, Le 24/05/2018 à 13:49, Alban Gruin a écrit : > Changes since v2: - Removing `mark_action_done()` from git-rebase--interactive.sh - Removing unused variables from git-rebase--interactive.sh Cheers, Alban

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

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. Signed-off-by: Alban Gruin --- .gitignore

[GSoC][PATCH v3 2/4] rebase: strip unused code in git-rebase--preserve-merges.sh

This removes the code coming from git-rebase--interactive.sh that is not needed by preserve-merges. Signed-off-by: Alban Gruin --- git-rebase--preserve-merges.sh | 65 +++--- 1 file changed, 4 insertions(+), 61 deletions(-) diff --git

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

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. This patch series is based of js/sequencer-and-root-commits.

[GSoC][PATCH v3 4/4] rebase: remove -p code from git-rebase--interactive.sh

All the code specific to preserve-merges was moved to git-rebase--preserve-merges.sh, and so it’s useless to keep it here. Signed-off-by: Alban Gruin --- git-rebase--interactive.sh | 802 + 1 file changed, 8 insertions(+), 794

[GSoC][PATCH v3 3/4] rebase: use the new git-rebase--preserve-merges.sh

Creates a new type of rebase, "preserve-merges", used when rebase is called with -p. Before that, the type for preserve-merges was "interactive", and some places of this script compared $type to "interactive". Instead, the code now checks if $interactive_rebase is empty or not, as it is set to

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

more pedantry -- was digging through "man git-diff" and noticed the inconsistency in how options are represented. first, in the synopsis, you see "[options]": SYNOPSIS git diff [options] [] [--] [...] git diff [options] --cached [] [--] [...] git diff [options] [--] [...]

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

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 > the conflict and ran rerere, the entry

unexpected "unresolved merge conflict" for a new file

Hi, `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) Documentation/core-api/gfp_mask-from-fs-io.rst:27:=== $ git status --porcelain A

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: [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

  1   2   >