Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Santiago Torres writes: > ... It seems Debian oldstable and other variants still ship gpg1, > which doesn't have it. Would it make sense to have a fallthrough branch > on the switch statement for gpg2.1 instead? something like the attached patch. If the problem of leftover

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

> Oh, wait, I can run "gpg" just fine, but I do not seem to have > gpgconf. > > $ type gpgconf > bash: type: gpgconf: not found > > The patch may need a bit more cross-version work, it seems. Right, sorry about that. I was testing against Debian Stretch/Arch, who do ship gpg2 with

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Santiago Torres writes: > On Mon, Jul 17, 2017 at 03:09:44PM -0700, Junio C Hamano wrote: >> I am not sure if it is merely "if it's even necessary"; if there are >> two tests running in parallel, with their own separate >> $TRASH_DIRECTORY, and one of them say "kill the agent"

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

On Mon, Jul 17, 2017 at 03:09:44PM -0700, Junio C Hamano wrote: > I am not sure if it is merely "if it's even necessary"; if there are > two tests running in parallel, with their own separate > $TRASH_DIRECTORY, and one of them say "kill the agent" at the > beginning, would it affect the other

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Santiago Torres writes: > Other projects such as notmuch opted for a solution that's simlar to > what I had suggested[1], but I wonder if it's even necessary to do. > There is already a fix on the master branch of gnupg[2], which I imagine > will show up to the next version of

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

> > I'll dig into this. This sounds a way more reasonable approach. > > Thanks. Another thing that may help, if it turns out that we do > want to let agent run when it wants to I did some digging on the reason as to why this was happening. It turns out there is a bug on gnupg. As of gpg 2.1.21,

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Ævar Arnfjörð Bjarmason writes: > Let's see what *nix does: > > $ rm -rf /tmp/{master,backup}; mkdir /tmp/master && cd /tmp/master && mv > /tmp/{master,backup} ; file /tmp/{master,backup} > > Similarly to that, when you're on "master" "git branch --move backup" > could

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

On Thu, Jul 13 2017, Junio C. Hamano jotted: > Here are the topics that have been cooking. Commits prefixed with > [...] > > * jc/allow-lazy-cas (2017-07-06) 1 commit > - push: disable lazy --force-with-lease by default > > Because "git push --force-with-lease[=]" that relies on the >

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Santiago Torres writes: >> Combined with the unknown-ness of the root cause of the issue, I can >> only say that the patch may be raising an issue worth addressing, >> but it is too sketchy to tell if it is a right solution or what the >> exact problem being solved is. > > I'll

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Hi, Junio. Thanks for replying. > I postponed it when I saw it the first time to see if anybody > comments on it, and then it turns out nobody was interested, and it > remained uninteresting to the list to this day. > True, that's what I was afraid of, but I wanted to give it some closure. >

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Santiago Torres writes: >> Here are the topics that have been cooking. > > I sent (a patch almost a week ago) that would probably[1] be labeled > as "uninteresting" (as per the notes from the maintainer), but I wanted > to make sure it wasn't lost in the noise -- I see that

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

> Here are the topics that have been cooking. Hi, I sent (a patch almost a week ago) that would probably[1] be labeled as "uninteresting" (as per the notes from the maintainer), but I wanted to make sure it wasn't lost in the noise -- I see that theres a lot of active development lately. I

What's cooking in git.git (Jul 2017, #04; Thu, 13)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. A maintenance release for 2.13.x