Re: Compile Error v2.13.2 on Solaris SPARC

2017-06-26 22:27 GMT+02:00 Ævar Arnfjörð Bjarmason : > Could you (or anyone else for that matter) please test it with: > > git clone --branch bigend-detect-solaris-again > https://github.com/avar/sha1collisiondetection.git && > cd sha1collisiondetection && > make

Re: Bug: Cannot kill Nodejs process using ctrl + c

Appreciate it. Thanks a lot. Regards, Gyandeep Singh Website: http://gyandeeps.com On Mon, Jun 26, 2017 at 10:15 PM, Stefan Beller wrote: > I miss-read your email. > > So you are not running Git, but only talk about the (Git-)bash that is > conveniently bundled with Git for

Re: Bug: Cannot kill Nodejs process using ctrl + c

I miss-read your email. So you are not running Git, but only talk about the (Git-)bash that is conveniently bundled with Git for Windows? For that I recommend https://github.com/git-for-windows/git/issues/new Johannes Schindelin the GfW maintainer is cc'd here as well, but AFAICT he prefers

Re: --color-moved feedback, was Re: [PATCH v2 19/29] packed-backend: new module for handling packed references

On Fri, Jun 23, 2017 at 6:10 PM, Jeff King wrote: > On Fri, Jun 23, 2017 at 01:23:52PM -0700, Stefan Beller wrote: > >> > In the end, I just did --color-moved=plain, ... >> > "yep, this is all a giant moved chunk, so I don't have to look carefully >> > at it". >> >> This is

Re: Bug: Cannot kill Nodejs process using ctrl + c

Not sure what you mean by output. But its just goes back to normal like this Gyandeep@Gyandeep MINGW64 ~ $ It was working fine on first release of git 2.13. It broken with releases after that. Will try with –no-pager flag and let you tomorrow. Thanks Gyandeep Regards, Gyandeep Singh

