On May 19, 2015, Stefan Beller wrote : >On Mon, May 18, 2015 at 4:23 PM, Antoine Delaite ><antoine.delaite@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> Hello Git community, >> >> >> We are a team of five students from the ENSIMAG (a french school of engineering and computer science) who are going to contribute to git during a month at least and after if we have the opportunity. We will work under the supervision of Mr. Moy. >> >> >> We are glad to contribute to git and we are looking forward to getting advices and reviews from the git community. It will be a great experience for us as young programmers. >> >> >> We planned to work on « git pull –setupstream » for the first days if nobody is currently working on it and then we thought of finishing the work of elder contributors from the ensimag on : « git bisect fix/unfixed ». > >git pull is being converted from shell to C as part of the >Google Summer of Code (cc'ing Paul Tan who is the >student, and Johannes Schindelin and me who are the >mentors) so there may be some merge conflicts arising >if we go uncoordinated. See a planned timeline of Paul >at [1]. Depending on your timeline, it might be wise to >hold on a bit and then base your contributions on the C >implementation rather than the bash implementation. Thank you for the warning, we will wait for the C implementation then. On May 19, 2015, Stefan Beller wrote : >I am not aware of the scope you're planning to contribute >to within the git bisect fix/unfixed topic, though I'd like >to share a result[2] of a discussion we had some time >ago, on how git bisect can be improved (nobody did it >yet though). On May 19, 2015, Christian Couder wrote : >It's interesting, but the document doesn't really explain what is not >optimal with the current algorithm and why the proposed algorithm is >better. For now we are not planning on heavily modifying the algorithm of git bisect but we are rather planning on fixing an existing patch considering that we are new to the mailing list and patches (though we might have to modify partly the algorithm in the end, we have not really begun to dwelve into the code of git bisect yet). On May 19, 2015, Christian Couder wrote : >Last Autumn I started to work a bit on « git bisect fix/unfixed » (or >more accurately « git bisect old/new ») by applying and reworking a >bit what your Ensimag elders had done. It is not much but maybe it can >help you a bit. > >It is on this branch on my github repo: >[...] >https://github.com/chriscool/git/commits/boldnew2 > Thank you very much, this will be really useful. On a different note, we have started to work on the following points, to get used to the code of Git, writing the tests, documentation... : - A possibility to configure git am so that it uses the option -3way automatically by adding the boolean am.3way in .gitconfig. The conversion from a bash version to a C version is no big matter. - Adding the possibility to use the key-word 'drop' in git rebase -i, it has the same effect as deleting the line (removing the commit) but allows a better control of your actions and reduces the possibility of removing a commit by mistake. We plan to work on the following points : - Adding warning/errors when removing commits by removing the line in git rebase -i. This would be configurable through the variable rebase.dropBehaviour in .gitconfig, it would have 3 states ('ignore', 'warn', 'error'). 'ignore' would be the same behavior as currently, 'warn' would display a warning (the rebase would still proceed) when a commit is removed through line removal and 'error' would stop the rebase instead. - Fixing a patch for git bisect fixed/unfixed as stated earlier. - Working on git pull --set-upstream (similar to what git push --set-upstream does) after the C implementation of git pull. The above list is most likely to change according to the difficulty, the time needed and other parameters. Thanks again, Rémi Galan Alfonso, Rémi Lespinet, Antoine Delaite, Louis Stuber, Guillaume Pagès -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html