"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 lazily tried to
piggy-back
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) had a permanent GUID
> as
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, which is now reflec
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 you.
>
> Reviewed-by: Jonathan Nieder
Thanks, bo
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
---
Documentation/git-for-each-
"'"- (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: Taylo
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 argumen
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 non-trai
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 infor
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
"%(trailers:only,unfold)"
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 Documentation
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
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
NS
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 beginni
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
---
Documentation/git-for-each-
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 non-trai
"'"- (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: Taylo
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 infor
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 argumen
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
"%(trailers:only,unfold)"
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 Documentation/
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.
>
> I'
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
Mentored-by: Christian Couder
Mentore
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 \
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 respo
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 Cor
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 (an
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
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 [
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.
>
> He
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
--
===
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 quite a bit of
insult to injur
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
imp
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:
>
> %(contents:trailer
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 opti
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 %(traile
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.
>
37 matches
Mail list logo