Re: [PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing

On Fri, Jun 23, 2017 at 5:51 PM, Junio C Hamano wrote: if (recurse_submodules != RECURSE_SUBMODULES_OFF) { - if (recurse_submodules_default) { - int arg =

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

On Fri, Jun 23, 2017 at 6:01 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> But for the purpose of this "moved line coloring", >> excluding multiple copy destinations of the same thing may be a >> simpler and more robust solution. It will not catch

Re: Bug: Cannot kill Nodejs process using ctrl + c

Which exact outputs of Git are invoked? Does it change when giving slightly different options e.g. --no-pager?

Re: [PATCH v6 5/6] convert: move multiple file filter error handling to separate function

On Mon, Jun 26, 2017 at 10:56 AM, Junio C Hamano wrote: > Not about this patch, but viewing this with > > git show -w --color-moved=zebra > > gives an interesting result. The bulk of the part moved are > re-indented, and the comment string gets zebra stripes, as if the

Re: [PATCH] pack-bitmap: Don't perform unaligned memory access

James Clarke wrote: > The preceding bitmap entries have a 1-byte XOR-offset and 1-byte flags, > so their size is not a multiple of 4. Thus the name-hash cache is only > guaranteed to be 2-byte aligned and so we must use get_be32 rather than > indexing the array directly. > > Signed-off-by: James

Re: [GSoC] Update: Week 5

On Tue, Jun 20, 2017 at 5:31 AM, Andrew Ardill wrote: > On 20 June 2017 at 07:41, Prathamesh Chavan wrote: > >>But as communicating between child_process is still an issue >>and so there was no simple was to current carry out the >>porting.

[GSoC][PATCH 4/6 v2] submodule: port submodule subcommand status

The mechanism used for porting submodule subcommand 'status' is similar to that used for subcommand 'foreach'. The function cmd_status from git-submodule is ported to three functions in the builtin submodule--helper namely: module_status, for_each_submodule_list and status_submodule. print_status

[GSoC][PATCH 5/6 v2] submodule: port submodule subcommand sync from shell to C

The mechanism used for porting the submodule subcommand 'sync' is similar to that of 'foreach', where we split the function cmd_sync from shell into three functions in C, module_sync, for_each_submodule_list and sync_submodule. print_default_remote is introduced as a submodule--helper subcommand

[GSoC][PATCH 1/6 v2] submodule--helper: introduce for_each_submodule_list

Introduce function for_each_submodule_list for using it in the later patches, related to porting submodule subcommands from shell to C. This new function is also used in ported submodule subcommand init. Mentored-by: Christian Couder Mentored-by: Stefan Beller

[GSoC][PATCH 2/6 v2] submodule: port subcommand foreach from shell to C

This aims to make git-submodule foreach a builtin. This is the very first step taken in this direction. Hence, 'foreach' is ported to submodule--helper, and submodule--helper is called from git-submodule.sh. The code is split up to have one function to obtain all the list of submodules. This

[GSoC][PATCH 6/6 v2] submodule: port submodule subcommand 'deinit' from shell to C

The same mechanism is used even for porting this submodule subcommand, as used in the ported subcommands till now. The function cmd_deinit in split up after porting into three functions: module_deinit, for_each_submodule_list and deinit_submodule. Mentored-by: Christian Couder

[GSoC][PATCH 3/6 v2] submodule: port set_name_rev from shell to C

Since later on we want to port submodule subcommand status, and since set_name_rev is part of cmd_status, hence this function is ported. It has been ported to function print_name_rev in C, which calls get_name_rev to get the revname, and after formatting it, print_name_rev prints it. And hence in

[GSoC] Update: Week 6

SUMMARY OF MY PROJECT: Git submodule subcommands are currently implemented by using shell script 'git-submodule.sh'. There are several reasons why we'll prefer not to use the shell script. My project intends to convert the subcommands into C code, thus making them builtins. This will increase

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

Junio C Hamano writes: + filter->string = ""; + continue; + } + + /* In dco->paths we store a list of all delayed paths. + The filter just send

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

Lars Schneider writes: > Maybe this? > [...] If Git sends this command, then the > filter is expected to return a list of pathnames representing blobs > that have been delayed earlier and are now available. [...] OK. >>> +by a "success" status that is

Re: [PATCH/RFC] commit-template: improve readability of commit template

Kaartic Sivaraam writes: > * Previously the commit template didn't separate the > distinct messages shown. This resulted in difficulty > in interpreting it's content. Add new lines to separate > the distinct parts of the template. > > * Previously the

Dear Beloved

-- Dear Beloved Friend, I am Mrs Nicole Benoite Marois and I have been suffering from ovarian cancer disease and the doctor says that i have just few weeks to leave. I am from (Paris) France but based in Benin republic since eleven years ago as a business woman dealing with gold exportation

let me know

Hello, important charity foundation proposal to discuss with you, if you are interested please reply urgently for details. with love, CELINE

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

> On 26 Jun 2017, at 21:02, Junio C Hamano wrote: > > Lars Schneider writes: > >> Some `clean` / `smudge` filters might require a significant amount of >> time to process a single blob (e.g. the Git LFS smudge filter might >> perform network

Re: Bug: Cannot kill Nodejs process using ctrl + c

Environment: OS: Windows 7 Git: git version 2.13.1.windows.2 NodeJS: 8.1.2 Steps: 1. Create a js file with content const http = require('http'); const fs = require('fs'); const port = 3000; const app = http.createServer((req,res) => { res.writeHead(200); res.end("hi"); });

Re: [PATCH] pack-bitmap: Don't perform unaligned memory access

James Clarke writes: > The preceding bitmap entries have a 1-byte XOR-offset and 1-byte flags, > so their size is not a multiple of 4. Thus the name-hash cache is only > guaranteed to be 2-byte aligned and so we must use get_be32 rather than > indexing the array directly. > >

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

Marc Branchaud writes: > OTOH, we shouldn't need to do any conflict resolution on these > "tracking" refs: The remote side should update the refs > properly. Nobody should make local changes to these refs. > > I guess I'm advocating that git should only allow "tracking"

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

Lars Schneider writes: > Some `clean` / `smudge` filters might require a significant amount of > time to process a single blob (e.g. the Git LFS smudge filter might > perform network requests). During this process the Git checkout > operation is blocked and Git needs to

Re: [PATCH v6 3/6] t0021: write "OUT" only on success

> On 26 Jun 2017, at 19:50, Junio C Hamano wrote: > > Lars Schneider writes: > >>> On 26 Jun 2017, at 00:17, Junio C Hamano wrote: >>> >>> Lars Schneider writes: >>> "rot13-filter.pl" used to

Re: Compile Error v2.13.2 on Solaris SPARC

On Mon, Jun 26 2017, Michael Kebe jotted: > Still no luck, with one or both patches. Could you please attach (or pastebin or whatever) your copy of /usr/include/sys/isa_defs.h? And what Solaris/Illumos/Whatever version is this? Maybe this patch works for you: diff --git a/sha1dc/sha1.c

Re: Compile Error v2.13.2 on Solaris SPARC

* ?var Arnfj?r? Bjarmason [170626 08:47]: > > On Mon, Jun 26 2017, Michael Kebe jotted: > > > No luck with the patch. > > > > Still got: > > > > CC sha1dc/sha1.o > > sha1dc/sha1.c:43:58: error: operator '==' has no right operand > > (defined(_BYTE_ORDER) &&

Re: [PATCH] submodule--helper: teach push-check to handle HEAD

On 06/23, Junio C Hamano wrote: > Brandon Williams writes: > > > In 06bf4ad1d (push: propagate remote and refspec with > > --recurse-submodules) push was taught how to propagate a refspec down to > > submodules when the '--recurse-submodules' flag is given. The only refspecs

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

On 2017-06-23 04:54 PM, Junio C Hamano wrote: Jacob Keller writes: Instead, lets add support for a new refs/tracking/* hierarchy which is laid out in such a way to avoid this inconsistency. All refs in "refs/tracking//*" will include the complete ref, such that

Re: [PATCH v6 5/6] convert: move multiple file filter error handling to separate function

Lars Schneider writes: > Refactoring the filter error handling is useful for the subsequent patch > 'convert: add "status=delayed" to filter process protocol'. > > In addition, replace the parentheses around the empty "if" block with a > single semicolon to adhere to

Re: [PATCH v6 5/6] convert: move multiple file filter error handling to separate function

Not about this patch, but viewing this with git show -w --color-moved=zebra gives an interesting result. The bulk of the part moved are re-indented, and the comment string gets zebra stripes, as if the line movement detection code does not realize that these came from the same place.

Re: [PATCH v6 3/6] t0021: write "OUT" only on success

Lars Schneider writes: >> On 26 Jun 2017, at 00:17, Junio C Hamano wrote: >> >> Lars Schneider writes: >> >>> "rot13-filter.pl" used to write "OUT " to the debug log even in case >>> of >>> an abort or error. Fix this by

Re: [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended

On Mon, Jun 26, 2017 at 10:28 AM, Junio C Hamano wrote: > Jonathan Tan writes: > >> On Sat, Jun 24, 2017 at 5:45 AM, Jeff King wrote: >>> On Mon, Jun 19, 2017 at 06:03:13PM -0700, Jonathan Tan wrote: >>> Subject: [PATCH v4 6/8]

Re: [PATCH v6 1/6] t0021: keep filter log files on comparison

Lars Schneider writes: >> It would become a problem _if_ we want future users of this helper >> to reuse the same expect (or actual) multiple times and start from >> an unmodified one. There may be some other reason why you do not >> want the comparison to smudge these

Re: [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended

Jonathan Tan writes: > On Sat, Jun 24, 2017 at 5:45 AM, Jeff King wrote: >> On Mon, Jun 19, 2017 at 06:03:13PM -0700, Jonathan Tan wrote: >> >>> Subject: [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended >>> Improve sha1_object_info_extended()

Re: [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended

Jeff King writes: > On Mon, Jun 19, 2017 at 06:03:13PM -0700, Jonathan Tan wrote: > >> Subject: [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended >> Improve sha1_object_info_extended() by supporting additional flags. This >> allows has_sha1_file_with_flags() to be

[PATCH/RFC] commit-template: improve readability of commit template

* Previously the commit template didn't separate the distinct messages shown. This resulted in difficulty in interpreting it's content. Add new lines to separate the distinct parts of the template. * Previously the warning about usage of explicit paths without any options wasn't clear.

Re: What's cooking in git.git (Jun 2017, #07; Sat, 24)

On Sat, 24 Jun 2017 16:25:13 -0700 Junio C Hamano wrote: > * jt/unify-object-info (2017-06-21) 8 commits > - sha1_file: refactor has_sha1_file_with_flags > - sha1_file: do not access pack if unneeded > - sha1_file: improve sha1_object_info_extended > - sha1_file: refactor

Re: [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended

On Sat, Jun 24, 2017 at 5:45 AM, Jeff King wrote: > On Mon, Jun 19, 2017 at 06:03:13PM -0700, Jonathan Tan wrote: > >> Subject: [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended >> Improve sha1_object_info_extended() by supporting additional flags. This >> allows

Re: [PATCH v4 7/8] sha1_file: do not access pack if unneeded

On Sat, Jun 24, 2017 at 1:39 PM, Jeff King wrote: > On Sat, Jun 24, 2017 at 11:41:39AM -0700, Junio C Hamano wrote: > If we are open to writing anything, then I think it should follow the > same pointer-to-data pattern that the rest of the struct does. I.e., > declare the extra

Re: What's cooking in git.git (Jun 2017, #07; Sat, 24)

Lars Schneider writes: >> On 26 Jun 2017, at 11:44, Ævar Arnfjörð Bjarmason wrote: >> >> If we're cloning the submodule, which from this output, and AFAIK in >> general happens with all Travis builds, but correct me if I'm wrong >> we'll set

[PATCH] pack-bitmap: Don't perform unaligned memory access

The preceding bitmap entries have a 1-byte XOR-offset and 1-byte flags, so their size is not a multiple of 4. Thus the name-hash cache is only guaranteed to be 2-byte aligned and so we must use get_be32 rather than indexing the array directly. Signed-off-by: James Clarke ---

[ANNOUNCE] Git for Windows 2.13.2

Dear Git users, It is my pleasure to announce that Git for Windows 2.13.2 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.13.1(2) (June 15th 2017) New Features * Comes with Git v2.13.2. * Comes with Git Credential Manager v1.10.1. * The Git

Re: Compile Error v2.13.2 on Solaris SPARC

Still no luck, with one or both patches. Greetings Michael 2017-06-26 14:47 GMT+02:00 Ævar Arnfjörð Bjarmason : > > On Mon, Jun 26 2017, Michael Kebe jotted: > >> No luck with the patch. >> >> Still got: >> >> CC sha1dc/sha1.o >> sha1dc/sha1.c:43:58: error: operator '=='

Re: Compile Error v2.13.2 on Solaris SPARC

On Mon, Jun 26 2017, Michael Kebe jotted: > No luck with the patch. > > Still got: > > CC sha1dc/sha1.o > sha1dc/sha1.c:43:58: error: operator '==' has no right operand > (defined(_BYTE_ORDER) && (_BYTE_ORDER == _BIG_ENDIAN)) || \ >

Re: Compile Error v2.13.2 on Solaris SPARC

No luck with the patch. Still got: CC sha1dc/sha1.o sha1dc/sha1.c:43:58: error: operator '==' has no right operand (defined(_BYTE_ORDER) && (_BYTE_ORDER == _BIG_ENDIAN)) || \ ^ gmake: *** [sha1dc/sha1.o] Error 1 Greetings

ANNOUNCE: A mailing list for git packaging discussion

Now that my PCRE v2 patches have landed, I wanted to prod packagers of git to tell them they could build against it since they probably had it packaged already. After E-Mailing Jonathan Nieder about that asking if there was a better way to contact packagers than hunting down their E-Mails

Re: What's cooking in git.git (Jun 2017, #07; Sat, 24)

> On 26 Jun 2017, at 11:44, Ævar Arnfjörð Bjarmason wrote: > > > On Mon, Jun 26 2017, Lars Schneider jotted: > >>> On 25 Jun 2017, at 01:25, Junio C Hamano wrote: >> >>> ... >> >>> * ab/sha1dc (2017-06-07) 2 commits >>> - sha1collisiondetection:

Re: What's cooking in git.git (Jun 2017, #07; Sat, 24)

On Mon, Jun 26 2017, Lars Schneider jotted: >> On 25 Jun 2017, at 01:25, Junio C Hamano wrote: > >> ... > >> * ab/sha1dc (2017-06-07) 2 commits >> - sha1collisiondetection: automatically enable when submodule is populated >> - sha1dc: optionally use sha1collisiondetection as

Re: Getting first tag per branch for a commit

On Mon, Jun 26, 2017 at 12:54 AM, Junio C Hamano wrote: > Orgad Shaneh writes: > >> What I'd like to have is a way to tell the first tag per branch (or >> per merge) that the commit appeared on. > >> I think that this can be done by filtering out tags that

Re: [PATCH v6 3/6] t0021: write "OUT" only on success

> On 26 Jun 2017, at 00:17, Junio C Hamano wrote: > > Lars Schneider writes: > >> "rot13-filter.pl" used to write "OUT " to the debug log even in case of >> an abort or error. Fix this by writing "OUT " to the debug log only in >> the successful

Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes

On 23/06/17 20:01, Junio C Hamano wrote: > Junio C Hamano writes: > >> For 3420, I can wrap the two-liner patch I showed here earlier into >> a commit on top of the series. > > So, here is what I'll queue on top before merging the topic down to > 'master'. Thanks for

Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes

On 23/06/17 19:53, Junio C Hamano wrote: > Junio C Hamano writes: > >> 3404 needs a similar fix-up for the series to be able to stand on >> its own. Alternatively, at least we need to understand what in 'pu' >> makes the result of the merge pass---the symptom indicates that

Re: [PATCH v6 1/6] t0021: keep filter log files on comparison

> On 26 Jun 2017, at 00:12, Junio C Hamano wrote: > > Lars Schneider writes: > >> The filter log files are modified on comparison. Write the modified log files >> to temp files for comparison to fix this. > > The phrase "to fix this" implies that

Re: What's cooking in git.git (Jun 2017, #07; Sat, 24)

> On 25 Jun 2017, at 01:25, Junio C Hamano wrote: > ... > * ab/sha1dc (2017-06-07) 2 commits > - sha1collisiondetection: automatically enable when submodule is populated > - sha1dc: optionally use sha1collisiondetection as a submodule > > The "collission-detecting"

Re: [PATCH v4 5/5] stash: implement builtin stash

Thomas Gummerer writes: > After the line > > test -n "$seen_non_option" || set "push" "$@" > > it's not possible that $# is 0 anymore, so this will never be > printed. From a quick look at the history it seems like it wasn't > possible to trigger that codepath for a while.

Compile Error v2.13.2 on Solaris SPARC

When compiling 2.13.2 on Solaris SPARC I get this error: CC sha1dc/sha1.o sha1dc/sha1.c:41:58: error: operator '==' has no right operand #if ((defined(_BYTE_ORDER) && (_BYTE_ORDER == _BIG_ENDIAN)) || \ ^ gmake: *** [sha1dc/sha1.o]