Change timestamps while rebasing git branch

git git-rebase

34,928

Solution 1

git rebase --ignore-date

Solution 2

In my case rebasing changed timestamps to CommitDate value, so in gitweb a bunch of months old commits showed up as 4 days old. I found the last commit with the correct date and did:

$ git rebase --committer-date-is-author-date SHA

Solution 3

There are the following ways

Normal rebase
```
git rebase --ignore-date
```

Interactive rebase

git rebase -i master
git commit --amend --date=now
git push origin <branch> -f

Solution 4

From comments:

Incompatible with the --interactive option

Actually... it is no longer incompatible with Git 2.29 (Q4 2020): "git rebase -i"^(man) learns a bit more options.
Options which are compatible with:

--interactive/-i
--root!

See commit 6160b2e (26 Aug 2020) by Junio C Hamano (gitster).
See commit 2712669 (17 Aug 2020), and commit ef484ad (13 Jul 2020) by Rohit Ashiwal (r1walz).
See commit a3894aa, commit 7573cec, commit e8cbe21 (17 Aug 2020) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit 9c31b19, 03 Sep 2020)}

rebase -i: support --ignore-date

^{Original-patch-by: Rohit Ashiwal}
^{Signed-off-by: Phillip Wood}

Rebase is implemented with two different backends - 'apply' and 'merge' each of which support a different set of options.

In particular the apply backend supports a number of options implemented by 'git am^(man)' that are not implemented in the merge backend.
This means that the available options are different depending on which backend is used which is confusing.

This patch adds support for the --ignore-date option to the merge backend.

This option uses the current time as the author date rather than reusing the original author date when rewriting commits.
We take care to handle the combination of --ignore-date and --committer-date-is-author-date in the same way as the apply backend.

And:

rebase: add --reset-author-date

^{Helped-by: Junio C Hamano}
^{Signed-off-by: Rohit Ashiwal}

The previous commit introduced --ignore-date flag to rebase -i, but the name is rather vague as it does not say whether the author date or the committer date is ignored.
Add an alias to convey the precise purpose.

--reset-author-date

Also:

rebase -i: support --committer-date-is-author-date

^{Original-patch-by: Rohit Ashiwal}
^{Signed-off-by: Phillip Wood}

This patch adds support for the --committer-date-is-author-date option to the merge backend.
This option uses the author date of the commit that is being rewritten as the committer date when the new commit is created.

git rebase now includes in its man page:

--committer-date-is-author-date:

Instead of using the current time as the committer date, use the author date of the commit being rebased as the committer date.
This option implies --force-rebase.

git rebase also includes in its man page:

--ignore-date:

This flag is passed to 'git am' to change the author date of each rebased commit (see git am).

Note that in 2.29 (above), "--committer-date-is-author-date" option of "rebase" and "am" subcommands lost the e-mail address by mistake, which has been corrected with Git 2.29.1 (Q4 2020).

See commit 5f35edd, commit 16b0bb9, commit 56706db (23 Oct 2020) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit f34687d, 26 Oct 2020)}

am: fix broken email with --committer-date-is-author-date

^{Signed-off-by: Jeff King}

Commit e8cbe2118a (am: stop exporting GIT_COMMITTER_DATE, 2020-08-17) rewrote the code for setting the committer date to use fmt_ident(), rather than setting an environment variable and letting commit_tree() handle it.
But it introduced two bugs:

we use the author email string instead of the committer email

when parsing the committer ident, we used the wrong variable to compute the length of the email, resulting in it always being a zero-length string

This commit fixes both, which causes our test of this option via the rebase "apply" backend to now succeed.

And:

rebase: fix broken email with --committer-date-is-author-date

^{Reported-by: VenomVendor}
^{Signed-off-by: Jeff King}

