On 20.08.2018 22:22, Johannes Sixt wrote:
Am 20.08.2018 um 19:40 schrieb Phillip Wood:
On 20/08/2018 11:22, Konstantin Kharlamov wrote:
It's spectacular, that content of one of inserted conflict markers is
empty, so all you have to do is to remove the markers, and use `git add`
on the file,
Dear International Sales & Marketing Director,
Zhejiang Wuchuan Industrial Co., Ltd
(Please kindly forward this message to the person responsible for export.)
This is Eiichi Hasegawa from LIFESTYLE EXPO TOKYO Show Management.
LIFESTYLE EXPO TOKYO is Japan's leading trade show for gifts, homeware a
Hi Konstantin,
On 21/08/2018 11:37, Konstantin Kharlamov wrote:
>
> > There's another possibility (and I think it is what happens
> > actually in Konstantin's case): When one side added lines 1 2 and the
> > other side added 1 2 3, then the actual conflict is
> > << 1 2 == 1 2 3 >>, but our me
From: Derrick Stolee
Ensure that the commit-graph.txt and commit-graph-format.txt files
are compiled to HTML using ASCIIDOC.
Signed-off-by: Derrick Stolee
---
Documentation/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d079
Similar to [1], add the commit-graph and commit-graph-format technical docs
to Documentation/Makefile so they are automatically converted to HTML when
needed.
I compiled the docs and inspected the HTML manually in the browser. Nothing
looked strange, so I don't think the docs themselves need any e
Hi!
I have an alias for 'git status': 'git st'. I also have configured
that an unrecognised (mistyped) Git command runs the closest match. In
this case I did the following:
'''
$ git stt
git: 'stt' is not a git command. See 'git --help'.
The most similar commands are
st
status
'''
In this p
On 8/20/2018 5:23 PM, Stefan Beller wrote:
On Mon, Aug 20, 2018 at 9:52 AM Derrick Stolee wrote:
When an object fails to decompress from a pack-file, we mark the object
as 'bad' so we can retry with a different copy of the object (if such a
copy exists).
Before now, the multi-pack-index did no
On 8/20/2018 6:01 PM, Stefan Beller wrote:
On Mon, Aug 20, 2018 at 9:52 AM Derrick Stolee wrote:
There are many places in the codebase that want to iterate over
all packfiles known to Git. The purposes are wide-ranging, and
those that can take advantage of the multi-pack-index already
do. So, u
On Mon, Aug 20, 2018 at 6:53 PM Derrick Stolee wrote:
> To better understand the implications of the multi-pack-index with
> other scenarios, I ran the test suite after adding a step to 'git repack'
> to write a multi-pack-index, and to default core.multiPackIndex to 'true'.
> This commit is avail
On 8/21/2018 10:34 AM, Duy Nguyen wrote:
On Mon, Aug 20, 2018 at 6:53 PM Derrick Stolee wrote:
To better understand the implications of the multi-pack-index with
other scenarios, I ran the test suite after adding a step to 'git repack'
to write a multi-pack-index, and to default core.multiPackI
On Mon, Aug 20, 2018 at 9:30 PM Jonathan Nieder wrote:
>
> Hi,
>
> Nguyễn Thái Ngọc Duy wrote:
>
> > So many times I have carefully cherry picked changes to the index with
> > `git add -p` then accidentally did `git commit -am ` (usually by
> > retrieving a command from history and pressing En
On Mon, Aug 20, 2018 at 8:16 PM Elijah Newren wrote:
> Playing with sparse-checkout, it feels to me like a half-baked
> feature. It seems like it required too much manual work, and it was
> sometimes hard to tell if I was misunderstanding configuration rules
> or I was just running into bugs in t
On Tue, Aug 21, 2018 at 3:13 AM Jeff King wrote:
> I _think_ they should work together OK without further modification.
> Once upon a time the caller had to say "don't show if we're past N%
> after M seconds", but I think with the current code we'd just show it if
> we're not completely finished a
On Mon, Aug 20, 2018 at 8:38 PM Stefan Beller wrote:
>
> On Mon, Aug 20, 2018 at 6:18 AM Matthew DeVore wrote:
> >
> > There were many instances in this file where it seemed like BUG would be
> > better, so I created a new commit before this one to switch them over. The
> > interdiff is below.
>
Hi Stefan,
On Mon, 20 Aug 2018, Stefan Beller wrote:
> On Mon, Aug 20, 2018 at 12:31 PM Johannes Schindelin
> wrote:
> >
> > On Fri, 17 Aug 2018, Stefan Beller wrote:
> >
> > > This will prove useful in range-diff in a later patch as we will be able
> > > to differentiate between adding a new fi
Derrick Stolee writes:
> 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. Test this
> interaction succeeds, including ignoring an existing commit-graph and
>
Stefan Beller writes:
> On Mon, Aug 20, 2018 at 11:24 AM Derrick Stolee wrote:
>> Because of the change of base, it is hard to provide a side-by-side diff
>> from v1.
>
> I thought that was the whole point of range-diff. ;-)
I thought so, too. Was there any change that confused range-diff
mach
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Ensure that the commit-graph.txt and commit-graph-format.txt files
> are compiled to HTML using ASCIIDOC.
>
> Signed-off-by: Derrick Stolee
> ---
> Documentation/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --g
On 8/21/2018 1:51 PM, Junio C Hamano wrote:
Stefan Beller writes:
On Mon, Aug 20, 2018 at 11:24 AM Derrick Stolee wrote:
Because of the change of base, it is hard to provide a side-by-side diff
from v1.
I thought that was the whole point of range-diff. ;-)
I thought so, too. Was there any
On 8/21/2018 1:45 PM, Junio C Hamano wrote:
Derrick Stolee writes:
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. Test this
interaction succeeds, including
The test-tool programs include "test-tool.h" as their first
include, which breaks our CodingGuideline of "the first
include must be git-compat-util.h or an equivalent".
Rather than change them all, let's instead make test-tool.h
one of those equivalents, just like we do for builtin.h
(which many o
On 2018-08-08 18:10:22, Matthieu Moy wrote:
> "jrnieder" wrote:
>
>> (+cc: some folks interested in git-remote-mediawiki)
>
> Thanks.
>
> In case it still matters, an obvious Acked-by: Matthieu Moy
>
Hi,
I seem to have lost context of the original email, and can't find a copy
on public-inbox.o
Jeff King writes:
> The test-tool programs include "test-tool.h" as their first
> include, which breaks our CodingGuideline of "the first
> include must be git-compat-util.h or an equivalent".
>
> Rather than change them all, let's instead make test-tool.h
> one of those equivalents, just like we
About half of test_perf() is boilerplate preparing to run
_any_ test, and the other half is specifically running a
timing test. Let's split it into two functions, so that we
can reuse the boilerplate in future commits.
Signed-off-by: Jeff King
---
t/perf/perf-lib.sh | 61
On Fri, Aug 17, 2018 at 04:54:27PM -0400, Jeff King wrote:
> This series more aggressively reuses on-disk deltas to serve fetches
> when reachability bitmaps tell us a more complete picture of what the
> client has. That saves server CPU and results in smaller packs. See the
> final patch for numb
A server with bitmapped packs can serve a clone very
quickly. However, fetches are not necessarily made any
faster, because we spend a lot less time in object traversal
(which is what bitmaps help with) and more time finding
deltas (because we may have to throw out on-disk deltas if
the client does
The main objective of scripts in the perf framework is to
run "test_perf", which measures the time it takes to run
some operation. However, it can also be interesting to see
the change in the output size of certain operations.
This patch introduces test_size, which records a single
numeric output
This will let us reuse the code when we add new values to
aggregate besides times.
Signed-off-by: Jeff King
---
t/perf/aggregate.perl | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl
index bc865160e7..3181b08
When we do a bitmap walk, we save the result, which
represents (WANTs & ~HAVEs); i.e., every object we care
about visiting in our walk. However, we throw away the
haves bitmap, which can sometimes be useful, too. Save it
and provide an access function so code which has performed a
walk can query it
When we serve a fetch, we pass the "wants" and "haves" from
the fetch negotiation to pack-objects. That tells us not
only which objects we need to send, but we also use the
boundary commits as "preferred bases": their trees and blobs
are candidates for delta bases, both for reusing on-disk
deltas a
On Tue, Aug 21, 2018 at 03:06:22PM -0400, Jeff King wrote:
> On Fri, Aug 17, 2018 at 04:54:27PM -0400, Jeff King wrote:
>
> > This series more aggressively reuses on-disk deltas to serve fetches
> > when reachability bitmaps tell us a more complete picture of what the
> > client has. That saves s
On Tue, Aug 21, 2018 at 2:55 PM Antoine Beaupré wrote:
> On 2018-08-08 18:10:22, Matthieu Moy wrote:
> > "jrnieder" wrote:
> >> (+cc: some folks interested in git-remote-mediawiki)
> >
> > In case it still matters, an obvious Acked-by: Matthieu Moy
> >
>
> I seem to have lost context of the ori
We already advise people to make sure their documentation
formats correctly. Let's point them at the doc-diff script,
which can help with that.
Let's also put a brief note in the script about its purpose,
since that otherwise can only be found in the original
commit message. Along with the existin
Similar to [1], add the commit-graph and commit-graph-format technical docs
to Documentation/Makefile so they are automatically converted to HTML when
needed.
I compiled the docs and inspected the HTML manually in the browser. As
suggested, I modified the documents to format a bit better. See the
On 2018-08-21 15:22:43, Eric Sunshine wrote:
> On Tue, Aug 21, 2018 at 2:55 PM Antoine Beaupré wrote:
>> On 2018-08-08 18:10:22, Matthieu Moy wrote:
>> > "jrnieder" wrote:
>> >> (+cc: some folks interested in git-remote-mediawiki)
>> >
>> > In case it still matters, an obvious Acked-by: Matthieu
From: Derrick Stolee
Ensure that the commit-graph.txt and commit-graph-format.txt files
are compiled to HTML using ASCIIDOC.
Signed-off-by: Derrick Stolee
---
Documentation/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d079
From: Derrick Stolee
When viewing commit-graph.txt as a plain-text document, it makes
sense to keep paragraphs left-padded between bullet points.
However, asciidoc converts these left-padded paragraphs as monospace
fonts, creating an unpleasant document. Remove the padding.
The "Future Work" sec
Jeff King writes:
> On Fri, Aug 17, 2018 at 04:54:27PM -0400, Jeff King wrote:
>
>> This series more aggressively reuses on-disk deltas to serve fetches
>> when reachability bitmaps tell us a more complete picture of what the
>> client has. That saves server CPU and results in smaller packs. See
On Tue, Aug 21, 2018 at 3:29 PM Derrick Stolee via GitGitGadget
wrote:
> When viewing commit-graph.txt as a plain-text document, it makes
> sense to keep paragraphs left-padded between bullet points.
> However, asciidoc converts these left-padded paragraphs as monospace
> fonts, creating an unplea
On Tue, Aug 21, 2018 at 03:23:21PM -0400, Jeff King wrote:
> We already advise people to make sure their documentation
> formats correctly. Let's point them at the doc-diff script,
> which can help with that.
>
> Let's also put a brief note in the script about its purpose,
> since that otherwise
On 8/21/2018 3:23 PM, Jeff King wrote:
We already advise people to make sure their documentation
formats correctly. Let's point them at the doc-diff script,
which can help with that.
Let's also put a brief note in the script about its purpose,
since that otherwise can only be found in the origin
Jeff King writes:
> When we serve a fetch, we pass the "wants" and "haves" from
> ...
> This lets us limit the change primarily to the oe_delta()
> and oe_set_delta_ext() functions. And as a bonus, most of
> the rest of the code does not consider these dummy entries
> at all, saving both runtime
On 8/21/2018 3:07 PM, Jeff King wrote:
When we do a bitmap walk, we save the result, which
represents (WANTs & ~HAVEs); i.e., every object we care
about visiting in our walk. However, we throw away the
haves bitmap, which can sometimes be useful, too. Save it
and provide an access function so cod
On Tue, Aug 21, 2018 at 12:34:18PM -0700, Junio C Hamano wrote:
> > 1: 89fa0ec8d8 ! 1: 3e1b94d7d6 pack-bitmap: save "have" bitmap from walk
> > @@ -69,6 +69,8 @@
> > +
> > + if (!bitmap_git)
> > + return 0; /* no bitmap loaded */
> > ++ if (!bitmap_g
On Tue, Aug 21, 2018 at 03:47:36PM -0400, Derrick Stolee wrote:
> On 8/21/2018 3:07 PM, Jeff King wrote:
> > When we do a bitmap walk, we save the result, which
> > represents (WANTs & ~HAVEs); i.e., every object we care
> > about visiting in our walk. However, we throw away the
> > haves bitmap,
Junio C Hamano writes:
> Jeff King writes:
>
>> When we serve a fetch, we pass the "wants" and "haves" from
>> ...
>> This lets us limit the change primarily to the oe_delta()
>> and oe_set_delta_ext() functions. And as a bonus, most of
>> the rest of the code does not consider these dummy entri
On Tue, Aug 21, 2018 at 12:43:49PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > When we serve a fetch, we pass the "wants" and "haves" from
> > ...
> > This lets us limit the change primarily to the oe_delta()
> > and oe_set_delta_ext() functions. And as a bonus, most of
> > the rest o
On Tue, Aug 21, 2018 at 12:50:09PM -0700, Junio C Hamano wrote:
> > Sorry for commenting on something completely off-topic, but when
> > applied with "git am -s", I get a resulting commit with 3 S-o-b (the
> > above two, plus the one added by "-s"), with a blank line in between
> > them. I can un
On Tue, Aug 21, 2018 at 04:07:47PM -0400, Jeff King wrote:
> On Tue, Aug 21, 2018 at 12:50:09PM -0700, Junio C Hamano wrote:
>
> > > Sorry for commenting on something completely off-topic, but when
> > > applied with "git am -s", I get a resulting commit with 3 S-o-b (the
> > > above two, plus th
On Tue, Aug 21, 2018 at 3:36 PM Jeff King wrote:
> The script does basically this to set up the temporary tree:
>
> test -d $tmp || git worktree add $tmp ...
>
> The script never cleans up the worktree (since its results can often be
> reused between runs), but you may do so with "rm" or "git cl
On 8/20/2018 6:13 PM, Junio C Hamano wrote:
An early preview release Git v2.19.0-rc0 is now available for
testing at the usual places.
As part of testing the release candidate, I ran the performance suite
against a fresh clone of the Linux repository using v2.18.0 and
v2.19.0-rc0 (also: GIT_P
On Tue, Aug 21, 2018 at 04:22:08PM -0400, Eric Sunshine wrote:
> On Tue, Aug 21, 2018 at 3:36 PM Jeff King wrote:
> > The script does basically this to set up the temporary tree:
> >
> > test -d $tmp || git worktree add $tmp ...
> >
> > The script never cleans up the worktree (since its results
Jeff King writes:
> Another is to tighten the check. Something like this seems more
> sensible:
Great minds think alike; is it a space was exactly what I was toying
with before I went to lunch. FWIW I saw the full test suite passes
when I came back and then saw you had an identical patch ;-)
>
The author_date_slab is used to store the author date of a commit
when walking with the --author-date flag in rev-list or log. This
was added as an 'unsigned long' in
81c6b38b "log: --author-date-order"
Since 'unsigned long' is ambiguous in its bit-ness across platforms
(64-bit in Linux,
Jeff King writes:
> Ah, yeah, I think you're right. We call find_patch_start(), which thinks
> the "---" line is the end of the commit message. That makes sense when
> parsing trailers out of "format-patch" output, but not when we know we
> have just the commit message.
Yes, but that does not ex
Derrick Stolee writes:
> The author_date_slab is used to store the author date of a commit
> when walking with the --author-date flag in rev-list or log. This
> was added as an 'unsigned long' in
>
> 81c6b38b "log: --author-date-order"
>
> Since 'unsigned long' is ambiguous in its bit-ness
On Tue, Aug 21, 2018 at 04:41:02PM -0400, Derrick Stolee wrote:
> On 8/20/2018 6:13 PM, Junio C Hamano wrote:
> > An early preview release Git v2.19.0-rc0 is now available for
> > testing at the usual places.
>
> As part of testing the release candidate, I ran the performance suite
> against a fr
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> When viewing commit-graph.txt as a plain-text document, it makes
> sense to keep paragraphs left-padded between bullet points.
> However, asciidoc converts these left-padded paragraphs as monospace
> fonts, creating an unpleasa
On Tue, Aug 21, 2018 at 01:52:33PM -0700, Junio C Hamano wrote:
> > I think there really are two bugs here, though. The find_patch_start()
> > check is overly lax, but we also should not have to use it at all when
> > we know there is no patch.
>
> Yes, I was grepping for callchains, and it appea
On Tue, Aug 21, 2018 at 01:57:07PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Ah, yeah, I think you're right. We call find_patch_start(), which thinks
> > the "---" line is the end of the commit message. That makes sense when
> > parsing trailers out of "format-patch" output, but not
Stefan Beller writes:
>> So I think this patch is insufficient, and needs to at least change
>> the "submodule.active" codepath to return !!ret; otherwise, a caller
>> that now expects 0 (not active), 1 (active but can lose URL) and 2
>> (active and the presence of URL makes it so) will be confus
Stefan Beller writes:
>> ...
>> OTOH, if it were up to me I would have just gotten rid of
>> test_must_be_empty and used an existing function with the right
>> argument, like `test_cmp /dev/null` - but using some form consistently
>> is the most important, whatever it is.
>
> /dev/null, eh? It sh
Jeff King writes:
>> > If we assume that "expect" is first (which is our convention but not
>> > necessarily guaranteed), then I think the best logic is something like:
>> >
>> > if $1 is empty; then
>> > bug in the test script
>> > elif test_cmp_allow_empty "$@"
>> > test failure
>>
Hey amc2399!
An email address (aam...@icloud.com) was added to your account. Visit
https://github.com/settings/emails to review email addresses currently
associated with your account.
To see this and other security events for your account, visit
https://github.com/settings/security
If you run
The test '--dry-run with conflicts fixed from a merge' in
't7501-commit.sh', added in 8dc874b2ee (wt-status.c: set commitable
bit if there is a meaningful merge., 2016-02-15), runs the following
unnecessary and downright bogus command substitution:
! $(git merge --no-commit commit-1) &&
I.e. af
On Tue, Aug 21, 2018 at 05:29:24PM -0400, Jeff King wrote:
> 0001.2: rev-list --all --objects 37.07(36.62+0.45) 39.11(38.58+0.51) +5.5%
>
> Less change, but my overall times were smaller, too, so clearly our
> hardware or exact repos are a little bit different. Those numbers seem
> pretty consi
On 8/21/2018 5:29 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
From: Derrick Stolee
When viewing commit-graph.txt as a plain-text document, it makes
sense to keep paragraphs left-padded between bullet points.
However, asciidoc converts these left-padded paragraphs as m
On Wed, Aug 22, 2018 at 12:48:16AM +, brian m. carlson wrote:
> > diff --git a/cache.h b/cache.h
> > index b1fd3d58ab..9c004a26c9 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -1023,7 +1023,10 @@ extern const struct object_id null_oid;
> >
> > static inline int hashcmp(const unsigned ch
On Tue, Aug 21, 2018 at 11:03:44PM -0400, Jeff King wrote:
> with the obvious "oideq()" implementation added, that seems to get me to
> 2-3%. Not _quite_ as good as the original branching version I showed.
> And we had to touch all the callsites (although arguably that kind of
> "eq" function is a
Good day,
My name is Richard Jeffery I have a client, who died as a result of
heart-related condition on the 10th of December, 2015. I have contacted
you to assist in distributing the estate left behind by my client, who
shares the same last name as yours. Would discuss more when I hear from
y
On Tue, Aug 21, 2018 at 11:03:44PM -0400, Jeff King wrote:
> So I wonder if there's some other way to tell the compiler that we'll
> only have a few values. An enum comes to mind, though I don't think the
> enum rules are strict enough to make this guarantee (after all, it's OK
> to bitwise-OR enum
On Tuesday, February 16, 2016 8:33:54 PM MST Junio C Hamano wrote:
> In fact, "commit --dry-run" is already broken without this "a merge
> ends up in a no-op" corner case. The management of s->commitable
> flag and dry_run_commit() that uses it are unfortunately more broken
> than I originally tho
https://drive.google.com/open?id=0B_6x2GR6_FTMc2RERHlJZVpQc0RIMFMxNi13bE95UU1fZmp3
On Tue, Aug 21, 2018 at 10:54 PM Gaux Nation wrote:
>
> Hey there,
>
> The name is Sachin Sharma(19 yrs old, student, India) and passionate
> for innovative technology and digital content.
>
>
>
> Why Open Source?
>
On Wed, Aug 22, 2018 at 05:36:26AM +, brian m. carlson wrote:
> On Tue, Aug 21, 2018 at 11:03:44PM -0400, Jeff King wrote:
> > So I wonder if there's some other way to tell the compiler that we'll
> > only have a few values. An enum comes to mind, though I don't think the
> > enum rules are st
74 matches
Mail list logo
