Whenever a git command is present in the upstream of a pipe, its failure
gets masked by piping and hence it should be avoided for testing the
upstream git command. By writing out the output of the git command to
a file, we can test the exit codes of both the commands as a failure exit
code in any c
From: Prathamesh
Whenever a git command is present in the upstream of a pipe, its failure
gets masked by piping and hence it should be avoided for testing the
upstream git command. By writing out the output of the git command to
a file, we can test the exit codes of both the commands as a failure
Jeff King writes:
> If we parse a remote alternates (or http-alternates), we
> expect relative lines like:
>
> ../../foo.git/objects
>
> which we convert into "$URL/../foo.git/" (and then use that
> as a base for fetching more objects).
>
> But if the remote feeds us nonsense like just:
>
> .
Prathamesh Chavan writes:
> From: Prathamesh
Your e-mail header says
From: Prathamesh Chavan
and you probably have "[user] name = Prathamesh" somewhere in your
config, and I think that is why we see the above line in format-patch
output and on your sign-off. If you really prefer to
Brandon Williams writes:
> +struct attr_check *attr_check_dup(const struct attr_check *check)
> +{
> + struct attr_check *ret;
> +
> + if (!check)
> + return NULL;
> +
> + ret = attr_check_alloc();
> +
> + ret->nr = check->nr;
> + ret->alloc = check->alloc;
> +
Nikhil Benesch writes:
> This commit is a revival of Lars Hjemli's 2009 patch to provide an
> option to include submodules in the output of `git archive`.
>
> The `--recurse-submodules` option (named consistently with fetch, clone,
> and ls-files) will recursively traverse submodules in the repos
Jean-Noel Avila writes:
> +#. type: Title =
> +#: git-add.txt:2
> +#, no-wrap
> +msgid "git-add(1)"
> +msgstr "git-add(1)"
> +
> +#. type: Title -
> +#: git-add.txt:5
> +#, no-wrap
> +msgid "NAME"
> +msgstr "NOM"
> +
> +#
> +#. type: Plain text
> +#: git-add.txt:7
> +msgid "git-add - Add file con
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-25.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub is
This patch is only a preview and a request for comment. The tool used to
perform the localization of manpages is po4a (po for anything). This tool
digests the asciidoc source files and writes a pot file, and then merges back
the po files into translated asciidoc files, for further processing.
T
On Sun, Mar 12, 2017 at 04:51:19PM +, brian m. carlson wrote:
> Yeah, my goal was basically to pass -fsyntax-only, not to produce useful
> object files. My patch does basically require that the user have
> OpenSSL installed, but I do, so it doesn't matter.
>
> I considered after the fact tha
Providing git in localized version is a good step for general adoption
of the tool. But as of now, if one needs to refer to the manual pages,
they are still confronted to english. The aim is to provide
documentation to users in their own language.
Signed-off-by: Jean-Noel Avila
---
Documentation
This is first attempt at starting the internationalisation of the git
man pages. For now, only man pages are generated, only for git-add and
only in french. The chosen tool for this is po4a (PO for anything)
which can ingest asciidoc files and spit po files for each structural
entity. Then from th
Jeff King writes:
> One further devil's advocate:
>
> If people really _do_ care about coverage, arguably the AFL tests are a
> pollution of that concept. Because they are running the code, but doing
> a very perfunctory job of testing it. IOW, our coverage of "code that
> doesn't segfault or tri
Jeff King writes:
> I can think of one downside of a time-based solution, though: if you run
> multiple gc's during the time period, you may end up using a lot of disk
> space (one repo's worth per gc). But that's a fundamental tension in the
> problem space; the whole point is to waste disk to k
Jeff King writes:
> diff --git a/Makefile b/Makefile
> index 9f0eae428..0d65d50e9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -690,6 +690,7 @@ XDIFF_LIB = xdiff/lib.a
> VCSSVN_LIB = vcs-svn/lib.a
>
> GENERATED_H += common-cmds.h
> +GENERATED_H += hash.h
> ...
> -BASIC_CFLAGS += -DSHA1_HEADE
Ævar Arnfjörð Bjarmason writes:
> And then later in the documentation:
>
> -l , --list
>
> I.e. for git-branch this type of invocation wouldn't make sense and
> would just happen to work, but for git-tag the --list option is
> explicitly documented to immediately take a argument.
But that
On Sun, Mar 12, 2017 at 09:01:49AM -0400, Jeff King wrote:
> On Sat, Mar 11, 2017 at 10:28:18PM +, brian m. carlson wrote:
>
> > Many developers use functionality in their editors that allows for quick
> > syntax checks, including warning about questionable constructs. This
> > functionality
On 12/03/2017 13:32, Jeff King wrote:
If people really _do_ care about coverage, arguably the AFL tests are a
pollution of that concept. Because they are running the code, but doing
a very perfunctory job of testing it. IOW, our coverage of "code that
doesn't segfault or trigger ASAN" is improved
On Sat, Mar 11, 2017 at 10:28:18PM +, brian m. carlson wrote:
> Many developers use functionality in their editors that allows for quick
> syntax checks, including warning about questionable constructs. This
> functionality allows rapid development with fewer errors. However, such
> function
On Fri, Mar 10, 2017 at 10:50:50PM +0100, Christian Couder wrote:
> I don't think it's a good idea to add those "hint: ..." and
> "reporting-bugs: ..." lines.
>
> I think it's better to do things like the following:
>
> - add `git version -h`
> - add proper documentation for `git version` so tha
On Sun, Mar 12, 2017 at 08:38:53AM -0400, Jeff King wrote:
> I posted this last week in the middle of another thread[1], but it
> didn't get any attention. So here it is again.
Oops, that [1] should be:
http://public-inbox.org/git/20170304034914.cgyvz735lxhe2...@sigill.intra.peff.net/
-Peff
If we parse a remote alternates (or http-alternates), we
expect relative lines like:
../../foo.git/objects
which we convert into "$URL/../foo.git/" (and then use that
as a base for fetching more objects).
But if the remote feeds us nonsense like just:
../
we will try to blindly strip the l
On Fri, Mar 10, 2017 at 11:58:13PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> I observe the following coverage changes (for t5300 only):
> >>
> >> path old% new%pp
> >>
> >> builtin/index-pack.c 74.3 76.6 2.3
> >> pack-writ
On Fri, Mar 10, 2017 at 10:18:23PM +0100, Vegard Nossum wrote:
> On 10/03/2017 20:42, Jeff King wrote:
> > > > That's something I guess, but I'm not enthused by the idea of just
> > > > dumping a bunch of binary test cases that nobody, not even the author,
> > > > understands.
> [...]
>
> > My re
On Fri, Mar 10, 2017 at 03:43:43PM -0800, Junio C Hamano wrote:
> James Melvin writes:
>
> > The new --preserve-and-prune option renames old pack files
> > instead of deleting them after repacking and prunes previously
> > preserved pack files.
> >
> > This option is designed to prevent stale fi
On Sat, Mar 11, 2017 at 12:08:55PM +, Ævar Arnfjörð Bjarmason wrote:
> Jeff King pointed out in
> <20170310124247.jvrmmcz2pbv4q...@sigill.intra.peff.net> in reply to
> that::
>
> The difference between "branch" and "tag" here is that "branch
> --contains" implies "--list" (and the arg
On Sat, Mar 11, 2017 at 09:01:25PM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Mar 9, 2017 at 2:29 PM, Jeff King wrote:
> > [...]
> > @@ -1874,6 +1886,8 @@ int filter_refs(struct ref_array *array, struct
> > ref_filter *filter, unsigned int
> > broken = 1;
> > filter-
On Sun, Mar 12, 2017 at 4:19 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change these invocations which currently error out without the -l, to
>> behave as if though -l was provided:
>>
>> git tag -l [--contains|--points-at|--[no-]merged]
>
> Shouldn't this be
>
>
On Sun, Mar 12, 2017 at 3:51 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> Junio: This will merge conflict with my in-flight --no-contains
>>> patch. I can re-send either one depending on which you want to accept
>>> first, this patch will need an additional test for --no-cont
On Sun, Mar 12, 2017 at 5:44 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change the tag, branch & for-each-ref commands to have a --no-contains
>> option in addition to their longstanding --contains options.
>>
>> The use-case I have for this is to find the last-good rollout
30 matches
Mail list logo
