Michael Haggerty writes:
> Finally, when I'm inventing new functions (which I admit isn't the case
> here), I usually write the declaration first and then copy-paste it to
> the C file as the first step in writing the definition. If I name the
> parameters in the declaration then (a) I don't have
Johannes Schindelin writes:
>> Jokes aside, given that you should regularly repack your repository
>> anyway, I do not think it is such a big downside that this mode
>> misses a corrupt objects, and the 1 out of 4 kinds of objects,
>> i.e. blobs, occupy major part of the repository storage, so th
Scott Schmit writes:
> On Fri, Jun 19, 2015 at 01:53:01PM -0700, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>
>> > Can you think of a name for the option that is as short as `--quick`
>> > but means the same as `--connectivity-only`?
>>
>> No I can't. I think `--connectivity-only`
On 06/15/2015 08:53 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> +struct ref_transaction *t;
>> +struct strbuf err = STRBUF_INIT;
>> +
>> +t = ref_transaction_begin(&err);
>> +if (!t)
>> +die(err.buf);
>
> Yikes, and sorry for sending three messages witho
On 06/15/2015 08:35 PM, Jeff King wrote:
> On Mon, Jun 15, 2015 at 11:13:22AM -0700, Junio C Hamano wrote:
>
>>> @@ -78,15 +170,15 @@ typedef int each_ref_fn(const char *refname,
>>> * modifies the reference also returns a nonzero value to immediately
>>> * stop the iteration.
>>> */
>>> -ex
On Fri, Jun 19, 2015 at 01:53:01PM -0700, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Can you think of a name for the option that is as short as `--quick`
> > but means the same as `--connectivity-only`?
>
> No I can't. I think `--connectivity-only` is a very good name that
> is u
Junio C Hamano writes:
> What would be the end-user experience if you stopped at the first
> error? You see an error, add an "fsck. = ignore" and rerun,
> only to find another error and rinse and repeat? Wouldn't you
> rather see all of them and add the "ignore" to cover them in one go?
>
>> I
Ahh, I didn't see that they were not grouped by object types, features
or any meaningful axis.
That explains it (i.e. I can now understand why the original list was
ordered differently from the final order).
On Fri, Jun 19, 2015 at 2:09 PM, Johannes Schindelin
wrote:
> Hi Junio,
>
> On 2015-06-1
That "... can be made ..." was not my wish but more like "the way the
code is structured it is possible for somebody to do such a thing
easily, well done" compliment ;-)
The message names will have to be shown somewhere in the
documentation, and in Documentation/ we try to use camelCase to show
th
Hi Junio,
On 2015-06-19 21:28, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> 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 "missingemail", the user might want to call `git config
On Fri, Jun 19, 2015 at 11:11 PM, Tuncer Ayaz wrote:
> On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski wrote:
>> [This is sent from Thunderbird news, so it should be all right]
>
> This is fine, the other one was broken. Out of curiosity what's the
> difference between Thunderbird email and news
On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski wrote:
> On 2015-06-18 at 23:25, Tuncer Ayaz wrote:
> > On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:
> > > On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> [...]
> > > One could imagine some frankly, quite rare example where t
Hi Junio,
On 2015-06-19 22:22, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> #define FSCK_FATAL -1
>> +#define FSCK_INFO -2
>>
>> #define FOREACH_MSG_ID(FUNC) \
>> /* fatal errors */ \
>> @@ -50,15 +51,16 @@
>> FUNC(ZERO_PADDED_DATE, ERROR) \
>> /* warnings */ \
>>
Hi Junio,
On 2015-06-19 22:21, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> 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
Hi Junio,
On 2015-06-19 22:16, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> err = fsck_ident(&buffer, &commit->object, options);
>> if (err)
>> return err;
>> +while (skip_prefix(buffer, "author ", &buffer)) {
>> +err = report(options, &commit->
Hi Junio,
On 2015-06-19 22:18, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> 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.
>
Johannes Schindelin writes:
>> I do not think this "if (err) return err;" that uses the return
>> value of report(), makes sense.
>>
>> As all the errors that use this pattern are isolated ones that does
>> not break parsing of the remainder (e.g. author ident had an extra >
>> in it may break "
Hi,
Stefan Beller wrote:
> This was introduced at b6e8a3b5 (2015-04-17, limit_list: avoid
> quadratic behavior from still_interesting), which
> also introduced the check a few lines before, which already dereferences
> `interesting_cache`. So at this point `interesting_cache` is guaranteed to
> b
On Fri, Jun 19, 2015 at 12:01:23PM -0700, Stefan Beller wrote:
> This was introduced at b6e8a3b5 (2015-04-17, limit_list: avoid
> quadratic behavior from still_interesting), which
> also introduced the check a few lines before, which already dereferences
> `interesting_cache`. So at this point `in
Hi Junio,
On 2015-06-19 22:12, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Note that some problems are too problematic to simply ignore. For
>> example, when the header lines are mixed up, we punt after encountering
>> an incorrect line. Therefore, demoting certain warnings to error
Johannes Schindelin writes:
> Can you think of a name for the option that is as short as `--quick`
> but means the same as `--connectivity-only`?
No I can't. I think `--connectivity-only` is a very good name that
is unfortunately a mouthful, I agree that we need a name that is as
short as `--xx
Johannes Schindelin writes:
> + if (strcmp(var, "receive.fsck.skiplist") == 0) {
> + const char *path = is_absolute_path(value) ?
> + value : git_path("%s", value);
This "either absolute or inside $GIT_DIR" looks somewhat strange to
me. Shouldn't we mimick wh
Hi Junio,
On 2015-06-19 22:32, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> This option avoids unpacking each and all objects, and just verifies the
>> connectivity.
>
> That sounds like marketing ;-)
>
> "Wow this does not unpack unnecessarily, wait, it needs to unpack
> and parse
Johannes Schindelin writes:
> + if (strcmp(var, "fsck.skiplist") == 0) {
> + const char *path = is_absolute_path(value) ?
> + value : git_path("%s", value);
Same comment as 18/19.
--
To unsubscribe from this list: send the line "unsubscribe git" in
On Fri, Jun 19, 2015 at 2:28 PM, Alexander Kuleshov
wrote:
> We can pass -o/--output-directory to the format-patch command to
> store patches not in the working directory. This patch introduces
> format.outputDirectory configuration option for same purpose.
>
> The case of usage of this configurat
Johannes Schindelin writes:
> This option avoids unpacking each and all objects, and just verifies the
> connectivity.
That sounds like marketing ;-)
"Wow this does not unpack unnecessarily, wait, it needs to unpack
and parse 3 out of 4 kinds of objects?"
Jokes aside, given that you should reg
Johannes Schindelin writes:
> #define FSCK_FATAL -1
> +#define FSCK_INFO -2
>
> #define FOREACH_MSG_ID(FUNC) \
> /* fatal errors */ \
> @@ -50,15 +51,16 @@
> FUNC(ZERO_PADDED_DATE, ERROR) \
> /* warnings */ \
> FUNC(BAD_FILEMODE, WARN) \
> - FUNC(BAD_TAG_NAME, WARN
Johannes Schindelin writes:
> 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 | 14 --
>
Johannes Schindelin writes:
> 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.
I agree with that. But if FSCK_MSG_BAD_OBJECT_SHA1 is an ignor
Johannes Schindelin writes:
> err = fsck_ident(&buffer, &commit->object, options);
> if (err)
> return err;
> + while (skip_prefix(buffer, "author ", &buffer)) {
> + err = report(options, &commit->object,
> FSCK_MSG_MULTIPLE_AUTHORS, "invalid format - mu
Johannes Schindelin writes:
> 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.
That makes sense.
> Note that some problems are too problem
Hi Paul,
On 2015-06-19 18:15, Paul Tan wrote:
> On Fri, Jun 19, 2015 at 11:09 PM, Junio C Hamano wrote:
>
>> The primary thing I care about is to discourage callers of the API element
>> am_state from touching these fields with strbuf functions. If it is char *
>> then
>> the would think twice
Johannes Schindelin writes:
> 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
> ---
Makes sense.
--
To unsubscribe from this list: send
Hi Junio,
first of all: the improvements discussed here are already part of v6.
On 2015-06-19 19:33, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> I basically made up names on the go, based on the messages.
>>
>>> Some of the questionable groups are:
>>>
>>> BAD_DATE DATE_OVERFLO
Johannes Schindelin writes:
> 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 "missingemail", the user might want to call `git config
> --add receive.fsck.missingemail=warn`).
>
> Signed-off-by:
Johannes Schindelin writes:
> diff --git a/fsck.c b/fsck.c
> index da5717c..8c3caff 100644
> --- a/fsck.c
> +++ b/fsck.c
> @@ -103,13 +103,85 @@ static int fsck_msg_type(enum fsck_msg_id msg_id,
> {
> int msg_type;
>
> - msg_type = msg_id_info[msg_id].msg_type;
> - if (options->s
Johannes Schindelin writes:
> +#define MSG_ID(id, msg_type) { STR(id), FSCK_##msg_type },
> static struct {
> + const char *id_string;
> int msg_type;
> } msg_id_info[FSCK_MSG_MAX + 1] = {
> FOREACH_MSG_ID(MSG_ID)
> - { -1 }
> + { NULL, -1 }
> };
> #undef MSG_ID
>
>
Am 18.06.2015 um 22:55 schrieb Lars Schneider:
AFAIK Git has two ways to clone a repository with respect to submodules:
(1) Plain clone of just the repository itself:
git clone git://github.com/foo/bar.git
(2) Recursive clone of the repository including all its submodules:
git clone --recursive
Johannes Schindelin writes:
> 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 war
Johannes Schindelin writes:
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> index 48fa472..87ae9ba 100644
> --- a/builtin/index-pack.c
> +++ b/builtin/index-pack.c
> @@ -75,6 +75,7 @@ static int nr_threads;
> static int from_stdin;
> static int strict;
> static int do_fsck_object;
This was introduced at b6e8a3b5 (2015-04-17, limit_list: avoid
quadratic behavior from still_interesting), which
also introduced the check a few lines before, which already dereferences
`interesting_cache`. So at this point `interesting_cache` is guaranteed to
be not NULL. The code is called refere
W dniu 2015-06-19 o 19:58, Junio C Hamano pisze:
> Charles Bailey writes:
[...]
>> +if (!git_parse_ulong(arg, opt->value))
>> +return opterror(opt, "expects a numerical value",
>> flags);
>
> This used to be:
>
>> -die(_("unable to parse value '%s' f
Junio C Hamano writes:
> Except for the minor nits above, I think this is a good change.
Oh, I forgot to mention one thing. I am not sure if this should be
called ULONG. "unsigned long"-ness is not the most important part
of this thing from the end-user's point of view, and also from the
point
We can pass -o/--output-directory to the format-patch command to
store patches not in the working directory. This patch introduces
format.outputDirectory configuration option for same purpose.
The case of usage of this configuration option can be convinience
to not pass everytime -o/--output-direc
Charles Bailey writes:
> From: Charles Bailey
>
> Fix the printf specification to treat 'integer' as the signed type that
> it is and add a test that checks that we parse negative option
> arguments.
>
> Signed-off-by: Charles Bailey
> ---
Makes sense. Will queue.
> t/t0040-parse-options.sh
Jeff King writes:
> Right, my point was only that it works for _your_ particular
> filter, but it would be nice to have something more general. And
> we already have "cat-file --batch-check". IOW, I think I would
> prefer the "magical" form because it's a better scripting building
> block. As you
On 2015-06-18 at 23:25, Tuncer Ayaz wrote:
> On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:
>> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
[...]
>> One could imagine some frankly, quite rare example where there is a
>> team of people who votes on each commit before it gets
Alexander Kuleshov writes:
> Ah, you mean to put this check before.
I am fuzzy what you mean "before" (or "after"); the "how about doing
it this way instead?" patch we are discussing is to replace the
change you did in your original, so if you apply it you would know
what addition goes to where
On 2015-06-19 at 06:25, Jeff King wrote:
> On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:
>> Author and committer include datetime in the contents of the
>> field, which is used by Git for heuristics limiting walk. Coauthor
>> would have the same date as author, isn't it? If, after
Charles Bailey writes:
> diff --git a/parse-options.h b/parse-options.h
> index c71e9da..2ddb26f 100644
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -18,7 +18,8 @@ enum parse_opt_type {
> OPTION_INTEGER,
> OPTION_CALLBACK,
> OPTION_LOWLEVEL_CALLBACK,
> - OPTION_FILEN
Sorry for the noise guys, was my fault.
Junio, now all is working and I'm going to send v2.
How to send it better in one patch or separate patches
for the documentation, tests and etc..?
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe git" in
Michael J Gruber writes:
> When no diff nor merge tool is specified (config, option), mergetool-lib
> is supposed to choose a default tool from a set of tools. That set is
> constructed dynamically depending on the environment (graphical, editor
> setting) as a space separated string of tool name
Johannes Schindelin writes:
> I basically made up names on the go, based on the messages.
>
>> Some of the questionable groups are:
>>
>> BAD_DATE DATE_OVERFLOW
>
> I guess it should be BAD_DATE_OVERFLOW to be more consistent?
I am not sure about "consistency", but surely a common prefix wo
Ah, you mean to put this check before. Just tested it and
many tests are broken. Will look on it now
2015-06-19 23:19 GMT+06:00 Alexander Kuleshov :
>> I thought I made that "if we did not see '-o dir' on the command
>> line, initialize output_directory to what we read from the config"
>> before w
Jeff King writes:
> I do strip it off, so it is OK for it to be different in both the
> pre-image and post-image. But what I can't tolerate is the
> intermingling with actual data:
>
> +\t\t\x1b[32m;foo
> +\t\x1b[32m;bar
I think that depends on the definition of "strip it off" ;-) What I
me
> I thought I made that "if we did not see '-o dir' on the command
> line, initialize output_directory to what we read from the config"
> before we make a call to set_outdir().
>
> What I am missing?
>
> Puzzled... FWIW, IIRC, the patch you are responding to passed the
> test you added.
Ok, Now w
Michael J Gruber writes:
> Now, since external diff runs on smudged blobs, it appears as if we
> mixed cleaned and smudged blobs when feeding external diffs; whereas
> really, we mix "worktree blobs" and "smudged repo blobs", which is okay
> as per our definition of clean/smudge: the difference i
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 18.06.2015 17:57:
>>
>> Perhaps 'tr/remerge-diff' (on 'pu') is of interest?
>
> I haven't reviewed remerge-diff but merged it on top of my own local
> additions and ran the full test suite successfully. Any big blocker to
> watch out
On Fri, Jun 19, 2015 at 11:09 PM, Junio C Hamano wrote:
> You do realize that strbuf internally does alloc/free so as a solution to
> fragmentation issue you are at the mercy of the same alloc/free, don't you?
Yes, of course, but it has the "alloc" variable to keep track of the
size of the alloca
Paul Tan writes:
> On Fri, Jun 19, 2015 at 5:10 AM, Junio C Hamano wrote:
>> Paul Tan writes:
>>
>>> + /* commit message and metadata */
>>> + struct strbuf author_name;
>>> + struct strbuf author_email;
>>> + struct strbuf author_date;
>>> + struct strbuf msg;
>>
>> Same co
Alexander Kuleshov writes:
> 2015-06-19 3:46 GMT+06:00 Junio C Hamano :
>> I agree with "later -o should override an earlier one", but I do not
>> necessarily agree with "'-o -' should be --stdout", for a simple
>> reason that "-o foo" is not "--stdout >foo".
>>
>> Perhaps something like this to
Duy Nguyen writes:
> Anyway it does not put strbuf_slopbuf in .rodata.
That's sad. I wa hoping that it would behave the same as this,
which does give me SEGV:
#include
static const char x = '\0';
static char *y = (char *)&x;
int main (void) {
*y = 1;
}
--
To unsubscribe from this li
2015-06-19 11:32 GMT+02:00 John Keeping :
> On Fri, Jun 19, 2015 at 10:57:55AM +0200, Michael J Gruber wrote:
>> Junio C Hamano venit, vidit, dixit 19.06.2015 00:55:
>> > John Keeping writes:
>> >
>> >> I think the summary is that there are some scenarios where the external
>> >> diff tool should
On 06/15/2015 08:29 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Subject: Re: [PATCH v2 05/12] delete_refs(): improve error message
>
> I'd call this "make error message more generic".
>
>> Change the error message from
>>
>> Could not remove branch %s
>>
>> to
>>
>> could
Hi Gary,
On 2015-06-19 16:09, Gary England wrote:
> Will do. It's unlikely that I'll be able to reproduce the error. But,
> in the event that it happens again, I'll let you know.
For the record, the problem usually lies with a certain implementation detail
on 32-bit only (if you know the `rebas
Hi Rusi,
Cc:ing the main Git list, as some of this has been discussed at the GitMerge in
Paris, and some participants of that discussion might want to join this thread.
On 2015-06-19 14:55, Rusi Mody wrote:
> Trying to setup git.
> Majority folks are MS VS users but also some *nixers.
>
> My c
Hi Johannes,
Will do. It's unlikely that I'll be able to reproduce the error. But, in the
event that it happens again, I'll let you know.
Thanks,
Gary
From: Johannes Schindelin
Sent: Friday, June 19, 2015 6:58 AM
To: Gary England
Cc: git@vger.kernel.org
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.missi
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by specifying `invalidtagname` and
`missingtaggerentry` in the receive.fsck. config setting.
Incidentally, the missing tagger warning is now really shown as a warning
(as opposed to being reported with the "er
Signed-off-by: Johannes Schindelin
---
Documentation/config.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3e37b93..306ab7a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2205,6 +2205,20 @
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
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
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
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 message type to "ignore".
This change "abuses" the missingemail=warn test to verify that "ignore"
is also accep
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. to missingcommitter=warn, but
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
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 | 14 --
t/t5504-fetch-receive-strict.sh | 11 +++
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..3f7e96a 100755
--- a/t/t5504-fetch-receive-strict.sh
+++ b/t/t5504-fet
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
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
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 "missingemail", the user might want to call `git config
--add receive.fsck.missingemail=warn`).
Signed-off-by: Johannes Schindelin
---
fsck.c
For example, missing emails in commit and tag objects can be demoted to
mere warnings with
git config receive.fsck.missingemail=warn
The value is actually a comma-separated list.
In case that the same key is listed in multiple receive.fsck.
lines in the config, the latter configuration w
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
These functions 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. The upcoming `fsck_set_msg_types()` function has to
handle partial strings because we would like to be able to parse, say,
'missingemail=
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
2015-06-19 3:46 GMT+06:00 Junio C Hamano :
> I agree with "later -o should override an earlier one", but I do not
> necessarily agree with "'-o -' should be --stdout", for a simple
> reason that "-o foo" is not "--stdout >foo".
>
> Perhaps something like this to replace builtin/ part of Alexander's
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
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
Hi Gary,
On 2015-06-11 21:21, Gary England wrote:
> Using git version 1.9.2-preview20140411, in Git Bash for Windows,
> performing a "git pull --rebase", received an unhandled exception.
Please note that the newest 1.9.x release is 1.9.5. Could you re-test with that
version, please? Or maybe yo
On Fri, Jun 19, 2015 at 4:43 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> diff --git a/builtin/am.c b/builtin/am.c
>> index dbc8836..af68c51 100644
>> --- a/builtin/am.c
>> +++ b/builtin/am.c
>> @@ -6,6 +6,158 @@
>> #include "cache.h"
>> #include "builtin.h"
>> #include "exec_cmd.h"
>> +#
On Fri, Jun 19, 2015 at 03:34:55AM -0400, Jeff King wrote:
> And here's some more bad news. If you look at the diff for this
> patch itself, it's terribly unreadable (the regular diff already is
> pretty bad, but the highlights make it much worse). There are big chunks
> where we take away 5 or 10
Hello,
Yes, thank you for advice.
2015-06-19 17:34 GMT+06:00 Remi Galan Alfonso
:
> Alexander Kuleshov writes:
>> +test_expect_success "format-patch format.outputDirectory option" '
>> + git config format.outputDirectory "patches/" &&
>> + git format-patch master..side &&
>> + cnt=$(ls | wc -l)
Alexander Kuleshov writes:
> +test_expect_success "format-patch format.outputDirectory option" '
> + git config format.outputDirectory "patches/" &&
> + git format-patch master..side &&
> + cnt=$(ls | wc -l) &&
> + echo $cnt &&
> + test $cnt = 3 &&
> + git config --unset format.outputDirectory
> +
On Fri, Jun 19, 2015 at 01:03:25PM +0200, Remi Galan Alfonso wrote:
>
> It's trivial matter but the line:
> > + > output 2> output.err &&
> should be written:
> > + >output 2>output.err &&
>
> It was incorrectly written before but since
> you are modifying the line, it might be a
> good thing t
On Fri, Jun 19, 2015 at 11:52:28AM +0100, John Keeping wrote:
> On Fri, Jun 19, 2015 at 11:33:24AM +0100, Charles Bailey wrote:
> > So, yes, performance is definitely an issue and I could have called this
> > command "git magically-generate-all-object-for-scripts" but then, as it
> > was so easy to
Charles Bailey writes:
> test_expect_success 'long options' '
> - test-parse-options --boolean --integer 1729 --boolean --string2=321 \
> - --verbose --verbose --no-dry-run --abbrev=10 --file fi.le\
> - --obsolete > output 2> output.err &&
> + test-parse-options --boolean --integer 1729 --unsigned
On Fri, Jun 19, 2015 at 11:33:24AM +0100, Charles Bailey wrote:
> So, yes, performance is definitely an issue and I could have called this
> command "git magically-generate-all-object-for-scripts" but then, as it
> was so easy to provide exactly the filtering that I was looking for in
> the C code,
On Fri, Jun 19, 2015 at 11:33:24AM +0100, Charles Bailey wrote:
> > Obviously I've glossed over the "how to get a list of objects" part.
> > If you truly want all objects (not just reachable ones), or if "rev-list
> > --objects" is too slow [...]
>
> So, yes, performance is definitely an issue an
On Fri, Jun 19, 2015 at 5:50 PM, Remi Galan Alfonso
wrote:
> Duy Nguyen writes:
>
>> + sb.buf[0] = 'Z';
>> + printf("%c\n", strbuf_slopbuf[0]);
>> + return 0;
>> startup_info = &git_startup_info;
>
> I might be wrong, but I definitely think that this
> printf and return 0 are some debug lines tha
Duy Nguyen writes:
> + sb.buf[0] = 'Z';
> + printf("%c\n", strbuf_slopbuf[0]);
> + return 0;
> startup_info = &git_startup_info;
I might be wrong, but I definitely think that this
printf and return 0 are some debug lines that you
forgot to remove.
Rémi
--
To unsubscribe from this list: send th
1 - 100 of 119 matches
Mail list logo
