Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > Changes since v5: > > - replaced a get_sha1() call by a get_oid() call already. > > - adjusted to hashmap API changes Applying this to the tip of 'master' yields exactly the same result as merging the previous round js/rebase-i-final to the tip of 'master' and then applying merge-fix/js/rebase-i-final to adjust to the codebase, so the net effect of this reroll is none. Which is a good sign, as it means there wasn't any rebase mistake and the evil merge we've been carrying was a good one. But at the same time, I prefer to avoid rebasing to newer 'master' until the codebase starts drifting too far apart, or until a new feature release is made out of newer 'master'. This is primarily because I want dates on commits to mean something---namely, "this change hasn't seen a need to be updated for 'oops, that was wrong' since this date". This use of commit dates as 'priority date' matters much less for a topic not in 'next', but as a general principle, my workflow tries to preserve commit dates for all topics. For the above reason, I may hold onto this patch series in my inbox without actually updating js/rebase-i-final topic until the current cycle is over; please do not mistake it as this new reroll being ignored. Thanks.
