From: Junio C Hamano <gitster@pobox.com>
To: Antonio Russo <aerusso@aerusso.net>
Cc: Derrick Stolee <stolee@gmail.com>,
Aiyee Bee <shane.880088.supw@gmail.com>,
git@vger.kernel.org
Subject: Re: DEVEL: Help with feature implementation
Date: Mon, 18 Jan 2021 17:24:52 -0800 [thread overview]
Message-ID: <xmqq7do9iuqj.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <992cd021-d6f6-dfe4-1918-45643aa85a61@aerusso.net> (Antonio Russo's message of "Mon, 18 Jan 2021 17:54:06 -0700")
Antonio Russo <aerusso@aerusso.net> writes:
> As a side note, would this list be willing to look at patches that remove
> the need to use revs->limited? Adding new features would be much easier if
> we could restrict git to use streaming algorithms for these simplifications.
Do you mean you will write new implementations of operations like
"--simplify-merges", "--ancestory-path" and all its friends without
the need for the "limited" bit?
Willing to look at? I do not know about others, but sure, it would
make be extremely excited.
You may be able to rewrite some other operations that implicitly
require the limited bit into an incremental implementation, but I am
skeptical that you can do "simplify-merges" in a streaming fashion
in such a way that we'd dig a bit but not all the way down before
making decisions on which commits should be included in the output
and how their parenthood relationship should appear etc. I and
Linus tried independently and we did not get that far in our
attempts (note: there wasn't commit-graph back then).
If you are talking about precomputed stuff like commit-graph, that
may change the equation, but we'd prefer to have the system work
without requiring these auxiliary data (in other words, it would be
fine to use them as optimization).
next prev parent reply other threads:[~2021-01-19 1:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 18:06 DEVEL: Help with feature implementation Aiyee Bee
2021-01-18 18:19 ` Antonio Russo
2021-01-18 18:26 ` Derrick Stolee
2021-01-18 19:15 ` Aiyee Bee
2021-01-18 22:54 ` Junio C Hamano
2021-01-18 19:25 ` Aiyee Bee
2021-01-18 19:31 ` Aiyee Bee
2021-01-18 20:58 ` Derrick Stolee
2021-01-19 0:54 ` Antonio Russo
2021-01-19 1:24 ` Junio C Hamano [this message]
2021-01-19 14:52 ` Antonio Russo
2021-01-20 2:21 ` Derrick Stolee
2021-01-19 2:39 ` Derrick Stolee
2021-01-19 5:35 ` Aiyee Bee
2021-01-19 5:38 ` Aiyee Bee
2021-01-19 15:13 ` Antonio Russo
-- strict thread matches above, loose matches on Subject: below --
2021-01-19 5:20 Aiyee Bee
2021-01-19 4:58 Aiyee Bee
2021-01-18 18:00 FriendlyNeighborhoodShane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7do9iuqj.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=aerusso@aerusso.net \
--cc=git@vger.kernel.org \
--cc=shane.880088.supw@gmail.com \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).