Re: [PATCH] mailmap: update brandon williams's email address

On Sat, Dec 8, 2018 at 7:09 AM Junio C Hamano wrote: > If this were "Jonathan asked Brandon if we want to record an address > we can reach him in our .mailmap file and sent a patch to add one", Not sure about Jonathan, but I did. > then the story is different, and I tend to agree with you that

Re: [PATCH] mailmap: update brandon williams's email address

On Sat, Dec 08 2018, Junio C Hamano wrote: > Stefan Beller writes: > >> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote: >>> >>> Brandon Williams wrote: >>> >>> > Signed-off-by: Brandon Williams >>> > --- >>> > .mailmap | 1 + >>> > 1 file changed, 1 insertion(+) >>> >>> I can confirm

Re: "git add -p" versus "git add -i", followed by "p"

On Sun, 2 Dec 2018, Duy Nguyen wrote: > On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote: > > > Patch update>> 2 > > > staged unstaged path > > > * 1:unchanged+1/-0 README.md > > > * 2:unchanged+1/-0 contrib/README > > > 3:unchanged

Re: [PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)

On Sat, Dec 8, 2018 at 9:11 AM wrote: > Changes since V2: latest patch still fixes original issue - thanks > - Settled on a better name: > The common code is in compat/win32/path-utils.c/h > [...] > - The "DOS" moniker is still used for 2 reasons: > Windows inherited the "drive letter"

[PATCH v4 0/7] %(trailers) improvements in pretty format

Updated since v3: * multiple 'key=' matches any * allow overriding implicit 'only' when using key * minor grammar and spelling fixes * documentation restructuring * Helper functions for parsing options Anders Waldenborg (7): doc: group pretty-format.txt placeholders descriptions pretty:

[PATCH v4 6/7] strbuf: separate callback for strbuf_expand:ing literals

Expanding '%n' and '%xNN' is generic functionality, so extract that from the pretty.c formatter into a callback that can be reused. No functional change intended Signed-off-by: Anders Waldenborg --- pretty.c | 16 +--- strbuf.c | 21 + strbuf.h | 8 3

[PATCH v4 5/7] pretty: add support for "valueonly" option in %(trailers)

With the new "key=" option to %(trailers) it often makes little sense to show the key, as it by definition already is knows which trailer is printed there. This new "valueonly" option makes it omit the key when printing trailers. E.g.: $ git show -s

[PATCH v4 1/7] doc: group pretty-format.txt placeholders descriptions

The placeholders can be grouped into three kinds: * literals * affecting formatting of later placeholders * expanding to information in commit Also change the list to a definition list (using '::') Signed-off-by: Anders Waldenborg --- Documentation/pretty-formats.txt | 235

[PATCH v4 2/7] pretty: allow %(trailers) options with explicit value

In addition to old %(trailers:only) it is now allowed to write %(trailers:only=yes) By itself this only gives (the not quite so useful) possibility to have users change their mind in the middle of a formatting string (%(trailers:only=true,only=false)). However, it gives users the opportunity to

[PATCH v4 7/7] pretty: add support for separator option in %(trailers)

By default trailer lines are terminated by linebreaks ('\n'). By specifying the new 'separator' option they will instead be separated by user provided string and have separator semantics rather than terminator semantics. The separator string can contain the literal formatting codes %n and %xNN

[PATCH v4 4/7] pretty: allow showing specific trailers

Adds a new "key=X" option to "%(trailers)" which will cause it to only print trailer lines which match any of the specified keys. Signed-off-by: Anders Waldenborg --- Documentation/pretty-formats.txt | 8 + pretty.c | 47 ++---

[PATCH v4 3/7] pretty: single return path in %(trailers) handling

No functional change intended. This change may not seem useful on its own, but upcoming commits will do memory allocation in there, and a single return path makes deallocation easier. Signed-off-by: Anders Waldenborg --- pretty.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

Re: why doesn't "git reset" mention optional pathspec?

On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote: > > > from "man git-reset": > > SYNOPSIS > git reset [-q] [] [--] ... > git reset (--patch | -p) [] [--] [...] > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > [] > > oddly, the third form says nothing about

Re: why doesn't "git reset" mention optional pathspec?

On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote: > > > > > > from "man git-reset": > > > > SYNOPSIS > > git reset [-q] [] [--] ... > > git reset (--patch | -p) [] [--] [...] > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep]

Re: why doesn't "git reset" mention optional pathspec?

On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > wrote: > > > > > > > > > from "man git-reset": > > > > > > SYNOPSIS > > > git reset [-q] [] [--] ... > > > git reset (--patch | -p) []

Re: why doesn't "git reset" mention optional pathspec?

On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > wrote: > > > > > > > > > > > > from "man git-reset": > > > > > > > > SYNOPSIS > > > >

Re: why doesn't "git reset" mention optional pathspec?

On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > wrote: > > > > > > > > > > > > from "man git-reset": > > > > > > > > SYNOPSIS > > > >

Re: why doesn't "git reset" mention optional pathspec?

On Sat, Dec 8, 2018 at 6:37 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day > > wrote: > > > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > > wrote: > >

why doesn't "git reset" mention optional pathspec?

from "man git-reset": SYNOPSIS git reset [-q] [] [--] ... git reset (--patch | -p) [] [--] [...] git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [] oddly, the third form says nothing about possible "", even though i'm pretty sure they're valid in that third case (at

Documentation: update "man git-add" to include "[]"

Current "man git-add" emphasizes single letter interactive shortcut commands with "[]". Signed-off-by: Robert P. J. Day --- diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 45652fe4a6..ad9bd7c7a6 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt

[PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)

From: Torsten Bögershausen A regression for cygwin users was introduced with commit 05b458c, "real_path: resolve symlinks by hand". In the the commit message we read: The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe

[wishlist] submodule.update config

Relates (but orthogonal) to my other thread [wishlist] git submodule update --reset-hard ATM, it possible to specify per submodule update strategy via configuration variable submodule.SUBMODULE.update where SUBMODULE is the name of the corresponding submodule. But I see no way to specify

[PATCH] rebase docs: drop stray word in merge command description

Delete a misplaced word introduced by caafecfcf1 (rebase --rebase-merges: adjust man page for octopus support, 2018-03-09). Signed-off-by: Kyle Meyer --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rebase.txt