Use commit/author dates relative to the commit, not Now() #5

kevinwallace · 2015-02-23T23:16:44Z

This makes gitbrute convenient to use on a series of commits after rebasing.
Otherwise, date information for those commits is completely destroyed.

This makes gitbrute convenient to use on a series of commits after rebasing. Otherwise, date information for those commits is completely destroyed.

Design inspired heavily by https://github.com/bradfitz/gitbrute . 'git hash-object ...' suggestion from rdebath in bradfitz#7 . Like bradfitz#5 , this program walks the commit and authorship dates backward, rather than the current date. Like bradfitz#8 , we have the same problem. Fortunately, current dates are 10 digits long; it would take about 2^58 iterations to actually come up with a shorter time_t in decimal; we're way too CPU limited to realistically be brute forcing hashes with 58 bits of prefix.

Use commit/author dates relative to the commit, not Now()

0000000

This makes gitbrute convenient to use on a series of commits after rebasing. Otherwise, date information for those commits is completely destroyed.

Strikeskids mentioned this pull request Jan 5, 2016

Date replacement fails if timestamp changes length #8

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Use commit/author dates relative to the commit, not Now() #5

Use commit/author dates relative to the commit, not Now() #5

Uh oh!

kevinwallace commented Feb 23, 2015

Uh oh!

Uh oh!

Use commit/author dates relative to the commit, not Now() #5

Are you sure you want to change the base?

Use commit/author dates relative to the commit, not Now() #5

Uh oh!

Conversation

kevinwallace commented Feb 23, 2015

Uh oh!

Uh oh!