On 25/04/2013 19:51, Junio C Hamano wrote:
Kevin Bracey <ke...@bracey.fi> 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.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to