On Tue, Jun 26, 2018 at 05:13:05PM -0400, Eric Sunshine wrote:
> On Tue, Jun 26, 2018 at 5:01 PM Jeff King wrote:
> > On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> > > Some of these dangers can be de-thoothed during the linting phase by
> > > defining do-nothing shell
On Thu, Jun 28, 2018 at 02:44:47AM +, brian m. carlson wrote:
> On Wed, Jun 27, 2018 at 07:54:52AM +, Steve Groeger wrote:
> > We have common code that is supposed to be usable across different
> > platforms and hence different file encodings. With the full support of the
> >
On Wed, Jun 27, 2018 at 04:58:43PM -0400, Todd Zullinger wrote:
> I tend to think that the default should be to build
> documentation that is accurate for that build, but since
> it's something I'll set once for my package builds it's not
> a big deal either way to me.
To be clear, I think so,
On Wed, Jun 27, 2018 at 12:44:43PM -0400, Todd Zullinger wrote:
> I wrote:
> > Jeff King wrote:
> >> (Related, there's a build target in the local Makefile for using
> >> asciidoctor; does it need updated, too?)
> >
> > I didn't test asciidoctor specficially, but it also respects
> >
On Wed, Jun 27, 2018 at 11:03:52AM -0400, Todd Zullinger wrote:
> So what you're saying is that if I had procrastinated a
> little, you may have written such a patch for me? :)
Yes, but that's a dangerous game of chicken. :)
> > 1. The pre-built documentation that Junio builds for
> >
> Do we have any numbers on performance or memory pressure here?
> (I would think benchmarking fast-import would suffice as that is where the mem
> pool originated)
I ran fast-import on the git.git and linux.git repositories - this action
reports the
overall memory allocated to pools. The
> How much work is it to convert these to object_id while at it instead of char
> *sha1?
> (I think we really dislike introducing new sha1 based code; If it doesn't
> sound
> easy maybe we can have a static inline wrapper here that just converts oid to
> sha1 and then calls this function?)
I
Add functions for:
- combining two memory pools
- determining if a memory address is within the range managed by a
memory pool
These functions will be used by future commits.
Signed-off-by: Jameson Miller
---
mem-pool.c | 42 ++
Add an option (controlled by an environment variable) perform extra
validations on mem_pool allocated cache entries. When set:
1) Invalidate cache_entry memory when discarding cache_entry.
2) When discarding index_state struct, verify that all cache_entries
were allocated from expected
When reading large indexes from disk, a portion of the time is
dominated in malloc() calls. This can be mitigated by allocating a
large block of memory and manage it ourselves via memory pools.
This change moves the cache entry allocation to be on top of memory
pools.
Design:
The index_state
Refactor refresh_cache_entry() to work on a specific index, instead of
implicitly using the_index. This is in preparation for making the
make_cache_entry function apply to a specific index.
Signed-off-by: Jameson Miller
---
cache.h | 2 +-
merge-recursive.c | 2 +-
read-cache.c |
Instead of searching all memory blocks for available space to fulfill
a memory request, only search the head block. If the head block does
not have space, assume that previous block would most likely not be
able to fulfill request either. This could potentially lead to more
memory fragmentation,
Changes from v4 are minor code review feedback items:
- Remove extern keyword from new function definitions in cache.h
- Make_cache_entry(..) functions work with object_id instead of sha
- Add details to commit message for "block alloc: allocate cache entries from
mem_pool"
- Add details
Add initialization and discard functions to mem_pool type. As the
memory allocated by mem_pool can now be freed, we also track the large
allocations.
If the there are existing mp_blocks in the mem_poo's linked list of
mp_blocksl, then the mp_block for a large allocation is inserted
behind the
The make_cache_entry function should take an object_id struct instead
of sha.
Signed-off-by: Jameson Miller
---
apply.c| 2 +-
builtin/checkout.c | 2 +-
builtin/difftool.c | 4 ++--
builtin/reset.c| 2 +-
cache.h| 7 ++-
merge-recursive.c | 2 +-
read-cache.c
Add an API around managing the lifetime of cache_entry
structs. Abstracting memory management details behind this API will
allow for alternative memory management strategies without affecting
all the call sites. This commit does not change how memory is
allocated or freed. A later commit in this
On Wed, Jun 27, 2018 at 09:35:23PM +0200, Johannes Schindelin via GitGitGadget
wrote:
> To prevent erroneous commits from being reported (e.g. when unpacking
> Git's source code from a .tar.gz file into a subdirectory of a different
> Git project, as e.g. git_osx_installer does), we
Team,
[Cc:ing Tim]
On Thu, 28 Jun 2018, Johannes Schindelin via GitGitGadget wrote:
> In ed32b788c06 (version --build-options: report commit, too, if
> possible, 2017-12-15), we introduced code to let `git version
> --build-options` report the current commit from which the binaries were
>
Hi Junio,
On Wed, 27 Jun 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > git rev-list --bisect-all --first-parent F..E >revs &&
> > # only E, e1..e8 should be listed, nothing else
> > test_line_count = 9 revs &&
> > for rev in E e1 e2 e3 e4 e5 e6 e7 e8
> >
On Mon, Jun 25, 2018 at 11:49 PM, Junio C Hamano wrote:
>
> Just an early warning, as I haven't even complained on patch titles
> of these patches in the series ;-)
>
> 5702.20 and 5702.21 seems to fail in standalone test, when these are
> directly queued on top of Git v2.18.0; I haven't looked
In ed32b788c06 (version --build-options: report commit, too, if
possible, 2017-12-15), we introduced code to let `git version
--build-options` report the current commit from which the binaries were
built, if any.
To prevent erroneous commits from being reported (e.g. when unpacking
Git's source
From: Johannes Schindelin
In ed32b788c06 (version --build-options: report commit, too, if
possible, 2017-12-15), we introduced code to let `git version
--build-options` report the current commit from which the binaries were
built, if any.
To prevent erroneous commits from being reported (e.g.
The commit-graph feature shipped in Git 2.18 has some inconsistencies in
the constants used by the implementation and specified by the format
document.
The commit data chunk uses the key "CDAT" in the file format, but was
previously documented to say "CGET".
The commit data chunk stores commit
On 6/28/2018 1:11 AM, Grant Welch wrote:
I recently read the "Supercharging the Git Commit Graph blog by
Derrick Stolee. I found the article interesting and wanted to verify
the performance numbers for myself. Then that led me to want to know
more about the implementation, so I read the
On Wed, Jun 27, 2018 at 07:39:53PM +0100, Ramsay Jones wrote:
> Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02),
> fsck will issue an error message for '.gitmodules' content that cannot
> be parsed correctly. This is the case, even when the corresponding blob
> object has
On 27.06.2018 21:11, Junio C Hamano wrote:
Marc Strapetz writes:
[1. text/plain]
The current description of "core.ignoreCase" reads like an option which
is intended to be changed by the user while it's actually expected to
be set by Git on initialization only. Subsequently, Git relies on the
The current description of "core.ignoreCase" reads like an option which
is intended to be changed by the user while it's actually expected to
be set by Git on initialization only. Subsequently, Git relies on the
proper configuration of this variable, as noted by Bryan Turner [1]:
Git on a
This rewrites append_todo_help() from shell to C. It also incorporates
some parts of initiate_action() and complete_action() that also write
help texts to the todo file.
This also introduces the source file rebase-interactive.c. This file
will contain functions necessary for interactive rebase
This makes rebase_path_todo(), get_missing_commit_check_level() and the
enum check_level accessible outside sequencer.c. check_level is renamed
missing_commit_check_level, and its value names are prefixed by
MISSING_COMMIT_ to avoid namespace pollution.
This will be needed for the rewrite of
This patch rewrites append_todo_help() from shell to C. The C version
covers a bit more than the old shell version. To achieve that, some
parameters were added to rebase--helper.
This also introduce a new source file, rebase-interactive.c.
This is part of the effort to rewrite interactive rebase
Hi Aaron,
On Wed, 27 Jun 2018, Aaron Schrab wrote:
> Use configured comment character when generating comments about branches
> in an instruction sheet. Failure to honor this configuration causes a
> failure to parse the resulting instruction sheet.
Good catch.
Now, if you can refer to the
Hi,
This is a patch I keep in wip-rebase branch[1][2].
It shouldn't be applied to `pu`.
This main objective of this file in the branch is to keep track of
the converted shell scripts of `git-rebase.sh` and plan on the
conversion of other remaining parts.
[1]:
On Thu, Jun 28, 2018 at 9:46 AM, Pratik Karki wrote:
> The motivation behind this commit is to extract the core part of
> do_reset() from sequencer.c and move it to a new detach_head_to()
> function in checkout.c.
If this is independent from your other patches and if this can be used
by Alban's
On Thu, Jun 28, 2018 at 9:46 AM, Pratik Karki wrote:
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> new file mode 100644
> index 0..1152b7229
> --- /dev/null
> +++ b/builtin/rebase.c
> @@ -0,0 +1,55 @@
> +/*
> + * "git rebase" builtin command
> + *
> + * Copyright (c) 2018 Pratik
On Thu, Jun 28, 2018 at 9:46 AM, Pratik Karki wrote:
> The motivation behind this is to call the backend functions
> *directly* from C, bypassing `git-rebase.sh`. Therefore those functions
> need to live in a separate file: we need to be able to call
> `.git-rebase--common` in that script
The motivation behind this commit is to extract the core part of
do_reset() from sequencer.c and move it to a new detach_head_to()
function in checkout.c.
Here the index only gets locked after performing the first part of
`do_reset()` rather than before which essentially derives the `oid`
from
This commit imitates the strategy that was used to convert the
difftool to a builtin, see be8a90e (difftool: add a skeleton for the
upcoming builtin, 2017-01-17) for details: This commit renames the
shell script `git-rebase.sh` to `git-legacy-rebase.sh` and hands off to
it by default.
The current
This is a verbatim copy of `git-rebase.sh`. This acts as a tracker
for components to be converted and to find the progress of current
conversion of `git-rebase.sh` to `builtin/rebase.c`. The commented
parts denote the converted parts.
Signed-off-by: Pratik Karki
---
TODO-rebase.sh | 738
The function present in `git-legacy-rebase.sh` are used by backends
so, this refactor tries to extract the functions out so that, the
`git-legacy-rebase.sh` can be retired easily as the
`git-rebase--common.sh` will provide the functions for now.
The motivation behind this is to call the backend
This patch gives life to the skeleton added in the previous patch.
This patch makes real operation happen i.e. by using
`git -c rebase.usebuiltin=true rebase `.
With this patch, the basic operation of rebase can be done.
The current version of the builtin rebase does not, however, make full
use
As a GSoC project, I have been working on the builtin rebase.
The motivation behind the rewrite of rebase i.e. from shell script to C
are for following reasons:
1. Writing shell scripts and getting it to production is much faster
than doing the equivalent in C but lacks in performance and
101 - 141 of 141 matches
Mail list logo
