This is another set of patches from Git for Windows' fork that have been
sitting there since 2010, providing cross-platform GUI helpers to ask the
user a question or allow typing in a password.
This patch series was first submitted as
https://github.com/patthoyts/git-gui/pull/5 which was ignored
This series makes user-manual.html and user-manual.pdf render well with
Asciidoctor. The first patch is a while-at-it. The other three patches
then align Asciidoctor-rendering with AsciiDoc, first with two
bigger-scope patches, then with a local ASCII-art fix.
I was happily surprised that there we
On 2019-08-17 at 16:19:29, René Scharfe wrote:
> The code for building pax extended headers has been miscalculating
> lengths slightly shorter than powers of 10 since I wrote it in 2006.
> That affects entries for paths with a length of 990, 991, 9989, 9990,
> 9991, 99988 etc. and link targets 4 c
The code for building pax extended headers has been miscalculating
lengths slightly shorter than powers of 10 since I wrote it in 2006.
That affects entries for paths with a length of 990, 991, 9989, 9990,
9991, 99988 etc. and link targets 4 characters shorter. Here's a
series for fixing it.
a
This series focuses on allowing parallel access to zlib inflation and
using that to perform a faster git-grep in the non-worktree case.
Threads were disabled for this case at 53b8d93 ("grep: disable
threading in non-worktree case", 12-12-2011), due to performance drops.
However, by allowing threa
On Wed, Jul 31 2019, Jeff King wrote:
> On Fri, May 10, 2019 at 01:20:55AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > Michael Haggerty and I have (off-list) discussed variations on that, but
>> > it opens up a lot of new issues. Moving something into quarantine isn't
>> > atomic. So you've st
On Fri, May 10, 2019 at 01:20:55AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Michael Haggerty and I have (off-list) discussed variations on that, but
> > it opens up a lot of new issues. Moving something into quarantine isn't
> > atomic. So you've still corrupted the repo, but now it's recoverabl
Duy Nguyen writes:
> On Thu, Jun 27, 2019 at 9:53 AM Duy Nguyen wrote:
>>
>> On Thu, Jun 27, 2019 at 2:58 AM Junio C Hamano wrote:
>> >
>> > Nguyễn Thái Ngọc Duy writes:
>> >
>> > > This is small refinements (except 4/4).
>> >
>> > What's the status of these?
>>
>> Small test fixup needed. I
On Thu, Jun 27, 2019 at 9:53 AM Duy Nguyen wrote:
>
> On Thu, Jun 27, 2019 at 2:58 AM Junio C Hamano wrote:
> >
> > Nguyễn Thái Ngọc Duy writes:
> >
> > > This is small refinements (except 4/4).
> >
> > What's the status of these?
>
> Small test fixup needed. I should be able to do it later tod
On Thu, Jun 27, 2019 at 2:58 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This is small refinements (except 4/4).
>
> What's the status of these?
Small test fixup needed. I should be able to do it later today.
> As another low-prio topic interferes
> with the code touched by
Nguyễn Thái Ngọc Duy writes:
> This is small refinements (except 4/4).
What's the status of these? As another low-prio topic interferes
with the code touched by nd/switch-and-restore and hence needs to
wait for these to stabilize, I'd rather see us focus on finishing
these before switching our
This is small refinements (except 4/4).
2/4 relaxes the 'in-progress' check for bisect because switching while
bisecting is normal _and_ safe. 3/4 makes 'switch -d' completion much
more useful. 4/4 adds the last missing piece in 'git restore', records
new files in worktree as i-t-a.
Still on the
I noticed a while ago that I could not build Git's master in Git for
Windows' SDK when using GCC v8.x. This became a much less pressing problem
when I discovered a serious bug that would not let us compile with ASLR/DEP
enabled (the resulting executables would just throw segmentation faults left
an
On Mon, May 20, 2019 at 06:02:11AM -0400, Jeff King wrote:
> I haven't tried to reproduce yet. Is the repository (and patch) that you
> used to demonstrate this publicly available? Or alternatively, is it
> possible to show a backtrace from the coredump?
Never mind. It reproduces quite easily, be
On Tue, May 07 2019, Jeff King wrote:
> On Mon, May 06, 2019 at 11:44:06AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Maybe there's some case I haven't thought of that makes this stupid, but
>> I wonder if something like a "gc quarantine" might be a fix fo both of
>> the the issues you noted abo
On Mon, May 06, 2019 at 11:44:06AM +0200, Ævar Arnfjörð Bjarmason wrote:
> Maybe there's some case I haven't thought of that makes this stupid, but
> I wonder if something like a "gc quarantine" might be a fix fo both of
> the the issues you noted above.
>
> I.e. it seems to me that the main issu
On Tue, Mar 19 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 11:45:39PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > I don't think the quarantine stuff should impact contention at all. It's
>> > only quarantining the objects, which are the least contentious part of
>> > Git (because object co
On 04/15, Johannes Schindelin wrote:
> Hi Thomas,
>
> On Sun, 14 Apr 2019, Thomas Gummerer wrote:
>
> > @@ -99,10 +90,10 @@ modified file Documentation/git-revert.txt
>
> A better example might be a .c file, as the function name is often a
> pretty useful piece of information.
Yeah, maybe w
Hi Thomas,
On Sun, 14 Apr 2019, Thomas Gummerer wrote:
> @@ -99,10 +90,10 @@ modified file Documentation/git-revert.txt
A better example might be a .c file, as the function name is often a
pretty useful piece of information.
Read: I think it should be part of the outer hunk header.
Also, t
This series aims at improving the output of 'git range-diff',
especially in cases like the one mentioned in [*1*], where a diff
header, that was before the outer diff's hunk header was
misinterpreted as being the filename of the diff that followed it.
It does so by substituting the diff header of
On Thu, Apr 11, 2019 at 12:43:08PM -0700, Taylor Blau wrote:
> > I don't think we can ban malloc, since we have to use it ourselves. :)
> >
> > With some contortions, we probably could unban it specifically in
> > wrapper.c (though note there are a few other calls I've left which would
> > need to
Hi Peff,
On Thu, Apr 11, 2019 at 03:37:35PM -0400, Jeff King wrote:
> On Thu, Apr 11, 2019 at 12:14:52PM -0700, Taylor Blau wrote:
>
> > > This series cleans up most of the bare calls found by:
> > >
> > > git grep -E '[^a-z_](m|c|re)alloc\(' '*.c' :^compat :^contrib
> > > :^wrapper.c
> >
> > T
On Thu, Apr 11, 2019 at 12:14:52PM -0700, Taylor Blau wrote:
> > This series cleans up most of the bare calls found by:
> >
> > git grep -E '[^a-z_](m|c|re)alloc\(' '*.c' :^compat :^contrib :^wrapper.c
>
> This (admittedly pretty awesome) 'git grep' invocation reminds me of a
> series I was pre
Hi Peff,
On Thu, Apr 11, 2019 at 09:47:36AM -0400, Jeff King wrote:
> It was reported on the Git security list that there are a few spots
> which use a bare malloc() but don't check the return value, which could
> dereference NULL. I don't think any of these are exploitable in an
> interesting way
It was reported on the Git security list that there are a few spots
which use a bare malloc() but don't check the return value, which could
dereference NULL. I don't think any of these are exploitable in an
interesting way, beyond Git just segfaulting more or less immediately.
But we should still
Teach git to load default Trace2 settings from the system config (usually
"/etc/gitconfig"). The existing GIT_TR2_* environment variables can be used
to override the new system defaults. It also includes a little startup
refactoring.
Note: I found interactive testing of this feature to be awkward
During the 'git switch' discusion, Phillip found out that staged changes
could be silently lost when doing 'git checkout -m'. The first attempt
[2] tries to fix it by warning and moving on, because t7201.10 would
fail if we simply die() when there are staged changes.
This round, I update read-tree
On Tue, 19 Mar 2019 at 04:14, Jeff King wrote:
>
> On Sun, Mar 17, 2019 at 07:35:59PM +0100, Martin Ågren wrote:
>
> > I've taught `doc-diff` a few new knobs to support usage like
> >
> > $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD
>
> Very nice. All the patches look good to me.
Tha
On Sun, Mar 17, 2019 at 07:35:59PM +0100, Martin Ågren wrote:
> I've taught `doc-diff` a few new knobs to support usage like
>
> $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD
>
> and I don't think I've messed it up too badly in the process. I'm open
> to the idea that this might not
On Mon, Mar 18, 2019 at 11:45:39PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I don't think the quarantine stuff should impact contention at all. It's
> > only quarantining the objects, which are the least contentious part of
> > Git (because object content is idempotent, so we don't do any locking
On Mon, Mar 18 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 05:14:58PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> This series is unrelated (and does not conflict with) my in-flight gc
>> contention series
>> (https://public-inbox.org/git/20190315155959.12390-1-ava...@gmail.com/),
>> but the
On Mon, Mar 18, 2019 at 05:14:58PM +0100, Ævar Arnfjörð Bjarmason wrote:
> This series is unrelated (and does not conflict with) my in-flight gc
> contention series
> (https://public-inbox.org/git/20190315155959.12390-1-ava...@gmail.com/),
> but the "git-gc" docs should be updated to discuss the
>
I've been annoyed by the "gc" docs for a while. This fixes most of the
issues I've noticed, and also removes the duplication between the "gc"
variables in git-config(1) and in git-gc(1), which was made possible
by Duy's Documentation/config/* series.
This should make the "gc" docs more awesome, an
Martin Ågren writes:
> I've taught `doc-diff` a few new knobs to support usage like
>
> $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD
Nice.
> But I have made some progress on fixing up Asciidoctor *and* AsciiDoc
> issues using this, and once the output of the above command is empty
I've taught `doc-diff` a few new knobs to support usage like
$ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD
and I don't think I've messed it up too badly in the process. I'm open
to the idea that this might not be interesting to a whole lot of people.
But I have made some progress on f
When the working tree contains a repository with no commits, it's
treated as an empty directory, not a repository:
$ git init
$ git init no-commit && touch no-commit/untracked
$ git init with-commit && touch with-commit/untracked
$ git -C with-commit commit --allow-empty -mmsg
On Wed, Mar 13, 2019 at 03:16:30AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> Over at the companion PR for Git for Windows
> [https://github.com/git-for-windows/git/pull/2121], I discussed this with
> Peff (who introduced the loose object cache), and he pointed out that my
> original so
Being rather a power user of the interactive rebase, I discovered recently
that one of my scripts ran into an odd problem where an interactive rebase
appended new commands to the todo list, and the interactive rebase failed to
validate the (short) OIDs. But when I tried to fix things via git rebase
This patch series improves handling of very large repositories, as generated
by, for example, bup (https://github.com/bup/bup). Prolonged operation
thereof creates quite a lot of small pack files; repacking improves
filesystem performance of the objects/pack directory, but is quite
expensive, in t
I can only concur about the genuine usefulness of symbolic refs as
branch aliases. I wrote my shell script for this 5 years ago, and
I've made use of the facility almost every working day since.
I jump around branches frequently, and my feature branch names always
start with an issue/bug number f
On Tue, Mar 5, 2019 at 7:21 AM Junio C Hamano wrote:
>
> Kenneth Cochran writes:
>
> > From c1bad54b29ae1c1d8548d248f6ecaa5959e55f7b Mon Sep 17 00:00:00 2001
> > From: Kenneth Cochran
> > Date: Mon, 4 Mar 2019 09:40:22 -0600
> > Subject: [RFC PATCH 0/4] Add
Kenneth Cochran writes:
> From c1bad54b29ae1c1d8548d248f6ecaa5959e55f7b Mon Sep 17 00:00:00 2001
> From: Kenneth Cochran
> Date: Mon, 4 Mar 2019 09:40:22 -0600
> Subject: [RFC PATCH 0/4] Add alias option to git branch
> Cc: Sahil Dua ,
> Duy Nguyen ,
> Jeff King
From c1bad54b29ae1c1d8548d248f6ecaa5959e55f7b Mon Sep 17 00:00:00 2001
From: Kenneth Cochran
Date: Mon, 4 Mar 2019 09:40:22 -0600
Subject: [RFC PATCH 0/4] Add alias option to git branch
Cc: Sahil Dua ,
Duy Nguyen ,
Jeff King
I find myself often using git symbolic-ref to get around work
On Fri, Mar 01, 2019 at 08:14:26PM +0100, Alban Gruin wrote:
> > diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> > index f1cb45c227..7aaa86f1c0 100644
> > --- a/builtin/name-rev.c
> > +++ b/builtin/name-rev.c
> > @@ -431,6 +431,8 @@ int cmd_name_rev(int argc, const char **argv, const
> > c
Hi Jeff,
Le 01/03/2019 à 19:42, Jeff King a écrit :
> On Fri, Mar 01, 2019 at 06:50:20PM +0100, Alban Gruin wrote:
>
>> rafasc reported on IRC that on a repository with a lot of branches,
>> tags, remotes, and commits, name-rev --stdin could use a massive amount
>> of memory (more than 2GB of RAM
On Fri, Mar 01, 2019 at 06:50:20PM +0100, Alban Gruin wrote:
> rafasc reported on IRC that on a repository with a lot of branches,
> tags, remotes, and commits, name-rev --stdin could use a massive amount
> of memory (more than 2GB of RAM) to complete.
>
> This patch series tries to improve name-
rafasc reported on IRC that on a repository with a lot of branches,
tags, remotes, and commits, name-rev --stdin could use a massive amount
of memory (more than 2GB of RAM) to complete.
This patch series tries to improve name-rev’s memory usage.
There is some improvement that could be done, such
It was reported by Nazri Ramliy that ORIG_HEAD was set incorrectly again,
this time caused by the shortcut to call git am directly, without detouring
to a Unix shell script.
Patch 2/4 might look like something completely unrelated, but without it,
the update to HEAD might use an incorrect reflog m
This is on ms/packet-err-check.
This is a follow-up of my earlier work to allow partial CDN offloading
of fetch v2 response packfiles, which had the issue of having to buffer
(or suspend) progress and keepalive messages because we didn't have
sideband until the packfile section started (as I wrote
On Wed, 2018-12-19 at 00:59 -0500, John Passaro wrote:
> On Fri, Dec 14, 2018 at 6:10 PM John Passaro wrote:
> > All seems to work fine when I treat %Gs as a detached signature.
>
> In light of this, my best guess as to why the cleartext PGP message
> didn't verify properly is that the commit data
Especially on Windows, where Unix shell scripting is a foreign endeavor, and
an expensive one at that, we really want to avoid running through the Bash.
This not only makes everything faster, but also more robust, as the Bash we
use on Windows relies on a derivative of the Cygwin runtime, which in
On Fri, Dec 14, 2018 at 6:10 PM John Passaro wrote:
> All seems to work fine when I treat %Gs as a detached signature.
In light of this, my best guess as to why the cleartext PGP message
didn't verify properly is that the commit data normally doesn't end
with \n, but as far as I can tell there's n
On Fri, Dec 14, 2018 at 11:07:03AM -0500, John Passaro wrote:
> Then I might rename the other new placeholders too:
>
> %Gs: signed commit signature (blank when unsigned)
> %Gp: signed commit payload (i.e. in practice minus the gpgsig header;
> also blank when unsigned as well)
One complication:
On Sun, Dec 16, 2018 at 03:34:42PM +0100, Martin Ågren wrote:
> Your list seems complete to me in terms of "how could we teach doc-diff
> to diff asciidoctor vs asciidoc?". For the resulting diff to actually be
> useful ;-) there are two more outstanding issues that I see:
>
> - Headers and foo
On Sun, 16 Dec 2018 at 11:45, Jeff King wrote:
>
> On Sat, Dec 15, 2018 at 12:27:38PM +0100, Martin Ågren wrote:
> I think the relevant bits from [1] are:
>
> * Use `make --always-make ... install-man` in doc-diff.
> * ./doc-diff -f HEAD HEAD # note -f
> * Add empty commit and tweak config.mak
On Sat, Dec 15, 2018 at 12:27:38PM +0100, Martin Ågren wrote:
> I have (ab)used doc-diff to try to find instances where Asciidoctor and
> Asciidoc render our documentation differently. (See [1] for details on
> the hack.) This series fixes the differences that somehow stood out in
> the diff. Many
I have (ab)used doc-diff to try to find instances where Asciidoctor and
Asciidoc render our documentation differently. (See [1] for details on
the hack.) This series fixes the differences that somehow stood out in
the diff. Many smaller differences remain.
With each patch, I am giving one or a few
Michał Górny writes:
> Just a suggestion: since the raw signature is not very useful without
> the commit data to check it against, and the commit data is non-trivial
> to construct (requires mangling raw data anyway), maybe you could either
> add another placeholder to get the data for signature
v2:
I reworded the commit messages to explain the patches from the ground up
instead of only linking to the old commits, that got reverted.
> Just pretend that the ealier commits and their reversion never
> happened, and further pretend that we are doing the best thing that
> should happen to our
On Fri, Dec 14, 2018 at 6:10 PM John Passaro wrote:
>
> On Fri, Dec 14, 2018 at 11:49 AM Michał Górny wrote:
> >
> > On Fri, 2018-12-14 at 11:07 -0500, John Passaro wrote:
> > > On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
> > > >
> > > > On Thu, 2018-12-13 at 16:22 -0500, John Passaro w
On Fri, Dec 14, 2018 at 11:49 AM Michał Górny wrote:
>
> On Fri, 2018-12-14 at 11:07 -0500, John Passaro wrote:
> > On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
> > >
> > > On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> > > > Currently, users who do not have GPG installed have n
On Fri, 2018-12-14 at 11:07 -0500, John Passaro wrote:
> On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
> >
> > On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> > > Currently, users who do not have GPG installed have no way to discern
> > > signed from unsigned commits without exami
On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
>
> On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> > Currently, users who do not have GPG installed have no way to discern
> > signed from unsigned commits without examining raw commit data. I
> > propose two new pretty-print placehold
On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> Currently, users who do not have GPG installed have no way to discern
> signed from unsigned commits without examining raw commit data. I
> propose two new pretty-print placeholders to expose this information:
>
> %GR: full ("R"aw) contents
Currently, users who do not have GPG installed have no way to discern
signed from unsigned commits without examining raw commit data. I
propose two new pretty-print placeholders to expose this information:
%GR: full ("R"aw) contents of gpgsig header
%G+: Y/N if the commit has nonempty gpgsig heade
Stefan Beller writes:
>> - now these three changes that were problematic in the past is
>>resent without any update (other than that it has one preparatory
>>patch to add tests).
>
> One of the three changes was problematic, (e98317508c02),
> the other two are good (in company of the thi
On Fri, Dec 7, 2018 at 9:57 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > A couple days before the 2.19 release we had a bug report about
> > broken submodules[1] and reverted[2] the commits leading up to them.
> >
> > The behavior of said bug fixed itself by taking a different approac
Stefan Beller writes:
> A couple days before the 2.19 release we had a bug report about
> broken submodules[1] and reverted[2] the commits leading up to them.
>
> The behavior of said bug fixed itself by taking a different approach[3],
> specifically by a weaker enforcement of having `core.worktr
A couple days before the 2.19 release we had a bug report about
broken submodules[1] and reverted[2] the commits leading up to them.
The behavior of said bug fixed itself by taking a different approach[3],
specifically by a weaker enforcement of having `core.worktree` set in a
submodule [4].
The
Hi Junio,
On Wed, 31 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > An alternative approach which was rejected at the time (because it
> > interfered with the then-ongoing work to compile Git for Windows using
> > MS Visual C++) would patch the make_env
"Johannes Schindelin via GitGitGadget"
writes:
> An alternative approach which was rejected at the time (because it
> interfered with the then-ongoing work to compile Git for Windows using MS
> Visual C++) would patch the make_environment_block() function to skip the
> specified environment varia
In Git for Windows, we do not support running the Perl scripts with any
random Perl interpreter. Instead, we insist on using the shipped one (except
for MinGit, where we do not even ship the Perl scripts, to save on space).
However, if Git is called from, say, a Perl script running in a different
Geert Jansen writes:
> Maybe a better option would be to check for the non-existence of the [00-ff]
> directories under .git/objects.
Please do not do this; I expect many people do this before they
leave work, just like I do:
$ git repack -a -d -f --window=$largs --depth=$small
On Sun, Oct 28, 2018 at 10:50:19PM +, Ævar Arnfjörð Bjarmason wrote:
> I left the door open for that in the new config option 4/4 implements,
> but I suspect for Geert's purposes this is something he'd prefer to
> turn off in git on clone entirely, i.e. because it may be running on
> some rand
This patch series implements what I suggested in
https://public-inbox.org/git/87lg6jljmf@evledraar.gmail.com/
It's not a replacement for what Geert Jansen's RFC in
https://public-inbox.org/git/ed25e182-c296-4d08-8170-340567d89...@amazon.com/
does, which was to turn this off entirely on "clone"
Ævar Arnfjörð Bjarmason writes:
>> This is all to say: having a maximum size is good. 512 is big enough
>> to cover _most_ commits, but not so big that we may store _really_ big
>> filters.
>
> Makes sense. 512 is good enough to hardcode initially, but I couldn't
> tell from briefly skimming the
> | Implementation | Queries | Maybe | FP # | FP % |
> ||-|---|--|---|
> | Szeder | 66095 | 1142 | 256 | 0.38% |
> | Jonathan | 66459 | 107 | 89 | 0.16% |
> | Stolee | 53025 | 492 | 479 | 0.90% |
>
> (Note that we must have
On 10/16/2018 8:57 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Oct 16 2018, Derrick Stolee wrote:
On 10/16/2018 12:45 AM, Junio C Hamano wrote:
Derrick Stolee writes:
2. The filters are sized according to the number of changes in each
commit, with a minimum of one 64-bit word.
...
6. When we
On Tue, Oct 16 2018, Derrick Stolee wrote:
> On 10/16/2018 12:45 AM, Junio C Hamano wrote:
>> Derrick Stolee writes:
>>
>>> 2. The filters are sized according to the number of changes in each
>>> commit, with a minimum of one 64-bit word.
>>> ...
>>> 6. When we compute the Bloom filters, we don
On 10/16/2018 12:45 AM, Junio C Hamano wrote:
Derrick Stolee writes:
2. The filters are sized according to the number of changes in each
commit, with a minimum of one 64-bit word.
...
6. When we compute the Bloom filters, we don't store a filter for
commits whose first-parent diff has more tha
Derrick Stolee writes:
> 2. The filters are sized according to the number of changes in each
> commit, with a minimum of one 64-bit word.
> ...
> 6. When we compute the Bloom filters, we don't store a filter for
> commits whose first-parent diff has more than 512 paths.
Just being curious but wa
On 10/9/2018 3:34 PM, SZEDER Gábor wrote:
To keep the ball rolling, here is my proof of concept in a somewhat
cleaned-up form, with still plenty of rough edges.
Peff, Szeder, and Jonathan,
Thanks for giving me the kick in the pants to finally write a proof of
concept for my personal take on h
This series builds on en/merge-cleanup. Technically, this could be
broken into three separate topics with only one of them depending on
en/merge-cleanup, but I have a subsequent series that depends on both
en/merge-cleanup and the fixes here, so I'm submitting these four
patches as a set.
Elijah
On 10/9/2018 3:34 PM, SZEDER Gábor wrote:
To keep the ball rolling, here is my proof of concept in a somewhat
cleaned-up form, with still plenty of rough edges.
You can play around with it like this:
$ GIT_USE_POC_BLOOM_FILTER=$((8*1024*1024*8)) git commit-graph write
Computing commit gra
To keep the ball rolling, here is my proof of concept in a somewhat
cleaned-up form, with still plenty of rough edges.
You can play around with it like this:
$ GIT_USE_POC_BLOOM_FILTER=$((8*1024*1024*8)) git commit-graph write
Computing commit graph generation numbers: 100% (52801/52801), don
We recently (about eight months ago) transitioned to git source control systems
for several very large, very complex systems. We brought over several active
versions requiring maintenance updates, and also set up several subtree repos
to manage code shared between the systems. Recently, we attem
The first patch is a bug-fix. The second applies some more
`monospace`-ing, which should also be good thing.
The last two patches are based on my understanding that `git
commit-graph` handles the "commit graph file", without a dash. If that's
correct, there might be more such cleanups to be made i
While working on a series to make file collision conflict handling
consistent, I discovered a latent bug in merge_content()...and several
opportunities for cleanup. This series fixes that bug, deletes the
merge_file_special_markers() and merge_file_one() functions, and
renames a pair of functions
Jeff King writes:
>> Either is fine. I am not moving 'next' beyond what is necessary for
>> this release cycle during the pre-release freeze period, and because
>> I thought that Peff was in favor of squashing in the changes to the
>> original when the next cycle starts, I haven't bothered to me
On Mon, Sep 10, 2018 at 09:53:56AM -0700, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > I'm just reverting jk/pack-delta-reuse-with-bitmap out of next when
> > building my own package of git, but I think this really should be fixed
> > in that branch, either by merging the fix do
Ævar Arnfjörð Bjarmason writes:
> I'm just reverting jk/pack-delta-reuse-with-bitmap out of next when
> building my own package of git, but I think this really should be fixed
> in that branch, either by merging the fix down or reverting the original
> series out of next, I think just merging the
On Sat, Sep 01 2018, Jeff King wrote:
> On Fri, Aug 31, 2018 at 06:55:58PM -0400, Jeff King wrote:
>
>> On Fri, Aug 31, 2018 at 05:23:17PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> > On Tue, Aug 21 2018, Jeff King wrote:
>> >
>> > > +int bitmap_has_sha1_in_uninteresting(struct bitmap_index *bi
On Tue, Sep 04, 2018 at 12:30:14PM -0700, Stefan Beller wrote:
> > [1/4]: bitmap_has_sha1_in_uninteresting(): drop BUG check
> >
> > The actual fix. This should get merged to next ASAP (or the original
> > topic just reverted).
> >
> > [2/4]: t5310: test delta reuse with bitmaps
> >
>
> [1/4]: bitmap_has_sha1_in_uninteresting(): drop BUG check
>
> The actual fix. This should get merged to next ASAP (or the original
> topic just reverted).
>
> [2/4]: t5310: test delta reuse with bitmaps
>
> I did this separately to give us flexibility to squash or merge
> quic
On Fri, Aug 31, 2018 at 06:55:58PM -0400, Jeff King wrote:
> On Fri, Aug 31, 2018 at 05:23:17PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > On Tue, Aug 21 2018, Jeff King wrote:
> >
> > > +int bitmap_has_sha1_in_uninteresting(struct bitmap_index *bitmap_git,
> > > +
Note that you can also trivially convert a lot more instances of empty
checking to the "right" way: 'test_line_count = 0'
$ grep -Ir 'test_line_count = 0' t | wc -l
76
I think it would be nice to clean these up as well.
This series is a continuation of and applies on top of
'ab/test-must-be-empty-for-master', and converts even more places to
use 'test_must_be_empty'.
There are still a bunch of cases in the form of 'test -z "$(cmd...)"'
that could use 'test_must_be_empty'... maybe someday.
SZEDER Gábor (4):
te
On Mon, Aug 13, 2018 at 11:45:06AM -0700, Jonathan Tan wrote:
> > [1/7]: for_each_*_object: store flag definitions in a single location
> > [2/7]: for_each_*_object: take flag arguments as enum
> > [3/7]: for_each_*_object: give more comprehensive docstrings
> > [4/7]: for_each_packed_obje
This improves colors of the range-diff, see last patch for details.
This is a partial resend of
https://public-inbox.org/git/20180804015317.182683-1-sbel...@google.com/
and is also available via
git fetch https://github.com/stefanbeller/git sb/range-diff-better-colors
It applies on the (just r
Hi Peff,
On Fri, 10 Aug 2018, Jeff King wrote:
> On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote:
>
> > So unless you are willing to ignore, to willfully keep this breakage,
> > I would suggest not to introduce the ugliness of an overridden
> > upload-pack for the sole purpos
1 - 100 of 652 matches
Mail list logo
