Re: Bug: rebase -i creates committer time inversions on 'reword'

From: Phillip Wood <phil@philandanna.no-ip.org>
Date: Apr 14, 2018, 11:15 UTC
Message-ID: <f56b84fa-9286-3a7b-fc5b-2307c9ff5b5e@philandanna.no-ip.org>
In-Reply-To: <5f5d5b88-b3ac-ed4f-ee24-6ce2cba2bd55@kdbg.org>

On 13/04/18 17:52, Johannes Sixt wrote:

Show 10 quoted lines

> 
> I just noticed that all commits in a 70-commit branch have the same
> committer timestamp. This is very unusual on Windows, where rebase -i of
> such a long branch takes more than one second (but not more than 3 or
> so thanks to the builtin nature of the command!).
> 
> And, in fact, if you mark some commits with 'reword' to delay the quick
> processing of the patches, then the reworded commits have later time
> stamps, but subsequent not reworded commits receive the earlier time
> stamp. This is clearly not intended.

Oh dear, I think this is probably due to my series making rebase commit in-process when the commit message isn't being edited. I didn't realize that git cached the commit date rather than using the current time when calling commit_tree_extended(). I'll take a look at it next week. I think 'git am' probably gives all patches the same commit time as well if the commit date is cached though it wont suffer from the time-travel problem.

Best Wishes

Phillip

Show 18 quoted lines

> Perhaps something like this below is needed.
> 
> diff --git a/ident.c b/ident.c
> index 327abe557f..2c6bff7b9d 100644
> --- a/ident.c
> +++ b/ident.c
> @@ -178,8 +178,8 @@ const char *ident_default_email(void)
>  
>  static const char *ident_default_date(void)
>  {
> -	if (!git_default_date.len)
> -		datestamp(&git_default_date);
> +	strbuf_reset(&git_default_date);
> +	datestamp(&git_default_date);
>  	return git_default_date.buf;
>  }
>  
>