Re: [PATCH] Add shell completion for git remote rm

On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote: > On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote: > > Duy Nguyen writes: > > > > > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote: > > >> So it sounds like either we should

[PATCH] RelNotes: fsmonitor: add a pointer to man page and the word itself

Add a pointer to git-update-index(1) and a bit more detail about fsmonitor and watchman to help people following up the new feature. --- Hi Ben and Junio, Wouldn't it be nice to tell the world a bit more about "file system monitor" we now support? I think that "git status" and "watchman" might

Re: [PATCH v3 0/2] Doc/submodules: a few updates

On Wednesday 17 January 2018 01:32 AM, Junio C Hamano wrote: > I had a few "Huh?" > moments while reading the resulting text, but nothing show-stopping. > It always happens when there are people around who are trying to be over careful :) Anyways, it's only now that I remember that I've missed

Re: [PATCH v4 6/7] trace.c: print env vars in trace_run_command()

Stefan Beller writes: > On Tue, Jan 16, 2018 at 2:13 PM, Junio C Hamano wrote: >> Nguyễn Thái Ngọc Duy writes: >> >>> +test_trace() { >>> + local expected="$1" >> >> Style: "test_trace () {" is how we start a shell function. >>

Re: [PATCH] diff.c: flush stdout before printing rename warnings

On Wed, Jan 17, 2018 at 2:06 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> The diff output is buffered in a FILE object and could still be >> partially buffered when we print these warnings (directly to fd 2). >> The output is messed up like

Re: [PATCH/RFC 0/2] Automate updating git-completion.bash a bit

On Tue, Jan 16, 2018 at 11:36 AM, Nguyễn Thái Ngọc Duy wrote: > I noticed --recurse-submodules was missing from git-grep complete > list. Then I found a couple more should be on the list as well and > many more in future may face the same faith. Perhaps this helps remedy > this

Re: [PATCH] Add shell completion for git remote rm

On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote: > Duy Nguyen writes: > > > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote: > >> So it sounds like either we should deprecate rm, or I should update the > >> patch to the suggested method

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

On 01/17, Duy Nguyen wrote: > On Wed, Jan 17, 2018 at 4:42 AM, Brandon Williams wrote: > > On 01/07, Thomas Gummerer wrote: > >> read_index_from() takes a path argument for the location of the index > >> file. For reading the shared index in split index mode however it just >

Re: [PATCH 1/2] parse-options: support --git-completion-helper

On Wed, Jan 17, 2018 at 6:46 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> This option is designed to be used by git-completion.bash. For many >> simple cases, what we do in there is usually >> >> __gitcomp "lots of completion options"

Re: [PATCH 1/2] parse-options: support --git-completion-helper

On Wed, Jan 17, 2018 at 1:25 AM, Jacob Keller wrote: > On Tue, Jan 16, 2018 at 2:36 AM, Nguyễn Thái Ngọc Duy > wrote: >> This option is designed to be used by git-completion.bash. For many >> simple cases, what we do in there is usually >> >>

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

On Wed, Jan 17, 2018 at 4:42 AM, Brandon Williams wrote: > On 01/07, Thomas Gummerer wrote: >> read_index_from() takes a path argument for the location of the index >> file. For reading the shared index in split index mode however it just >> ignores that path argument, and

Re: [PATCH 1/2] parse-options: support --git-completion-helper

Nguyễn Thái Ngọc Duy writes: > This option is designed to be used by git-completion.bash. For many > simple cases, what we do in there is usually > > __gitcomp "lots of completion options" > > which has to be manually updated when a new user-visible option is > added.

Re: [PATCH] Removed unnecessary void* from hashmap.h that caused compile warnings

"Randall S. Becker" writes: > I like it. Do you need this resubmitted? Or should I just learn for next > time? I'll queue the attached for today's iteration. Thanks, both. -- >8 -- From: "Randall S. Becker" Date: Sun, 14 Jan 2018 13:07:48 -0500

Re: [PATCH v4 6/7] trace.c: print env vars in trace_run_command()

On Tue, Jan 16, 2018 at 2:13 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> +test_trace() { >> + local expected="$1" > > Style: "test_trace () {" is how we start a shell function. > Portability: we do not use "local". > >> + shift >>

Re: [PATCH v4 6/7] trace.c: print env vars in trace_run_command()

Nguyễn Thái Ngọc Duy writes: > +test_trace() { > + local expected="$1" Style: "test_trace () {" is how we start a shell function. Portability: we do not use "local". > + shift > + GIT_TRACE=1 test-run-command "$@" run-command true 2>&1 >/dev/null | \ > +

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

On 01/07, Thomas Gummerer wrote: > read_index_from() takes a path argument for the location of the index > file. For reading the shared index in split index mode however it just > ignores that path argument, and reads it from the gitdir of the current > repository. > > This works as long as an

Re: GSoC 2018 Org applications. Deadline = January 23, 2018 at 18:00 (CET)

On Fri, Jan 5, 2018 at 2:26 AM, Matthieu Moy wrote: > Hi, > > The Google Summer of Code Organization application is open. The deadline > is rather soon (23/1). > > Like last year, I won't have much time to dedicate to it. I can try to > help, but don't expect much from me. >

Re: [PATCH v3 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

On Sun, Jan 14, 2018 at 9:37 AM, Kaartic Sivaraam wrote: > * Only mention porcelain commands in examples > > * Split a sentence for better readability > > * Add missing apostrophes > > * Clearly specify the advantages of using submodules > > * Avoid abbreviations > > *

Re: [PATCH v3 0/2] Doc/submodules: a few updates

Kaartic Sivaraam writes: > These are just a few improvements that I thought would make the > documentation > related to submodules a little better in various way such as readability, > consistency etc., These were things I noticed while reading thise >

[PATCH v3] packed_ref_cache: don't use mmap() for small files

Take a hint from commit ea68b0ce9f8 (hash-object: don't use mmap() for small files, 2010-02-21) and use read() instead of mmap() for small packed-refs files. This also fixes the problem[1] where xmmap() returns NULL for zero length[2], for which munmap() later fails. Alternatively, we could

Re: [PATCH v3 0/2] Incremental rewrite of git-submodules

Prathamesh Chavan writes: > Changes in v3: > > * For the variables: super_config_url and sub_origin_url, xstrdup() was used > while assigning "" to them, before freeing. > > * In case of the function deinit_submodule, since the orignal code doesn't die > upon failure of

Re: [PATCH 12/26] ls-refs: introduce ls-refs server command

On 01/09, Jonathan Tan wrote: > On Tue, 2 Jan 2018 16:18:14 -0800 > Brandon Williams wrote: > > > + symrefs: In addition to the object pointed by it, show the underlying > > + ref pointed by it when showing a symbolic ref. > > + peel: Show peeled tags. > > +

Re: [PATCH] diff.c: flush stdout before printing rename warnings

Nguyễn Thái Ngọc Duy writes: > The diff output is buffered in a FILE object and could still be > partially buffered when we print these warnings (directly to fd 2). > The output is messed up like this > > worktree.c | 138 +- > worktree.h

Re: [PATCH] sha1_file: remove static strbuf from sha1_file_name()

On 1/16/2018 9:01 AM, Derrick Stolee wrote: On 1/16/2018 2:18 AM, Christian Couder wrote: Using a static buffer in sha1_file_name() is error prone and the performance improvements it gives are not needed in most of the callers. So let's get rid of this static buffer and, if necessary or

Re: [PATCH] Add shell completion for git remote rm

Duy Nguyen writes: > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote: >> So it sounds like either we should deprecate rm, or I should update the >> patch to the suggested method where we just complete remotes, but not rm in >> the list of completions. > >

Re: [PATCH v5 6/7] trace.c: print env vars in trace_run_command()

On 01/15, Nguyễn Thái Ngọc Duy wrote: > Occasionally submodule code could execute new commands with GIT_DIR set > to some submodule. GIT_TRACE prints just the command line which makes it > hard to tell that it's not really executed on this repository. > > Print the env delta (compared to parent

Re: [PATCH 1/2] parse-options: support --git-completion-helper

On Tue, Jan 16, 2018 at 2:36 AM, Nguyễn Thái Ngọc Duy wrote: > This option is designed to be used by git-completion.bash. For many > simple cases, what we do in there is usually > > __gitcomp "lots of completion options" > > which has to be manually updated when a new

Re: [PATCH v5 3/7] trace.c: move strbuf_release() out of print_trace_line()

On 01/15, Nguyễn Thái Ngọc Duy wrote: > The function is about printing a trace line, not releasing the buffer it > receives too. Move strbuf_release() back outside. This makes it easier > to see how strbuf is managed. This makes the code much more readable. -- Brandon Williams

Re: Git uses wrong subkey for signing commits with GPG key

Todd Zullinger writes: > Glad it helped. The git-tag documentation points to > git-config and the user.signingKey variable in the > CONFIGURATION section. The git-config documentation for > that variable currently says: > ... > so you may specify a key using any method that

Re: [ANNOUNCE] Git v2.16.0-rc2 - breakages in t1308 and 1404

Tanay Abhra writes: > I was the original author of the test, I am sorry about the typo. > ... > 'configset_get_value' will be changed to 'configset_get_value_multi' > since the test expects a list of values instead of a single value. Thanks for a quick reaction!!

Re: [PATCH] sha1_file: remove static strbuf from sha1_file_name()

On Tue, Jan 16, 2018 at 08:18:14AM +0100, Christian Couder wrote: > Using a static buffer in sha1_file_name() is error prone > and the performance improvements it gives are not needed > in most of the callers. > > So let's get rid of this static buffer and, if necessary > or helpful, let's use

Re: [PATCH] describe: use strbuf_add_unique_abbrev() for adding short hashes

> Patch generated by Coccinelle (and contrib/coccinelle/strbuf.cocci). Interesting. The static analysis build job on Travis CI runs 'make coccicheck', so it should have caught this. However, I've looked at more build job results than I could count while working on some Travis CI related patches

Did you get my last email

Hello there, I sent you an email a few days with a proposal that I think you will be interested in because it is of mutual benefit. Did you receive the email? I am not if you got it because I did not receive a reply from you and my mailbox has been acting up lately. Could you please reply me

Re: [PATCH] sha1_file: remove static strbuf from sha1_file_name()

On 1/16/2018 2:18 AM, Christian Couder wrote: Using a static buffer in sha1_file_name() is error prone and the performance improvements it gives are not needed in most of the callers. So let's get rid of this static buffer and, if necessary or helpful, let's use one in the caller. First: this

Re: [PATCH] describe: use strbuf_add_unique_abbrev() for adding short hashes

On 1/15/2018 12:10 PM, René Scharfe wrote: Call strbuf_add_unique_abbrev() to add an abbreviated hash to a strbuf instead of taking a detour through find_unique_abbrev() and its static buffer. This is shorter and a bit more efficient. Patch generated by Coccinelle (and

Re: [BUG] git remote prune removes local tags, depending on fetch config

On Jan 15 2018, Michael Giuffrida wrote: > It doesn't seem like a useful feature -- you wouldn't expect `git > fetch --prune` to remove your local branches that you were developing > on, right? Don't mix local and remote refs. There is a reason why remote tracking

Re: [BUG] git remote prune removes local tags, depending on fetch config

On Tue, Jan 16 2018, Michael Giuffrida jotted: > Just to confirm, you're talking about the behavior of removing *all* > tags that aren't found on the remote? (Not just tags that used to be > on some remote, but have since been removed from that remote.) So, > with your proposed workflow, you

[PATCH/RFC 0/2] Automate updating git-completion.bash a bit

I noticed --recurse-submodules was missing from git-grep complete list. Then I found a couple more should be on the list as well and many more in future may face the same faith. Perhaps this helps remedy this situation? This lets us extract certain information from git commands and feed it

[PATCH 2/2] git-completion: use --git-completion-helper

The builtin command is updated to hide some options. The new options that are complete-able are: --after-context= --all-match --before-context= --color --context --exclude-standard --recurse-submodules --textconv --max-depth and --threads are already completable, but now it will complete with

[PATCH 1/2] parse-options: support --git-completion-helper

This option is designed to be used by git-completion.bash. For many simple cases, what we do in there is usually __gitcomp "lots of completion options" which has to be manually updated when a new user-visible option is added. With support from parse-options, we can write __gitcomp

Re: [PATCH] Add shell completion for git remote rm

On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote: > So it sounds like either we should deprecate rm, or I should update the patch > to the suggested method where we just complete remotes, but not rm in the > list of completions. I vote for deprecation. I could send a patch to

Re: [PATCH v2 02/18] cat-file: reuse struct ref_format

2018-01-16 0:37 GMT+03:00 Jeff King : > On Wed, Jan 10, 2018 at 09:36:41AM +, Olga Telezhnaya wrote: > >> Start using ref_format struct instead of simple char*. >> Need that for further reusing of formatting logic from ref-filter. > > OK, this makes sense (though again, at some

[PATCH] diff.c: flush stdout before printing rename warnings

The diff output is buffered in a FILE object and could still be partially buffered when we print these warnings (directly to fd 2). The output is messed up like this worktree.c | 138 +- worktree.hwarning: inexact rename detection was skipped due to