Hi,
just to make it also clear in this thread: you can ignore this patch
series in favor of the better patch series by Peff [1] that has found
its way to the mailing list at the same time.
1.
https://public-inbox.org/git/20190905224859.ga28...@sigill.intra.peff.net/
Stephan
On 9/6/19 12:58 AM, Jeff King wrote:
> On Fri, Sep 06, 2019 at 12:53:49AM +0200, Stephan Beyer wrote:
>
>> On 9/6/19 12:48 AM, Jeff King wrote:
>>> On Thu, Sep 05, 2019 at 10:24:59AM +0200, Stephan Beyer wrote:
>>>
>>>> Compiler heuristics for detect
On 9/6/19 12:48 AM, Jeff King wrote:
> On Thu, Sep 05, 2019 at 10:24:59AM +0200, Stephan Beyer wrote:
>
>> Compiler heuristics for detection of potentially uninitialized variables
>> may change between compiler versions and enabling link-time optimization
>> may fi
This is done by removing namelen at all. It is only used once
and simply strlen(name), hence we use strlen(name) directly.
Suggested-by: Jeff King
Signed-off-by: Stephan Beyer
---
t/helper/test-read-cache.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/helper/test
red.
This patch sets index_pos to zero on the first run to silence the warning.
Signed-off-by: Stephan Beyer
---
pack-objects.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/pack-objects.c b/pack-objects.c
index 52560293b6..726147a75d 100644
--- a/pack-objects.c
+++ b/pack
This prevents a potential segmentation fault.
Signed-off-by: Stephan Beyer
---
builtin/am.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/am.c b/builtin/am.c
index 1aea657a7f..71da34913c 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1272,7 +1272,8 @@ static
R=1 switch (which sets -Werror).
Signed-off-by: Stephan Beyer
---
bulk-checkin.c | 2 ++
fast-import.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 39ee7d6107..87fa28c227 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -20
in the most naïve way. This allows to compile git using the
DEVELOPER=1 switch (which sets -Werror) and using the -flto flag.
Signed-off-by: Stephan Beyer
---
builtin/am.c | 2 +-
builtin/pack-objects.c | 2 +-
bulk-checkin.c | 2 ++
fast-import.c | 3
On 01/24/2018 10:19 PM, Isaac Hier wrote:
> Thanks for your interest! This patch is based on the cmake-build
> branch of https://github.com/isaachier/git, but the full history is on
> the cmake branch (squashed it for easier readability). Hope that
> helps.
Thanks. I use the cmake branch because I
Hi Isaac,
On 01/24/2018 02:45 PM, Isaac Hier wrote:
> I realize this is a huge patch, but does anyone have feedback for the
> general idea?
Thank you very much. I am *personally* interested in this due to several
reasons (which are mostly that I am used to CMake and when I do
something on the Git
On 11/11/2017 03:34 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>>> "You use it by first telling it a "bad" commit that is known to
>>> contain the bug, and a "good" commit that is known to be before the
>>> bug was introduced."
>>
>> Yeah, 'and at least a "good" commit' would be bette
oviding a command now
results in an error.
Signed-off-by: Stephan Beyer
---
git-bisect.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/git-bisect.sh b/git-bisect.sh
index 0138a8860..a69e43656 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -450,6 +450,8 @@ bisect_replay () {
bisect_run
Hi,
On 11/11/2017 03:38 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> On Sat, Nov 11, 2017 at 12:42 PM, Robert P. J. Day
>> wrote:
>>>
>>> the man page for "git bisect" makes no mention of "git bisect next",
>>> but the script git-bisect.sh does:
>>
>> Yeah the following patch was
Hi again ;)
On 10/27/2017 05:06 PM, Pranit Bauva wrote:
> @@ -44,6 +46,11 @@ static void set_terms(struct bisect_terms *terms, const
> char *bad,
> terms->term_bad = xstrdup(bad);
> }
>
> +static const char *voc[] = {
> + "bad|new",
> + "good|old"
> +};
> +
> /*
> * Check whet
> @@ -21,6 +22,7 @@ static const char * const git_bisect_helper_usage[] = {
> N_("git bisect--helper --bisect-reset []"),
> N_("git bisect--helper --bisect-write
> []"),
> N_("git bisect--helper --bisect-check-and-set-terms
> "),
> + N_("git bisect--helper --bisect-nex
Hi,
another minor:
On 10/27/2017 05:06 PM, Pranit Bauva wrote:
> @@ -264,6 +271,79 @@ static int check_and_set_terms(struct bisect_terms
> *terms, const char *cmd)
> return 0;
> }
>
> +static int mark_good(const char *refname, const struct object_id *oid,
> + int flag,
Hi,
> + return error(_("unrecognised option: '%s'"), arg);
Please write "unrecogni_z_ed".
Since the string for translation changed from
"unrecognised option: '$arg'"
to
"unrecognised option: '%s'"
anyway, it does not result in further work for the translators
On 10/27/2017 05:06 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 0f9c3e63821b8..ab0580ce0089a 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
[...]
> +static int bisect_terms(struct bisect_terms *terms, const char **argv
On 10/30/2017 02:38 PM, Stephan Beyer wrote:
> This last change is not necessary. You never use "res".
Whoops, ignore this!
I compared old and new diff and mixed something up, it seems.
Sorry,
Stephan
Also just a minor in addition to the others:
> @@ -153,9 +241,10 @@ int cmd_bisect__helper(int argc, const char **argv,
> const char *prefix)
> WRITE_TERMS,
> BISECT_CLEAN_STATE,
> CHECK_EXPECTED_REVS,
> - BISECT_RESET
> + BISECT_R
Hi Pranit,
On 10/27/2017 05:06 PM, Pranit Bauva wrote:
> A big thanks to Stephan and Ramsay for patiently reviewing my series and
> helping me get this merged.
You're welcome. ;)
In addition to the things mentioned by the other reviewers, only a minor
thing:
> diff --git a/builtin/bisect--helpe
Hi,
On 10/02/2017 01:37 AM, Junio C Hamano wrote:
> diff --git a/.clang-format b/.clang-format
> index 56822c116b..7670eec8df 100644
> --- a/.clang-format
> +++ b/.clang-format
> @@ -1,4 +1,8 @@
> -# Defaults
> +# This file is an example configuration for clang-format 5.0.
> +#
> +# Note that this
On 10/01/2017 10:30 PM, Junio C Hamano wrote:
> I think we do want the endgame to be that .clang-format defines how
> the code should look like. It's that we are not there yet, and I
> think that is what we should say in this comment.
>
> Note that this style definition does not yet quite r
beginning of the file.
Additionally, the working clang-format version is mentioned because the config
directives change from time to time (in a compatibility-breaking way).
Signed-off-by: Stephan Beyer
---
Notes:
On 10/01/2017 04:45 AM, Junio C Hamano wrote:
> it makes as if a random patch
beginning of the file.
Additionally, the working clang-format version is mentioned because the config
directives change from time to time (in a compatibility-breaking way).
Signed-off-by: Stephan Beyer
---
Notes:
On 09/30/2017 12:45 AM, Jonathan Nieder wrote:
> Sounds good to me. Care to s
Hi,
On 09/29/2017 08:40 PM, Jonathan Nieder wrote:
> Going forward, is there an easy way to preview the effect of this kind
> of change (e.g., to run "make style" on the entire codebase so as to be
> able to compare the result with two different versions of
> .clang-format)?
I just ran clang-form
Hi Pranit,
On 09/29/2017 08:49 AM, Pranit Bauva wrote:
> It has been a long time since this series appeared on the mailing list.
> The previous version v15[1] is now split into many parts and I am
> sending the first part right now, will focus on getting this merged and
> then send out the next pa
On 08/31/2017 08:36 AM, Kevin Daudt wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>> I have a file
>>
>> app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:
On 08/23/2017 07:29 PM, Stefan Beller wrote:
> On Wed, Aug 23, 2017 at 8:19 AM, Stephan Beyer wrote:
>> On 08/23/2017 04:40 PM, Johannes Schindelin wrote:
>>> These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe
>>> you want to do that, too?
>&g
Hi,
On 08/23/2017 04:40 PM, Johannes Schindelin wrote:
> These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe
> you want to do that, too?
That's a very valuable hint, thank you very much!
Best
Stephan
Hi,
On 08/23/2017 01:08 AM, Stefan Beller wrote:
> The editor opened proposing the following instruction sheet,
> which in my opinion is buggy:
>
> pick 1234 some commit
> exec make
> pick 2345 another commit
> exec make
> pick 3456 third commit
> # pick 4567 empty commit
Hi,
On 03/29/2017 10:02 PM, Alex Hoffman wrote:
> Any news about this patch?
Haha nice, your initial patch is the same as mine (but mine was part of
a bigger patch series and the v3 is probably going to have one less commit):
https://public-inbox.org/git/1456452282-10325-4-git-send-email-s-be...@
Hi Pranit,
On 03/04/2017 12:26 AM, Junio C Hamano wrote:
> --
> [Stalled]
[...]
>
> * pb/bisect (2017-02-18) 28 commits
> - fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C
> - bisect--helper: remove the dequote in bisec
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,
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
> 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 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
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,
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 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 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,
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,
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 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 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,
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
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 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
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(&
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
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
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
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
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
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
;, 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
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
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 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 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
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
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
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...
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
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.
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,
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;
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 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 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,
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 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 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,
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,
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,
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 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
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/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
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,
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 04/15/2016 10:00 PM, Junio C Hamano wrote:
> Stephan Beyer writes:
>
>> test_cmp_rev() took exactly two parameters, the expected revision
>> and the revision to test. This commit generalizes this function
>> such that it takes any number of at least two revisions:
On 04/10/2016 09:16 PM, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Portabily:
>> Since yesterday/yesterweek the usage of hard-coded
>> #!/bin/sh had shown to be problematic
>
> That is not a new revelation, though ;-) It is just that these are
> problematic to those on minority pl
This commit gets rid of the O(#commits) extra overhead of
the best_bisection() function.
Signed-off-by: Stephan Beyer
---
Notes:
I made the best_bisection structure be allocated on the heap
because it will get free()d when the code is invoked by
git rev-list --bisect ... The old
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
---
Notes:
I plugged a memory leak here.
bisect.c | 18 +-
1 file changed, 13 insertions
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
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
---
bisect.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/bisect.c b/bisect.c
index 4209c75
Signed-off-by: Stephan Beyer
---
bisect.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/bisect.c b/bisect.c
index 2c1102f..cfd406c 100644
--- a/bisect.c
+++ b/bisect.c
@@ -38,6 +38,14 @@ static inline struct node_data *node_data(struct commit
*elem
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
1 - 100 of 139 matches
Mail list logo
