[bug] git-check-ignore and file names with unicode chars in name - sys-out filename is corrupted

Reproduction: $ echo "*.ignoreme" >> .gitignore # (and commit) $ touch "fooo-€.ignoreme" $ find . -print | grep fooo | xargs git check-ignore "./fooo-\342\202\254.ignoreme" You could view that git-check-ignore isn't corrupting anything, it is just outputting another form for the file

Re: [PATCHv2 0/6] git clone: Marry --recursive and --reference

On Mon, Aug 8, 2016 at 9:08 PM, Stefan Beller wrote: > > v3: > > Thanks to Junios critial questions regarding the design, I took a step back > to look at the bigger picture. > > --super-reference sounds confusing. (what is the super referring to?) > So drop that approach. > >

HELLO

Hello, I hope this Message finds you well. To start with my name is George Oloni. I am seeking for your cooperation to invest in your Country. Please kindly respond to this message as to enable me to gives you More Details about my investment proposal. Warm Regards Mr. George Oloni -- To

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

On Tue, Aug 9, 2016 at 12:20 AM, Michael Haggerty wrote: > On 08/04/2016 05:58 PM, Johannes Schindelin wrote: >> [...] >> Even requiring every contributor to register with GitHub would be too much >> of a limitation, I would wager. >> [...] > > Is it *really* so insane to

[PATCHv2 0/6] git clone: Marry --recursive and --reference

v3: Thanks to Junios critial questions regarding the design, I took a step back to look at the bigger picture. --super-reference sounds confusing. (what is the super referring to?) So drop that approach. Instead we'll compute where the reference might be in the superproject scope and ask the

[PATCHv3 6/9] clone: implement optional references

In a later patch we want to try to create alternates for all submodules, but they might not exist in the referenced superproject. So add a way to skip the non existing references and report them. Signed-off-by: Stefan Beller --- Documentation/git-clone.txt | 5 -

[PATCHv3 7/9] submodule helper: pass through --reference-if-able

In a later patch we need to pass optional references through to git clone, so add the capability for it. Signed-off-by: Stefan Beller --- builtin/submodule--helper.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git

[PATCHv3 5/9] clone: clarify option_reference as required

In the next patch we introduce optional references; To better distinguish between optional and required references we rename the variable. Signed-off-by: Stefan Beller --- builtin/clone.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCHv2 5/6] submodule update: add super-reference flag

When we have a another clone of a superproject, we may want to mirror the submodules using alternates. Introduce an option `--super-reference` that let's a user point to another superproject, which is assumed to have the same structure as the one they are running the "submodule update" command

[PATCHv2 6/6] clone: reference flag is used for submodules as well

When giving a --reference while also giving --recurse, the alternates for the submodules are assumed to be in the superproject as well. In case they are not, we error out when cloning the submodule. However we error out completely, we did not record the alternates yet, so a following update

[PATCHv3 8/9] submodule: try alternates when superproject has an alternate

Signed-off-by: Stefan Beller --- Documentation/git-clone.txt| 4 builtin/submodule--helper.c| 47 ++ t/t7408-submodule-reference.sh | 29 +- 3 files changed, 79 insertions(+), 1 deletion(-) diff

[PATCHv3 4/9] submodule--helper update-clone: allow multiple references

Allow the user to pass in multiple references to update_clone. Currently this is only internal API, but once the shell script is replaced by a C version, this is needed. This fixes an API bug between the shell script and the helper. Currently the helper accepts "--reference" "--reference=foo" as

[PATCHv3 9/9] submodule--helper: use parallel processor correctly.

When developing the prior patches I had a temporary state in which git-clone would segfault, when prepared the call in prepare_to_clone_next_submodule. This lead to the call failing, i.e. in `update_clone_task_finished` the task was scheduled to be tried again. The second call to

[PATCHv3 1/9] t7408: modernize style

