git-credential-libsecret not prompting to unlock keyring

> Apologies, forgot the crucial details post that log: This turned out to be an error unrelated to git or git-credential-libsecret. Apologies for the noise (and the badly threaded reply earlier). Paul

Re: git-credential-libsecret not prompting to unlock keyring

Apologies, forgot the crucial details post that log: $ git --version git version 2.19.0 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.1 LTS Release:18.04 Codename: bionic

git-credential-libsecret not prompting to unlock keyring

Hi, For some reason today, after an apt update, my combination of GNOME keyring and git-credential-libsecret stopped working. Stopped working in so far as I am no longer prompted by GNOME keyring to unlock my keyring, instead I get prompted for the password that git is looking for. Trace output b

Re: Change in behaviour in git fetch between 2.18.0 and 2.18.0.547.g1d89318c48

> I think this is the bug from: > > https://public-inbox.org/git/20180729121900.ga16...@sigill.intra.peff.net/ > > The fix is in e2842b39f4 (fetch-pack: unify ref in and out param, > 2018-08-01), and is currently in the 'next' branch, and marked for > merging to master in the next integration cyc

Change in behaviour in git fetch between 2.18.0 and 2.18.0.547.g1d89318c48

Hi, I've tried to skim through the archive, but I couldn't find anything that describes what I'm seeing. Apologies if that's because I missed something/used the wrong search terms, or this is an intentional change in behaviour. Using 2.18.0.547.g1d89318c48, git fetch behaves differently to 2.18.0

Re: [PATCH 3/2] ls-files: only recurse on active submodules

> It looks like it was merged to master. This should be the relevant > commit: 188dce131 (ls-files: use repository object, 2017-06-22). I was just typing a response to my response. Apologies, I was testing locally with the wrong compiled version of git. Confirmed fixed for me in e2d9c4613 at lea

Re: [PATCH 3/2] ls-files: only recurse on active submodules

>> Thanks for the quick response. > > Course, let me know if you find anything else! :D Brandon - doesn't look like this change has made it's way into master: https://github.com/git/git/blob/master/builtin/ls-files.c Is there a plan to merge it? Thanks

Re: [PATCH 3/2] ls-files: only recurse on active submodules

>> How can I help diagnose what's going on here? > Welp that's a pretty terrible bug which stems from > missing a check to see if a submodule is initialized, and not explicitly > setting GIT_DIR=.git (theres cases where we don't want this but turns > out we probably should do that here). Let me