22.08.2015, 01:39, Junio C Hamano gits...@pobox.com:
Ivan Chernyavsky campo...@yandex.ru writes:
Another problem is that builtin/branch.c currently does not use
setup_revisions(), so I'll have to hook it there as well.
Heh, you say problem above, but I do not think it is a problem
22.08.2015, 12:19, Ivan Chernyavsky campo...@yandex.ru:
One thing I'm worried about is that git-branch already has option --all. So
we'll get a semantics conflict with setup_revisions() (all branches vs all
refs). This will have to be treated carefully, e.g. retrace and fix effects
17.08.2015, 20:49, Junio C Hamano gits...@pobox.com:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Aug 5, 2015 at 7:47 PM, Ivan Chernyavsky campo...@yandex.ru
wrote:
That is a dangeous thought. I'd understand if it were internally
two step process, i.e. (1) the first pass finds
15.08.2015, 12:19, Duy Nguyen pclo...@gmail.com:
Probably because nobody is interested and steps up to do it. The lack
of response to you mail is a sign. Maybe you can try make a patch? I
imagine it would not be so different from current --contains code, but
this time we need to look into
Dear community,
For some time I'm wondering why there's no --grep option to the git branch
command, which would request to print only branches having specified
string/regexp in their history.
So for example:
$ git branch -r --grep=BUG12345
should be roughly equivalent to following
Sorry for empty subject in the original mail, somehow I've deleted it and
didn't even notice.
05.08.2015, 20:05, Junio C Hamano gits...@pobox.com:
Junio C Hamano gits...@pobox.com writes:
I think people do things like:
git log --all --decorate --grep=...
s/decorate/source/; sorry
6 matches
Mail list logo
