Re: [PATCH v2 7/7] Makefile: add a knob to enable the use of Asciidoctor

On Mon, Jan 23, 2017 at 03:57:13AM +0100, Øyvind A. Holm wrote: > On 2017-01-22 02:41:56, brian m. carlson wrote: > > While Git has traditionally built its documentation using AsciiDoc, some > > people wish to use Asciidoctor for speed or other reasons. Add a > > Makefile knob, USE_ASCIIDOCTOR,

Re: [PATCH v2 7/7] Makefile: add a knob to enable the use of Asciidoctor

On 2017-01-22 02:41:56, brian m. carlson wrote: > While Git has traditionally built its documentation using AsciiDoc, some > people wish to use Asciidoctor for speed or other reasons. Add a > Makefile knob, USE_ASCIIDOCTOR, that sets various options in order to > produce acceptable output. For

Re: [PATCH] blame: add option to print tips (--tips)

Edmundo Carmona Antoranz writes: > I wrote this for human consumption, actually. I see. > Maybe I overestimated the > need for this feature (I definitely find it handy, but it might be just me). That is too early to tell. At this point we only know there are me who

Re: [RFC PATCH] Option to allow cherry-pick to skip empty commits

Giuseppe Bilotta writes: > This allows cherry-picking a set of commits, some of which may be > redundant, without stopping to ask for the user intervention. > > Signed-off-by: Giuseppe Bilotta > --- > Documentation/git-cherry-pick.txt |

[PATCH 4/4] git-prompt.sh: add tests for submodule indicator

--- t/t9903-bash-prompt.sh | 43 +++ 1 file changed, 43 insertions(+) diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh index 97c9b32..4dce366 100755 --- a/t/t9903-bash-prompt.sh +++ b/t/t9903-bash-prompt.sh @@ -37,6 +37,11 @@

Re: [PATCH] blame: add option to print tips (--tips)

On Sun, Jan 22, 2017 at 4:58 PM, Junio C Hamano wrote: > > What is the target audience? If you are trying to write a script > that reads output by "git blame", you are strongly discouraged > unless you are reading from "git blame --porcelain" which is more > compact and has

Re: Does it make sense to show tips on blame?

On Sun, Jan 22, 2017 at 4:25 PM, Junio C Hamano wrote: > Edmundo Carmona Antoranz writes: > > What does the word "tip" mean in this context? The word is often > used to mean the commits directly pointed at by branches (i.e. the > tip of history), but I do

[PATCH 2/7] completion: add subcommand completion for rerere

From: Cornelius Weig Managing recorded resolutions requires command-line usage of git-rerere. Added subcommand completion for rerere and path completion for its subcommand forget. --- contrib/completion/git-completion.bash | 11 +++ 1 file changed, 11

[PATCH 0/7] completion bash: add more options and commands

From: Cornelius Weig The cli interface for git has the greatest versatility of all git tools. Its productivity depends on how easy it is to type commands and to remember options. The command line completion helps two-fold by easing input and displaying possible

[PATCH 3/7] completion: improve bash completion for git-add

From: Cornelius Weig Add some long-options for git-add and improve path completion when the --update flag is given. --- contrib/completion/git-completion.bash | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git

[PATCH 4/7] completion: teach ls-remote to complete options

From: Cornelius Weig ls-remote needs to complete remote names and its own options. In addition to the existing remote name completions, do also complete the options --heads, --tags, --refs, and --get-url. --- contrib/completion/git-completion.bash | 6 ++ 1 file

Re: [PATCH] blame: add option to print tips (--tips)

Edmundo Carmona Antoranz writes: > So, this is a draft of what I mean by "adding tips to blame". > > Example output (sample from builtin/blame.c): > ... > 15:32 $ ./git blame --tips -L 1934,1960 builtin/blame.c >cee7f245dc: git-pickaxe: blame rewritten. > cee7f245dc

[PATCH 6/7] completion: teach remote subcommands option completion

From: Cornelius Weig Git-remote needs to complete remote names, its subcommands, and options thereof. In addition to the existing subcommand and remote name completion, do also complete the options - add: --track --master --fetch --tags --no-tags --mirror= -

[PATCH 5/7] completion: teach replace to complete options

From: Cornelius Weig Git-replace needs to complete references and its own options. In addition to the existing references completions, do also complete the options --edit --graft --format= --list --delete. --- contrib/completion/git-completion.bash | 6 ++ 1 file

[PATCH 7/7] completion: recognize more long-options

