Re: [GSoC][PATCH v2 2/2] rebase -i: support --committer-date-is-author-date

From: Rohit Ashiwal <rohit.ashiwal265@gmail.com>
Date: Aug 2, 2019, 20:57 UTC
Message-ID: <20190802205731.13794-1-rohit.ashiwal265@gmail.com>
In-Reply-To: <xmqqwogdtzxc.fsf@gitster-ct.c.googlers.com>

Hi Junio

On Fri, 19 Jul 2019 15:36:15 -0700 Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

>
> [...]
> Hmph, are we sure that author-script is always available at this
> point so that a call to read_author_date_or_die() is safe?  There
> are three callers to the run_git_commit() function and I am not sure
> if codepaths that reach all of them prepared the input to the
> read_author_script() helper.

Functions do_pick_commit() and do_merge() always write author_script before calling run_git_commit(), so, we are sure to find it on disk. Furthermore, commit_staged_changes() only calls run_git_commit() when rebase is stopped (by merge conflicts or 'edit' commands), so we are sure that the previous invocation of git must have saved author_script. In all other cases, we fail as we should.

Show 9 quoted lines

> [...]
>
> In the same function, we seem to be grabbing the author ident by
> calling get_author(message), where the message is an in-core copy of
> a commit object, which suggests me that we may not necessarily be
> working with the on-disk information read_author_date_or_die() is
> prepared to deal with.  Are we sure we have the needed information
> on disk so that read_author_date_or_die() will read the correct
> information from the disk?

Yes, in that case, we can re-parse the author date and re-set the env variable while we are in this if branch. I believe that the information stored on the disk is same as the information retrieved through get_author(), please confirm or disprove this.

> [...]

With all this knowledge, I'll polish the patch and re-send it.

Thanks Rohit