On 25/04/2013 19:51, Junio C Hamano wrote:
Kevin Bracey <kevin@xxxxxxxxx> writes:
Thanks for the test addition. Maybe we will be able to satisfy your
greed in this series. There could be more worth doing here, and I
think getting TREESAME precise is key.
It is perfectly fine to do things one step at a time. Let's get
the --full-history change into a good shape first and worry about
the more complex case after we are done.
So do you see the rerun of try_to_simplify_commit() as acceptable? I'm
really not happy with it - it was fine for an initial proof-of-concept,
but it's an obvious waste of CPU cycles to recompute something we
already figured out, and I'm uncomfortable with the fact that the
function potentially does more than just compute TREESAME; by inspection
it seems safe given the known context inside simplify_merges(), but it
feels like something waiting to trip us up. The latter could be dealt
with by breaking try_to_simplify_commit() up, but that feels like a
diversion. I'd rather just get on and make this first patch store and
use the per-parent-treesame flags if feasible.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html