Hi Junio, On Thu, 10 Mar 2016, Junio C Hamano wrote:
> Junio C Hamano <gits...@pobox.com> writes: > > > I think this is quite subjective, as I tend to take the presence of > > "prefix" to mean "the callee assumes that the caller has gone up to > > the root level already", and take the absense of use of "prefix" in > > the callee to mean "the callee is working on the whole tree", and > > discarding the parameter is robbing that clue from that point of > > view. > > > > So I am mildly opposed to most parts of this change, including not > > spelling out (void) as the list of parameters for a function that > > does not take any. > > > > I do think not passing "prefix" to init_revisions() would be the > > right thing. In fact, that prefix is copied to rev, but the current > > end result is correct _only_ because the pathspec limit given by > > that "prefix" parameter to init_revisions() is not automatically > > copied to rev_info.diffopt, and the code is very misleading. > > Another reason why it is more sensible to keep the prefix available, > but not use it to limit the extent of diff, to has_*_changes() > functions is that it would be easier for us to change our mind later > to allow the users to ask for more detailed output. Instead of > "Cannot pull with rebase: You have unstaged changes, period.", you > may be asked to list which paths are dirty in such a case, and in > order to present the list relative to the directory where the user > started the command, you would need "prefix" available to the code > that calls into diff machinery somehow. Let me summarize. First, you argue that the prefix is a documented way to say: "This function needs to be called from the top-level directory". Nevermind that the parameter reads "prefix" instead of "this_parameter_means_you_have_to_call_this_from_the_top_level_directory". And then you say that it is not a bug to pretend to use said "prefix" value by passing it to init_revisions() only to ignore it presently due to some chain of side effects. In short: there is no bug, even if the code is really confusing, so much so that this developer got highly confused. And after that, you continue by stating that we need to keep the "prefix" parameter because we *might*, *eventually* fix the bug (that is not a bug at all?!?!?!)? Now I am even more confused than before. Ciao, Dscho P.S.: The idea that a rebasing pull might, at some stage in the future, want to require only part of the working directory to be clean, this idea also makes little sense to me. -- 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
