3 ms·
"If you've got an entire history that's been heavily-rebased and your problem is This bug started happening on Tuesday last week", you have a big problem: You c
by kderbe 13y ago
"If you've got an entire history that's been heavily-rebased and your problem is This bug started happening on Tuesday last week", you have a big problem: You can't just track back through your simple, linear branch until you get to last Tuesday's commits. You have to keep going back until you're absolutely certain there are no other commits further back in the history that are newer chronologically."
I think the author is mistaken. As mentioned by jedbrown, git has a separate AuthorDate and CommitDate, and rebase updates the CommitDate. You can see them both using:
git log --format=fuller
Furthermore, when you use @-limiting to filter logs by date, the CommitDate is used. For example, if you have a bug that started last Thursday, you can show all the commits that were either written or rebased since then with:
git log HEAD@{last.thusday}..
- gurkendoktor 13y agoI think this is the most important bit because it makes the whole article fall apart (for my use case - code reviews). Both my UI (Tower) and bitbucket sort by commit date. There is no way to sneak a broken commit into last week; for that I'd have to rebase master on top of the buggy commit.