Junio C Hamano writes:
> I do not know if it makes sense to have 3 and 5 separate; I suspect
> a single patch that does "clarify the warning, and allow those who
> have no choice in which version of Git to choose squelch it" would
> suffice.
I actually do not mind two patches for these, but I
Junio C Hamano writes:
> As the deployed versions of Git will keep sending the wrong message,
> I do not mind applying 1/5 and 2/5, given especially that Ben seems
> to be OK with the plan. I however do not think 3 thru 5 is ready
> yet with this round---there were some discussions on phrasing
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I don't *think* you intend to say "sure, you got user reports, but
>> (those users are wrong | those users are not real | you are not
>> interpreting those users correctly)", but that is what I am hearing.
>
> What I have been saying is "we are
Jonathan Nieder writes:
> I don't *think* you intend to say "sure, you got user reports, but
> (those users are wrong | those users are not real | you are not
> interpreting those users correctly)", but that is what I am hearing.
What I have been saying is "we are sending a wrong message to
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Now, a meta point. Throughout this discussion, I have been hoping for
>> some acknowledgement of the problem --- e.g. an "I am sympathetic to
>> what you are trying to do, but ". I wasn't able to find that, and
>> that is part of what
Jeff King writes:
> But in (b), we use the number of stored objects, _not_ the allocated
> size of the objects array. So we can run into a situation like this:
>
> 1. packlist_alloc() needs to store the Nth object, so it grows the
> objects array to M, where M > N.
>
> 2.
"Johannes Schindelin via GitGitGadget"
writes:
> A quick fix for a recent topic. Not overly critical, but I would deem this
> v2.20.0-rc1 material.
>
> Johannes Schindelin (1):
> rebase: warn about the correct tree's OID
>
Yup, it is kind of embarrasing that nobody caught it, but at the
same
Carlo Arenas writes:
> Tested-by: Carlo Marcelo Arenas Belón
>
> the C version prepends: "fatal: " unlike the shell version for both
> error messages
In addition, "Invalid whitespace option" says 'bad', not
'--whitespace=bad', in the builtin version.
I think the following would address both
Jonathan Nieder writes:
> Now, a meta point. Throughout this discussion, I have been hoping for
> some acknowledgement of the problem --- e.g. an "I am sympathetic to
> what you are trying to do, but ". I wasn't able to find that, and
> that is part of what contributed to the feeling of not
SZEDER Gábor writes:
> I rename these variables to 'num_large_edges', because the commit
> graph file format speaks about the 'Large Edge List' chunk.
>
> However, I do find that the term 'extra' makes much more sense and
> fits the concept better (i.e. extra commit graph edges resulting from
>
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
merge.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
Finally,
This cleans up the original test by removing some unnecessary braces and
removing a pipe.
Helped-by: SZEDER Gábor
Signed-off-by: Denton Liu
---
t/t7600-merge.sh | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index
Thanks for catching that, Szeder. I tested this revised patch under
GETTEXT_POISON and it should be passing tests now.
Changes since V1:
* Only check MERGE_MSG for a scissors line instead of all prepended
files
* Make a variable static in merge where appropriate
Stefan Xenos wrote:
> Jonathan Nieder wrote:
>> 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
The optional 'Large Edge List' chunk of the commit graph file stores
parent information for commits with more than two parents. Since the
chunk is optional, write_commit_graph() looks through all commits to
find those with more than two parents, and then writes the commit
graph file header
The commit graph file format describes an optional 'Large Edge List'
chunk, and the function writing out this chunk is called
write_graph_chunk_large_edges(). Then there are two functions in
'commit-graph.c', namely write_graph_chunk_data() and
write_commit_graph(), which have a local variable
On Tue, Nov 20, 2018 at 05:58:00PM +0100, SZEDER Gábor wrote:
> I saw a
> bit of weirdness while at it, and want to look into it, but now I've
> got to go...
So here are two simple patches that address the "Huh?!" moments I had
while looking at the progress output during writing the commit graph
Junio C Hamano wrote:
> This series has a strong smell of pushing back by the
> toolsmiths who refuse to promptly upgrade to help their users, and
> that is why I do not feel entirely happy with this series.
Last reply, I promise. :)
This sentence might have the key to the
onathan Nieder wrote:
> Junio C Hamano wrote:
>> I am still puzzled by the insistence of 3/5 and this step that wants
>> to kill the coalmine canary. But I am even more puzzled by the
>> first two steps that want to disable the two optional extensions.
[...]
> I acknowledge your puzzlement. I'm
Hi,
Junio C Hamano wrote:
> I am still puzzled by the insistence of 3/5 and this step that wants
> to kill the coalmine canary. But I am even more puzzled by the
> first two steps that want to disable the two optional extensions.
>
> What's so different this time with the new optional
Оля Тележная writes:
>> I am OK if we avoid PRIdMAX and use PRIuMAX instead with a cast to
>> the corresponding size in this codepath, as long as we properly
>> handle negative oi.disk_size field, which may be telling some
>> "unusual" condition to us.
>
> Maybe we want to change the type (from
Ben Peart writes:
>> This message should say something like "Index uses the mandatory %s
>> extension" to clarify and distinguish it from the below. We don't
>> understand the upper-case one either, but the important distinction is
>> that one is mandatory, and the other can be dropped. The two
Jonathan Nieder writes:
>> +Sven Strickroth
>
> Is the above line needed? It's not clear to me from the commit message
> what it does.
Stare at it once again and you'll see ;-) FWIW I needed to do that
myself before you had the same issue.
Sven is trying to hide real-name name and have a
> 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
This is a backport, really, to accommodate a new regression test that was
introduced when the built-in rebase learned to validate the -C and
--whitespace= arguments early.
Johannes Schindelin (1):
legacy-rebase: backport -C and --whitespace= checks
git-legacy-rebase.sh | 8
1 file
From: Johannes Schindelin
Since 04519d720114 (rebase: validate -C and --whitespace=
parameters early, 2018-11-14), the built-in rebase validates the -C and
--whitespace arguments early. As this commit also introduced a
regression test for this, and as a later commit introduced the
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
Add more progress output to sections of code that can collectively
take 5-10 seconds on a large enough repository. On a test repository
with I have with ~7 million commits and ~50 million objects we'll now
emit:
$ ~/g/git/git --exec-path=$HOME/g/git commit-graph write
Finding commits for
Make the progress output shown when we're searching for commits to
include in the graph more descriptive. This amends code I added in
7b0f229222 ("commit-graph write: add progress output", 2018-09-17).
Now, on linux.git, we'll emit this sort of output in the various modes
we support:
$ git
Show the percentage progress for the "Finding commits for commit
graph" phase for the common case where we're operating on all packs in
the repository, as "commit-graph write" or "gc" will do.
Before we'd emit on e.g. linux.git with "commit-graph write":
Finding commits for commit graph:
Remove the empty line between a QSORT(...) and the subsequent oideq()
for-loop. This makes it clearer that the QSORT(...) is being done so
that we can run the oideq() loop on adjacent OIDs. Amends code added
in 08fd81c9b6 ("commit-graph: implement write_commit_graph()",
2018-04-02).
Fixes issues SZEDER raised with v1, except displaying an accurate ETA
in write_graph_*(). As noted in 2/6 I don't think it's worth it, I
just adjusted the message instead.
Ævar Arnfjörð Bjarmason (6):
commit-graph write: rephrase confusing progress output
commit-graph write: add more progress
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, but before this change we'd noticeably hang for
2-3 seconds at the end on medium
Rephrase the title shown for the progress output emitted by
close_reachable(). The message I added in 7b0f229222 ("commit-graph
write: add progress output", 2018-09-17) gave the impression that it
would count up to the number of commit objects.
But that's not what the number means. It just
Signed-off-by: Sven Strickroth
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap b/.mailmap
index f165222a78..a30f409f39 100644
--- a/.mailmap
+++ b/.mailmap
@@ -235,6 +235,8 @@ Steven Grimm
Steven Grimm kor...@midwinter.com
Steven Walter
Steven Walter
+Sven
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
>
The git-multi-pack-index doc links to technical/multi-pack-index.html.
Ensure it is built to prevent a broken link.
Signed-off-by: Todd Zullinger
---
While building 2.20.0-rc0 I noticed the broken link from
git-multi-pack-index to technical/multi-pack-index.html.
Documentation/Makefile | 1 +
On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote:
> I promise to come back with something better (at least it still
> sounds better in my mind). If that idea does not work out, we can
> come back and see if we can improve this.
So this is it. The patch isn't pretty, mostly as a proof of
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
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 was doing by comparing inode number (and
only fall back to
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
Remove the empty line between a QSORT(...) and the subsequent oideq()
for-loop. This makes it clearer that the QSORT(...) is being done so
that we can run the oideq() loop on adjacent OIDs. Amends code added
in 08fd81c9b6 ("commit-graph: implement write_commit_graph()",
2018-04-02).
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, but before this change we'd noticeably hang for
2-3 seconds at the end on medium
Rephrase the title shown for the progress output emitted by
close_reachable(). The message I added in 7b0f229222 ("commit-graph
write: add progress output", 2018-09-17) gave the impression that it
would count up to the number of commit objects.
But that's not what the number means. It just
This replaces my "commit-graph: split up close_reachable() progress
output". We could still do something like that, but I think this makes
more sense, and also plugs some missing holes in the progress
output. See 6/6 for what the end-state is.
I believe this addresses SZEDER Gábor's concerns
Show the percentage progress for the "Finding commits for commit
graph" phase for the common case where we're operating on all packs in
the repository, as "commit-graph write" or "gc" will do.
Before we'd emit on e.g. linux.git with "commit-graph write":
Finding commits for commit graph:
Add more progress output to sections of code that can collectively
take 5-10 seconds on a large enough repository. On a test repository
with 7141512 commits (see earlier patches for details) we'll now emit:
$ ~/g/git/git --exec-path=$HOME/g/git commit-graph write
Finding commits for
Make the progress output shown when we're searching for commits to
include in the graph more descriptive. This amends code I added in
7b0f229222 ("commit-graph write: add progress output", 2018-09-17).
Now, on linux.git, we'll emit this sort of output in the various modes
we support:
$ git
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
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 rm fop-2.1.pom
git commit -m "Second Commit"
git format-patch HEAD~
git reset
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
On 11/20/2018 6:34 AM, Jeff King wrote:
On Mon, Nov 19, 2018 at 10:40:53AM -0500, Derrick Stolee wrote:
Since depth is never incremented, we are not covering this block. Is it
possible to test?
This should be covered by the fix in:
On Tue, Nov 20, 2018 at 05:58:25AM -0500, Jeff King wrote:
> On Tue, Nov 20, 2018 at 05:45:28AM -0500, Jeff King wrote:
>
> > 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
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 it's on its way out, and the
author is not interested in fixing it[1].
Dear developers,
I am a daily use of gitk; I use the "color words" diff option most often.
I have found no way to set --word-diff-regex for gitk, or to make the command
git config --global diff.wordRegex '.'
have effect on the diffs shown in gitk.
I think the value of --word-diff-regex is
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
On Mon, Nov 19, 2018 at 10:40:53AM -0500, Derrick Stolee wrote:
> > 28b8a73080 builtin/pack-objects.c 2793) depth++;
> > 108f530385 builtin/pack-objects.c 2797) oe_set_tree_depth(_pack, ent,
> > depth);
>
> This 'depth' variable is incremented as part of a for loop in this patch:
>
> static
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`
On Tue, Nov 20, 2018 at 05:45:28AM -0500, Jeff King wrote:
> 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
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()
>
When delta-islands are in use, we need to record the deepest path at
which we find each tree and blob. Our loop to do so counts slashes, so
"foo" is depth 0, "foo/bar" is depth 1, and so on.
However, this neglects root trees, which are represented by the empty
string. Those also have depth 0, but
Commit 108f530385 (pack-objects: move tree_depth into 'struct
packing_data', 2018-08-16) started maintaining a tree_depth array that
matches the "objects" array. We extend the array when:
1. The objects array is extended, in which case we use realloc to
extend the tree_depth array.
2. A
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 options don't require us to
track tree depths)
2. tree_depth
This fixes a few bugs in the cc/delta-islands topic: one major, and two
minor.
Sadly, the major one was not caught by our test suite, and I'm not sure
how to remedy that. The problem is a memory management one, and happens
only when you have a reasonably large number of objects. So it triggers
From: Johannes Schindelin
This was a simple copy/paste error, and an obvious one at that: if we
cannot fill the tree descriptor, we should show an error message about
*that* tree, not another one.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 3 ++-
1 file changed, 2
A quick fix for a recent topic. Not overly critical, but I would deem this
v2.20.0-rc1 material.
Johannes Schindelin (1):
rebase: warn about the correct tree's OID
builtin/rebase.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
base-commit: bb75be6cb916297f271c846f2f9caa3daaaec718
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
1 - 100 of 103 matches
Mail list logo
