Re: [PATCH 00/16] git bisect improvements
On Tue, Mar 22, 2016 at 3:52 AM, Stephan Beyer wrote: >> If it is okay with you then can I work more upon these >> patches in my GSoC project. > > I'm totally fine with that, of course. :) Thanks! :) I will try and fix the left over bug if time persists. Regards, Pranit Bauva -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] git bisect improvements
On Mon, Mar 21, 2016 at 11:22 PM, Stephan Beyer wrote: > > Also sorry, I am not following the list so I didn't know there was a > GSoC project for bisect. > >> If it is okay with you then can I work more upon these >> patches in my GSoC project. > > I'm totally fine with that, of course. :) You are the Stephan Beyer who did a GSoC project on the sequencer around 2009, right? It's nice to see you back on the list :-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] git bisect improvements
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 branch on github[1] for you which is the state-of-the-art for patchset v2. Note that it also contains an odd bug (which seems to exist before my patches but turns to light after my patches) but I haven't found time to investigate it further before my vacation started. (That's also why I didn't post any updates on that topic to the list.) 1. https://github.com/sbeyer/git/commits/bisect Also sorry, I am not following the list so I didn't know there was a GSoC project for bisect. > If it is okay with you then can I work more upon these > patches in my GSoC project. I'm totally fine with that, of course. :) Thanks, Stephan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] git bisect improvements
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. If it is okay with you then can I work more upon these patches in my GSoC project. These really seem interesting and Git could really benefit from this. Regards, Pranit Bauva On Fri, Feb 26, 2016 at 7:34 AM, Stephan Beyer wrote: > Hi, > > this set of patches provides improvements for git bisect. > > Quick summary of changes > - relevant for users: >- `git bisect next` is documented and motivated >- git bisect implementation becomes much faster > (or: is now working) for big repositories** > - relevant for developers: >- a test for the git bisect algorithm is added >- fix: bisect.c compiles also if DEBUG_BISECT is set > > The ** marked change is the most interesting one. > To be more accurate: the use case is when you want to bisect in a > repository with a huge amount of merge commits (and having these > merge commits relevant for the actual bisect process). > For example, a bisect in the whole git master branch took > ~50 seconds, now it takes ~4 seconds. > > > Note that the patches have finer granularity (especially the performance > improvements are splitted into several preparing commits). > For some patches, there is some 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 the bisect algorithm > bisect: make bisect compile if DEBUG_BISECT is set > bisect: make algorithm behavior independent of DEBUG_BISECT > bisect: get rid of recursion in count_distance() > bisect: use struct node_data array instead of int array > bisect: replace clear_distance() by unique markers > bisect: use commit instead of commit list as arguments when > appropriate > bisect: extract get_distance() function from code duplication > bisect: introduce distance_direction() > bisect: make total number of commits global > bisect: rename count_distance() to compute_weight() > bisect: prepare for different algorithms based on find_all > bisect: use a modified breadth-first search to find relevant weights > bisect: compute best bisection in compute_relevant_weights() > bisect: get back halfway shortcut > > Documentation/git-bisect.txt | 25 +++ > bisect.c | 473 > --- > git-bisect.sh| 15 +- > t/t8010-bisect-algorithm.sh | 162 +++ > 4 files changed, 502 insertions(+), 173 deletions(-) > create mode 100755 t/t8010-bisect-algorithm.sh > > -- > 2.7.1.354.gd492730.dirty > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/16] git bisect improvements
Hi, this set of patches provides improvements for git bisect. Quick summary of changes - relevant for users: - `git bisect next` is documented and motivated - git bisect implementation becomes much faster (or: is now working) for big repositories** - relevant for developers: - a test for the git bisect algorithm is added - fix: bisect.c compiles also if DEBUG_BISECT is set The ** marked change is the most interesting one. To be more accurate: the use case is when you want to bisect in a repository with a huge amount of merge commits (and having these merge commits relevant for the actual bisect process). For example, a bisect in the whole git master branch took ~50 seconds, now it takes ~4 seconds. Note that the patches have finer granularity (especially the performance improvements are splitted into several preparing commits). For some patches, there is some 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 the bisect algorithm bisect: make bisect compile if DEBUG_BISECT is set bisect: make algorithm behavior independent of DEBUG_BISECT bisect: get rid of recursion in count_distance() bisect: use struct node_data array instead of int array bisect: replace clear_distance() by unique markers bisect: use commit instead of commit list as arguments when appropriate bisect: extract get_distance() function from code duplication bisect: introduce distance_direction() bisect: make total number of commits global bisect: rename count_distance() to compute_weight() bisect: prepare for different algorithms based on find_all bisect: use a modified breadth-first search to find relevant weights bisect: compute best bisection in compute_relevant_weights() bisect: get back halfway shortcut Documentation/git-bisect.txt | 25 +++ bisect.c | 473 --- git-bisect.sh| 15 +- t/t8010-bisect-algorithm.sh | 162 +++ 4 files changed, 502 insertions(+), 173 deletions(-) create mode 100755 t/t8010-bisect-algorithm.sh -- 2.7.1.354.gd492730.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
