Let's start with some background about oe_delta_size() and
oe_set_delta_size(). If you already know, skip the next paragraph.
These two are added in 0aca34e826 (pack-objects: shrink delta_size
field in struct object_entry - 2018-04-14) to help reduce 'struct
object_entry' size. The delta size fiel
On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index a32172a43c..f682e92a1a 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2542,6 +2542,10 @@ Note that changing the compression level will
On Sun, Jul 22, 2018 at 7:52 AM Christian Couder
wrote:
> @@ -700,51 +705,58 @@ static struct object_entry **compute_write_order(void)
> */
> for_each_tag_ref(mark_tagged, NULL);
>
> - /*
> -* Give the objects in the original recency order until
> -* we see a
From: "Frank Wolf"
Sent: Wednesday, July 18, 2018 7:38 AM
Hi @ll,
I hope I'm posting to the right group (not sure if it's Windows related)
but I've got
a weird problem using GIT:
By accident I've tried to push a repository (containing an already
commited but not yet pushed submodule referenc
On Fri, Jul 13, 2018 at 7:50 PM Christian Couder
wrote:
> @@ -477,8 +478,8 @@ static int batch_objects(struct batch_options *opt)
>
> for_each_loose_object(batch_loose_object, &sa, 0);
> for_each_packed_object(batch_packed_object, &sa, 0);
> - if (repo
On Tue, Jul 3, 2018 at 12:41 AM Jonathan Tan wrote:
> +static void add_negotiation_tips(struct git_transport_options *smart_options)
> +{
> + struct oid_array *oids = xcalloc(1, sizeof(*oids));
> + int i;
> +
> + for (i = 0; i < negotiation_tip.nr; i++) {
> + const
On Sun, Jul 8, 2018 at 8:03 PM Pratik Karki wrote:
> +int cmd_rebase(int argc, const char **argv, const char *prefix)
> +{
> + /*
> +* NEEDSWORK: Once the builtin rebase has been tested enough
> +* and git-legacy-rebase.sh is retired to contrib/, this preamble
> +* ca
On Thu, Jun 28, 2018 at 12:33 AM Brandon Williams wrote:
> +static void receive_wanted_refs(struct packet_reader *reader, struct ref
> *refs)
> +{
> + process_section_header(reader, "wanted-refs", 0);
> + while (packet_reader_read(reader) == PACKET_READ_NORMAL) {
> + str
On Mon, Jul 2, 2018 at 9:49 PM Jameson Miller wrote:
> +struct cache_entry *make_transient_cache_entry(unsigned int mode, const
> struct object_id *oid,
> + const char *path, int stage)
> +{
> + struct cache_entry *ce;
> + int len;
> +
> +
The --interdiff option introduces the embedded interdiff generically as
"Interdiff:", however, we can do better when --reroll-count is specified
by emitting "Interdiff against v{n}:" instead.
Signed-off-by: Eric Sunshine
---
builtin/log.c | 17 -
revision.h
make_cover_letter() returns early when it lacks sufficient state to emit
a diffstat, which makes it difficult to extend the function to reliably
emit additional generated content. Work around this shortcoming by
factoring diffstat-printing logic out to its own function and calling it
as needed with
The --range-diff option announces the embedded range-diff generically
as "Range-diff:", however, we can do better when --reroll-count is
specified by emitting "Range-diff against v{n}:" instead.
Signed-off-by: Eric Sunshine
---
builtin/log.c | 7 ++-
revision.h| 1 +
2 files changed, 7 i
The actual diffs output by range-diff respect diff_option.file, which
range-diff passes down the call-chain, thus are destination-agnostic.
However, output_pair_header() is hard-coded to emit to 'stdout'. Fix
this by making output_pair_header() respect diff_option.file, as well.
Signed-off-by: Eri
When submitting a revised version of a patch series, it can be helpful
(to reviewers) to include a summary of changes since the previous
attempt in the form of an interdiff, however, doing so involves manually
copy/pasting the diff into the cover letter.
Add an --interdiff option to automate this
When submitting a revised version of a patch series, it can be helpful
(to reviewers) to include a summary of changes since the previous
attempt in the form of a range-diff, however, doing so involves manually
copy/pasting the diff into the cover letter.
Add a --range-diff option to automate this
When submitting a revised a patch series, the --range-diff option embeds
a range-diff in the cover letter showing changes since the previous
version of the patch series. The argument to --range-diff is a simple
revision naming the tip of the previous series, which works fine if the
previous and cur
When submitting a revised version of a patch or series, it can be
helpful (to reviewers) to include a summary of changes since the
previous attempt in the form of a range-diff, typically in the cover
letter. However, it is occasionally useful, despite making for a noisy
read, to insert a range-diff
When re-submitting a patch series, it is often helpful (for reviewers)
to include an interdiff or range-diff against the previous version.
Doing so requires manually running git-diff or git-range-diff and
copy/pasting the result into the cover letter of the new version.
This series automates the p
There are a number of very low-level configuration details which need to
be managed precisely to generate a proper range-diff. In particular,
'diff_options' output format, header suppression, indentation, and
dual-color mode must all be set appropriately to ensure proper behavior.
Handle these det
When submitting a revised version of a patch or series, it can be
helpful (to reviewers) to include a summary of changes since the
previous attempt in the form of an interdiff, typically in the cover
letter. However, it is occasionally useful, despite making for a noisy
read, to insert an interdiff
In patches generated by git-format-patch, the area below the "---" line
following the commit message and before the actual 'diff' can be used
for commentary which the patch author wants to convey to readers of the
patch itself but not include in the commit message proper.
By default, the commentar
The range-diff back-end allows its heuristic to be tweaked via the
"creation factor". git-range-diff, the only client of the back-end,
defaults the factor to 60% (hard-coded in builtin/range-diff.c), but
allows the user to override it with the --creation-factor option.
Publish the default range fa
A future change will allow "git format-patch --interdiff= -1" to
insert an interdiff into the commentary section of the lone patch of a
1-patch series. However, to prevent the inserted interdiff from
confusing git-am, as well as human readers, it needs to be indented.
Therefore, teach show_interdif
When generating a range-diff, matching up commits between two version of
a patch series involves heuristics, thus may give unexpected results.
git-range-diff allows tweaking the heuristic via --creation-factor.
Follow suit by accepting --creation-factor in combination with
--range-diff when generat
On Sat, 21 Jul 2018 23:59:41 +, brian m. carlson wrote:
> On Sun, Jul 22, 2018 at 12:38:41AM +0200, Johannes Schindelin wrote:
> > Do you really want to value contributors' opinion more than
> > cryptographers'? I mean, that's exactly what got us into this hard-coded
> > SHA-1 mess in the first
On Sun, Jul 22, 2018 at 5:57 AM Eric Sunshine wrote:
> Add an --interdiff option to automate this process. The argument to
> --interdiff specifies the tip of the previous attempt against which to
> generate the interdiff.
>
> Signed-off-by: Eric Sunshine
> ---
> diff --git a/interdiff.c b/interdi
On Sun, Jul 22, 2018 at 10:50 AM, Duy Nguyen wrote:
> On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
> wrote:
>> +pack.island::
>> + A regular expression configuring a set of delta islands. See
>> + "DELTA ISLANDS" in linkgit:git-pack-objects[1] for details.
>> +
>
> That section i
On Sun, Jul 22, 2018 at 11:34:42AM +0200, Eric Deplagne wrote:
> On Sat, 21 Jul 2018 23:59:41 +, brian m. carlson wrote:
> > I don't know your colleagues, and they haven't commented here. One
> > person that has commented here is Adam Langley. It is my impression
> > (and anyone is free to co
On Sun, 22 Jul 2018 14:21:48 +, brian m. carlson wrote:
> On Sun, Jul 22, 2018 at 11:34:42AM +0200, Eric Deplagne wrote:
> > On Sat, 21 Jul 2018 23:59:41 +, brian m. carlson wrote:
> > > I don't know your colleagues, and they haven't commented here. One
> > > person that has commented here
Dear all,
I wanted to react to some statements I read in this discussion. But
first let me introduce myself. I'm Joan Daemen and I'm working in
symmetric cryptography since 1988. Vincent Rijmen and I designed
Rijndael that was selected to become AES and Guido Bertoni, Michael
Peeters and Gilles Va
Hi Dear, my name is Jack and i am seeking for a relationship in which i will
feel loved after a series of failed relationships.
I am hoping that you would be interested and we could possibly get to know each
other more if you do not mind. I am open to answering questions from you as i
think my
Somewhere upthread, Brian refers to me as a cryptographer. That's
flattering (thank you), but probably not really true even on a good
day. And certainly not true next to Joan Daemen. I do have experience
with crypto at scale and in ecosystems, though.
Joan's count of cryptanalysis papers is a reas
It seems that t7406 is sometimes shaky - when checking stderr in test
case 4.
The order of the submodules may vary, sorting the stderr output makes it
more reliable (and somewhat funny to read).
Does anybody have a better idea ?
[]
cat
On Sat, Jul 21, 2018 at 11:56:06PM +0200, Johannes Schindelin wrote:
> > The script that I feed a message from gmane or public-inbox when I need
> > to learn the set of commits that resulted from the message instead uses
> > "git grep $message-id notes/amlog". And that is fast enough for my
> > p
34 matches
Mail list logo
