Re: [PATCH/RFC] completion: complete all possible -no-

On Tue, Apr 17, 2018 at 2:13 PM, Nguyễn Thái Ngọc Duy wrote: > The problem with completing --no- form is that the number of > completable options now usually doubles, taking precious screen space > and also making it hard to find the option you want. > > So the other half of

Re: [PATCH v7 0/4] worktree: teach "add" to check out existing branches

On Sun, Apr 15, 2018 at 4:29 PM, Thomas Gummerer wrote: > The main change once again in this series is the user interface. It > feels like we went in a complete circle here now, as this iteration is > bringing the "Preparing ..." line back (although in a slightly >

Re: [PATCH v7 2/4] worktree: improve message when creating a new worktree

On Sun, Apr 15, 2018 at 4:29 PM, Thomas Gummerer wrote: > Currently 'git worktree add' produces output like the following: > > Preparing ../foo (identifier foo) > HEAD is now at 26da330922 > [...] > Instead of this message, print a message that gives the user a bit

Re: Git enhancement request - checkout (clone) set modified dates to commit date

On Sun, Apr 22, 2018 at 5:23 PM, Andrew Wolfe wrote: > Kevin, thanks for your feedback. > > You have a reasonable point, because usually you don't put the outputs of a > build into version control, but the build script checks them for being > current. > > On the other

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

On Sun, Apr 22, 2018 at 9:17 PM, Taylor Blau wrote: > On Sun, Apr 22, 2018 at 08:16:12PM -0400, Eric Sunshine wrote: >> One way to achieve a more coherent patch series would be to build the >> machinery first and then expose it to the user in various ways. Also, >> each patch

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

On Sun, Apr 22, 2018 at 08:16:12PM -0400, Eric Sunshine wrote: > On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > > show_line() currently receives the line number within the > > 'grep_opt->buf' in order to determine which line number to display. In > > order to display

Re: [PATCH v2 5/6] builtin/grep.c: show column numbers via --column-number

On Sun, Apr 22, 2018 at 08:32:28PM -0400, Eric Sunshine wrote: > On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > > This commit teaches 'git-grep(1)' a new option, '--column-number'. This > > option builds upon previous commits to show the column number of the > > first

Re: [PATCH v2 4/6] grep.c: display column number of first match

On Sun, Apr 22, 2018 at 08:24:55PM -0400, Eric Sunshine wrote: > On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > > Building upon our work in the previous commit to add members 'columnnum' > > and 'color_columno' to 'grep_opt', we teach show_line() how to respect > > those

Re: [PATCH v2 3/6] grep.[ch]: teach columnnum, color_columnno to grep_opt

On Sun, Apr 22, 2018 at 08:21:33PM -0400, Eric Sunshine wrote: > On Sun, Apr 22, 2018 at 7:24 PM, Taylor Blau wrote: > > On Sun, Apr 22, 2018 at 11:42:48PM +0200, Ęvar Arnfjörš Bjarmason wrote: > >> On Sun, Apr 22 2018, Taylor Blau wrote: > >> > In preparation of adding

Re: Git enhancement request - checkout (clone) set modified dates to commit date

Kevin, thanks for your feedback. You have a reasonable point, because usually you don't put the outputs of a build into version control, but the build script checks them for being current. On the other hand, when you change branches, your existing output directories are worthless problems

Re: [PATCH v2 5/6] builtin/grep.c: show column numbers via --column-number

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > This commit teaches 'git-grep(1)' a new option, '--column-number'. This > option builds upon previous commits to show the column number of the > first match on a non-context line. Imperative mood (and dropping unnecessary

Re: [PATCH v2 4/6] grep.c: display column number of first match

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > Building upon our work in the previous commit to add members 'columnnum' > and 'color_columno' to 'grep_opt', we teach show_line() how to respect > those options. > > When requested, show_line() will display the column

Re: [PATCH v2 3/6] grep.[ch]: teach columnnum, color_columnno to grep_opt

On Sun, Apr 22, 2018 at 7:24 PM, Taylor Blau wrote: > On Sun, Apr 22, 2018 at 11:42:48PM +0200, Ęvar Arnfjörš Bjarmason wrote: >> On Sun, Apr 22 2018, Taylor Blau wrote: >> > In preparation of adding --column-number to 'git-grep(1)', we extend >> > grep_opt to take in the

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > show_line() currently receives the line number within the > 'grep_opt->buf' in order to determine which line number to display. In > order to display information about the matching column number--if > requested--we must

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

On Mon, Apr 23, 2018 at 08:33:11AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > I noticed that tb/config-default, however, only landed two commits: > > > > - builtin/config: introduce `color` type specifier > > - config.c: introduce 'git_config_color' to parse

Re: [PATCH v2 0/6] Teach '--column-number' to 'git-grep(1)'

On Mon, Apr 23, 2018 at 08:28:14AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh > > index 0cf654824d..7349c7fadc 100755 > > --- a/t/t7810-grep.sh > > +++ b/t/t7810-grep.sh > > @@ -106,7 +106,7 @@ do > >

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

Taylor Blau writes: > I noticed that tb/config-default, however, only landed two commits: > > - builtin/config: introduce `color` type specifier > - config.c: introduce 'git_config_color' to parse ANSI colors > > but not: > > - builtin/config: introduce `--default`

Re: [PATCH v2 1/6] grep.c: take regmatch_t as argument in match_line()

On Sun, Apr 22, 2018 at 07:14:58PM -0400, Eric Sunshine wrote: > On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > > In a subsequent patch, we teach show_line() to optionally include the > > column number of the first match on each matched line. > > > > The regmatch_t

Re: [PATCH v2 0/6] Teach '--column-number' to 'git-grep(1)'

Taylor Blau writes: > * Removed '-m' as an alias for '--column-number', per René's > suggestion [1]. > > * Fix some incorrect spelling of 'columnnumber'. > > * Change casing of 'color.grep.linenumber' to 'color.grep.lineNumber' > to be consistent with

Re: [PATCH v2 6/6] contrib/git-jump/git-jump: use column number when grep-ing

On Sun, Apr 22, 2018 at 11:49:39PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Sun, Apr 22 2018, Taylor Blau wrote: > > > This patch adds the '--column-number' synonym '-m' to the default > > grep command so that callers are brought to the correct line _and_ > > column of each matched location. >

Re: [PATCH v2 5/6] builtin/grep.c: show column numbers via --column-number

On Sun, Apr 22, 2018 at 11:48:53PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Sun, Apr 22 2018, Taylor Blau wrote: > > I think this part though... > > > While we're at it, change color.grep.linenumber to color.grep.lineNumber > > to match the casing of nearby variables. > > [...] > >

Re: [PATCH v2 3/6] grep.[ch]: teach columnnum, color_columnno to grep_opt

On Sun, Apr 22, 2018 at 11:42:48PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Sun, Apr 22 2018, Taylor Blau wrote: > > > In preparation of adding --column-number to 'git-grep(1)', we extend > > grep_opt to take in the requisite new members. > > Just a nit: Makes sense to refer to these camel-cased

Re: [PATCH v2 1/6] grep.c: take regmatch_t as argument in match_line()

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > In a subsequent patch, we teach show_line() to optionally include the > column number of the first match on each matched line. > > The regmatch_t involved in match_line() and match_one_pattern() both > contain this

Re: [PATCH v2 6/6] contrib/git-jump/git-jump: use column number when grep-ing

On Sun, Apr 22 2018, Taylor Blau wrote: > This patch adds the '--column-number' synonym '-m' to the default > grep command so that callers are brought to the correct line _and_ > column of each matched location. > [...] > diff --git a/contrib/git-jump/git-jump b/contrib/git-jump/git-jump > index

Re: [PATCH v2 5/6] builtin/grep.c: show column numbers via --column-number

On Sun, Apr 22 2018, Taylor Blau wrote: I think this part though... > While we're at it, change color.grep.linenumber to color.grep.lineNumber > to match the casing of nearby variables. > [...] > -`linenumber`;; > +`lineNumber`;; Makes sense as its own patch at the beginning of the series,

Re: [PATCH v2 3/6] grep.[ch]: teach columnnum, color_columnno to grep_opt

On Sun, Apr 22 2018, Taylor Blau wrote: I think [345]/6 would make much more sense as just one patch. Comments on them to follow... > In preparation of adding --column-number to 'git-grep(1)', we extend > grep_opt to take in the requisite new members. Just a nit: Makes sense to refer to these

Some mutt(1) patches and scripts

Hi, I have spent more time contributing to the Git list lately, and as such have grown a number of patches and scripts that have been useful for my workflow. I am interested in sharing them here in the hopes that they will be useful for others as well :-). My workflow is as follows: 1. Write

[PATCH v2 3/6] grep.[ch]: teach columnnum, color_columnno to grep_opt

In preparation of adding --column-number to 'git-grep(1)', we extend grep_opt to take in the requisite new members. We additionally teach the 'grep.columnnumber' and 'color.grep.columnnumber' configuration variables to configure showing and coloring the column number, respectively. (These options

[PATCH v2 2/6] grep.c: take column number as argument to show_line()

show_line() currently receives the line number within the 'grep_opt->buf' in order to determine which line number to display. In order to display information about the matching column number--if requested--we must additionally take in that information. To do so, we extend the signature of

[PATCH v2 1/6] grep.c: take regmatch_t as argument in match_line()

In a subsequent patch, we teach show_line() to optionally include the column number of the first match on each matched line. The regmatch_t involved in match_line() and match_one_pattern() both contain this information (via regmatch_t->rm_so), but their current implementation throws this stack

[PATCH v2 5/6] builtin/grep.c: show column numbers via --column-number

This commit teaches 'git-grep(1)' a new option, '--column-number'. This option builds upon previous commits to show the column number of the first match on a non-context line. For example: $ ./git-grep -n --column-number foo | head -n3 .clang-format:51:14:# myFunction(foo, bar, baz);

[PATCH v2 4/6] grep.c: display column number of first match

Building upon our work in the previous commit to add members 'columnnum' and 'color_columno' to 'grep_opt', we teach show_line() how to respect those options. When requested, show_line() will display the column number of the first match on a non-context line. show_line() differentiates between

[PATCH v2 6/6] contrib/git-jump/git-jump: use column number when grep-ing

This patch adds the '--column-number' synonym '-m' to the default grep command so that callers are brought to the correct line _and_ column of each matched location. Signed-off-by: Taylor Blau --- contrib/git-jump/git-jump | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v2 0/6] Teach '--column-number' to 'git-grep(1)'

Hi, Attached is a re-roll of the series to add --column-number to 'git-grep(1)'. Since last time, I have changed the following (an inter-diff is available below for easier consumption): * Removed '-m' as an alias for '--column-number', per René's suggestion [1]. * Fix some incorrect

Re: [PATCH v2 1/2] completion: stop showing 'save' for stash by default

On 04/20, Duy Nguyen wrote: > On Fri, Apr 20, 2018 at 1:25 AM, Thomas Gummerer wrote: > > The 'save' subcommand in git stash has been deprecated in > > fd2ebf14db ("stash: mark "git stash save" deprecated in the man page", > > 2017-10-22). > > > > Stop showing it when the

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

On Tue, Apr 17, 2018 at 03:07:46PM +0900, Junio C Hamano wrote: > * tb/config-type (2018-04-10) 2 commits > - builtin/config.c: support `--type=` as preferred alias for `--` > - builtin/config.c: treat type specifiers singularly > (this branch is used by tb/config-default.) > > The "git

Re: Git enhancement request - checkout (clone) set modified dates to commit date

On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote: > Hi Brian, > > Not completely sure what you're saying. If the files on master are > not changed, the changed files' commit timestamps will be older than > the branch commit timestamps. > > However, if I check out master after

Re: Git enhancement request - checkout (clone) set modified dates to commit date

Hi Brian, Not completely sure what you're saying. If the files on master are not changed, the changed files' commit timestamps will be older than the branch commit timestamps. However, if I check out master after committing to a branch, the modifications will necessarily disappear because

Re: RFC: How should we handle un-deleted remote branches?

On Sun, Apr 22 2018, Andreas Heiduk wrote: > Am 22.04.2018 um 13:17 schrieb Ævar Arnfjörð Bjarmason: >> >> On Sun, Apr 22 2018, Andreas Heiduk wrote: >> >>> Am 20.04.2018 um 14:14 schrieb Ævar Arnfjörð Bjarmason: But this is a possible work-around: git init /tmp/empty.git

[PATCH 2/2] walker: drop fields of `struct walker` which are always 1

After the previous commit, both users of `struct walker` set `get_tree`, `get_history` and `get_all` to 1. Drop those fields and simplify the walker implementation accordingly. Let's hope that any out-of-tree users will not mind this change. They should notice that the compilation fails as they

[PATCH 1/2] http-fetch: make `-a` standard behaviour

This is a follow-up to a6c786fce8 (Mark http-fetch without -a as deprecated, 2011-08-23). For more than six years, we have been warning when `-a` is not provided, and the documentation has been saying that `-a` will become the default. It is a bit unclear what "default" means here. There is no

Re: Git enhancement request - checkout (clone) set modified dates to commit date

On Sun, Apr 22, 2018 at 01:18:10PM -0400, Andrew Wolfe wrote: > I would like to propose that the checkout process set the create and > modification times of a file to the timestamp at which a file was committed. The reason Git doesn't do this is pretty simple: make and various other tools do

Re: Is support for 10.8 dropped?

On Sun, Apr 22, 2018 at 12:10:20AM -0700, Perry Hutchison wrote: > Eric Sunshine wrote: > > On Sun, Apr 22, 2018 at 1:15 AM, Igor Korot wrote: > > > MyMac:git-2.17.0 igorkorot$ cat config.mak > > > NO_GETTEXT=Yes > > > NO_OPENSSL=Yes > > > > > >

Git enhancement request - checkout (clone) set modified dates to commit date

Hello, there are several timestamps in the lifecycle of a modification to a file in Git: • file write timestamp • git add timestamp • git commit timestamp • git push timestamp • git merge timestamp • git checkout timestamp Right now when I check

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

On 21/04/18 16:56, Phillip Wood wrote: > On 21/04/18 11:33, Johannes Schindelin wrote: >> This patch is part of the effort to reimplement `--preserve-merges` with >> a substantially improved design, a design that has been developed in the >> Git for Windows project to maintain the dozens of

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On 22/04/18 17:12, Duy Nguyen wrote: > On Sun, Apr 22, 2018 at 5:58 PM, Ramsay Jones > wrote: I think you need to try a little harder than this! ;-) >>> >>> Yeah. I did think about grepping the output but decided not to because >>> of gettext poison stuff and

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sun, Apr 22, 2018 at 5:58 PM, Ramsay Jones wrote: >>> I think you need to try a little harder than this! ;-) >> >> Yeah. I did think about grepping the output but decided not to because >> of gettext poison stuff and column output in "git help". If we do want >> to

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

