Re: [Resurrection Remix] #substratum # nice? Come on 100 +1 xx

مساء الخير بتاريخ 25‏/3‏/2017، كتب Google+ (‪Hugo R3s3nd3 BeZaInA‬‏)‏ : > نشر ‪Hugo R3s3nd3 BeZaInA‬‏ مشاركة مع Resurrection Remix. عرض: >

Re: What's cooking in git.git (Mar 2017, #10; Fri, 24)

Brandon Williams writes: > On 03/24, Junio C Hamano wrote: >> * bw/recurse-submodules-relative-fix (2017-03-17) 5 commits >> - ls-files: fix bug when recursing with relative pathspec >> - ls-files: fix typo in variable name >> - grep: fix bug when recursing with relative

--no-commit option does not work.

Setup Version : git version 2.12.1.windows.1 OS Version : Microsoft Windows [Version 10.0.14393] Options $ cat /etc/install-options.txt Path Option: Cmd SSH Option: OpenSSH CURL Option: OpenSSL CRLF Option: CRLFCommitAsIs Bash Terminal Option: MinTTY Performance Tweaks FSCache: Enabled Use

Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

René Scharfe writes: > FreeBSD implements getcwd(3) as a syscall, but falls back to a version > based on readdir(3) if it fails for some reason. The latter requires > permissions to read and execute path components, while the former does > not. That means that if our buffer is

Re: [PATCH v3 2/2] l10n: Add git-add.txt to localized man pages

Jean-Noël AVILA writes: > ... So I would > think the other way around: for those interested in translated the > documentation, some script would allow to checkout the git project inside the > gitman-l10n project (like a kind of library). > > This would be mainly transparent

Re: [PATCH] git-p4: Add failing test case for name-rev vs symbolic-ref

Luke Diamand writes: > As per the discussion about use of "git name-rev" vs "git symbolic-ref" in > git-p4 here: > > http://marc.info/?l=git=148979063421355 > > git-p4 could get confused about the branch it is on and affects > the git-p4.allowSubmit option. This adds a failing

Re: [PATCH v2 3/3] rev-parse: match ^{} case-insensitively

Ævar Arnfjörð Bjarmason writes: > Change the revision parsing logic to match ^{commit}, ^{tree}, ^{blob} > etc. case-insensitively. > > Before this change supplying anything except the lower-case forms > emits an "unknown revision or path not in the working tree" > error. This

Re: [PATCH 0/7] PREVIEW: Introduce DC_AND_OPENSSL_SHA1 make flag

On Sun, Mar 26, 2017 at 04:16:06PM -0700, Junio C Hamano wrote: > > I don't think this case really matters for collision detection. What's > > important is what Git does when it receives a brand-new packfile that > > would overwrite an existing one. It _should_ keep the old one, under the > >

Re: [PATCH v2 3/3] rev-parse: match ^{} case-insensitively

On Sun, Mar 26, 2017 at 05:36:21PM -0700, Junio C Hamano wrote: > It's not "potential confusion". This closes the door for us to > introduce "TREE" as a separate object type in the future. > > If we agree to make a declaration that all typenames are officially > spelled in lowercase [*1*] and

[PATCH v2 1/3] rev-parse: match @{upstream}, @{u} and @{push} case-insensitively

Change the revision parsing logic to match @{upstream}, @{u} & @{push} case-insensitively. Before this change supplying anything except the lower-case forms emits an "unknown revision or path not in the working tree" error. This change makes upper-case & mixed-case versions equivalent to the

[PATCH v2 0/3] rev-parse case insensitivity & @{p} synonym

This v2 addresses the feedback on my "rev-parse: match @{u}, @{push} and ^{} case-insensitively" patch. I've split this into a 3 patch series: Ævar Arnfjörð Bjarmason (3): rev-parse: match @{upstream}, @{u} and @{push} case-insensitively Reworded the documentation as Junio suggested in

[PATCH v2 2/3] rev-parse: add @{p} as a synonym for @{push}

Add @{p} as a shorthand for @{push} for consistency with the @{u} shorthand for @{upstream}. This wasn't added when @{push} was introduced in commit adfe5d0434 ("sha1_name: implement @{push} shorthand", 2015-05-21), but it can be added without any ambiguity and saves the user some typing.

[PATCH v2 3/3] rev-parse: match ^{} case-insensitively

