On Mon, 8 Oct 2018, Jacob Keller wrote:
> On Mon, Oct 8, 2018 at 8:22 PM Jeff King wrote:
> >
> > On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
> >
> > > Julia Lawall writes:
> > >
> > > >> Doing the same for -S is much harder at the machinery level, as it
> > > >> performs
Derrick Stolee writes:
> I see these failures, too, but I believe they are due to
> ds/commit-graph-with-grafts not being merged to 'next' yet. The
> purpose of that branch is to fix these test breaks. The environment
> variable got merged a lot faster.
A separate "ping" would have helped me. W
Stephen & Linda Smith writes:
> Junio - I've been working this but would like your opinion on 7500, 7501 and
> now 7510.
>
> I note that the the commit tests have intermixed functionality. An example
> is
> signoff tests that are in the three tests I mentioned.
>
> I've been tempted mul
Junio C Hamano writes:
>> There is one crucial difference: the exit code.
>
> OK, and it was good that you explicitly said "with exit code 0" in
> the log message. Together with the idea to update the doc I floated
> earlier, this probably is worth documenting, too.
Heh, I am becoming sloppy in
Jeff King writes:
> I think that is the best we could do for "-S", though, which is
> inherently about counting hits.
>
> For "-G", we are literally grepping the diff. It does not seem
> unreasonable to add the ability to grep only "-" or "+" lines, and the
> interface for that should be pretty s
On Wed, Oct 03, 2018 at 06:32:06PM -0400, Noam Postavsky wrote:
> > which is admittedly pretty horrible, too, but at least resembles a
> > graph. I dunno.
>
> Yeah, but it's lossy, so it doesn't seem usable for the test. Maybe
> doubling up some characters?
>
> ** left
> R| **B-B-M-M. oct
Johannes Schindelin writes:
> Hi Junio,
>
> On Fri, 5 Oct 2018, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>> > From: Johannes Schindelin
>> >
>> > The 'edit' command can be used to cherry-pick a commit and then
>> > immediately drop out of the interactive
On Mon, Oct 8, 2018 at 8:22 PM Jeff King wrote:
>
> On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
>
> > Julia Lawall writes:
> >
> > >> Doing the same for -S is much harder at the machinery level, as it
> > >> performs its thing without internally running "diff" twice, but just
Junio C Hamano writes:
> Antonio Ospite writes:
>
>> Finally, add t7416-submodule-sparse-gitmodules.sh to verify that reading
>> from .gitmodules succeeds and that writing to it fails when the file is
>> not checked out.
>> ...
>> t/t7416-submodule-sparse-gitmodules.sh | 78
Antonio Ospite writes:
> Finally, add t7416-submodule-sparse-gitmodules.sh to verify that reading
> from .gitmodules succeeds and that writing to it fails when the file is
> not checked out.
> ...
> t/t7416-submodule-sparse-gitmodules.sh | 78 ++
This now triggers test-li
On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
> Julia Lawall writes:
>
> >> Doing the same for -S is much harder at the machinery level, as it
> >> performs its thing without internally running "diff" twice, but just
> >> counts the number of occurrences of 'foo'---that is suff
On Fri, Oct 05, 2018 at 09:54:13PM +0200, SZEDER Gábor wrote:
> Runtimes tend to fluctuate quite a bit more on Travis CI compared to
> my machine, but not this much, and it seems to be consistent so far.
>
> After scripting/querying the Travis CI API a bit, I found that from
> the last 100 static
On Sat, Oct 06, 2018 at 10:42:57AM +0200, René Scharfe wrote:
> > That's OK, too, assuming people would actually want to use it. I'm also
> > OK shipping this (with the "make -j" fix you suggested) and seeing if
> > anybody actually complains. I assume there are only a handful of people
> > runnin
On Mon, Oct 08, 2018 at 11:09:20AM -0700, Taylor Blau wrote:
> Attached is (what I anticipate to be) the final re-roll of my series to
> introduce 'core.alternateRefsCommand' and 'core.alternateRefsPrefixes'
> in order to limit the ".have" advertisement when pushing over protocol
> v1 to a reposit
On Mon, Oct 08, 2018 at 02:29:47PM -0400, Derrick Stolee wrote:
> > > > But I'm afraid it will take a while until I get around to turn it into
> > > > something presentable...
> > > Do you have the code pushed somewhere public where one could take a look?
> > > I
> > > Do you have the code pushed
On Mon, 8 Oct 2018 at 22:43, Derrick Stolee wrote:
>
> On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
> > Hi All,
> Hello, Ananya! Welcome.
>
> > I was searching through #leftovers and found this.
> > https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.co
Ævar Arnfjörð Bjarmason writes:
> Depending on how we're counting there's at least two.
I thought you were asking "why the special sentinel is not 0{40}?"
You counted the number of reasons why 0{40} is used to stand in for
a real value, but that was the number I didn't find interesting in
the sc
Stefan Beller writes:
> On Sun, Oct 7, 2018 at 1:07 PM Junio C Hamano wrote:
>>
>> Junio C Hamano writes:
>
>> > ...
>> > by general public and I do not have to explain the choice to the
>> > general public ;-)
>>
>> One thing that is more important than "why not 00 but 17?" to answer
>> is why
> Well, submodule-config.c has its implementation and another caller,
> which technically is outside submodule.c ;-)
i.e. there is a typo in my commit message.
I meant to say submodule-config.c
> repo_read_gitmodules
> has two more callers in unpack-trees.c these days, so perhaps we can
> do wit
On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
wrote:
>
> Since this data is stored in the .git directory, it makes sense for us
> to use the same hash algorithm for it as for everything else. Convert
> the remaining uses of SHA-1 to use the_hash_algo. Use GIT_MAX_RAWSZ for
> allocations. Rena
On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
wrote:
>
> With SHA-256, the length of the all-zeros object ID is longer. Add a
> function to git-submodule.sh to check if a full hex object ID is the
> all-zeros value, and use it to check the output we're parsing from git
> diff-files or diff-inde
Julia Lawall writes:
>> Doing the same for -S is much harder at the machinery level, as it
>> performs its thing without internally running "diff" twice, but just
>> counts the number of occurrences of 'foo'---that is sufficient for
>> its intended use, and more efficient.
>
> There is still the
On Mon, Oct 8, 2018 at 6:27 PM Stefan Beller wrote:
> On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
> wrote:
> > - if (line.len != 40)
> > - die("repack: Expecting 40 character sha1 lines only
> > from pack-objects.");
> > + if (line.len != the
SZEDER Gábor writes:
> There is certainly potential there. With a (very) rough PoC
> experiment, a 8MB bloom filter, and a carefully choosen path I can
> achieve a nice, almost 25x speedup:
>
> $ time git rev-list --count HEAD -- t/valgrind/valgrind.sh
> 6
>
> real0m1.563s
> user
On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
wrote:
>
> Replace uses of GIT_SHA1_RAWSZ with references to the_hash_algo to avoid
> dependence on a particular hash length.
Unlike the previous patches, this is dealing directly with packfiles,
which (I would think) carry their own hash function s
> - /* This knows the pack format -- the 20-byte trailer
> + /* This knows the pack format -- the hash trailer
> * follows immediately after the last object data.
While at it, fix the comment style?
With or without the nit addressed, this patch (and patches
1 and 4) are
Re
On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
wrote:
>
> Instead of using a hard-coded constant for the size of a hex object ID,
> switch to use the computed pointer from parse_oid_hex that points after
> the parsed object ID.
>
> Signed-off-by: brian m. carlson
> ---
> builtin/mktree.c | 2 +-
On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
wrote:
>
> Signed-off-by: brian m. carlson
> ---
> builtin/repack.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/repack.c b/builtin/repack.c
> index c6a7943d5c..e77859062d 100644
> --- a/builtin/repack.c
> ++
On Mon, Oct 08, 2018 at 10:03:51PM +, brian m. carlson wrote:
> This series introduces an EditorConfig file to help developers using any
> editor set their editor's settings in conformance with the Git Project's
> settings. This is helpful for developers who work on different projects
> with d
> +test_expect_success 'not writing gitmodules config file when it is not
> checked out' '
> +test_must_fail git -C super submodule--helper config
> submodule.submodule.url newurl
This only checks the exit code, do we also want to check for
test_path_is_missing .gitmodules ?
> +tes
This series introduces an EditorConfig file to help developers using any
editor set their editor's settings in conformance with the Git Project's
settings. This is helpful for developers who work on different projects
with different indentation standards to keep their work in sync.
Changes since
Contributors to Git use a variety of editors, each with their own
configuration files. Because C lacks the defined norms on how to indent
and style code that other languages, such as Ruby and Rust, have, it's
possible for various contributors, especially new ones, to have
configured their editor t
Now that we have two places where we set code formatting settings,
.editorconfig and .clang-format, it's possible that they could fall out
of sync. This is relatively unlikely, since we're not likely to change
the tab width or our preference for tabs, but just in case, add comments
to both files r
Replace several 40-based constants with references to GIT_MAX_HEXSZ or
the_hash_algo, as appropriate.
Signed-off-by: brian m. carlson
---
apply.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/apply.c b/apply.c
index e485fbc6bc..792ecea36a 100644
--- a/ap
Switch uses of GIT_SHA1_HEXSZ to use the_hash_algo so that they are
appropriate for the any given hash length.
Signed-off-by: brian m. carlson
---
refs/packed-backend.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.
Express the various constants used in terms of the_hash_algo.
Signed-off-by: brian m. carlson
---
pack-revindex.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/pack-revindex.c b/pack-revindex.c
index bb521cf7fb..3756ec71a8 100644
--- a/pack-revindex.c
+++ b/pack-re
Rename these structure members to "new_oid_prefix" and "old_oid_prefix".
Signed-off-by: brian m. carlson
---
apply.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/apply.c b/apply.c
index 792ecea36a..b9eb02ec12 100644
--- a/apply.c
With SHA-256, the length of the all-zeros object ID is longer. Add a
function to git-submodule.sh to check if a full hex object ID is the
all-zeros value, and use it to check the output we're parsing from git
diff-files or diff-index.
Signed-off-by: brian m. carlson
---
git-submodule.sh | 7 +++
Since this data is stored in the .git directory, it makes sense for us
to use the same hash algorithm for it as for everything else. Convert
the remaining uses of SHA-1 to use the_hash_algo. Use GIT_MAX_RAWSZ for
allocations. Rename various struct members, local variables, and a
function to be n
Signed-off-by: brian m. carlson
---
tag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tag.c b/tag.c
index 1db663d716..7445b8f6ea 100644
--- a/tag.c
+++ b/tag.c
@@ -144,7 +144,7 @@ int parse_tag_buffer(struct repository *r, struct tag
*item, const void *data, u
Use parse_oid_hex to compute a pointer instead of using GIT_SHA1_HEXSZ.
This simplifies the code and makes it independent of the hash length.
Signed-off-by: brian m. carlson
---
transport.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/transport.c b/transport.c
index
Signed-off-by: brian m. carlson
---
pack-bitmap-write.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pack-bitmap-write.c b/pack-bitmap-write.c
index fc82f37a02..6f0c78d6aa 100644
--- a/pack-bitmap-write.c
+++ b/pack-bitmap-write.c
@@ -37,7 +37,7 @@ struct bitmap_writer {
Instead of using GIT_SHA1_HEXSZ, use parse_oid_hex to compute a pointer
and use that in comparisons. This is both simpler to read and works
independent of the hash length. Update references to SHA-1 in the same
function to refer to object IDs instead.
Signed-off-by: brian m. carlson
---
builti
Convert all uses of the GIT_SHA1_HEXSZ to use the_hash_algo so that they
are appropriate for any given hash length.
Signed-off-by: brian m. carlson
---
upload-pack.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 62a1000f44..
Replace uses of GIT_SHA1_RAWSZ with references to the_hash_algo to avoid
dependence on a particular hash length.
Signed-off-by: brian m. carlson
---
packfile.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/packfile.c b/packfile.c
index 841b36182f..17f993b5bf 100644
---
This is the fifteenth series in the ongoing hash function transition.
This series includes several conversions to use the_hash_algo, combined
with some use of parse_oid_hex and GIT_MAX_RAWSZ. None of the
transformations here are especially surprising.
brian m. carlson (14):
pack-bitmap-write:
Instead of using a hard-coded constant for the size of a hex object ID,
switch to use the computed pointer from parse_oid_hex that points after
the parsed object ID.
Signed-off-by: brian m. carlson
---
builtin/mktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/m
Signed-off-by: brian m. carlson
---
builtin/repack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index c6a7943d5c..e77859062d 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -407,8 +407,8 @@ int cmd_repack(int argc, const cha
On Mon, Oct 08, 2018 at 10:53:52PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> It looks like we can add at least "pm" and "pl" to that pattern:
Sure. I didn't think we had any of those, but you've just proven me
wrong. I'll send a v3 shortly.
--
brian m. carlson: Houston, Texas, US
OpenPGP: http
Whenever a sparse checkout occurs, the existence of all blobs in the
index is verified, whether or not they are included or excluded by the
.git/info/sparse-checkout specification. This degrades performance,
significantly in the case of a partial clone, because a lazy fetch
occurs whenever the exis
On Mon, Oct 08 2018, brian m. carlson wrote:
> Contributors to Git use a variety of editors, each with their own
> configuration files. Because C lacks the defined norms on how to indent
> and style code that other languages, such as Ruby and Rust, have, it's
> possible for various contributors
This series introduces an EditorConfig file to help developers using any
editor set their editor's settings in conformance with the Git Project's
settings. This is helpful for developers who work on different projects
with different indentation standards to keep their work in sync.
Changes since
Contributors to Git use a variety of editors, each with their own
configuration files. Because C lacks the defined norms on how to indent
and style code that other languages, such as Ruby and Rust, have, it's
possible for various contributors, especially new ones, to have
configured their editor t
Now that we have two places where we set code formatting settings,
.editorconfig and .clang-format, it's possible that they could fall out
of sync. This is relatively unlikely, since we're not likely to change
the tab width or our preference for tabs, but just in case, add comments
to both files r
On Sun, Oct 7, 2018 at 1:07 PM Junio C Hamano wrote:
>
> Junio C Hamano writes:
> > ...
> > by general public and I do not have to explain the choice to the
> > general public ;-)
>
> One thing that is more important than "why not 00 but 17?" to answer
> is why a hardcoded number rather than a r
On 10/8/2018 2:10 PM, SZEDER Gábor wrote:
On Mon, Oct 08, 2018 at 12:57:34PM -0400, Derrick Stolee wrote:
Nice! These numbers make sense to me, in terms of how many TREESAME queries
we actually need to perform for such a query.
Yeah... because you didn't notice that I deliberately cheated :)
On 10/8/2018 10:19 AM, Ævar Arnfjörð Bjarmason wrote:
On Thu, Sep 06 2018, Ævar Arnfjörð Bjarmason wrote:
On Thu, Feb 01 2018, Ævar Arnfjörð Bjarmason wrote:
The GIT_FSMONITOR_TEST variable allows you to roundtrip the fsmonitor
codpath in the whole test suite. On both Debian & CentOS this
On Mon, Oct 08, 2018 at 12:57:34PM -0400, Derrick Stolee wrote:
> On 10/8/2018 12:41 PM, SZEDER Gábor wrote:
> >On Wed, Oct 03, 2018 at 03:18:05PM -0400, Jeff King wrote:
> >>I'm still excited about the prospect of a bloom filter for paths which
> >>each commit touches. I think that's the next big
Hi,
Attached is (what I anticipate to be) the final re-roll of my series to
introduce 'core.alternateRefsCommand' and 'core.alternateRefsPrefixes'
in order to limit the ".have" advertisement when pushing over protocol
v1 to a repository with configured alternates.
Not much has changed from last t
The recently-introduced "core.alternateRefsCommand" allows callers to
specify with high flexibility the tips that they wish to advertise from
alternates. This flexibility comes at the cost of some inconvenience
when the caller only wishes to limit the advertisement to one or more
prefixes.
For exa
To list alternate references, 'read_alternate_refs' creates a child
process running 'git for-each-ref' in the alternate's Git directory.
Prepare to run other commands besides 'git for-each-ref' by introducing
and moving the relevant code from 'read_alternate_refs' to
'fill_alternate_refs_command'.
When in a repository containing one or more alternates, Git would
sometimes like to list references from those alternates. For example,
'git receive-pack' lists the "tips" pointed to by references in those
alternates as special ".have" references.
Listing ".have" references is designed to make pus
From: Jeff King
None of the current callers use the refname parameter we pass to their
callbacks. In theory somebody _could_ do so, but it's actually quite
weird if you think about it: it's a ref in somebody else's repository.
So the name has no meaning locally, and in fact there may be duplicate
On Sat, Oct 6, 2018 at 5:10 PM Junio C Hamano wrote:
>
> As output made inside test_expect_{succcess,failure} are discarded
> by default and shown while debugging tests, there is no strong
> reason to use "grep -q" in our tests. I saw a few instances of
> "grep -q" added in this series including
On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
Hi All,
Hello, Ananya! Welcome.
I was searching through #leftovers and found this.
https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.com/
This patch address the task discussed in the above link.
The di
Hi All,
I was searching through #leftovers and found this.
https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.com/
This patch address the task discussed in the above link.
From: Ananya Krishan Maram
skip the #include of git-compat-util.h since all .c f
On 10/8/2018 12:41 PM, SZEDER Gábor wrote:
On Wed, Oct 03, 2018 at 03:18:05PM -0400, Jeff King wrote:
I'm still excited about the prospect of a bloom filter for paths which
each commit touches. I think that's the next big frontier in getting
things like "git log -- path" to a reasonable run-time
On Wed, Oct 03, 2018 at 03:18:05PM -0400, Jeff King wrote:
> I'm still excited about the prospect of a bloom filter for paths which
> each commit touches. I think that's the next big frontier in getting
> things like "git log -- path" to a reasonable run-time.
There is certainly potential there.
--
Are you a Business Owner or a Financial Consultant looking for a
Business loan or are you looking for a Personal loan. Our interest
rates are affordable, ranging from 3% to 4.5% interest rate per annual
depends on the loan type. If interested, please contact us today here
on email: lawrencec
On Mon, Oct 08, 2018 at 04:54:51PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> Thanks. I had ~400 runs of the tests I ran before and they were all
> >> OK. Now trying also with t1701 (which I hadn't noticed was a new
> >> test...).
> >
> > Ran that overnight with the same conditions as before. 2683
Hello,
Business proposition for you.
I have a client from Syrian who will like to invest with your
company. My client is willing to invest $4 Million. Can I have
your company website to show to my client your company so that
they will check and decide if they will invest there funds with
you
From: Derrick Stolee
When closing a multi-pack-index, we intend to close each pack-file
and free the struct packed_git that represents it. However, this
line was previously freeing the array of pointers, not the
pointer itself. This leads to a double-free issue.
Signed-off-by: Derrick Stolee
--
To increase coverage of the multi-pack-index feature, add a
GIT_TEST_MULTI_PACK_INDEX environment variable similar to other GIT_TEST_*
variables.
After creating the environment variable and running the test suite with it
enabled, I found a few bugs in the multi-pack-index implementation. These
are
From: Derrick Stolee
When repacking, we may remove pack-files. This invalidates the
multi-pack-index (if it exists). Previously, we removed the
multi-pack-index file before removing any pack-file. In some cases,
the repack command may load the multi-pack-index into memory. This
may lead to later
From: Derrick Stolee
The multi-pack-index feature is tested in isolation by
t5319-multi-pack-index.sh, but there are many more interesting
scenarios in the test suite surrounding pack-file data shapes
and interactions. Since the multi-pack-index is an optional
data structure, it does not make sen
On 10/8/2018 10:58 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Oct 08 2018, Derrick Stolee wrote:
On 10/8/2018 9:43 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Aug 28 2018, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The commit-graph feature is tested in isolation by
t5318-co
On Mon, Oct 08 2018, Derrick Stolee wrote:
> On 10/8/2018 9:43 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Tue, Aug 28 2018, Derrick Stolee via GitGitGadget wrote:
>>
>>> From: Derrick Stolee
>>>
>>> The commit-graph feature is tested in isolation by
>>> t5318-commit-graph.sh and t6600-test-reach.
On Fri, Sep 28 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 27 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Sep 27 2018, SZEDER Gábor wrote:
>>
>>> On Thu, Sep 27, 2018 at 03:53:24PM +0200, Ævar Arnfjörð Bjarmason wrote:
On Thu, Sep 27 2018, SZEDER Gábor wrote:
> T
From: Derrick Stolee
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has
an X.c.gcov
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has an
X.c.gcov file containing the coverage c
On 10/8/2018 9:43 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Aug 28 2018, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The commit-graph feature is tested in isolation by
t5318-commit-graph.sh and t6600-test-reach.sh, but there are many
more interesting scenarios involving commi
On Thu, Sep 06 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Feb 01 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> The GIT_FSMONITOR_TEST variable allows you to roundtrip the fsmonitor
>> codpath in the whole test suite. On both Debian & CentOS this breaks for
>> me:
>>
>> (cd t && GIT_FSMONITOR
unsubscribe git
On Tue, Aug 28 2018, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The commit-graph feature is tested in isolation by
> t5318-commit-graph.sh and t6600-test-reach.sh, but there are many
> more interesting scenarios involving commit walks. Many of these
> scenarios are covere
Hi Johannes
On 02/10/2018 14:50, Johannes Schindelin wrote:
Hi Phillip,
[sorry, I just got to this mail now]
Don't worry, I'm impressed you remembered it, I'd completely forgotten
about it.
On Sun, 6 May 2018, Phillip Wood wrote:
On 27/04/18 21:48, Johannes Schindelin wrote:
During a
unsubscribe git
Hello Git Team.
I would like to help to continue the books' translation to Brazilian
Portuguese and I don't know how to proceed. Thanks in advance for your
help.
Regards,
--
Thiago Saife
(11) 97236-8742
On Sun, 07 Oct 2018 08:44:20 +0900
Junio C Hamano wrote:
> Stefan Beller writes:
>
> >> static int module_config(int argc, const char **argv, const char *prefix)
> >> {
> >> + enum {
> >> + CHECK_WRITEABLE = 1
> >> + } command = 0;
> >
> > Can we have the default nam
On Sun, Oct 07 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> 1. We still have this check of objects/17/ in builtin/gc.c today. Why
>>objects/17/ and not e.g. objects/00/ to go with other 000* magic such
>>as the SHA-1?d Stat
90 matches
Mail list logo
