Hi,
I noticed that t5561 fails on my machine when compiling with
"make PROFILE=GEN". Luckily, the reason seems to be the test only,
not the tool it is testing.
I tracked it down that far that log_div() (defined in
t/t5561-http-backend.sh but used in t/t556x_common) appends
the given text to the a
o get rid of this behavior, the logfile is not touched at all. This
commit removes log_div() and its calls. The readability-improving
information is kept in the test but filtered out before comparing
it to the actual logfile.
Signed-off-by: Stephan Beyer
---
t/t5560-http-backend-noserver.sh
Hi,
On 09/24/2015 01:24 AM, Jeff King wrote:
>> I noticed that t5561 fails on my machine when compiling with
>> "make PROFILE=GEN". Luckily, the reason seems to be the test only,
>> not the tool it is testing.
>>
>> I tracked it down that far that log_div() (defined in
>> t/t5561-http-backend.sh b
ile at all.
This commit removes log_div() and its calls. The additional information
is kept in the test (for readability reasons) but filtered out before
comparing it to the actual logfile.
Signed-off-by: Stephan Beyer
---
Okay Peff, I added the information to the commit message (in my own
words).
ile at all.
This commit removes log_div() and its calls. The additional information
is kept in the test (for readability reasons) but filtered out before
comparing it to the actual logfile.
Signed-off-by: Stephan Beyer
Acked-by: Jeff King
---
SubmittingPatches says that when there is consensus the
'../../perl/blib/lib';
instead of the flexible environment-based variant
use lib (split(/:/, $ENV{GITPERLLIB}));
which is used in tests written in Perl.
The hard-coded variant is used because the whole performance test
framework does it that way (and GITPERLLIB is not set there).
Signed-off-b
Hi Pranit,
On 12/16/2016 08:00 PM, Pranit Bauva wrote:
> On Wed, Dec 7, 2016 at 1:03 AM, Pranit Bauva wrote:
>>> I don't understand why the return value is int and not void. To avoid a
>>> "return 0;" line when calling this function?
>>
>> Initially I thought I would be using the return value but
Hi Pranit,
On 12/16/2016 08:35 PM, Pranit Bauva wrote:
> On Thu, Nov 17, 2016 at 5:17 AM, Stephan Beyer wrote:
>> On 10/14/2016 04:14 PM, Pranit Bauva wrote:
>>> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
>>> index d84ba86..c542e8b 100644
>>
Hi,
On 12/14/2016 08:29 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>> -/* We will introduce the 'interactive rebase' mode later */
>> static inline int is_rebase_i(const struct replay_opts *opts)
>> {
>> -return 0;
>> +return opts->action == REPLAY_INTERACTIVE_REBASE;
>> }
Hi,
On 12/18/2016 01:18 PM, Kaartic Sivaraam wrote:
> I have found the "Did you mean this?" feature of git as a very good
> feature. I thought it would be even better if it took a step toward by
> asking for a prompt when there was only one alternative to the command
> that was entered.
>
> E.g.
Hi Dscho,
>> However, maintaining more than one directory (like "sequencer" for
>> sequencer state and "rebase-merge" for rebase todo and log) can cause
>> the necessity to be even more careful when hacking on sequencer... For
>> example, the cleanup code must delete both of them, not only one of
Hi Pranit,
On 12/31/2016 11:43 AM, Pranit Bauva wrote:
>>> +
>>> +static int bisect_auto_next(struct bisect_terms *terms, const char *prefix)
>>> +{
>>> + if (!bisect_next_check(terms, NULL))
>>> + return bisect_next(terms, prefix);
>>> +
>>> + return 0;
>>> +}
>>
>> Hmm, the h
Hi,
a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
"git stash pop", he got into a merge conflict. After he resolved the
conflict, he did not know what to do to get the repository into the
wanted state. In his case, it was only "git add "
followed by a "git reset" and a "git
Hi,
On 01/16/2017 01:21 AM, Junio C Hamano wrote:
> I haven't spent enough time to think if it even makes sense to
> "stash" partially, leaving the working tree still dirty. My initial
> reaction was "then stashing away the dirty WIP state to get a spiffy
> clean working environment becomes impos
Hi,
On 01/18/2017 04:41 PM, Marc Branchaud wrote:
> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
>> On Mon, 16 Jan 2017, Stephan Beyer wrote:
>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
>>> "git stash pop", he got into a
> I am tempted to say that there should be a way to somehow forbid use
> of the "-m" option to "git commit" by default, until the user gains
> more familiarity with use of Git.
Since I am using git, I am tempted to say that "git commit -m" should be
abolished. If I tell somebody how to use git, I
Hi,
On 02/13/2017 09:30 AM, Junio C Hamano wrote:
> Linus Torvalds writes:
>
>> On Sat, Feb 11, 2017 at 10:02 AM, Linus Torvalds
>> wrote:
>>>
>>> I've signed off on this, because I think it's an "obvious" improvement,
>>> but I'm putting the "RFC" in the subject line because this is clearly a
Hi,
On 02/17/2017 11:29 PM, Alex Hoffman wrote:
> According to the documentation "git bisect" is designed "to find the
> commit that introduced a bug" .
> I have found a situation in which it does not returns the commit I expected.
> In order to reproduce the problem:
For the others who are too l
Hi,
I saw in the recent "What's cooking" mail that this is still waiting
for review, so I thought I could interfere and help reviewing it from a
non-git-developer point of view.
But only two commits for today. The first one seems fine. The second
one makes me write this mail ;-)
On 10/14/2016 04:
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/bisect.c b/bisect.c
> index 6f512c2..45d598d 100644
> --- a/bisect.c
> +++ b/bisect.c
> @@ -1040,3 +1046,40 @@ int estimate_bisect_steps(int all)
>
> return (e < 3 * x) ? n : n - 1;
> }
> +
> +static int mark_for_removal(const
Hi,
On 10/27/2016 06:59 PM, Junio C Hamano wrote:
> Does any of you (and others on the list) have time and inclination
> to review this series?
Me, currently. ;)
Besides the things I'm mentioning in respective patch e-mails, I wonder
why several bisect--helper commands are prefixed by "bisect"; I
On 11/15/2016 10:40 PM, Junio C Hamano wrote:
> Stephan Beyer writes:
>
>>> +int bisect_clean_state(void)
>>> +{
>>> + int result = 0;
>>> +
>>> + /* There may be some refs packed during bisection */
>>> +
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 6a5878c..1d3e17f 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -24,6 +27,8 @@ static const char * const git_bisect_helper_usage[] = {
> N
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 4254d61..d84ba86 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -84,12 +89,47 @@ static int write_terms(const char *bad, const char *good)
>
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index d84ba86..c542e8b 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -123,13 +123,40 @@ static int bisect_reset(const char *commit)
> return bi
Hi,
I've only got some minors to mention here ;)
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index c542e8b..3f19b68 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -19,9 +19,15 @@ static const char
Hi Pranit,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 3f19b68..c6c11e3 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -20,6 +20,7 @@ static const char * const git_bisect_helper_usage[] = {
>
Hi Pranit,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> Also reimplement `bisect_voc` shell function in C and call it from
> `bisect_next_check` implementation in C.
Please don't! ;D
> +static char *bisect_voc(char *revision_type)
> +{
> + if (!strcmp(revision_type, "bad"))
> +
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 317d671..6a5878c 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
[...]
> +static int bisect_terms(struct bisect_terms *terms, const char **argv, int
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 493034c..c18ca07 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -858,6 +858,23 @@ static int bisect_state(struct bisect_terms *terms,
> const c
Hi Pranit,
this one is hard to review because you do two or three commits in one here.
I think the first commit should be the exit()->return conversion, the
second commit is next and autonext, and the third commit is the pretty
trivial bisect_start commit ;) However, you did it this way and it's
a
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 6a5878c..1d3e17f 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -403,6 +408,205 @@ static int bisect_terms(struct bisect_terms *terms,
> const
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 502bf18..1767916 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -422,6 +425,7 @@ static int bisect_next(...)
> {
> int res, no_checkout;
On 11/20/2016 09:01 PM, Stephan Beyer wrote:
> First, replace the current set_terms() by
>
> static void set_terms(struct bisect_terms *terms, const char *bad,
> const char *good)
> {
> terms->term_good = xstrdup
Hi Pranit,
in this mail I review the "second part" of your patch: the transition of
bisect_next and bisect_auto_next to C.
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 1d3e17f..fcd7574 100644
> --- a/builtin/bisect--helper.
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> Reimplement the `bisect_state` shell function in C and also add a
> subcommand `--bisect-state` to `git-bisect--helper` to call it from
> git-bisect.sh .
>
> Using `--bisect-state` subcommand is a temporary measure to port shell
> function to C so
Okay Pranit,
this is the last patch for me to review in this series.
Now that I have a coarse overview of what you did, I have the general
remark that imho the "terms" variable should simply be global instead of
being passed around all the time.
I also had some other remarks but I forgot them...
Hey Pranit,
On 12/06/2016 10:14 PM, Pranit Bauva wrote:
>>> +
>>> + if (argc == 0) {
>>> + printf(_("Your current terms are %s for the old state\nand "
>>> +"%s for the new state.\n"), terms->term_good,
>>> +terms->term_bad);
>>
>> Very minor
Hey Pranit,
On 12/07/2016 12:02 AM, Pranit Bauva wrote:
>>> +static int bisect_replay(struct bisect_terms *terms, const char *filename)
>>> +{
>>> + struct strbuf line = STRBUF_INIT;
>>> + struct strbuf word = STRBUF_INIT;
>>> + FILE *fp = NULL;
>>
>> (The initialization is not necessa
Hi Pranit and Christian and Lars ;)
On 12/07/2016 12:02 AM, Pranit Bauva wrote:
> On Tue, Nov 22, 2016 at 6:19 AM, Stephan Beyer wrote:
>> Okay Pranit,
>>
>> this is the last patch for me to review in this series.
>>
>> Now that I have a coarse overview of
Hi Pranit,
On 12/06/2016 11:40 PM, Pranit Bauva wrote:
> On Tue, Nov 22, 2016 at 5:42 AM, Stephan Beyer wrote:
>> On 10/14/2016 04:14 PM, Pranit Bauva wrote:
>>> +static int bisect_state(struct bisect_terms *terms, const char **argv,
>>> + int a
Hi,
On 12/06/2016 07:58 PM, Junio C Hamano wrote:
> I was burned a few times with this in the past few years, but it did
> not irritate me often enough that I didn't write it down. But I
> think this is serious enough that deserves attention from those who
> were involved.
>
> A short reproducti
Hi,
On 12/07/2016 09:04 PM, Junio C Hamano wrote:
> Stephan Beyer writes:
>
>> [1] By the way: git cherry-pick --quit, git rebase --forget ...
>> different wording for the same thing makes things unintuitive.
>
> It is not too late to STOP "--forget" from ge
;, instead she just has to check the HEAD.
Signed-off-by: Stephan Beyer
---
builtin/am.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/am.c b/builtin/am.c
index 7cf40e6f2..826f18ba1 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -2134,7 +2134,7 @@ static int saf
single-pick case because
it is handled differently.
Signed-off-by: Stephan Beyer
---
sequencer.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index 30b10ba14..c9b560ac1 100644
--- a/sequencer.c
+++ b/sequencer.c
@
Signed-off-by: Stephan Beyer
---
t/t3510-cherry-pick-sequence.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index 7b7a89dbd..372307c21 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick
Signed-off-by: Stephan Beyer
---
Okay let's give it a try. Some minor things that I found
are also in this patchset (patch 01, 02 and 05).
The branch can also be found on
https://github.com/sbeyer/git/commits/sequencer-abort-safety
builtin/am.c | 2 +-
1 file changed, 1 insertion(
This function is used only once, for the removal of the
directory. It is not used for the creation of the directory
nor anywhere else.
Signed-off-by: Stephan Beyer
---
sequencer.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index c9b560ac1
Hi,
I'm a little afraid of feeding Parkinson's law of triviality here, but... ;)
On 12/08/2016 06:27 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> On Wed, 7 Dec 2016, Stephan Beyer wrote:
>>
>>> diff --git a/sequencer.c b/sequencer.c
The test expects failure because it is a current breakage
reported by Junio C Hamano.
Signed-off-by: Stephan Beyer
---
t/t3510-cherry-pick-sequence.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index
Signed-off-by: Stephan Beyer
---
builtin/am.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/am.c b/builtin/am.c
index 6981f42ce..7cf40e6f2 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -2124,7 +2124,7 @@ static int safe_to_abort(const struct am_state *state
;, instead she just has to check the HEAD.
Signed-off-by: Stephan Beyer
---
builtin/am.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/am.c b/builtin/am.c
index 7cf40e6f2..826f18ba1 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -2134,7 +2134,7 @@ static int saf
single-pick case because
it is handled differently.
Signed-off-by: Stephan Beyer
---
sequencer.c | 48 +
t/t3510-cherry-pick-sequence.sh | 2 +-
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
ind
This function is used only once, for the removal of the
directory. It is not used for the creation of the directory
nor anywhere else.
Signed-off-by: Stephan Beyer
---
sequencer.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 35c158471
Hi Junio,
On 12/09/2016 07:07 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>> Having the same operation with different names only increases git
>> reputation of bad/inconsistent UI. Either forget is renamed to quit,
>> or vice versa. I prefer forget, but the decision is yours and the
>> communi
On 12/09/2016 08:24 PM, Stephan Beyer wrote:
> t3510 also shows another use-case for --quit: the title says it all:
> "cherry-pick --quit" to "cherry-pick --abort"
I should've read what I actually pasted.
I wanted to paste: '--quit keeps HEAD and conflicte
On 12/10/2016 09:04 PM, Jeff King wrote:
> On Sat, Dec 10, 2016 at 08:56:26PM +0100, Christian Couder wrote:
>
>>> +static int rollback_is_safe(void)
>>> +{
>>> + struct strbuf sb = STRBUF_INIT;
>>> + struct object_id expected_head, actual_head;
>>> +
>>> + if (strbuf_read_file(&
Hi Ariel,
On 12/09/2016 07:26 PM, Ariel wrote:
> On Wed, 7 Dec 2016, Duy Nguyen wrote:
>> We could improve it a bit, suggesting the user to do git add -N. But
>> is there a point of using -p on a new file?
>
> I got into the habit of always using -p as a way of checking my diffs
> before committi
Hi,
On 12/11/2016 02:00 PM, Jeff King wrote:
> On Sat, Dec 10, 2016 at 02:04:33PM -0800, Junio C Hamano wrote:
>> Jeff King writes:
>>> On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:
>>> ...
But it doesn't have to be that way. You could make add -p identical to add
without optio
Hi,
While we're on the topic that "git add -p" should behave like the
"normal" "git add" (not "git add -u"): what about unmerged changes?
When I have merge conflicts, I almost always use my aliases
"edit-unmerged" and "add-unmerged":
$ git config --global --list | grep unmerged
alias.list-unmerg
Signed-off-by: Stephan Beyer
---
We will also use that function more often later.
bisect.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/bisect.c b/bisect.c
index 76f2445..afdd1c4 100644
--- a/bisect.c
+++ b/bisect.c
@@ -38,6 +38,14 @@ static inline
It makes no sense that the argument for count_distance() and
halfway() is a commit list when only its first commit is relevant.
Signed-off-by: Stephan Beyer
---
This is just some kind of minor code cleanup.
The typical "while at it", you know it, I guess.
bisect.c | 16 -
more patch-related story as
"cover letter material" in these patches.
Btw: I also wondered about the internationalizaton: no string in bisect.c
is marked for translation. Intentionally?
Cheers
Stephan Beyer (16):
bisect: write about `bisect next` in documentation
bisect: add test for
marker ids that do not need to be
cleared afterwards. This speeds up the bisecting process on
large repositories with a huge amount of merges.
Signed-off-by: Stephan Beyer
---
Yaaay, this is our first gain of performance!
My test: ~30 seconds
bisect.c | 29 +++--
1 file
Setting the macro DEBUG_BISECT to 1 enables debugging information
for the bisect algorithm. The code did not compile due to struct
changes.
Signed-off-by: Stephan Beyer
---
bisect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index 06ec54e
We introduce the concept of rising and falling distances
(in addition to a halfway distance).
This will be useful in subsequent commits.
Signed-off-by: Stephan Beyer
---
bisect.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/bisect.c b
The documentation says that when the maximum possible distance
is found, the algorithm stops immediately. That feature is
reestablished by this commit.
Signed-off-by: Stephan Beyer
---
In my tests, I have not seen any gain of performance by
doing this... but it's fast now anyway, who
() for the
"git rev-list --bisect-all" command. All other bisect-related
commands will use compute_relevant_weights().
Signed-off-by: Stephan Beyer
---
bisect.c | 116 ---
1 file changed, 97 insertions(+), 19 deletions(-)
dif
Large repositories with a huge amount of merge commits in the
bisection process could lead to stack overflows in git bisect.
In order to prevent this, this commit uses an *iterative* version
for counting the number of ancestors of a commit.
Signed-off-by: Stephan Beyer
---
In the cover letter I
is known.
Some user message in git-bisect.sh is changed to reflect that
use case. It is also simplified: there is no need to mention
running `bisect start` explicitly, because it can be done
indirectly using `bisect bad`.
Signed-off-by: Stephan Beyer
---
This patch considers the source code
Signed-off-by: Stephan Beyer
---
To be honest: the test could be better, it could be more "targeted",
i.e. the example commit history could be smaller and just consider
all the cases and corner cases and whatever.
However, I made it first to understand the algorithm and verify the
desc
This commit gets rid of the O(#commits) extra overhead of
the best_bisection() function.
Signed-off-by: Stephan Beyer
---
bisect.c | 43 ++-
1 file changed, 18 insertions(+), 25 deletions(-)
diff --git a/bisect.c b/bisect.c
index 827a82a..185a3cf 100644
The total number of commits in a bisect process is a property of
the bisect process. Making this property global helps to make the code
clearer.
Signed-off-by: Stephan Beyer
---
bisect.c | 74 ++--
1 file changed, 39 insertions(+), 35
This is a preparation for subsequent changes.
During a bisection process, we want to augment commits with
further information to improve speed.
Signed-off-by: Stephan Beyer
---
bisect.c | 61 ++---
1 file changed, 30 insertions(+), 31
med to "compute_weight()",
and it also directly sets the computed weight.
Signed-off-by: Stephan Beyer
---
bisect.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/bisect.c b/bisect.c
index 3a3a728..a9387a7 100644
--- a/bisect.c
+++ b/bise
If DEBUG_BISECT is set to 1, bisect does not only show debug
information but also changes the algorithm behavior: halfway()
is always false.
This commit makes the algorithm independent of DEBUG_BISECT.
Signed-off-by: Stephan Beyer
---
bisect.c | 2 --
1 file changed, 2 deletions(-)
diff --git
).
Merge commits from that collection are considered for further visits
as soon as all their parents have been visited.
Their weights are computed using compute_weight().
Each BFS walk ends when the computed weight is falling or halfway.
Signed-off-by: Stephan Beyer
---
In other words: walk the
Hi,
On 02/26/2016 04:09 AM, Junio C Hamano wrote:
> Interesting. So you walk from the bottom commits, incrementing the
> weight while walking on a part of the graph that is single strand of
> pearls, or doing the "count the reachable ones the hard way" when
> you hit a merge [*1*], but either way
Hi Christian,
On 02/26/2016 07:53 AM, Christian Couder wrote:
>> +test_expect_success 'bisect algorithm works in linear history with an odd
>> number of commits' '
>> + git bisect start A7 &&
>> + git bisect next &&
>> + test "$(git rev-parse HEAD)" = "$(git rev-parse A3)" \
>>
Hi,
On 02/26/2016 07:47 PM, Junio C Hamano wrote:
> But I wonder if it is safe and sane to encourage "checking out other
> branches during a bisect session." as you cannot tell what other
> crazy things they will do while on "other branches". I do not think
> we even try to (and I do not think we
Hi,
On 02/27/2016 07:03 PM, Junio C Hamano wrote:
> Stephan Beyer writes:
>
>> This command is also handy when you accidentally checked out another
>> commit during a bisection. It computes the commit for the bisection
>> and checks it out again.
>>
>>
Hi Pranit,
On 03/20/2016 07:50 PM, Pranit Bauva wrote:
> I have been recently following this series of patches and it seems a
> bit stale. These patches haven't been followed up with improvement
> patches.
I'm on vacation at the moment.
Patchset v1 contains some bugs. So I just updated the branc
Large repositories with a huge amount of merge commits in the
bisection process could lead to stack overflows in git bisect.
In order to prevent this, this commit uses an *iterative* version
for counting the number of ancestors of a commit.
Signed-off-by: Stephan Beyer
---
bisect.c | 55
This is a preparation for subsequent changes.
During a bisection process, we want to augment commits with
further information to improve speed.
Signed-off-by: Stephan Beyer
---
bisect.c | 61 ++---
1 file changed, 30 insertions(+), 31
algorithm works.
This commit generalizes the test t6030 such that it works
even if the bisect algorithm uses its degree of freedom to
choose another commit.
While at it, fix some indentation issues: use tabs instead of
4 spaces.
Signed-off-by: Stephan Beyer
---
t/t6030-bisect-porcelain.sh | 167
revision coincides with the
expected revision.
While at it, the side effect of generating two (temporary) files
is removed.
Signed-off-by: Stephan Beyer
---
t/test-lib-functions.sh | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib
() for the
"git rev-list --bisect-all" command. All other bisect-related
commands will use compute_relevant_weights().
Signed-off-by: Stephan Beyer
---
bisect.c | 116 ---
1 file changed, 97 insertions(+), 19 deletions(-)
dif
is known.
Some user message in git-bisect.sh is changed to reflect that
use case. It is also simplified: there is no need to mention
running `bisect start` explicitly, because it can be done
indirectly using `bisect bad`.
Signed-off-by: Stephan Beyer
---
Notes:
I rephrased the "Bisect
Signed-off-by: Stephan Beyer
---
Notes:
Based on the review by Christian Couder, I use test_cmp_rev()
instead of non-standard test ... -o ...
t/t8010-bisect-algorithm.sh | 155
1 file changed, 155 insertions(+)
create mode 100755 t/t8010
The total number of commits in a bisect process is a property of
the bisect process. Making this property global helps to make the code
clearer.
Signed-off-by: Stephan Beyer
---
bisect.c | 74 ++--
1 file changed, 39 insertions(+), 35
Signed-off-by: Stephan Beyer
---
bisect.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/bisect.c b/bisect.c
index 7996c29..901e4d3 100644
--- a/bisect.c
+++ b/bisect.c
@@ -984,6 +984,8 @@ int bisect_next_all(const char *prefix, int no_checkout)
exit(10
If DEBUG_BISECT is set to 1, bisect does not only show debug
information but also changes the algorithm behavior: halfway()
is always false.
This commit makes the algorithm independent of DEBUG_BISECT.
Signed-off-by: Stephan Beyer
---
bisect.c | 2 --
1 file changed, 2 deletions(-)
diff --git
Setting the macro DEBUG_BISECT to 1 enables debugging information
for the bisect algorithm. The code did not compile due to struct
changes.
Signed-off-by: Stephan Beyer
---
bisect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index 901e4d3
med to "compute_weight()",
and it also directly sets the computed weight.
Signed-off-by: Stephan Beyer
---
bisect.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/bisect.c b/bisect.c
index 2b415ad..a254f28 100644
--- a/bisect.c
+++ b/bise
Now that the documentation talks about bisecting without a good commit
being known, this should also be allowed for "git bisect run".
Signed-off-by: Stephan Beyer
---
Notes:
This is a new patch in the patchset.
git-bisect.sh | 17 -
1 file changed, 12 insert
iciently
good for inclusion. :)
Cheers
1. https://www.mail-archive.com/git@vger.kernel.org/msg86353.html
Stephan Beyer (21):
bisect: write about `bisect next` in documentation
bisect: allow 'bisect run' if no good commit is known
t/test-lib-functions.sh: generalize test_cmp_rev
t: use
marker ids that do not need to be
cleared afterwards. This speeds up the bisecting process on
large repositories with a huge amount of merges.
Signed-off-by: Stephan Beyer
---
bisect.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/bisect.c b
We introduce the concept of rising and falling distances
(in addition to a halfway distance).
This will be useful in subsequent commits.
Signed-off-by: Stephan Beyer
---
bisect.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/bisect.c b
uot; using
compute_weight() when we hit a merge commit.
A traversal ends when the computed weight is falling or halfway.
This way, commits with too high weight to be relevant are never
visited (and their weights are never computed).
Signed-off-by: Stephan Beyer
---
Notes:
I rephrased the comm
test_cmp_rev() from t/test-lib-functions.sh is used to make many
tests clearer.
Signed-off-by: Stephan Beyer
---
Notes:
This change is in some way independent of the bisect topic but
the next patch is based on this (for t6030).
t/t2012-checkout-last.sh | 8 ++--
t
1 - 100 of 139 matches
Mail list logo