From: "Johannes Schindelin" This patch is part of the effort to reimplement `--preserve-merges` with a substantially improved design, a design that has been developed in the Git for Windows project to maintain the dozens of Windows-specific patch series on top of

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On 22/04/18 16:22, Duy Nguyen wrote: > On Sun, Apr 22, 2018 at 4:45 PM, Ramsay Jones > wrote: >> >> >> On 21/04/18 17:56, Duy Nguyen wrote: >>> On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: Changes: - remove the deprecated

Re: [PATCH 3/3] Avoid multiple PREFIX definitions

From: "Johannes Schindelin" From: Philip Oakley The short and sweet PREFIX can be confused when used in many places. Rename both usages to better describe their purpose. EXEC_CMD_PREFIX is used in full to disambiguate it from the nearby

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sun, Apr 22, 2018 at 4:45 PM, Ramsay Jones wrote: > > > On 21/04/18 17:56, Duy Nguyen wrote: >> On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: >>> Changes: >>> >>> - remove the deprecated column in command-list.txt. My change break it >>>

Re: [PATCH v3 09/11] technical/shallow: describe the relationship with replace refs

From: "Johannes Schindelin" Now that grafts are deprecated, we should start to assume that readers have no idea what grafts are. So it makes more sense to describe the "shallow" feature in terms of replace refs. Suggested-by: Eric Sunshine

