On Fri, Oct 11, 2019 at 11:35 PM Pratyush Yadav wrote:
>
> I'll take the silence to mean there are no further objections, and will
> merge this version in to 'master'.
correct. FWIW
Acked-by: Bert Wesarg
>
> On 08/10/19 05:47PM, Pratyush Yadav wrote:
> > It is a good idea to have a readme so p
Denton Liu writes:
> Changes since v3:
>
> * Change --infer-cover-subject to --cover-from-description
>
> * No more test cleanup patches (they were merged in
> 'dl/format-patch-doc-test-cleanup')
With these patches, t4013 and t9902 seem to break, when queued on
top of dl/format-patch-doc-test-
Denton Liu writes:
> +format.coverFromDescription::
> + The default mode for format-patch to determine which parts of
> + the cover letter will be populated using the branch's
> + description. See the `--cover-from-description` option in
> + linkgit:git-format-patch[1].
> +
> for
Denton Liu writes:
> -#define THREAD_SHALLOW 1
> -#define THREAD_DEEP 2
> -static int thread;
> +enum thread_level {
> + THREAD_UNSET,
> + THREAD_SHALLOW,
> + THREAD_DEEP
> +};
> +static enum thread_level thread;
As the assignment of values do not change, this is a safe conversion
ev
Beat Bolli writes:
> diff --git a/utf8.c b/utf8.c
> index 3b42fadffd..5c8f151f75 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -95,13 +95,11 @@ static int git_wcwidth(ucs_char_t ch)
> return -1;
>
> /* binary search in table of non-spacing characters */
> - if (bisearch(ch,
Jakob Jarmar writes:
> diff --git a/t/t3906-stash-submodule.sh b/t/t3906-stash-submodule.sh
> index d7219d6f8f..83106fa958 100755
> --- a/t/t3906-stash-submodule.sh
> +++ b/t/t3906-stash-submodule.sh
> @@ -1,6 +1,6 @@
> #!/bin/sh
>
> -test_description='stash apply can handle submodules'
> +tes
On 10/11/2019 12:50 PM, James Coglan wrote:
> On 10/10/2019 18:19, Derrick Stolee wrote:
>> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
>>> +++ b/t/t4215-log-skewed-merges.sh
>>> @@ -0,0 +1,42 @@
>>> +#!/bin/sh
>>> +
>>> +test_description='git log --graph of skewed merges'
>>> +
>>
"Maxim Belsky via GitGitGadget" writes:
> Signed-off-by: Maxim Belsky
> Helped-by: Johannes Schindelin
> Helped-by: Junio C Hamano
No need to resend (as I'll fix it up locally while queuing), but
your sign-off comes last, as we keep these things chronological.
With help from others, you wrote
"William Baker via GitGitGadget" writes:
> +# Test staging/unstaging files that appear at the end of the index. Test
> +# file names begin with 'z' so that they are sorted to the end of the index.
Well, the test is now done in a freshly created repository, so the
z* files are the only thing yo
Daniel Lezcano writes:
> I would like to do something:
>
> git am -s -l "Link: https://lore.kernel.org/r/"
>
> Which will give:
>
> blabla
>
> Signed-off-by: aut...@kairnail.org
> Signed-off-by: commi...@kairnail.org
> Link: https://lore.kernel.org/r/
>
> This way it is compatible with patchwork,
Junio C Hamano writes:
> By the way, I think I made a mistake in my calendar math.
>
> This topic was merged to 'next' on the 7th and it is not especially
> tricky; unless I (or somebody else) find glaring issues in it during
> the final sanity check before merging it to 'master' during the next
c ("sha1-file: split OBJECT_INFO_FOR_PREFETCH", 2019-05-28)
separated SKIP_FETCH_OBJECT out of FOR_PREFETCH, the latter of which
was and is SKIP_FETCH and QUICK combined. Use SKIP_FETCH_OBJECT
alone may need to be re-examined and discouraged?
Jonathan Tan writes:
>> > Also, I have a slight preference for putting "= 02" on the BLAME_COPY
>> > line but that is not necessary.
>>
>> That is absolutely necessary; it is not like "we do not care what
>> exact value _COPY gets; it can be any value as long as it is _MOVE
>> plus 1", as these
James Coglan writes:
> - We don't want a general solution to this problem for everything
> `strbuf` could be used for; it only needs to address the graph
> padding problem.
Of course. Somebody may use strbuf to hold rows of a table and you
do not want to contaminate strbuf with fields like widt
Jeff King writes:
> The current code does so by creating a new entry in the reused_chunks
> array. In the worst case that can grow to have the same number of
> entries as we have objects. So this code was an attempt to pad the
> header of a shrunken entry to keep it the same size. I don't remembe
Elijah Newren writes:
> Did I shoot myself in the foot by being quick to jump on Rene's couple
> of cosmetic touch-up suggestions he posted over a week after the
> series was originally posted?
If the suggested updates were simple enough to do and would improve
the result sufficiently (which is
On Fri, Oct 11, 2019 at 07:50:10PM +0200, SZEDER Gábor wrote:
> On Thu, Oct 10, 2019 at 08:19:32AM -0700, Emily Shaffer wrote:
> > diff --git a/Documentation/MyFirstObjectWalk.txt
> > b/Documentation/MyFirstObjectWalk.txt
> > new file mode 100644
> > index 00..7085f17072
> > --- /dev/null
On Fri, Oct 11, 2019 at 02:50:34PM +0900, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > @@ -77,6 +77,7 @@ API_DOCS = $(patsubst %.txt,%,$(filter-out
> > technical/api-index-skel.txt technica
> > SP_ARTICLES += $(API_DOCS)
> >
> > TECH_DOCS += MyFirstContribution
> > +TECH_DOCS += MyFir
On Fri, Oct 11, 2019 at 3:26 PM Elijah Newren wrote:
>
> On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
> Looks good, thanks for the fixes. I'm still slightly worried about
> folks not looking at the docs and calling sparse-checkout set without
> calling init, and then being nega
On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The 'git sparse-checkout set' subcommand takes a list of patterns
> and places them in the sparse-checkout file. Then, it updates the
> working directory to match those patterns. For a large list of
On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The 'git sparse-checkout set' subcommand takes a list of patterns
> as arguments and writes them to the sparse-checkout file. Then, it
> updates the working directory using 'git read-tree -mu HEAD'.
Hi Johannes,
Thanks for the re-roll. Some comments below...
On 08/10/19 04:33AM, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> Since v2.9.0, Git knows about the config variable core.hookspath that
> allows overriding the path to the directory contai
On Mon, Oct 7, 2019 at 11:26 AM Derrick Stolee wrote:
>
> On 10/5/2019 8:30 PM, Elijah Newren wrote:
> > On Sat, Oct 5, 2019 at 3:44 PM Elijah Newren wrote:
> >>
> >> On Thu, Sep 19, 2019 at 3:07 PM Derrick Stolee via GitGitGadget
> >> wrote:
> >>> +static int write_patterns_and_update(struct pa
On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
wrote:
> During the 'git sparse-checkout init' call, we must first look
> to see if HEAD is valid, since 'git clone' does not have a valid
> HEAD.
...does not have a valid HEAD by the time git_sparse_checkout_init() is called?
> The
On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
wrote:
> ++
> +The init subcommand also enables the 'extensions.worktreeConfig' setting
> +and sets the `core.sparseCheckout` setting in the worktree-specific config
> +file. This prevents the sparse-checkout feature from interfering w
> As a general rule (and why I'm raising this issue in reply to Jonathan's
> patch), I think most or all sites that want OBJECT_INFO_QUICK will want
> SKIP_FETCH_OBJECT as well, and vice versa. The reasoning is generally
> the same:
>
> - it's OK to racily have a false negative (we'll still be c
Hi Thomas & Junio,
On Mon, 7 Oct 2019, Thomas Gummerer wrote:
> On 10/07, Junio C Hamano wrote:
> > Johannes Schindelin writes:
> >
> > > Date: Fri, 04 Oct 2019 08:09:25 -0700 (PDT)
> > > [...]
> > > X-Google-Original-Date: Fri, 04 Oct 2019 15:09:10 GMT
> > > [...]
> > >
> > > I am fai
lly repopulating the working directory when you
> +no longer want sparse checkout. You cannot just disable "sparse
> +checkout" because skip-worktree bits are still in the index and your working
> +directory is still sparsely p
I'll take the silence to mean there are no further objections, and will
merge this version in to 'master'.
On 08/10/19 05:47PM, Pratyush Yadav wrote:
> It is a good idea to have a readme so people finding the project can
> know more about it, and know how they can get involved.
>
> Signed-off-by
> > This makes sense - offsets may be different when we omit objects from
> > the packfile. I think this can be computed by calculating the number of
> > zero bits between the current object's index and the nth object prior
> > (where n is the offset) in the bitmap resulting from
> > reuse_partial_
On Fri, Oct 11, 2019 at 03:10:33PM -0500, Brent Casavant wrote:
> I noticed what appears to be a bug in rev-parse with an admittedly
> somewhat unusual combination of arguments.
>
> Compare the output of the following:
>
> % git rev-parse HEAD --not --remotes=origin
> 3de09080eb219149a8596dc2191
On Fri, Oct 11, 2019 at 9:42 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> * en/fast-imexport-nested-tags (2019-10-04) 8 commits
> >> (merged to 'next' on 2019-10-07 at 3e75779e10)
> >> + fast-export: handle nested tags
> >> ...
> >> + fast-export: fix exporting a tag and nothing
On Fri, Oct 11, 2019 at 11:48:03AM -0700, Jonathan Tan wrote:
> > > Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> > > these names are still global, so it is good to retain the extra context.
> > >
> > > (This doesn't mean that you are wrong to remove them - I just gave
// Dropping a few folks from the cc list as the thread is so old that
I think it should just be the normal git mailing list.
Hi Dscho,
On Wed, Oct 9, 2019 at 1:39 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> sorry about the blast from the past, but I just stumbled over something
> I could no
> > Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> > these names are still global, so it is good to retain the extra context.
> >
> > (This doesn't mean that you are wrong to remove them - I just gave my
> > opinion, and a reason for my opinion. If you had a reason to re
> Jonathan Tan writes:
>
> >> - if ((opt & PICKAXE_BLAME_COPY_HARDEST)
> >> - || ((opt & PICKAXE_BLAME_COPY_HARDER)
> >> + if ((opt & BLAME_COPY_HARDEST)
> >> + || ((opt & BLAME_COPY_HARDER)
> >
> > Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> > these name
Christian Schoenebeck writes:
> 4. MTA's should also address this DKIM issue more accurately.
I agree that Exim should be changed as you suggest.
>
> By taking these things into account, emails of domains with strict DMARC
> policies are no longer munged on gnu lists.
Additional info: Migra
On Fri, Oct 11, 2019 at 09:49:53AM +0200, Christian Couder wrote:
> > I think this should be squashed with patch 3, adding to that commit
> > message "since word_alloc might be 0, we need to change the growth
> > function". (Or just make the minimum word_alloc be 1 or 32 or something
> > positive,
On Thu, Oct 10, 2019 at 04:59:52PM -0700, Jonathan Tan wrote:
> > +/*
> > + * Record the offsets needed in our reused packfile chunks due to
> > + * "gaps" where we omitted some objects.
> > + */
> > +static struct reused_chunk {
> > + off_t start;
> > + off_t offset;
> > +} *reused_chunks;
>
On Thu, Oct 10, 2019 at 08:19:32AM -0700, Emily Shaffer wrote:
> diff --git a/Documentation/MyFirstObjectWalk.txt
> b/Documentation/MyFirstObjectWalk.txt
> new file mode 100644
> index 00..7085f17072
> --- /dev/null
> +++ b/Documentation/MyFirstObjectWalk.txt
> @@ -0,0 +1,905 @@
> +My Firs
On 11/10/2019 17:02, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 10 Oct 2019, Denton Liu wrote:
>
>> On Fri, Oct 11, 2019 at 10:42:20AM +0900, Junio C Hamano wrote:
>>> Denton Liu writes:
>>>
static int calculate_width(const struct strbuf *row)
{
int in_termcode
Hi Johannes,
On 10/10/2019 22:07, Johannes Schindelin wrote:
> Hi James,
>
> On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote:
>
>> From: James Coglan
>>
>> All the output functions in `graph.c` currently keep track of how many
>> printable chars they've written to the buffer, before ca
On 10/10/2019 18:49, Derrick Stolee wrote:
> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
>> From: James Coglan
>>
>> Following the introduction of "left-skewed" merges, which are merges
>> whose first parent fuses with another edge to its left, we have some
>> more edge cases to d
On 10/10/2019 18:19, Derrick Stolee wrote:
> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
>> +++ b/t/t4215-log-skewed-merges.sh
>> @@ -0,0 +1,42 @@
>> +#!/bin/sh
>> +
>> +test_description='git log --graph of skewed merges'
>> +
>> +. ./test-lib.sh
>> +
>> +test_expect_success 'setup
Elijah Newren writes:
>> * en/fast-imexport-nested-tags (2019-10-04) 8 commits
>> (merged to 'next' on 2019-10-07 at 3e75779e10)
>> + fast-export: handle nested tags
>> ...
>> + fast-export: fix exporting a tag and nothing else
>>
>> Updates to fast-import/export.
>>
>> Will merge to 'mast
On 10/10/19 4:22 AM, SZEDER Gábor wrote:
>>> +# This test covers staging/unstaging files that appear at the end of the
>>> index.
>>> +# Test files with names beginning with 'z' are used under the assumption
>>> that
>>> +# earlier tests do not add/leave index entries that sort below them.
>
>
On Fri, Oct 11, 2019 at 05:47:44PM +0200, Bert Wesarg wrote:
> > > > +test_expect_success 'format-patch -o with no leading directories' '
> > > > + rm -fr patches &&
> > > > + git format-patch -o patches master..side &&
> > > > + count=$(git rev-list --count master..side) &&
> > > > +
On Fri, Oct 11, 2019 at 08:31:30AM -0400, Derrick Stolee wrote:
> >> Ensure that these lazy fetches do not occur.
> >
> > That makes sense. For similar reasons, should we be using
> > OBJECT_INFO_QUICK here? If the other side has a bunch of ref tips that
> &g
On Fri, Oct 11, 2019 at 05:02:33PM +0100, Philip Oakley wrote:
> Another case, of a different style, is that of `git bundle --all` which does
> need mentioning that particular rev-list option as a major usage (I couldn't
> manage to understand the three layers of man page that needed reading).
>
Hi,
On Thu, 10 Oct 2019, Denton Liu wrote:
> On Fri, Oct 11, 2019 at 10:42:20AM +0900, Junio C Hamano wrote:
> > Denton Liu writes:
> >
> > > static int calculate_width(const struct strbuf *row)
> > > {
> > > int in_termcode = 0;
> > > int width = 0;
> > > int i
On 11/10/2019 07:04, Jeff King wrote:
On Fri, Oct 04, 2019 at 05:13:08PM -0700, Denton Liu wrote:
The synopsis section in git-rev-list.txt has grown to be a huge list
that probably needs its own synopsis. Since the list is huge, users may
be given the false impression that the list is complete,
On Sat, Oct 12, 2019 at 02:42:49AM +1100, Daniel Axtens wrote:
> >> where a possible solution was to get senders to use in-body From
> >> headers even when sending their own patches.
> [...]
> I'm not sure this solution is correct.
>
> If I take a patch from Andrew, backport it, and send to the l
On Fri, Oct 11, 2019 at 5:45 PM Bert Wesarg wrote:
>
> On Fri, Oct 11, 2019 at 4:46 PM SZEDER Gábor wrote:
> >
> > On Fri, Oct 11, 2019 at 10:36:41AM +0200, Bert Wesarg wrote:
> > > Changes in v4:
> > > * based on dl/format-patch-doc-test-cleanup and adopt it
> >
> > Thanks... but here I am nit
On Fri, Oct 11, 2019 at 4:46 PM SZEDER Gábor wrote:
>
> On Fri, Oct 11, 2019 at 10:36:41AM +0200, Bert Wesarg wrote:
> > Changes in v4:
> > * based on dl/format-patch-doc-test-cleanup and adopt it
>
> Thanks... but here I am nitpicking again, sorry :)
>
> > diff --git a/t/t4014-format-patch.sh b
On Fri, Oct 11, 2019 at 12:35 AM Junio C Hamano wrote:
> [Cooking]
[...]
> * en/fast-imexport-nested-tags (2019-10-04) 8 commits
> (merged to 'next' on 2019-10-07 at 3e75779e10)
> + fast-export: handle nested tags
> + t9350: add tests for tags of things other than a commit
> + fast-export:
Hi,
>> Neat. There was discussion on a similar issue recently in:
>>
>>
>> https://public-inbox.org/git/305577c2-709a-b632-4056-658277117...@redhat.com/
>>
>> where a possible solution was to get senders to use in-body From
>> headers even when sending their own patches.
>
> I think that's a
Hi Dscho
On 10/10/2019 22:31, Johannes Schindelin wrote:
Hi Phillip,
On Thu, 10 Oct 2019, Phillip Wood via GitGitGadget wrote:
From: Phillip Wood
Prior to commit 356ee4659b ("sequencer: try to commit without forking
'git commit'", 2017-11-24) the sequencer would always run the
post-commit h
On Fri, Oct 11, 2019 at 10:36:41AM +0200, Bert Wesarg wrote:
> Changes in v4:
> * based on dl/format-patch-doc-test-cleanup and adopt it
Thanks... but here I am nitpicking again, sorry :)
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> index 72b09896cf..9facc3a79e 100755
> --
On Freitag, 11. Oktober 2019 06:50:14 CEST Andrew Donnellan wrote:
> On 11/10/19 3:36 pm, Andrew Donnellan wrote:
> > It would be nice if Mailman could adopt X-Original-Sender too. As it is,
>
> (which I have gone ahead and reported as
> https://gitlab.com/mailman/mailman/issues/641)
Not stopping
e upstream of the branch being pushed.
>>
>> Ensure that these lazy fetches do not occur.
>
> That makes sense. For similar reasons, should we be using
> OBJECT_INFO_QUICK here? If the other side has a bunch of ref tips that
> we don't have, we'll end up re-scanning
On Thu, Oct 10, 2019 at 11:44:39AM -0700, Jonathan Tan wrote:
> > Convert pickaxe_blame preprocessor constants in blame.h to an enum.
> > Also replace previous instances of the constants with the new enum values.
>
> First of all, thanks for your initiative in finding a microproject and
> making a
On Fri, Oct 11, 2019 at 1:44 AM Jonathan Tan wrote:
>
> > As we now allocate 2 more words than necessary for each
> > bitmap to serve as marks telling us that we can stop
> > iterating over the words, we don't need to rely on
> > bitmap_git->reuse_objects to stop iterating over the words.
>
> As P
On Fri, Oct 11, 2019 at 1:40 AM Jonathan Tan wrote:
>
> > From: Jeff King
> >
> > In a following patch we will allocate a variable number
> > of words in some bitmaps. When iterating over the words we
> > will need a mark to tell us when to stop iterating. Let's
> > always allocate 2 more words,
On Fri, Oct 11, 2019 at 1:59 AM Jonathan Tan wrote:
>
> I'm going to start with pack-bitmap.h, then builtin/pack-objects.c.
>
> > int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
> > struct packed_git **packfile,
> > -
On Wed, Oct 09, 2019 at 07:25:51PM +0200, SZEDER Gábor wrote:
> > Probably they'd be easy enough to fix (and they're out of tree anyway),
> > so I'm not really arguing against the escape hatch exactly. Mostly I'm
> > just surprised that if I introduced 3 cases (out of probably a dozen
> > scripts)
On Wed, Oct 09, 2019 at 11:28:51AM -0400, Joey Hess wrote:
> > I suspect it's not entirely sufficient for clean input, though. You're
> > not feeding filenames but rather full "object names". I wouldn't be
> > surprised if we mis-parse "$rev:$path" when $path has "@{}" or similar
> > in it.
>
> N
makes sense. For similar reasons, should we be using
OBJECT_INFO_QUICK here? If the other side has a bunch of ref tips that
we don't have, we'll end up re-scanning the pack directory over and over
(which is _usually_ pretty quick, but can be slow if you have a lot of
packs locally). And it&#
On Fri, Oct 04, 2019 at 05:13:08PM -0700, Denton Liu wrote:
> The synopsis section in git-rev-list.txt has grown to be a huge list
> that probably needs its own synopsis. Since the list is huge, users may
> be given the false impression that the list is complete, however it is
> not. It is missing
Jakob Jarmar writes:
> git stash push does not recursively stash submodules, but if
> submodule.recurse is set, it may recursively reset --hard them. Having
> only the destructive action recurse is likely to be surprising
> behaviour, and unlikely to be desirable, so the easiest fix should be to
On Fri, Oct 11, 2019 at 01:39:28PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > ... but I'd still wait for a few
> > days for people who expressed their Acks but your scan missed, or
> > those who wanted to give their Acks but forgot to do so, to raise
> > their hands on this thre
Denton Liu writes:
> In previous patches, extern was mechanically removed from function
> declarations without care to formatting, causing parameter lists to be
> misaligned. Manually format changed sections such that the parameter
> lists are realigned.
>
> Viewing this patch with 'git diff -w'
Johannes Schindelin writes:
> On Thu, 10 Oct 2019, Maxim Belsky via GitGitGadget wrote:
>
>> From: Maxim Belsky
>>
>> Signed-off-by: Maxim Belsky
>
> I totally agree with the patch, but only because I read a couple of
> reports that users were struggling with this. Maybe add a couple of
> refer
On Thu, Oct 10, 2019 at 12:18:53AM +, Eric Wong wrote:
> > The project leadership team can be contacted by email as a whole at
> > g...@sfconservancy.org, or individually:
> >
> > - Ævar Arnfjörð Bjarmason
> > - Christian Couder
> > - Jeff King
> > - Junio C Hamano
>
> All folks
Emily Shaffer writes:
> @@ -77,6 +77,7 @@ API_DOCS = $(patsubst %.txt,%,$(filter-out
> technical/api-index-skel.txt technica
> SP_ARTICLES += $(API_DOCS)
>
> TECH_DOCS += MyFirstContribution
> +TECH_DOCS += MyFirstRevWalk
s/Rev/Object/ probably (if so I can locally amend).
> diff --git a/D
Johannes Schindelin writes:
> I should note that I looked through all of the hits of `git grep -w
> except -- t/` and did not find any other typo.
Thanks.
Thomas Gummerer writes:
> On 10/10, Johannes Schindelin via GitGitGadget wrote:
>> From: Johannes Schindelin
>>
>> The original phrasing of this paragraph made at least one person stumble
>> over the word "from" (thinking that it was a typo and "from" was
>> intended), and other readers chimed
On Fri, Oct 11, 2019 at 10:42:20AM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > static int calculate_width(const struct strbuf *row)
> > {
> > int in_termcode = 0;
> > int width = 0;
> > int i;
> >
> > for (i = 0; i < row.len; i++
On 11/10/19 3:36 pm, Andrew Donnellan wrote:
It would be nice if Mailman could adopt X-Original-Sender too. As it is,
(which I have gone ahead and reported as
https://gitlab.com/mailman/mailman/issues/641)
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com I
Junio C Hamano writes:
> ... but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.
Now, two days and four hours have passed, so I'll merge the result
to 'n
On 11/10/19 3:29 pm, Junio C Hamano wrote:
Jeff King writes:
This might provide an alternate solution (or vice versa). I kind of like
this one better in that it doesn't require the sender to do anything
differently (but it may be less robust, as it assumes the receiver
reliably de-mangling).
Jeff King writes:
> This might provide an alternate solution (or vice versa). I kind of like
> this one better in that it doesn't require the sender to do anything
> differently (but it may be less robust, as it assumes the receiver
> reliably de-mangling).
I share the assessment. I also feel t
Johannes Schindelin writes:
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index d898a57f5d..adb8c89c60 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -1653,7 +1653,7 @@ int cmd_commit(int argc, const char **argv, const char
>> *prefix)
>>
>> repo_rerere(the_reposi
Johannes Schindelin writes:
>> builtin/commit.c | 22 --
>> commit.h | 3 ---
>> sequencer.c | 45 ++---
>> sequencer.h | 2 ++
>> 4 files changed, 36 insertions(+), 36 deletions(-)
>
> Hmm. I would have thought that
"Johannes Schindelin via GitGitGadget"
writes:
> To answer Jonathan's question, at long last, yes, it is useful. A hook is
> not only an opportunity to run code at given points in Git's life cycle, but
> also an opportunity to stop Git in its tracks.
In general that is correct, and especially so
Jonathan Tan writes:
>> -if ((opt & PICKAXE_BLAME_COPY_HARDEST)
>> -|| ((opt & PICKAXE_BLAME_COPY_HARDER)
>> +if ((opt & BLAME_COPY_HARDEST)
>> +|| ((opt & BLAME_COPY_HARDER)
>
> Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> these names are stil
Jeff King writes:
> Yes, I agree that ordering and de-duplication rules are useful, too.
> Some of that can be expressed already in trailer.* config, but I don't
> know if it would be capable enough to do everything you want (though
> again, it would be really nice to _make_ it capable enough so
Denton Liu writes:
> static int calculate_width(const struct strbuf *row)
> {
> int in_termcode = 0;
> int width = 0;
> int i;
>
> for (i = 0; i < row.len; i++) {
> if (row.buf[i] == '\033')
>
Johannes Schindelin writes:
> This is a big heavy-handed: adding a `width` field to `struct strbuf`
> and maintaining it _just_ for the purpose of `graph.c` puts an
> unnecssary load on every other `strbuf` user (of which there are a
> _lot_).
>
> So my obvious question is: what makes `width` dif
On 10/10/2019 7:05 PM, Denton Liu wrote:
> Hi Dscho,
>
> On Thu, Oct 10, 2019 at 11:07:35PM +0200, Johannes Schindelin wrote:
>> Hi James,
>>
>> On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote:
>>
>>> From: James Coglan
>>>
>>> All the output functions in `graph.c` currently keep trac
I'm going to start with pack-bitmap.h, then builtin/pack-objects.c.
> int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
> struct packed_git **packfile,
> -uint32_t *entries, off_t *up_to);
> +
> As we now allocate 2 more words than necessary for each
> bitmap to serve as marks telling us that we can stop
> iterating over the words, we don't need to rely on
> bitmap_git->reuse_objects to stop iterating over the words.
As Peff states [1], this justification is probably incorrect as well.
> From: Jeff King
>
> In a following patch we will allocate a variable number
> of words in some bitmaps. When iterating over the words we
> will need a mark to tell us when to stop iterating. Let's
> always allocate 2 more words, that will always contain 0,
> as that mark.
[snip]
> if (b
On Fri, 11 Oct 2019 10:16:40 +1100 Daniel Axtens wrote:
>
> Andrew Donnellan writes:
>
> > On 11/10/19 6:41 am, Jonathan Nieder wrote:
> >> Interesting! I'm cc-ing the Git mailing list in case "git am" might
> >> wnat to learn the same support.
> > Argh, that reminds me... this patch only r
Andrew Donnellan writes:
> On 11/10/19 6:41 am, Jonathan Nieder wrote:
>> Interesting! I'm cc-ing the Git mailing list in case "git am" might
>> wnat to learn the same support.
> Argh, that reminds me... this patch only rewrites the name and email
> that is recorded as the Patchwork submitter,
On 2019-10-10 at 08:49:23, Toon Claes wrote:
> Jeff King writes:
>
> > Yeah, I'd agree that we should start first with a generic trailer line.
>
> IIUC you are suggesting something like this?
>
> git commit --trailer="Co-authored-by: "
>
> I really want to consider this, but I do not understa
On Fri, Oct 11, 2019 at 10:01:23AM +1100, Andrew Donnellan wrote:
> > This might provide an alternate solution (or vice versa). I kind of like
> > this one better in that it doesn't require the sender to do anything
> > differently (but it may be less robust, as it assumes the receiver
> > reliabl
Hi Dscho,
On Thu, Oct 10, 2019 at 11:07:35PM +0200, Johannes Schindelin wrote:
> Hi James,
>
> On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote:
>
> > From: James Coglan
> >
> > All the output functions in `graph.c` currently keep track of how many
> > printable chars they've written to
On 11/10/19 9:54 am, Jeff King wrote:
Neat. There was discussion on a similar issue recently in:
https://public-inbox.org/git/305577c2-709a-b632-4056-658277117...@redhat.com/
where a possible solution was to get senders to use in-body From
headers even when sending their own patches.
I thi
On Thu, Oct 10, 2019 at 12:41:32PM -0700, Jonathan Nieder wrote:
> > Add support for using the X-Original-Sender or Reply-To headers, as used by
> > Google Groups and Mailman respectively, to unmangle the From header when
> > necessary.
> [...]
> Interesting! I'm cc-ing the Git mailing list in ca
Hi Phillip,
On Thu, 10 Oct 2019, Phillip Wood via GitGitGadget wrote:
> From: Phillip Wood
>
> Prior to commit 356ee4659b ("sequencer: try to commit without forking
> 'git commit'", 2017-11-24) the sequencer would always run the
> post-commit hook after each pick or revert as it forked `git comm
401 - 500 of 116325 matches
Mail list logo
