On 01/28/2015 11:33 PM, Junio C Hamano wrote:
> We may want to say something about command line option names in the
> new section as well, but for now, let's make sure everybody is clear
> on how to structure and name their configuration variables.
>
> The text for the rules are partly taken from
Hi Junio,
The following changes since commit 15598cf41beed0d86cd2ac443e0f69c5a3b40321:
Git 2.3.0-rc2 (2015-01-27 14:39:53 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 7471cf88f54990831fe2fd84160350fe432a7b76:
l10n:
The optional new config option `receive.fsck.skiplist` specifies the path
to a file listing the names, i.e. SHA-1s, one per line, of objects that
are to be ignored by `git receive-pack` when `receive.fsckObjects = true`.
This is extremely handy in case of legacy repositories where it would
cause m
Identical to support in `git receive-pack for the config option
`receive.fsck.skiplist`, we now support ignoring given objects in
`git fsck` via `fsck.skiplist` altogether.
This is extremely handy in case of legacy repositories where it would
cause more pain to change incorrect objects than to liv
We already have support in `git receive-pack` to deal with some legacy
repositories which have non-fatal issues.
Let's make `git fsck` itself useful with such repositories, too, by
allowing users to ignore known issues, or at least demote those issues
to mere warnings.
Example: `git -c fsck.sever
This option avoids unpacking each and all objects, and just verifies the
connectivity. In particular with large repositories, this speeds up the
operation, at the expense of missing corrupt blobs and ignoring
unreachable objects, if any.
Signed-off-by: Johannes Schindelin
---
Documentation/git-f
Some legacy code has objects with non-fatal fsck issues; To enable the
user to ignore those issues, let's print out the ID (e.g. when
encountering "missing-email", the user might want to call `git config
--add receive.fsck.severity missing-email=warn`).
Signed-off-by: Johannes Schindelin
---
fsc
An fsck issue in a legacy repository might be so common that one would
like not to bother the user with mentioning it at all. With this change,
that is possible by setting the respective error to "ignore".
This change "abuses" the missing-email=warn test to verify that "ignore"
is also accepted an
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by specifying `invalid-tag-name` and
`missing-tagger-entry` in the receive.fsck.severity config setting.
Incidentally, the missing tagger warning is now really shown as a warning
(as opposed to being reported
This problem has been detected in the wild, and is the primary reason
to introduce an option to demote certain fsck errors to warnings. Let's
offer to ignore this particular problem specifically.
Technically, we could handle such repositories by setting
receive.fsck.severity to missing-committer=w
Signed-off-by: Johannes Schindelin
---
t/t5504-fetch-receive-strict.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
index 69ee13c..9d49cb7 100755
--- a/t/t5504-fetch-receive-strict.sh
+++ b/t/t5504-fet
Signed-off-by: Johannes Schindelin
---
Documentation/config.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae6791d..f893492 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2130,6 +2130,21
Some kinds of errors are intrinsically unrecoverable (e.g. errors while
uncompressing objects). It does not make sense to allow demoting them to
mere warnings.
Signed-off-by: Johannes Schindelin
---
fsck.c | 13 +++--
t/t5504-fetch-receive-strict.sh | 11
When fsck_tag() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Just like fsck_commit(), there are certain problems that could hide other
issues with the same tag
When fsck_ident() identifies a problem with the ident, it should still
advance the pointer to the next line so that fsck can continue in the
case of a mere warning.
Signed-off-by: Johannes Schindelin
---
fsck.c | 49 +++--
1 file changed, 27 insertions
When fsck_commit() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Note that some problems are too problematic to simply ignore. For
example, when the header lines
There are legacy repositories out there whose older commits and tags
have issues that prevent pushing them when 'receive.fsckObjects' is set.
One real-life example is a commit object that has been hand-crafted to
list two authors.
Often, it is not possible to fix those issues without disrupting th
Just like the diff machinery, we are about to introduce more settings,
therefore it makes sense to carry them around as a (pointer to a) struct
containing all of them.
Signed-off-by: Johannes Schindelin
---
builtin/fsck.c | 20 +--
builtin/index-pack.c | 9 +--
builtin/unpac
For example, missing emails in commit and tag objects can be demoted to
mere warnings with
git config receive.fsck.severity missing-email=warn
The value is actually a comma-separated list.
In case that the same key is listed in multiple receive.fsck.severity
lines in the config, the latt
Instead of specifying whether a message by the fsck machinery constitutes
an error or a warning, let's specify an identifier relating to the
concrete problem that was encountered. This is necessary for upcoming
support to be able to demote certain errors to warnings.
In the process, simplify the r
This function will be used in the next commits to allow the user to
ask fsck to handle specific problems differently, e.g. demoting certain
errors to warnings. It has to handle partial strings because we would
like to be able to parse, say, 'missing-email,missing-tagger-entry'
command lines.
To ma
At the moment, the git-fsck's integrity checks are targeted toward the
end user, i.e. the error messages are really just messages, intended for
human consumption.
Under certain circumstances, some of those errors should be allowed to
be turned into mere warnings, though, because the cost of fixing
Hi Michael & Junio,
On 2015-01-22 18:17, Johannes Schindelin wrote:
> [...] we need to avoid confusing settings such as
>
> ```
> [receive.fsck]
> warn = missing-tagger-entry
> error = missing-tagger-entry
> ```
I *think* I found a solution.
Please let me recapitulate quickly the probl
Please avoid the combination "-B -M" when running "diff" family of
commands, as it can produce incorrect results [*1*] in corner cases.
Use of either "-B" or "-M" by itself is fine, but not both at the
same time.
This problem exists even in Git v1.7.12, and I have no reason to
suspect that it work
Hi,
It seems that the same commit dfa72fdb96 is responsible for the error
in "git svn clone https://geuz.org/svn/gmsh/trunk";. But unlike in my
case, the patch doesn't fix it.
Cheers,
Valery
On 31 January 2015 at 13:51, Nico Schlömer wrote:
> I tried the patch and I still get
> ```
> [...]
> r
I tried the patch and I still get
```
[...]
r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
Unexpected result returned from git cat-file at
/home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 335.
Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
/home/nsc
you have an important message email Mrs Cathrina Hugan for details.
chuga...@gmail.com
Confidential: This communication and any attachment(s) may contain confidential
or privileged information and is intended solely for the address(es) or the
entity representing the recipient(s). If you have
27 matches
Mail list logo
