This eliminates an unnecessary prompt to continue after failed merger.
The patch uses positional parameters to count files in the list. If only
one iteration is remained, the prompt_after_failed_merge function is not
called.
Signed-off-by: Nicholas Guriev
---
git-mergetool.sh | 8 +---
1 fil
09.08.2018 18:44, Junio C Hamano пишет:
> Unlike "-u', "-i" is supported by "git commit" which shares the
> underlying implementation, and that is the historical reason why we
> never had "-i" shorthand, I think.
git-commit supports the -u flag, its meaning is the same as for
git-status. Althoug
On Mon, Aug 13, 2018 at 3:14 AM, Ramsay Jones
wrote:
> On 12/08/18 06:11, Christian Couder wrote:
>> Because the inefficiency primarily arises when an
>> object is delitified against another object that does
>
> s/delitified/deltified/ ?
Ok, this will be in the next reroll if any.
>> not exist
On 12/08/18 06:11, Christian Couder wrote:
> From: Jeff King
>
> Hosting providers that allow users to "fork" existing
> repos want those forks to share as much disk space as
> possible.
>
> Alternates are an existing solution to keep all the
> objects from all the forks into a unique central
Two tests added in dade47c06c (commit-graph: add repo arg to graph
readers, 2018-07-11) prepare the contents of 'expect' files by
'echo'ing the results of command substitutions. That's unncessary,
avoid them by directly saving the output of the commands executed in
those command substitutions.
Si
Hi Dscho,
On 08/10, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> [..]
>
> @@ -13,15 +14,38 @@ NULL
> int cmd_range_diff(int argc, const char **argv, const char *prefix)
> {
> int creation_factor = 60;
> + struct diff_options diffopt = { NULL };
>
The commit-graph files are binary files, so they should not be
compared with 'test_cmp', because that might cause issues on Windows,
where 'test_cmp' is a shell function to deal with random LF-CRLF
conversions.
Use 'test_cmp_bin' instead.
Signed-off-by: SZEDER Gábor
---
t/t5318-commit-graph.sh
On Sun, 12 Aug 2018 at 09:19, Nguyễn Thái Ngọc Duy wrote:
Hi,
> + trace_performance_leave("cache_tree_update");
I would suggest trace_performance_leave() calls use __func__ instead.
That way, there's no ambiguity if the function name ever changes.
Kindly,
Thomas
On Sat, Aug 11, 2018 at 4:25 PM Jeff King wrote:
> > I do still have these warnings and no amount of git gc/git fsck/etc.
> > has reduced them in any way:
> >
> > $ git gc
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: r
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what exactly is "dirty".
This patch helps the situation a bit by
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 webkit.git, 275k
files on worktree)
performance: 0.056651714 s: read cache .git/index
performance: 0.18310
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
---
unpack-trees
We do n-way merge by walking the source index and n trees at the same
time and add merge results to a new temporary index called o->result.
The merge result for any given path could be either
- keep_entry(): same old index entry in o->src_index is reused
- merged_entry(): either a new entry is add
Performance measurements are listed right now as a flat list, which is
fine when we measure big blocks. But when we start adding more and
more measurements, some of them could be just part of a bigger
measurement and a flat list gives a wrong impression that they are
executed at the same level inst
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 directory as well, we
v4 has a bunch of changes
- 1/5 is a new one to show indented tracing. This way it's less
misleading to read nested time measurements
- 3/5 now has the switch/restore cache_bottom logic. Junio suggested a
check instead in his final note, but I think this is safer (yeah I'm
scared too)
- the
16 matches
Mail list logo
