> Commit 6c213e863a ("http-backend: respect CONTENT_LENGTH for
receive-pack", 2018-07-27) adds a test which uses the non-portable
export construct. Replace it with "FOO=bar && export FOO" instead.
Thank you. Apparently the check is performed by make -C t, and I did
not run it like this since I
"Derrick Stolee via GitGitGadget" writes:
[I hope that the rest of replies would make it all right through
GitGitGadget]
> From: Derrick Stolee
>
> Signed-off-by: Derrick Stolee
> ---
> commit-graph.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/commit-graph.c b/commit-graph.c
Commit 94d4e2fb88 ("rebase -i: move rebase--helper modes to
rebase--interactive", 2018-07-24) removed the definition of the
'cmd_rebase__helper' symbol, but forgot to remove the corresponding
declaration in the 'builtin.h' header file.
Signed-off-by: Ramsay Jones
---
Hi Alban,
If you need to
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Augment commit_graph_compatible(r) to return false when the given
> repository r has commit grafts or is a shallow clone. Test that in these
> situations we ignore existing commit-graph files and we do not write new
>
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> The incredibly useful [`git-tbdiff`](https://github.com/trast/tbdiff) tool to
> compare patch series (say, to see what changed between two iterations sent to
> the Git mailing list) is slightly less useful for this developer due to the
>
On 07/29, Eric Sunshine wrote:
> On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer wrote:
> > On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > > Just like tbdiff, we now show the diff between matching patches. This is
> > > a "diff of two diffs", so it can be a bit daunting to read for the
On Jul 29 2018, Ævar Arnfjörð Bjarmason wrote:
> Also, to you and anyone else with access to AIX: I'd be happy to figure
> these issues out pro-actively if you give me a login to an AIX
> machine. I promise not to do anything except compile/debug/test git on
> it.
The GCC compile farm
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> After using this command extensively for the last two months, this
> developer came to the conclusion that even if the dual color mode still
> leaves a lot of room for confusion about what was actually changed,
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> This change brings `git range-diff` yet another step closer to
> feature parity with tbdiff: it now shows the oneline, too, and indicates
> with `=` when the commits have identical diffs.
>
> Signed-off-by:
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> The bulk of this patch consists of a heavily butchered version of
> tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from
Thanks for the mention here, but this was really mostly Thomas Rast's
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Signed-off-by: Derrick Stolee
> ---
> t/helper/test-repository.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/t/helper/test-repository.c b/t/helper/test-repository.c
> index
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Create new method commit_graph_compatible(r) to check if a given
> repository r is compatible with the commit-graph feature. Fill the
> method with a check to see if replace-objects exist.
All right, looks sensible. Did you
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> We are comparing complete, formatted commit messages with patches. There
> are no function names here, so stop looking for them.
While there are no function names here, trying out range-diff without
this patch
On 29/07/2018 22:06, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
On 29/07/2018 21:27, brian m. carlson wrote:
Well, that explains it. I would recommend submitting a patch to
https://github.com/cr-marcstevens/sha1collisiondetection, and the we can
pull in
On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
> On 29/07/2018 21:27, brian m. carlson wrote:
> > Well, that explains it. I would recommend submitting a patch to
> > https://github.com/cr-marcstevens/sha1collisiondetection, and the we can
> > pull in the updated submodule with that fix.
On Sun, Jul 29 2018, Michael wrote:
> On 29/07/2018 20:10, brian m. carlson wrote:
>> On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote:
>>> root@x066:[/tmp/xxx]git --version
>>> git version 2.13.3
>>> root@x066:[/tmp/xxx]git clone g...@github.com:aixtools/hello-world.git
>>> Cloning into
On 29/07/2018 21:27, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 08:59:39PM +0200, Michael wrote:
On 29/07/2018 20:10, brian m. carlson wrote:
Are you using SHA1DC on that system, and does compiling with another
SHA-1 implementation help? There was a change to the SHA1DC code big
endian
On 29/07/2018 20:10, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote:
root@x066:[/tmp/xxx]git --version
git version 2.13.3
root@x066:[/tmp/xxx]git clone g...@github.com:aixtools/hello-world.git
Cloning into 'hello-world'...
remote: Counting objects: 3, done.
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> This change brings `git range-diff` yet another step closer to
> feature parity with tbdiff: it now shows the oneline, too, and indicates
> with `=` when the commits have identical diffs.
>
> Signed-off-by:
The object ID parsing machinery is aware of "@" as a synonym for "HEAD"
and this is documented accordingly in gitrevisions(7). The push
documentation describes the source portion of a refspec as "any
arbitrary 'SHA-1 expression'"; however, "@" is not allowed on the
left-hand side of a refspec,
On Sun, Jul 29, 2018 at 9:13 AM Jakub Narebski wrote:
> Sidenote: the GitGitGadget doesn't fold/wrap lines properly in the
> cover-letter. Not that it is much of a problem.
Stefan opened a ticket at the gitgitgadget project:
https://github.com/gitgitgadget/gitgitgadget/issues/26
On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > Just like tbdiff, we now show the diff between matching patches. This is
> > a "diff of two diffs", so it can be a bit daunting to read for the
> > beginner.
> > [...]
> > Note also:
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> Just like tbdiff, we now show the diff between matching patches. This is
> a "diff of two diffs", so it can be a bit daunting to read for the
> beginner.
>
> An alternative would be to display an interdiff,
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> At this stage, `git range-diff` can determine corresponding commits
> of two related commit ranges. This makes use of the recently introduced
> implementation of the linear assignment algorithm.
>
> The core
On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote:
> root@x066:[/tmp/xxx]git --version
> git version 2.13.3
> root@x066:[/tmp/xxx]git clone g...@github.com:aixtools/hello-world.git
> Cloning into 'hello-world'...
> remote: Counting objects: 3, done.
> remote: Total 3 (delta 0), reused 0
Hi,
Several years ago I had downloaded and packaged git-2.10.1 with no real
issues, and it has been working fine. Deciding it was time for an update
I downloaded git-2.18.0 and built from scratch.
After testing lots of version - the the last 2.12 version worked;
git-2.13.2 works but
tOn Sun, Jul 29, 2018 at 5:36 PM Nguyễn Thái Ngọc Duy wrote:
>
> These extra comments should be make it easier to understand how to use
> locks in pack-objects delta search code. For reference, see
Side note. I wonder if we could take progress_lock() less often in
find_deltas() to reduce
These extra comments should be make it easier to understand how to use
locks in pack-objects delta search code. For reference, see
8ecce684a3 (basic threaded delta search - 2007-09-06)
384b32c09b (pack-objects: fix threaded load balancing - 2007-12-08)
50f22ada52 (threaded pack-objects: Use
On 29/07/18 04:13, Eric Sunshine wrote:
> On Sat, Jul 28, 2018 at 6:51 PM Ramsay Jones
> wrote:
>> Commit 6c213e863a ("http-backend: respect CONTENT_LENGTH for
>> receive-pack", 2018-07-27) adds a test which uses the non-portable
>> export construct. Replace it with "FOO=bar && export FOO"
I want us to join hands as partners because i have a deal for you
I want us to join hands as partners because i have a deal for you
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> As it exists right now, the commit-graph feature may provide
> inconsistent results when combined with commit grafts, replace objects,
> and shallow clones. Update the design document to discuss why these
> interactions are
"Derrick Stolee via GitGitGadget" writes:
Sidenote: the GitGitGadget doesn't fold/wrap lines properly in the
cover-letter. Not that it is much of a problem.
> One unresolved issue with the commit-graph feature is that it can
> cause issues when combined with replace objects, commit grafts, or
I've noticed for the past couple of weeks that some of my fetches don't
seem to actually update refs, but a follow-up fetch will. I finally
managed to catch it in the act and track it down. It bisects to your
989b8c4452 (fetch-pack: put shallow info in output parameter,
2018-06-27).
A
Am 28.07.2018 um 00:32 schrieb Junio C Hamano:
> Josh Steadmon writes:
>
>> # Supporting HTTP remotes in "git archive"
>>
>> We would like to allow remote archiving from HTTP servers. There are a
>> few possible implementations to be discussed:
>>
>> ## Shallow clone to temporary repo
>>
>> This
From: Duy Nguyen
In order to merge one or many trees with the index, unpack-trees code
walks multiple trees in parallel with the index and performs n-way
merge. If we find out at start of a directory that all trees are the
same (by comparing OID) and cache-tree happens to be available for
that
This series speeds up unpack_trees() a bit by using cache-tree.
unpack-trees could bit split in three big parts
- the actual tree unpacking and running n-way merging
- update worktree, which could be expensive depending on how much I/O
is involved
- repair cache-tree
This series focuses on the
This is a micro optimization that probably only shines on repos with
deep directory structure. Instead of allocating and freeing a new
cache_entry in every iteration, we reuse the last one and only update
the parts that are new each iteration.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
We're going to optimize unpack_trees() a bit in the following
patches. Let's add some tracing to measure how long it takes before
and after. This is the baseline ("git checkout -" on gcc.git, 80k
files on worktree)
0.018239226 s: read cache .git/index
0.052541655 s: preload index
With the new cache-tree, we could mostly avoid I/O (due to odb access)
the code mostly becomes a loop of "check this, check that, add the
entry to the index". We could skip a couple checks in this giant loop
to go faster:
- We know here that we're copying entries from the source index to the
On Sun, Jul 29, 2018 at 07:26:41AM +0200, Duy Nguyen wrote:
> > strcasecmp() will only catch a subset of the cases. We really need to
> > follow the same folding rules that the filesystem would.
>
> True. But that's how we handle case insensitivity internally. If a
> filesytem has more
On Fri, Jul 27, 2018 at 07:52:33PM +0200, Duy Nguyen wrote:
> Just FYI I'm still trying to reduce execution time further and this
> change happens to half traverse_trees() time (which is a huge deal)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index f0be9f298d..a2e63ad5bf 100644
> ---
42 matches
Mail list logo
