> putting it in the commit message is a way to
> experiment with the workflow without changing the object format
As long as we're talking about a temporary state of affairs for users
that have opted in, and we're explicit about the fact that future
versions of git won't understand the change
Tested-by: Carlo Marcelo Arenas Belón
the C version prepends: "fatal: " unlike the shell version for both
error messages
Carlo
On Tue, Nov 20, 2018 at 07:50:23PM +, Ævar Arnfjörð Bjarmason wrote:
> Add more progress output 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,
On Tue, Nov 20, 2018 at 12:57 PM Johannes Schindelin
wrote:
>
> Team,
>
> On Sun, 18 Nov 2018, Junio C Hamano wrote:
>
> > An early preview release Git v2.20.0-rc0 is now available for
> > testing at the usual places. It is comprised of 887 non-merge
> > commits since v2.19.0, contributed by 71
Stefan Xenos wrote:
> On Tue, Nov 20, 2018 at 1:43 AM Ævar Arnfjörð Bjarmason
> wrote:
>> I think it sounds better to just make it, in the header:
>>
>> x-evolve-pt content
>> x-evolve-pt obsolete
>> x-evolve-pt origin
>>
>> Where "pt = parent-type", we could of course spell that out
Hi,
Sven Strickroth wrote:
> Subject: .mailmap: record canonical email address for Sven Strickroth
>
> Signed-off-by: Sven Strickroth
> ---
> .mailmap | 2 ++
> 1 file changed, 2 insertions(+)
Thanks for taking care of it.
[...]
> --- a/.mailmap
> +++ b/.mailmap
> @@ -235,6 +235,8 @@ Steven
Team,
On Sun, 18 Nov 2018, Junio C Hamano wrote:
> An early preview release Git v2.20.0-rc0 is now available for
> testing at the usual places. It is comprised of 887 non-merge
> commits since v2.19.0, contributed by 71 people, 23 of which are
> new faces.
The "for Windows" flavor of Git
Hi Junio,
On Tue, 20 Nov 2018, Junio C Hamano wrote:
> Sven Strickroth writes:
>
> > This also removes an implicit conversion from size_t (unsigned) to int
> > (signed).
> >
> > _stricmp as well as _strnicmp are both available since VS2012.
Looks good to me.
> > Signed-off-by: Sven
Hi Stolee,
On Mon, 19 Nov 2018, Derrick Stolee wrote:
> On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
> > On Mon, Nov 19 2018, Derrick Stolee wrote:
> >
> > > [...]
> > > builtin/rebase.c
> > > 62c23938fa 55) return env;
> > > [...]
> > > Ævar Arnfjörð Bjarmason 62c23938f: tests: add a
> If a merge has been cherry-picked we cannot update it as we don't record
> which parent was used for the pick, however it is probably not a problem
> in practice - I think it is unusual to amend merges.
I've read and reread that sentence several times and don't fully
understand it. Could you
> This explains why we have 'origin' fields in the meta commits, it might
> be worth putting a forward reference or note earlier on to explain why
> recording the origin is useful. (I didn't find gerrit needs it very
> convincing on its own but it is actually more general than gerrit's
> specific
Hi Ævar,
On Tue, 20 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Mark a test added in 04519d7201 ("rebase: validate -C and
> --whitespace= parameters early", 2018-11-14) as only succeeding
> with the builtin version of rebase. It would be nice if the
> shellscript version had the same fix, but
On Tue, Nov 20, 2018 at 8:35 PM Carlo Arenas wrote:
> IMHO it would be ideal if test would be enabled/validated for windows
> (native, not only cygwin) as it might even work without the override
> and if we are to see conflicts, that is probably where most users with
> file insensitive
Tested-by: Carlo Marcelo Arenas Belón
in macOS 10.14.1 with APFS
in Linux using VFAT (for the lulz)
IMHO it would be ideal if test would be enabled/validated for windows
(native, not only cygwin) as it might even work without the override
and if we are to see conflicts, that is probably where
On Sun, May 20 2018, Nguyễn Thái Ngọc Duy wrote:
> The help command currently hard codes the list of guides and their
> summary in C. Let's move this list to command-list.txt. This lets us
> extract summary lines from Documentation/git*.txt. This also
> potentially lets us list guides in
On 20/11/2018 16:28, Nguyễn Thái Ngọc Duy wrote:
> 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. The
> "find duplicate file" check
On 11/20/2018 1:13 AM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
@@ -3143,6 +3144,9 @@ int prepare_revision_walk(struct rev_info *revs)
commit_list_sort_by_date(>commits);
if (revs->no_walk)
return 0;
+ if (revs->limited &&
+
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
>
> From: Phillip Wood
>
> When using --color-moved-ws=allow-indentation-change allow lines with
> the same indentation change to be grouped across blank lines. For now
> this only works if the blank lines have been moved as well, not for
>
This sounds like a proposal for general namespacing. I like it - that
would pave the way for other header extensions - but that should
probably be the subject of a separate proposal (who owns the content
of a namespace, what is the process for adding a new namespace or a
new attribute within a
> I was trying to see if this is something we can leave out to limit the
> initial scope.
Oh, in that case, "yes". :-) If there's a need to cut something,
origin parents would be a viable candidate.
I was thinking that this file could document the final goal so that if
anyone else wanted to
On Tue, Nov 20, 2018 at 03:04:39PM +, Ævar Arnfjörð Bjarmason wrote:
> Add more progress output 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,
On Tue, Nov 20, 2018 at 11:04 AM Jeff King wrote:
>
> Commit 108f530385 (pack-objects: move tree_depth into 'struct
> packing_data', 2018-08-16) dynamically manages a tree_depth array in
> packing_data that maintains one of these invariants:
>
> 1. tree_depth is NULL (i.e., the requested
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 performance improvement. But the
delta-island code only makes sense on a very
On 11/20/2018 1:11 AM, Jonathan Nieder wrote:
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance, but when a Git
On 11/20/2018 4:26 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Nov 20 2018, Jonathan Nieder wrote:
Just commenting here on the end-state of this since it's easier than
each patch at a time:
First, do we still need to be doing %.4s instead of just %s? It would be
easier for translators / to
On 11/20/2018 1:14 AM, Jonathan Nieder wrote:
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent of
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 update_index_if_able(struct index_state *istate,
> >struct lock_file *lockfile
>
On Tue, Nov 20, 2018 at 1:55 PM SZEDER Gábor wrote:
>
> On Tue, Nov 20, 2018 at 01:39:40PM +0100, Mathieu Malaterre wrote:
> > Here is a simple setup:
> >
> > cd /tmp
> > mkdir g
> > cd g
> > git init .
> > wget
> >
On 11/20/2018 1:12 AM, Jonathan Nieder wrote:
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly ignore the unrecognized section,
but in the process they loudly warn
On 11/20/2018 1:11 AM, Jonathan Nieder wrote:
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance, but when a Git
On 15/11/2018 00:55, sxe...@google.com wrote:
From: Stefan Xenos
+Obsolescence across cherry-picks
+
+By default the evolve command will treat cherry-picks and squash merges as
being
+completely separate from the original. Further amendments to the original
On 20/11/2018 12:18, Phillip Wood wrote:
On 15/11/2018 00:55, sxe...@google.com wrote:
From: Stefan Xenos
+Divergence
+--
+From the user’s perspective, two changes are divergent if they both
ask for
+different replacements to the same commit. More precisely, a target
commit is
On Tue, Nov 20, 2018 at 01:39:40PM +0100, Mathieu Malaterre wrote:
> Here is a simple setup:
>
> cd /tmp
> mkdir g
> cd g
> git init .
> wget
> http://central.maven.org/maven2/org/apache/xmlgraphics/fop/2.1/fop-2.1.pom
> git add fop-2.1.pom
> git commit -m "My First Commit"
> git
On Tue, Nov 20, 2018 at 4:36 AM Torsten Bögershausen wrote:
> Could you please post a "git diff" of your instrumented code,
> so that I/we can follow the debugging, especially what the printouts mean?
>
> I think we need to understand what is going on in abspath.c
>
diff --git a/abspath.c
On Tue, Nov 20, 2018 at 07:17:46AM -0500, Derrick Stolee wrote:
> > And I think that's a pattern with the delta-island code. What we really
> > care about most is that if we throw a real fork-network repository at
> > it, it produces faster clones with fewer un-reusable deltas. So I think
> > a
Hi Stefan
Thanks for working on this, I think it could be a really useful addition
to git. I'd echo Gábor's comments about making commands descriptive and
easy for the user to find, git has aliases, accepts abbreviated option
names and has shell completion so I don't think typing is really
Certainly we could add a tag to the repo in t5320, and this code would
get executed. But verifying that it's doing the right thing is much
harder (and is more easily done with a perf test).
Blind coverage goals are definitely not worth the effort. My goal here
was to re-check all of the
uot;, but
> only if "prove -o" is used (and even then, it's hard to associate it
> with a particular test when you're running many in parallel).
Just to be clear: I don't mind if in some combination of test
harnesses and test options a "bug in the test script" message doesn't
r
On Tue, Nov 20, 2018 at 12:25:38PM +0100, SZEDER Gábor wrote:
> > but we do not
> > usually bother to do so for our helper functions (like test_cmp).
>
> test_i18ngrep() does since your 03aa3783f2 (t: send verbose
> test-helper output to fd 4, 2018-02-22).
Oh, indeed. Usually I find myself
list[dst] = list[src];
> +
> + dst++;
> + }
> + island_count = dst;
> + }
>
> This means that our "deduplication" logic is never actually doing anything
> meaningful.
Sorry, I don't even remember what this code is trying to do. The island
code is 5+ years old, and just recently ported to upstream Git by
Christian. And that's perhaps part of my laziness in the above tests; it
would be a significant effort to re-figure out all these corner cases.
It's a big part of why I hadn't been sending the patches upstream
myself.
-Peff
On Mon, Nov 19, 2018 at 02:49:20PM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
>
> > The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> > checking the output of two 'git rev-parse' commands, which means that
> > its output on failure is
Hi Ævar,
On Mon, 19 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Nov 14 2018, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > It is a good idea to error out early upon seeing, say, `-Cbad`, rather
> > than starting the rebase only to have the `--am`
produced by the test script. But no, it eats both stdout
and stderr. You can sneak a line through by prepending it with "#", but
only if "prove -o" is used (and even then, it's hard to associate it
with a particular test when you're running many in parallel).
So I guess the status quo is not too bad: prove says "dubious", and then
you re-run the test with "./t1234-foo.sh -v -i" and you get to see the
error.
-Peff
On Tue, Nov 20, 2018 at 12:34:04AM +0100, SZEDER Gábor wrote:
> > I do notice that many of the existing "FATAL:" errors use descriptor 5,
> > which goes to stdout. I'm not sure if those should actually be going to
> > stderr (or if there's some TAP significance to those lines).
>
> I chose to
On 20.11.18 01:17, Steven Penny wrote:
> On Sun, Nov 18, 2018 at 11:21 PM Torsten Bögershausen wrote:
>> If nothing works,
>> it may help to add some fprintf(stderr,...) in the functions used
>> by 05b458c104708141d2f:
>>
>> strip_last_component(),
>> get_next_component()
>> real_path_internal()
>
On Tue, Nov 20 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Nov 15 2018, sxe...@google.com wrote:
>
>>> +Parent-type
>>> +---
>>> +The “parent-type” field in the commit header identifies a commit as a
>>> +meta-commit and indicates the meaning for each of its
On Tue, Nov 20 2018, Jonathan Nieder wrote:
Just commenting here on the end-state of this since it's easier than
each patch at a time:
First, do we still need to be doing %.4s instead of just %s? It would be
easier for translators / to understand what's going on if it were just
%s. I.e. "this
вт, 13 нояб. 2018 г. в 04:52, Junio C Hamano :
>
> Jeff King writes:
>
> >> You mean something like
> >>
> >> v->s = xstrfmt("%"PRIdMAX, (intmax_t)oi->disk_size);
> >
> > I think elsewhere we simply use PRIuMAX for printing large sizes via
> > off_t; we know this value isn't
On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> tests 3-8 seem to fail because perl is hardcoded to /urs/bin/perl in
> t5562/invoke-with-content-length.pl, while I seem to be getting some
> sporadic errors in 9 with the following output :
>
> ++ env
On Sun, Nov 18, 2018 at 6:45 AM Anders Waldenborg wrote:
> By default trailer lines are terminated by linebreaks ('\n'). By
> specifying the new 'separator' option they will instead be separated by
> user provided string and have separator semantics rather than terminator
> semantics. The
On Sun, Nov 18, 2018 at 6:45 AM Anders Waldenborg wrote:
> With the new "key=" option to %(trailers) it often makes little sense to
> show the key, as it by definition already is know which trailer is
s/know/known/
> printed there. This new "valueonly" option makes it omit the key when
>
"Derrick Stolee via GitGitGadget" writes:
> @@ -3143,6 +3144,9 @@ int prepare_revision_walk(struct rev_info *revs)
> commit_list_sort_by_date(>commits);
> if (revs->no_walk)
> return 0;
> + if (revs->limited &&
> + git_env_bool(GIT_TEST_COMMIT_GRAPH,
Anders Waldenborg writes:
> + followed by a colon and zero or more comma-separated options:
> + ** 'only': omit non-trailer lines from the trailer block.
> + ** 'unfold': make it behave as if interpret-trailer's `--unfold`
> + option was given.
> + ** 'key=': only show trailers with
Anders Waldenborg writes:
> + followed by a colon and zero or more comma-separated options:
> + ** 'only': omit non-trailer lines from the trailer block.
> + ** 'unfold': make it behave as if interpret-trailer's `--unfold`
> + option was given.
> + ** 'key=': only show trailers with
On Sun, Nov 11, 2018 at 03:17:50PM +0200, Orgad Shaneh wrote:
> Hi,
>
> I found 2 bugs in grep, using Git for Windows 2.19.1 (but noticed
> these several versions ago):
>
> 1. git grep --recursive on a worktree (without rev) always matches
> against the submodule's HEAD, not its worktree, as it
On Tue, Nov 20, 2018 at 06:04:54AM +0100, tbo...@web.de wrote:
> From: Torsten Bögershausen
>
> Currently the length of data which is stored in memory is stored
> in "unsigned long" at many places in the code base.
> This is OK when both "unsigned long" and size_t are 32 bits,
> (and is OK when
Ævar Arnfjörð Bjarmason writes:
> I don't have time to poke at this now, but wonder if:
>
> 1) The correction facility shouldn't at least have a list of "this does
> stuff over the wire" commands and would then use a more conservative
> estimate.
Not limited to 'over the wire' but 'can
Duy Nguyen writes:
>> > I see this at the same level as "Switched to branch 'foo'" which is
>> > also protected by opts->quiet. If we start hiding messages based on
>> > tty it should be done for other messages in update_refs_for_switch()
>> > too, I guess?
>
> No let's drop this for now. I
Duy Nguyen writes:
>
> - for (i = 0; i < state->istate->cache_nr; i++) {
> + for (i = 0; i < trust_ino && state->istate->cache_nr; i++) {
There is some typo here, but modulo that this looks like the right
thing to do.
> @@ -419,10 +419,24 @@ static void mark_colliding_entries(const
Sven Strickroth writes:
> This also removes an implicit conversion from size_t (unsigned) to int
> (signed).
>
> _stricmp as well as _strnicmp are both available since VS2012.
>
> Signed-off-by: Sven Strickroth
> ---
> compat/msvc.h | 8 +---
> 1 file changed, 1 insertion(+), 7
Torsten Bögershausen writes:
> The only problematic system is Win64, where "unsigned long" is 32 bit,
> and therefore we must use size_t to address data in memory.
> This is not to be confused with off_t, which is used for "data on disk"
> (and nothing else) or timestamp_t which is used for
Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 15 2018, sxe...@google.com wrote:
>> +Parent-type
>> +---
>> +The “parent-type” field in the commit header identifies a commit as a
>> +meta-commit and indicates the meaning for each of its parents. It is never
>> +present for normal commits.
Hi,
Stefan Xenos wrote:
> But since several comments have focused on the commands, let's brainstorm!
>
> Here's some options that occur to me:
>
> 1. Three commands: evolve + change + obslog as top-level commands (the
> current proposal). Change gets a bunch of subcommands for manipulating
> the
ok 99 - colliding file detection
as well in macOS with APFS
Carlo
Stefan Xenos writes:
>> But it is not immediately obvious to me how it would help to have
>> "Z was cherry-picked from W" in "evolve".
>
> The evolve command would use it for handling the
> obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
> a commit and then amends the
On Sun, Nov 18, 2018 at 11:21 PM Torsten Bögershausen wrote:
> If nothing works,
> it may help to add some fprintf(stderr,...) in the functions used
> by 05b458c104708141d2f:
>
> strip_last_component(),
> get_next_component()
> real_path_internal()
I didnt see any "real_path_internal" in the
On 19/11/2018 23:29, Ramsay Jones wrote:
>
>
> On 19/11/2018 21:03, Duy Nguyen wrote:
>> First of all, Ramsay, it would be great if you could test the below
>> patch and see if it works on Cygwin. I assume since Cygwin shares the
>> underlying filesystem, it will share the same "no trusting
On Mon, Nov 19, 2018 at 02:44:32PM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
>
> > Send these "bug in the test script" error messages directly to the
> > test scripts standard error and thus to the terminal, so those bugs
> > will be much harder to
On 19/11/2018 21:03, Duy Nguyen wrote:
> First of all, Ramsay, it would be great if you could test the below
> patch and see if it works on Cygwin. I assume since Cygwin shares the
> underlying filesystem, it will share the same "no trusting inode"
> issue with native builds (or it calculates
On Mon, Nov 19, 2018 at 08:23:00PM +, Ævar Arnfjörð Bjarmason wrote:
> Amend the progress output added in 7b0f229222 ("commit-graph write:
> add progress output", 2018-09-17) so that the total numbers it reports
> aren't higher than the total number of commits anymore. See [1] for a
> bug
On Mon, Nov 19, 2018 at 11:26:03PM +0200, Max Kirillov wrote:
> On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> > NO_CURL reflects the build setting (for http support); CURL checks for
> > the curl binary, but as Ævar points out the requirements must be from
> > somewhere else
On Mon, Nov 19 2018, Derrick Stolee wrote:
> On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>>
>>> [...]
>>> builtin/rebase.c
>>> 62c23938fa 55) return env;
>>> [...]
>>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>>> where
On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> NO_CURL reflects the build setting (for http support); CURL checks for
> the curl binary, but as Ævar points out the requirements must be from
> somewhere else since a NO_CURL=1 build (tested in macOS) still passes
> the test, but not
> Subcommand names and --long-options are just as descriptive.
Yeah, I'm convinced about the descriptiveness. If you check the latest
version of the patch, I've already updated the "change" command to use
subcommands rather than lettered arguments.
> If a user wants to deal with reflogs, then
On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
[...]
builtin/rebase.c
62c23938fa 55) return env;
[...]
Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
where rebase.useBuiltin is off
This one would be covered with
On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote:
> Thanks Carlo for the file and "stat" output. The problem is APFS has
> 64-bit inode (according to the Internet) while we store inodes as
> 32-bit, so it's truncated.
> ...
> We will have to deal with the same
> truncated inode elsewhere to make
On 11/19/2018 2:00 PM, Ben Peart wrote:
On 11/19/2018 10:40 AM, Derrick Stolee wrote:
There are a lot of lines introduced by the IEOT extension in these
commits:
> Ben Peart 3255089ad: ieot: add Index Entry Offset Table
(IEOT) extension
> Ben Peart 3b1d9e045: eoie: add End of
... and I "dear Ramsay" without CCing him.. sigh.. sorry for the noise.
On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote:
>
> First of all, Ramsay, it would be great if you could test the below
> patch and see if it works on Cygwin. I assume since Cygwin shares the
> underlying filesystem, it
First of all, Ramsay, it would be great if you could test the below
patch and see if it works on Cygwin. I assume since Cygwin shares the
underlying filesystem, it will share the same "no trusting inode"
issue with native builds (or it calculates inodes anyway using some
other source?).
Back to
On Mon, Nov 19 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>
>>> [...]
>>> builtin/rebase.c
>>> 62c23938fa 55) return env;
>>> [...]
>>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>>> where rebase.useBuiltin is
On 11/19/2018 3:23 PM, Ævar Arnfjörð Bjarmason wrote:
+ if (report_progress)
+ progress = start_delayed_progress(
+ _("Expanding reachable commits in commit graph"), j =
0);
This should be the only one that shows up in all but the very largest of
Hi,
Xenos wrote:
> Lets explore the "when" question. I think there's a compelling reason
> to add them as soon as possible - namely, gerrit. If and when we come
> to some sort of agreement on this proposal, gerrit could start adding
> tooling to understand change graphs as an alternative to
> But it is not immediately obvious to me how it would help to have "Z was
> cherry-picked from W" in "evolve".
The evolve command would use it for handling the
obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
a commit and then amends the original, the evolve command would
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> checking the output of two 'git rev-parse' commands, which means that
> its output on failure is not particularly informative, as it's
> basically two OIDs with a bit
On 11/19/2018 2:39 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
The coverage report has been using the following:
export GIT_TEST_MULTI_PACK_INDEX=1
export GIT_TEST_COMMIT_GRAPH=1
export GIT_TEST_INDEX_VERION=4
export GIT_TEST_SPLIT_INDEX=yes
export
get rid of descriptors 5 and 7 in favor of
3 and 4, if we did the conditional redirection when running each test,
instead of ahead of time.
But unless we are running out of descriptors, it's not worth the effort
(it's debatable whether we are; 9be795fbce (t5615: avoid re-using
descriptor 4, 2017-1
On Mon, Nov 19, 2018 at 9:23 AM Ramsay Jones
wrote:
> ok 99 # skip colliding file detection (missing !CYGWIN of
> !MINGW,!CYGWIN,CASE_INSENSITIVE_FS)
you need to enable this specific test first (removing !CYGWIN) so it
doesn't get skipped
Carlo
On Mon, Nov 19 2018, Derrick Stolee wrote:
> On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>>
>>> Here is a test coverage report for the uncovered lines introduced in
>>> v2.20.0-rc0 compared to v2.19.1.
>> Thanks a lot for this.
>>
>>>
On Mon, Nov 19, 2018 at 10:40 AM Max Kirillov wrote:
>
> On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote:
> > 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> > 2018-07-27)
> > introduced all tests but without a check for CURL support from git.
>
On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
Here is a test coverage report for the uncovered lines introduced in
v2.20.0-rc0 compared to v2.19.1.
Thanks a lot for this.
[...]
builtin/rebase.c
62c23938fa 55) return env;
[...]
Ævar Arnfjörð
On 11/19/2018 10:40 AM, Derrick Stolee wrote:
The test coverage reports started mid-way through this release cycle, so
I thought it would be good to do a full review of the new uncovered code
since the last release.
I eliminated most of the uncovered code due to the following cases:
1.
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 19 2018, Derrick Stolee wrote:
>> [...]
>> builtin/rebase.c
>> 62c23938fa 55) return env;
>> [...]
>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>> where rebase.useBuiltin is off
>
> This one would be covered with
>
On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote:
> 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> 2018-07-27)
> introduced all tests but without a check for CURL support from git.
The tests should not be using curl, they just pipe data to
On Mon, Nov 19, 2018 at 11:21:38AM -0500, Jeff King wrote:
> > + if (use_delta_islands) {
> > + const char *p;
> > + unsigned depth = 0;
> > + struct object_entry *ent;
> > +
> > + for (p = strchr(name, '/'); p; p = strchr(p + 1, '/'))
On Mon, Nov 19 2018, Derrick Stolee wrote:
> Here is a test coverage report for the uncovered lines introduced in
> v2.20.0-rc0 compared to v2.19.1.
Thanks a lot for this.
> [...]
> builtin/rebase.c
> 62c23938fa 55) return env;
> [...]
> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special
On Mon, Nov 19, 2018 at 6:14 PM Carlo Arenas wrote:
>
> On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote:
> >
> > Did you test it on Mac ?
>
> macOS 10.14.1 but only using APFS, did you test my patch with HFS+?
>
> > So what exactly are you trying to fix ?
>
> I get
>
> not ok 99 -
Am 19.11.2018 um 06:33 schrieb Torsten Bögershausen:
> The archive-tar.c is actually a good example, why a step-by-step update
> is not ideal (the code would not work any more on Win64).
>
> If we look here:
>
> static int stream_blocked(const struct object_id *oid)
> {
> struct
On Sun, Nov 18, 2018 at 03:18:52PM -0500, Derrick Stolee wrote:
> On 11/17/2018 10:11 AM, tbo...@web.de wrote:
> >From: Torsten Bögershausen
> >
> >Currently Git users can not commit files >4Gib under 64 bit Windows,
> >where "long" is 32 bit but size_t is 64 bit.
> >Improve the code base in
On 19/11/2018 12:28, Torsten Bögershausen wrote:
> On 2018-11-19 09:20, Carlo Marcelo Arenas Belón wrote:
>> While I don't have an HFS+ volume to test, I suspect this patch should be
>> needed for both, even if I have to say thay even the broken output was
>> better than the current state.
>>
On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote:
>
> Did you test it on Mac ?
macOS 10.14.1 but only using APFS, did you test my patch with HFS+?
> So what exactly are you trying to fix ?
I get
not ok 99 - colliding file detection
#
# grep X icasefs/warning &&
# grep x
701 - 800 of 100366 matches
Mail list logo
