On Wed, Oct 10, 2018 at 09:58:51AM +0900, Junio C Hamano wrote:
> > +static void bitmap_to_rle(struct strbuf *out, struct bitmap *bitmap)
> > +{
> > + int curval = 0; /* count zeroes, then ones, then zeroes, etc */
> > + size_t run = 0;
> > + size_t word;
> > + size_t orig_len = out->len;
`git ls-files` takes zero or more s, but the manpage (and the `-h`
output) lists it as taking zero or more s instead. This is confusing as
is documented in `man git` as a filename, without any magic. But a
pathspec has a lot of special handling. The gitglossary entry for pathspec does
say
On Wed, Oct 10, 2018 at 09:48:53AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > The one difference is the sort order: git's diff output is
> > in tree-sort order, so a subtree "foo" sorts like "foo/",
> > which is after "foo.bar". Whereas the bitmap path list has a
> > true byte sort,
On Thu, 11 Oct 2018 08:01:40 +0900, Junio wrote:
> Michael Witten writes:
>
>> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>>
>>> We haven't seen much complaints and breakages reported against the
>>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>>> time to merge
Johannes Schindelin writes:
> https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051
> fixup! builtin rebase: support `-C` and `--whitespace=`
For c7ee2134d4 (rebase-in-c-4-opts); a single liner that is
obviously correct.
>
Junio C Hamano writes:
> From: Johannes Schindelin
> Date: Thu, 27 Sep 2018 14:48:17 +0200
>
> The `--gpg-sign` option takes an *optional* argument, not a mandatory
> one.
>
> This was discovered as part of the investigation of
> https://github.com/git-for-windows/git/issues/1836.
>
>
From: Johannes Schindelin
Date: Thu, 27 Sep 2018 14:48:17 +0200
The `--gpg-sign` option takes an *optional* argument, not a mandatory
one.
This was discovered as part of the investigation of
https://github.com/git-for-windows/git/issues/1836.
Signed-off-by: Johannes Schindelin
---
* I am
Stefan Beller writes:
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> I would suggest merging to 'next'.
OK.
>> * sb/strbuf-h-update (2018-09-29) 1 commit
> The patch as-is just adds names everywhere.
> I'd be happy to resend with either
> (a) not enforcing names everywhere, but only
Phillip Wood writes:
> On 10/10/2018 06:43, 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
Johannes Sixt writes:
> Am 10.10.18 um 07:43 schrieb Junio C Hamano:
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> before moving
Hi,
Derrick Stolee wrote:
> commit-reach.c| 4 +++-
> t/t6600-test-reach.sh | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
I like this testing technique, and the test passes for me.
Except: if I put
CC = cc -m32
NO_OPENSSL = YesPlease
NO_CURL =
Thomas Gummerer writes:
> There was a v9 of this series [*1*], which hasn't been picked up yet.
> Was that intentional, or an oversight?
;-) Yes, I often miss patches that are buried in other discussions,
but this time, it was quite deliberate. I saw comments that pointed
out at least one
Signed-off-by: Jonathan Tan
---
commit-graph.c | 4 ++--
revision.c | 20
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index 90b0b3df90..d21d555611 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -782,9 +782,9 @@
Signed-off-by: Jonathan Tan
---
bloom-filter.c | 31 ++-
bloom-filter.h | 12
commit-graph.c | 26 --
revision.c | 9 +++--
4 files changed, 37 insertions(+), 41 deletions(-)
diff --git a/bloom-filter.c b/bloom-filter.c
I did my own experiments on top of what Szeder provided - the first
patch is to have one fixed-size bloom filter per commit, and the second
patch makes that bloom filter apply to only the first parent of each
commit. The results are:
Original (szeder's)
$
Olga Telezhnaya writes:
> Use ref_array_clear() to release memory instead of UNLEAK macros.
>
> Signed-off-by: Olga Telezhnaia
> ---
> builtin/ls-remote.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
OK, this is immediately before the command exits, and we have a way
to clear and
Olga Telezhnaya writes:
> Release item->value.
> Initialize item->value->s dynamically and then release its resources.
> Release some local variables.
Again, "why" is lacking.
> @@ -1373,36 +1379,31 @@ static void fill_remote_ref_details(struct used_atom
> *atom, const char *refname,
>
Olga Telezhnaya writes:
> Release memory from used_atom variable.
That much readers would know from a quick look of the patch text.
Without knowing what you are aiming at, it is impossible to judge if
the patch is a good change.
Seeing FREE_AND_NULL(array->items) in the same function makes me
On Wed, Oct 10, 2018 at 10:59:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Callers who _are_ prepared to act on the exit code probably ought to
> > just use --auto-exit-code in their invocation.
> >
> > That said, I'm not entirely opposed to the matching config. There's
> > enough history here
On Wed, Oct 10, 2018 at 10:54:32PM +0200, Daniels Umanovskis wrote:
> When called with --show-current, git branch will print the current
> branch name and terminate. Only the actual name gets printed,
> without refs/heads. In detached HEAD state, nothing is output.
I also wondered what happens
On Thu, Oct 11, 2018 at 06:54:15AM +0900, Junio C Hamano wrote:
> > I'm not sure about saying "branch or tag" in the first bullet. It's
> > friendlier to most users, but less technically correct (if you said
> > "notes/foo", I believe we'd match an existing "refs/notes/foo", because
> > it's
On Wed, Oct 10, 2018 at 11:23:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I wonder if we could reword the first paragraph to be a little less
> > confusing, and spell out what we tried already. E.g., something like:
> >
> > The destination you provided is not a full refname (i.e., starting
>
On Thu, Oct 11, 2018 at 07:14:31AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I get why you're doing it: your topic here only cares about removing
> > index dependencies, so you did the minimal thing to move that forward.
> >
> > But if you think about what this function is doing,
On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> Do like it's done in grep so mode doesn't end up as
> 016, which means range-diff doesn't work if one has
> "submodule.diff = log" in the configuration. Without this
> while using range-diff I only get a
>
> Submodule a
On Wed, Oct 10, 2018 at 4:38 PM Junio C Hamano wrote:
>
> Brandon Casey writes:
>
> > ... Again, I don't feel strongly about it, but I'm not
> > sure this change actually improves the code.
>
> Yeah, in the context of the current caller, this is a safe change
> that does not break anybody and
On 2018.10.05 12:25, Stefan Beller wrote:
> > > > I suppose if we are strict about serving from a single endpoint, the
> > > > version registry makes more sense, and individual operations can declare
> > > > acceptable version numbers before calling any network code?
> > >
> > > Ah yeah, that
On Wed, Oct 10, 2018 at 05:59:05AM +0900, Junio C Hamano wrote:
> I do not offhand know if we want "show the current one only" option
> that is "command mode" sitting next to "list", "delete", "rename"
> etc., or "limit the operation to the one that is currently cheked
> out". If we want the
Daniels Umanovskis writes:
> On 10/11/18 12:26 AM, Junio C Hamano wrote:
>> Among the remaining ones in the list, cherry and get-tar-commit-id
>> are probably better classified as plumbing. I do not know why
>> cherry is marked for completion; perhaps some crazy people use that
>> on the
Brandon Casey writes:
> ... Again, I don't feel strongly about it, but I'm not
> sure this change actually improves the code.
Yeah, in the context of the current caller, this is a safe change
that does not break anybody and reduces the number of instructions
executed in this codepath. A
Mihir Mehta writes:
> -Just in case if you are doing something exotic, it should be
> +Just in case you are doing something exotic, it should be
Thanks. Somehow I didn't notice this change earlier, but it looks
good, too.
Will queue.
Instead of passing the sign directly to emit_line_ws_markup, pass only the
index to lookup the sign in diff_options->output_indicators.
Signed-off-by: Stefan Beller
---
I still have this patch laying around, it simplifies the diff code
a tiny bit.
Stefan
diff.c | 12 +---
1 file
On Wed, Oct 10 2018, SZEDER Gábor wrote:
> On Thu, Oct 04, 2018 at 11:09:58PM -0700, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>> >> git-gc - Cleanup unnecessary files and optimize the local repository
>> >>
>> >> Creating these indexes like the commit-graph falls under "optimize
Michael Witten writes:
> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>>
On 10/11/18 12:26 AM, Junio C Hamano wrote:
> Among the remaining ones in the list, cherry and get-tar-commit-id
> are probably better classified as plumbing. I do not know why
> cherry is marked for completion; perhaps some crazy people use that
> on the command line?
I think cherry could go
On Wed, Oct 10, 2018 at 11:56 AM Antonio Ospite wrote:
>
> On Mon, 8 Oct 2018 15:19:00 -0700
> Stefan Beller wrote:
>
> > > +test_expect_success 'not writing gitmodules config file when it is not
> > > checked out' '
> > > +test_must_fail git -C super submodule--helper config
> > >
On Tue, Oct 9, 2018 at 5:10 PM Jonathan Tan wrote:
>
> > It claimed that grep would still need some explicit handling, but that is
> > not the call to repo_read_gitmodules (applying this patch on top of
> > ff6f1f564c4 still keep the test suite happy, specifically
> >
On Wed, Oct 10 2018, SZEDER Gábor wrote:
> On Wed, Oct 10, 2018 at 11:56:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Oct 10 2018, SZEDER Gábor wrote:
>
>> >> for (i = 0; i < oids->nr; i++) {
>> >> + display_progress(progress, ++j);
>>
>> [...]
>>
>> > This display_progress()
On Wed, Oct 10, 2018 at 12:32 PM Ævar Arnfjörð Bjarmason
wrote:
>
> Checking gc_auto_threshold in too_many_loose_objects() was added in
> 17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.",
> 2007-09-17) when need_to_gc() itself was also reliant on
> gc_auto_pack_limit before its
I noticed that git-merge-base was unlikely to actually be a git command,
and tried it in my shell. Seeing that it doesn't work, I cleaned up two
places in the docs where it appears.
Signed-off-by: Mihir Mehta
---
Documentation/git-diff.txt | 4 ++--
Daniels Umanovskis writes:
> git-rev-parse mostly seems like plumbing, and is more usd in
> scripts than in regular use. Online it's often mentioned as
> a plumbing command. Nonetheless it's listed under porcelain
> interrogators in `man git`. It seems appropriate to formally
> move
Ævar Arnfjörð Bjarmason wrote:
> Which is what I'm doing by running "gc --auto" across a set of servers
> and looking at the exit code. If it's been failing I get an error, if
> there's no need to gc nothing happens, and if it hasn't been failing and
> it just so happens that it's time to GC then
On Wed, Oct 10, 2018 at 11:56:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Oct 10 2018, SZEDER Gábor wrote:
> >>for (i = 0; i < oids->nr; i++) {
> >> + display_progress(progress, ++j);
>
> [...]
>
> > This display_progress() call, however, doesn't seem to be necessary.
> >
Mihir Mehta writes:
> Thanks, Junio. Instead of removing that part of the patch, I opted to
> expand it to make it a little clearer (in my opinion) than it was
> before. Let me know if this works.
I am mildly negative on that change. "Omitting both would give an
empty diff" would be
On Wed, Oct 10 2018, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> Perhaps this reporting could also print the message from a previous
>>> run, so you could write:
>>>
>>> git gc --detached-status || exit
>>> git gc --auto; # perhaps also passing
Jeff King writes:
> I get why you're doing it: your topic here only cares about removing
> index dependencies, so you did the minimal thing to move that forward.
>
> But if you think about what this function is doing, it is quite clearly
> dependent on the whole repository, since the userdiff
On Thu, Oct 04, 2018 at 11:09:58PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> git-gc - Cleanup unnecessary files and optimize the local repository
> >>
> >> Creating these indexes like the commit-graph falls under "optimize the
> >> local repository",
> >
> > But it doesn't
On Wed, Oct 10 2018, SZEDER Gábor wrote:
> On Mon, Sep 17, 2018 at 03:33:35PM +, Ævar Arnfjörð Bjarmason wrote:
>> $ git -c gc.writeCommitGraph=true gc
>> [...]
>> Annotating commits in commit graph: 1565573, done.
>> Computing commit graph generation numbers: 100%
Jeff King writes:
>> Fix both of those, now the message will look like this instead:
>>
>> $ ./git-push avar v2.19.0^{commit}:newbranch -n
>> error: unable to push to unqualified destination: newbranch
>> hint: The destination refspec neither matches an existing
>> hint: ref on
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Perhaps this reporting could also print the message from a previous
>> run, so you could write:
>>
>> git gc --detached-status || exit
>> git gc --auto; # perhaps also passing --detach
>>
>> (Names still open for bikeshedding.)
>
>
Gerrit, the code review tool, has a different workflow than our mailing
list based approach. Usually users upload changes to a Gerrit server and
continuous integration and testing happens by bots. Sometimes however a
user wants to checkout a change locally and look at it locally. For this
use
We can string_list_insert() to maintain sorted-ness of the
list as we find new items, or we can string_list_append() to
build an unsorted list and sort it at the end just once.
As we do not rely on the sortedness while building the
list, we pick the "append and sort at the end" as it
has better
The submodule subsystem is really bad at staying within 80 characters.
Fix it while we are here.
Signed-off-by: Stefan Beller
---
submodule.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index b53cb6e9c4..0de9e2800a 100644
---
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
Documentation/technical/api-oid-array.txt | 5 +
sha1-array.c | 17 +
sha1-array.h | 3 +++
3 files changed, 25 insertions(+)
diff --git
The `changed_submodule_names` are only used for fetching, so let's make it
part of the struct that is passed around for fetching submodules.
Signed-off-by: Stefan Beller
---
submodule.c | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff
This patch started as a refactoring to make 'get_next_submodule' more
readable, but upon doing so, I realized that "git fetch" of the submodule
actually doesn't need to be run in the submodules worktree. So let's run
it in its git dir instead.
That should pave the way towards fetching submodules
Currently when git-fetch is asked to recurse into submodules, it dispatches
a plain "git-fetch -C " (with some submodule related options
such as prefix and recusing strategy, but) without any information of the
remote or the tip that should be fetched.
This works surprisingly well in some
When constructing a struct repository for a submodule for some revision
of the superproject where the submodule is not contained in the index,
it may not be present in the working tree currently either. In that
siutation giving a 'path' argument is not useful. Upgrade the
repo_submodule_init
'calculate_changed_submodule_paths' uses a local list to compute the
changed submodules, and then produces the result by copying appropriate
items into the result list.
Instead use the result list directly and prune items afterwards
using string_list_remove_empty_items.
By doing so we'll have
This is nearly the same as sent in [1], with one commit message fixed.
[1] https://public-inbox.org/git/20180925194755.105578-1-sbel...@google.com/
and replaces sb/submodule-recursive-fetch-gets-the-tip.
Thanks,
Stefan
Stefan Beller (9):
sha1-array: provide oid_array_filter
submodule.c: fix
git-rev-parse mostly seems like plumbing, and is more usd in
scripts than in regular use. Online it's often mentioned as
a plumbing command. Nonetheless it's listed under porcelain
interrogators in `man git`. It seems appropriate to formally
move git-rev-parse to plumbing interrogators.
Jonathan Nieder writes:
> Perhaps this reporting could also print the message from a previous
> run, so you could write:
>
> git gc --detached-status || exit
> git gc --auto; # perhaps also passing --detach
>
> (Names still open for bikeshedding.)
When the command is given
Am 10.10.18 um 07:43 schrieb Junio C Hamano:
We haven't seen much complaints and breakages reported against the
two big "rewrite in C" topics around "rebase"; perhaps it is a good
time to merge them to 'next' soonish to cook them for a few weeks
before moving them to 'master'?
Please let me
On Wed, Oct 10 2018, Jeff King wrote:
> On Wed, Oct 10, 2018 at 10:41:45AM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Improve the error message added in f8aae12034 ("push: allow
>> unqualified dest refspecs to DWIM", 2008-04-23), which before this
>> change looks like this:
>>
>> $ git push
Ævar Arnfjörð Bjarmason wrote:
> Right. I know. What I mean is now I can (and do) use it to run 'git gc
> --auto' across our server fleet and see whether I have any of #3, or
> whether it's all #1 or #2. If there's nothing to do in #1 that's fine,
> and it just so happens that
On Wed, Oct 10 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
>> configuration option to optionally bring back the 'git gc --auto' exit
>> code behavior as it existed between 2.6.3..2.19.0
On Wed, Oct 10 2018, Jeff King wrote:
> On Wed, Oct 10, 2018 at 07:27:32PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
>> configuration option to optionally bring back the 'git gc --auto' exit
>> code behavior as it existed
When called with --show-current, git branch will print the current
branch name and terminate. Only the actual name gets printed,
without refs/heads. In detached HEAD state, nothing is output.
Intended both for scripting and interactive/informative use.
Unlike git branch --list, no filtering is
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
Hm. Can you tell me more about the use case
On Wed, Oct 10, 2018 at 10:41:45AM +, Ævar Arnfjörð Bjarmason wrote:
> Improve the error message added in f8aae12034 ("push: allow
> unqualified dest refspecs to DWIM", 2008-04-23), which before this
> change looks like this:
>
> $ git push avar v2.19.0^{commit}:newbranch -n
> error:
On Wed, Oct 10, 2018 at 10:41:44AM +, Ævar Arnfjörð Bjarmason wrote:
> Mark up the error(...) messages in remote.c for translation. The likes
> of "unable to push to unqualified destination" are relatively big
> parts of the UI, i.e. error messages shown when "git push" fails.
>
> I don't
v2 reroll of a previously-discussed patch. Thanks to everyone for their
comments. Based on feedback:
1. Command is now a verb: git branch --show-current.
2. Changed to gitster's suggested implementation: nothing is printed
if HEAD does not point to a symbolic ref. A fatal
error if HEAD is a
On Mon, Sep 17, 2018 at 03:33:35PM +, Ævar Arnfjörð Bjarmason wrote:
> $ git -c gc.writeCommitGraph=true gc
> [...]
> Annotating commits in commit graph: 1565573, done.
> Computing commit graph generation numbers: 100% (782484/782484), done.
While poking around
On 10.10.18 07:43, Junio C Hamano wrote:
* ts/alias-of-alias (2018-09-17) 3 commits
(merged to 'next' on 2018-10-09 at ac19b4730b)
+ t0014: introduce an alias testing suite
+ alias: show the call history when an alias is looping
+ alias: add support for aliases of an alias
An alias
On Wed, Oct 10, 2018 at 07:27:32PM +, Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
>
> This was
Explicitly mention in the intro that we may be writing supplemental
data structures such as the commit-graph during "gc", i.e. to call out
the "optimize" part of what this command does, it doesn't just
"collect garbage" as the "gc" name might imply.
Past changes have updated the intro to reflect
Expand on the work started in 095c741edd ("commit: run git gc --auto
just before the post-commit hook", 2018-02-28) to run "gc --auto" in
more commands where new objects can be created.
The notably missing commands are now "rebase" and "stash". Both are
being rewritten in C, so any use of "gc
Checking gc_auto_threshold in too_many_loose_objects() was added in
17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.",
2007-09-17) when need_to_gc() itself was also reliant on
gc_auto_pack_limit before its early return:
gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0
When
Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
configuration option to optionally bring back the 'git gc --auto' exit
code behavior as it existed between 2.6.3..2.19.0 (inclusive).
This was changed in 3029970275 ("gc: do not return error for prior
errors in daemonized
Need for update subscribing to mailing list from @git
Thanks
Sent from my Evertek
On Tue, Oct 9, 2018 at 6:10 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
> >> Oh, I think I misled you by saying "more important".
> >> ...
> > I do challenge the decision to take a hardcoded value, though, ...
>
> I do not find any reason why you need to say "though" here.
I caught
On Wed, 10 Oct 2018 18:51:17 -, Michael Witten wrote:
> merge -# Same as merge -C abcde r1
That should be:
merge -# Same as `merge r1'
On Mon, 8 Oct 2018 15:19:00 -0700
Stefan Beller wrote:
> > +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
> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> - diff --color-moved: fix a memory leak
> - diff --color-moved-ws: fix another memory leak
> - diff --color-moved-ws: fix a memory leak
> - diff --color-moved-ws: fix out of bounds string access
> - diff --color-moved-ws: fix double free
On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
> We haven't seen much complaints and breakages reported against the
> two big "rewrite in C" topics around "rebase"; perhaps it is a good
> time to merge them to 'next' soonish to cook them for a few weeks
> before moving them to 'master'?
On Wed, Oct 10 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> I'm just saying it's hard in this case to remove one piece without the
>> whole Jenga tower collapsing, and it's probably a good idea in some of
>> these cases to pester the user about what he wants, but
Hello,
Am 10.10.2018 um 01:38 schrieb Артем Семенов:
> Hello.
>
> Git svn bug on merging svn branches:
>
> Svn repository (branches tag trunk).
>
> 1. Add a some file by svn tools.
> 2. Create a new branch by svn tools (e.g. br1) .
> 3. Create a new branch by svn tools on branch br1 (e.g.
> I'd be happy to submit a documentation patch for discussion that
> formally moves rev-parse to plumbing.
I'd be happy to see such a patch.
On Wed, Oct 10, 2018 at 8:26 AM Phillip Wood wrote:
>
> On 09/10/2018 22:10, Stefan Beller wrote:
> >> As I said above I've more or less come to the view that the correctness
> >> of pythonic indentation is orthogonal to move detection as it affects
> >> all additions, not just those that
On Wed, Oct 10, 2018 at 09:51:52AM -0700, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
> > I'm just saying it's hard in this case to remove one piece without the
> > whole Jenga tower collapsing, and it's probably a good idea in some of
> > these cases to pester the user about what
Hi,
Ævar Arnfjörð Bjarmason wrote:
> I'm just saying it's hard in this case to remove one piece without the
> whole Jenga tower collapsing, and it's probably a good idea in some of
> these cases to pester the user about what he wants, but probably not via
> gc --auto emitting the same warning
On Wed, Oct 10, 2018 at 8:21 AM Junio C Hamano wrote:
> We probably can keep the "let's not run for a day" safety while
> pretending that "git gc -auto" succeeded for callers like "git svn"
> so that these callers do not hae to do "eval { ... }" to hide our
> exit code, no?
>
> I think that is
On 10/10/18 5:03 PM, Ævar Arnfjörð Bjarmason wrote:
>
> I'm mildly negative on this because git-rev-parse is plumbing, but
> git-branch is porcelain [..]
>
> We also list git-rev-parse as porcelain, just under "Porcelain / Ancillary
> Commands / Interrogators".
>
> Should we just move it to
From: Ben Peart
This patch enables addressing the CPU cost of loading the index by adding
additional data to the index that will allow us to efficiently multi-
thread the loading and conversion of cache entries.
It accomplishes this by adding an (optional) index extension that is a
table of
From: Ben Peart
This patch helps address the CPU cost of loading the index by loading
the cache extensions on a worker thread in parallel with loading the cache
entries.
In some cases, loading the extensions takes longer than loading the
cache entries so this patch utilizes the new EOIE to
From: Ben Peart
This patch helps address the CPU cost of loading the index by utilizing
the Index Entry Offset Table (IEOT) to divide loading and conversion of
the cache entries across multiple threads in parallel.
I used p0002-read-cache.sh to generate some performance data:
Test w/100,000
From: Ben Peart
Add support for a new index.threads config setting which will be used to
control the threading code in do_read_index(). A value of 0 will tell the
index code to automatically determine the correct number of threads to use.
A value of 1 will make the code single threaded. A
From: Ben Peart
This patch does a clean up pass to minimize the casting required to work
with the memory mapped index (mmap).
It also makes the decoding of network byte order more consistent by using
get_be32() where possible.
Signed-off-by: Ben Peart
---
read-cache.c | 23
From: Nguyễn Thái Ngọc Duy
Index format v4 requires some more computation to assemble a path
based on a previous one. The current code is not very efficient
because
- it doubles memory copy, we assemble the final path in a temporary
first before putting it back to a cache_entry
-
From: Ben Peart
The End of Index Entry (EOIE) is used to locate the end of the variable
length index entries and the beginning of the extensions. Code can take
advantage of this to quickly locate the index extensions without having
to parse through all of the index entries.
The EOIE extension
From: Ben Peart
Fixed issues identified in review the most impactful probably being plugging
some leaks and improved error handling. Also added better error messages
and some code cleanup to code I'd touched.
The biggest change in the interdiff is the impact of renaming ieot_offset to
1 - 100 of 162 matches
Mail list logo
