Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
First release candidate 2.3-rc1 has been tagged. Please spend some
time to find and fix regressions, instead of spending all time
having fun wi
Yi EungJun writes:
> +static void write_accept_language(struct strbuf *buf)
> +{
> + /*
> + * MAX_DECIMAL_PLACES must not be larger than 3. If it is larger than
> + * that, q-value will be smaller than 0.001, the minimum q-value the
> + * HTTP specification allows. See
> +
Mike Hommey writes:
> Note the most important part is actually between the parens: that only
> happens when the remote helper returns '?' to the `list` command, which
> non-git remotes helpers (like git-remote-hg or git-remote-bzr) do.
> git-remote-testgit also does, so if you only apply the test
No i don't see any reasons why list_and_choose() shoud give a prompt
without candidates. Will resed patch.
Thank you.
2015-01-22 3:17 GMT+06:00 Junio C Hamano :
> Junio C Hamano writes:
>
>>> sub add_untracked_cmd {
>>> -my @add = list_and_choose({ PROMPT => 'Add untracked' },
>>> -
Ok, understand.
How to be with it? Resend after 2.3?
Thank you.
2015-01-22 3:13 GMT+06:00 Junio C Hamano :
> Thanks, but please hold this off until the 2.3 final is tagged.
>
> It is way too late for anything that is not a regression fix at this
> point in this cycle, and changes that affect i18
On Wed, Jan 21, 2015 at 10:46:48PM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > A typical remote helper will return a `list` of refs containing a symbolic
> > ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all
> > the refs are being requested through `fetch` or
"Kirill A. Shutemov" writes:
> I have tried to fix this before: see 568950388be2, but it doesn't
> really work.
>
> I don't know how it happend, but that commit makes interactive rebase to
> respect core.abbrev only during --edit-todo, but not the initial todo
> list edit.
>
> For this time I've
On Jan 21, 2015, at 14:33, Junio C Hamano wrote:
"Kyle J. McKay" writes:
So since I've not been able to get test 2 or 3 to core dump (even
before 250b3c6c) I tend to believe you are correct in that the code
thinks (incorrectly) that the result should fit within the buffer.
Thanks; let me st
Mike Hommey writes:
> A typical remote helper will return a `list` of refs containing a symbolic
> ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all
> the refs are being requested through `fetch` or `import`, including the
> symbolic ref.
>
> While this works properly, in
version2:
* This applies on top of origin/sb/atomic-push though it will result in a one
line merge conflict with origin/jk/lock-ref-sha1-basic-return-errors when
merging to origin/next.
* It now uses the FILE* pointer instead of file descriptors. This
results in a combination of the 2 forme
By closing the file descriptors after creating the lock file we are not
limiting the size of the transaction by the number of available file
descriptors.
Signed-off-by: Stefan Beller
---
refs.c| 17 +
t/t1400-update-ref.sh | 4 ++--
2 files changed, 15 insertions
The 'lock_fd' is the same as 'lk->fd'. No need to store it twice so remove
it. You may argue this introduces more coupling as we need to know more
about the internals of the lock file mechanism, but this will be solved in
a later patch.
No functional changes intended.
Signed-off-by: Stefan Beller
Signed-off-by: Stefan Beller
---
t/t1400-update-ref.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 7b4707b..47d2fe9 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -973,4 +973,32 @@ test_ex
During creation of the patch series our discussion we could have a
more descriptive name for the prerequisite for the test so it stays
unique when other limits of ulimit are introduced.
Signed-off-by: Stefan Beller
---
t/t7004-tag.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
Now we only have one place where we need to touch the internals of
the lock_file struct.
No functional changes intended.
Signed-off-by: Stefan Beller
---
refs.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 2472e61..2013d37 100644
On Mon, Jan 19, 2015 at 03:20:51PM +0100, Michael J Gruber wrote:
> Alexander Kuleshov schrieb am 17.01.2015 um 08:35:
> > This patch adds support -d/--dry-run option for branch(es) deletion.
> > If -d/--dry-run option passed to git branch -d branch..., branch(es)
> > will not be removed, instead j
On Wed, Jan 21, 2015 at 11:03 AM, Jeff King wrote:
>
> in your debugging statement (and of course use run_with... for the
> actual git command you want to limit).
>
Thanks for that hint, its now part of the bugfix series.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" i
On Wed, Jan 21, 2015 at 03:44:36PM -0800, Stefan Beller wrote:
> On Wed, Jan 21, 2015 at 3:38 PM, Jeff King wrote:
> > On Wed, Jan 21, 2015 at 03:23:42PM -0800, Stefan Beller wrote:
> >
> >> There is another occurrence where we could have used write_str_in_full
> >> (line 3107: write_in_full(lock
On Wed, Jan 21, 2015 at 03:23:39PM -0800, Stefan Beller wrote:
> (reported as: git update-ref --stdin : too many open files, 2014-12-20)
>
> First a test case is introduced to demonstrate the failure,
> the patches 2-6 are little refactoring and the last patch
> fixes the bug and also marks the
On Wed, Jan 21, 2015 at 03:23:44PM -0800, Stefan Beller wrote:
> + const char *sha1_lf;
>
> if (!lock) {
> errno = EINVAL;
> @@ -3104,8 +3104,9 @@ static int write_ref_sha1(struct ref_lock *lock,
> errno = EINVAL;
> return -1;
> }
> -
On Wed, Jan 21, 2015 at 3:38 PM, Jeff King wrote:
> On Wed, Jan 21, 2015 at 03:23:42PM -0800, Stefan Beller wrote:
>
>> There is another occurrence where we could have used write_str_in_full
>> (line 3107: write_in_full(lock->lk->fd, &term, 1)), so the current state
>> is inconsistent. This replac
On Wed, Jan 21, 2015 at 03:23:43PM -0800, Stefan Beller wrote:
> Now we only have one place where we need to touch the internals of
> the lock_file struct.
I wonder if the point of the previous patch would be more obvious if it
were combined with this one. I am OK leaving them separate, though.
On Wed, Jan 21, 2015 at 03:23:42PM -0800, Stefan Beller wrote:
> There is another occurrence where we could have used write_str_in_full
> (line 3107: write_in_full(lock->lk->fd, &term, 1)), so the current state
> is inconsistent. This replaces the only occurrence of write_str_in_full
> by write_in
On Wed, Jan 21, 2015 at 03:23:40PM -0800, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> t/t1400-update-ref.sh | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index 6805b9e..ea98b9b 100755
> ---
The 'lock_fd' is the same as 'lk->fd'. No need to store it twice so remove
it. You may argue this introduces more coupling as we need to know more
about the internals of the lock file mechanism, but this will be solved in
a later patch.
No functional changes intended.
Signed-off-by: Stefan Beller
Now we only have one place where we need to touch the internals of
the lock_file struct.
No functional changes intended.
Signed-off-by: Stefan Beller
---
refs.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 8281bed..311599b 100644
---
Signed-off-by: Stefan Beller
---
t/t1400-update-ref.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 6805b9e..ea98b9b 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -1065,4 +1065,32 @@ test_
By closing the file descriptors after creating the lock file we are not
limiting the size of the transaction by the number of available file
descriptors.
Signed-off-by: Stefan Beller
---
refs.c| 14 +-
t/t1400-update-ref.sh | 4 ++--
2 files changed, 15 insertions(+)
Instead of having to call write_in_full_to_lock_file twice get a formatted
string such that we only need to invoke writing to the lock file once.
This is helpful for the next patch when we only open the file descriptors
as needed. The lock file API has a reopen_lock_file which currently
doesn't op
There is another occurrence where we could have used write_str_in_full
(line 3107: write_in_full(lock->lk->fd, &term, 1)), so the current state
is inconsistent. This replaces the only occurrence of write_str_in_full
by write_in_full, so we only need to wrap write_in_full in the next patch.
No func
(reported as: git update-ref --stdin : too many open files, 2014-12-20)
First a test case is introduced to demonstrate the failure,
the patches 2-6 are little refactoring and the last patch
fixes the bug and also marks the bugs as resolved in the
test suite.
Unfortunately this applies on top of
"Kyle J. McKay" writes:
> So since I've not been able to get test 2 or 3 to core dump (even
> before 250b3c6c) I tend to believe you are correct in that the code
> thinks (incorrectly) that the result should fit within the buffer.
Thanks; let me steal your tests when I reroll.
--
To unsubscribe
Torsten Bögershausen writes:
> Hm, being one day offline and there are lots of ideas and
> new patches, I like that.
> I run these test under msys and cygwin on latest pu (a3dc223ff234481356c):
> ...
> (msys passes or skips all)
>
> Without digging further, these fail on my cygwin:
> ...
> I'm no
On Wed, Jan 21, 2015 at 04:28:00PM -0500, Ramkumar Ramachandra wrote:
> > So overall I think it has some promise, but I do not think it is quite
> > flexible enough yet for us to use day-to-day.
>
> The big negative is that it will probably never be. I'll try to look
> at the larger issues later
Johannes Schindelin writes:
>>> @@ -1488,8 +1501,13 @@ static const char *unpack(int err_fd, struct
>>> shallow_info *si)
>>>
>>> argv_array_pushl(&child.args, "index-pack",
>>> "--stdin", hdr_arg, keep_arg, NULL);
>>> - if (fsck_objects)
>>> -
Jeff King wrote:
> On Wed, Jan 21, 2015 at 12:01:27PM -0500, Ramkumar Ramachandra wrote:
>> +BreakBeforeBraces: Linux
>> [...]
>> +BreakBeforeBraces: Stroustrup
Oh, oops.
> - It really wants to break function declarations that go over the
>column limit, even though we often do not do so. I t
Junio C Hamano writes:
>> sub add_untracked_cmd {
>> -my @add = list_and_choose({ PROMPT => 'Add untracked' },
>> - list_untracked());
>> -if (@add) {
>> -system(qw(git update-index --add --), @add);
>> -say_n_paths('added', @add);
>>
Thanks, but please hold this off until the 2.3 final is tagged.
It is way too late for anything that is not a regression fix at this
point in this cycle, and changes that affect i18n are the last thing
we want to take late in the cycle because l10n people need time to
update the translations.
--
T
Alexander Kuleshov writes:
> If user selects 'add untracked' and there are no untracked files,
> "Add untracked>>" opens. But it does not make sense in this case,
> because there are no untracked files. So let's print message and
> exit from "add untracked" mode.
That reasoning makes perfect sen
On Wed, Jan 21, 2015 at 12:01:27PM -0500, Ramkumar Ramachandra wrote:
> Instead of manually eyeballing style in reviews, just ask all
> contributors to run their patches through [git-]clang-format.
Thanks for mentioning this; I hadn't seen the tool before.
I didn't see it mentioned here, but for
Christian Halstrick writes:
> Is it allowed that the git index contains a tree extension mentioning
> patch 'x/y/z' while the only entry in the index is a '.gitattributes'
> files in the root?
Depends on the definition of "mention", but it is not unexpected
that you see "x", "y", and "z" in the
Please, no top posting. It breaks the discussion flow.
From: "Max W"
Hi philip,
thanks for your reply.
You don't say which parts you believe should be identical, nor why.
I expected my representation to be identical, nevertheless what path
I have taken to come there. e.g.
git clone -b
git c
Identical to support in `git receive-pack for the config option
`receive.fsck.skiplist`, we now support ignoring given objects in
`git fsck` altogether.
This is extremely handy in case of legacy repositories where it would
cause more pain to change incorrect objects than to live with them
(e.g. a
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.ignor
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
Signed-off-by: Johannes Schindelin
---
Documentation/config.txt | 28
1 file changed, 28 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae6791d..cc4cd91 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -213
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by specifying `invalid-tag-name` and
`missing-tagger-entry` to the receive.fsck.error config setting.
Incidentally, the missing tagger warning is now really shown as a warning
(as opposed to being reported wit
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 | 9
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 warn=missing-email test to verify that "ignore"
is also accepted an
Signed-off-by: Johannes Schindelin
---
t/t5504-fetch-receive-strict.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
index 69ee13c..40c7557 100755
--- a/t/t5504-fetch-receive-strict.sh
+++ b/t/t5504-fetc
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
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.warn = missing-committer, but t
For example, missing emails in commit and tag objects can be demoted to
mere warnings with
git config receive.fsck.warn = missing-email
The value is actually a comma-separated list, and there is a
corresponding receive.fsck.error setting.
In case that the same key is listed in multiple r
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 "missing-email", the user might want to call `git config
receive.fsck.warn missing-email`).
Signed-off-by: Johannes Schindelin
---
fsck.c |
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
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
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
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
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
If user selects 'add untracked' and there are no untracked files,
"Add untracked>>" opens. But it does not make sense in this case, because there
are no untracked files. So let's print message and exit from "add untracked"
mode.
Signed-off-by: Alexander Kuleshov
---
git-add--interactive.perl |
On Wed, Jan 21, 2015 at 10:59:06AM -0800, Stefan Beller wrote:
> so I wanted to create a new test for large transactions, which should look
> like:
>
> run_with_limited_open_files () {
> (ulimit -n 64 && "$@")
> }
>
> test_lazy_prereq ULIMIT 'run_with_limited_ope
Signed-off-by: Alexander Kuleshov
---
builtin/bundle.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/bundle.c b/builtin/bundle.c
index 92a8a60..ca4a6a4 100644
--- a/builtin/bundle.c
+++ b/builtin/bundle.c
@@ -10,10 +10,10 @@
*/
static const char builtin_
Hi,
so I wanted to create a new test for large transactions, which should look like:
run_with_limited_open_files () {
(ulimit -n 64 && "$@")
}
test_lazy_prereq ULIMIT 'run_with_limited_open_files true'
test_expect_success ULIMIT 'large transaction
Duy Nguyen writes:
> On Wed, Jan 21, 2015 at 3:32 PM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> Helped-by: Eric Sunshine
>>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>> Signed-off-by: Junio C Hamano
>>> ---
>>
>> It appears that this hijacks a fixed name dir-mtime-test at the
Hi Junio,
On 2015-01-21 10:17, Junio C Hamano wrote:
> The documentation did not format well. Tentatively I added the
> attached fix-up on top of the series before merging to 'pu'.
>
> [...]
Sorry for that! I have to admit that I did not even build the documentation :-(
I incorporated your fi
Hi Junio,
On 2015-01-21 10:02, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> 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.fs
Hi Junio,
On 2015-01-21 09:59, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Signed-off-by: Johannes Schindelin
>> ---
>> t/t5504-fetch-receive-strict.sh | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/t/t5504-fetch-receive-strict.sh
>> b/t/t5504-f
Hi Junio,
On 2015-01-21 09:54, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>>
>> +if (starts_with(var, "receive.fsck.")) {
>> +if (fsck_severity.len)
>> +strbuf_addch(&fsck_severity, ',');
>> +strbuf_addf(&fsck_severity, "%s=%s", var + 13
Eric Wong wrote:
> Adding it to GITPERLLIB should work...
I tried everything including replicating the commands in the brew
formula that does the Right thing:
https://github.com/Homebrew/homebrew/blob/master/Library/Formula/git.rb
I'm clearly missing something. Can someone on Darwin tell us the r
Hi Junio,
On 2015-01-21 09:49, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> +static inline int substrcmp(const char *string, int len, const char *match)
>> +{
>> +int match_len = strlen(match);
>> +if (match_len != len)
>> +return -1;
>> +return memcmp(string,
Ramkumar Ramachandra wrote:
> Signed-off-by: Ramkumar Ramachandra
Junio: this isn't in the latest rebuild of pu; I wonder if you've
forgotten to pick it up.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info
René Scharfe wrote:
> However, even then struct declarations that are combined with variable
> declaration and initialization get mangled:
I'm pretty sure this is a bug in clang-format. It might be
semi-trivial to fix too.
Thanks for your inputs.
--
To unsubscribe from this list: send the line "u
Instead of manually eyeballing style in reviews, just ask all
contributors to run their patches through [git-]clang-format.
However, struct declarations that are combined with variable
declaration and initialization get mangled:
struct a {
int n;
const char
Is it allowed that the git index contains a tree extension mentioning
patch 'x/y/z' while the only entry in the index is a '.gitattributes'
files in the root?
I have such a repo in a bug report against JGit [1]. Native git has no
problems with this repo but JGit can't read such an index. I am
wond
On Wed, Jan 21, 2015 at 2:28 AM, Torsten Bögershausen wrote:
> Do you have a commit on a public repo ?
Just pushed to https://github.com/pclouds/git/commits/untracked-cache
> pu + your serious, or master + V3 + this delta ?
it's a replacement of nd/untracked-cache on 'pu'. You may need to
merge
On Wed, Jan 21, 2015 at 3:32 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Helped-by: Eric Sunshine
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> Signed-off-by: Junio C Hamano
>> ---
>
> It appears that this hijacks a fixed name dir-mtime-test at the root
> level of every project
Hello Junio,
2015-01-21 15:23 GMT+06:00 Junio C Hamano :
> Alexander Kuleshov writes:
>
>> Some of Makefile variables as TEST_PROGRAMS_NEED_X and BUILTIN_OBJS filled
>> directly by hand, let's collect it with the standard functions of 'make'
>> util.
>
> I am not sure if we want to do this.
>
>
Alexander Kuleshov writes:
> Some of Makefile variables as TEST_PROGRAMS_NEED_X and BUILTIN_OBJS filled
> directly by hand, let's collect it with the standard functions of 'make' util.
I am not sure if we want to do this.
$(wildcard) is a double-edged sword. It will grab any file that
matches
The documentation did not format well. Tentatively I added the
attached fix-up on top of the series before merging to 'pu'.
* The wildcard in "fsck.*" and "receive.fsck.*" may have made sense
back in v1 when the variables are unbounded set, but v2 fixes it
and we now have a known fixed set
These patches provides two minor typo fixes in pack-bitmap.c and
t/lib-terminal.sh
Alexander Kuleshov (2):
pack-bitmap: fix typo
t/lib-terminal.sh: fix typo
pack-bitmap.c | 2 +-
t/lib-terminal.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.3.0-rc1
--
To unsubscribe
Signed-off-by: Alexander Kuleshov
---
t/lib-terminal.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/lib-terminal.sh b/t/lib-terminal.sh
index 5184549..cd220e3 100644
--- a/t/lib-terminal.sh
+++ b/t/lib-terminal.sh
@@ -1,7 +1,7 @@
# Helpers for terminal output tests.
Signed-off-by: Alexander Kuleshov
---
pack-bitmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 0cd85f6..365f9d9 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -60,7 +60,7 @@ static struct bitmap_index {
struct ewah_bitmap *bl
These patches provides two minor typo fixes in pack-bitmap.c and
t/lib-terminal.sh
Alexander Kuleshov (2):
pack-bitmap: fix typo
t/lib-terminal.sh: fix typo
pack-bitmap.c | 2 +-
t/lib-terminal.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.3.0-rc1
--
To unsubscribe
Johannes Schindelin writes:
> 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`.
Makes sense, but I wonder if it makes sen
Johannes Schindelin writes:
> Signed-off-by: Johannes Schindelin
> ---
> t/t5504-fetch-receive-strict.sh | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
> index 69ee13c..d491172 100755
> --- a/t/t55
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.
Quite sensible.
>
> Signed-off-by: Johannes Schindelin
> ---
> fsck.c | 49 +++
Johannes Schindelin writes:
>
> + if (starts_with(var, "receive.fsck.")) {
> + if (fsck_severity.len)
> + strbuf_addch(&fsck_severity, ',');
> + strbuf_addf(&fsck_severity, "%s=%s", var + 13, value);
Wouldn't it be safer to use skip_prefix() that
Some of Makefile variables as TEST_PROGRAMS_NEED_X and BUILTIN_OBJS filled
directly by hand, let's collect it with the standard functions of 'make' util.
Signed-off-by: Alexander Kuleshov
---
Makefile | 134 +--
1 file changed, 2 insert
Johannes Schindelin writes:
> +static inline int substrcmp(const char *string, int len, const char *match)
> +{
> + int match_len = strlen(match);
> + if (match_len != len)
> + return -1;
> + return memcmp(string, match, len);
> +}
Is this what we call "starts_with()" the
Nguyễn Thái Ngọc Duy writes:
> Helped-by: Eric Sunshine
> Signed-off-by: Nguyễn Thái Ngọc Duy
> Signed-off-by: Junio C Hamano
> ---
It appears that this hijacks a fixed name dir-mtime-test at the root
level of every project managed by Git. Is that intended?
Shouldn't --use-untracked-cache
93 matches
Mail list logo
