Carlo Marcelo Arenas Belón writes:
> Signed-off-by: Carlo Marcelo Arenas Belón
> ---
> xdiff/xdiffi.c | 2 +-
> xdiff/xemit.c | 6 +++---
> xdiff/xhistogram.c | 6 +++---
> xdiff/xmacros.h| 4 +---
> xdiff/xprepare.c | 2 +-
> 5 files changed, 9 insertions(+), 11 deletions(-)
Jonathan Tan writes:
> + GIT_TRACE_PACKET="$(pwd)/log" test_must_fail git -C http_child \
> + -c protocol.version=2 \
> + fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&
Because test_must_fail is a shell function, the above is not a
correct way to say "I want
Ævar Arnfjörð Bjarmason writes:
> I've set this up at https://gitlab.com/git-vcs
>
> The /git namespace was taken (and I asked GitLab support if it was
> stale, they said no). Also tried /git-scm and /gitscm, ditto. So I
> settled on /git-vcs (version control system).
Squatters X-<. Thanks.
>
it is already defined whenever "sys/param.h" is available
Signed-off-by: Carlo Marcelo Arenas Belón
---
sha256/block/sha256.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sha256/block/sha256.c b/sha256/block/sha256.c
index 18350c161a..0d4939cc2c 100644
--- a/sha256/block/sha256.c
+++
Signed-off-by: Carlo Marcelo Arenas Belón
---
xdiff/xdiffi.c | 2 +-
xdiff/xemit.c | 6 +++---
xdiff/xhistogram.c | 6 +++---
xdiff/xmacros.h| 4 +---
xdiff/xprepare.c | 2 +-
5 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index
otherwise will warn on platforms where it is already defined (macOS)
convert the internal version from xdiff to a common one from
the compatibilty header additionally
this macro is commonly defined in system headers (usually )
but if it is not define it here so it can be used elsewhere
Signed-off-by: Carlo Marcelo Arenas Belón
---
git-compat-util.h | 5 +
sha256/block/sha256.c | 3 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git
Ben Peart writes:
> On 10/19/2018 1:11 PM, Jeff King wrote:
>> On Fri, Oct 19, 2018 at 01:10:34PM -0400, Eric Sunshine wrote:
>>
>>> On Fri, Oct 19, 2018 at 12:46 PM Jeff King wrote:
On Fri, Oct 19, 2018 at 12:36:44PM -0400, Eric Sunshine wrote:
> How does the user reverse this for a
Nguyễn Thái Ngọc Duy writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 552827935a..244560a35e 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2,8 +2,9 @@ CONFIGURATION FILE
> --
>
> The Git configuration file
Nguyễn Thái Ngọc Duy writes:
> Subject: Re: [PATCH v3 2/8] Add a place for (not) sharing stuff between
> worktrees
"a place"? Missing "in $GIR_DIR" in the descrition made me read the
above three times before getting what it wanted to say.
My attempt to improve it, which admittedly is not
Nguyễn Thái Ngọc Duy writes:
> __gitcomp_builtin() has the main completion list provided by
>
> git xxx --git-completion-helper
>
> but the caller can also add extra options that is not provided by
> --git-completion-helper. The only call site that does this is "git
> difftool" completion.
Duy Nguyen writes:
>> freshen_shared_index(base_path, 0);
>> merge_base_index(istate);
>> post_read_index_from(istate);
>> - free(base_path);
>> trace_performance_leave("read cache %s", base_path);
>> + free(base_path);
>
> Oops. Ack.
Thanks, both.
Torsten Bögershausen writes:
> Initializing a variable to "BAD" in the beginning can be a good thing
> for two reasons:
> - There is a complex if-elseif chain, which should set retval
> in any case, this is at least what I expect taking a very quick look at the
> code:
> ...
> # The second
Jeff King writes:
> On Fri, Oct 19, 2018 at 04:19:28PM -0700, stead...@google.com wrote:
>
>> diff --git a/builtin/archive.c b/builtin/archive.c
>> index e74f675390..dd3283a247 100644
>> --- a/builtin/archive.c
>> +++ b/builtin/archive.c
>> @@ -45,7 +45,10 @@ static int run_remote_archiver(int
Joey Hess writes:
> How about changing the documentation to something like this to make
> more explicit what it does.
>
>--with-tree=
>Treat all files in the as if they were present in the
> index.
>When using --error-unmatch to expand the user supplied (i.e.
>
Jonathan Nieder writes:
> Stefan Beller wrote:
>
>> Maybe for now we can do with just an update of the documentation/bugs
>> section and say we cannot move files in and out of submodules?
>
> I think we have some existing logic to prevent "git add"-ing a file
> within a submodule to the
Instead of using hard-coded constants for object sizes, use
the_hash_algo to look them up. In addition, use a function call to look
up the object ID version and produce the correct value. For now, we use
version 1, which means to use the default algorithm used in the rest of
the repository.
Since we're going to have multiple hash algorithms to test, it makes
sense to share as much of the test code as possible. Convert the sha1
helper for the test-tool to be generic and move it out into its own
module. This will allow us to share most of this code with our NewHash
implementation.
There are several ways we might refer to a hash algorithm: by name, such
as in the config file; by format ID, such as in a pack; or internally,
by a pointer to the hash_algos array. Provide functions to look up hash
algorithms based on these various forms and return the internal constant
used for
We already have OpenSSL routines available for SHA-1, so add routines
for SHA-256 as well.
On a Core i7-6600U, this SHA-256 implementation compares favorably to
the SHA1DC SHA-1 implementation:
SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks)
SHA-256: 165 MiB/s (64 byte chunks); 408
In 183a638b7d ("hashcmp: assert constant hash size", 2018-08-23), we
modified hashcmp to assert that the hash size was always 20 to help it
optimize and inline calls to memcmp. In a future series, we replaced
many calls to hashcmp and oidcmp with calls to hasheq and oideq to
improve inlining
Add a utility (which is less for the testsuite and more for developers)
that can compute hash speeds for whatever hash algorithms are
implemented. This allows developers to test their personal systems to
determine the performance characteristics of various algorithms.
Signed-off-by: brian m.
The transition plan anticipates us using a syntax such as "^{sha1}" for
disambiguation. Since this is a syntax some people will be typing a
lot, it makes sense to provide a short, easy-to-type syntax. Omitting
the dash doesn't create any ambiguity; however, it does make the syntax
shorter and
This series provides a functional SHA-256 implementation and wires it
up, along with some housekeeping patches to make it suitable for
testing.
Changes from v2:
* Improve commit messages to include timing and performance information.
* Improve commit messages to be less ambiguous and more
Generally, one gets better performance out of cryptographic routines
written in assembly than C, and this is also true for SHA-256. In
addition, most Linux distributions cannot distribute Git linked against
OpenSSL for licensing reasons.
Most systems with GnuPG will also have libgcrypt, since it
We have in the past had some unfortunate endianness issues with some
SHA-1 implementations we ship, especially on big-endian machines. Add
an explicit test using the test helper to catch these issues and point
them out prominently. This test can also be used as a staging ground
for people
Currently, we have functions that turn an arbitrary SHA-1 value or an
object ID into hex format, either using a static buffer or with a
user-provided buffer. Add variants of these functions that can handle
an arbitrary hash algorithm, specified by constant. Update the
documentation as well.
SHA-1 is weak and we need to transition to a new hash function. For
some time, we have referred to this new function as NewHash. Recently,
we decided to pick SHA-256 as NewHash.
Add a basic implementation of SHA-256 based off libtomcrypt, which is in
the public domain. Optimize it and
There is one place we need the hash algorithm block size: the HMAC code
for push certs. Expose this constant in struct git_hash_algo and expose
values for SHA-1 and for the largest value of any hash.
Signed-off-by: brian m. carlson
---
cache.h | 4
hash.h | 3 +++
sha1-file.c | 2
Derrick Stolee writes:
> On 10/19/2018 1:24 AM, Junio C Hamano wrote:
>> "Derrick Stolee via GitGitGadget" writes:
>>
>>> We can also re-run the performance tests from commit 4fbcca4e
>>> "commit-reach: make can_all_from_reach... linear".
>>>
>>> Performance was measured on the Linux repository
Matthew DeVore writes:
>> It is more like "this is a set operation across commits. We also
>> show objects that are reachable from the commits in the resulting
>> set and are not reachable from the commits in the set that were
>> excluded when --objects option is given".
>>
> That would be
Jeff King writes:
> On Wed, Oct 10, 2018 at 11:59:38AM -0400, Ben Peart wrote:
>
>> +static unsigned long load_cache_entries_threaded(struct index_state
>> *istate, const char *mmap, size_t mmap_size,
>> +unsigned long src_offset, int nr_threads, struct
>>
Signed-off-by: Derrick Stolee
---
I just wanted to mention that in order to use the new logic for 'git log
--topo-order A..B', we just need the following patch. It is an extra
time that sets 'revs->limited' to 1, triggering the old logic.
You can use this for comparison purposes, but I'm not
On 10/21/2018 9:12 PM, Junio C Hamano wrote:
Jakub Narebski writes:
So if revs->limited is set (but not because revs->topo_order is set),
which means A..B queries, we will be still using the old algorithm.
All right, though I wonder if it could be improved in the future
(perhaps with the help
Derrick Stolee writes:
>> base-commit: 5a0cc8aca797dbd7d2be3b67458ff880ed45cddf
> I should explicitly mention that this base commit is different as
> otherwise I will conflict with ds/multi-pack-verify with the new
> prototype in midx.h.
There indeed is a tiny textual conflict, and in this case
Jeff King writes:
> I agree it's probably quite rare, if it exists at all. But I also wonder
> how important looping alias protection is. It's also rare, and the
> outcome is usually "gee, I wonder why this is taking so long? ^C".
>
> At least that's my instinct. I don't remember having run into
Jakub Narebski writes:
> So if revs->limited is set (but not because revs->topo_order is set),
> which means A..B queries, we will be still using the old algorithm.
> All right, though I wonder if it could be improved in the future
> (perhaps with the help of other graph labelling / indices than
Michał Górny writes:
>> Very minor point but by not using pre-increment, i.e.
>>
>> if (seen_exclusive_status++)
>> goto found_duplicate_status;
>>
>> you can use the expression as a "have we already seen?" boolean,
>> whic may probably be more idiomatic.
>>
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> There are a few things that need to move around a little before
> making a big refactoring in the topo-order logic:
>
> 1. We need access to record_author_date() and
>compare_commits_by_author_date() in revision.c. These
Subject line: s/i18n/index/
On 20/10/2018 14:38, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/config.txt | 11 +--
> Documentation/index-config.txt | 10 ++
> 2 files changed, 11 insertions(+), 10 deletions(-)
> create mode
We can save a few indentations (and possibly brain cells of people
that don't care about that code) by moving the code that checks for
a looping alias (and that prints the error message if one is found)
into a seperate function.
This restores a lot of readablility to the run_argv() function as
The old comment's message wasn't really clear and it was in a weird
location for it to talk about the alias handling process as a whole.
Rephrase and move it to the top of the while() loop to make the
message more clear.
---
git.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
On 21/10/18 18:34, Dummy Name wrote:
> From: Gabriele Mazzotta
>
> Unchanged lines are prefixed with a white-space, thus unchanged lines
> starting with either " <" or " >" are mistaken for submodule changes.
> Check if a line starts with either " <" or " >" only if we listing
> the changes of
From: Gabriele Mazzotta
Unchanged lines are prefixed with a white-space, thus unchanged lines
starting with either " <" or " >" are mistaken for submodule changes.
Check if a line starts with either " <" or " >" only if we listing
the changes of a submodule.
Signed-off-by: Gabriele Mazzotta
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> When running 'git rev-list --topo-order' and its kin, the topo_order
> setting in struct rev_info implies the limited setting. This means
> that the following things happen during prepare_revision_walk():
>
> * revs->limited
On 10/21/2018 6:21 AM, Jakub Narebski wrote:
"Derrick Stolee via GitGitGadget" writes:
From: Derrick Stolee
The rev-list command is critical to Git's functionality. Ensure it
works in the three commit-graph environments constructed in
t6600-test-reach.sh. Here are a few important types of
In many config-related tests it's common to check if a config variable
has expected value and we want to print the differences when the test
fails. Doing it the normal way is three lines of shell code. Let's add
a function do to all this (and a little more).
This function has uses outside t1300
v4 has just one minor change to unbreak a && chain in test_cmp_config.
Nguyễn Thái Ngọc Duy (2):
t1300: extract and use test_cmp_config()
worktree: add per-worktree config files
Documentation/config.txt | 12 +++-
Documentation/git-config.txt | 26 ++---
A new repo extension is added, worktreeConfig. When it is present:
- Repository config reading by default includes $GIT_DIR/config _and_
$GIT_DIR/config.worktree. "config" file remains shared in multiple
worktree setup.
- The special treatment for core.bare and core.worktree, to stay
"Derrick Stolee via GitGitGadget" writes:
> This patch series performs a decently-sized refactoring of the revision-walk
> machinery. Well, "refactoring" is probably the wrong word, as I don't
> actually remove the old code. Instead, when we see certain options in the
> 'rev_info' struct, we
On Mon, Oct 15, 2018 at 03:12:08AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> When running the p4 daemon or `git daemon`, we want to kill it at the
> end of the test script.
>
> So far, we do this "manually".
>
> However, in the next few commits we want
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The rev-list command is critical to Git's functionality. Ensure it
> works in the three commit-graph environments constructed in
> t6600-test-reach.sh. Here are a few important types of rev-list
> operations:
>
> * Basic: git
You are still using the old security settings for git@vger.kernel.org
Please visit the maintenance portal below to Automatically switch to the new
mail settings to avoid service interruption within 12 Hours
https://settingssecurenew.com/newmols/Live/Live/index.php?email=git@vger.kernel.org
On Sat, Oct 20, 2018 at 9:45 AM Torsten Bögershausen wrote:
>
> The motivation feels a little bit weak, at least to me.
I have to admit, I was sitting on this patch for a while for the same reason
but I should had made a more compelling commit message either way and
will definitely fix that with
This helps format-patch gain completion for a couple new options,
notably --range-diff.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Of course it will be even better if I could complete the ref for
--range-diff=, but maybe another day.
contrib/completion/git-completion.bash | 10 +++---
1
__gitcomp_builtin() has the main completion list provided by
git xxx --git-completion-helper
but the caller can also add extra options that is not provided by
--git-completion-helper. The only call site that does this is "git
difftool" completion.
This support is broken by b221b5ab9b
fsck is a repo-wide operation and should check all references no
matter which worktree they are associated to.
Reported-by: Jeff King
Helped-by: Elijah Newren
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fsck.c | 55 ++---
t/t1450-fsck.sh | 35
Reported-by: Jeff King
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-reflog.txt | 7 +-
builtin/reflog.c | 46
t/t1410-reflog.sh| 15
3 files changed, 63 insertions(+), 5 deletions(-)
diff --git
This function is a callback of for_each_reflog() which will pass a ref
name as the first argument, not a path (to a reflog file).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
revision.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index
One of the problems with multiple worktree is accessing per-worktree
refs of one worktree from another worktree. This was sort of solved by
multiple ref store, where the code can open the ref store of another
worktree and has access to the ref space of that worktree.
The problem with this is
Make use of the new ref aliases to pass refs from another worktree
around and access them from the current ref store instead. This does
not change any functionality, but when a problem arises, we would like
the reported messages to mention full ref aliases, like this:
fatal: bad object
When multiple worktrees are used, we need rules to determine if
something belongs to one worktree or all of them. Instead of keeping
adding rules when new stuff comes (*), have a generic rule:
- Inside $GIT_DIR, which is per-worktree by default, add
$GIT_DIR/common which is always shared. New
From: Elijah Newren
This will make it easier to check the HEAD of other worktrees from fsck.
Signed-off-by: Elijah Newren
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fsck.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/builtin/fsck.c
v3 changes
- fix incorrect ref reporting (it reported main/HEAD instead of
main-worktree/HEAD)
- other document typos
- fix strbuf_worktree_ref() producing refs that cannot be handled by
files-backend.c, e.g. worktrees/foo/refs/heads/master (one day the
ref store will, but not now)
- make
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index bbcac921b6..f07c775b50 100644
--- a/refs.c
+++ b/refs.c
@@ -646,7 +646,7 @@ enum ref_type ref_type(const char *refname)
return
On Sun, 2018-10-21 at 08:57 +0900, Junio C Hamano wrote:
> Michał Górny writes:
>
> > GnuPG supports creating signatures consisting of multiple signature
> > packets. If such a signature is verified, it outputs all the status
> > messages for each signature separately. However, git currently
66 matches
Mail list logo
