On Mon, Jun 29, 2015 at 11:32 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Christian Couder christian.cou...@gmail.com writes:
[...]
I find it particularly frustrating that we issue the message:
The merge base %s is bad.\n
This means the bug has been fixed
between %s and
Christian Couder christian.cou...@gmail.com writes:
On Mon, Jun 29, 2015 at 9:34 AM, Matthieu Moy
As a user, when I
discovered git bisect, I was actually surprised that it expected one
particular order between good and bad. I would have expected to be able
to say this is good, this is bad,
Junio C Hamano gits...@pobox.com writes:
I moderately hate to see both from aesthetics point of view, but can
we at least lose --name- prefix?
I changed it to --term- prefix, but I'd rather not drop it. When reading
--old=foo, it is not clear to me whether the meaning should be the
term used
Christian Couder christian.cou...@gmail.com writes:
On Mon, Jun 29, 2015 at 11:32 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
bisect is all about finding the commit where a property has changed,
That is your interpretation of this command. On the man page there is:
git-bisect
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
I moderately hate to see both from aesthetics point of view, but can
we at least lose --name- prefix?
I changed it to --term- prefix, but I'd rather not drop it. When reading
--old=foo, it is not
Matthieu Moy matthieu@grenoble-inp.fr writes:
So, my proposal would be to remove the old/new patch from the series,
and keep the other patches.
What do you think?
Let me answer after reading v11 through.
but now it would be more clear that $name_good and $name_bad is a bad
way to name
Junio C Hamano gits...@pobox.com writes:
I _think_ bulk of Antoine and Matthieu's work can be salvaged/reused
to implement the proposal,
I'm obviously biaised since I already spent time on the bisect terms
idea, and I would hate to see my work and Antoine Louis' thrown away.
But I have to
Christian Couder christian.cou...@gmail.com writes:
On Sun, Jun 28, 2015 at 8:46 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
I understand that the user might make a mistake when marking the initial
commits, but as soon as bisect says
Commit sha1-abbrev is an ancestor of
On Mon, Jun 29, 2015 at 9:34 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Christian Couder christian.cou...@gmail.com writes:
On Sun, Jun 28, 2015 at 8:46 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
I understand that the user might make a mistake when marking the initial
On 06/28/2015 09:32 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I understand that the user might make a mistake when marking the initial
commits, but as soon as bisect says
Commit sha1-abbrev is an ancestor of sha1-abbrev, so I
will look for the commit
On Sat, Jun 27, 2015 at 10:51 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
I would like to remind everybody of my old claim that it would be
possible to teach `git bisect` to infer by itself which term means
older and which term means newer:
On 06/28/2015 08:15 AM, Junio C Hamano wrote:
On Sat, Jun 27, 2015 at 10:51 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
I would like to remind everybody of my old claim that it would be
possible to teach `git bisect` to infer by itself which term means
older and which term means newer:
Michael Haggerty mhag...@alum.mit.edu writes:
I understand that the user might make a mistake when marking the initial
commits, but as soon as bisect says
Commit sha1-abbrev is an ancestor of sha1-abbrev, so I
will look for the commit that caused the transition from
xyzzy to
Michael Haggerty mhag...@alum.mit.edu writes:
On 06/28/2015 09:32 AM, Junio C Hamano wrote:
You just _always_ say good or bad. If something is slow, you
say bad and if something is fast, you say good.
Yes, I think good and bad would usually be perfectly intuitive and
would almost always
On Sun, Jun 28, 2015 at 8:46 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 06/28/2015 08:15 AM, Junio C Hamano wrote:
On Sat, Jun 27, 2015 at 10:51 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
I would like to remind everybody of my old claim that it would be
possible to teach `git
Christian Couder christian.cou...@gmail.com writes:
On Sat, Jun 27, 2015 at 6:25 AM, Junio C Hamano gits...@pobox.com wrote:
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
christian.cou...@gmail.com wrote:
If we don't want to support positional arguments, then I would suggest
supporting
Matthieu Moy matthieu@grenoble-inp.fr writes:
Christian Couder christian.cou...@gmail.com writes:
On Sat, Jun 27, 2015 at 6:25 AM, Junio C Hamano gits...@pobox.com wrote:
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
christian.cou...@gmail.com wrote:
If we don't want to support
On 06/27/2015 06:25 AM, Junio C Hamano wrote:
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
christian.cou...@gmail.com wrote:
If we don't want to support positional arguments, then I would suggest
supporting first the following instead:
git bisect terms --name-good=fast
From: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
Introduction of the git bisect terms command. The user can set his own
terms. It will work exactly like before. The terms must be set before the
start.
Signed-off-by: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
Matthieu Moy matthieu@imag.fr writes:
Matthieu Moy matthieu@imag.fr writes:
+ git bisect terms term-old term-new
I think this is the other way around.
Indeed.
I hate to be saying this, but this is a strong indication that
consistency with start $bad $good... must be broken. If
On Sat, Jun 27, 2015 at 12:25 AM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@imag.fr writes:
Matthieu Moy matthieu@imag.fr writes:
+ git bisect terms term-old term-new
I think this is the other way around.
Indeed.
I hate to be saying this, but this is a strong
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
christian.cou...@gmail.com wrote:
If we don't want to support positional arguments, then I would suggest
supporting first the following instead:
git bisect terms --name-good=fast --name-bad=slow
git bisect terms
On Sat, Jun 27, 2015 at 6:25 AM, Junio C Hamano gits...@pobox.com wrote:
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
christian.cou...@gmail.com wrote:
If we don't want to support positional arguments, then I would suggest
supporting first the following instead:
git bisect
23 matches
Mail list logo