Commit 7573cec52c ("rebase -i: support --committer-date-is-author-date", 2020-08-17, Git v2.29.0-rc0 -- merge listed in batch #13) copied the committer ident-parsing code from builtin/am.c.
And in doing so, it copied a bug in which we always set the email to an empty string.

We fixed the version in git-am in the previous commit; this commit fixes the copied code.

View more solutions

34,928

Author by

Ghork

I am the maintainer of Magit and the Emacsmirror

Updated on July 22, 2022

Comments

Ghork almost 2 years

I have reorganized the commits in a branch before it is going to be made public causing the timestamps of the commits to be in an mixed up order. I would rather have them be all be today with only seconds in between.

Obviously these time stamps won't be correct either, but since this is the time when things go public I prefer that over a mixed up history, time-wise.

So how do I tell git to create new timestamps while rebasing?
Ghork over 14 years

I believed to remember that it involved setting some envvar. (Actually I did check for that in the manpage but did not find anything. But I did not go through the options, because I was so certain it involved a envvar.)
Michael Krelin - hacker over 14 years

tarsius, I think you're talking about git filter-branch, but you don't really need it for a simple task like this.
Ghork over 14 years

Well actually it does not work with git from the master branch: git rebase -i --ignore-date a7a86fe error: unknown option `ignore-date' This seams to be a bug however: in the manpage this option actually is listed.
Michael Krelin - hacker over 14 years

I have tried it before posting.. Except for I haven't done it interactively, maybe that's the trick? Also, have you tried the --committer-date-is-author-date alias? Maybe the --ignore-date was introduced in later version, I have no idea.
Ghork over 14 years

Yes, if done non-interactively it works. But then - as always with rebase - the very first commit is not affected.
Tim over 8 years

@MichaelKrelin-hacker: according to the documentation, --ignore-date These flags are passed to git am to easily change the dates of the rebased commits (see git-am[1]). Incompatible with the --interactive option.
Tim over 8 years

@tarsius: the given commit SHA1 is the parent commit your editing the children from. You need such a basis to get the work done. You can't cut off the branch you're sitting on :)
Tim over 8 years

@MichaelKrelin-hacker What you can do is first git rebase --ignore-date to update author dates then git rebase -i to reorder/modify commits.
Michael Krelin - hacker over 8 years

@Tim, absolutely, though it wasn't me who needed that. Thanks for pointing that out in the docs though!
Ghork over 8 years

@Tim The root commit does not have a parent, and when I asked this question I also wanted to change the date of that commit. Now we have --root, which makes this possible.
Michael Krelin - hacker over 8 years

@tarsius, hey, thanks for telling, I didn't know about --root. Not that I immediately need it, but it's good to know.
Tim over 8 years

@tarsius --root is great to know. Thanks for sharing.
Michał Poreda over 8 years

No, it's not. In fact, it's the exact opposite. From the docs of git rebase: "These flags are passed to git am to easily change the dates of the rebased commits". In git am it says: --committer-date-is-author-date "[...]allows the user to lie about the committer date by using the same value as the author date" while --ignore-date "[...]allows the user to lie about the author date by using the same value as the committer date".
Vlastimil Ovčáčík about 7 years

Incompatible with the --interactive option. See docs
Michael Krelin - hacker about 7 years

@VlastimilOvčáčík, thanks, Tim said the same thing a year and a half ago :)
Vlastimil Ovčáčík about 7 years

@MichaelKrelin-hacker yeah :) I didn't notice it at first, so I made this eye catching comment and upvoted him.
Pablo Halpern over 3 years

Thank god for an easy-to-understand way to do the job for any kind of rebase! Thank you! I will use --date=new every time I use --amend from now on. IMO, any squash or fixup in an interactive rebase and any commit --amend should automatically update the timestamp now or at least to the date of the most recent of the combined commits. I don't think it can reasonably be argued that the combined commit should have the same timestamp as the first of the commits being combined, as though nothing had changed since then, and yet that's what we have today.
AlikElzin-kilaka about 3 years

I tried --reset-author-date together with -i and it worked perfectly!