This commit replaces spawning `git write-tree` with API calls.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash.c | 41 -
1 file changed, 12 insertions(+), 29 deletions(-)
diff --git a/builtin/stash.c b/builtin/stash.c
index
Add stash push to the helper.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 245 +++-
git-stash.sh| 6 +-
2 files changed, 245 insertions(+), 6 deletions(-)
diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c
From: Joel Teichroeb
Add a builtin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
lets conversion get started without the other commands being
finished.
The helper is being implemented as a drop in replacement for
stash so that
Add stash list to the helper and delete the list_stash function
from the shell script.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 31 +++
git-stash.sh| 7 +--
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git
Add stash save to the helper and delete functions which are no
longer needed (`show_help()`, `save_stash()`, `push_stash()`,
`create_stash()`, `clear_stash()`, `untracked_files()` and
`no_changes()`).
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 50 +++
Rename some test cases' labels to be more descriptive and under 80
characters per line.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3903-stash.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index
Remove whitespaces after redirection operators and wrap
long lines.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3903-stash.sh | 120 ---
1 file changed, 61 insertions(+), 59 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index
Mention in the documentation, that `show` accepts any
option known to `git diff`.
Signed-off-by: Paul-Sebastian Ungureanu
---
Documentation/git-stash.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index
This commit introduces tests for `git stash show`
config. It tests all the cases where `stash.showStat`
and `stash.showPatch` are unset or set to true / false.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3907-stash-show-config.sh | 83
1 file changed, 83
Implement `strbuf_insertf()` and `strbuf_vinsertf()` to
insert data using a printf format string.
Original-idea-by: Johannes Schindelin
Signed-off-by: Paul-Sebastian Ungureanu
---
strbuf.c | 36
strbuf.h | 9 +
2 files changed, 45 insertions(+)
Hello,
This is the 11th iteration of C git stash. Here are some of the changes,
based on Thomas's and dscho's suggestions (from mailing list / pull request
#495):
- improved memory management. Now, the callers of `do_create_stash()`
are responsible of freeing the parameter they pass in.
From: Joel Teichroeb
In preparation for converting the stash command incrementally to
a builtin command, this patch improves test coverage of the option
parsing. Both for having too many parameters, or too few.
Signed-off-by: Joel Teichroeb
Signed-off-by: Paul-Sebastian Ungureanu
---
Change the narrow test added in 31e2617a5f ("format-patch: add
--range-diff option to embed diff in cover letter", 2018-07-22) to
test the full output. This test would have spotted a regression in the
output if it wasn't beating around the bush and tested the full
output, let's do that.
Fix a regression introduced in my a48e12ef7a ("range-diff: make diff
option behavior (e.g. --stat) consistent", 2018-11-13). Since the
format-patch setup code implicitly sets --stat --summary by default,
we started emitting the --stat output in the cover letter's
range-diff.
As noted in
[Dropping LKML & git-packagers from CC]
On Thu, Nov 22 2018, Eric Sunshine wrote:
> On Thu, Nov 22, 2018 at 10:58 AM Ævar Arnfjörð Bjarmason
> wrote:
>> There's a regression related to this that I wanted to send a headsup
>> for, but don't have time to fix today. Now range-diff in format-patch
--
Greetings,
I wish to seek your assistance to legally move my late husband's estate
to your country for investment and charity purposes.If interested,i
will give you more details.Thanks.
Mrs.Aya Ashraf
--
Which FS was this tested on?, is Git LFS I keep hearing about also considered
a "filesystem" for git?
Could you also test with the following applied on top?
Carlo
-- >8 --
Subject: [PATCH] entry: remove windows fallback to inode checking
this test is really FS specific, so is better to avoid
On Thu, Nov 22, 2018 at 8:28 AM Ævar Arnfjörð Bjarmason
wrote:
> Range-diff:
> By the way, is there any way to
> Pass the equivalent of "git range-diff origin/master topic-2 topic-3"
> to git-format-patch?
git-range-diff documentations says that the three-argument form:
git range-diff
On Thu, Nov 22 2018, Jeff King wrote:
> On Wed, Nov 21, 2018 at 11:48:14AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>>
>> 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:
From: Torsten Bögershausen
Commit b878579ae7 (clone: report duplicate entries on case-insensitive
filesystems - 2018-08-17) adds a warning to user when cloning a repo
with case-sensitive file names on a case-insensitive file system.
This test has never been enabled for MINGW.
It had been
On Wed, Nov 21, 2018 at 11:48:14AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> 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:
On Mon, Nov 12, 2018 at 11:04:52AM -0800, Stefan Beller wrote:
> > for (odb = the_repository->objects->odb; odb; odb = odb->next) {
> > if (odb->local)
> > return odb->path;
> > }
> > return NULL; /* yikes? */
> >
> > ? That feels like it's making things more
On Thu, Nov 08, 2018 at 01:57:52PM -0500, Jeff Hostetler wrote:
> > Should we simply be disallowing sparse:path filters over upload-pack?
>
> The option to allow an absolute path over the wire probably needs more
> thought as you suggest.
>
> Having it in the traverse code was useful for local
On Sat, Nov 17, 2018 at 11:07:32PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I suspect it would be less confusing if the rewrite were inverted, like:
> >
> > [url "gh:"]
> > rewriteTo = https://github.com
> > rewritePrivate
> >
> > [url "git://github.com"]
> > rewriteTo =
Hi Stefan,
On Thu, 22 Nov 2018, stefan.na...@atlas-elektronik.com wrote:
> Just a quick note:
>
> I installed v2.20.0-rc0 with these options:
>
> $ cat /etc/install-options.txt
> Editor Option: VIM
> Custom Editor Path:
> Path Option: Cmd
> SSH Option: OpenSSH
> CURL Option: OpenSSL
> CRLF
On Tue, Nov 20, 2018 at 05:37:18PM +0100, Duy Nguyen wrote:
> > But in (b), we use the number of stored objects, _not_ the allocated
> > size of the objects array. So we can run into a situation like this:
> >
> > 1. packlist_alloc() needs to store the Nth object, so it grows the
> >
On Tue, Nov 20, 2018 at 10:06:57AM -0500, Derrick Stolee wrote:
> On 11/20/2018 4:44 AM, Jeff King wrote:
> > In cases like this I think it's often a good idea to have a perf test.
> > Those are expensive anyway, and we'd have the double benefit of
> > exercising the code and showing off the
On Wed, Nov 21, 2018 at 11:28:28AM -0800, Bryan Turner wrote:
> But that test code exists because Bitbucket Server provides a Java API
> [1][2] which allows third-party developers to easily build arbitrary
> Git commands to invoke for their own functionality. Setting
>
On Thu, Nov 22, 2018 at 11:16:38AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> > + rm -rf .git &&
> > + git init &&
> > + echo "* diff=bin" > .gitattributes &&
> > + printf "a\0b" >data.bin &&
> > + git add
On Wed, Nov 21, 2018 at 09:52:27PM +0100, Thomas Braun wrote:
> diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
> index 69fc55ea1e..8c2558b07d 100644
> --- a/diffcore-pickaxe.c
> +++ b/diffcore-pickaxe.c
> @@ -144,6 +144,11 @@ static int pickaxe_match(struct diff_filepair *p, struct
>
On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
> Peff, could you elaborate on your "load testing" setup? which could
> give us any hints
> on what to look for?, FWIW I hadn't been able to reproduce the problem
> anywhere
> else (and not for a lack of trying)
The script I use is
On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
> > So it's maybe do-able, but not quite as trivial as one might hope.
>
> A trivial alternative would be to recommend adding a man page for
> 3rd-party git-s.
>
> In other words, as soon as `git-sizer` is accompanied by
On Wed, Nov 21, 2018 at 6:08 PM Stephen P. Smith wrote:
>
> Picking up someones stalled patch is one thing, picking up Linus' patch is in
> a different league.
No, I think it works the other way - my random patches are likely the
_least_ important ones, simply because I can carry them around in
On Thu, Nov 22, 2018 at 11:58:36AM +0100, Greg Hurrell wrote:
> I was troubleshooting some breakage in some code that consumes the
> output of `git log --raw` and looking on two machines with different
> versions of Git just now I discovered the output format has changed
> somewhere between
From: SZEDER Gábor
The commit graph file format describes an optional 'Large Edge List'
chunk, and the function writing out this chunk is called
write_graph_chunk_large_edges(). Then there are two functions in
'commit-graph.c', namely write_graph_chunk_data() and
write_commit_graph(), which
Rephrase the title shown for the progress output emitted by
close_reachable(). The message I added in 7b0f229222 ("commit-graph
write: add progress output", 2018-09-17) gave the impression that it
would count up to the number of commit objects.
But that's not what the number means. It just
From: SZEDER Gábor
The optional 'Large Edge List' chunk of the commit graph file stores
parent information for commits with more than two parents. Since the
chunk is optional, write_commit_graph() looks through all commits to
find those with more than two parents, and then writes the commit
Add progress output to be shown when we're writing out the
commit-graph, this adds to the output already added in 7b0f229222
("commit-graph write: add progress output", 2018-09-17).
As noted in that commit most of the progress output isn't displayed on
small repositories, but before this change
Add progress output to sections of code between "Annotating[...]" and
"Computing[...]generation numbers". This can collectively take 5-10
seconds on a large enough repository.
On a test repository with I have with ~7 million commits and ~50
million objects we'll now emit:
$ ~/g/git/git
The "Writing out" progress output was off-by-one because I'd screwed
up a merge conflict. Fix that, and update the various progress output.
On my test setup the "Annotating commit graph" progress sometimes
shows up on linux.git, sometimes not, it's right on that edge of
taking 1 second. So always
Change the "Annotating commit graph" progress output to show a
completion percentage. I added this in 7b0f229222 ("commit-graph
write: add progress output", 2018-09-17) and evidently didn't notice
how easy it was to add a completion percentage.
Now for e.g. linux.git we'll emit:
~/g/git/git
Make the "Writing out" part of the progress output more
descriptive. Depending on the shape of the graph we either make 3 or 4
passes over it.
Let's present this information to the user in case they're wondering
what this number, which is much larger than their number of commits,
has to do with
Remove the empty line between a QSORT(...) and the subsequent oideq()
for-loop. This makes it clearer that the QSORT(...) is being done so
that we can run the oideq() loop on adjacent OIDs. Amends code added
in 08fd81c9b6 ("commit-graph: implement write_commit_graph()",
2018-04-02).
Show the percentage progress for the "Finding commits for commit
graph" phase for the common case where we're operating on all packs in
the repository, as "commit-graph write" or "gc" will do.
Before we'd emit on e.g. linux.git with "commit-graph write":
Finding commits for commit graph:
Make the progress output shown when we're searching for commits to
include in the graph more descriptive. This amends code I added in
7b0f229222 ("commit-graph write: add progress output", 2018-09-17).
Now, on linux.git, we'll emit this sort of output in the various modes
we support:
$ git
Remove the empty line between a QSORT(...) and the subsequent oideq()
for-loop. This makes it clearer that the QSORT(...) is being done so
that we can run the oideq() loop on adjacent OIDs. Amends code added
in 08fd81c9b6 ("commit-graph: implement write_commit_graph()",
2018-04-02).
Add progress output to sections of code between "Annotating[...]" and
"Computing[...]generation numbers". This can collectively take 5-10
seconds on a large enough repository.
On a test repository with I have with ~7 million commits and ~50
million objects we'll now emit:
$ ~/g/git/git
Change the "Annotating commit graph" progress output to show a
completion percentage. I added this in 7b0f229222 ("commit-graph
write: add progress output", 2018-09-17) and evidently didn't notice
how easy it was to add a completion percentage.
Now for the very large test repository mentioned in
Add progress output to be shown when we're writing out the
commit-graph, this adds to the output already added in 7b0f229222
("commit-graph write: add progress output", 2018-09-17).
As noted in that commit most of the progress output isn't displayed on
small repositories, but before this change
This incorporates SZEDER's recent two-part series, rebases mine on
top, and fixes a few things while I'm at it. Now there's no progress
output where we don't show a completion percentage.
SZEDER Gábor (2):
commit-graph: rename 'num_extra_edges' variable to 'num_large_edges'
commit-graph:
Make the progress output shown when we're searching for commits to
include in the graph more descriptive. This amends code I added in
7b0f229222 ("commit-graph write: add progress output", 2018-09-17).
Now, on linux.git, we'll emit this sort of output in the various modes
we support:
$ git
Show the percentage progress for the "Finding commits for commit
graph" phase for the common case where we're operating on all packs in
the repository, as "commit-graph write" or "gc" will do.
Before we'd emit on e.g. linux.git with "commit-graph write":
Finding commits for commit graph:
From: SZEDER Gábor
The optional 'Large Edge List' chunk of the commit graph file stores
parent information for commits with more than two parents. Since the
chunk is optional, write_commit_graph() looks through all commits to
find those with more than two parents, and then writes the commit
Make the "Writing out" part of the progress output more
descriptive. Depending on the shape of the graph we either make 4 or 5
passes over it.
Let's present this information to the user in case they're wondering
what this number, which is much larger than their number of commits,
has to do with
Rephrase the title shown for the progress output emitted by
close_reachable(). The message I added in 7b0f229222 ("commit-graph
write: add progress output", 2018-09-17) gave the impression that it
would count up to the number of commit objects.
But that's not what the number means. It just
From: SZEDER Gábor
The commit graph file format describes an optional 'Large Edge List'
chunk, and the function writing out this chunk is called
write_graph_chunk_large_edges(). Then there are two functions in
'commit-graph.c', namely write_graph_chunk_data() and
write_commit_graph(), which
Hi Peff,
On Sat, 17 Nov 2018, Jeff King wrote:
> On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> > So maybe we should just document this interface better. It seems one
> > implicit dependency is that we expect a manpage for the tool to exist
> > for --help.
>
>
The topic ot/ref-filter-object-info broke the Windows build since it entered
pu, and as a consequence we have no test coverage of the other topics in pu.
Sadly, this topic now advanced to next. Junio, I would like to ask you to
merge this fix down to next and to advance to master together with
From: Johannes Schindelin
The `%lld` format is supported on Linux and macOS, but not on Windows.
This issue has been reported ten days ago (Message-ID:
nycvar.qro.7.76.6.1811121300520...@tvgsbejvaqbjf.bet), but the
corresponding topic still advanced to `next` in the meantime, breaking
the
Hello!
I have very bad news for you.
06/08/2018 - on this day I hacked your operating system and got full access to
your account git@vger.kernel.org
On that day your account git@vger.kernel.org password was: e7d1w8i2n
It is useless to change the password, my malware intercepts it every time.
Hi Junio,
On Wed, 21 Nov 2018, Junio C Hamano wrote:
> Оля Тележная writes:
>
> >> I am OK if we avoid PRIdMAX and use PRIuMAX instead with a cast to
> >> the corresponding size in this codepath, as long as we properly
> >> handle negative oi.disk_size field, which may be telling some
> >>
I was troubleshooting some breakage in some code that consumes the output of
`git log --raw` and looking on two machines with different versions of Git just
now I discovered the output format has changed somewhere between v2.14.5:
:00 100644 0... 9773b7718... A
On Thu, Nov 22, 2018 at 11:31 AM Stephen P. Smith wrote:
>
> 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 Wed, Nov 21, 2018 at 10:37 PM Max Kirillov wrote:
>
> On Wed, Nov 21, 2018 at 05:04:25PM -0800, Carlo Arenas wrote:
> > the last child of its children long gone with an error as shown by :
> >
> > 9255 1 git-http-backend CALL close(1)
> ...
> > 9255 1 git-http-backend CALL
>
On Wed, Nov 21 2018, Thomas Braun wrote:
> 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
On Wed, Nov 21 2018, Thomas Braun wrote:
> 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
On Thu, 22 Nov 2018 at 07:39, Mgr Georg Black wrote:
> 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.
Have you considered "using git cherry-pick can be used to backport
changes one by one" [1]
> I red
Just a quick note:
I installed v2.20.0-rc0 with these options:
$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use
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
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
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 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
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
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 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
"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
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.
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 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.
>
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 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.
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
>
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
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
---
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
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
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
> 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
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
901 - 1000 of 197272 matches
Mail list logo
