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
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
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
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
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
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,
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
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
>
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
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
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
> 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
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
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
> -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
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
[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
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
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
>
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
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
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
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,
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
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
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
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
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
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
@@
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
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
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
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
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,
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
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' '
>>
>>
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)
>
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
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
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
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
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
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
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
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
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
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
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
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
> >
> * 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
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
> >
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.
> [...]
>
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
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.
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.
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
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
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
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
---
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
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.
>
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"
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
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
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
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
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
> -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
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
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,
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
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.
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 ...
>
>> +
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
>
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)",
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
---
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
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)
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 ...
>[--] [...]
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
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
>
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
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
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
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
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
"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]
> [ | ]
>
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
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
Æ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
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
Æ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.
> +
>
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
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,
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
>
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
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
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
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
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 - 100 of 112 matches
Mail list logo