Re: "man git-checkout", man page is inconsistent between SYNOPSIS and details

"Robert P. J. Day" writes: > it's simply a matter of the forms not matching between the SYNOPSIS > and the DESCRIPTION sections. am i making sense? I think the whole thing is wrong and the root cause is because the (relatively newer) description of the "--patch" mode

Re: [idea] File history tracking hints

Jeff Hostetler writes: > On 9/29/2017 7:12 PM, Johannes Schindelin wrote: > >> Therefore, it would be good to have a way to tell Git about renames >> explicitly so that it does not even need to use its heuristics. > > Agreed. > > It would be nice if every file (and tree)

Re: [PATCH] Add a comment to .clang-format about the meaning of the file

Stephan Beyer writes: > Having a .clang-format file in a project can be understood in a way that code > has to be in the style defined by the .clang-format file, i.e., you just have > to run clang-format over all code and you are set. This is not the case in the > Git project,

Re: [PATCH] clang-format: adjust line break penalties

Jonathan Nieder writes: > Hi Dscho, > > Johannes Schindelin wrote: > >> Signed-off-by: Johannes Schindelin >> --- >> .clang-format | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) > > Well executed and well explained. Thank

[PATCH v3 5/6] ref-filter.c: use trailer_opts to format trailers

Fill trailer_opts with "unfold" and "only" to match the sub-arguments given to the "%(trailers)" atom. Then, let's use the filled trailer_opts instance with 'format_trailers_from_commit' in order to format trailers in the desired manner. Signed-off-by: Taylor Blau ---

[PATCH v3 4/6] doc: use modern "`"-style code fencing

"'"- (single-quote) styled code fencing is no longer considered modern within the "Documentation/" subtree. In preparation for adding additional information to this section of git-for-each-ref(1)'s documentation, update old-style code fencing to use "`"-style fencing instead. Signed-off-by:

[PATCH v3 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

The %(contents) atom takes a contents "field" as its argument. Since "trailers" is one of those fields, extend contents_atom_parser to parse "trailers"'s arguments when used through "%(contents)", like: %(contents:trailers:unfold,only) A caveat: trailers_atom_parser expects NULL when no

[PATCH v3 2/6] t6300: refactor %(trailers) tests

We currently have one test for %(trailers) in `git-for-each-ref(1)`, through "%(contents:trailers)". In preparation for more, let's add a few things: - Move the commit creation step to its own test so that it can be re-used. - Add a non-trailer to the commit's trailers to test that

[PATCH v3 3/6] doc: 'trailers' is the preferred way to format trailers

The documentation makes reference to 'contents:trailers' as an example to dig the trailers out of a commit. 'trailers' is an unmentioned alternative, which is treated as an alias of 'contents:trailers'. Since 'trailers' is easier to type, prefer that as the designated way to dig out trailers

[PATCH v3 1/6] pretty.c: delimit "%(trailers)" arguments with ","

In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or

Re: [PATCH v2 0/6] Support %(trailers) arguments in for-each-ref(1)

Hi, Attached is v3 of my patch-set "Support %(trailers) arguments in for-each-ref(1)". It includes all of the changes in V2: > * Accept "empty-sub-argument" lists, like %(contents:trailers:). > > * Fix incorrect tabs/spaces formatting in t6300. > > * Modern-ize code fencing in

Re: "man git-checkout", man page is inconsistent between SYNOPSIS and details

On Sat, 30 Sep 2017, Kevin Daudt wrote: > On Sat, Sep 30, 2017 at 05:27:22AM -0400, Robert P. J. Day wrote: > > > > just noticed that in "man git-checkout", the SYNOPSIS contains > > the line: > > > > git checkout [-p|--patch] [] [--] [...] > > > > implying that is optional, but further down

Re: RFC v3: Another proposed hash function transition plan

Dear Johannes, thanks for your response and taking the effort to express your concerns. Please see below for some feedback. On 30/09/17 00:33, Johannes Schindelin wrote: Hi Joan, On Fri, 29 Sep 2017, Joan Daemen wrote: if ever there was a SHA-2 competition, it must have been held inside

[PATCH] Add a comment to .clang-format about the meaning of the file

Having a .clang-format file in a project can be understood in a way that code has to be in the style defined by the .clang-format file, i.e., you just have to run clang-format over all code and you are set. This is not the case in the Git project, which is now reflected by an comment in the

[PATCH v2 5/6] ref-filter.c: use trailer_opts to format trailers

Fill trailer_opts with "unfold" and "only" to match the sub-arguments given to the "%(trailers)" atom. Then, let's use the filled trailer_opts instance with 'format_trailers_from_commit' in order to format trailers in the desired manner. Signed-off-by: Taylor Blau ---

[PATCH v2 2/6] t6300: refactor %(trailers) tests

We currently have one test for %(trailers) in `git-for-each-ref(1)`, through "%(contents:trailers)". In preparation for more, let's add a few things: - Move the commit creation step to its own test so that it can be re-used. - Add a non-trailer to the commit's trailers to test that

[PATCH v2 4/6] doc: use modern "`"-style code fencing

"'"- (single-quote) styled code fencing is no longer considered modern within the "Documentation/" subtree. In preparation for adding additional information to this section of git-for-each-ref(1)'s documentation, update old-style code fencing to use "`"-style fencing instead. Signed-off-by:

[PATCH v2 3/6] doc: 'trailers' is the preferred way to format trailers

The documentation makes reference to 'contents:trailers' as an example to dig the trailers out of a commit. 'trailers' is an unmentioned alternative, which is treated as an alias of 'contents:trailers'. Since 'trailers' is easier to type, prefer that as the designated way to dig out trailers

[PATCH v2 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

The %(contents) atom takes a contents "field" as its argument. Since "trailers" is one of those fields, extend contents_atom_parser to parse "trailers"'s arguments when used through "%(contents)", like: %(contents:trailers:unfold,only) A caveat: trailers_atom_parser expects NULL when no

[PATCH v2 1/6] pretty.c: delimit "%(trailers)" arguments with ","

In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or

[PATCH v2 0/6] Support %(trailers) arguments in for-each-ref(1)

Hi, Attached is v2 of my patch-set "Support %(trailers) arguments in for-each-ref(1)". It includes the following changes since v1: * Accept "empty-sub-argument" lists, like %(contents:trailers:). * Fix incorrect tabs/spaces formatting in t6300. * Modern-ize code fencing in

Re: [PATCH Outreachy] mru: use double-linked list from list.h

I added "v2" after "PATCH", but it does not appeared. Actually it was written automatically and it was "PATCH Outreachy v2". I rearranged it in the middle of the phrase. >> I forgot about leak. I also need to add checking in mru_clear. That's >> not beautiful solution but it works reliably. > >

[PATCH v2 Outreachy] mru: use double-linked list from list.h

Simplify mru.[ch] and related code by reusing the double-linked list implementation from list.h instead of a custom one. This commit is an intermediate step. Our final goal is to get rid of mru.[ch] at all and inline all logic. Signed-off-by: Olga Telezhnaia

git submodule add fails when using both --branch and --depth

I'm running git 2.14.2 on Ubuntu 16.04. Compare the behavior of > git clone --branch pu --depth 1 https://github.com/git/git git-pu which clones only the latest commit of the pu branch and > mkdir tmp && cd tmp && git init > git submodule add --branch pu --depth 1 https://github.com/git/git \

[no subject]

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your

Re: Reply Urgent

Hello, How are you doing? We have an inheritance of a deceased client with your surname. Contact Mr Andrew Bailey by this email address: ands...@europe.com with your full names for further information's. Thanks for your understanding. Melissa. -- Correo

Re: [idea] File history tracking hints

Hi Jeff, On Sat, 30 Sep 2017, Jeff Hostetler wrote: > On 9/29/2017 7:12 PM, Johannes Schindelin wrote: > > > Therefore, it would be good to have a way to tell Git about renames > > explicitly so that it does not even need to use its heuristics. > > Agreed. > > It would be nice if every file

Re: "man git-checkout", man page is inconsistent between SYNOPSIS and details

On Sat, 30 Sep 2017, Kevin Daudt wrote: > On Sat, Sep 30, 2017 at 05:27:22AM -0400, Robert P. J. Day wrote: > > > > just noticed that in "man git-checkout", the SYNOPSIS contains the > > line: > > > > git checkout [-p|--patch] [] [--] [...] > > > > implying that is optional, but further down

Re: "man git-checkout", man page is inconsistent between SYNOPSIS and details

On Sat, Sep 30, 2017 at 05:27:22AM -0400, Robert P. J. Day wrote: > > just noticed that in "man git-checkout", the SYNOPSIS contains the > line: > > git checkout [-p|--patch] [] [--] [...] > > implying that is optional, but further down in the > DESCRIPTION, one reads: > > git checkout

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

On 29/09/17 07:49, Pranit Bauva wrote: > `--next-all` is meant to be used as a subcommand to support multiple > "operation mode" though the current implementation does not contain any > other subcommand along side with `--next-all` but further commits will > include some more subcommands. > >

"man git-checkout", man page is inconsistent between SYNOPSIS and details

just noticed that in "man git-checkout", the SYNOPSIS contains the line: git checkout [-p|--patch] [] [--] [...] implying that is optional, but further down in the DESCRIPTION, one reads: git checkout [-p|--patch] [] [--] ... suggesting that is required. rday --

Re: [idea] File history tracking hints

On 9/29/2017 7:12 PM, Johannes Schindelin wrote: Hi Philip, On Fri, 15 Sep 2017, Philip Oakley wrote: From: "Johannes Schindelin" In light of such experiences, I have to admit that the notion that the rename detection can always be improved in hindsight puts

Re: [PATCH 0/5] Support %(trailers) arguments in for-each-ref(1)

On Fri, Sep 29, 2017 at 11:22:33PM -0700, Taylor Blau wrote: > Attached is a patch to extend Peff's recent work of adding parsing options to > "--pretty=%(trailers)" by supporting those same options in > git-for-each-ref(1). Thanks for working on this. The direction and general sketch of the

Re: [PATCH 5/5] ref-filter.c: parse trailers arguments with %(contents) atom

On Fri, Sep 29, 2017 at 11:22:38PM -0700, Taylor Blau wrote: > The %(contents) atom takes a contents "field" as its argument. Since > "trailers" > is one of those fields, extend contents_atom_parser to parse "trailers"'s > arguments when used through "%(contents)", like: > >

Re: [PATCH 4/5] ref-filter.c: use trailer_opts to format trailers

On Fri, Sep 29, 2017 at 11:22:37PM -0700, Taylor Blau wrote: > In preparation to support additional sub-arguments given to the "%(trailers)" > atom, use 'format_trailers_from_commit' in order to format trailers in the > desired manner. This isn't just in preparation, is it? It looks like the

Re: [PATCH 3/5] ref-filter.c: add trailer options to used_atom

On Fri, Sep 29, 2017 at 11:22:36PM -0700, Taylor Blau wrote: > In preparation for "%(trailers)" to take trailer parsing arguments, use Jeff's > convenience structure for trailer processing options introduced in 8abc89800c. > > We will later populate this field from the arguments given to

Re: [PATCH 2/5] t6300: refactor %(trailers) tests

On Fri, Sep 29, 2017 at 11:22:35PM -0700, Taylor Blau wrote: > We currently have one test for %(trailers) in `git-for-each-ref(1)`, through > "%(contents:trailers)". In preparation for more, let's add a few things: > > - Move the commit creation step to its own test so that it can be re-used.

Re: [PATCH 1/5] pretty.c: delimit "%(trailers)" arguments with ","

On Fri, Sep 29, 2017 at 11:22:34PM -0700, Taylor Blau wrote: > In preparation for adding consistent "%(trailers)" atom options to > `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c > to separate sub-arguments with a ",", instead of a ":". > > Multiple sub-arguments

[PATCH 5/5] ref-filter.c: parse trailers arguments with %(contents) atom

The %(contents) atom takes a contents "field" as its argument. Since "trailers" is one of those fields, extend contents_atom_parser to parse "trailers"'s arguments when used through "%(contents)", like: %(contents:trailers:unfold,only) A caveat: trailers_atom_parser expects NULL when no

[PATCH 3/5] ref-filter.c: add trailer options to used_atom

In preparation for "%(trailers)" to take trailer parsing arguments, use Jeff's convenience structure for trailer processing options introduced in 8abc89800c. We will later populate this field from the arguments given to %(trailers), and then use the trailer_opts instance to format ref trailers

[PATCH 4/5] ref-filter.c: use trailer_opts to format trailers

In preparation to support additional sub-arguments given to the "%(trailers)" atom, use 'format_trailers_from_commit' in order to format trailers in the desired manner. Signed-off-by: Taylor Blau --- Documentation/git-for-each-ref.txt | 6 +- ref-filter.c

[PATCH 0/5] Support %(trailers) arguments in for-each-ref(1)

Hi, Attached is a patch to extend Peff's recent work of adding parsing options to "--pretty=%(trailers)" by supporting those same options in git-for-each-ref(1). In summary, this patch adds correct behavior for the following options, when given to git-for-each-ref(1): *

[PATCH 2/5] t6300: refactor %(trailers) tests

We currently have one test for %(trailers) in `git-for-each-ref(1)`, through "%(contents:trailers)". In preparation for more, let's add a few things: - Move the commit creation step to its own test so that it can be re-used. - Add a non-trailer to the commit's trailers to test that

[PATCH 1/5] pretty.c: delimit "%(trailers)" arguments with ","

In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or