Le Friday 05 June 2009, Junio C Hamano a écrit : > Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > > because we will need to get more information from this function in > > some later patches. > > > > The new "int *count" parameter gives the number of commits left after > > the skipped commit have been filtered out. > > > > The new "int *skipped_first" parameter tells us if the first commit > > in the list has been skipped. Note that using this parameter also > > changes the behavior of the function if the first commit is indeed > > skipped. Because we assume that in this case we will want all the > > filtered commits, not just the first one, even if "show_all" is not > > set. > > The way you use (*skipped_first == -1) as a marker to mean "we've already > checked more than one commit_list so even when we see a one to be > skipped, it won't be the first one" is unreadable, especially without > explanation. Worse yet, the above paragraph explains what the parameter > does, but why is it so special to skip the one that happens to be the > first on the input list, especially when one does not know how the list > is sorted to begin with. I added the following comment before the function: /* * In this function, passing a not NULL skipped_first is very special. * It means that we want to know if the first commit in the list is * skipped because we will want to test a commit away from it if it is * indeed skipped. * So if the first commit is skipped, we cannot take the shortcut to * just "return list" when we find the first non skipped commit, we * have to return a fully filtered list. * * We use (*skipped_first == -1) to mean "it has been found that the * first commit is not skipped". In this case *skipped_first is set back * to 0 just before the function returns. */ I hope this is enough to clarify what this function does. > I understand that the list is sorted by the "goodness" value, i.e. the > one that cuts the graph into closer-to-equal halves comes earlier in the > list, but still it is unclear why having to skip the best one is so > special compared to having to skip say the second best one, especially > when you imagine a case where the first two on the list are of equal > "goodness" value. The reason why only having to skip the best one is special is just because it is simpler to only check if the best one is skipped or not. I agree that it could be an improvement to consider if other commits with the same goodness value are also skipped, but I think it would make the code more complex. Thanks, Christian. -- 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