The correct name in git-send-email.perl is aliasfiletype [1]. There are
actually two instances of this misspelling. The other was found and
fixed in 6068ac8848 (completion: add missing configuration variables -
2010-12-20)
[1] 994d6c66d3 (send-email: address expansion for common mailers - 2006-05-
On Sat, May 05 2018, Taylor Blau wrote:
> +--o::
> +--only-matching::
> + Show only the matching part of the lines.
> +
Makes sense to steal GNU grep's description here:
Print only the matched (non-empty) parts of a matching line, with
each such part on a separate output line.
> +
On Sat, May 5, 2018 at 4:43 AM, Taylor Blau wrote:
> Teach 'git-grep(1)' a new option, '--column', to show the column
> number of the first match on a non-context line.
Why? Or put it another way, what is this option used for? Only
git-jump? (which should also be mentioned here if true)
>
> For
Teach 'git-grep(1)' how to print a line header multiple times from
show_line() in preparation for it learning '--only-matching'.
show_line_header() comprises of the code in show_line() executed in
order to produce a line header. It is a one-for-one extraction of the
existing implementation.
For n
Hi,
Attached is a series to teach 'git-grep(1)' how to respond to
'--only-matching' (a-la GNU grep(1)'s --only-matching, including an '-o'
synonym) to only print the matching component(s) of a line. It is based
on v4 of tb/grep-colno, which was sent in [1].
This was suggested to me by Ævar in [2]
Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option
prints only the matching components of each line. It writes multiple
lines if more than one match exists on a given line.
For example:
$ git grep -on --column --heading git -- README.md | head -3
README.md
15:56:git
1
When calling match_line(), callers presently cannot determine the
relative offset of the match because match_line() discards the
'regmatch_t' that contains this information.
Instead, teach match_line() to take in a 'regmatch_t *' so that callers
can inspect the match's starting and ending offset f
To support showing the matched column when calling 'git-grep(1)', teach
'grep_opt' the normal set of options to configure the default behavior
and colorization of this feature.
Signed-off-by: Taylor Blau
---
grep.c | 3 +++
grep.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/grep.c b/g
Take advantage of 'git-grep(1)''s new option, '--column' in order to
teach Peff's 'git-jump' script how to jump to the correct column for any
given match.
'git-grep(1)''s output is in the correct format for Vim's jump list, so
no additional cleanup is necessary.
Signed-off-by: Taylor Blau
---
c
To support git-grep(1)'s new option, '--column', document and teach
grep.c how to interpret relevant configuration options, similar to those
associated with '--line-number'.
Signed-off-by: Taylor Blau
---
Documentation/config.txt | 5 +
Documentation/git-grep.txt | 3 +++
grep.c
Teach 'git-grep(1)' a new option, '--column', to show the column
number of the first match on a non-context line.
For example:
$ git grep -n --column foo | head -n3
.clang-format:51:14:# myFunction(foo, bar, baz);
.clang-format:64:7:# int foo();
.clang-format:75:8:# void foo()
Signed-off
To prepare for 'git grep' learning '--column', teach grep.c's
show_line() how to show the column of the first match on non-context
line.
Signed-off-by: Taylor Blau
---
grep.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/grep.c b/grep.c
index fb0fa232
lineNumber has casing that is inconsistent with surrounding options,
like color.grep.matchContext, and color.grep.matchSelected. Re-case this
documentation in order to be consistent with the text around it, and to
ensure that new entries are consistent, too.
Signed-off-by: Taylor Blau
---
Docume
Hi,
Attached is my fourth--and what I anticipate to be the final--re-roll of
my series to add teach 'git-grep(1)' a new '--column' flag.
Since last time, I have changed the following:
* Respond to Ævar's review suggesting that I (1) change git-jump's
README, (2) use --column over --column-
Hello Dscho,
On 04.05.2018 01:10, Johannes Schindelin wrote:
Hi Paul,
On Fri, 4 May 2018, Paul-Sebastian Ungureanu wrote:
The community bonding period started. It is well known that for a
greater rate of success, it is recommended to send weekly reports
regarding project status. But, what wo
On Fri, May 04, 2018 at 08:07:53AM -0500, Eric Blake wrote:
> [adding a cross-post to the git mailing list]
>
> On 05/04/2018 02:10 AM, Cornelia Huck wrote:
> > On Thu, 3 May 2018 22:51:40 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > This way they are easier to find using standard rules.
> >
On Thu, 3 May 2018 11:12:27 -0700
Stefan Beller wrote:
> >> There are three different possible solutions that have more value:
> >> (a) The path value is documented as the path from the toplevel of the
> >> superproject to the mount point of the submodule. If 'the' refers to
> >> the supe
On Fri, May 04 2018, Jakub Narebski wrote:
(Just off-the cuff here and I'm surely about to be corrected by
Derrick...)
> * What to do about merge commits, and octopus merges in particular?
> Should Bloom filter be stored for each of the parents? How to ensure
> fast access then (fixed-width
On Fri, May 04 2018, Jakub Narebski wrote:
> With early parts of commit-graph feature (ds/commit-graph and
> ds/lazy-load-trees) close to being merged into "master", see
> https://public-inbox.org/git/xmqq4ljtz87g@gitster-ct.c.googlers.com/
> I think it would be good idea to think what other
>
> Branch-diff vs v1:
> 1: 42db734a980 ! 1: 73398da7119 sequencer: learn about the special "fake
> root commit" handling
> @@ -54,40 +54,50 @@
> return NULL;
>}
>
> ++/* Read author-script and return an ident line (author
> timestamp) */
> +static const char *re
Hello,
With early parts of commit-graph feature (ds/commit-graph and
ds/lazy-load-trees) close to being merged into "master", see
https://public-inbox.org/git/xmqq4ljtz87g@gitster-ct.c.googlers.com/
I think it would be good idea to think what other data could be added
there to make Git even fa
On 3 May 2018 at 20:48, Andreas Heiduk wrote:
> Changes since the last reroll:
>
> - Better commit comment for "doc: align 'diff --no-index' in text and
> synopsis"
> This includes Martin's `s/with/and/` comment.
> - Eric's typo fix in "doc: add note about shell quoting to revision.txt"
> - Add
Hi Rafael,
On 4 May 2018 at 18:28, Rafael Ascensão wrote:
> While trying to create a pseudo reference named REF pointing to the
> empty tree iff it doesn't exist, I stumbled on the following:
>
> I assume both are valid ways to create such reference:
> a) $ echo -e option no-deref\\nupdat
Hi Junio,
On Sun, Apr 29, 2018 at 8:25 PM, Junio C Hamano wrote:
> * en/rename-directory-detection-reboot (2018-04-25) 36 commits
>
> Reboot of an attempt to detect wholesale directory renames and use
> it while merging.
>
> Will merge to 'next'.
Usually you have a mini-release-note in your
On Fri, May 04 2018, Duy Nguyen wrote:
> On Fri, May 4, 2018 at 9:54 AM, Ævar Arnfjörð Bjarmason
> wrote:
>> Realistically the way we do hooks now would make the UI of this suck,
>> i.e. you couldn't configure it globally or system-wide easily. Something
>> like what I noted in
>> https://public
Hello Dear
I am Sister Dorothy Kent I really need your assistance to help me discuss a
project .
Thanks,
Sister Dorothy Kent
On Thu, May 3, 2018 at 11:40 PM, Johannes Schindelin
wrote:
> I actually have a hacky script to fixup commits in a patch series. It lets
> me stage part of the current changes, then figures out which of the
> commits' changes overlap with the staged changed. If there is only one
> commit, it autom
On Fri, May 4, 2018 at 12:18 AM, Stefan Beller wrote:
> I just measured on git.git and linux.git (both of which are not *huge* by
> any standard, but should give a good indication. linux has 6M objects,
> and when allocating 1024 at a time, we run into the new block allocation
> ~6000 times).
>
>
Hi,
On Fri, May 4, 2018 at 9:21 AM, Elijah Newren wrote:
> On Fri, May 4, 2018 at 8:34 AM, Johannes Schindelin
> wrote:
>> The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
>> what changed between two iterations sent to the Git mailing list) is slightly
>> less useful
While trying to create a pseudo reference named REF pointing to the
empty tree iff it doesn't exist, I stumbled on the following:
I assume both are valid ways to create such reference:
a) $ echo -e option no-deref\\nupdate REF $(git hash-object -t tree
/dev/null) 0
Hi Dscho,
On Fri, May 4, 2018 at 8:34 AM, Johannes Schindelin
wrote:
> This change brings branch-diff yet another step closer to feature parity
> with tbdiff: it now shows the oneline, too, and indicates with `=` when
> the commits have identical diffs.
>
> @@ -270,9 +272,57 @@ static int get_co
On Fri, May 4, 2018 at 8:34 AM, Johannes Schindelin
wrote:
> The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
> what changed between two iterations sent to the Git mailing list) is slightly
> less useful for this developer due to the fact that it requires the
> `hungar
I can help you secure a private loan , should you be interested please respond
for more details .
Thanks
Allen
On Fri, 04 May 2018 11:24:39 +0900
Junio C Hamano wrote:
> Hmm, when somebody breaks "git server serve", we probably would not
> want to see the binary spewed to the output while debugging it. So
> I'd probably keep the redirection---it may be an improvement to use
> ">out" and then checking it
On Fri, Apr 27, 2018 at 12:13 PM, Bryan Turner wrote:
> On Fri, Apr 27, 2018 at 12:08 PM, Wink Saville wrote:
>>
>> The other change was rather than using
>> ""+refs/tags/*:refs/remote-tags/$name/*"
>> I've changed it to "+refs/tags/*:refs/remote/tags/$name/*" which seems
>> cleaner.
>> Again,
On 04/05/18 07:40, Johannes Schindelin wrote:
[snip]
> BTW I ran `make sparse` for the first time, and it spits out tons of
> stuff. And I notice that they are all non-fatal warnings, but so were the
> ones you pointed out above. This is a bit sad, as I would *love* to
> install a VSTS build job
When displaying a diff of diffs, it is possible that there is an outer
`+` before a context line. That happens when the context changed between
old and new commit. When that context line starts with a tab (after the
space that marks it as context line), our diff machinery spits out a
white-space er
This patch lets branch-diff use the same order as tbdiff.
The idea is simple: for left-to-right readers, it is natural to assume
that the branch-diff is performed between an older vs a newer version of
the branch. As such, the user is probably more interested in the
question "where did this come f
When diffing diffs, it can be quite daunting to figure out what the heck
is going on, as there are nested +/- signs.
Let's make this easier by adding a flag in diff_options that allows
color-coding the outer diff sign with inverted colors, so that the
preimage and postimage is colored like the dif
Arguably the most important part of branch-diff's output is the list of
commits in the two branches, together with their relationships.
For that reason, tbdiff introduced color-coding that is pretty
intuitive, especially for unchanged patches (all dim yellow, like the
first line in `git show`'s ou
At this stage, `git branch-diff` can determine corresponding commits of
two related commit ranges. This makes use of the recently introduced
implementation of the Hungarian algorithm.
The core of this patch is a straight port of the ideas of tbdiff, the
seemingly dormant project at https://github.
Tab completion of `branch-diff` is very convenient, especially given
that the revision arguments that need to be passed to `git branch-diff`
are typically more complex than, say, your grandfather's `git log`
arguments.
Without this patch, we would only complete the `branch-diff` part but
not the o
When showing what changed between old and new commits, we show a diff of
the patches. This diff is a diff between diffs, therefore there are
nested +/- signs, and it can be relatively hard to understand what is
going on.
With the --dual-color option, the preimage and the postimage are colored
like
For every regular color, there exists the inverted equivalent where
background and foreground colors are exchanged.
We will use this in the next commit to allow inverting *just* the +/-
signs in a diff.
Signed-off-by: Johannes Schindelin
---
color.h | 6 ++
1 file changed, 6 insertions(+)
When comparing commit messages, we need to keep in mind that they are
indented by four spaces. That is, empty lines are no longer empty, but
have "trailing whitespace". When displaying them in color, that results
in those nagging red lines.
Let's just right-trim the lines in the commit message, it
The main information in the branch-diff view comes from the list of
matching and non-matching commits, the diffs are additional information.
Indenting them helps with the reading flow.
Signed-off-by: Johannes Schindelin
---
builtin/branch-diff.c | 9 +
1 file changed, 9 insertions(+)
di
When showing the diff between corresponding patches of the two branch
versions, we have to make up a fake filename to run the diff machinery.
That filename does not carry any meaningful information, hence tbdiff
suppresses it. So we should, too.
Signed-off-by: Johannes Schindelin
---
builtin/br
This change brings branch-diff yet another step closer to feature parity
with tbdiff: it now shows the oneline, too, and indicates with `=` when
the commits have identical diffs.
Signed-off-by: Johannes Schindelin
---
builtin/branch-diff.c | 67 +--
1 file
From: Thomas Rast
These are essentially lifted from https://github.com/trast/tbdiff, with
light touch-ups to account for the new command name.
Apart from renaming `tbdiff` to `branch-diff`, only one test case needed
to be adjusted: 11 - 'changed message'.
The underlying reason it had to be adju
This is a heavily butchered version of the README written by Thomas
Rast and Thomas Gummerer, lifted from https://github.com/trast/tbdiff.
Signed-off-by: Johannes Schindelin
---
Documentation/git-branch-diff.txt | 239 ++
1 file changed, 239 insertions(+)
create mode
We are comparing complete, formatted commit messages with patches. There
are no function names here, so stop looking for them.
Signed-off-by: Johannes Schindelin
---
builtin/branch-diff.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/branch-diff.c b/builtin/branch-diff.c
inde
The Jonker-Volgenant algorithm was implemented to answer questions such
as: given two different versions of a topic branch (or iterations of a
patch series), what is the best pairing of commits/patches between the
different versions?
Signed-off-by: Johannes Schindelin
---
Makefile| 1 +
hu
Just like tbdiff, we now show the diff between matching patches. This is
a "diff of two diffs", so it can be a bit daunting to read for the
beginner.
And just like tbdiff, we now also accept the `--no-patches` option
(which is actually equivalent to the diff option `-s`).
This brings branch-diff
This builtin does not do a whole lot so far, apart from showing a usage
that is oddly similar to that of `git tbdiff`. And for a good reason:
the next commits will turn `branch-diff` into a full-blown replacement
for `tbdiff`.
At this point, we ignore tbdiff's color options as well as the
--no-pat
The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
what changed between two iterations sent to the Git mailing list) is slightly
less useful for this developer due to the fact that it requires the `hungarian`
and `numpy` Python packages which are for some reason really har
On Fri, May 4, 2018 at 5:23 PM, Johannes Schindelin
wrote:
>> > So that's what `info` does: it influences whether/where
>> > the command is listed in `git help`'s output... Interesting. I thought the
>> > lines here were trying to automate parts of the tab completion or
>> > something.
>>
>> Oh it
Hi Duy,
On Fri, 4 May 2018, Duy Nguyen wrote:
> On Fri, May 4, 2018 at 9:23 AM, Johannes Schindelin
> wrote:
> > Oh, okay. It was not at all clear to me what the exact format and role of
> > these lines are...
>
> Noted. I'm making more updates in this file in another topic and will
> add some
On Fri, May 04, 2018 at 04:44:49PM +0200, Duy Nguyen wrote:
> On Fri, May 4, 2018 at 9:23 AM, Johannes Schindelin
> wrote:
> > Oh, okay. It was not at all clear to me what the exact format and role of
> > these lines are...
>
> Noted. I'm making more updates in this file in another topic and will
On Fri, May 4, 2018 at 4:12 AM, Eckhard S. Maaß
wrote:
> If you do something like
>
> - git add .
> - git status
> - git commit
> - git show (or git diff HEAD)
>
> one would expect to have analogous output from git status and git show
> (or similar diff-related programs). This is g
On Fri, May 4, 2018 at 9:54 AM, Ævar Arnfjörð Bjarmason
wrote:
> Realistically the way we do hooks now would make the UI of this suck,
> i.e. you couldn't configure it globally or system-wide easily. Something
> like what I noted in
> https://public-inbox.org/git/871sf3el01@evledraar.gmail.com
On Fri, May 4, 2018 at 9:23 AM, Johannes Schindelin
wrote:
> Oh, okay. It was not at all clear to me what the exact format and role of
> these lines are...
Noted. I'm making more updates in this file in another topic and will
add some explanation so the next guy will be less confused.
> So that'
On Fri, May 4, 2018 at 3:18 AM, Heiko Voigt wrote:
> Hi,
>
> On Fri, May 04, 2018 at 08:29:32AM +, Middelschulte, Leif wrote:
>> Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
>> > It seems to me that you do not want to mix integration testing and
>> > testing of the feature
On 4 May 2018 at 14:26, Cornelia Huck wrote:
> On Fri, 4 May 2018 08:07:53 -0500
> Eric Blake wrote:
>> On the other hand, cc'ing all recipients for a largely mechanical patch
>> series that was split into 67 parts, in part because it touches so many
>> different maintainers' areas, may make the
On Fri, 4 May 2018 08:07:53 -0500
Eric Blake wrote:
> [adding a cross-post to the git mailing list]
>
> On 05/04/2018 02:10 AM, Cornelia Huck wrote:
> > On Thu, 3 May 2018 22:51:40 +0300
> > "Michael S. Tsirkin" wrote:
> >
> >> This way they are easier to find using standard rules.
> >>
> >>
When shown the email summary, an opportunity is presented for the user
to edit the email as if they had specified --annotate. This also permits
them to edit it multiple times.
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
Thanks for the review Eric, updated to address your feedback.
[adding a cross-post to the git mailing list]
On 05/04/2018 02:10 AM, Cornelia Huck wrote:
On Thu, 3 May 2018 22:51:40 +0300
"Michael S. Tsirkin" wrote:
This way they are easier to find using standard rules.
Signed-off-by: Michael S. Tsirkin
---
...
[Goes to find cover letter to figure o
When bisecting a performance regression using a config file,
`./bisect_regression --config my_perf.conf` for example, the
config file can contain Codespeed configuration which would
instruct the 'aggregate.perl' script called by the 'run'
script to output results in the Codespeed format and maybe
t
If you do something like
- git add .
- git status
- git commit
- git show (or git diff HEAD)
one would expect to have analogous output from git status and git show
(or similar diff-related programs). This is generally not the case, as
git status has hard coded values for diff rela
Hi,
On Fri, May 04, 2018 at 08:29:32AM +, Middelschulte, Leif wrote:
> Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
> > I still do not understand how the current behaviour is mismatching with
> > users expectations. Let's assume that you directly tracked the files of
> > L i
On Thu, May 3, 2018 at 9:18 AM, Ævar Arnfjörð Bjarmason
wrote:
> Introduce a checkout.implicitRemote setting which can be used to
> designate a remote to prefer (via checkout.implicitRemote=origin) when
> running e.g. "git checkout master" to mean origin/master, even though
> there's other remotes
On Fri, May 04 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> The reason I'm doing this is because I found it confusing that I can't
>> do:
>>
>> for t in tag commit tree blob; do ./git --exec-path=$PWD rev-parse
>> 7452^{$t}; done
>>
>> And get, respectively, only the S
Hi,
Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
> Hi,
>
> On Wed, May 02, 2018 at 07:30:25AM +, Middelschulte, Leif wrote:
> > Am Montag, den 30.04.2018, 19:02 +0200 schrieb Heiko Voigt:
> > > On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote:
> > > > Stefan wro
Drew DeVault wrote:
> When shown the email summary, an opportunity is presented for the user
> to edit the email as if they had specified --annotate. This also permits
> them to edit it multiple times.
Thanks, this seems like a good idea for the cover letter, especially.
I prefer to get the commi
On Thu, May 03 2018, Duy Nguyen wrote:
> On Thu, May 3, 2018 at 3:18 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> Introduce a checkout.implicitRemote setting which can be used to
>> designate a remote to prefer (via checkout.implicitRemote=origin) when
>> running e.g. "git checkout master" to mean or
On Fri, May 4, 2018 at 2:52 AM, Johannes Schindelin
wrote:
> On Thu, 3 May 2018, Eric Sunshine wrote:
>> On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin
>> wrote:
>> > +static const char * const builtin_branch_diff_usage[] = {
>> > + N_("git rebase--helper [] ( A..B C..D | A...B | base
Hi Junio,
On Fri, 4 May 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Johannes Schindelin (17):
> > Add a function to solve least-cost assignment problems
> > Add a new builtin: branch-diff
> > branch-diff: first rudimentary implementation
> > branch-diff: improve the
Hi Duy,
On Fri, 4 May 2018, Duy Nguyen wrote:
> On Thu, May 3, 2018 at 10:32 PM, Johannes Schindelin
> wrote:
> >
> > On Thu, 3 May 2018, Johannes Schindelin wrote:
> >
> >> On Thu, 3 May 2018, Duy Nguyen wrote:
> >>
> >> > On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin
> >> > wrote:
> >>
On Fri, May 4, 2018 at 3:14 AM, Eric Sunshine wrote:
> The setting up of a remote-tracking branch is DWIM'd as of 4e85333197
> ("worktree: make add dwim", 2017-11-26); it doesn't
> require an explicit option to enable it (though tracking can be
> disabled via --no-track). The "guess-remote" feat
Hi Junio,
On Fri, 4 May 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Note: due to differences in the diff algorithm (`tbdiff` uses the
> > Pythong module `difflib`, Git uses its xdiff fork), the cost matrix
>
> Pythong???
Yes, that's the French pronunciation.
Ciao,
Dscho
Hi Eric,
On Thu, 3 May 2018, Eric Sunshine wrote:
> On Thu, May 3, 2018 at 11:31 AM, Johannes Schindelin
> wrote:
> > This is a heavily butchered version of the README written by Thomas
> > Rast and Thomas Gummerer, lifted from https://github.com/trast/tbdiff.
> >
> > Signed-off-by: Johannes Sch
Hi Eric,
On Thu, 3 May 2018, Eric Sunshine wrote:
> On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin
> wrote:
> > Just like tbdiff, we now show the diff between matching patches. This is
> > a "diff of two diffs", so it can be a bit daunting to read for the
> > beginnger.
>
> s/beginnger/be
On Wed, May 2, 2018 at 2:25 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, May 02 2018, Eric Sunshine wrote:
>> A few observations:
>>
>> 1. DWIM has broad meaning; while this certainly falls within DWIM,
>> it's also just a _default_, so should this instead be named
>> "defaultRemote"?
>>
>> 2. Bui
Hi Eric,
On Thu, 3 May 2018, Eric Sunshine wrote:
> On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin
> wrote:
> > At this stage, `git branch-diff` can determine corresponding commits of
> > two related commit ranges. This makes use of the recently introduced
> > implementation of the Hungari
83 matches
Mail list logo