{"@attributes":{"version":"2.0"},"channel":{"title":"Rohit Ashiwal","description":"Hello, I am Rohit Ashiwal","link":"https:\/\/rashiwal.me\/","pubDate":"Wed, 04 Feb 2026 07:35:06 +0000","lastBuildDate":"Wed, 04 Feb 2026 07:35:06 +0000","generator":"Jekyll v3.10.0","item":[{"title":"# The Final Report","description":"

Hey Everyone!<\/p>\n\n

My project was to improve the consistency of sequencer commands<\/a>. There are two backends available for rebasing, viz, the am and the interactive. Naturally, there shall be some features that are implemented in one but not in the other. The project aimed to remove inconsistencies in how the command line options are handled. A copy of my project proposal is hosted here<\/a>. The project was done under the guidance of Thomas Gummerer<\/a> and Elijah Newren<\/a>, two of the best Git developers.<\/p>\n\n

Let\u2019s dive into my journey of GSoC with Git!<\/em><\/p>\n\n

## Pre-GSoC Period<\/h2>\n\n

I started contributing to Git from this February where Dscho (aka Johannes) was mentoring me to remove an\u00a0external dependency<\/a>\u00a0of the MinGit package.<\/p>\n\n

After some time, I\u00a0introduced\u00a0myself<\/a> to Git where I picked a\u00a0micro-project<\/a> and continued working on it and improving my understanding of the mailing list. People at Git are extremely co-operative and the community is always active to help you 24x7. It\u2019s the time when I received some critical reviews and learned how things work in an organization. The interaction taught me the workflow and more importantly how important \u201cword choice\u201d is when committing.<\/p>\n\n

After several iterations and help from the people, I was able to complete my proposal that I finally submitted for GSoC \u201819. And yeah! I was selected for GSoC!<\/p>\n\n

## The \u201cPlan\u201d<\/h2>\n\n

I planned on completing the following tasks:<\/p>\n\n

1.<\/span> Suggest relevant flags for operations that have such a concept like git cherry-pick --skip\n2.<\/span> Unify the suggestive messages of git (cherry-pick|rebase-i) with git (am|rebase)\n3.<\/span> Implement flags that am-based rebases support, but not interactive, in interactive rebases, e.g.:\n\t--ignore-whitespace\n\t--committer-date-is-author-date\n\t--ignore-date (aka --reset-author-date)\n\t--whitespace=...\n4.<\/span> [Bonus] Make a flag to allow rebase to rewrite commit messages that refer to older commits that were also rebased\n5.<\/span> [Bonus] Performance run on different backends of rebasing, if everything agrees, deprecate am-based rebases\n<\/code><\/pre><\/div><\/div>\n\n
Alas! I was only able to complete the first two tasks and flags --ignore-whitespace, --committer-date-is-author-date and --ignore-date with almost no work done on --whitespace=\u2026 flags and [Bonus] features.<\/p>\n\n
## Phase 2<\/h2>\n\n
Most of the work was done in phase 2. I started by implementing and  polishing<\/a> --ignore-whitespace and --committer-date-is-author-date flags. The former was expected to appropriately handle whitespace changes while committing while the latter helped us to set the committer date equal to the value same as the author date. This was the time when I got familiar with the internal workings of the sequencer. I sent the patches for review while I started working on another flag --ignore-date. Review took a long time (Git community as always on their toes to only allow the most pristine code into their tree). By the time of phase 3 I was only able to work on these two flags :\/<\/p>\n\n
## Phase 3<\/h2>\n\n
The parallel submission<\/a> of the previous (two) patches was causing a mental mess, so I switched a new topic rebase-i-more-options<\/a>. It contained the previous patches along with the code of yet another flag --ignore-date (also aliased --reset-author-date). Since the polishing from phase 2 took a toll on time, I asked my mentors if we can start working on --whitespace=\u2026 flags while my patches were still in review to which they answered, \u201cIt\u2019s fine even if we are not able to meet all the goals, what\u2019s important is that we only allow well-tested and well-written code into the git\u2019s source\u201d. I agreed. I spent all my time in this phase to polish the patch series which was sent to the mailing list.<\/p>\n\n
## Post-GSoC<\/h2>\n\n
The project still requires the following to be done:<\/p>\n\n
1.<\/span> Introduce --whitespace=... flags\n2.<\/span> Work on the aforementioned bonus features\n<\/code><\/pre><\/div><\/div>\n\n
I am planning on continuing even after GSoC. I\u2019ll take the project to completion since I feel responsible for all the projects that I\u2019m part of.<\/p>\n\n
Best Wishes
\nRohit<\/p>\n\n
\n
### git log<\/h4>\n\n
The following commits were sent during GSoC \u201819 and they are currently present in git\/git\u2019s tree (master and proposed updates).<\/p>\n\n
ac9e40e8ef<\/a> Merge branch \u2018ra\/t3600-test-path-funcs\u2019<\/p>\n
A GSoC micro.\n\n* ra\/t3600-test-path-funcs:\n  t3600: use helpers to replace test -d\/f\/e\/s <path>\n  t3600: modernize style\n  test functions: add function `test_file_not_empty`\n<\/code><\/pre><\/div><\/div>\n\n
d97c62c828<\/a> Merge branch \u2018ra\/cherry-pick-revert-skip\u2019<\/p>\n
\"git cherry-pick\/revert\" learned a new \"--skip\" action.\n\n* ra\/cherry-pick-revert-skip:\n  cherry-pick\/revert: advise using --skip\n  cherry-pick\/revert: add --skip option\n  sequencer: use argv_array in reset_merge\n  sequencer: rename reset_for_rollback to reset_merge\n  sequencer: add advice for revert\n<\/code><\/pre><\/div><\/div>\n\n
966fc12521<\/a> Merge branch \u2018ra\/rebase-i-more-options\u2019 into pu<\/p>\n
\"git rebase -i\" learned a few options that are known by \"git\nrebase\" proper.\n\nLooking good.\n\n* ra\/rebase-i-more-options:\n  rebase: add --reset-author-date\n  rebase -i: support --ignore-date\n  sequencer: rename amend_author to author_to_rename\n  rebase -i: support --committer-date-is-author-date\n  sequencer: add NULL checks under read_author_script\n  rebase -i: add --ignore-whitespace flag\n<\/code><\/pre><\/div><\/div>\n\n
\n
Psst!<\/p>\n\n
I also have a repository<\/a> containing all the patches that I have sent (and will be sending) to the GIT mailing list. The work done under GSoC contains [GSoC] tag in the commit message. Clone the repo and use git log --grep=\"GSoC\"<\/code> to list all \u201cGSoC\u201d commits.<\/p>\n\n
\n
### Special Thanks<\/h4>\n\n
I\u2019d love to take some time and thank all the people who helped me to realize the project, especially:<\/p>\n\n
-<\/span> Christian Couder\n-<\/span> Elijah Newren\n-<\/span> Eric Sunshine\n-<\/span> Johannes Schindelin\n-<\/span> Junio C. Hamano\n-<\/span> Phillip Wood\n-<\/span> Thomas Gummerer\n<\/code><\/pre><\/div><\/div>\n\n
and many others. Thank you very much!<\/p>\n\n","pubDate":"Wed, 21 Aug 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/final-report\/","guid":"https:\/\/rashiwal.me\/2019\/final-report\/"},{"title":"# Another Iteration","description":"
Hey All!<\/p>\n\n
Sorry for a late post. Weeks are busy as we are in the middle of our internship season. I had to run between things and this is the time which I\u2019m able to factor out of my schedule.<\/p>\n\n
We are in the final week of GSoC now and I still yet to implement the --whitespace=<\u2026> flags. I\u2019ll try to, at least, form a minimal patch (or idea) of how these new set of flags should work. I may not be able to implement in the given time, but GSoC is not about completing the project, it\u2019s about introducing a student to the world of open source. And now that I am familiar with the code of git, I\u2019ll become a \u201cserial\u201d committer and will try to keep my project alive until completion.<\/p>\n\n
See ya!<\/p>\n\n","pubDate":"Mon, 12 Aug 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/another-iteration\/","guid":"https:\/\/rashiwal.me\/2019\/another-iteration\/"},{"title":"# The Discussion","description":"
Hey Everyone!<\/p>\n\n
As mentioned in the last week\u2019s post<\/a>, Junio pointed out that calling read_author_date_or_die() (now, read_author_date_or_null()) might<\/em> be unsafe as we might<\/em> not have a saved copy of the author information on the disk.<\/p>\n\n
The mentors and I had a long discussion on how the current calling of function is actually \u201csafe\u201d. Here is the thought process:<\/p>\n\n
    \n  
  1. do_pick_commit() and do_merge() always call write_author_script() to write author information to the disk before calling run_git_commit() so, we are sure to find the information there on the disk.<\/li>\n  
  2. commit_staged_changes() only calls run_git_commit() when it is stopped because of merge conflicts or by \u2018edit\u2019 todo commands. In this case, author_script is already written by the previous invocation of git. In all other cases, run_git_commit() throws an error as it should. So we are fine if read_author_date_or_null() also throws an error.<\/li>\n<\/ol>\n\n
    ## Current Work<\/h2>\n\n
    I am working on polishing my patches. The work is already done but before sending them to the mailing list I am thinking of updating my PR about introducing --ignore-date<\/a>.<\/p>\n\n
    If everything goes well, I\u2019ll have it done by tomorrow evening and will send all the commits under a new common topic \u201crebase-i-more-options\u201d (Junio named it :p) by Tuesday.<\/p>\n\n
    See ya!<\/p>\n\n","pubDate":"Sat, 03 Aug 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/the-discussion\/","guid":"https:\/\/rashiwal.me\/2019\/the-discussion\/"},{"title":"# Second Evaluation","description":"
    Hey Everyone!<\/p>\n\n
    Last week I sent two patched introducing \u2013ignore-whitespace and \u2013committer-date-is-author-date to the interactive rebase. Both received good reviews and I think \u2013ignore-whitespace is in a better condition now.<\/p>\n\n
    As for the other, I still need to get some work done. I modified the function read_env_script() to accept NULL arguments to selectively retrieve the required information. Also, I introduced read_author_date_or_die() to read the author date from disk using that modified function. The thing is, there are three callers of run_git_commit (which calls our baby function) and it turns out, as Junio pointed, calling them might not be safe as we might not have a saved copy of the author information on the disk. I\u2019m currently working on fixing this. This will significantly change the current implementation.<\/p>\n\n
    Phillip Wood mentioned that read_author_date_or_die() is not a good function, in essence, it kills the process in the library code. We try hard to keep the process from dying in a dirty state. So, it\u2019s better to give out an error and let the repo come to a \u201cclean\u201d state than error and die out. A piece of nice advice to keep in mind.<\/p>\n\n
    ## Other Stuff<\/h2>\n\n
    College<\/strong> Internship season is around the corner, so I had to spend some time with the Training and Placement team of the college to get my resume verified. This long<\/em> process kept me busy for the whole week! Other than that:<\/p>\n\n
    \"secone_evaluation\"<\/p>\n\n
    The results of GSoC second evaluation was out and I passed! The project is going in the right direction and that too pretty fast (compared to other projects in the past), hope all my patches get merged unifying behaviour of different sequencer commands.<\/p>\n\n
    Best!<\/p>\n","pubDate":"Fri, 26 Jul 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/second-evaluation\/","guid":"https:\/\/rashiwal.me\/2019\/second-evaluation\/"},{"title":"# A Tale of Two Patches","description":"
    Hey Everyone!<\/p>\n\n
    This week was very productive. I solved the part where we were spawning an octopus. It turns out that it also checks for the \u201cGIT_COMMITTER_DATE\u201d env variable and that reduced the work to a child\u2019s play.<\/p>\n\n
    For perfectionists, here is the full flow chart:<\/em><\/p>\n\n
    \"flow<\/p>\n\n
    Finally, I was able to send two patches for the review, here<\/a> and here<\/a>. Merging them will teach the interactive rebase the art of ignoring whitespace changes and lying about the committer date (by changing it to the author date). Since the patches were dependent on each other, in essence, they had overlapping codes, I had to base my second patch on the first. Because they were sent during weekends, they didn\u2019t receive any comments yet. But believe it will soon receive their critical eye soon.<\/p>\n\n
    ## Future Plans<\/h2>\n\n
    My college will re-open very soon, but I don\u2019t think that will hinder me from my work at Git. Workflow at Git allows even a busy student to work on his project without any (say) \u201cdelays\u201d since the community is spread across the globe, we are sure to receive the reviews \u2018round the clock.<\/p>\n\n
    I\u2019ll start working on --ignore-date flag which will help us \u201clie\u201d about the author date by ignoring the date author date in the patches and using the time of commit. Actually, I\u2019ve already started working on this and soon will submit a draft PR on GitHub.<\/p>\n\n
    Stay Tuned!<\/p>\n\n","pubDate":"Sun, 14 Jul 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/tale-of-two-patches\/","guid":"https:\/\/rashiwal.me\/2019\/tale-of-two-patches\/"},{"title":"# A Lie","description":"
    Hey Everyone!<\/p>\n\n
    It\u2019s almost time we fully implement --committer-date-is-author-date for rebase -i. For those who don\u2019t know, this flag helps us \u201clie\u201d about the committer date (making it equal to the author date).<\/p>\n\n
    ## Implementation<\/h2>\n\n
    Here is a flow chart showing the rough control flow of what happens when we run \u201cgit rebase -i <args>\u201d or \u201cgit rebase --continue\u201d.<\/p>\n\n
    \"flow<\/p>\n\n
    Both the commands (after executing \u201cepilogue\u201d) calls sequencer_continue which can be thought of as the driver function. As it is clear from the chart, in the end, all of the functions call either commit_tree_extended or run_git_commit. Both of them checks for GIT_COMMITTER_DATE env variable to set the committer date. We can easily read the author date from the author script which is saved under rebase_path_author_script()<\/a> and set the committer date to the value read. The catch here is, this all works only when we do not allow fast-forwards, i.e., we force<\/a> a rebase!<\/p>\n\n
    Also, I\u2019ve not explored the part<\/a> where we actually spawn an octopus merge to record a merge commit. I guess it also reads GIT_COMMITTER_DATE env variable somehow but we will only know for sure when we read the code ;)<\/p>\n\n
    Remember the \u201cepilogue\u201d I mentioned? It helps us sustain the --committer-date-is-author-date flag between interrupts. Something that am based rebase can\u2019t do :P We are basically saving it as a file under the rebase_path()<\/a> as rebase_path_cdate_is_adate() (subject to change) and checking<\/a> if this path exists to set the flag.<\/p>\n\n
    I still need to work on the documentation and tests for this new flag. Let\u2019s see, this flag will soon be a reality!<\/p>\n\n
    ## Other Stuff<\/h2>\n\n
    I was discussing with the mentors about my previous patch. It\u2019s about time we send it to the mailing list. There are some final checks that need to be clear. I can already see it in the git\/git tree :P<\/p>\n\n
    \u2018Till then!<\/p>\n\n","pubDate":"Sun, 07 Jul 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/a-lie\/","guid":"https:\/\/rashiwal.me\/2019\/a-lie\/"},{"title":"# First Evaluation","description":"
    Hey Everyone!<\/p>\n\n
    We are on a path to implement \u2013committer-date-is-author-date in rebase -i and this week I got to explore some parts of it, particularly the sequencer file. It is clear from the code that not only the functions directly spawning \u201cgit-commit\u201d can be \u201cfixed\u201d by setting GIT_COMMITTER_DATE variable but also some functions like commit_trees() which check for env variables will be fixed through this way. Moreover, I found that we might<\/em> need to change the merge mechanism code to handle the flag but more research is needed.<\/p>\n\n
    ## Other Stuff<\/h2>\n\n
    \"first_evaluation\"<\/p>\n\n
    The results of GSoC first evaluation was out and I passed!<\/p>\n","pubDate":"Fri, 28 Jun 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/first-evaluation\/","guid":"https:\/\/rashiwal.me\/2019\/first-evaluation\/"},{"title":"# Unproductive Week","description":"
    Hey Everyone!<\/p>\n\n
    Last week was even duller. I didn\u2019t get any time to work on the new flag \u2013committer-date-is-author-date. My mentors and I, all were busy with travelling and other stuff. But I discovered that setting GIT_COMMITTER_DATE environment variable through the code will not affect committer date during interactive rebase. The week ended with two more rounds of review of my earlier patch<\/a>. The good news is that my patch is now in Junio\u2019s tree<\/a>! And soon it will be merged in the main git\/git<\/a> repository.<\/p>\n\n
    ## Other Stuff<\/h2>\n\n
    Remember that foo.bar<\/a> challenge? Dude, it is real! I received a mail from the Google Staffing! Who knows I might fetch an internship at Google for real! I am very excited.<\/p>\n\n
    Thanks!<\/p>\n\n","pubDate":"Sat, 22 Jun 2019 00:00:00 +0000","link":"https:\/\/rashiwal.me\/2019\/unproductive-week\/","guid":"https:\/\/rashiwal.me\/2019\/unproductive-week\/"},{"title":"# Esoteric Teachings About Git Commit","description":"
    Hey Everyone!<\/p>\n\n
    Now that we know how to use git-commit and what commits are all about, we are ready to learn about some of the rules which will help us in efficient collaboration.<\/p>\n\n
Last week was spent polishing the patch<\/a> that I sent. From making the patch compile on Windows to factoring out code to changing documentation,  I had accounted for all the suggestions that I received there. The PR<\/a> which focused on adding --ignore-date to the interactive machinery was also added to the series. There was nothing new to the logical part, just changing the control path and introducing functions.<\/p>\n\n
## Phase 1<\/h2>\n\n
The phase started with teaching cherry-pick and revert to \u201cskip\u201d commits<\/a>. git am or rebase advice user to use\u00a0git am --skip\u00a0or\u00a0git rebase --skip\u00a0to skip the commit that has become empty or has risen conflict. OTOH, git\u00a0rebase -i\u00a0or\u00a0cherry-pick\u00a0advice user to use git reset HEAD which on the user\u2019s part is annoying and sometimes confusing. My\u00a0PATCH brought consistency between the advice of these commands by introducing --skip option to these subcommands.<\/p>\n\n