Week 12: Patch series part 1 will queue!

PATCH SERIES PART 1 Last week, I sent my patch series part 1 v4. After some time without getting any answer, I started to get nervous because Outreachy’s deadline was close. Finally, after four days without news, I received an email saying the part 1 will queue. Great, I am so happy!!!. PATCH SERIES PART 2 Now, the next step is waiting until part 1 is in next branch to send patch series part 2. [Read More]

Week 11: Making connections

MAKING CONNECTIONS Proposed week theme by Outreachy was: “Making connections”. So, our goal this week was to start brain storming with our mentors about three people for us to approach for an informational chat about their career or their role as a free software contributor. We have some names on the table but we have to discuss a little more to have our final list. And after that I will contact them and with luck, I will schedule our chat. [Read More]

Week 10: Patch series v3 on review!

APPLYING SUGGESTIONS AND SENDING V3 Finishing the patch series v3 and sending it to Git mailing list was my objective for last week. One of the main tasks was to use an enum variable for returning error codes in bisect.c. This has been done including the corresponding enum and explanation in the commit it was introduced, changing return type in bisect.c functions headers and replacing number error codes with their corresponding enum codes in the return calls. [Read More]

Week 8: First review received

PATCH SERIES FIRST ROUND REVIEW After sending the patch series to Git mailing list, I have received some useful reviews. First, one interesting recommendation was to split the series into smaller groups in order to be easily reviewed. Let me remind that patch series was composed of 29 patches. In this respect, I am preparing a new patch series version with 11 patches that corresponds to preparatory and clean-up commits and all bisect. [Read More]

Week 7: Patch series sent!

LATEST COMMITS With previous patch series very near to be sent, I started working on future patches. Previous patch series changes end with a complete conversion of all shell commands to C, but git-bisect.sh still exists. To finish the porting to C, we have to get rid of the shell file. My work now consists on implementing the remaining changes in step by step commits, checking that all things compile and tests pass. [Read More]

Week 5 and 6: Refining patch series

REMOVING GOTO STATEMENTS In my previous post, I explained one of the improvements I was coding was removing goto statements of builtin/bisect-helper.c file. In my first approach, I got rid of all goto’s present in the file. They affected six functions and I made one commit per each one. After discussing with my mentor, only commits related to the patch series I am preparing will be sent and the rest will be done as improvement steps later on. [Read More]

Week 4: Introducing some improvements

NEW COMMITS I continued with the implementation of some suggestions and improvements this week. I focused on removing goto statements from builtin/bisect-helper.c file. For those not familiar with goto in C, it is a jump statement which transfers the program’s control from one statement to another (where some label is defined). The goto statement is generally discouraged in C, because it alters the sequential flow of logic that is one characteristic of C language. [Read More]

Week 3: preparation of patch series

NEW COMMITS Studying files related to git bisect I detected some parts that could be improved. After discussing my suggestions with my mentor, I included them in my working branch. Something I detected in builtin/bisect--helper.c and bisect.c was a mix of same evaluation conditions with different conventions. In some cases: if (!example_int_var) was used and in others: if (example_int_var == 0) I asked my mentor which one followed Git’s convention, which turned out to be the first one, and I fixed it. [Read More]

Week 2: Git rebasing and more!

Git rebase One of my tasks this second week was using interactive rebase to organize previous work. Interactive rebase, git rebase -i, is a useful and powerful command that allows you to change your commits in many ways such as editing, deleting, splitting and squashing. You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto. In my case: $git rebase -i HEAD~30 [Read More]