From: Cornelius Weig Recognize several new long-options for bash completion in the following commands: - apply: --recount --directory= --unsafe-paths - archive: --prefix= --remote= --exec= --output - branch: --column --no-column --sort= --points-at - clone:

[PATCH 1/7] completion: teach options to submodule subcommands

From: Cornelius Weig The subcommands of submodule have different long-options which command line users need to type in. Therefore, teach bash completion to support most subcommand options for submodule. --- contrib/completion/git-completion.bash | 32

[PATCH v2] travis-ci: fix Perforce install on macOS

The `perforce` and `perforce-server` package were moved from brew [1][2] to cask [3]. Teach TravisCI the new location. Perforce updates their binaries without version bumps. That made the brew install (legitimately!) fail due to checksum mismatches. The workaround is not necessary anymore as Cask

Re: [PATCH v2 3/4] show-ref: Optimize show_ref a bit

Junio C Hamano writes: > Having to do this change probably is an indication that the division > of labour between show_ref() and show_one() up to this step needs to > be rethought. > > Conceptually, "git show-ref" works in two ways: > > * When in --verify mode, the end user

Re: [PATCH v2 3/4] show-ref: Optimize show_ref a bit

Vladimir Panteleev writes: > The inner `if (verify)' check was not being used before the preceding > commit, as show_ref was never being called from a code path where > verify was non-zero. > > Adding a `!verify' check to the outer if skips an unnecessary string >

Re: Does it make sense to show tips on blame?

