On Tue, Aug 28, 2018 at 05:20:20PM -0400, Eric Sunshine wrote:
> prune_worktrees() and delete_git_dir() both remove worktree
> administrative entries from .git/worktrees, and their implementations
> are nearly identical. The only difference is that prune_worktrees() is
> also capable of removing a
Hi,
Robert Dailey wrote:
> Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
> ask is, I want that setting to be 'input' on linux but 'true' on
> Windows.
Others are exploring your question about the configuration language,
but I want to emphasize some other ramifications.
Why
Jeff King wrote:
> I guess I just wonder if I set up a mirror on another domain, would
> anybody actually _use_ it? I'd think most people would just go to
> public-inbox.org as the de facto URL.
If it's faster than public-inbox.org and you don't mind the traffic I
would send, then I'll use it. :)
On Wed, Aug 29, 2018 at 10:02:43AM +, Eric Wong wrote:
> Jeff King wrote:
> > I've thought about mirroring it to a public server as well, just for
> > redundancy. But without the same domain, I'm not sure it would be all
> > that useful as a community resource.
>
> I wouldn't get too attache
On Wed, Aug 29, 2018 at 04:46:29PM +0200, Johannes Schindelin wrote:
> On Wed, 29 Aug 2018, Jeff King wrote:
>
> > On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:
> >
> > > Rather than have a "hack day", I would actually prefer to work with
> > > other contributors in a way
On Wednesday, August 29, 2018 7:43:05 PM MST Ramsay Jones wrote:
>
> Hope this helps.
>
> ATB,
> Ramsay Jones
I was working on the patch for wt-status.c and thought I screwed up my git
database. So I ran fsck and ran into the tag issue.
Thanks
sps
On Wed, Aug 29, 2018 at 03:12:37PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > 2. To get our landing page and list of projects in order (and also
> > micro-projects for applicants). This can probably build on the
> > previous round at:
> >
> >https://git.github.io/Outreachy-15/
>
On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> > Could you cut down to a real minimal reproduction, i.e. just these 20
> > lines or so?
>
> I'm working on getting down to a minimal reproduction, a few lines at
> a time. One thing that seems strange: as I've removed lines, ther
On 30/08/18 02:56, Stephen & Linda Smith wrote:
> I am getting the following warning when runing a git fsck command against tag
> v0.99.
Yes, that is expected.
>
> $ git --version
> git version 2.18.0
>
> $ git fsck
> checking object directories: 100% (256/256), done.
> warning in tag d6602
Good day my dear friend,
Let me start by introducing myself. I am Bartholomew Caleb, an accounts
officer with Bank of Africa here in Burkina Faso West Africa.
I am writing you this letter based on the latest development at my bank whichI
will like to bring to your personal edification. ($9mill
On Thu, Aug 30, 2018 at 02:21:51AM +, brian m. carlson wrote:
> On Wed, Aug 29, 2018 at 11:37:25AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > It seems to me that aside from t/helper/test-hash-speed.c and
> > t/t0014-hash.sh everything being added here modifies existing files with
> > many aut
On Wed, Aug 29, 2018 at 08:41:36AM -0400, Derrick Stolee wrote:
> On 8/28/2018 8:58 PM, brian m. carlson wrote:
> > Instead of using hard-coded constants for object sizes, use
> > the_hash_algo to look them up. In addition, use a function call to look
> > up the object ID version and produce the c
On Wed, Aug 29, 2018 at 11:37:25AM +0200, Ævar Arnfjörð Bjarmason wrote:
> It seems to me that aside from t/helper/test-hash-speed.c and
> t/t0014-hash.sh everything being added here modifies existing files with
> many authors, and would thus also need their permission to re-license as
> anything
I did have some possibly interfering settings in my .gitconfig
previously. I removed everything, so all the commands I'll describe
were run with an empty config.
On Mon, Aug 27, 2018 at 1:47 PM Stefan Beller wrote:
> I suspected you might have a different diff algorithm configured,
> so I tested
Hello my dear.
I have been expecting your response based on the email I sent you few days ago.
Please, study my mail and respond back to me as the matter is becoming late.
Expecting your urgent response.
Yours Sincerely,
Mr. Kimasala.
I am getting the following warning when runing a git fsck command against tag
v0.99.
$ git --version
git version 2.18.0
$ git fsck
checking object directories: 100% (256/256), done.
warning in tag d6602ec5194c87b0fc87103ca4d67251c76f233a: missingTaggerEntry:
invalid format - expected 'tagger' l
Dear git people,
I've created a diff algorithm that focuses on creating readable diffs,
see https://github.com/pierstitus/klondiff
The git integration as an external diff command works quite well,
though it would be nice to integrate it deeper in git, and also in
git-gui and gitk. Any way to use e
Hi Junio,
On Wed, Aug 29, 2018 at 3:38 PM Junio C Hamano wrote:
> * en/directory-renames-nothanks (2018-08-29) 4 commits
> - SQUASH???
> - am: avoid directory rename detection when calling recursive merge machinery
> - merge-recursive: add ability to turn off directory rename detection
> - t
On Wed, Aug 29, 2018 at 11:32:08AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Aug 29 2018, brian m. carlson wrote:
>
> > SHA-1 is weak and we need to transition to a new hash function. For
> > some time, we have referred to this new function as NewHash.
> >
> > The selection criteria for
Hi Junio,
On Wed, Aug 29, 2018 at 3:12 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > +test_expect_success 'rebase --interactive: NO directory rename' '
> > + test_when_finished "git -C no-dir-rename rebase --abort" &&
> > + (
> > + cd no-dir-rename &&
> > +
> > +
On Wed, Aug 29, 2018 at 01:46:23PM -0700, Jonathan Nieder wrote:
> > Can you elaborate on that?
>
> What I'm saying is, regardless of the syntax used, as a user I *need*
> a way to look up $some_hash as a sha256-name, with zero risk of Git
> trying to outsmart me and treating $some_hash as a sha1
On Wed, Aug 29, 2018 at 10:53:01AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Aug 29 2018, brian m. carlson wrote:
>
> > Generally, one gets better performance out of cryptographic routines
> > written in assembly than C, and this is also true for SHA-256
>
> It makes sense to have a libg
On Wed, Aug 29, 2018 at 02:03:34PM -0700, Junio C Hamano wrote:
> Andreas Gruenbacher writes:
>
> > Some commands like 'log' default to HEAD if no other revisions are
> > specified on the command line or otherwise. Unfortunately, excludes
> > (^) cancel out that default, so when a command only
On Tue, Aug 28, 2018 at 09:05:48PM -0700, Jonathan Nieder wrote:
> >Add two additional helpers,
> > test_oid_cache, which can be used to load data for test_oid from
> > standard input, and test_oid_init, which can be used to load certain
> > fixed values from lookup
On Wed, Aug 29, 2018 at 5:54 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Wed, 29 Aug 2018, Elijah Newren wrote:
>
> > Signed-off-by: Elijah Newren
> > ---
> > merge-recursive.c | 18 +-
> > merge-recursive.h | 1 +
> > 2 files changed, 14 insertions(+), 5 deletions(-)
>
On Wed, Aug 29, 2018 at 08:37:48AM -0400, Derrick Stolee wrote:
> On 8/28/2018 8:56 PM, brian m. carlson wrote:
> > + rawsz="$(test_oid rawsz)" &&
> > + hexsz="$(test_oid hexsz)" &&
>
> These are neat helpers! The 'git commit-graph verify' tests in
> t5318-commit-graph.sh should automatically
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The builtin rebase and the builtin interactive rebase have been
> developed independently, on purpose: Google Summer of Code rules
> specifically state that students have to work on independent projects,
> they cannot
René Scharfe writes:
> Add best-effort support for patches sent using format=flowed (RFC 3676).
> Remove leading spaces ("unstuff"), remove soft line breaks (indicated
> by space + newline), but leave the signature separator (dash dash space
> newline) alone.
>
> Warn in git am when encountering
Ben Peart writes:
> There isn't any change in behavior with unknown extensions and this
> patch. If an unknown extension exists it will just get ignored and
> reported as an "unknown extension" or "die" if it is marked as
> "required."
OK.
Thomas Gummerer writes:
> Yeah that makes sense. Maybe something like this?
>
> (replying to here to keep
> the patches in one thread)
>
> Documentation/technical/rerere.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/technical/rerere.txt
> b/Documentation/techn
Jonathan Nieder writes:
> Tim Schumacher wrote:
>
>> Subject: doc: Don't echo sed command for manpage-base-url.xsl
>
> Cribbing from my review of v2: a description like
>
> Documentation/Makefile: make manpage-base-url.xsl generation quieter
>
> would make it more obvious what this does whe
Andreas Gruenbacher writes:
> Some commands like 'log' default to HEAD if no other revisions are
> specified on the command line or otherwise. Unfortunately, excludes
> (^) cancel out that default, so when a command only excludes
> revisions (e.g., 'git log ^origin/master'), the command will not
Eric Sunshine writes:
> This is an extract from v3 of es/chain-lint-more[1] which never got
> picked up. Instead, v2 of that series[2] got merged to 'next' and later
> 'master'. The only change between v2 and v3 was to make 'chainlint' also
> recognize double-quoted here-doc tags. This solo patch
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.
Git 2.19-rc1 is out. Hopefully th
On Wed, Aug 29, 2018 at 06:03:53PM -0400, Jeff King wrote:
> Without your second patch applied, this complains about mmap-ing
> /dev/null (or any zero-length file).
>
> Also, \x escapes are sadly not portable (dash, for example, does not
> respect them). You have to use octal instead (which is no
On Wed, Aug 29, 2018 at 05:20:25PM -0400, Jeff King wrote:
> Nice catch. The patch looks good to me, but just to lay out my thought
> process looking for other related problems:
>
> We have two types of instructions:
>
> 1. Take N bytes from position P within the source.
>
> 2. Take the nex
Elijah Newren writes:
> +test_expect_success 'rebase --interactive: NO directory rename' '
> + test_when_finished "git -C no-dir-rename rebase --abort" &&
> + (
> + cd no-dir-rename &&
> +
> + git checkout B^0 &&
> +
> + set_fake_editor &&
> +
On Wed, Aug 29, 2018 at 10:58:57PM +0200, Jann Horn wrote:
> This verifies the changes from commit "patch-delta: fix oob read".
A minor nit, but usually we'd either introduce tests along with the
fix, or introduce them beforehand as test_expect_failure and then flip
them to success along with the
On Wed, Aug 29, 2018 at 05:46:21PM -0400, Jeff King wrote:
> > I think even with ASAN, you'd still need read_in_full() or an mmap()
> > wrapper that fiddles with the ASAN shadow, because mmap() always maps
> > whole pages:
> >
> > $ cat mmap-read-asan-blah.c
> > #include
> > #include
> > int ma
On Wed, Aug 29, 2018 at 11:40:41PM +0200, Jann Horn wrote:
> > If we want to detect this kind of thing in tests, we should probably be
> > relying on tools like ASan, which would cover all mmaps.
> >
> > It would be nice if there was a low-cost way to detect this in
> > production use, but it look
On 8/29/2018 1:12 PM, Junio C Hamano wrote:
Ben Peart writes:
This is possible because the current extensions don't access the cache
entries in the index_state structure so are OK that they don't all exist
yet.
The CACHE_EXT_TREE, CACHE_EXT_RESOLVE_UNDO, and CACHE_EXT_UNTRACKED
extensions
On Wed, Aug 29, 2018 at 11:34 PM Jeff King wrote:
>
> On Wed, Aug 29, 2018 at 10:58:56PM +0200, Jann Horn wrote:
>
> > This ensures that any attempts to access memory directly after the input
> > buffer or delta buffer in a delta test will cause a segmentation fault.
> >
> > Inspired by vsftpd.
>
On 8/29/2018 1:14 PM, Junio C Hamano wrote:
Ben Peart writes:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1c42364988..79f8296d9c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2391,6 +2391,12 @@ imap::
The configuration variables
On Wed, Aug 29, 2018 at 10:58:56PM +0200, Jann Horn wrote:
> This ensures that any attempts to access memory directly after the input
> buffer or delta buffer in a delta test will cause a segmentation fault.
>
> Inspired by vsftpd.
Neat trick, but it seems funny to protect this one buffer in
non
On Wed, Aug 29, 2018 at 02:09:13PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>
> >> Yeah, then let's just convert '/' with as little overhead as possible.
> >
> > Do you care about case-folding issues (e.g., submodules "FOO
On Wed, Aug 29, 2018 at 02:10:37PM -0700, Stefan Beller wrote:
> > Yes, that makes even the capitalized "CON" issues go away. It's not a
> > one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
>
> foo_ would map to foo__, and foo- would map to something else.
> (foo- as we do n
On Wed, Aug 29, 2018 at 2:18 PM Jonathan Nieder wrote:
>
> Hi,
>
> Stefan Beller wrote:
>
> >> Yes, that makes even the capitalized "CON" issues go away. It's not a
> >> one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
> >
> > foo_ would map to foo__, and foo- would map to so
On 08/29, Stefan Beller wrote:
> On Wed, Aug 29, 2018 at 2:09 PM Jonathan Nieder wrote:
> >
> > Jeff King wrote:
> > > On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
> >
> > >> Yeah, then let's just convert '/' with as little overhead as possible.
> > >
> > > Do you care about case
On Wed, Aug 29, 2018 at 10:58:55PM +0200, Jann Horn wrote:
> If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
> `memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
> into `dst_buf`.
>
> This is not an exploitable bug because triggering the bug increments the
Hi,
Stefan Beller wrote:
>> Yes, that makes even the capitalized "CON" issues go away. It's not a
>> one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
>
> foo_ would map to foo__, and foo- would map to something else.
> (foo- as we do not rewrite dashes, yet?)
>
>> If we want
On Wed, Aug 29, 2018 at 2:09 PM Jonathan Nieder wrote:
>
> Jeff King wrote:
> > On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>
> >> Yeah, then let's just convert '/' with as little overhead as possible.
> >
> > Do you care about case-folding issues (e.g., submodules "FOO" and "fo
> Yes, that makes even the capitalized "CON" issues go away. It's not a
> one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
foo_ would map to foo__, and foo- would map to something else.
(foo- as we do not rewrite dashes, yet?)
>
> If we want that, too, I think something like
Jeff King wrote:
> On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>> Yeah, then let's just convert '/' with as little overhead as possible.
>
> Do you care about case-folding issues (e.g., submodules "FOO" and "foo"
> colliding)?
>
> I'm OK if the answer is "no", but if you do want
On Mon, Aug 27, 2018 at 03:12:56PM -0700, Stefan Beller wrote:
> When cloning a superproject with the option
> --recurse-submodules='.', it is easy to find yourself wanting
> a submodule active, but not having that submodule present in
> the modules directory.
>
> Signed-off-by: Stefan Beller
>
On Wed, Aug 29, 2018 at 11:10:51AM -0700, Stefan Beller wrote:
> > Do you care about case-folding issues (e.g., submodules "FOO" and "foo"
> > colliding)?
>
> I do. :(
>
> 2d84f13dcb6 (config: fix case sensitive subsection names on writing,
> 2018-08-08)
> explains the latest episode of case fo
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> In other words, I want the input format and output format completely
>> decoupled.
>
> I thought that the original suggestion was to use "hashname:" as a
> prefix to specify input format. In other words
>
> sha1:abababab
> sha256:aba
This ensures that any attempts to access memory directly after the input
buffer or delta buffer in a delta test will cause a segmentation fault.
Inspired by vsftpd.
Signed-off-by: Jann Horn
---
t/helper/test-delta.c | 78 +--
1 file changed, 53 insertions
This verifies the changes from commit "patch-delta: fix oob read".
Signed-off-by: Jann Horn
---
t/t5303-pack-corruption-resilience.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/t/t5303-pack-corruption-resilience.sh
b/t/t5303-pack-corruption-resilience.sh
index 3634e
If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
`memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
into `dst_buf`.
This is not an exploitable bug because triggering the bug increments the
`data` pointer beyond `top`, causing the `data != top` sanity check af
Jonathan Nieder writes:
> In other words, I want the input format and output format completely
> decoupled.
I thought that the original suggestion was to use "hashname:" as a
prefix to specify input format. In other words
sha1:abababab
sha256:abababab
And an unadorned abababab
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>> In other words, I want the input format and output format completely
>> decoupled. If I pass ^{sha1}, I am indicating the input format. To
>> specify the output format, I'd use --output-format instead.
>
> This
On Wed, Aug 29, 2018 at 10:17 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > Not quite, as this is ...
> >
> > Looking at the test in the previous patch, I would think a reasonable
> > workflow
> > in the test is ...
> >
> >> The MOVE_HEAD_FORCE codepath that follows this hunk is, eh,
Ævar Arnfjörð Bjarmason writes:
> Fix this by removing the redundant quotes. There's no need for them,
> and the resulting code works under all the aforementioned shells. This
> fixes a regression in c2f1d3989 ("t4013: test new output from diff
> --abbrev --raw", 2017-12-03) first released with G
+cc the mailing list
> > >
> > > git merge development_feature_branch
> > > fatal: refusing to merge unrelated histories
> > >
> >
> > See the git merge man page for the
> > --allow-unrelated-histories switch.
>
> I have tried that switch, however when merging a small feature branch,
> the merge
Thank you for taking the time to help me Stefan
On Aug 29, 2018 15:15, "Stefan Beller" wrote:
>
> On Wed, Aug 29, 2018 at 9:49 AM Tomas Zubiri wrote:
> >
> > Hello all,
> >
> > I have recently joined a team there seems to be a couple of issue
> > with the git repositories:
> >
> >
> > 1- A bra
Some commands like 'log' default to HEAD if no other revisions are
specified on the command line or otherwise. Unfortunately, excludes
(^) cancel out that default, so when a command only excludes
revisions (e.g., 'git log ^origin/master'), the command will not produce
any result.
If all the speci
On Wed, Aug 29 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>
>>> what objects would you expect the following to refer to?
>>>
>>> abcdabcd^{sha1}
>>> abcdabcd^{sha256}
>>> ef01ef01^{sha1}
>>> ef01ef01^{sha256}
>>
>>
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>> what objects would you expect the following to refer to?
>>
>> abcdabcd^{sha1}
>> abcdabcd^{sha256}
>> ef01ef01^{sha1}
>> ef01ef01^{sha256}
>
> I still can't really make any sense of why anyone would even
Johannes Schindelin writes:
> The `stash` command only incidentally requires that the author is set, as
> it calls `git commit` internally (which records the author). As stashes
> are intended to be local only, that author information was never meant to
> be a vital part of the `stash`.
>
> I cou
On Wed, Aug 29 2018, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> And with that model, ^{sha256}^{tree}
>> could mean to obtain the sha256 value of and then derive
>> the tree from that object,
>
> What does "the sha256 value of " mean?
>
> For example, in a repository wi
On Wed, Aug 29, 2018 at 10:59 AM Jonathan Nieder wrote:
>
> Stefan Beller wrote:
>
> > And with that model, ^{sha256}^{tree}
> > could mean to obtain the sha256 value of and then derive
> > the tree from that object,
>
> What does "the sha256 value of " mean?
s/hexvalue/hexdigit
On Wed, Aug 29, 2018 at 9:49 AM Tomas Zubiri wrote:
>
> Hello all,
>
> I have recently joined a team there seems to be a couple of issue
> with the git repositories:
>
>
> 1- A branch created from development cannot be merged into the
> production branch.
>
>
>
> (production)
>
> git merge develo
On Tue, Aug 28, 2018 at 10:25 PM Jeff King wrote:
>
> On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>
> > 3) (optional) instead of putting it all in modules/, use another
> >directory gitmodules/ for example. this will make sure we can tell
> >if a repository has been conv
Stefan Beller wrote:
> And with that model, ^{sha256}^{tree}
> could mean to obtain the sha256 value of and then derive
> the tree from that object,
What does "the sha256 value of " mean?
For example, in a repository with two objects:
1. an object with sha1-name abcdabcdabcda
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Aug 24 2018, Jonathan Nieder wrote:
>> Ævar Arnfjörð Bjarmason wrote:
>>> Or is this expected to be chained, as e.g. ^{tag}^{sha256} ?
>>
>> Great question. The latter (well, ^{sha256}^{tag}, not the
>> other way around).
>
> Since nobody's chimed in
On Wed, Aug 29, 2018 at 2:13 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Aug 24 2018, Jonathan Nieder wrote:
>
> > Hi,
> >
> > Ævar Arnfjörð Bjarmason wrote:
> >
> >>> git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}
> >>
> >> How is this going to interact with other peel syntax?
On 29.08.18 18:55, Jonathan Nieder wrote:
Tim Schumacher wrote:
Subject: doc: Don't echo sed command for manpage-base-url.xsl
Cribbing from my review of v2: a description like
Documentation/Makefile: make manpage-base-url.xsl generation quieter
would make it more obvious what this d
Stefan Beller writes:
> Not quite, as this is ...
>
> Looking at the test in the previous patch, I would think a reasonable workflow
> in the test is ...
>
>> The MOVE_HEAD_FORCE codepath that follows this hunk is, eh, already
>> forcing to correct the situation, so there is no need to touch tha
Ben Peart writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 1c42364988..79f8296d9c 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2391,6 +2391,12 @@ imap::
> The configuration variables in the 'imap' section are described
>
Duy Nguyen writes:
> Yeah I kinda hated dummy_entry too but the feeling wasn't strong
> enough to move towards the index->version check. I guess I'm going to
> do it now.
Sounds like a plan. Thanks again for a pleasant read.
Ben Peart writes:
> This is possible because the current extensions don't access the cache
> entries in the index_state structure so are OK that they don't all exist
> yet.
>
> The CACHE_EXT_TREE, CACHE_EXT_RESOLVE_UNDO, and CACHE_EXT_UNTRACKED
> extensions don't even get a pointer to the index s
Tim Schumacher wrote:
> Subject: doc: Don't echo sed command for manpage-base-url.xsl
Cribbing from my review of v2: a description like
Documentation/Makefile: make manpage-base-url.xsl generation quieter
would make it more obvious what this does when viewed in "git log
--oneline".
> P
Tim Schumacher wrote:
> Subject: doc: Don't echo sed command for manpage-base-url.xsl
At first glance, I thought this was going to change the rendered
documentation in some way. Maybe this should say
Makefile: make 'sed' commands quieter
? That led me to look in the Makefile, where it
Hello all,
I have recently joined a team there seems to be a couple of issue
with the git repositories:
1- A branch created from development cannot be merged into the
production branch.
(production)
git merge development_feature_branch
fatal: refusing to merge unrelated histories
2-
On Wed, Aug 29 2018, Andrei Rybak wrote:
> On 2018-08-29 12:02, Eric Wong wrote:
>> Anyways I hope to teach public-inbox to auto-linkify Message-ID-looking
>> strings "" into URLs for domain-portability,
>> (but it's ambiguous with email addresses). But yeah, I don't
>> like things being tied t
Hi Ulrich,
On Tue, 28 Aug 2018, Ulrich Gemkow wrote:
> A trivial enhancement request:
>
> All commands which require that the author is set (and complain if
> it is not set) should accept the option --author.
>
> At least the command stash does not accept this option. We are using
> git version
Previously, the sed command for generating manpage-base-url.xsl
was printed to the console when being run.
Make the console output for this rule similiar to all the
other rules by printing a short status message instead of
the whole command.
Signed-off-by: Tim Schumacher
---
Documentation/Makef
On 2018-08-29 12:02, Eric Wong wrote:
> Anyways I hope to teach public-inbox to auto-linkify Message-ID-looking
> strings "" into URLs for domain-portability,
> (but it's ambiguous with email addresses). But yeah, I don't
> like things being tied to domain names.
This would be very useful for peo
The big changes in this itteration are:
- Switched to index.threads to provide control over the use of threading
- Added another worker thread to load the index extensions in parallel
- Applied optimization expand_name_field() suggested by Duy
The net result of these optimizations is a savings
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It accomplishes this by having the primary thread loop across the index file
tracking the offset and (for V4 indexe
- strbuf_remove() in expand_name_field() is not exactly a good fit
for stripping a part at the end, _setlen() would do the same job
and is much cheaper.
- the open-coded loop to find the end of the string in
expand_name_field() can't beat an optimized strlen()
I used p0002-read-cache.s
This patch helps address the CPU cost of loading the index by loading
the cache extensions on a worker thread in parallel with loading the cache
entries.
This is possible because the current extensions don't access the cache
entries in the index_state structure so are OK that they don't all exist
Team,
the corresponding Git for Windows v2.19.0-rc1 (most notably with the
Experimental Options page in the installer letting you opt into using the
built-in `stash` and `rebase`) was built by Jameson Miller (and me) last
night and can be found here:
https://github.com/git-for-windows/git/release
Hi Peff,
On Wed, 29 Aug 2018, Jeff King wrote:
> On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:
>
> > Rather than have a "hack day", I would actually prefer to work with
> > other contributors in a way that we have not done before, but which I
> > had the pleasure of "test
Hi Peff,
On Wed, 29 Aug 2018, Jeff King wrote:
> On Mon, Aug 27, 2018 at 03:22:39PM +0200, Johannes Schindelin wrote:
>
> > Having said that, I believe that we core contributors can learn to have a
> > fruitful online meeting. With 30+ participants, too.
> >
> > Learning from my past life in ac
On 8/29/2018 9:27 AM, Derrick Stolee wrote:
On 8/29/2018 9:09 AM, Johannes Schindelin wrote:
What I meant was to leverage the midx code, not the .midx files.
My comment was motivated by my realizing that both the SHA-1 <-> SHA-256
mapping and the MIDX code have to look up (in a *fast* way) inf
Hi Jonathan,
On Tue, 28 Aug 2018, Jonathan Nieder wrote:
> [... talking about the IRC channel ...]
>
> My offer to +v anyone affected by the channel's current settings still
> stands (just /msg me). Zero people have taken me up on this offer so
> far.
I did have problems seeing any private mes
From: Johannes Schindelin
The builtin rebase and the builtin interactive rebase have been
developed independently, on purpose: Google Summer of Code rules
specifically state that students have to work on independent projects,
they cannot collaborate on the same project.
One fallout is that the r
The builtin rebase and the builtin interactive rebase have been developed
independently, on purpose: Google Summer of Code rules specifically state
that students have to work on independent projects, they cannot collaborate
on the same project.
The reason is probably the very fine tradition in aca
Hi Jonathan,
On Tue, 28 Aug 2018, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
> > On Mon, 27 Aug 2018, Junio C Hamano wrote:
> >> Johannes Schindelin writes:
> >>> Jonathan Nieder wrote:
>
> Please include this information in the commit message. It's super
> helpful to find t
1 - 100 of 124 matches
Mail list logo
