The -S option of log looks for differences that changes the
number of occurrences of the specified string (i.e. addition/deletion)
in a file.
Add a test to ensure that we keep looking into binary files with -S
as changing that would break backwards compatibility in unexpected ways.
Based on the previous discussion in [1] I've prepared patches which teach
log -G to ignore binary files. log -S keeps its behaviour but got a test to
ensure that.
Feedback welcome!
[1]:
https://public-inbox.org/git/7a0992eb-adb9-a7a1-cfaa-3384bc4d3...@virtuell-zuhause.de/
Thomas Braun (2):
The -G option of log looks for the differences whose patch text
contains added/removed lines that match regex.
The concept of differences only makes sense for text files, therefore
we need to ignore binary files when searching with -G as well.
Signed-off-by: Thomas Braun
---
On Wed, Nov 21, 2018 at 04:02:04AM -0800, Carlo Arenas wrote:
> for some tracing, it would seem that it gets 0 when
> trying to read 4 bytes from what I think is a pipe that connects to a
> child that has been gone already for a while.
Could you clarify it? I'm afraid I don't understand.
On 21.11.2018 14:37, Junio C Hamano wrote:
Jeff King writes:
On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote:
From our GUI client we are invoking git operations on a possibly large set
of files. ...
command line length, especially on Windows [1] and OSX [2]. To workaround
Based on the previous discussion in [1] I've prepared patches which teach
log -G to ignore binary files. log -S keeps its behaviour but got a test to
ensure that.
Feedback welcome!
[1]:
https://public-inbox.org/git/7a0992eb-adb9-a7a1-cfaa-3384bc4d3...@virtuell-zuhause.de/
PS: This is the
> I don't have a strong opinion about whether this would go in the
> design doc. I suppose the doc could have an "implementation plan"
> section describing temporary stopping points on the way to the final
> result, but it's not necessary to include that.
As long as this is something I'm just
Hi Junio,
On Wed, 21 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > A quick fix for a recent topic. Not overly critical, but I would deem this
> > v2.20.0-rc1 material.
> >
> > Johannes Schindelin (1):
> > rebase: warn about the correct tree's OID
>
Hi Junio,
On Wed, 21 Nov 2018, Junio C Hamano wrote:
> * js/vsts-ci (2018-10-16) 13 commits
> . travis: fix skipping tagged releases
> . README: add a build badge (status of the Azure Pipelines build)
> . tests: record more stderr with --write-junit-xml in case of failure
> . tests: include
On Wed, Nov 21, 2018 at 6:20 AM Jeff King wrote:
>
> On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
>
> > I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> > both Linux and Windows, and the only failures were related to this
> > change:
> >
> > * "git branch -l
International credit settlement
Office of the director of operations
World Bank united state of America.
Attention :
This Is To Officially Inform You That We Have Verified Your
Contact Inheritance File Presently On My Desk, And I Found Out
That You Have Not Received Your Payment Due To Your
On Wed, Nov 21, 2018 at 2:49 PM Max Kirillov wrote:
>
> Should I install bash for it to work? I cannot say I understand what the
> message is about.
yes, you need to install bash and use SHELL_PATH=/usr/pkg/bin/bash;
PERL_PATH=/usr/pkg/bin/perl for the perl script
Carlo
On 11/20/2018 8:26 PM, SZEDER Gábor wrote:
write_graph_chunk_data(f, GRAPH_OID_LEN, commits.list, commits.nr);
- write_graph_chunk_large_edges(f, commits.list, commits.nr);
+ if (num_large_edges)
+ write_graph_chunk_large_edges(f, commits.list, commits.nr);
Hi Stefan
On 20/11/2018 20:24, Stefan Xenos wrote:
>> If a merge has been cherry-picked we cannot update it as we don't record
>> which parent was used for the pick, however it is probably not a problem
>> in practice - I think it is unusual to amend merges.
>
> I've read and reread that
On Wed, Nov 21 2018, Junio C Hamano wrote:
> * jk/loose-object-cache (2018-11-13) 9 commits
> (merged to 'next' on 2018-11-18 at 276691a21b)
> + fetch-pack: drop custom loose object cache
> + sha1-file: use loose object cache for quick existence check
> + object-store: provide helpers for
On 11/20/2018 10:29 PM, Junio C Hamano wrote:
SZEDER Gábor writes:
I rename these variables to 'num_large_edges', because the commit
graph file format speaks about the 'Large Edge List' chunk.
However, I do find that the term 'extra' makes much more sense
Would it make sense to do the
On 11/20/2018 12:04 AM, tbo...@web.de wrote:
From: Torsten Bögershausen
Currently the length of data which is stored in memory is stored
in "unsigned long" at many places in the code base.
This is OK when both "unsigned long" and size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64
FWIW the issue goes away when more than 1 CPU is used in NetBSD 8,0
(32-bit) and for some tracing, it would seem that it gets 0 when
trying to read 4 bytes from what I think is a pipe that connects to a
child that has been gone already for a while.
Carlo
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The group of last-minute fixes
Denton Liu writes:
> Changes since V3:
> * Add patch to cleanup 'merge --squash c3 with c7' test in t7600
> * Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
Queued. Thanks, both.
On Wed, Nov 21 2018, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
>> This series has a strong smell of pushing back by the
>> toolsmiths who refuse to promptly upgrade to help their users, and
>> that is why I do not feel entirely happy with this series.
>
> Last reply, I
On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote:
> From our GUI client we are invoking git operations on a possibly large set
> of files. This may result in pathspecs which are exceeding the maximum
> command line length, especially on Windows [1] and OSX [2]. To workaround
> this
Jeff King writes:
> On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote:
>
>> From our GUI client we are invoking git operations on a possibly large set
>> of files. ...
>> command line length, especially on Windows [1] and OSX [2]. To workaround
>> this problem we are currently
On 20/11/2018 18:05, Stefan Beller wrote:
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
From: Phillip Wood
When using --color-moved-ws=allow-indentation-change allow lines with
the same indentation change to be grouped across blank lines. For now
this only works if the blank lines
I think I've got it now; maybe I just needed to sleep on it. It's
happier if I use the whole URL for trunk in the -T parameter.
I'll see how the rest of it plays out, but the `git svn show-ignore
--id=origin/trunk` command is working now.
On Wed, Nov 21, 2018 at 10:45 AM Jamie Jackson wrote:
>
>
ICF2008571:eclipse-workspace jjackson$ git svn clone \
> -r 95115:HEAD https://mydomain.com/svn/HUD/onecpd \
> -T trunk \
> --no-metadata \
> -A ~/eclipse-workspace/scraps/git_migration/users.txt \
> hudx-git-migration
ICF2008571:eclipse-workspace jjackson$ cd hudx-git-migration/
By the way, my goal is to pull in trunk (only) at first, and possibly
pull in certain branches (later) on an as-needed basis. I'll need to
sync the Git repo with SVN for a while, until we permanently switch to
Git (and put SVN in read-only).
On Wed, Nov 21, 2018 at 10:38 AM Jamie Jackson wrote:
>
>From Barr
This is Barr Philip Twite reaching you from the United Kingdom further to my
previous email notice. I have not received your response till this date.
Kindly forward to me the required information to engender further discuss.
Information should include; your full
Names
Address
Telephone
Hello,
I'm using an older version of git, so this particular issue might have
already been fixed.
$ git --version
git version 2.17.1
If I specify the branch to explore, git grep prints a colon instead of
a slash in the path:
$ git grep arm,coresight-tmc master:Documentation/devicetree
Here is today's test report.
Thanks,
-Stolee
[1] https://dev.azure.com/git/git/_build/results?buildId=271=logs
---
pu: c4a21f043160e02a25755bbf43e4d2fa0b9766aa
jch: 29ea8ddbcef3ec1c79fffa23cc5751a45344754c
next: 68bc7959f8dc2d629c09be1a52f1b95b977b3a13
master:
Hi everyone,
The 45th edition of Git Rev News is now published:
https://git.github.io/rev_news/2018/11/21/edition-45/
Thanks a lot to the contributors: Elijah Newren, Luca Milanesio,
Derrick Stolee and Johannes Schindelin!
Enjoy,
Christian, Jakub, Markus and Gabriel.
On Wed, Nov 21, 2018 at 08:37:03AM -0500, Jamie Jackson wrote:
> I'm brand new to svn-git and I'm having a problem right out of the
> gate. I suspect I need a different ID, but I have no clue how to get
> it.
>
> Here's the failed attempt:
>
From our GUI client we are invoking git operations on a possibly large
set of files. This may result in pathspecs which are exceeding the
maximum command line length, especially on Windows [1] and OSX [2]. To
workaround this problem we are currently splitting up such operations by
invoking
Hi Junio,
On Wed, 21 Nov 2018, Junio C Hamano wrote:
> Carlo Arenas writes:
>
> > Tested-by: Carlo Marcelo Arenas Belón
> >
> > the C version prepends: "fatal: " unlike the shell version for both
> > error messages
>
> In addition, "Invalid whitespace option" says 'bad', not
>
On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
> I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> both Linux and Windows, and the only failures were related to this
> change:
>
> * "git branch -l " used to be a way to ask a reflog to be
>created while
I think if we move to making this atom just store worktree path, that
needs to be implemented as a hashmap of refname->wtpath, which would
also solve this string_list issue, correct? Just making sure I'm not
missing something before I submit another patch.
On Tue, Nov 13, 2018 at 2:38 AM Junio C
OK, I see 3 votes for cyan and 4-5 people participating in the thread,
so I'll make it cyan in the next revision.
On Tue, Nov 13, 2018 at 3:49 PM Jeff King wrote:
>
> On Mon, Nov 12, 2018 at 06:07:18PM +, Rafael Ascensão wrote:
>
> > On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
On Wed, Nov 21, 2018 at 03:05:04PM +0100, Nickolai Belakovski wrote:
> I think if we move to making this atom just store worktree path, that
> needs to be implemented as a hashmap of refname->wtpath, which would
> also solve this string_list issue, correct? Just making sure I'm not
> missing
I'm brand new to svn-git and I'm having a problem right out of the
gate. I suspect I need a different ID, but I have no clue how to get
it.
Here's the failed attempt:
https://gist.github.com/jamiejackson/57e90302802f4990b36dfe28c3c71d13
What am I doing wrong?
Thanks,
Jamie
On Wed, Nov 21, 2018 at 02:54:34PM +0100, Marc Gonzalez wrote:
> If I specify the branch to explore, git grep prints a colon instead of
> a slash in the path:
>
> $ git grep arm,coresight-tmc master:Documentation/devicetree
> master:Documentation/devicetree:bindings/arm/coresight.txt:
Thomas Braun writes:
> The -S option of log looks for differences that changes the
> number of occurrences of the specified string (i.e. addition/deletion)
> in a file.
s/-S /-S/ and
s/the specified string/the specified block of text/ would make it
more in line with how
Jeff King writes:
> Yes, there are two ways to write this. With a conditional to initialize
> and return or to return the default, as we have here:
>
>> > >+ if (!git_config_get_bool("index.recordendofindexentries", ))
>> > >+ return val;
>> > >+ return 0;
>
> Or initialize the default
On Wed, Nov 21, 2018 at 06:38:20PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Changes since V3:
> > * Add patch to cleanup 'merge --squash c3 with c7' test in t7600
> > * Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
>
> Queued. Thanks, both.
I just
On Wed, Nov 21, 2018 at 05:04:25PM -0800, Carlo Arenas wrote:
> the error that gets eventually to stderr in the caller comes from
> get_packet_data, who is trying to read 4 bytes and gets 0.
> when looking at the trace (obtained with ktrace)
Yes too early close of the input data is the thing
"Stephen P. Smith" writes:
> On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
>> [Stalled]
>>
>> * lt/date-human (2018-07-09) 1 commit
>> - Add 'human' date format
>>
>> A new date format "--date=human" that morphs its output depending
>> on how far the time is from the
The post-rewrite hook is supposed to be invoked for each rewritten
commit. The fact that a commit was selected and processed by the rebase
operation (even though when we hit an error a user said it had no more
useful changes), suggests we should write an entry for it. In
particular, let's treat
Ever since commit 3f213981e44a ("add tests for rebasing merged history",
2013-06-06), t3425 has had tests which included the rebasing of merged
history and whose order of applied commits was checked. Unfortunately,
the tests expected different behavior depending on which backend was in
use.
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick
While 'quiet' and 'interactive' may sound like antonyms, the interactive
machinery actually has logic that implements several
interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
which won't pop up an editor. The rewrite of interactive rebase in C
added a quiet option, though
The post-rewrite hook is documented as being invoked by commands that
rewrite commits such as commit --amend and rebase, and that it will
be called for each rewritten commit.
Apparently, the three backends handled --skip'ed commits differently:
am: treat the skipped commit as though it weren't
The git-legacy-rebase.sh script previously had code of the form:
if git_am_opt:
if interactive:
if incompatible_opts:
show_error_about_interactive_and_am_incompatibilities
if rebase-merge:
if incompatible_opts
show_error_about_merge_and_am_incompatibilities
which was a
In commit f57696802c30 ("rebase: really just passthru the `git am`
options", 2018-11-14), the handling of `git am` options was simplified
dramatically (and an option parsing bug was fixed), but it introduced
a small regression in the error message shown when options only
understood by separate
[Important: Patch 1 fixes a (minor) regression in 2.20 relative to
2.19...but it also modifies a translated string. I'm not sure what the
right step we want to take there is. If you want me to submit it
separately and also resubmit the rest of this series to depend on the
separated first patch,
On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
> [Stalled]
>
> * lt/date-human (2018-07-09) 1 commit
> - Add 'human' date format
>
> A new date format "--date=human" that morphs its output depending
> on how far the time is from the current time has been introduced.
>
Thomas Braun writes:
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> The concept of differences only makes sense for text files, therefore
> we need to ignore binary files when searching with -G as well.
>
> Signed-off-by:
On Wednesday, November 21, 2018 6:06:13 PM MST Junio C Hamano wrote:
> "Stephen P. Smith" writes:
> > On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
> >> [Stalled]
> >>
> >> * lt/date-human (2018-07-09) 1 commit
> >>
> >> - Add 'human' date format
> >>
> >> A new date
Hello everyone.I red git manual but I can't figure out how to propagate
critical change from master branch to long live develop branch. I red chapter
about rebasing that I think could solve it but at the end of this chapter is
written that it's not recommended for pubic repositories. I don't
On Wed, Nov 21, 2018 at 2:49 PM Max Kirillov wrote:
>
> On Wed, Nov 21, 2018 at 04:02:04AM -0800, Carlo Arenas wrote:
> > for some tracing, it would seem that it gets 0 when
> > trying to read 4 bytes from what I think is a pipe that connects to a
> > child that has been gone already for a while.
On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote:
> diff --git a/builtin/prune.c b/builtin/prune.c
> index 41230f8215..11284d0bf3 100644
> --- a/builtin/prune.c
> +++ b/builtin/prune.c
> @@ -120,6 +120,7 @@ int cmd_prune(int argc, const char **argv, const char
> *prefix)
>
On Tue, Nov 20, 2018 at 02:21:51PM +0100, SZEDER Gábor wrote:
> On Tue, Nov 20, 2018 at 08:06:16AM -0500, Ben Peart wrote:
> > >diff --git a/read-cache.c b/read-cache.c
> > >index 4ca81286c0..1e9c772603 100644
> > >--- a/read-cache.c
> > >+++ b/read-cache.c
> > >@@ -2689,6 +2689,15 @@ void
60 matches
Mail list logo
