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
> printin
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 separato
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 CONTENT_TYPE=application/x-git-
вт, 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 g
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 i
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
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 insertions(+),
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
P
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
rea
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
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
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
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 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 sen
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 (or
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 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 no
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(&to_pack, ent,
> > depth);
>
> This 'depth' variable is incremented as part of a for loop in this patch:
>
> static
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 forge
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 effec
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].
Thi
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 std
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:
https://public-inbox.org/git/20181120095053.gc22...@sigill.
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 suc
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 --har
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 mu
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 b/abspat
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 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
+consid
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
com
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 repositor
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 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
> > http://central.maven.org/maven2/org/apache/xmlgraphics/fop/2.1/fop-2.1.
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 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 turning
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 u
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 repositor
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 co
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: 6418
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 commit
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 (than
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 represe
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).
Signed-off-by:
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 si
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 spec
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 fs
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 options
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,
> 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 cont
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 name
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
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 +
1
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
> bloc
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(&revs->commits);
if (revs->no_walk)
return 0;
+ if (revs->limited
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 w
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 git.txt
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 mo
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 filesystems
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 S
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 si
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 represe
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 c
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 co
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).
Signed-off-by:
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
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: 6365
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 it's
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 ch
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
GIT_TEST_REBASE
> 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 u
> 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 ela
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 sp
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 Strickrot
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 v2.20.
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 G
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
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 p
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,
> 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 graph
Tested-by: Carlo Marcelo Arenas Belón
the C version prepends: "fatal: " unlike the shell version for both
error messages
Carlo
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 bla
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 m
Оля Тележная 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
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 extensions
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
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 misunders
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
f
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 cal
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 accordi
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 fut
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
*
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 106148254d..d879e
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, w
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
> t
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 bei
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 is
"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 t
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. oe_set_tree_dep
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 contribut
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 thos
1 - 100 of 103 matches
Mail list logo
