Proposal
Hello , My name is Sgt Major John Dailey. I am here in Afghanistan , I came upon a project I think we can work together on. I and my partner (1st Lt. Daniel Farkas ) have the sum of $15 Million United State Dollars which we got from a Crude Oil Deal in Iraq before he was killed by an explosion while on a Vehicle Patrol. Due to this incident, I want you to receive these funds on my behalf as far as I can be assured that my share will be safe in your care until I complete my service here in Afghanistan and come over to meet with you. Since we are working here for an Official capacity, I cannot keep these funds hence by contacting you. I Guarantee and Assure you that this is risk free. I just need your acceptance to help me receive these funds and all is done. Since the death of my partner, my life is not guaranteed here anymore, so I have decided to share these funds with you. I am also offering you 40% of this money for the assistance you will give to me. One passionate appeal I will make to you, is for you not to discuss this matter with anybody, should you have reasons to reject this offer, please and please destroy this message as any leakage of this information will be too bad for us as soldiers here in Afghanistan. I do not know how long we will remain here, and I have been shot, wounded and survived so many suicide bomb attacks, this and other reasons have prompted me to reach out to you for help. I honestly want this matter to be resolved immediately, please contact me as soon as possible on my e-mail address which is my only way of communication. Yours In Service, SGM John Dailey
Proposal
I wish to discuss a proposal with you, please contact me via email for more details immediately.
Greetings in the name of God, Business proposal in God we trust
Greetings in the name of God Dear Friend Greetings in the name of God,please let this not sound strange to you for my only surviving lawyer who would have done this died early this year.I prayed and got your email id from your country guestbook. I am Mrs Suran Yoda from London,I am 72 years old,i am suffering from a long time cancer of the lungs which also affected my brain,from all indication my conditions is really deteriorating and it is quite obvious that,according to my doctors they have advised me that i may not live for the next two months,this is because the cancer stage has gotten to a very bad stage.I am married to (Dr Andrews Yoda) who worked with the Embassy of United Kingdom in South Africa for nine years,Before he died in 2004. I was bred up from a motherless babies home and was married to my late husband for Thirty years without a child,my husband died in a fatal motor accident Before his death we were true believers.Since his death I decided not to re-marry,I sold all my inherited belongings and deposited all the sum of $6.5 Million dollars with Bank in South Africa.Though what disturbs me mostly is the cancer. Having known my condition I decided to donate this fund to church,i want you as God fearing person,to also use this money to fund church,orphanages and widows,I took this decision,before i rest in peace because my time will so on be up. The Bible made us to understand that blessed are the hands that giveth. I took this decision because I don`t have any child that will inherit this money and my husband's relatives are not Christians and I don`t want my husband hard earned money to be misused by unbelievers. I don`t want a situation where these money will be used in an ungodly manner,hence the reason for taking this bold decision.I am not afraid of death hence i know where am going.Presently,I'm with my laptop in a hospital here in London where I have been undergoing treatment for cancer of the lungs. As soon as I receive your reply I shall give you the contact of the Bank.I will also issue you a letter of authority that will prove you as the new beneficiary of my fund.Please assure me that you will act accordingly as I stated.Hoping to hear from you soon. Remain blessed in the name of the Lord. Yours in Christ, Mrs Suran Yoda
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you,i asked before and i still await your positive response thanks.
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you i asked before and i still await your positive response thanks
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you i asked before and i still await your positive response thanks
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you i asked before and i still await your positive response thanks
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you i asked before and i still await your positive response thanks
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you i asked before and i still await your positive response thanks
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you i asked before and i still await your positive response thanks
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you i asked before and i still await your positive response thanks
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you.
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you.
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you.
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you.
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you.
Proposal
Hello I have a business proposal of mutual benefits i would like to discuss with you.
Business Proposal
I am Sgt.Brenda Wilson, originally from Lake Jackson Texas USA.I personally made a special research and I came across your information. I am presently writing this mail to you from U.S Military base Kabul Afghanistan I have a secured business proposal for you. Reply for more details via my private E-mail ( brendawilson...@hotmail.com )
Proposal
-- Good day, i know you do not know me personally but i have checked your profile and i see generosity in you, There's an urgent offer attach to your name here in the office of Mr. Fawaz KhE. Al Saleh Member of the Board of Directors, Kuveyt Türk Participation Bank (Turkey) and head of private banking and wealth management Regards, Mr. Fawaz KhE. Al Saleh
BUSINESS INTEREST/ PROPOSAL
Hello RE:BUSINESS INQUIRY/ PROPOSAL How are you doing today, i hope this mail finds you in a good and convenient position! My name is ZHAO DONG. I am the senior manager for Procurement, Hong Kong Refining Company (Sinopec Group Inc) I have been mandated to source crude oil from Libya for supply to our refineries. However, I have been able to establish a good relationship with the senior management of the Azzawya Oil Refining Company, Libya. I am now looking for a competent middle man to stand in between my company, Hong Kong Refining Company and the Azzawya Oil Refining Company of Libya for the sale and purchase of 2 Million Barrels Monthly for 36 Months. This is in order to take home a commission of USD5 to USD7 per barrel. This amount is payable to the middle man as commission. On your response I will give you further details you may need and proof of my identity. Kindly reply directly to zhaodong...@gmail.com or zhaodon...@yandex.com for further vital details you may need. Best Regards ZHAO DONG
Proposal
-- Hello I have been trying to contact you. Did you get my business proposal? Best Regards, Miss.Victoria Mehmet
Lucrative Business Proposal
-- Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Quatif Group of Companies
Lucrative Business Proposal
-- Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Quatif Group of Companies
Proposal
-- Hello I have been trying to contact you. Did you get my business proposal? Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turke
Proposal
-- Hello I have been trying to contact you. Did you get my business proposal? Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turke
Proposal
-- Hello I have been trying to contact you. Did you get my business proposal? Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turke
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Business Proposal
Hello, I am Mr. Alan Austin, I am currently working with Credit suisse Bank London. I saw your contact during my private search and I have a deep believe that you will be very honest, committed and capable of assisting in this business venture. I am an account officer to late Dr. Manzoor Hassan who died with his entire family in Syria, It is based on this that I am contacting you to stand as the beneficiary to my late client so that his funds in our custody will be released and paid to you as the beneficiary to the deceased. It is important you respond back to me with your full name and address, including your direct phone number to enable me give you full details of this transaction and more information about my late client who left huge amount of money in our Bank. I will provide you with all the necessary information, documents and proof to legally back up the claim from the different offices concerned for the smooth transfer of the fund to any of your accounts as the true beneficiary. Yours Sincerely, Mr. Alan Austin
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for our mutual benefit please let me know if you are interested. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for our mutual benefit please let me know if you are interested. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Dear Greetings to you, please I have a very important business proposal for our mutual benefit, please let me know if you are interested. Best Regards, Miss. Zeliha ömer Faruk Caddesi Kristal Kule Binasi No:215
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Proposal
Hello Greeetings to you please did you get my previous email regarding my investment proposal last week friday ? MS.Zeliha ömer faruk zeliha.omer.fa...@gmail.com
business Proposal / Geschäftsvorschlag
I have a business Proposal for you, contact me directly This business has a cash involvement of $250,000,000.00 Anders Karlsson Ich habe einen Geschäftsvorschlag für Sie, kontaktieren Sie mich direkt Dieses Unternehmen hat eine Beteiligung von $ 250.000.000,00 - [] Anders Karlsson
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally so i will give you a video call to explain more but did you get my previous email ? Let me know asap. Best Regards, Miss Melisa Mehmet Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Re: [GSoC] Convert “git stash” to builtin proposal
On Sun, Mar 25, 2018 at 4:38 PM, Paul-Sebastian Ungureanu <ungureanupaulsebast...@gmail.com> wrote: > On 25.03.2018 12:46, Christian Couder wrote: >> >> On Sat, Mar 24, 2018 at 8:31 PM, Paul-Sebastian Ungureanu >> <ungureanupaulsebast...@gmail.com> wrote: >>> >>> On 23.03.2018 19:11, Christian Couder wrote: >>> >>>>> * Ensure that no regression occurred: considering that there are plenty >>>>> of tests and that I have a good understanding of the function, this >>>>> should be a trivial task. >>>> >>>> There are a lot of things that the test suite doesn't test. >>> >>> Hopefully, by first adding new tests, any eventual bug will be spotted. >> >> I was thinking about things like memory leaks that tests cannot easily >> spot.> > > I will do my best and follow best practices in order to avoid any memory > leaks. However, to make sure that my code is really leak free, I will use > Valgrind, which is already integrated with the testing framework. Yeah, but it's still not so easy even with valgrind for a number of reasons. For example it's difficult to test all the error paths, and there are also some memory leaks that we accept when we know that they happen just once and that we are going to exit soon anyway when we should free the memory. >> Ok. Feel free to resend another version of your proposal. > > Sorry for not sending the whole proposal again. I decided to send only the > changed parts because the proposal is quite big and I wanted to avoid > sending the same thing over and over again. It's up to you, but but fewer people might review it. > One thing I did not mention in the previous reply was that I also added a > new paragraph to "Benefits to community" about 'git stash' being slow on > Windows for a lot of users. I consider this alone to be a very good > justification for this project and doing this project will be very > beneficial for the Windows users. Sure.
Re: [GSoC] Convert “git stash” to builtin proposal
Hi Paul, On Sun, 25 Mar 2018, Paul-Sebastian Ungureanu wrote: > One thing I did not mention in the previous reply was that I also added > a new paragraph to "Benefits to community" about 'git stash' being slow > on Windows for a lot of users. I consider this alone to be a very good > justification for this project and doing this project will be very > beneficial for the Windows users. Yes! Thank you, Johannes
Re: [GSoC] Convert “git stash” to builtin proposal
On 25.03.2018 12:46, Christian Couder wrote: On Sat, Mar 24, 2018 at 8:31 PM, Paul-Sebastian Ungureanu <ungureanupaulsebast...@gmail.com> wrote: On 23.03.2018 19:11, Christian Couder wrote: * Ensure that no regression occurred: considering that there are plenty of tests and that I have a good understanding of the function, this should be a trivial task. There are a lot of things that the test suite doesn't test. Hopefully, by first adding new tests, any eventual bug will be spotted. I was thinking about things like memory leaks that tests cannot easily spot.> I will do my best and follow best practices in order to avoid any memory leaks. However, to make sure that my code is really leak free, I will use Valgrind, which is already integrated with the testing framework. Ok. Feel free to resend another version of your proposal. Sorry for not sending the whole proposal again. I decided to send only the changed parts because the proposal is quite big and I wanted to avoid sending the same thing over and over again. One thing I did not mention in the previous reply was that I also added a new paragraph to "Benefits to community" about 'git stash' being slow on Windows for a lot of users. I consider this alone to be a very good justification for this project and doing this project will be very beneficial for the Windows users. Best regards, Paul Ungureanu
Re: [GSoC] Convert “git stash” to builtin proposal
On 23.03.2018 19:06, Johannes Schindelin wrote: [... proposal ...] This is a pretty good proposal. The initial draft at converting `stash list` is a good start (it will need to be converted to avoid spawning an extra process, but that is something we can do incrementally, together). Thank you for your kind words. It feels good to see other people appreciate my work. It is a strong incentive to keep going on. I made a few adjustments and I hope that the final version will be better. Best regards, Paul Ungureanu
Proposal
I have a very profitable business for you
Re: [GSoC] Convert “git stash” to builtin proposal
On Sat, Mar 24, 2018 at 8:31 PM, Paul-Sebastian Ungureanu <ungureanupaulsebast...@gmail.com> wrote: > On 23.03.2018 19:11, Christian Couder wrote: > >>> * Ensure that no regression occurred: considering that there are plenty >>> of tests and that I have a good understanding of the function, this >>> should be a trivial task. >> >> There are a lot of things that the test suite doesn't test. > > Hopefully, by first adding new tests, any eventual bug will be spotted. I was thinking about things like memory leaks that tests cannot easily spot. >>> * In the end, an analysis based on performance can be made. >>> Benchmarking the script will be done by recording the running time >>> given a large set of diversified tests that cover all the >>> functionalities, before and after conversion. The new commands should >>> run faster just because they were written in C, but I expect to see >>> even more improvements. >> >> If you want to do benchmarks, you might want to add performance tests >> into t/perf. > > That is great. I will surely make use of the existent testing framework to > do benchmarks. Good. >>> ## Example of conversion (for “git stash list”) >>> -- >>> To test my capabilities and to be sure that I am able to work on a >>> project of this kind, I tried to convert “git stash list” into a built- >>> in. The result can be found below in text-only version or at the Github >>> link. >> >> I think it would be better if it was sent as a patch (maybe an RFC >> patch) to the mailing list and add the link to the patch email in the >> maling list archive to your proposal. > > I sent it as a [RFC] patch to the mailing list and included it in the > proposal. > > <https://public-inbox.org/git/20180324182313.13705-1-ungureanupaulsebast...@gmail.com> Nice. >> It could be useful if you described a bit more how you could (re)use >> the work that has already been made. >> >> In the rest of your proposal it looks like you are starting from >> scratch, which is a bit strange if a lot of progress has already been >> made. > > The patches about converting ‘git stash’ are a great starting point and I > will definitely use them. Each time I start converting a new command I will > first take a look at what other patches there are, evaluate them and if I > consider the patch to be good enough I will continue my work on top of that > patch. Otherwise, I will start from scratch and that patch will only serve > for comparison. > > One other resource that is of great importance is git itself. I can learn > how a builtin is structured and how it is built by considering examples the > other Git commands. Having a similar coding standard used, the codebase will > be homogeneous and hopefully easier to maintain. > > Another important resource are commands that are Google Summer of Code > projects from previous years (2016 and 2017) which had as purpose to convert > “git bisect” and “git submodule”. I can always take a look at the patches > they submitted and read their code reviews to avoid making same mistakes > they did. Nice. >> It is probably better especially for reviewers and more common to work >> in small batches, for example to send a patch series converting a few >> related commands, then to start working on the next small batch of >> commands in another patch series while improving the first patch >> series according to reviews. >> >> Also we ask GSoC students to communicate publicly every week about >> their project for example by writing a blg post or sending a report to >> the mailing list. > > Noted. > >>> ## Git contributions >>> -- >>> My first contribution to Git was to help making “git tag --contains >>> ” les chatty if is invalid. Looking over the list of available >>> microprojects, there were a couple of microprojects which got my >>> attention, but I picked this up because it seemed to be a long-standing >>> bug (I noticed it was approached by students in 2016, 2017 and now in >>> 2018). Thanks to the code reviews from the mailing list, after a few >>> iterations I succeeded in coming up with a patch that not only fixed >>> the mentioned problem, but also a few others that were having the same >>> cause. >>> >>> It got merged in the proposed updates branch. >> >> What is its status in Junio's "What's cooking in Git" emails? > > It is now in the ‘next’ branch of the Git repository. > > I updated the proposal, in which I included these ideas and some additional > examples. Thank you a lot! Ok. Feel free to resend another version of your proposal. Thanks.
Re: [RFC v3][GSoC] Project proposal: convert interactive rebase to C
Hi, this is the first draft of my proposal. --- ABSTRACT git is a modular source control management software, and all of its subcommands are programs on their own. A lot of them are written in C, but a couple of them are shell or Perl scripts. This is the case of =git-rebase--interactive= (or interactive rebase), which is a shell script. Rewriting it in C would improve its performance, its portability, and maybe its robustness. ABOUT `git-rebase` AND `git-rebase--interactive` git-rebase allows to re-apply changes on top of another branch. For instance, when a local branch and a remote branch have diverged, git-rebase can re-unify them, applying each change made on the local branch on top of the remote branch. git-rebase--interactive is used to reorganize commits by reordering, rewording, or squashing them. To achieve this purpose, =git= opens the list of commits to be modified in a text editor (hence the interactivity), as well as the actions to be performed for each of them. PROJECT GOALS Back in 2016, Johannes Schindelin discussed[1] about retiring git-rebase.sh (described here as a “hacky shell script”) in favor of a builtin. He explained that, as it’s only a command-line parser for git-rebase--am.sh, git-rebase--interactive.sh, and git-rebase--merge.sh, these 3 scripts should be rewritten first. The goal of this project is to rewrite git-rebase--interactive.sh in C, for multiple reasons : Performance improvements Shell scripts are inherently slow. When Johannes Schindelin began to rewrite some parts of git-rebase--interactive in C, its performance increased from 3 to 5 times, depending on the platform[2]. That’s because each command is a program by itself. So, for each command, the shell interpreter has to spawn a new process and to load a new program (with fork() and exec() syscalls), which is an expensive process. Those commands can be other git commands. Sometimes, they are wrappers to call internal C functions (eg. git-rebase--helper), something shell scripts can’t do natively. These wrappers basically parse the parameters, then start the appropriate function, which is obviously slower than just calling a function from C. Other commands can be POSIX utilities (eg. sed, cut, etc.). They have their own problems (speed aside), namely portability. Portability improvements Shell scripts often relies on many of those POSIX utilities, which are not necessarily natively available on all platforms (most notably, Windows), or may have more or less features depending on the implementation. Although C is not perfect portability-wise, it’s still better than shell scripts. For instance, the resulting binaries will not necessarily depend on third-party programs or libraries. RISKS Of course, rewriting a piece of software takes time, and can lead to regressions (ie. new bugs). To mitigate that risk, I should understand well the functions I want to rewrite, run tests on a regular basis and write new if needed, and of course discuss about my code with the community during reviews. APPROXIMATIVE TIMELINE Normally, I would be able to work 35 to 40 hours a week. When I have courses or exams at university, I could work between 20 and 25 hours a week. Community bonding --- April 23, 2018 -- May 14, 2018 /I’ll still have courses at the university during this period./ During the community bonding, I would like to dive into git’s codebase, and to understand what git-rebase--interactive does under the hood. At the same time, I’d communicate with the community and my mentor, seeking for clarifications, and asking questions about how things should or should not be done. Weeks 1 & 2 --- May 14, 2018 -- May 27, 2018 /From May 14 to 18, I have exams at the university, so I won’t be able to work full time./ I would search for edge cases not covered by current tests and write some if needed. Week 3 --- May 28, 2018 -- June 3, 2018 At the same time, I would refactor --preserve-merges in its own shell script, if it has not been deprecated or moved in the meantime. Dscho explained that this would be the first step of the conversion[1]. This operation is not really tricky by itself, as --preserve-merges is about only 50 lines of code into git_rebase__interactive(), plus some specific functions (eg. pick_one()). Weeks 4 to 7 --- June 4, 2018 -- July 1, 2018 Then, I would start to incrementally rewrite git-rebase--interactive.sh functions in C, and move them git-rebase--helper.c. Newly-rewritten C functions are then associated to command-line parameters to be able to use them from shell scripts. Examples of such conversion can be found in commits 0cce4a2756[3] (rebase -i -x: add exec commands via the rebase--helper) and b903674b35[4] (bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C). There is a lot of functions into git-rebase--interactive.sh to rewrite. Most of them are small, and some of them are even wrappers for a single command (eg. do_next()), so they shouldn’t b
Re: [GSoC] Convert “git stash” to builtin proposal
On 23.03.2018 19:11, Christian Couder wrote: * Ensure that no regression occurred: considering that there are plenty of tests and that I have a good understanding of the function, this should be a trivial task. There are a lot of things that the test suite doesn't test. Hopefully, by first adding new tests, any eventual bug will be spotted. * In the end, an analysis based on performance can be made. Benchmarking the script will be done by recording the running time given a large set of diversified tests that cover all the functionalities, before and after conversion. The new commands should run faster just because they were written in C, but I expect to see even more improvements. If you want to do benchmarks, you might want to add performance tests into t/perf. That is great. I will surely make use of the existent testing framework to do benchmarks. ## Example of conversion (for “git stash list”) -- To test my capabilities and to be sure that I am able to work on a project of this kind, I tried to convert “git stash list” into a built- in. The result can be found below in text-only version or at the Github link. I think it would be better if it was sent as a patch (maybe an RFC patch) to the mailing list and add the link to the patch email in the maling list archive to your proposal. I sent it as a [RFC] patch to the mailing list and included it in the proposal. <https://public-inbox.org/git/20180324182313.13705-1-ungureanupaulsebast...@gmail.com> It could be useful if you described a bit more how you could (re)use the work that has already been made. In the rest of your proposal it looks like you are starting from scratch, which is a bit strange if a lot of progress has already been made. The patches about converting ‘git stash’ are a great starting point and I will definitely use them. Each time I start converting a new command I will first take a look at what other patches there are, evaluate them and if I consider the patch to be good enough I will continue my work on top of that patch. Otherwise, I will start from scratch and that patch will only serve for comparison. One other resource that is of great importance is git itself. I can learn how a builtin is structured and how it is built by considering examples the other Git commands. Having a similar coding standard used, the codebase will be homogeneous and hopefully easier to maintain. Another important resource are commands that are Google Summer of Code projects from previous years (2016 and 2017) which had as purpose to convert “git bisect” and “git submodule”. I can always take a look at the patches they submitted and read their code reviews to avoid making same mistakes they did. It is probably better especially for reviewers and more common to work in small batches, for example to send a patch series converting a few related commands, then to start working on the next small batch of commands in another patch series while improving the first patch series according to reviews. Also we ask GSoC students to communicate publicly every week about their project for example by writing a blg post or sending a report to the mailing list. Noted. ## Git contributions -- My first contribution to Git was to help making “git tag --contains ” les chatty if is invalid. Looking over the list of available microprojects, there were a couple of microprojects which got my attention, but I picked this up because it seemed to be a long-standing bug (I noticed it was approached by students in 2016, 2017 and now in 2018). Thanks to the code reviews from the mailing list, after a few iterations I succeeded in coming up with a patch that not only fixed the mentioned problem, but also a few others that were having the same cause. It got merged in the proposed updates branch. What is its status in Junio's "What's cooking in Git" emails? It is now in the ‘next’ branch of the Git repository. I updated the proposal, in which I included these ideas and some additional examples. Thank you a lot! Best regards, Paul Ungureanu
Re: [RFC] [GSoC] Project proposal: convert scripts to builtins
Hi, On Wed, Mar 21, 2018 at 7:16 AM, Pratik Karki <predatoram...@gmail.com> wrote: > > Thanks for the feedback. Thanks to you, I realized my proposal was > a bit ambitious. Both git-stash and git-rebase are big > commitment. After much analyzing, I found out I cannot complete > both in the given time frame. So, I decided to stick to one and > complete it. Great. [...] > There has been some development in `git-stash` as seen on > [<https://public-inbox.org/git/20171110231314.30711-1-j...@teichroeb.net/>] > (https://public-inbox.org/git/20171110231314.30711-1-j...@teichroeb.net/). > To maximize the productivity, the findings from the patch submitted can > be used. Since, there are already much discussions regarding the > rewrite. In general it would be nice if you summarized what has already been done, how you can reuse it and what is needed to complete it. I see that you talk about some of that below, but a more general overview might be nice too. It could be interesting also to put the author(s) of the work that you will reuse in Cc. [...] > Timeline and Development Cycle > -- > > - Apr 23: Accepted student proposals announced. > > - Apr 23 onwards: Researching of all the test suites. Discussion of > possible test improvements in for `git-stash`. > > Firstly, the test suite coverage of every command will be reviewed > using gcov and kcov. I don't think it is necessary to spend a lot of time on the test suite coverage. > The test suite might not be perfect or > comprehensive but must cover all the major code paths and > command-line switches of the script. For the tests which seem > inadequate, minimum required tests are written and developed > incrementally. The minimum tests must provide safety net for > migration of scripts to built-ins. The tests would be sent as a > separate patch for parallel development and review process so that > development of built-ins can happen at the same time productively. Nice. > The tests will be written for every code changes and will be worked > throughout the summer. > > - May 1: Rewriting skeleton begins. > > The shell scripts are translated on a line-by-line basis into C > code. The C code will be written in a way to maximize the use of git > internal API. In git-stash `parse-options` API can be used for > implementing parsing argument of command-line. This would be way > better than parsing via the scripts. Firstly, I will start > implementing `stash --helper`from respective scripts to C code. Then > increment it further more. Then I'll start converting git-stash.sh > on a line-by-line basis. Not sure what you mean by line-by-line basis. > Again for git-stash some work seem to be done > > [<https://public-inbox.org/git/20171110231314.30711-1-j...@teichroeb.net/>] > (https://public-inbox.org/git/20171110231314.30711-1-j...@teichroeb.net/). > Now, to maximize the output I'll be taking findings from the > previous patch and use it for my patch. As seen from the comments in > the patch some tests for checking branch when `git stash branch` > fails needs to be written. Nice. Maybe writing those tests can come earlier in you schedule. > New tests will be written and code > coverage tools will be used for the written code. Not sure that code coverage tools need to be used. > - May 13: Making minimal `builtin/stash.c` with `stash--helper` ready > for review process. (This goes on for some time.) > > The initial review of minimal builtin would be ready for git-stash. > The result C code at this stage may not be necessarily be efficient > but would be free from obvious bugs and can serve as a baseline for > the final patch. This is sent for review process which can take some > time. The code will ofcourse be tested using the test suite with > some additional tests. How does that relates with the existing work? Will this be one or several patch series? What will each patch do? [...] > - June 10 - Jul 20: Start optimizing `builtin/stash.c`. Benchmarking > and profiling is done. They are exclusively compared to their > original shell scripts, to check whether they are more performant or > not and the results are published in the mailing list for further > discussion. Will the performance tests be added to the t/perf tests? > The C code will be optimized for speed and efficiency in this stage. The > built-ins will now be profiled using the new efficient test suites to > find hot spots. Bench-marking is also done in comparison to original > scripts.The performance for stash can be measured by making it stash > large number of chang
Re: [RFC][GSoC] Project proposal: convert interactive rebase to C
Hi, On Thu, Mar 22, 2018 at 11:03 PM, Alban Gruin <alban.gr...@gmail.com> wrote: > Hi, > > here is my second draft of my proposal. As last time, any feedback is > welcome :) > > I did not write my phone number and address here for obvious reasons, > but they will be in the “about me” section of the final proposal. > > Apart from that, do you think there is something to add? Please take a look at the comments that have been made on other's proposal. Many proposals could be improved in the same way and it is a bit annoying for us to repeat the same things many times. [...] > The goal of this project is to rewrite git-rebase--interactive in C > as it has been discussed on the git mailing list[1], for multiple > reasons : In general when the project or some issues related to the project have already been worked on or discussed on the mailing list, it is a good thing to summarize those discussions and link to them in your proposal. It shows that you want to take the time to gather existing information, to understand that information and to take it into account in your proposal, and it can also make your proposal easier to read and understand. More specifically your proposal has some links which is nice, but I think it would be better if it summarized a bit more what the links contain. [...] > Weeks 1 & 2 -- May 14, 2018 - May 27, 2018 > /From May 14 to 18, I have exams at the university, so I won’t be able > to work full time./ > > I would search for edge cases not covered by current tests and write > some if needed. > > Week 3 -- May 28, 2018 - June 3, 2018 > At the same time, I would refactor --preserve-merges in its own > shell script (as described in Dscho’s email[1]), if it has > not been deprecated or moved in the meantime. Here for example it is better if we could get a better idea about how you plan to do it without having to read Dscho's email. > This operation is not > really tricky by itself, as --preserve-merges is about only 50 lines > of code into git_rebase__interactive(). > > Weeks 4 to 7 -- May 4, 2018 - July 1, 2018 > Then, I would start to incrementally rewrite > git-rebase--interactive.sh functions in C, and move them > git-rebase--helper.c (as in commits 0cce4a2756[2] (rebase -i > -x: add exec commands via the rebase--helper) and b903674b35[3] > (bisect--helper: `is_expected_rev` & `check_expected_revs` shell > function in C)). I know what you mean but I would still appreciate if you could summarize it. > There is a lot of functions into git-rebase--interactive.sh to > rewrite. Most of them are small, and some of them are even wrappers > for a single command (eg. is_merge_commit()), so they shouldn’t be > really problematic. > > A couple of them are quite long (eg. pick_one()), and will probably > be even longer once rewritten in C due to the low-level nature of the > language. They also tend to depend a lot on other smaller functions. > > The plan here would be to start rewriting the smaller functions when > applicable (ie. they’re not a simple command wrapper) before > working on the biggest of them. > > Week 8 -- July 2, 2018 - July 8, 2018 > When all majors functions from git-rebase--interactive.sh have been > rewritten in C, I would retire the script in favor of a builtin. > > Weeks 9 & 10 -- July 9, 2018 - July 22, 2018 > I plan to spend theses two weeks to improve the code coverage where > needed. > > Weeks 11 & 12 -- July 23, 2018 - August 5, 2018 > In the last two weeks, I would polish the code where needed, in order > to improve its performance or to make it more readable. We like to have big improvements be split into batches of patches, also called patch series, and polishing of the first batches happening as soon as possible so that they can be ready to be merged soon. The patch series that are sent to the mailing list often need a number of round of reviews and improvements which can take a long time, so it is better if this process starts as soon as possible. Thanks.
Re: [GSoC] Convert “git stash” to builtin proposal
On Fri, Mar 23, 2018 at 12:15 AM, Paul-Sebastian Ungureanu <ungureanupaulsebast...@gmail.com> wrote: > > On Tue, 2018-03-20 at 23:08 +0100, Christian Couder wrote: >> >> On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu >> <ungureanupaulsebast...@gmail.com> wrote: >> > >> > * Convert function: this step is basically makes up the goal of >> > this >> > project. >> >> Could you explain a bit more how you would convert a function? Or >> could you explain for example how you would convert "git stash list" >> below? > > In order to convert a command, all the functions which are used by the > command must be converted first. The conversion will start with the > bottom-level functions, which do not have any dependencies. > > For example, to convert "git stash list", the parser will call > “list_stash”, which will call “have_stash”. The conversion of these > functions will be made in reverse order they were mentioned (have_stash > first and then list_stash). Ok. > It is very important to know the Git source well in order to avoid > reimplementing functionality. In this case “have_stash()” is somehow > already implemented as “get_oid(ref_stash, )”. > >> > I am expecting to submit a patch for every command that is >> > converted. >> > This way, I have well set milestones and results will be seen as >> > soon >> > as possible. Moreover, seeing my contributions getting merged will >> > be a >> > huge confidence boost to myself. >> > Each “convert” phase of the project below is not only about >> > converting >> > from Shell to C, but also ensuring that everything is documented, >> > there >> > are enough tests and there are no regressions. >> > >> > 14th May - 20th May - Convert "git stash list" >> >> For example could you explain a bit more which functions/commands you >> would create in which file and how you would call them to convert >> `git >> stash list` > > The new C code will be found in stash-helper.c and will be used by git- > stash.sh until the full conversion is complete. As soon as the entire > conversion is done, stash-helper.c will be promoted to stash.c. Any > functionality that will be implemented, but is not strictly related to > git stash will reside in the appropriate files (for example if I had to > implement similar to get_oid, which is not related to git stash, but to > Git, then I would not implement it in stash-helper.c; anyway, I do not > believe I will encounter this situation that often). Ok. > In the updated version of the proposal [1], I included the ideas stated > before and more information about the procces of benchmarking. In > addition, to test my capabilities and to be sure that I am able to work > on a project of this kind, I tried to convert “git stash list” into a > built-in (the code can be found in proposal). > > [1] https://docs.google.com/document/d/1TtdD7zgUsEOszHG5HX1at4zHMDsPmSB > YWqydOPTTpV8/edit I guess that below you inlined the updated version of your proposal. Nice. > Convert “git stash” to builtin [...] > * Ensure that no regression occurred: considering that there are plenty > of tests and that I have a good understanding of the function, this > should be a trivial task. There are a lot of things that the test suite doesn't test. > * Write more tests to ensure the best code coverage. This step will be > almost non existent due to step 4. Maybe you should use a numbered list if you want to refer to the items by their number. > * In the end, an analysis based on performance can be made. > Benchmarking the script will be done by recording the running time > given a large set of diversified tests that cover all the > functionalities, before and after conversion. The new commands should > run faster just because they were written in C, but I expect to see > even more improvements. If you want to do benchmarks, you might want to add performance tests into t/perf. [...] > ## Example of conversion (for “git stash list”) > -- > To test my capabilities and to be sure that I am able to work on a > project of this kind, I tried to convert “git stash list” into a built- > in. The result can be found below in text-only version or at the Github > link. I think it would be better if it was sent as a patch (maybe an RFC patch) to the mailing list and add the link to the patch email in the maling list archive to your proposal. [...] > Useful resources > There has been a lot of progress made in this direction already and I > believe it will serve of great help. However, from my
Re: [GSoC] Convert “git stash” to builtin proposal
Hi Paul-Sebastian, On Fri, 23 Mar 2018, Paul-Sebastian Ungureanu wrote: > On Tue, 2018-03-20 at 23:08 +0100, Christian Couder wrote: > > Hi, > > > > On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu > > <ungureanupaulsebast...@gmail.com> wrote: > > > > > > * Convert function: this step is basically makes up the goal of > > > this > > > project. > > > > Could you explain a bit more how you would convert a function? Or > > could you explain for example how you would convert "git stash list" > > below? > > In order to convert a command, all the functions which are used by the > command must be converted first. The conversion will start with the > bottom-level functions, which do not have any dependencies. > > For example, to convert "git stash list", the parser will call > “list_stash”, which will call “have_stash”. The conversion of these > functions will be made in reverse order they were mentioned (have_stash > first and then list_stash). > > It is very important to know the Git source well in order to avoid > reimplementing functionality. In this case “have_stash()” is somehow > already implemented as “get_oid(ref_stash, )”. Very good > [... proposal ...] This is a pretty good proposal. The initial draft at converting `stash list` is a good start (it will need to be converted to avoid spawning an extra process, but that is something we can do incrementally, together). Ciao, Johannes
Re: [GSoC] Convert “git stash” to builtin proposal
Hello, On Tue, 2018-03-20 at 23:08 +0100, Christian Couder wrote: > Hi, > > On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu > <ungureanupaulsebast...@gmail.com> wrote: > > > > * Convert function: this step is basically makes up the goal of > > this > > project. > > Could you explain a bit more how you would convert a function? Or > could you explain for example how you would convert "git stash list" > below? In order to convert a command, all the functions which are used by the command must be converted first. The conversion will start with the bottom-level functions, which do not have any dependencies. For example, to convert "git stash list", the parser will call “list_stash”, which will call “have_stash”. The conversion of these functions will be made in reverse order they were mentioned (have_stash first and then list_stash). It is very important to know the Git source well in order to avoid reimplementing functionality. In this case “have_stash()” is somehow already implemented as “get_oid(ref_stash, )”. > > I am expecting to submit a patch for every command that is > > converted. > > This way, I have well set milestones and results will be seen as > > soon > > as possible. Moreover, seeing my contributions getting merged will > > be a > > huge confidence boost to myself. > > Each “convert” phase of the project below is not only about > > converting > > from Shell to C, but also ensuring that everything is documented, > > there > > are enough tests and there are no regressions. > > > > 14th May - 20th May - Convert "git stash list" > > For example could you explain a bit more which functions/commands you > would create in which file and how you would call them to convert > `git > stash list` The new C code will be found in stash-helper.c and will be used by git- stash.sh until the full conversion is complete. As soon as the entire conversion is done, stash-helper.c will be promoted to stash.c. Any functionality that will be implemented, but is not strictly related to git stash will reside in the appropriate files (for example if I had to implement similar to get_oid, which is not related to git stash, but to Git, then I would not implement it in stash-helper.c; anyway, I do not believe I will encounter this situation that often). In the updated version of the proposal [1], I included the ideas stated before and more information about the procces of benchmarking. In addition, to test my capabilities and to be sure that I am able to work on a project of this kind, I tried to convert “git stash list” into a built-in (the code can be found in proposal). [1] https://docs.google.com/document/d/1TtdD7zgUsEOszHG5HX1at4zHMDsPmSB YWqydOPTTpV8/edit Convert “git stash” to builtin ## Name and Contact Information -- Hello! My name is Paul-Sebastian Ungureanu. I am currently a first year Computer Science & Engineering student at Politehnica University of Bucharest, Romania. My email address is ungureanupaulsebast...@gmail.com and my phone number is [CENSORED]. You can also find me on #git IRC channel as ungps. FLOSS manual recommends students to include in their proposal their postal address and mention a relative as a emergency contact. My permanent address is [CENSORED]. In case of an emergency, you may contact my brother, [CENSORED] by email at [CENSORED] or by phone at [CENSORED]. ## Synopsis -- Currently, many components of Git are still in the form of Shell or Perl scripts. This choice makes sense especially when considering how faster new features can be implemented in Shell and Perl scripts, rather than writing them in C. However, in production, where Git runs daily on millions of computers with distinct configurations (i.e. different operating systems) some problems appear (i.e. POSIX-to- Windows path conversion issues). The idea of this project is to take “git-stash.sh” and reimplement it in C. Apart from fixing compatibility issues and increasing the performance by going one step closer to native code, I believe this is an excellent excuse to fix long-standing bugs or implement new minor features. ## Benefits to community -- The essential benefit brought by rewriting Git commands is the increased compatibility with a large number computers with distinct configuration. I believe that this project can have a positive impact on a large mass of developers around the world. By rewriting the code behind some popular commands and making them “built-in”, developers will have a better overall experience when using Git and get to focus on what really matters to them. As a side effect, there will be a number of other improvements: increased performance, ability to
Re: [RFC][GSoC] Project proposal: convert interactive rebase to C
Hi, here is my second draft of my proposal. As last time, any feedback is welcome :) I did not write my phone number and address here for obvious reasons, but they will be in the “about me” section of the final proposal. Apart from that, do you think there is something to add? --- ABSTRACT git is a modular source control management software, and all of its subcommands are programs on their own. A lot of them are written in C, but a couple of them are shell or Perl scripts. This is the case of git-rebase--interactive (or interactive rebase), which is a shell script. Rewriting it in C would improve its performance, its portability, and maybe its robustness. ABOUT `git-rebase` and `git-rebase--interactive` git-rebase allows to re-apply changes on top of another branch. For instance, when a local branch and a remote branch have diverged, git-rebase can re-unify them, applying each change made on the local branch on top of the remote branch. git-rebase--interactive is used to reorganize commits by reordering, rewording, or squashing them. To achieve this purpose, git opens the list of commits to be modified in a text editor (hence the interactivity), as well as the actions to be performed for each of them. PROJECT GOALS The goal of this project is to rewrite git-rebase--interactive in C as it has been discussed on the git mailing list[1], for multiple reasons : Performance improvements Shell scripts are inherently slow. That’s because each command is a program by itself. So, for each command, the shell interpreter has to spawn a new process and to load a new program (with fork() and exec() syscalls), which is an expensive process. Those commands can be other git commands. Sometimes, they are wrappers to call internal C functions (eg. git-rebase--helper), something shell scripts can’t do natively. These wrappers basically parse the parameters, then start the appropriate function, which is obviously slower than just calling a function from C. Other commands can be POSIX utilities (eg. sed, cut, etc.). They have their own problems (speed aside), namely portability. Portability improvements Shell scripts often relies on many of those POSIX utilities, which are not necessarily natively available on all platforms (most notably, Windows), or may have more or less features depending on the implementation. Although C is not perfect portability-wise, it’s still better than shell scripts. For instance, the resulting binaries will not necessarily depend on third-party programs or libraries. RISKS Of course, rewriting a piece of software takes time, and can lead to regressions (ie. new bugs). To mitigate that risk, I should understand well the functions I want to rewrite, run tests on a regular basis and write new if needed, and of course discuss about my code with the community during reviews. APPROXIMATIVE TIMELINE Community bonding -- April 23, 2018 - May 14, 2018 During the community bonding, I would like to dive into git’s codebase, and to understand what git-rebase--interactive does under the hood. At the same time, I’d communicate with the community and my mentor, seeking for clarifications, and asking questions about how things should or should not be done. Weeks 1 & 2 -- May 14, 2018 - May 27, 2018 /From May 14 to 18, I have exams at the university, so I won’t be able to work full time./ I would search for edge cases not covered by current tests and write some if needed. Week 3 -- May 28, 2018 - June 3, 2018 At the same time, I would refactor --preserve-merges in its own shell script (as described in Dscho’s email[1]), if it has not been deprecated or moved in the meantime. This operation is not really tricky by itself, as --preserve-merges is about only 50 lines of code into git_rebase__interactive(). Weeks 4 to 7 -- May 4, 2018 - July 1, 2018 Then, I would start to incrementally rewrite git-rebase--interactive.sh functions in C, and move them git-rebase--helper.c (as in commits 0cce4a2756[2] (rebase -i -x: add exec commands via the rebase--helper) and b903674b35[3] (bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C)). There is a lot of functions into git-rebase--interactive.sh to rewrite. Most of them are small, and some of them are even wrappers for a single command (eg. is_merge_commit()), so they shouldn’t be really problematic. A couple of them are quite long (eg. pick_one()), and will probably be even longer once rewritten in C due to the low-level nature of the language. They also tend to depend a lot on other smaller functions. The plan here would be to start rewriting the smaller functions when applicable (ie. they’re not a simple command wrapper) before working on the biggest of them. Week 8 -- July 2, 2018 - July 8, 2018 When all majors functions from git-rebase--interactive.sh have been rewritten in C, I would retire the script in favor of a builtin. Weeks 9 & 10 -- July 9, 2018 - July 22, 2018 I plan to spend theses two week
Re: [RFC][GSoC] Project proposal: convert interactive rebase to C
Hi Alban, On Wed, 21 Mar 2018, Alban Gruin wrote: > Le mardi 20 mars 2018 17:29:28 CET, vous avez écrit : > > > Also, I have a hunch that there is actually almost nothing left to > > rewrite after my sequencer improvements that made it into Git v2.13.0, > > together with the upcoming changes (which are on top of the > > --recreate-merges patch series, hence I did not send them to the > > mailing list yet) in > > https://github.com/dscho/git/commit/c261f17a4a3e > > One year ago, you said[2] that converting this script "will fill up 3 > month, very easily". Is this not accurate anymore? Let me read that mail ;-) *goes and reads* Well, I was talking about two different aspects to Ivan and to you. I should have been clearer. So let me try again: To convert `git-rebase--interactive.sh`, I think the most important part is to factor out the preserve-merges code into its own script. After that, there is little I can think of (apart from support for --root, which a not-yet-contributed patch in my sequencer-shears branch on https://github.com/dscho/git addresses) that still needs to be converted. For somebody familiar with Git's source code, I would estimate one week (and therefore 3 weeks would be a realistic estimate :-)). Come to think of it, a better approach might be to leave the preserve-merges stuff in, and teach `git-rebase.sh` to call the sequencer directly for --interactive without --preserve-merges, then rename the script to git-rebase--preserve.sh The other aspect, the one I thought would take up to 3 months, easily, was to convert the entirety of rebase -i into C. That would entail also the option parsing, for which you would have to convert also git-rebase.sh (and if you do not convert git-rebase--am.sh and git-rebase--merge.sh first, you would then have to teach builtin/rebase.c to populate the environment variables expected by those shell scripts while spawning them). I still think that the latter is too big a task for a single GSoC. > I’ll send a new draft as soon as possible (hopefully this afternoon). I look forward to reading it! Ciao, Johannes
Re: [RFC][GSoC] Project proposal: convert interactive rebase to C
Hi Johannes, Le mardi 20 mars 2018 17:29:28 CET, vous avez écrit : > > Weeks 1 & 2 — May 14, 2018 – May 28, 2018 > > First, I would refactor --preserve-merges in its own shell script, as > > described in Dscho’s email. > > Could you go into detail a bit here? Like, describe what parts of the > git-rebase--interactive.sh script would need to be duplicated, which ones > would be truly moved, etc > It would lead to duplicate a good chunk of git_rebase__interactive(), apparently. The moved parts would be everything in `if test t = "$preserve_merges"; then …; fi` statements. That is, about 50 lines of shell code. Judging by that, beginning by that is probably not the right thing to do. Also, somebody is already working on that[1]. > > Weeks 3 & 4 — May 18, 2018 – June 11, 2018 > > Then, I would start to rewrite git-rebase--interactive, and get rid of > > git- > > rebase--helper. > > I think this is a bit premature, as the rebase--helper would not only > serve the --interactive part, but in later conversions also --am and > --merge, and only in the very end, when git-rebase.sh gets converted, > would we be able to simply rename the rebase--helper to rebase. > Yes, Christian Couder told me that it would not be a good methodology too. > Also, I have a hunch that there is actually almost nothing left to rewrite > after my sequencer improvements that made it into Git v2.13.0, together > with the upcoming changes (which are on top of the --recreate-merges patch > series, hence I did not send them to the mailing list yet) in > https://github.com/dscho/git/commit/c261f17a4a3e One year ago, you said[2] that converting this script "will fill up 3 month, very easily". Is this not accurate anymore? > > So I would like to see more details here... ;-) Yep, I’m working on that. > > Weeks 5 to 9 — June 11, 2018 – July 15, 2018 > > During this period, I would continue to rewrite git-rebase--interactive. > > It would be good if the proposal said what parts of the conversion are > tricky, to merit spending a month on them. > > > Weeks 10 & 11 — July 16, 2018 – July 29, 2018 > > In the second half of July, I would look for bugs in the new code, test > > it, > > and improve its coverage. > > As I mentioned in a related mail, the test suite coverage would be most > sensibly extended *before* starting to rewrite code in C, as it helps > catching bugs early and avoids having to merge buggy code that needs to be > fixed immediately. Makes sense. > > > Weeks 12 — July 30, 2018 – August 5, 2018 > > In the last week, I would polish the code where needed, in order to > > improve for performance or to make the code more readable. > > Thank you for sharing this draft with us! > Johannes I’ll send a new draft as soon as possible (hopefully this afternoon). Thank you for your enthousiasm :) Alban [1] https://public-inbox.org/git/20180320204507.12623-1-w...@saville.com/ [2] https://public-inbox.org/git/alpine.DEB. 2.20.1703231827060.3767@virtualbox/
Re: [RFC] [GSoC] Project proposal: convert scripts to builtins
Hi Johannes, Thanks for the feedback. Thanks to you, I realized my proposal was a bit ambitious. Both git-stash and git-rebase are big commitment. After much analyzing, I found out I cannot complete both in the given time frame. So, I decided to stick to one and complete it. I decided to stick with git-stash. Thank you for directing me to the un-merged matches. Now, I can find the points where the patch couldn't be effective and work towards completing those effective things. Please provide feedback for this updated proposal. Cheers, Pratik Karki Convert Scripts to builtins === Abstract Many components of Git are still in the form of shell and Perl scripts. This has certain advantages of being extensible but causes problems in production code on multiple platforms like Windows.\ I propose to rewrite a couple of shell and perl scripts into portable and performant C code, making them built-ins. The major advantage of doing this is improvement in efficiency and performance. Much more scripts like `git-am` , `git-pull`, `git-branch` have already been rewritten in C. Much more scripts like `git-rebase`, `git-stash`, `git-add --interactive` are still present in shell and perl scripts. I propose to work in `git-stash`. ### Shell Scripts: Although shell scripts are more faster can be extensible in functionality and can be more easier to write, they introduce certain disadvantages. 1. Dependencies:\ The scripting languages and shell scripts make more productive code but there is an overhead of dependencies. The shell scripts are lighter and simpler and call other executables to perform non-trivial tasks. Taking `git-stash` shell script for example. `sed`, `rm`, `echo`, `test` are constantly present in `git-stash`. These look common to POSIX platforms but for non-POSIX platforms there needs some extra work for porting these commands. For example, in Git for Windows, the workaround for these commands in non-POSIX platform adds some extra utilities and adds MSYS2 shell commands and needs to pack language runtime for Perl. This increases the installation size and requires more disk space. Again, adding more batteries again needs implementation in all of the dependency libraries and executables. 2. Inefficiency:\ Git has internal caches for configuration values, the repository index and repository objects. The porcelain commands do not have access to git's internal API and so they spawn git processes to perform git operations. For every git invocation, git would re-read the user's configuration files, repository index, repopulate the filesystem cache, etc. This leads to overhead and unnecessary I/O. Windows is known to have worse I/O performance compared to Linux. There is also slower I/O performance of HDD compared to SSD. This unnecessary I/O operations causes runtime overhead and becomes slower in poor I/O performance setups. Now, writing the porcelain into C built-ins leverages the git API and there is no need of spawning separate git processes, caching can be used to reduce unnecessary I/O processes. 3. Spawing processes is less performant:\ Shell scripts usually spawn a lot of processes. Shell scripts are very lighter and hence have limited functionalites. For `git-stash.sh` to work it needs to perform lots of git operations like `git rev-parse` `git config` and thus spawns git executable processes for performing these operations. Again for invoking `git config` and providing configuration values, it spawn new processes to handle that. Spawning is implemented by `fork()` and `exec()` by shells. Now, on systems that do not support copy-on-write semantics for `fork()`, there is duplication of the memory of the parent process for every `fork()` call which turns out to be an expensive process. Now, in Windows, Git uses MSYS2 exclusively to emulate `fork()` but since, Windows doesnot support forking semantics natively, the workaround provided by MSYS2 emulates `fork()` without [copy-on-write semantics](https://www.cygwin.com/faq.html#faq.api.fork). Doing this creates another layer over Windows processes and thus slows git. Rewriting C built-ins - These above mentioned problems need to be fixed. The only fix for these problems would be to write built-ins in C for all these shell scripts leveraging the git API. Writing in built-in reduces the dependency required by shell scripts. Since, Git is native executable in Windows, doing this can make MSYS2 POSIX emulation obsolete. Then, using git's internal API and C data types, built-in `git_config_get_value()` can be used to get configuration value rather than spawning another git-config process. This removes the necessary to re-read git configuration cache everytime and reduces I/O. Furthermore, git-stash will be more faster and show
Re: [GSoC] Convert “git stash” to builtin proposal
Hi, On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanuwrote: > > * Convert function: this step is basically makes up the goal of this > project. Could you explain a bit more how you would convert a function? Or could you explain for example how you would convert "git stash list" below? > * Ensure that no regression occurred: considering that there are plenty > of tests and that I have a good understanding of the function, this > should be a trivial task. > > * Finally write more tests to ensure best code coverage. Maybe, as Dscho suggested to another potential GSoC student, it would be better to write more tests before converting the function. > # Useful resources > There has been a lot of progress made in this direction already and I > believe it will serve of great help. However, from my understanding it > is not yet mergeable and it requires changes. > > https://public-inbox.org/git/20170608005535.13080-1-j...@teichroeb.net/ > T/#m8849c7ce0ad8516cc206dd6910b79591bf9b3acd Maybe you should Cc the author of this patch series. Also please notice that the patch series started with adding some tests. > I am expecting to submit a patch for every command that is converted. > This way, I have well set milestones and results will be seen as soon > as possible. Moreover, seeing my contributions getting merged will be a > huge confidence boost to myself. > Each “convert” phase of the project below is not only about converting > from Shell to C, but also ensuring that everything is documented, there > are enough tests and there are no regressions. > > 14th May - 20th May - Convert "git stash list" For example could you explain a bit more which functions/commands you would create in which file and how you would call them to convert `git stash list`
[GSoC] Convert “git stash” to builtin proposal
Hello, I have completed the first draft of my proposal for the Google Summer of Code, which can be found at [1] or below for those who prefer the text version. Any feedback is greatly appreciated. Thanks! [1] https://docs.google.com/document/d/1TtdD7zgUsEOszHG5HX1at4zHMDsPmSBYWqy dOPTTpV8/edit?usp=sharing Best regards, Paul-Sebastian Ungureanu # Convert “git stash” to builtin # Name and Contact Information Hello! My name is Paul-Sebastian Ungureanu. I am currently a first year Computer Science & Engineering student at Politehnica University of Bucharest, Romania. My email address is ungureanupaulsebast...@gmail.com and my phone number is [CENSORED]. You can also find me on #git IRC channel as ungps. FLOSS manual recommends students to include in their proposal their postal address and mention a relative as a emergency contact. My permanent address is [CENSORED]. In case of an emergency, you may contact my brother, [CENSORED] by email at [CENSORED] or by phone at [CENSORED]. # Synopsis Currently, many components of Git are still in the form of Shell or Perl scripts. This choice makes sense especially when considering how faster new features can be implemented in Shell and Perl scripts, rather than writing them in C. However, in production, where Git runs daily on millions of computers with distinct configurations (i.e. different operating systems) some problems appear (i.e. POSIX-to- Windows path conversion issues). The idea of this project is to take “git-stash.sh” and reimplement it in C. Apart from fixing compatibility issues and increasing the performance by going one step closer to native code, I believe this is an excellent excuse to fix long-standing bugs or implement new minor features. # Benefits to community The essential benefit brought by rewriting Git commands is the increased compatibility with a large number computers with distinct configuration. I believe that this project can have a positive impact on a large mass of developers around the world. By rewriting the code behind some popular commands and making them “built-in”, developers will have a better overall experience when using Git and get to focus on what really matters to them. As a side effect, there will be a number of other improvements: increased performance, ability to rethink the design of some code that suffered from patching along the time, have the chance to create new features and fix old bugs. In theory, switching from Bash or Shell scripts, Git will be one step closer to native code which should have a positive impact on the performance. Being able to start from a clean slate is a great opportunity to rethink old designs that may have been patched a lot during their lifetime. This way, with the help of my mentors, I can think of new ways to try and remove some limitations of the current system (if there are any). Moreover, I believe that the community will benefit greatly from new features and bug fixes that I could help with. Even though this is not really one of the main goals of this project, I believe that it would be easier to fix bugs or implement new features while rewriting the code. However, I will have to discuss with my mentors and carefully review issues as I would not want to divagate from the purpose of the project. As a last point, I believe it is good to have a more homogenous codebase, where the majority of the code would be written in C. This could increase the number of contributions to the project as there are maybe more programmers who are familiar with C, and not so much with Perl or shell scripting. # Deliverables Deliverable of this project is “git stash” completely rewritten in portable C code. Along with the new code, there will be some additions and changes brought to tests to cover any new behaviour. # Related work Looking over the list of the other proposed projects, I believe that “Convert interactive rebase to C” and “git bisect improvements” are the most alike with this project and may be stretch goal of this project. Moreover, there is a chance that other scripts could benefit from this project if it were to be taken as an example for future conversions. # Biographical information I am a freshman at Politehnica University of Bucharest, which is considered to be one of the most prestigious universities in the Eastern Europe. I consider myself an ambitious software engineer that enjoys competition. This has been proven by my participation to programming competitions and extracurricular projects. As much as I like competitions, I also love working with and meeting people that share my interests for programming and technology. Even though, in the last two years I found myself to be more interested in Android software development rather than competitive programming, I still take part in most of the competitions, such as contests organized by Google HashCode, Google KickStart and ACM. I have a good grasp of programming languages such as C and C++ and I consider both of
Re: [RFC][GSoC] Project proposal: convert interactive rebase to C
Hi Alban, thank you for your proposal! I will only comment on the parts that I feel could use improvement, the rest is fine by me. On Sat, 17 Mar 2018, Alban Gruin wrote: > APPROXIMATIVE TIMELINE > > Community bonding — April 23, 2018 – May 14, 2018 > During the community bonding, I would like to dive into git’s codebase, > and to understand what git-rebase--interactive does under the hood. At > the same time, I’d communicate with the community and my mentor, seeking > for clarifications, and asking questions about how things should or > should not be done. > > Weeks 1 & 2 — May 14, 2018 – May 28, 2018 > First, I would refactor --preserve-merges in its own shell script, as > described in Dscho’s email. Could you go into detail a bit here? Like, describe what parts of the git-rebase--interactive.sh script would need to be duplicated, which ones would be truly moved, etc > Weeks 3 & 4 — May 18, 2018 – June 11, 2018 > Then, I would start to rewrite git-rebase--interactive, and get rid of git- > rebase--helper. I think this is a bit premature, as the rebase--helper would not only serve the --interactive part, but in later conversions also --am and --merge, and only in the very end, when git-rebase.sh gets converted, would we be able to simply rename the rebase--helper to rebase. Also, I have a hunch that there is actually almost nothing left to rewrite after my sequencer improvements that made it into Git v2.13.0, together with the upcoming changes (which are on top of the --recreate-merges patch series, hence I did not send them to the mailing list yet) in https://github.com/dscho/git/commit/c261f17a4a3e So I would like to see more details here... ;-) > Weeks 5 to 9 — June 11, 2018 – July 15, 2018 > During this period, I would continue to rewrite git-rebase--interactive. It would be good if the proposal said what parts of the conversion are tricky, to merit spending a month on them. > Weeks 10 & 11 — July 16, 2018 – July 29, 2018 > In the second half of July, I would look for bugs in the new code, test it, > and improve its coverage. As I mentioned in a related mail, the test suite coverage would be most sensibly extended *before* starting to rewrite code in C, as it helps catching bugs early and avoids having to merge buggy code that needs to be fixed immediately. > Weeks 12 — July 30, 2018 – August 5, 2018 > In the last week, I would polish the code where needed, in order to > improve for performance or to make the code more readable. Thank you for sharing this draft with us! Johannes
Re: [RFC] [GSoC] Project proposal: convert scripts to builtins
Hi Pratik, thank you so much for posting this inline, to make it easier to review. I will quote only on specific parts below; Please just assume that I like the other parts and have nothing to add. On Tue, 20 Mar 2018, Pratik Karki wrote: > > Timeline and Development Cycle > -- > > - Apr 23: Accepted student proposals announced. > - Apr 23 onwards: Researching of all the test suites. Discussion of > possible test improvements in for `git-stash` and `git-rebase`. > - May 1: Rewriting skeleton begins. I would have liked more detail here. Like, maybe even a rudimentary initial version identifying, say, a part of `git stash` and/or `git rebase` that could be put into a builtin (stash--helper and rebase--helper, respectively). It is my experience from several GSoCs working on this huge overarching project to convert the scripts (which are good prototypes, but lack in stringency in addition to performance) to C that even the individual scripts are too much to stem for a single GSoC. > - May 13: Making `builtin/stash.c` ready for review process. (This > goes on for some time.) There have been two past efforts to turn stash into a builtin: https://github.com/git-for-windows/git/pull/508 and https://public-inbox.org/git/20171110231314.30711-1-j...@teichroeb.net/ It would be good to read up on those and incorporate the learnings into the proposal. > - May 26: Making `builtin/rebase.c` ready for review process. (This > goes on for some time.) The `git-rebase.sh` script is itself not terribly interesting, as it hands off to `git-rebase--am.sh`, `git-rebase--interactive.sh` and `git-rebase--merge.sh`, respectively. Converting `git-rebase` into a builtin without first converting all of those scripts would make little sense. It would probably be better to choose one of those latter scripts and move their functionality into a builtin, in an incremental fashion. By doing it incrementally, you can also avoid... > - June 10: Make second versions with more improvements and more > batteries ready for next review cycle. ... leaving two weeks between checkpoints. Also, doing it incrementally lets you avoid sitting on your hands while waiting for the first patches to be reviewed. > - June 20: Writing new tests and using more code-coverage tools to > squash bugs present. Typically it helps a lot to have those tests *during* the conversion. That's how I found most of the bugs when converting difftool, for example. > - June 25 - Jul 20: Start optimizing `builtin/stash.c` and > `builtin/rebase.c`. Benchmarking and profiling is done. They are > exclusively compared to their original shell scripts, to check > whether they are more performant or not and the results are > published in the mailing list for further discussion. Could you add details how you would perform benchmarking and profiling? > - Jul 20 - Aug 5: More optimizing and polishing of `builtin/stash.c` > and `builtin/rebase.c` and running of new tests series written and > send them for code review. > - Aug 14: Submit final patches. > - Aug 22: Results announced. > - Apr 24 - Aug 14: Documentation is written. "What I'm working on" is > written and posted in my blog regarding GSoC with Git. The timeline is a bit ambitious. I would like to caution you that these are all big tasks, and maybe you want to cut down on the deliverables, and add more detail what exactly you want to deliver (such as: what part of stash/rebase do you find under-tested in our test suite and would therefore want to augment, what parts of stash/rebase do you think you would handle first, and how?). Ciao, Johannes
Re: [RFC] [GSoC] Project proposal: convert scripts to builtins
Hi, This is my draft for my proposal on "Convert Scripts to builtins" for GSoC. Please review and provide feedback. Cheers, Pratik Karki Convert Scripts to builtins === Abstract Many components of Git are still in the form of shell and Perl scripts. This has certain advantages of being extensible but causes problems in production code on multiple platforms like Windows. I propose to rewrite a couple of shell and perl scripts into portable and performant C code, making them built-ins. The major advantage of doing this is improvement in efficiency and performance. Much more scripts like `git-am` , `git-pull`, `git-branch` have already been rewritten in C. Much more scripts like `git-rebase`, `git-stash`, `git-add --interactive` are still present in shell and perl scripts. I propose to work in `git-rebase` and `git-stash`. Shell Scripts: -- Although shell scripts are more faster can be extensible in functionality and can be more easier to write, they introduce certain disadvantages. 1. Dependencies: The scripting languages and shell scripts make more productive code but there is an overhead of dependencies. The shell scripts are lighter and simpler and call other executables to perform non-trivial tasks. Taking `git-stash` shell script for example. `sed`, `rm`, `echo`, `test` are constantly present in `git-stash`. These look common to POSIX platforms but for non-POSIX platforms there needs some extra work for porting these commands. For example, in Git for Windows, the workaround for these commands in non-POSIX platform adds some extra utilities and adds MSYS2 shell commands and needs to pack language runtime for Perl. This increases the installation size and requires more disk space. Again, adding more batteries again needs implementation in all of the dependency libraries and executables. 2. Inefficiency: Git has internal caches for configuration values, the repository index and repository objects. The porcelain commands do not have access to git's internal API and so they spawn git processes to perform git operations. For every git invocation, git would re-read the user's configuration files, repository index, repopulate the filesystem cache, etc. This leads to overhead and unnecessary I/O. Windows is known to have worse I/O performance compared to Linux. There is also slower I/O performance of HDD compared to SSD. This unnecessary I/O operations causes runtime overhead and becomes slower in poor I/O performance setups. Now, writing the porcelain into C built-ins leverages the git API and there is no need of spawning separate git processes, caching can be used to reduce unnecessary I/O processes. 3. Spawing processes is less performant: Shell scripts usually spawn a lot of processes. Shell scripts are very lighter and hence have limited functionalites. For `git-stash.sh` to work it needs to perform lots of git operations like `git rev-parse` `git config` and thus spawns git executable processes for performing these operations. Again for invoking `git config` and providing configuration values, it spawn new processes to handle that. Spawning is implemented by `fork()` and `exec()` by shells. Now, on systems that do not support copy-on-write semantics for `fork()`, there is duplication of the memory of the parent process for every `fork()` call which turns out to be an expensive process. Now, in Windows, Git uses MSYS2 exclusively to emulate `fork()` but since, Windows doesnot support forking semantics natively, the workaround provided by MSYS2 emulates `fork()` without [copy-on-write semantics](https://www.cygwin.com/faq.html#faq.api.fork). Doing this creates another layer over Windows processes and thus slows git. Rewriting C built-ins - These above mentioned problems need to be fixed. The only fix for these problems would be to write built-ins in C for all these shell scripts leveraging the git API. Writing in built-in reduces the dependency required by shell scripts. Since, Git is native executable in Windows, doing this can make MSYS2 POSIX emulation obsolete. Then, using git's internal API and C data types, built-in `git_config_get_value()` can be used to get configuration value rather than spawning another git-config process. This removes the necessary to re-read git configuration cache everytime and reduces I/O. Furthermore, git-stash and git-rebase will be more faster and show consistent behaviour as instead of spawing another process and parsing command-line arguments manually, they can be hardcoded to be built-in and leverage all the required git's internal API's like `parse-options`. To implement git-stash and git-rebase in C, I propose to avoid spawning lots of external git processes and reduce redundant I/O by taking advantage of th
Re: [RFC] [GSoC] Project proposal: convert scripts to builtins
Hi, On Tue, Mar 20, 2018 at 10:00 AM, Pratik Karki <predatoram...@gmail.com> wrote: > Hi, > This is my draft for my proposal on "Convert Scripts to builtin" for GSoC. > Please review and provide feedbacks. > > https://gist.github.com/prertik/daaa73a39d3ce30811d9a208043dc235 It would be easier for us to comment if the markdown was sent inline. Thanks, Christian.
[RFC] [GSoC] Project proposal: convert scripts to builtins
Hi, This is my draft for my proposal on "Convert Scripts to builtin" for GSoC. Please review and provide feedbacks. https://gist.github.com/prertik/daaa73a39d3ce30811d9a208043dc235 Cheers, Pratik Karki
Investment Proposal
Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds Melisa Mehmet
Re: [RFC][GSoC] Project proposal: convert interactive rebase to C
Hi, On Sat, Mar 17, 2018 at 8:14 PM, Alban Gruin <alban.gr...@gmail.com> wrote: > > Weeks 3 & 4 — May 18, 2018 – June 11, 2018 > Then, I would start to rewrite git-rebase--interactive, and get rid of git- > rebase--helper. Usually to rewrite a shell script in C, we first rewrite shell functions into option arguments in a C builtin helper and make the schell script call the builtin helper (instead of the original shell functions). Eventually when the shell script is mostly only calling the builtin helper, we add what is needed into the builtin helper and we rename it to make it fully replace the shell script. See for example 0cce4a2756 (rebase -i -x: add exec commands via the rebase--helper, 2017-12-05) or b903674b35 (bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C, 2017-09-29). These examples show that we can do step by step rewrites. I would suggest planning to use the same approach, and describing in your proposal which shell functions you would like to rewrite into the C builtin helper in which order, before planning to fully replace the current git-rebase--interactive. Thanks, Christian.
[RFC][GSoC] Project proposal: convert interactive rebase to C
Hi, here is my first draft of my proposal for the GSoC, about the "convert interactive rebase to C" project. Any feedback is welcome :) --- ABSTRACT git is a modular source control management software, and all of its subcommands are programs on their own. A lot of them are written in C, but a couple of them are shell or Perl scripts. This is the case of git-rebase-- interactive (or interactive rebase), which is a shell script. Rewriting it in C would improve its performance, its portability, and maybe its robustness. ABOUT `git-rebase{,--interactive}` git-rebase allows to re-apply changes on top of another branch. For instance, when a local branch and a remote branch have diverged, git-rebase can re-unify them, applying each change made on the local branch on top of the remote branch. git-rebase--interactive is used to reorganize commits by reordering, rewording, or squashing them. To achieve this purpose, git opens the list of commits to be modified in a text editor (hence the interactivity), as well as the actions to be performed for each of them. PROJECT GOALS The goal of this project is to rewrite git-rebase--interactive in C as it has been discussed on the git mailing list[1], for multiple reasons : Performance improvements Shell scripts are inherently slow. That’s because each command is a program by itself. So, for each command, the shell interpreter has to spawn a new process and to load a new program. Those commands can be other git commands. Sometimes, they are wrappers to call internal C functions (eg. git-rebase--helper), something shell scripts can’t do natively. These wrappers basically parse the parameters, then start the appropriate function, which is obviously slower than just calling a function from C. Other commands can be POSIX utilities (eg. sed, cut, etc.). They have their own problems (speed aside), namely portability. Portability improvements Shell scripts often relies on many of those POSIX utilities, which are not necessarily natively available on all platforms (most notably, Windows), or may have more or less features depending on the implementation. APPROXIMATIVE TIMELINE Community bonding — April 23, 2018 – May 14, 2018 During the community bonding, I would like to dive into git’s codebase, and to understand what git-rebase--interactive does under the hood. At the same time, I’d communicate with the community and my mentor, seeking for clarifications, and asking questions about how things should or should not be done. Weeks 1 & 2 — May 14, 2018 – May 28, 2018 First, I would refactor --preserve-merges in its own shell script, as described in Dscho’s email. Weeks 3 & 4 — May 18, 2018 – June 11, 2018 Then, I would start to rewrite git-rebase--interactive, and get rid of git- rebase--helper. Weeks 5 to 9 — June 11, 2018 – July 15, 2018 During this period, I would continue to rewrite git-rebase--interactive. Weeks 10 & 11 — July 16, 2018 – July 29, 2018 In the second half of July, I would look for bugs in the new code, test it, and improve its coverage. Weeks 12 — July 30, 2018 – August 5, 2018 In the last week, I would polish the code where needed, in order to improve for performance or to make the code more readable. ABOUT ME My name is Alban Gruin, I am an undergraduate at the Paul Sabatier University in Toulouse, France, where I have been studying Computer Sciences for the past year and a half. My timezone currently is UTC+01:00, but will be UTC+02:00 starting from March 25th, because of the daylight saving time in Europe. I have been programming in C for the last 5 years. I learned using freely available resources online, and by attending class ever since last year. I am also quite familiar with shell scripts, and I have been using git for the last 3 years. My e-mail address is alban gruin gmail com. My IRC nick is abngrn. My micro-project was "userdiff: add built-in pattern for golang"[2][3]. --- You can find the Google Doc version here[4]. Regards, Alban Gruin [1] https://public-inbox.org/git/alpine.DEB.2.20.1609021432070.129229@virtualbox/ [2] https://public-inbox.org/git/20180228172906.30582-1-alban.gr...@gmail.com/ [3] https://git.kernel.org/pub/scm/git/git.git/commit/?id=1dbf0c0a [4] https://docs.google.com/document/d/1Jx0w867tVAht7QI1_prieiXg_iQ_nTloOyaIIOnm85g/edit?usp=sharing
Re: man gittutorial: patch proposal
hello. 1.I understood, that verbose commands are quoted in ` ' or ' '. While the points I changed are not verbose commands. Therefore I didn't see any sense in them. Because of the different quoting ways (e.g. `merge`), I thought that someone didn't understand the quoting concept. But it could also be me... 2.yes please. I will read this section. kalle Am 06.03.2018 um 00:25 schrieb Jonathan Nieder: > Hi, > > kalle wrote: > >> see attachment. > > Thanks for writing. A few questions: > > 1. Can you say a little more about the rationale for this change? > E.g. is the current formatting sending a confusing message? Is the > current formatting intending to use '' as quotes and using italics > instead? If so, should this use "" to fix it? > > 2. May we forge your sign-off? See the section "Certify your work" > in Documentation/SubmittingPatches for more about what this means. > > Thanks, > Jonathan >
Re: man gittutorial: patch proposal
Hi, kalle wrote: > see attachment. Thanks for writing. A few questions: 1. Can you say a little more about the rationale for this change? E.g. is the current formatting sending a confusing message? Is the current formatting intending to use '' as quotes and using italics instead? If so, should this use "" to fix it? 2. May we forge your sign-off? See the section "Certify your work" in Documentation/SubmittingPatches for more about what this means. Thanks, Jonathan
man gittutorial: patch proposal
see attachment. greetings, kalle >From ed466d29733a14acf3b2071d3d35aa829e09b1d7 Mon Sep 17 00:00:00 2001 From: kalledaballeDate: Thu, 8 Feb 2018 18:53:54 +0100 Subject: [PATCH 1/5] I corrected some few quotation mistakes --- Documentation/gittutorial.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 242de31..d04f8ac 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -372,7 +372,7 @@ her work-in-progress on top of the resulting history. When you are working in a small closely knit group, it is not unusual to interact with the same repository over and over -again. By defining 'remote' repository shorthand, you can make +again. By defining remote repository shorthand, you can make it easier: @@ -406,8 +406,8 @@ could merge the changes into her master branch: alice$ git merge bob/master - -This `merge` can also be done by 'pulling from her own remote-tracking -branch', like this: +This merge can also be done by pulling from her own remote-tracking +branch, like this: - alice$ git pull . remotes/bob/master -- 2.1.4
Proposal
Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds
Proposal
Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds
Proposal
Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds
Proposal
Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds
Proposal
Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds
Re: git-rebase --undo-skip proposal
Hi Jake, On Wed, 14 Feb 2018, Jacob Keller wrote: > On Wed, Feb 14, 2018 at 5:50 PM, Psidium Guajavawrote: > > 2018-02-14 22:53 GMT-02:00 Johannes Schindelin : > >> Now, when is the next possible time you can call `git rebase --undo-skip`? > > > > What if the scope were reduced from `--undo-skip` to `--undo-last-skip`? > > Also, further reduce the scope to only allow `--undo-last-skip` during > > a ongoing rebase, not caring about a finished one? > > > > But, this could be so niche that I have doubts if this would ever be used; > > I think this is too niche to actually be useful in practice, > especially since figuring out exactly what to replay might be tricky.. > I suppose it could keep track of where in the rebase the last skip was > used, and then just go back to rebase and stop there again? That > sounds like just redoing the rebase is easier.. (ie: use the reflog to > go back to before the rebase started, and then re-run it again and > don't skip this time). Yes, and having a record of what commits were skipped would probably be very helpful not only in this instance. Maybe also a record of what commits caused merge conflicts, which a mapping between original and new commit (which does get a bit tricky with fixup!/squash! commits, though). Ciao, Dscho
Re: git-rebase --undo-skip proposal
Hi Jake, On Wed, 14 Feb 2018, Jacob Keller wrote: > On Wed, Feb 14, 2018 at 4:53 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > > > On Wed, 14 Feb 2018, Psidium Guajava wrote: > > > >> On 2018-02-13 18:42 GMT-02:00 Stefan Beller <sbel...@google.com> wrote: > >> > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava > >> > <psiid...@gmail.com> wrote: I think this could also be done with > >> > "git rebase --edit-todo", which brings up the right file in your > >> > editor. > >> > >> Yeah that'd would only work if one started a rebase as a interactive > >> one, not am or merge. > > > > I agree that the original proposal was clearly for the non-interactive > > rebase (it talked about .git/rebase-apply/). > > > > The biggest problem with the feature request is not how useful it > > would be: I agree it would be useful. The biggest problem is that it > > is a little bit of an ill-defined problem. > > > > Imagine that you are rebasing 30 patches. Now, let's assume that patch > > #7 causes a merge conflict, and you mistakenly call `git rebase > > --skip`. > > > > Now, when is the next possible time you can call `git rebase > > --undo-skip`? It could be after a merge conflict in #8. Or in > > interactive rebase, after a `pick` that was turned into an `edit`. Or, > > and this is also entirely possible, after the rebase finished with #30 > > without problems and the rebase is actually no longer in progress. > > > > So I do not think that there is a way, in general, to implement this > > feature. Even if you try to remember the state where a `--skip` was > > called, you would remember it in the .git/rebase-apply/ (or > > .git/rebase-merge/) directory, which is cleaned up after the rebase > > concluded successfully. So even then the information required to > > implement the feature would not necessarily be there, still, when it > > would be needed. > > Instead of an "--undo-skip", what if we ask the question of what the > user actually wants? Heh, I thought in this instance, --undo-skip was what the user wanted ;-) > Generally I'd assume that the user wishes to go back to the rebase and > "pick" the commit back in. Right, and then replay whatever series of commits was picked since the one that was skipped. What *could* be done is to save a copy of the current todo list (with the skipped commit put back in, before the current first line) and save that together with `git rev-parse HEAD`. This should make it possible to implement `--undo-skip` for as long as the rebase did not finish. Theoretically, you could even save the commit name of the skipped commit somewhere else than $GIT_DIR/rebase-apply/ (or $GIT_DIR/rebase-merge/), say, as worktree-local `refs/rebase/skipped`, and then a `git rebase --undo-skip` could detect the absence of $GIT_DIR/rebase-*/ and fall back to `git cherry-pick refs/rebase/skipped`. You'd have to take pains to handle that ref in gc, and to record when the user edited the todo list via `git rebase --edit-todo` after skipping that commit (and warn loudly upon/prevent --undo-skip) because those todo list changes would then be lost. That's just one way how this feature could be implemented. It does strike me as awfully specific, though. And it would still only extend to the latest `git rebase --skip`. So I am not sure whether we really would want to go this direction, or whether we can maybe come up with something (probably based on your suggestion to give the user enough information) that would allow many more scenarios than just --undo-skip. > So what if we just make "git rebase --skip" more verbose so that it > more clearly spells out which commit is being skipped? Possibly even > as extra lines of "the following patches were skipped during the > rebase" after it completes? > > Then it's up to the user to determine what to do with those commits, > and there are many tools they could use to solve it, "git rebase -i, > git cherry-pick, git reflog to restore to a previous and re-run the > rebase, etc". I think this is a saner direction, as it will probably allow more scenarios to be addressed than just undoing the latest `git rebase --skip`. Ciao, Dscho
Re: git-rebase --undo-skip proposal
Hi Gabriel, On Wed, Feb 14, 2018 at 4:42 AM, Stefan Bellerwrote: > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote: >> >> Also, a little unrelated with this issue: >> 5. What happened to the rewrite of rebase in C [2]? I couldn't find >> any information after 2016. >> >> [1] https://public-inbox.org/git/201311011522.44631.tho...@koch.ro/ >> [2] >> https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyoka...@gmail.com/ > > cc'd Paul Tan, maybe he recalls the situation. It was discarded in favor of Johannes' rebase-helper approach, and I think parts of it are already in master. There's probably room for help there. I haven't had time to keep track of Git development, hence my inactivity. Sorry about that. Regards, Paul
Re: git-rebase --undo-skip proposal
On Wed, Feb 14, 2018 at 5:50 PM, Psidium Guajavawrote: > 2018-02-14 22:53 GMT-02:00 Johannes Schindelin : >> Now, when is the next possible time you can call `git rebase --undo-skip`? > > What if the scope were reduced from `--undo-skip` to `--undo-last-skip`? > Also, further reduce the scope to only allow `--undo-last-skip` during > a ongoing rebase, not caring about a finished one? > > But, this could be so niche that I have doubts if this would ever be used; I think this is too niche to actually be useful in practice, especially since figuring out exactly what to replay might be tricky.. I suppose it could keep track of where in the rebase the last skip was used, and then just go back to rebase and stop there again? That sounds like just redoing the rebase is easier.. (ie: use the reflog to go back to before the rebase started, and then re-run it again and don't skip this time).
Re: git-rebase --undo-skip proposal
2018-02-14 22:53 GMT-02:00 Johannes Schindelin: > Now, when is the next possible time you can call `git rebase --undo-skip`? What if the scope were reduced from `--undo-skip` to `--undo-last-skip`? Also, further reduce the scope to only allow `--undo-last-skip` during a ongoing rebase, not caring about a finished one? But, this could be so niche that I have doubts if this would ever be used;
Re: git-rebase --undo-skip proposal
On Wed, Feb 14, 2018 at 4:53 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi, > > On Wed, 14 Feb 2018, Psidium Guajava wrote: > >> On 2018-02-13 18:42 GMT-02:00 Stefan Beller <sbel...@google.com> wrote: >> > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava <psiid...@gmail.com> >> > wrote: >> > I think this could also be done with "git rebase --edit-todo", which brings >> > up the right file in your editor. >> >> Yeah that'd would only work if one started a rebase as a interactive >> one, not am or merge. > > I agree that the original proposal was clearly for the non-interactive > rebase (it talked about .git/rebase-apply/). > > The biggest problem with the feature request is not how useful it would > be: I agree it would be useful. The biggest problem is that it is a little > bit of an ill-defined problem. > > Imagine that you are rebasing 30 patches. Now, let's assume that patch #7 > causes a merge conflict, and you mistakenly call `git rebase --skip`. > > Now, when is the next possible time you can call `git rebase --undo-skip`? > It could be after a merge conflict in #8. Or in interactive rebase, after > a `pick` that was turned into an `edit`. Or, and this is also entirely > possible, after the rebase finished with #30 without problems and the > rebase is actually no longer in progress. > > So I do not think that there is a way, in general, to implement this > feature. Even if you try to remember the state where a `--skip` was > called, you would remember it in the .git/rebase-apply/ (or > .git/rebase-merge/) directory, which is cleaned up after the rebase > concluded successfully. So even then the information required to implement > the feature would not necessarily be there, still, when it would be needed. > > Ciao, > Johannes Instead of an "--undo-skip", what if we ask the question of what the user actually wants? Generally I'd assume that the user wishes to go back to the rebase and "pick" the commit back in. So what if we just make "git rebase --skip" more verbose so that it more clearly spells out which commit is being skipped? Possibly even as extra lines of "the following patches were skipped during the rebase" after it completes? Then it's up to the user to determine what to do with those commits, and there are many tools they could use to solve it, "git rebase -i, git cherry-pick, git reflog to restore to a previous and re-run the rebase, etc". Thanks, Jake
Re: git-rebase --undo-skip proposal
Hi, On Wed, 14 Feb 2018, Psidium Guajava wrote: > On 2018-02-13 18:42 GMT-02:00 Stefan Beller <sbel...@google.com> wrote: > > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava <psiid...@gmail.com> > > wrote: > > I think this could also be done with "git rebase --edit-todo", which brings > > up the right file in your editor. > > Yeah that'd would only work if one started a rebase as a interactive > one, not am or merge. I agree that the original proposal was clearly for the non-interactive rebase (it talked about .git/rebase-apply/). The biggest problem with the feature request is not how useful it would be: I agree it would be useful. The biggest problem is that it is a little bit of an ill-defined problem. Imagine that you are rebasing 30 patches. Now, let's assume that patch #7 causes a merge conflict, and you mistakenly call `git rebase --skip`. Now, when is the next possible time you can call `git rebase --undo-skip`? It could be after a merge conflict in #8. Or in interactive rebase, after a `pick` that was turned into an `edit`. Or, and this is also entirely possible, after the rebase finished with #30 without problems and the rebase is actually no longer in progress. So I do not think that there is a way, in general, to implement this feature. Even if you try to remember the state where a `--skip` was called, you would remember it in the .git/rebase-apply/ (or .git/rebase-merge/) directory, which is cleaned up after the rebase concluded successfully. So even then the information required to implement the feature would not necessarily be there, still, when it would be needed. Ciao, Johannes
Re: git-rebase --undo-skip proposal
On 2018-02-13 18:42 GMT-02:00 Stefan Bellerwrote: > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote: > I think this could also be done with "git rebase --edit-todo", which brings > up the right file in your editor. Yeah that'd would only work if one started a rebase as a interactive one, not am or merge. > cc'd Paul Tan, maybe he recalls the situation. >From what I've found on the archive, he didn't recently answer mails that come from the mail list, I could be wrong tho.
Re: git-rebase --undo-skip proposal
On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajavawrote: > Hello git community, > > I'd like to add a new feature in git-rebase: --undo-skip. > But first, I'd like to consult with the experts if it would be > beneficial for the project and if my line of tought is correct. > > Imagine that you are working on a feature for a long time, but there > are multiple bug fixes happening at `master` branch at the same time. > After lots of commits on both ends, you decide to rebase your changes > on top of the current `master` branch. > After lots of conflict resolution steps, you mistakenly call > `git-rebase --skip` instead of `git-rebase --continue`, thus losing a > commit of your work, and possibly inserting bugs in your project. > The only solution for this right now would be to abort the current > rebase and start over. > > It seems that a feature like this have been requested once on the mail list > [1]. > > I propose the existence of --undo-skip on git-rebase's `$action` domain. > > How I fixed it when that happened with me was (just after running the > wrong skip): > > 1. I figured I was making a rebase that used `git-am` as a backend. > 2. In the rebase-apply directory I searched for the patch file with > the change I just skipped. > 3. Found the `rebase-apply/next` file. > 4. Wrote the number of the patch I skipped - 1 in rebase-apply/next. > 5. run `git rebase --skip` again on the repository. > > This made the lost patch appear again and I could `--continue` it this time. I think this could also be done with "git rebase --edit-todo", which brings up the right file in your editor. > I propose the addition of an action `--undo-skip`, that could be > called only after a wrongfully called `--skip`. > `git rebase --undo-skip`. > I would implemented it to do programatically what I did by hand when > that happened with me. > > Here are my questions for you: > 1. Would this be beneficial for the users? I guess it is. > 2. For `rebase--am`, I would need to change `git-rebase--am.sh` file, correct? > 3. Can I assume `builtin/am.c` will always store its information on > `$state_dir/next` and `$state_dir/$patchnumbers`? > 4. How hard would it be to add that logic for `rebase--interactive` > and `rebase--merge` backends? cc'd Johannes who is currently working on revamping rebase. > > Also, a little unrelated with this issue: > 5. What happened to the rewrite of rebase in C [2]? I couldn't find > any information after 2016. > > [1] https://public-inbox.org/git/201311011522.44631.tho...@koch.ro/ > [2] > https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyoka...@gmail.com/ cc'd Paul Tan, maybe he recalls the situation.
git-rebase --undo-skip proposal
Hello git community, I'd like to add a new feature in git-rebase: --undo-skip. But first, I'd like to consult with the experts if it would be beneficial for the project and if my line of tought is correct. Imagine that you are working on a feature for a long time, but there are multiple bug fixes happening at `master` branch at the same time. After lots of commits on both ends, you decide to rebase your changes on top of the current `master` branch. After lots of conflict resolution steps, you mistakenly call `git-rebase --skip` instead of `git-rebase --continue`, thus losing a commit of your work, and possibly inserting bugs in your project. The only solution for this right now would be to abort the current rebase and start over. It seems that a feature like this have been requested once on the mail list [1]. I propose the existence of --undo-skip on git-rebase's `$action` domain. How I fixed it when that happened with me was (just after running the wrong skip): 1. I figured I was making a rebase that used `git-am` as a backend. 2. In the rebase-apply directory I searched for the patch file with the change I just skipped. 3. Found the `rebase-apply/next` file. 4. Wrote the number of the patch I skipped - 1 in rebase-apply/next. 5. run `git rebase --skip` again on the repository. This made the lost patch appear again and I could `--continue` it this time. I propose the addition of an action `--undo-skip`, that could be called only after a wrongfully called `--skip`. `git rebase --undo-skip`. I would implemented it to do programatically what I did by hand when that happened with me. Here are my questions for you: 1. Would this be beneficial for the users? 2. For `rebase--am`, I would need to change `git-rebase--am.sh` file, correct? 3. Can I assume `builtin/am.c` will always store its information on `$state_dir/next` and `$state_dir/$patchnumbers`? 4. How hard would it be to add that logic for `rebase--interactive` and `rebase--merge` backends? Also, a little unrelated with this issue: 5. What happened to the rewrite of rebase in C [2]? I couldn't find any information after 2016. [1] https://public-inbox.org/git/201311011522.44631.tho...@koch.ro/ [2] https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyoka...@gmail.com/ Best Regards, Gabriel Borges
Proposal
-- Hello i want to invest in your region i have some funds under my management please let me know if we can work together on this investment plan. Regards Melisa Mehmet
Proposal
-- Hello i want to invest in your region i have some funds under my management please let me know if we can work together on this investment plan. Regards Melisa Mehmet