On Tue, Jun 27, 2017 at 1:11 AM, Prathamesh Chavan wrote:
> +static char *get_up_path(const char *path)
> +{
> + int i = count_slashes(path);
> + int l = strlen(path);
Nit: "l" is quite similar to "i" in many fonts, so maybe use "len"
instead of "l", but see below.
> + struct
On the Solaris system here __BYTE_ORDER__ set to 4321 and _BIG_ENDIAN
is defined, but has no value.
The problem is the not short circuiting macro...
-8<--
#undef _FOO1
#undef _FOO2
#undef _FOO2
#undef _BAR1
#undef _BAR2
#undef _BAR3
#define _F
On Tue, Jun 27, 2017 at 1:11 AM, Prathamesh Chavan wrote:
> +
> + if (!is_submodule_populated_gently(list_item->name, NULL))
> + goto cleanup;
> +
> + prepare_submodule_repo_env(&cp.env_array);
> + /* For the purpose of executing in the submodule,
> +* sepa
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 test
Still no luck.
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 Windows?
> For that
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 Githu
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 dangerous, as "plain"
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
Web
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 =
parse_fetch_recurse_submodules_arg("--recurse-submodules-default",
recurse_su
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 "somebody
>> stupidly removed one func
Which exact outputs of Git are invoked?
Does it change when giving slightly different options e.g. --no-pager?
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
> line movement det
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 C
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. And hence, a hack was used instead. But afte
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
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 f
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
Signed-off-by: Prathamesh Chavan
-
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 functi
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
Mentored-by: Stefan
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 t
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 Git'
Junio C Hamano writes:
+ filter->string = "";
+ continue;
+ }
+
+ /* In dco->paths we store a list of all delayed paths.
+ The filter just send us a list of availa
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 also terminated with a flush p
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 warning about usage of explicit paths
>
--
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
Hello, important charity foundation proposal to discuss with you, if you are
interested please reply urgently for details.
with love,
CELINE
> 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 requests). During this process the Git checkout
>> o
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");
});
app.listen(p
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.
>
> Signed-off-by: James
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" refs to
> be updated by a
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 wait until the filter is d
> 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 write "OUT " to the debug log even in case
of
an abort or error. Fix this by writi
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 b/sha1d
* ?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) && (_BYTE_ORDER == _BIG_ENDIAN)
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
> > that are allowed
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
dropping the "tracking/" part wi
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 the Git style guide.
>
> Sign
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.
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 writing "OUT " to the debug log only in
>>> the successful case if outp
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] sha1_file: improve sha1_object_info_extended
Improve sha1_
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 files. Please state what
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() by supporting additional flags. This
>>> a
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 modified to use
>> sha
* 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. Mak
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 read_object
> - sha
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 has_sha1_file_with_flags
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 pack-data struct as
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 DC_SHA1_SUBMODULE=auto due to this bit in the Makefil
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
---
This was noticed tha
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
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 '==' has no right operand
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)) || \
>
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
Mich
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 individu
> 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: automatically enable when submodule is popula
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 a submodule
>>
>> Th
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 are connected
>> to already listed tags
> 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 case if output is actually written.
>
> Again,
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 creating this fixup, I'll
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 this
>> topic cannot
> 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 it is _wrong_ to modify after
> comparing it,
> 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" implementation of SHA-1 hash
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. If I'm reading things
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] Erro
64 matches
Mail list logo
