On Sat, Apr 21, 2018 at 12:54 PM, Nguyễn Thái Ngọc Duy
wrote:
> The help command currently hard codes the list of guides and their
> summary in C. Let's move this list to command-list.txt. This lets us
> extract summary lines from Documentation/git*.txt. This also
> potentially lets us lists guide
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 this patch, the part i
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
> different form than the origina
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 more
> detail of what e
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 hand, when you change branc
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 which implements some
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 information about the m
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 match on a non-context
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 options.
> >
> > Wh
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 --column-number to 'git-gre
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 anywa
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 "builds upon previous
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 number of the first
> mat
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 requisite new members.
>>
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 additionally take in tha
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 ANSI colors
> >
> > b
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
> > echo ${HC}file:5
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`
Whenever something like
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 involved in match_line()
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 'color.grep.columnNumber'. This
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.
>
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.
> > [...]
> > -`linenumber
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
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 information (via regmatch_t->
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
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, sinc
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 c
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 s
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
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 show_lin
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 var
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);
.clang
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 con
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(-)
diff --git a/contr
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 spe
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 users enters 'git stash '
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 config"
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 committ
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 the
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
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 tr
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 suc
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 rebu
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
> > >
> > > MyMac:dbhandler igorkorot$ /Users/igorkorot/git-2.1
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 o
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 Windows
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 column output in "git help". If
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 test this, how about I extend
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 upstream Git.
The previous patc
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 column in command-list.txt. My cha
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 GIT_EXEC_PATH.
@dcsho; Thanks for keeping up with this
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
>>> anyway if anyone uses it.
>>> -
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
Signed-off-by: Johannes Schindelin
---
Documentation/
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 cherry-pick'able set of patch series?
The o
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 a
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 cherry-pick'able set of patch series?
The o
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
>>>
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 rebase--helper to generate todo lis
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 is
> safe to just r
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 tha
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 upstream Git.
The previous patc
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
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 star
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 access
> > 'https://github.com/oneeyeman1/dbh
64 matches
Mail list logo