Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not think scripted
use will be inconvenienced; they will already have to use . or :/ to
be explicit (if they care) since the behavior is
On Thu, Oct 24, 2013 at 12:40 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not think scripted
use will be inconvenienced; they will
On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not think scripted
use will be inconvenienced; they will already
On Fri, Oct 25, 2013 at 11:37 AM, Jeff King p...@peff.net wrote:
On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not
Hi,
it would be nice if grep searched not only in current directory and
subdirectories, but in whole tree.
I know I can use :/ as a pathspec, but since most git commands work
tree, I got used to this and forgot that grep is different.
It's easy to make a mistake and believe that your code does
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
I think there were discussion about how there are several git commands
which do not search in whole tree by default and that it's going to be
changed. I think add is one of such commands. Is 'grep' left
unchanged?
In summary: changing is
Matthieu Moy matthieu@grenoble-inp.fr writes:
In summary: changing is painful. The case of git add was really bad,
since the same command had different behavior depending on the options
given, so it was clearly worth the pain. In the case of git grep, the
current behavior is not _that_
Junio C Hamano gits...@pobox.com writes:
I suspect that it would be too late for 2.0 we want to do sometime
early next year, though.
How would you manage transition from the current behavior? Warning
people to explicitly use . or :/ during some interim period sounds
worse than just switching
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
I suspect that it would be too late for 2.0 we want to do sometime
early next year, though.
How would you manage transition from the current behavior? Warning
people to explicitly use . or :/ during some interim
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
I suspect that it would be too late for 2.0 we want to do sometime
early next year, though.
How would you manage transition from the current behavior? Warning
people to
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
I suspect that it would be too late for 2.0 we want to do sometime
early next year, though.
How would you manage transition from the current
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
I suspect that it would be too late for 2.0 we want to do sometime
early next year, though.
How would you manage transition from the current
On Wed, Oct 23, 2013 at 12:31 PM, Junio C Hamano gits...@pobox.com wrote:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
I suspect that it would be too late for 2.0 we want to do sometime
On Wed, Oct 23, 2013 at 10:43:36PM +0200, Matthieu Moy wrote:
That may be an option. In the case of git add -u, it was a bit more
complicated, since a badly used git add somehow looses data (not very
serious, you may only loos the index). So, saying after the fact oh, by
the way, I messed up
14 matches
Mail list logo