Change the revision parsing logic to match ^{commit}, ^{tree}, ^{blob} etc. case-insensitively. Before this change supplying anything except the lower-case forms emits an "unknown revision or path not in the working tree" error. This change makes upper-case & mixed-case versions equivalent to the

Re: [PATCH v3 1/2] [GSoC] dir_iterator: iterate over dir after its contents

On 03/25/2017 07:12 PM, Daniel Ferreira wrote: > Create an option for the dir_iterator API to iterate over a directory > path only after having iterated through its contents. This feature was > predicted, although not implemented by 0fe5043 ("dir_iterator: new API > for iterating over a directory

Re: [PATCH 0/7] PREVIEW: Introduce DC_AND_OPENSSL_SHA1 make flag

Jeff King writes: > On Fri, Mar 24, 2017 at 11:37:54PM -0700, Junio C Hamano wrote: > >> The hash that names a packfile is constructed by sorting all the >> names of the objects contained in the packfile and running SHA-1 >> hash over it. I think this MUST be hashed with

Re: [PATCH v2 2/3] rev-parse: add @{p} as a synonym for @{push}

On Sun, Mar 26, 2017 at 12:16:53PM +, Ævar Arnfjörð Bjarmason wrote: > Add @{p} as a shorthand for @{push} for consistency with the @{u} > shorthand for @{upstream}. > > This wasn't added when @{push} was introduced in commit > adfe5d0434 ("sha1_name: implement @{push} shorthand",

Re: [PATCH v2 2/3] sequencer: make commit options more extensible

Johannes Schindelin writes: >> Making "flags" unsigned was a correct change, but this is now wrong, >> as "allow" is made unsigned by accident. > ... > > Your patch looks good, you could do even better by reverting that move > (IIRC it was at the end of the line, and

Re: [PATCH] pretty: add extra headers and MIME boundary directly

On Sun, Mar 26, 2017 at 03:41:14PM +0200, René Scharfe wrote: > Am 25.03.2017 um 22:11 schrieb Jeff King: > > The most correct way is that the caller of log_write_email_headers() and > > diff_flush() should have a function-local strbuf which holds the data, > > gets passed to diff_flush() as some

Re: [PATCH v2 1/3] rev-parse: match @{upstream}, @{u} and @{push} case-insensitively

Ævar Arnfjörð Bjarmason writes: > The ^{} suffix could be changed to be case-insensitive as well > without introducing any ambiguities. That was included in an earlier > version of this patch, but Junio objected to its inclusion in [2]. We try not to be personal in our log

Re: [PATCH v3 1/2] [GSoC] dir_iterator: iterate over dir after its contents

On 03/25/2017 07:12 PM, Daniel Ferreira wrote: > Create an option for the dir_iterator API to iterate over a directory > path only after having iterated through its contents. This feature was > predicted, although not implemented by 0fe5043 ("dir_iterator: new API > for iterating over a directory

Re: [PATCH v3 2/4] refs: introduce get_worktree_ref_store()

On Mon, Mar 20, 2017 at 9:25 PM, Michael Haggerty wrote: > Instead of moving all of the `for_each_*_submodule()` functions over, I > encourage you to consider getting rid of them entirely and let the > end-users call the `refs_for_each_*()` versions of the functions. Again,

Re: [PATCH] pretty: add extra headers and MIME boundary directly

Am 25.03.2017 um 22:11 schrieb Jeff King: > The most correct way is that the caller of log_write_email_headers() and > diff_flush() should have a function-local strbuf which holds the data, > gets passed to diff_flush() as some kind opaque context, and then is > freed afterwards. We don't have

[PATCH v2 11/21] sha1_name: convert struct disambiguate_state to object_id

Convert struct disambiguate_state to use struct object_id by changing the structure definition and applying the following semantic patch: @@ struct disambiguate_state E1; @@ - E1.bin_pfx + E1.bin_pfx.hash @@ struct disambiguate_state *E1; @@ - E1->bin_pfx + E1->bin_pfx.hash @@ struct

[PATCH v2 03/21] Convert GIT_SHA1_RAWSZ used for allocation to GIT_MAX_RAWSZ

Since we will likely be introducing a new hash function at some point, and that hash function might be longer than 20 bytes, use the constant GIT_MAX_RAWSZ, which is designed to be suitable for allocations, instead of GIT_SHA1_RAWSZ. This will ease the transition down the line by distinguishing

[PATCH v2 13/21] submodule: convert check_for_new_submodule_commits to object_id

All of the callers of this function have been converted, so convert this function and update the callers. This function also calls sha1_array_append, which we'll convert shortly. Signed-off-by: brian m. carlson --- builtin/fetch.c | 6 +++--- submodule.c | 4

[PATCH v2 20/21] Rename sha1_array to oid_array

Since this structure handles an array of object IDs, rename it to struct oid_array. Also rename the accessor functions and the initialization constant. This commit was produced mechanically by providing non-Documentation files to the following Perl one-liners: perl -pi -E 's/struct

[PATCH v2 04/21] builtin/diff: convert to struct object_id

Signed-off-by: brian m. carlson --- builtin/diff.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/builtin/diff.c b/builtin/diff.c index 3d64b85337..398eee00d5 100644 --- a/builtin/diff.c +++ b/builtin/diff.c

[PATCH v2 06/21] builtin/receive-pack: fix incorrect pointer arithmetic

If we had already processed the last newline in a push certificate, we would end up subtracting NULL from the end-of-certificate pointer when computing the length of the line. This would have resulted in an absurdly large length, and possibly a buffer overflow. Instead, subtract the

[PATCH v2 15/21] sha1-array: convert internal storage for struct sha1_array to object_id

Make the internal storage for struct sha1_array use an array of struct object_id internally. Update the users of this struct which inspect its internals. Signed-off-by: brian m. carlson --- bisect.c | 14 +++--- builtin/pull.c | 22

[PATCH v2 14/21] builtin/pull: convert to struct object_id

Convert virtually all uses of unsigned char [20] to struct object_id. Leave all the arguments that come from struct sha1_array, as these will be converted in a later patch. Signed-off-by: brian m. carlson --- builtin/pull.c | 72

[PATCH v2 01/21] Define new hash-size constants for allocating memory

Since we will want to transition to a new hash at some point in the future, and that hash may be larger in size than 160 bits, introduce two constants that can be used for allocating a sufficient amount of memory. They can be increased to reflect the largest supported hash size. Signed-off-by:

[PATCH v2 02/21] Convert GIT_SHA1_HEXSZ used for allocation to GIT_MAX_HEXSZ

Since we will likely be introducing a new hash function at some point, and that hash function might be longer than 40 hex characters, use the constant GIT_MAX_HEXSZ, which is designed to be suitable for allocations, instead of GIT_SHA1_HEXSZ. This will ease the transition down the line by

[PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

FreeBSD implements getcwd(3) as a syscall, but falls back to a version based on readdir(3) if it fails for some reason. The latter requires permissions to read and execute path components, while the former does not. That means that if our buffer is too small and we're missing rights we could get

[PATCH v2 00/21] object_id part 7

This is part 7 in the continuing transition to use struct object_id. This series focuses on two main areas: adding two constants for the maximum hash size we'll be using (which will be suitable for allocating memory) and converting struct sha1_array to struct oid_array. The rationale for adding

[PATCH v2 16/21] Make sha1_array_append take a struct object_id *

Convert the callers to pass struct object_id by changing the function declaration and definition and applying the following semantic patch: @@ expression E1, E2, E3; @@ - sha1_array_append(E1, E2[E3].hash) + sha1_array_append(E1, E2 + E3) @@ expression E1, E2; @@ - sha1_array_append(E1, E2.hash)

[PATCH v2 18/21] Convert sha1_array_lookup to take struct object_id

Convert this function by changing the declaration and definition and applying the following semantic patch to update the callers: @@ expression E1, E2; @@ - sha1_array_lookup(E1, E2.hash) + sha1_array_lookup(E1, ) @@ expression E1, E2; @@ - sha1_array_lookup(E1, E2->hash) + sha1_array_lookup(E1,

[PATCH v2 08/21] fsck: convert init_skiplist to struct object_id

Convert a hardcoded constant buffer size to a use of GIT_MAX_HEXSZ, and use parse_oid_hex to reduce the dependency on the size of the hash. This function is a caller of sha1_array_append, which will be converted later. Signed-off-by: brian m. carlson --- fsck.c |

[PATCH v2 21/21] Documentation: update and rename api-sha1-array.txt

Since the structure and functions have changed names, update the code examples and the documentation. Rename the file to match the new name of the API. Signed-off-by: brian m. carlson --- .../{api-sha1-array.txt => api-oid-array.txt} | 44

[PATCH v2 10/21] test-sha1-array: convert most code to struct object_id

This helper is very small, so convert the entire thing. Signed-off-by: brian m. carlson --- t/helper/test-sha1-array.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/t/helper/test-sha1-array.c b/t/helper/test-sha1-array.c index

[PATCH v2 17/21] Convert remaining callers of sha1_array_lookup to object_id

There are a very small number of callers which don't already use struct object_id. Convert them. Signed-off-by: brian m. carlson --- bisect.c | 14 +++--- builtin/pack-objects.c | 16 ref-filter.c | 22

[PATCH v2 05/21] builtin/pull: convert portions to struct object_id

Convert the caller of sha1_array_append to struct object_id. Signed-off-by: brian m. carlson --- builtin/pull.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/pull.c b/builtin/pull.c index 3ecb881b0b..a9f7553f30 100644 ---

[PATCH v2 19/21] Convert sha1_array_for_each_unique and for_each_abbrev to object_id

Make sha1_array_for_each_unique take a callback using struct object_id. Since one of these callbacks is an argument to for_each_abbrev, convert those as well. Rename various functions, replacing "sha1" with "oid". Signed-off-by: brian m. carlson ---

[PATCH v2 07/21] builtin/receive-pack: convert portions to struct object_id

Convert some hardcoded constants into uses of parse_oid_hex. Additionally, convert all uses of struct command, and miscellaneous other functions necessary for that. This work is necessary to be able to convert sha1_array_append later on. To avoid needing to specify a constant, reject shallow

[PATCH v2 12/21] sha1_name: convert disambiguate_hint_fn to take object_id

Convert this function pointer type and the functions that implement it to take a struct object_id. Introduce a temporary in show_ambiguous_object to avoid having to convert for_each_abbrev at this point. Signed-off-by: brian m. carlson --- sha1_name.c | 64

[PATCH v2 09/21] parse-options-cb: convert sha1_array_append caller to struct object_id

Signed-off-by: brian m. carlson --- parse-options-cb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/parse-options-cb.c b/parse-options-cb.c index b7d8f7dcb2..40ece4d8c2 100644 --- a/parse-options-cb.c +++ b/parse-options-cb.c @@ -96,7

[PATCH] contrib/subtree: add "--no-commit" flag for merge and pull

Allows the user to verify and/or change the contents of the merge before committing as necessary Signed-off-by: Mike Lewis --- contrib/subtree/git-subtree.sh | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/contrib/subtree/git-subtree.sh

[PATCH] git-p4: Add failing test case for name-rev vs symbolic-ref

As per the discussion about use of "git name-rev" vs "git symbolic-ref" in git-p4 here: http://marc.info/?l=git=148979063421355 git-p4 could get confused about the branch it is on and affects the git-p4.allowSubmit option. This adds a failing test case for the problem. Luke Diamand (1):

[PATCH] git-p4: add failing test for name-rev rather than symbolic-ref

Using name-rev to find the current git branch means that git-p4 does not correctly get the current branch name if there are multiple branches pointing at HEAD, or a tag. This change adds a test case which demonstrates the problem. Configuring which branches are allowed to be submitted from goes

Re: --no-commit option does not work.

BongHo Lee writes: > If I add --no-ff option, it works properly. > I think --no-commit option should be worked without --no-ff. It is understandable that this is confusing, but --no-commit is an instruction not to create a new commit object. As fast-forwarding to the commit

Re: [PATCH v2 3/3] rev-parse: match ^{} case-insensitively

Jeff King writes: > FWIW, I cannot see us ever adding TREE (or Tree) as a separate type. > It's too confusing for no gain. We'd call it "tree2" or something more > obvious. In case it was not clear, I didn't mean to say I _want_ to leave that door open. Well, I cannot imagine it

Re: [PATCH 0/7] PREVIEW: Introduce DC_AND_OPENSSL_SHA1 make flag

On Fri, Mar 24, 2017 at 11:37:54PM -0700, Junio C Hamano wrote: > The hash that names a packfile is constructed by sorting all the > names of the objects contained in the packfile and running SHA-1 > hash over it. I think this MUST be hashed with collision-attack > detection. A malicious site