Edmundo Carmona Antoranz writes: > Output is like this (from README.txt, taken from difflame on git > itself, sorry if it's too wide): It is not just too wide but it is line-wrapped and cannot see what you wanted to say out of it. What does the word "tip" mean in this

Re: interaction between git-diff-index and git-apply

Ariel Davis writes: > I have noticed an interesting interaction between git-diff-index and > git-apply. > Essentially, it seems that if we start with a clean working tree, then > git-apply a patch, then git-apply the reverse of that patch, git-diff-index > still thinks

Re: [PATCH] blame: add option to print tips (--tips)

Hello, everybody! So, this is a draft of what I mean by "adding tips to blame". Example output (sample from builtin/blame.c): 15:32 $ ./git blame --tips -L 1934,1960 builtin/blame.c cee7f245dc: git-pickaxe: blame rewritten. cee7f245dc builtin-pickaxe.c (Junio C Hamano

[PATCH] blame: add option to print tips (--tips)

--- builtin/blame.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/builtin/blame.c b/builtin/blame.c index 126b8c9e5..4bc449f40 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -1884,6 +1884,7 @@ static const char *format_time(unsigned long time, const char

interaction between git-diff-index and git-apply

Hello, I have noticed an interesting interaction between git-diff-index and git-apply. Essentially, it seems that if we start with a clean working tree, then git-apply a patch, then git-apply the reverse of that patch, git-diff-index still thinks files are modified. But then, if we git-status,

[PATCH v3 0/4] git gui: allow for a long recentrepo list

Way back in December 2015 I made a couple of attempts to patch up the git-gui's recentrepo list in the face of duplicate entries in the .gitconfig The series end at http://public-inbox.org/git/9731888BD4C348F5BFC82FA96D978034@PhilipOakley/ A similar problem was reported recently on the Git for

[PATCH v3 1/4] git-gui: remove duplicate entries from .gitconfig's gui.recentrepo

The git gui's recent repo list may become contaminated with duplicate entries. The git gui would barf when attempting to remove one entry. Remove them all - there is no option within 'git config' to selectively remove one of the entries. This issue was reported on the 'Git User' list

[PATCH v3 4/4] git gui: allow for a long recentrepo list

The gui.recentrepo list may be longer than the maxrecent setting. Allow extra space to show any extra entries. In an ideal world, the git gui would limit the number of entries to the maxrecent setting, however the recentrepo config list may have been extended outwith the gui, or the maxrecent

[PATCH v3 2/4] git gui: cope with duplicates in _get_recentrepo

_get_recentrepo will fail if duplicate invalid entries are present in the recentrepo config list. The previous commit fixed the 'git config' limitations in _unset_recentrepo by unsetting all config entries, however this code would fail on the second attempt to unset it. Refactor the code to

[PATCH v3 3/4] git gui: de-dup selected repo from recentrepo history

When the gui/user selects a repo for display, that repo is brought to the end of the recentrepo config list. The logic can fail if there are duplicate old entries for the repo (you cannot unset a single config entry when duplicates are present). Similarly, the maxrecentrepo logic could fail if

[PATCH 3/3] git-prompt.sh: fix for submodule 'dirty' indicator

Fixing wrong git diff line. --- contrib/completion/git-prompt.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh index c44b9a2..43b28e9 100644 --- a/contrib/completion/git-prompt.sh +++

Re: [RFC] Case insensitive Git attributes

Apologies for the delayed bump. I think because we're talking about affecting the behavior of .gitattributes that it would be better to have a distinct .gitattributes option, whether or not you also have a similar config option. Since .gitattributes is versioned and config options are not, I

Re: [RFC] what content should go in https://git-scm.com/doc/ext

On Sat, Jan 21, 2017 at 2:55 PM, Jeff King wrote: > I'm wondering if anybody has opinions on: > > https://github.com/git/git-scm.com/pull/924 > > (and I suspect most people in this community do not read pull requests > there, hence this post). Yeah, thanks for posting it here.

[DEMO][PATCH v2 6/5] compat: add a qsort_s() implementation based on GNU's qsort_r(1)

Implement qsort_s() as a wrapper to the GNU version of qsort_r(1) and use it on Linux. Performance increases slightly: Test HEAD^ HEAD 0071.2: sort(1) 0.10(0.20+0.02)

[PATCH v2 2/5] add QSORT_S

Add the macro QSORT_S, a convenient wrapper for qsort_s() that infers the size of the array elements and dies on error. Basically all possible errors are programming mistakes (passing NULL as base of a non-empty array, passing NULL as comparison function, out-of-bounds accesses), so terminating

[PATCH v2 5/5] ref-filter: use QSORT_S in ref_array_sort()

Pass the array of sort keys to compare_refs() via the context parameter of qsort_s() instead of using a global variable; that's cleaner and simpler. If ref_array_sort() is to be called from multiple parallel threads then care still needs to be taken that the global variable used_atom is not

[PATCH v2 4/5] string-list: use QSORT_S in string_list_sort()

Pass the comparison function to cmp_items() via the context parameter of qsort_s() instead of using a global variable. That allows calling string_list_sort() from multiple parallel threads. Our qsort_s() in compat/ is slightly slower than qsort(1) from glibc 2.24 for sorting lots of lines: Test

[PATCH v2 3/5] perf: add basic sort performance test

Add a sort command to test-string-list that reads lines from stdin, stores them in a string_list and then sorts it. Use it in a simple perf test script to measure the performance of string_list_sort(). Signed-off-by: Rene Scharfe --- t/helper/test-string-list.c | 25

[PATCH v2 1/5] compat: add qsort_s()

The function qsort_s() was introduced with C11 Annex K; it provides the ability to pass a context pointer to the comparison function, supports the convention of using a NULL pointer for an empty array and performs a few safety checks. Add an implementation based on compat/qsort.c for platforms

[PATCH v2 0/5] string-list: make string_list_sort() reentrant

Use qsort_s() from C11 Annex K to make string_list_sort() safer, in particular when called from parallel threads. Changes from v1: * Renamed HAVE_QSORT_S to HAVE_ISO_QSORT_S in Makefile to disambiguate. * Added basic perf test (patch 3). * Converted a second caller to QSORT_S, in ref-filter.c

RE: [PATCH] git-p4: Fix git-p4.mapUser on Windows

> On 22 Jan 2017, at 13:05, Luke Diamand > > I'm confusedsee below. That now makes two of us! I think I've figured out where I messed up, see below. > > On 21 January 2017 at 15:21, George Vanburgh > wrote: > >> On 21 Jan 2017, at 13:33, Lars

Re: [PATCH] git-p4: Fix git-p4.mapUser on Windows

I'm confusedsee below. On 21 January 2017 at 15:21, George Vanburgh wrote: >> On 21 Jan 2017, at 13:33, Lars Schneider >> > On 21 Jan 2017, at 13:02, George Vanburgh >> wrote: >> > >> > From: George Vanburgh

Urgent Information - 4.2-1

Hello, Good morning and good day. I work with an investment company that is funding projects as debt finance at 3% interest rate annually with an option of 1 to 25 years repayment plan. If you have any viable project that needs funding, contact us with your business plan/executive summary for

[PATCH 2/2] git-prompt.sh: rework of submodule indicator

Rework of the first patch. The prompt now will look like this: (+name:master). I tried to considere all suggestions. Tests still missing. --- contrib/completion/git-prompt.sh | 49 1 file changed, 24 insertions(+), 25 deletions(-) diff --git