Re: [PATCH v8 09/16] rebase: introduce the --rebase-merges option

From: "Johannes Schindelin" Once upon a time, this here developer thought: wouldn't it be nice if, say, Git for Windows' patches on top of core Git could be represented as a thicket of branches, and be rebased on top of core Git in order to maintain a

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On 21/04/18 17:56, Duy Nguyen wrote: > On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: >> Changes: >> >> - remove the deprecated column in command-list.txt. My change break it >> anyway if anyone uses it. >> - fix up failed tests that I marked in the RFC and kinda forgot

Re: [PATCH v8 09/16] rebase: introduce the --rebase-merges option

From: "Johannes Schindelin" Once upon a time, this here developer thought: wouldn't it be nice if, say, Git for Windows' patches on top of core Git could be represented as a thicket of branches, and be rebased on top of core Git in order to maintain a

Re: RFC: How should we handle un-deleted remote branches?

Am 22.04.2018 um 13:17 schrieb Ævar Arnfjörð Bjarmason: > > On Sun, Apr 22 2018, Andreas Heiduk wrote: > >> Am 20.04.2018 um 14:14 schrieb Ævar Arnfjörð Bjarmason: >>> But this is a possible work-around: >>> >>> git init /tmp/empty.git >>> git remote add avar file:///tmp/empty.git >>>