No functional change intended. This commit only changes formatting to the style we recently use, e.g. starting the body of a test with a single quote on the same line as the header, and then having the test indented in the following lines. Whenever we change directories, we do that in subshells.

[PATCHv3 2/9] t7408: merge short tests, factor out testing method

Tests consisting of one line each can be consolidated to have fewer tests to run as well as fewer lines of code. When having just a few git commands, do not create a new shell but use the -C flag in Git to execute in the correct directory. Signed-off-by: Stefan Beller ---

[PATCHv3 3/9] submodule--helper module-clone: allow multiple references

Allow users to pass in multiple references, just as clone accepts multiple references as well. Signed-off-by: Stefan Beller --- builtin/submodule--helper.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/builtin/submodule--helper.c

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

On 08/09/2016 12:36 AM, Junio C Hamano wrote: > Michael Haggerty writes: > >> Is it *really* so insane to consider moving collaboration on the Git >> project to GitHub or some other similar platform? > > I only know how "pull requests" and "issues" discussion in GitHub >

Re: What's cooking in git.git (Aug 2016, #03; Mon, 8)

On Mon, Aug 8, 2016 at 3:32 PM, Junio C Hamano wrote: > > * sb/submodule-clone-rr (2016-08-06) 6 commits > - clone: reference flag is used for submodules as well > - submodule update: add super-reference flag > - submodule--helper update-clone: allow multiple references > -

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

Michael Haggerty writes: > Is it *really* so insane to consider moving collaboration on the Git > project to GitHub or some other similar platform? I only know how "pull requests" and "issues" discussion in GitHub Web interface _currently_ looks like, so if you have even

What's cooking in git.git (Aug 2016, #03; Mon, 8)

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. Many topics in "Cooking" section

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

On 08/04/2016 05:58 PM, Johannes Schindelin wrote: > [...] > Even requiring every contributor to register with GitHub would be too much > of a limitation, I would wager. > [...] Is it *really* so insane to consider moving collaboration on the Git project to GitHub or some other similar platform?

Re: [PATCH v10 00/40] libify apply and use lib in am, part 2

