On Wed, Apr 11, 2018 at 12:50 AM, Junio C Hamano wrote:
> Chris Maes writes:
>
>> Is there any hope from here that anyone will pick up this / these
>> changes? Will anyone else be assigned the main responsible for this
>> git-gui repository?
>>
>> Just hoping to revive the discussion here, since
On 4 June 2018 at 23:55, Ævar Arnfjörð Bjarmason wrote:
> I think this makes more sense instead of this fix:
[...]
> -void refspec_item_init(struct refspec_item *item, const char *refspec, int
> fetch)
> +int refspec_item_init(struct refspec_item *item, const char *refspec, int
> fetch)
> {
>
On 04/06/18 18:06, Max Kirillov wrote:
> On Mon, Jun 04, 2018 at 01:31:58PM +0900, Junio C Hamano wrote:
>> Max Kirillov writes:
>>> + size_t n = xread(0, buf, chunk_length);
>>> + if (n < 0)
>>> + die_errno("Reading request failed");
>>
>> n that is of
> On 04 Jun 2018, at 06:53, Junio C Hamano wrote:
>
> A release candidate Git v2.18.0-rc1 is now available for testing
> at the usual places. It is comprised of 842 non-merge commits
> since v2.17.0, contributed by 65 people, 20 of which are new faces.
>
> ...
>
> * The new
Add a test function helper, test_translate, that will produce its first
argument if the hash in use is SHA-1 and the second if its argument is
NewHash. Implement a mode that can read entries from a file as well for
reusability across tests.
For the moment, use the length of the empty blob to
If the hash we're using is 32 bytes in size, attempting to insert a
20-byte object name won't work. Since these are synthesized objects
that are almost all zeros, look them up in a translation table.
Signed-off-by: brian m. carlson
---
t/t-basic.sh | 13 +++--
1 file changed, 7
This is next in the series of improvements to make tests
hash-independent.
Introduced here is a test helper, test_translate, that allows lookups in
tests based on the hash algorithm in use. Alternatives are either
specified inline (the former for SHA-1, the latter for NewHash), or
(more
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.
Signed-off-by: brian m. carlson
---
t/t0002-gitfile.sh | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index
Instead of hard-coding a 40-based constant, split the output of
for-each-ref and for-each-reflog by field.
Signed-off-by: brian m. carlson
---
t/t1406-submodule-ref-store.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t1406-submodule-ref-store.sh
Instead of hard-coding a 40-based constant, split the output of
for-each-ref and for-each-reflog by field.
Signed-off-by: brian m. carlson
---
t/t1407-worktree-ref-store.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t1407-worktree-ref-store.sh
Use the ZERO_OID variable to express the all-zeros object ID so that it
works with hash algorithms of all sizes.
Signed-off-by: brian m. carlson
---
t/t0027-auto-crlf.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t0027-auto-crlf.sh
Compute test values of the appropriate size instead of hard-coding
40-character values. Rename the echo20 function to echoid, since the
values may be of varying sizes.
Signed-off-by: brian m. carlson
---
t/t0064-sha1-array.sh | 49 ---
1 file changed, 27
Instead of hard-coding a 40-based constant, split the output of
for-each-ref and for-each-reflog by field.
Signed-off-by: brian m. carlson
---
t/t1405-main-ref-store.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t1405-main-ref-store.sh b/t/t1405-main-ref-store.sh
Compute the size of the tree and commit objects we're creating by
checking for the size of an object ID and computing the resulting sizes
accordingly.
Signed-off-by: brian m. carlson
---
t/t1006-cat-file.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Switch a hard-coded all-zeros object ID to use a variable instead.
Signed-off-by: brian m. carlson
---
t/t1400-update-ref.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index e1fd0f0ca8..ffaadf5f2d 100755
---
On Mon, Jun 04, 2018 at 03:39:26PM +0200, SZEDER Gábor wrote:
> On rare occasions the given pattern occurs not only in the commit
> message but in the GPG signature as well, and after it's replaced in
> the signature the resulting signature becomes invalid, GPG will report
> CRC error and that it
On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote:
Thanks for the comments, I will do the things you proposed,
or try to and get back later if there are any issues. Some
notes below.
> On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote:
> Since this is slightly less efficient,
تحية طيبة،
نحن نعيد بناء العراق بعد سنوات من الصراعات ونحن ندعو
عليك أن تأخذ العقود. نحن مصممون على شراء منتجاتك
بكميات كبيرة ، لاستخدامها في جميع محافظاتنا الثمانية عشر
(المحافظات) حيث أن مهمة إعادة بناء العراق تغطي كل قطاع واحد
وجانب مجتمعنا. سنقوم بإرسال معلومات منتجاتك إلى
مكتب المشروع
On Mon, Jun 04 2018, Martin Ågren wrote:
> We allocate a `struct refspec_item` on the stack without initializing
> it. In particular, its `dst` and `src` members will contain some random
> data from the stack. When we later call `refspec_item_clear()`, it will
> call `free()` on those pointers.
`git pull` understands some options of `git fetch` which then uses in
its operation. The documentation of `git pull` doesn't reflect this
clearly, showing options that are not yet supported (e.g. `--deepen`)
and omitting options that are supported (e.g. `--prune`).
Make the documentation
`git pull`'s documentation mentions that `--edit` can be used with short
option `-e`. But `git pull` doesn't understand `-e`.
To make things consistent, teach `git pull` `-e` for `--edit`
Signed-off-by: Rafael Ascensão
---
builtin/pull.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
A regression introduced in 8462ff43e42ab67cecd16fdfb59451a53cc8a945 caused
autocrlf rewrites to produce a warning message despite setting safecrlf=false.
Signed-off-by: Anthony Sottile
---
config.c| 2 +-
t/t0020-crlf.sh | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
On Mon, Jun 04, 2018 at 11:05:43PM +0800, Xiaolong Ye wrote:
> When users specify the commit range with 'Z..C' pattern for format-patch, all
> the parents of Z (including Z) would be marked as UNINTERESTING which would
> prevent revision walk in prepare_bases from getting the prerequisite commits,
On 04.06.18 17:43, Anthony Sottile wrote:
> On Mon, Jun 4, 2018 at 12:55 AM, Torsten Bögershausen wrote:
>>
>> Does the following patch fix your problem ?
>>
>> diff --git a/config.c b/config.c
>> index 6f8f1d8c11..c625aec96a 100644
>> --- a/config.c
>> +++ b/config.c
>> @@ -1233,7 +1233,7 @@
On Mon, Jun 04, 2018 at 12:18:59PM -0400, Martin-Louis Bright wrote:
> Why must the credentials must be deleted after receiving the 401 (or
> any) error? What's the rationale for this?
Because Git only tries a single credential per invocation. So if a
helper provides one, it doesn't prompt. If
On Mon, Jun 04, 2018 at 09:47:18AM -0400, Theodore Y. Ts'o wrote:
> For people who are doing real work on git repos, other commands that
> we very much care about include "git log --author=", "git
> tag --contains", "git blame", etc.
I do not see how those, or anything but git clone (and even
From: Leif Middelschulte
Since submodules are treated similarly to ordinary files (i.e. not as 'dumb'
pointers), an automatic merge should be mentioned if the user asks for it.
Just as it is mentioned for oridnary files.
Signed-off-by: Leif Middelschulte
---
merge-recursive.c | 10 ++
From: Leif Middelschulte
The provided patch is in response to Elijah Newren's [0] and Junio Hamano's [1]
comments on my prior patch regarding the reasoning and implementation of a user
notification during (clean) merges of submodules.
[0]
Hello
RE:BUSINESS INQUIRY/ PROPOSAL
How are you doing today, i hope this mail finds you in a good and convenient
position!
My name is ZHAO DONG. I am the senior manager for Procurement, Hong Kong
Refining Company (Sinopec Group Inc) I have been mandated to source crude oil
from Libya for
On 06/04, Martin Ågren wrote:
> We allocate a `struct refspec_item` on the stack without initializing
> it. In particular, its `dst` and `src` members will contain some random
> data from the stack. When we later call `refspec_item_clear()`, it will
> call `free()` on those pointers. So if the
On 06/02, Elijah Newren wrote:
> On Fri, Jun 1, 2018 at 10:03 PM, Duy Nguyen wrote:
> > On Fri, Jun 1, 2018 at 8:34 PM, Elijah Newren wrote:
> >> On Fri, Jun 1, 2018 at 9:11 AM, Nguyễn Thái Ngọc Duy
> >> wrote:
> >>> This is more of a bug report than an actual fix because I'm not sure
> >>> if
Introduce the new files fetch-negotiator.{h,c}, which contains an API
behind which the details of negotiation are abstracted. Currently, only
one algorithm is available: the existing one.
This patch is written to be more easily reviewed: static functions are
moved verbatim from fetch-pack.c to
This enables the calculation of was_common and the invocation to
mark_common() to be abstracted into a single call to the negotiator API
(to be introduced in a subsequent patch).
Signed-off-by: Jonathan Tan
---
fetch-pack.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Reduce the number of global variables by making the priority queue and
the count of non-common commits in it local, passing them as a struct to
various functions where necessary.
This also helps in the case that fetch_pack() is invoked twice in the
same process (when tag following is required
In do_fetch_pack_v2(), rev_list_insert_ref_oid() is invoked before
everything_local(). This means that if we have a commit that is both our
ref and their ref, it would be enqueued by rev_list_insert_ref_oid() as
SEEN, and since it is thus already SEEN, everything_local() would not
enqueue it.
If
Both Stefan and Junio have suggested in [1] that I create a new
negotiation API first, then implement a new algorithm, and I perhaps too
optimistically said that doing it all at once should be fine. Extracting
the API turns out to be more difficult than expected. Here are the
patches that do that,
If tag following is required when using a transport that does not
support tag following, fetch_pack() will be invoked twice in the same
process, necessitating a clearing of the object flags used by
fetch_pack() sometime during the second invocation. This is currently
done in find_common(), which
When "ACK %s ready" is received, find_common() clears rev_list in an
attempt to stop further "have" lines from being sent [1]. This appears
to work, despite the invocation to mark_common() in the "while" loop.
Though it is possible for mark_common() to invoke rev_list_push() (thus
making rev_list
On Mon, Jun 4, 2018 at 6:08 AM, Phillip Wood wrote:
> On 01/06/18 21:03, Eric Sunshine wrote:
>> On Fri, Jun 1, 2018 at 1:46 PM, Phillip Wood
>> wrote:
>>> + } elsif ($mode eq ' ' or $_ eq "\n") {
>>
>> Based upon a very cursory read of parts of git-add-interactive.perl,
>> do I
On Mon, Jun 04, 2018 at 01:31:58PM +0900, Junio C Hamano wrote:
> Max Kirillov writes:
>> +size_t n = xread(0, buf, chunk_length);
>> +if (n < 0)
>> +die_errno("Reading request failed");
>
> n that is of type size_t is unsigned and cannot be negative
Sorry I forgot to --in-reply-to the previous version [1]
[1]
https://public-inbox.org/git/20180524162504.158394-1-dsto...@microsoft.com/T/#u
On 6/4/2018 12:52 PM, Derrick Stolee wrote:
Thanks for the feedback on v3. There were several small cleanups, but
perhaps the biggest change is the
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
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
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 5faecae2a7..47fdd62e88 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -982,6 +982,12 @@ int
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
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 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
---
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 39 +--
commit-graph.c | 15 +++
commit-graph.h | 7 +++
3 files changed, 23 insertions(+), 38 deletions(-)
diff --git a/builtin/commit-graph.c
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,
The commit-graph file is a very helpful feature for speeding up git
operations. In order to make it more useful, make it possible to
write the commit-graph file during standard garbage collection
operations.
Add a 'gc.commitGraph' config setting that triggers writing a
commit-graph file after any
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'.
Signed-off-by: Derrick Stolee
---
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 | 17 +
t/t5318-commit-graph.sh | 7 +++
2 files changed, 24 insertions(+)
diff
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
---
commit-graph.c
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
The 'verify' subcommand must compare the commit content parsed from the
commit-graph 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 directly from
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 +++---
1 file changed, 15
Thanks for the feedback on v3. There were several small cleanups, but
perhaps the biggest change is the addition of "commit-graph: use
string-list API for input" which makes "commit-graph: add '--reachable'
option" much simpler.
The inter-diff is still reasonably large, but I'll send it in a
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
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
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
---
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 +---
1 file
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
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
@@ -51,8 +51,11 @@ static
Why must the credentials must be deleted after receiving the 401 (or
any) error? What's the rationale for this?
On Mon, Jun 4, 2018 at 10:47 AM, Jeff King wrote:
> On Mon, Jun 04, 2018 at 05:26:35AM -0700, lars.schnei...@autodesk.com wrote:
>
>> From: Lars Schneider
>>
>> If a Git HTTP server
Hello,
This is Ms Julian Smith and i am from Invictus Group Co.,LTD in United Kingdom.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial
order.
Best Regards,
Julian
On Mon, Jun 4, 2018 at 12:55 AM, Torsten Bögershausen wrote:
>
> Does the following patch fix your problem ?
>
> diff --git a/config.c b/config.c
> index 6f8f1d8c11..c625aec96a 100644
> --- a/config.c
> +++ b/config.c
> @@ -1233,7 +1233,7 @@ static int git_default_core_config(const char *var,
>
When users specify the commit range with 'Z..C' pattern for format-patch, all
the parents of Z (including Z) would be marked as UNINTERESTING which would
prevent revision walk in prepare_bases from getting the prerequisite commits,
thus `git format-patch --base Z..C` won't be able to generate
the
On Mon, Jun 04, 2018 at 04:18:17PM +0200, SZEDER Gábor wrote:
>
> > * jk/index-pack-maint (2018-06-01) 2 commits
> > (merged to 'next' on 2018-06-04 at c553a485e8)
> > + index-pack: handle --strict checks of non-repo packs
> > + prepare_commit_graft: treat non-repository as a noop
> >
> >
On Mon, Jun 04, 2018 at 05:26:35AM -0700, lars.schnei...@autodesk.com wrote:
> From: Lars Schneider
>
> If a Git HTTP server responds with 401 or 407, then Git tells the
> credential helper to reject and delete the credentials. In general
> this is good.
>
> However, in certain automation
On Mon, Jun 4, 2018 at 12:46 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Shallow clones with --shallow-since or --shalow-exclude work by
>> running rev-list to get all reachable commits, then draw a boundary
>> between reachable and unreachable and send "shallow" requests
We allocate a `struct refspec_item` on the stack without initializing
it. In particular, its `dst` and `src` members will contain some random
data from the stack. When we later call `refspec_item_clear()`, it will
call `free()` on those pointers. So if the call to `parse_refspec()` did
not assign
On Mon, Jun 4, 2018 at 1:32 PM, Derrick Stolee wrote:
> On 6/2/2018 12:38 AM, Duy Nguyen wrote:
>>
>> On Thu, May 24, 2018 at 6:25 PM, Derrick Stolee
>> wrote:
>>>
>>> + if (i && oidcmp(_oid, _oid) >= 0)
>>> + graph_report("commit-graph has incorrect OID
>>>
On 4 June 2018 at 14:57, 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 branches, but I am
Good day,
This is a personal email directed to you for your consideration alone,
I request that it remain and be treated as such only. My name is Mr.
Mallam Tanko. I am working with one of the prime banks here in Burkina
Faso. Here in this bank existed a dormant account for many years,
which
> * jk/index-pack-maint (2018-06-01) 2 commits
> (merged to 'next' on 2018-06-04 at c553a485e8)
> + index-pack: handle --strict checks of non-repo packs
> + prepare_commit_graft: treat non-repository as a noop
>
> "index-pack --strict" has been taught to make sure that it runs the
> final
On Mon, Jun 04, 2018 at 10:57:30PM +0900, Junio C Hamano wrote:
> * jk/index-pack-maint (2018-06-01) 2 commits
> (merged to 'next' on 2018-06-04 at c553a485e8)
> + index-pack: handle --strict checks of non-repo packs
> + prepare_commit_graft: treat non-repository as a noop
>
> "index-pack
On 4 June 2018 at 05:40, Junio C Hamano wrote:
Rick van Hattem writes:
> > The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check
> > moot. The result (at least for me) is that zsh segfaults because of all the
> > variables it's unsetting.
> > ---
>
> Overlong line, lack of
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 branches, but I am still holding onto them.
Generally I try to avoid sending
On Mon, Jun 04, 2018 at 12:16:16AM +0200, Peter Backes wrote:
>
> Verifying the commit ID by itself wouldn't be any less efficient than
> before. Admitteldly, it wouldn't verify the author and authordate
> integrity anymore without additional work. That would be some overhead,
> sure, and
A couple of test scripts create forged GPG signed commits or tags to
check that such forgery can't fool various git commands' signature
verification. All but one of those test scripts are prone to
occasional failures because the forgery creates a bogus GPG signature,
and git commands error out
The two tests 'detect fudged signature' and 'detect fudged signature
with NUL' in 't7510-signed-commit.sh' check that 'git verify-commit'
errors out when encountering a forged commit, but they do so by
running
! git verify-commit ...
Use 'test_must_fail' instead, because that would catch
"Robert P. J. Day" writes:
> one thing i don't see there, and it's based on an observation someone
> once made (i believe on this list), is that even if there is
> absolutely no ambiguity in a command, even if there are no pathspec
> arguments, it's still worthwhile to add a trailing "--":
>
>
On 6/2/2018 8:39 AM, Jakub Narebski wrote:
Derrick Stolee writes:
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
On 6/2/2018 2:03 PM, Jakub Narebski wrote:
Derrick Stolee writes:
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.
I think you meant here
The commit-graph tests should be checking that normal Git operations
succeed and have matching output with and without the commit-graph
feature enabled. However, the test was toggling 'core.graph' instead
of the correct 'core.commitGraph' variable.
Reported-by: Jakub Narebski
Signed-off-by:
From: Lars Schneider
If a Git HTTP server responds with 401 or 407, then Git tells the
credential helper to reject and delete the credentials. In general
this is good.
However, in certain automation environments it is not desired to remove
credentials automatically. This is in particular the
Hi Peter,
(lost the cc's)
From: "Peter Backes"
On Sun, Jun 03, 2018 at 11:28:43PM +0100, Philip Oakley wrote:
It is here that Article 6 kicks in as to whether the 'organisation' can
retain the data and continue to use it.
Article 6 is not about continuing to use data. Article 6 is about
On Sun, Jun 03, 2018 at 06:35:44AM -0400, Robert P. J. Day wrote:
> > > if (for some weird reason) i wanted to define a multi-level
> > > subsection,
> >
> > You can't, there are no multi-level subsections, see above.
>
> no, i *get* that, what i was asking was if i wanted to simulate or
>
On 6/2/2018 12:17 PM, Jakub Narebski wrote:
Derrick Stolee writes:
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.
All right, so we have one config variable to
On 6/2/2018 11:52 AM, Jakub Narebski wrote:
Derrick Stolee writes:
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
On 6/2/2018 8:23 AM, Jakub Narebski wrote:
Derrick Stolee writes:
While iterating through the commit parents, perform the generation
number calculation and compare against the value stored in the
commit-graph.
All right, that's good.
What about commit-graph files that have
On 6/2/2018 12:38 AM, Duy Nguyen wrote:
On Thu, May 24, 2018 at 6:25 PM, Derrick Stolee wrote:
+ if (i && oidcmp(_oid, _oid) >= 0)
+ graph_report("commit-graph has incorrect OID order: %s then
%s",
+oid_to_hex(_oid),
+
On 6/2/2018 5:19 PM, Jakub Narebski wrote:
Derrick Stolee writes:
Do we have a way to run individual steps of the test suite? I am
unfamiliar with that process.
The t/README describes three such ways in "Skipping Tests" section:
- GIT_SKIP_TESTS environment variable, which can either can
On Sun, 3 Jun 2018, Philip Oakley wrote:
> From: "Robert P. J. Day"
> > On Sun, 3 Jun 2018, Thomas Gummerer wrote:
> >> --get-regex works as the parse-option API allows abbreviations of
> >> the full option to be specified as long as the abbreviation is
> >> unambiguos. I don't know if this is
Nguyễn Thái Ngọc Duy writes:
> Shallow clones with --shallow-since or --shalow-exclude work by
> running rev-list to get all reachable commits, then draw a boundary
> between reachable and unreachable and send "shallow" requests based on
> that.
>
> The code does miss one corner case: if
On Mon, 4 Jun 2018, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > i realize that, when you "git stash push", stash graciously
> > saves the branch you were on as part of the commit message, but
> > does any subsequent stash operation technically *need* that branch
> > name?
>
> It
On 01/06/18 21:03, Eric Sunshine wrote:
> On Fri, Jun 1, 2018 at 1:46 PM, Phillip Wood
> wrote:
>> recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p:
>> calculate offset delta for edited patches", 2018-03-05) required all
>> context lines to start with a space, empty lines are not
On 6/2/2018 1:13 AM, Jeff King wrote:
On Sat, Jun 02, 2018 at 06:41:06AM +0200, Duy Nguyen wrote:
On Mon, Mar 26, 2018 at 4:31 PM, wrote:
+static inline void assert_in_array(const struct json_writer *jw)
+{
+ if (!jw->open_stack.len)
+ die("json-writer: array: missing
It was <2018-05-30 śro 17:37>, when Duy Nguyen wrote:
> On Fri, May 25, 2018 at 12:48:42PM +0200, Łukasz Stelmach wrote:
>> "git remote update" accepts both groups and single remotes.
>>
>> Signed-off-by: Łukasz Stelmach
>> ---
>> contrib/completion/git-completion.bash | 2 +-
>> 1 file
Dear friend
I am contacting you on a business deal of $17.5 Million US Dollars,
ready for transfer into your account
if we make this claim, we will share it 60%/40%.
100% risk free and it will be legally backed up with government
approved If you are interested reply for more details.
Best
1 - 100 of 102 matches
Mail list logo
