Re: [BUG] git remote prune removes local tags, depending on fetch config

ava...@gmail.com> wrote: > > On Mon, Jan 15 2018, Michael Giuffrida jotted: > >> `git remote prune ` should "delete all stale remote-tracking >> branches under ". I was surprised to discover, after some >> troubleshooting, that it also deletes *all* l

[BUG] git remote prune removes local tags, depending on fetch config

`git remote prune ` should "delete all stale remote-tracking branches under ". I was surprised to discover, after some troubleshooting, that it also deletes *all* local tags that don't exist on the remote, if the following refspec is included in the remote's fetch config:

[BUG] add_again() off-by-one error in custom format

In a custom pretty format, using the '+' or ' ' combinators to prefix a non-empty expansion with whitespace will erroneously truncate subsequent expansions of the same type. Normally '%+X' inserts a newline before , IFF the expansion of X is non-empty: $ git log -n 1

Re: git grep -P is multiline for negative lookahead/behind

On Mon, Aug 1, 2016 at 2:35 PM, Junio C Hamano <gits...@pobox.com> wrote: > Michael Giuffrida <michae...@chromium.org> writes: > >> Is this expected behavior, and if so, why/where is this documented? > > I do not think "git grep" was designed to do multi-li

git grep -P is multiline for negative lookahead/behind

Negative lookahead/lookbehind with `git grep -P` considers the surrounding lines of an otherwise positive match. This differs from `grep -P` behavior. It does not repro for *positive* lookahead/lookbehind. Example: $ echo -e 'Bar\nBar Baz\nBat' > test.txt && git add test.txt $ git grep -P