Re: [PATCH v8 08/16] rebase-helper --make-script: introduce a flag to rebase merges

From: "Johannes Schindelin" Sorry for the very late in the series comments.. The sequencer just learned new commands intended to recreate branch structure (similar in spirit to --preserve-merges, but with a substantially less-broken design). Let's allow the

Re: [RFC PATCH v10 32.5/36] unpack_trees: fix memory corruption with split_index when src != dst

On Sat, Apr 21, 2018 at 9:37 PM, Elijah Newren wrote: > Currently, all callers of unpack_trees() set o->src_index == o->dst_index. > Since we create a temporary index in o->result, then discard o->dst_index > and overwrite it with o->result, when o->src_index == o->dst_index it

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

On Fri, Apr 20, 2018 at 11:34:25AM -0700, Elijah Newren wrote: > Sorry, I think I wasn't being clear. The documentation for the config > options for e.g. diff.renameLimit, fetch.prune, log.abbrevCommit, and > merge.ff all mention the equivalent command line parameters. Your > patch doesn't do

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

From: "Johannes Schindelin" This patch is part of the effort to reimplement `--preserve-merges` with a substantially improved design, a design that has been developed in the Git for Windows project to maintain the dozens of Windows-specific patch series on top of

Re: RFC: How should we handle un-deleted remote branches?

On Sun, Apr 22 2018, Andreas Heiduk wrote: > Am 20.04.2018 um 14:14 schrieb Ævar Arnfjörð Bjarmason: >> But this is a possible work-around: >> >> git init /tmp/empty.git >> git remote add avar file:///tmp/empty.git >> git remote prune avar >> git remote remove avar > > This won't

Re: RFC: How should we handle un-deleted remote branches?

Am 20.04.2018 um 14:14 schrieb Ævar Arnfjörð Bjarmason: > But this is a possible work-around: > > git init /tmp/empty.git > git remote add avar file:///tmp/empty.git > git remote prune avar > git remote remove avar This won't do it also? git remote prune origin > I

Re: Is support for 10.8 dropped?

Eric Sunshine wrote: > On Sun, Apr 22, 2018 at 1:15 AM, Igor Korot wrote: > > MyMac:git-2.17.0 igorkorot$ cat config.mak > > NO_GETTEXT=Yes > > NO_OPENSSL=Yes > > > > MyMac:dbhandler igorkorot$ /Users/igorkorot/git-2.17.0/git pull > > fatal: unable to