From: Junio C Hamano <gitster@pobox.com>
To: "Haritha D via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Haritha <harithamma.d@ibm.com>
Subject: Re: [PATCH 02/13] Enable builds for z/OS.
Date: Tue, 14 Nov 2023 09:48:09 +0900 [thread overview]
Message-ID: <xmqqcywd2m9i.fsf@gitster.g> (raw)
In-Reply-To: <098b9ca8ece4fdce45a9b48e576b474ed81dced1.1699871056.git.gitgitgadget@gmail.com> (Haritha D. via GitGitGadget's message of "Mon, 13 Nov 2023 10:24:04 +0000")
"Haritha D via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Subject: Re: [PATCH 02/13] Enable builds for z/OS.
Documentation/CodingGuidelines and Documentation/SubmittingPatches
would help here, I think.
> # Define SHELL_PATH to a POSIX shell if your /bin/sh is broken.
> #
> +# Define SHELL_PATH_FOR_SCRIPTS to a POSIX shell if your /bin/sh is broken.
The reason to exist for the _FOR_SCRIPTS variants is not justified
anywhere in the proposed log message.
The former should be sufficient, and our policy is to let the
builder specify exactly what binaries the build products depend on,
(instead of random $PATH interfere with the choice by using
"#!/bin/env tool" that also has to assume that everybody's "env" is
installed in "/bin").
This patch has too many #ifdefs in the primary codepaths. Your
porting strategy may need to be rethought. Our usual convention is
to encapsulate these platform differences as much as possible in
git-compat-util.h and platform specific files in compat/ directory.
> diff --git a/builtin/hash-object.c b/builtin/hash-object.c
> index 5ffec99dcea..b33b32ff977 100644
> --- a/builtin/hash-object.c
> +++ b/builtin/hash-object.c
> @@ -57,11 +57,39 @@ static void hash_fd(int fd, const char *type, const char *path, unsigned flags,
> maybe_flush_or_die(stdout, "hash to stdout");
> }
>
> +#ifdef __MVS__
> +# if (__CHARSET_LIB == 1)
> +# include <stdio.h>
> +# include <stdlib.h>
> +
> + int setbinaryfd(int fd)
> + {
> + attrib_t attr;
> + int rc;
Ahh, OK, I saw [03/13] first and was utterly confused by this thing.
Do not send in such a mess that introduces broken code in an early
step that you need to later say "oops that one was broken and I need
to fix it up with this patch". "rebase -i" is your friend to clean
up your mess into a logical progression to help readers better
understand what you wrote.
I'll stop here.
next prev parent reply other threads:[~2023-11-14 0:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 10:24 [PATCH 00/13] Enabling z/OS workflow for git Haritha via GitGitGadget
2023-11-13 10:24 ` [PATCH 01/13] " Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 02/13] Enable builds for z/OS Haritha D via GitGitGadget
2023-11-13 23:03 ` brian m. carlson
2023-11-14 1:47 ` Junio C Hamano
2023-11-14 0:48 ` Junio C Hamano [this message]
2023-11-13 10:24 ` [PATCH 03/13] spaces and errors fix Handled git pipeline errors Haritha D via GitGitGadget
2023-11-14 0:38 ` Junio C Hamano
2023-11-13 10:24 ` [PATCH 04/13] fixes for build errors Handled git pipeline errorse Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 05/13] fixes for build errors Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 06/13] spaces and errors fix Handled git pipeline errors Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 07/13] " Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 08/13] platform_name " Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 09/13] strncpy " Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 10/13] " Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 11/13] " Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 12/13] Handled git pipeline errors - Memory leak Haritha D via GitGitGadget
2023-11-13 10:24 ` [PATCH 13/13] Handled git pipeline errors - z/OS enable Haritha D via GitGitGadget
2023-12-04 14:19 ` [PATCH v2] This PR enables a successful git build on z/OS Haritha via GitGitGadget
2023-12-04 21:46 ` Eric Sunshine
2023-12-05 20:58 ` René Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqcywd2m9i.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=harithamma.d@ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).