Christian Couder writes: > diff --git a/apply.h b/apply.h > index 27a3a7a..e2b89e8 100644 > --- a/apply.h > +++ b/apply.h > @@ -16,7 +16,7 @@ enum apply_ws_ignore { > enum apply_verbosity { > verbosity_silent = -1, > verbosity_normal = 0, > -

Re: [PATCH v10 33/40] environment: add set_index_file()

Christian Couder writes: > Now if someone really needs to use this new function, it should be > used like this: > > /* Save current index file */ > old_index_file = get_index_file(); > set_index_file((char *)tmp_index_file); > > /* Do stuff that will

Re: [PATCH v10 00/40] libify apply and use lib in am, part 2

On Mon, Aug 8, 2016 at 11:02 PM, Christian Couder wrote: > > I will send a diff between this version and the previous one, as a > reply to this email. Here is the diff: diff --git a/apply.c b/apply.c index a73889e..2ec2a8a 100644 --- a/apply.c +++ b/apply.c @@

[PATCH v2] .mailmap: use Christian Couder's Tuxfamily address

Signed-off-by: Christian Couder --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index a714e69..9441a54 100644 --- a/.mailmap +++ b/.mailmap @@ -33,6 +33,7 @@ Cheng Renquan Chris Shoemaker

[PATCH v10 24/40] builtin/apply: make write_out_one_result() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", write_out_one_result() should just return what remove_file() and create_file() are returning instead of

[PATCH v10 38/40] apply: change error_routine when silent

To avoid printing anything when applying with `state->apply_verbosity == verbosity_silent`, let's save the existing warn and error routines before applying, and let's replace them with a routine that does nothing. Then after applying, let's restore the saved routines. Helped-by: Stefan Beller

[PATCH v10 26/40] builtin/apply: make try_create_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", try_create_file() should return -1 in case of error. Unfortunately try_create_file() currently returns -1 to

[PATCH v10 27/40] builtin/apply: make create_one_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", create_one_file() should return -1 instead of calling exit(). Signed-off-by: Christian Couder

[PATCH v10 32/40] apply: use error_errno() where possible

To avoid possible mistakes and to uniformly show the errno related messages, let's use error_errno() where possible. Signed-off-by: Christian Couder --- apply.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/apply.c b/apply.c

[PATCH v10 29/40] apply: rename and move opt constants to apply.h

The constants for the "inaccurate-eof" and the "recount" options will be used in both "apply.c" and "builtin/apply.c", so they need to go into "apply.h", and therefore they need a name that is more specific to the API they belong to. Signed-off-by: Christian Couder ---

[PATCH v10 34/40] apply: make it possible to silently apply

This changes 'int apply_verbosely' into 'enum apply_verbosity', and changes the possible values of the variable from a bool to a tristate. The previous 'false' state is changed into 'verbosity_normal'. The previous 'true' state is changed into 'verbosity_verbose'. The new added state is

[PATCH v10 39/40] apply: refactor `git apply` option parsing

Parsing `git apply` options can be useful to other commands that want to call the libified apply functionality, because this way they can easily pass some options from their own command line to the libified apply functionality. This will be used by `git am` in a following patch. To make this

[PATCH v10 16/40] builtin/apply: make gitdiff_*() return 1 at end of header

The gitdiff_*() functions that are called as p->fn() in parse_git_header() should return 1 instead of -1 in case of end of header or unrecognized input, as these are not real errors. It just instructs the parser to break out. This makes it possible for gitdiff_*() functions to return -1 in case

[PATCH v10 40/40] builtin/am: use apply api in run_apply()

This replaces run_apply() implementation with a new one that uses the apply api that has been previously prepared in apply.c and apply.h. This shoud improve performance a lot in certain cases. As the previous implementation was creating a new `git apply` process to apply each patch, it could be

[PATCH v10 08/40] builtin/apply: make parse_whitespace_option() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_whitespace_option() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v10 19/40] builtin/apply: make build_fake_ancestor() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", build_fake_ancestor() should return -1 instead of calling die(). Helped-by: Eric Sunshine

[PATCH v10 37/40] usage: add get_error_routine() and get_warn_routine()

Let's make it possible to get the current error_routine and warn_routine, so that we can store them before using set_error_routine() or set_warn_routine() to use new ones. This way we will be able put back the original routines, when we are done with using new ones. Signed-off-by: Christian

[PATCH v10 36/40] usage: add set_warn_routine()

There are already set_die_routine() and set_error_routine(), so let's add set_warn_routine() as this will be needed in a following commit. Signed-off-by: Christian Couder --- git-compat-util.h | 1 + usage.c | 5 + 2 files changed, 6 insertions(+) diff

[PATCH v10 28/40] builtin/apply: rename option parsing functions

As these functions are going to be part of the libified apply api, let's give them a name that is more specific to the apply api. Signed-off-by: Christian Couder --- builtin/apply.c | 40 1 file changed, 20 insertions(+), 20

[PATCH v10 18/40] builtin/apply: change die_on_unsafe_path() to check_unsafe_path()

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", die_on_unsafe_path() should return a negative integer instead of calling die(), so while doing that let's

[PATCH v10 35/40] apply: don't print on stdout in verbosity_silent mode

When apply_verbosity is set to verbosity_silent nothing should be printed on both stderr and stdout. To avoid printing on stdout, we can just skip calling the following functions: - stat_patch_list(), - numstat_patch_list(), - summary_patch_list(). It is safe to do that

[PATCH v10 01/40] apply: make some names more specific

To prepare for some structs and constants being moved from builtin/apply.c to apply.h, we should give them some more specific names to avoid possible name collisions in th global namespace. Signed-off-by: Christian Couder --- builtin/apply.c | 20 ++-- 1

[PATCH v10 14/40] builtin/apply: make apply_all_patches() return 128 or 1 on error

To finish libifying the apply functionality, apply_all_patches() should not die() or exit() in case of error, but return either 128 or 1, so that it gives the same exit code as when die() or exit(1) is called. This way scripts relying on the exit code don't need to be changed. While doing that we

[PATCH v10 20/40] builtin/apply: make remove_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", remove_file() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v10 13/40] builtin/apply: move check_apply_state() to apply.c

To libify `git apply` functionality we must make check_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into "apply.c". Signed-off-by: Christian Couder --- apply.c | 32 apply.h | 1 +

[PATCH v10 17/40] builtin/apply: make gitdiff_*() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", gitdiff_*() functions should return -1 instead of calling die(). A previous patch made it possible for

[PATCH v10 07/40] builtin/apply: make parse_single_patch() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_single_patch() should return a negative integer instead of calling die(). Let's do that by using error()

[PATCH v10 33/40] environment: add set_index_file()

Introduce set_index_file() to be able to temporarily change the index file. Yeah, this is a short cut and this new function should not be used by other code. It adds a small technical debt, because unfortunately a very big technical debt already exists as the apply code and a lot of other

[PATCH v10 15/40] builtin/apply: make parse_traditional_patch() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", parse_traditional_patch() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v10 31/40] apply: make some parsing functions static again

Some parsing functions that were used in both "apply.c" and "builtin/apply.c" are now only used in the former, so they can be made static to "apply.c". Signed-off-by: Christian Couder --- apply.c | 6 +++--- apply.h | 5 - 2 files changed, 3 insertions(+), 8

[PATCH v10 25/40] builtin/apply: make write_out_results() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", write_out_results() should return -1 instead of calling exit(). Helped-by: Eric Sunshine

[PATCH v10 11/40] apply: make init_apply_state() return -1 instead of exit()ing

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", init_apply_state() should return -1 instead of calling exit(). Signed-off-by: Christian Couder

[PATCH v10 23/40] builtin/apply: make create_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", create_file() should just return what add_conflicted_stages_file() and add_index_file() are returning

[PATCH v10 21/40] builtin/apply: make add_conflicted_stages_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", add_conflicted_stages_file() should return -1 instead of calling die(). Helped-by: Eric Sunshine

[PATCH v10 06/40] builtin/apply: make parse_chunk() return a negative integer on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing or exit()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_chunk() should return a negative integer instead of calling die() or exit(). As

[PATCH v10 03/40] builtin/apply: make apply_patch() return -1 or -128 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. As a first step in this direction, let's make apply_patch() return -1 or -128 in case of errors instead of dying. For now its only caller apply_all_patches() will exit(128) when apply_patch() return

[PATCH v10 09/40] builtin/apply: make parse_ignorewhitespace_option() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", parse_ignorewhitespace_option() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v10 05/40] builtin/apply: make find_header() return -128 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, let's make find_header() return -128 instead of calling die(). We could make it return -1, unfortunately

[PATCH v10 02/40] apply: move 'struct apply_state' to apply.h

To libify `git apply` functionality we must make 'struct apply_state' usable outside "builtin/apply.c". Let's do that by creating a new "apply.h" and moving 'struct apply_state' there. Signed-off-by: Christian Couder --- apply.h | 100

[PATCH v10 12/40] builtin/apply: make check_apply_state() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", check_apply_state() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v10 22/40] builtin/apply: make add_index_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", add_index_file() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v10 10/40] builtin/apply: move init_apply_state() to apply.c

To libify `git apply` functionality we must make init_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into a new "apply.c". Helped-by: Eric Sunshine Signed-off-by: Christian Couder --- Makefile| 1 + apply.c

[PATCH v10 04/40] builtin/apply: read_patch_file() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. Let's do that by returning -1 instead of die()ing in read_patch_file(). Helped-by: Stefan Beller Signed-off-by: Christian Couder --- builtin/apply.c | 8

[PATCH v10 00/40] libify apply and use lib in am, part 2

Goal This is a patch series about libifying `git apply` functionality, and using this libified functionality in `git am`, so that no 'git apply' process is spawn anymore. This makes `git am` significantly faster, so `git rebase`, when it uses the am backend, is also significantly faster.

Re: [PATCH v5] pack-objects: teach it to use reachability bitmap index when generating non-stdout pack too

Kirill Smelkov writes: > diff --git a/Documentation/config.txt b/Documentation/config.txt > index bc1c433..4ba0c4a 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -2244,6 +2244,9 @@ pack.useBitmaps:: > to stdout (e.g., during the server side

Re: t0027 racy?

On Mon, Aug 08, 2016 at 11:29:26AM -0400, Jeff King wrote: > On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote: > > > I remember that you did a ton of work on t0027. Now I see problems, and > > not only that the entire script now takes a whopping 4 minutes 20 seconds > > to run

Re: [PATCH] merge: use string_list_split() in add_strategies()

Junio C Hamano writes: > If the input comes from the end user, we certainly would want to > allow "word1 word2\tword3 " as input (i.e. squishing repeated Any intelligent reader may have guessed already, but before I stupidly told Emacs to refill the paragraph, the above

Re: storing cover letter of a patch series?

Stefan Beller writes: > On Thu, Sep 10, 2015 at 9:28 AM, Jacob Keller wrote: >> Hey, >> >> does anyone know of any tricks for storing a cover letter for a patch >> series inside of git somehow? I'd guess the only obvious way currently >> is to store

Re: [PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

On Mon, Aug 08, 2016 at 12:06:13PM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> + if grep -qFf nonlocal-loose 1.objects; then > >> + echo "Non-local object present in pack generated with --local" > >> + return 1 > >> + fi > >> +' > > > > grep -f

Re: [PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

Kirill Smelkov writes: > 8< > From: Kirill Smelkov > Subject: [PATCH v3] pack-objects: Teach --use-bitmap-index codepath to respect > --local, --honor-pack-keep and --incremental (Not a question to Kirill) Hmph. I suspect that handling of in-body

Re: [PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

Jeff King writes: >> +if grep -qFf nonlocal-loose 1.objects; then >> +echo "Non-local object present in pack generated with --local" >> +return 1 >> +fi >> +' > > grep -f isn't portable. However, I think: > > echo $objsha1 >expect && > git

Re: [PATCH v4 2/2] pack-objects: Teach it to use reachability bitmap index when generating non-stdout pack too

On Mon, Aug 08, 2016 at 11:28:02AM -0700, Junio C Hamano wrote: > Kirill Smelkov writes: > > > Another question: I'm preparing another version of "pack-objects: Teach > > --use-bitmap-index codepath to respect --local ..." and was going to > > put > > > > ( updated patch is

[PATCH v3] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

Since 6b8fda2d (pack-objects: use bitmaps when packing objects) there are two codepaths in pack-objects: with & without using bitmap reachability index. However add_object_entry_from_bitmap(), despite its non-bitmapped counterpart add_object_entry(), in no way does check for whether --local or

[PATCH v5] pack-objects: teach it to use reachability bitmap index when generating non-stdout pack too

Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects) if a repository has bitmap index, pack-objects can nicely speedup "Counting objects" graph traversal phase. That however was done only for case when resultant pack is sent to stdout, not written into a file. The reason here

Re: Forward declaration of enum iterator_selection?

On 08/08/16 19:28, Ramsay Jones wrote: > > > On 08/08/16 17:30, Johannes Sixt wrote: >> Am 07.08.2016 um 22:34 schrieb Ramsay Jones: >>> On 05/08/16 23:26, Johannes Sixt wrote: > [snip] >>> At this point 'enum iterator_selection' is an incomplete type and may >>> be used when the size of the

Re: Forward declaration of enum iterator_selection?

On 08/08/16 17:30, Johannes Sixt wrote: > Am 07.08.2016 um 22:34 schrieb Ramsay Jones: >> On 05/08/16 23:26, Johannes Sixt wrote: [snip] >> At this point 'enum iterator_selection' is an incomplete type and may >> be used when the size of the object is not required. It is not needed, >> for

Re: [PATCH v4 2/2] pack-objects: Teach it to use reachability bitmap index when generating non-stdout pack too

Kirill Smelkov writes: > Another question: I'm preparing another version of "pack-objects: Teach > --use-bitmap-index codepath to respect --local ..." and was going to > put > > ( updated patch is in the end of this mail ) > > in the top of the message. Is it ok or better

Re: t0027 racy?

On 2016-08-08 17.05, Johannes Schindelin wrote: > Hi Torsten, > > I remember that you did a ton of work on t0027. Now I see problems, and > not only that the entire script now takes a whopping 4 minutes 20 seconds > to run on my high-end Windows machine. > > It appears that t0027 fails randomly

Re: [PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

( updated patch is in the end of this mail ) Jeff, first of all thanks for commenting, On Mon, Aug 08, 2016 at 09:50:20AM -0400, Jeff King wrote: > On Mon, Aug 08, 2016 at 03:37:35PM +0300, Kirill Smelkov wrote: > > > @@ -958,15 +958,30 @@ static int want_object_in_pack(const unsigned char >

Re: [PATCHv2 0/6] git clone: Marry --recursive and --reference

On Sat, Aug 6, 2016 at 10:29 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> Some submodules in the referenced superproject may not be there, >> (they are just not initialized/cloned/checked out), which yields >> an error for now. > > Perhaps you

Re: [PATCH v4 2/2] pack-objects: Teach it to use reachability bitmap index when generating non-stdout pack too

On Mon, Aug 08, 2016 at 11:08:34AM -0700, Junio C Hamano wrote: > Kirill Smelkov writes: > > > Thanks for the info. I did not knew about show-index when I was starting > > to work on this and later it just came out of sight. Please find > > corrected patch below. > > > > 8<

Re: [PATCH v4 2/2] pack-objects: Teach it to use reachability bitmap index when generating non-stdout pack too

Kirill Smelkov writes: > Thanks for the info. I did not knew about show-index when I was starting > to work on this and later it just came out of sight. Please find > corrected patch below. > > 8< > From: Kirill Smelkov > Date: Fri, 29 Jul 2016

Re: [PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

Josh Triplett writes: > I didn't realize you had already taken the patch series into next; I'd > assumed from the various comments that you expected me to reroll it > before you'd take it. > > Would you like me to write something up for the release notes regarding > plans

Re: [PATCH] merge: use string_list_split() in add_strategies()

Johannes Schindelin writes: > I wonder, however, if we could somhow turn things around by introducing > something like > > split_and_do_for_each(item_p, length, string, delimiter) > ... ... > > that both string_list_split() *and* add_strategies()

Re: storing cover letter of a patch series?

Duy Nguyen writes: > git-notes was mentioned in this thread back in 2015, but I think it's > discarded because of the argument that's part of the cover letter was > not meant to be kept permanently. I do not think the reason why we didn't think the notes mechanism was a good

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

Lars Schneider writes: > ... then I am always super > eager to send out a new roll just because I don't want any other reviewer > to waste time on obviously wrong patches. However, I have the impression > that frequent re-rolls are frowned upon.

Re: storing cover letter of a patch series?

On Thu, Sep 10, 2015 at 9:28 AM, Jacob Keller wrote: > Hey, > > does anyone know of any tricks for storing a cover letter for a patch > series inside of git somehow? I'd guess the only obvious way currently > is to store it at the top of the series as an empty commit.. but

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

Johannes Schindelin writes: > I think you both got it wrong. The original citizens were the mail > clients that allowed you to communicate with other human beings. > ... It is our usage to transport machine-readable content (and not > as an attachment!) that is the

Re: [PATCH v2 7/7] pack-objects: use mru list when iterating over packs

Jeff King writes: >> It worries me a lot to lose the warning unconditionally, though. >> That's the (only) coal-mine canary that lets us notice a problem >> when we actually start hitting that last-ditch cycle breaking too >> often. > > The dedicated cycle-detection will lose that

Re: [PATCH v5 9/9] status: unit tests for --porcelain=v2

Jeff Hostetler writes: > +test_expect_success pre_initial_commit_0 ' > + ... > + git status --porcelain=v2 --branch --untracked-files=normal >actual && > + test_cmp expect actual > +' > + > + > +test_expect_success pre_initial_commit_1 ' > + git add file_x

Re: [PATCH v2 7/7] pack-objects: use mru list when iterating over packs

On Mon, Aug 08, 2016 at 09:28:29AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Here's a list of approaches I think we can use to fix this: > > > > 1. squelch the warning and ignore it. The downside here, besides not > > warning the user about true in-pack

Re: [PATCH v2 7/7] pack-objects: use mru list when iterating over packs

Jeff King writes: > Here's a list of approaches I think we can use to fix this: > > 1. squelch the warning and ignore it. The downside here, besides not > warning the user about true in-pack cycles, is that we have no > opportunity to actually find a new delta (because

Re: Forward declaration of enum iterator_selection?

Am 07.08.2016 um 22:34 schrieb Ramsay Jones: On 05/08/16 23:26, Johannes Sixt wrote: When refs.c is being compiled, the only mention of enum iterator_selection is in this piece of code pulled in from refs-internal.h(have a look at the preprocessed code): typedef enum iterator_selection

Re: [PATCH v4 11/12] convert: add filter..process option

On Mon, Aug 08, 2016 at 06:21:18PM +0200, Lars Schneider wrote: > >> Happy answer with no content: > >> > >> packet: git< status=success\n > >> > > > > This can just be spelled: > > > > git< status=success > > git< > > git<

Re: [PATCH v4 11/12] convert: add filter..process option

> On 08 Aug 2016, at 17:02, Jeff King wrote: > > On Sat, Aug 06, 2016 at 08:19:28PM +0200, Lars Schneider wrote: > >>> I dunno. It's not _that_ big a deal to code around. I was just surprised >>> not to see an up-front status when responding to a request. It seems >>> like the

Re: [PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

Kirill Smelkov writes: >> > ... >> > Suggested-by: Junio C Hamano >> > Discussed-with: Jeff King >> > --- >> >> I do not think I suggested much of this to deserve credit like this, >> though, as I certainly haven't thought about the

Re: [PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

Jeff King writes: > On Mon, Aug 08, 2016 at 03:37:35PM +0300, Kirill Smelkov wrote: > ... > static int want_object_in_pack(...) > { > ... > if (!exclude && local && has_loose_object_nonlocal(sha1)) > return 0; > > if (*found_pack) { >

Re: [PATCH v4 2/2] pack-objects: Teach it to use reachability bitmap index when generating non-stdout pack too

On Mon, Aug 08, 2016 at 09:56:00AM -0400, Jeff King wrote: > On Fri, Jul 29, 2016 at 10:47:46AM +0300, Kirill Smelkov wrote: > > > @@ -2527,7 +2528,7 @@ static int get_object_list_from_bitmap(struct > > rev_info *revs) > > if (prepare_bitmap_walk(revs) < 0) > > return -1; > > >

Re: t0027 racy?

On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote: > I remember that you did a ton of work on t0027. Now I see problems, and > not only that the entire script now takes a whopping 4 minutes 20 seconds > to run on my high-end Windows machine. > > It appears that t0027 fails

  1   2   >