patchpull: drop confusing prefix parameter of die_on_unclean_work_tree()

In cmd_pull(), when verifying that there are no changes preventing a rebasing pull, we diligently pass the prefix parameter to the die_on_unclean_work_tree() function which in turn diligently passes it to the has_unstaged_changes() and has_uncommitted_changes() functions.

The casual reader might now be curious (as this developer was) whether that means that calling `git pull --rebase` in a subdirectory will ignore unstaged changes in other parts of the working directory. And be puzzled that `git pull --rebase` (correctly) complains about those changes outside of the current directory.

The puzzle is easily resolved: while we take pains to pass around the prefix and even pass it to init_revisions(), the fact that no paths are passed to init_revisions() ensures that the prefix is simply ignored.

That, combined with the fact that we will *always* want a *full* working directory check before running a rebasing pull, is reason enough to simply do away with the actual prefix parameter and to pass NULL instead, as if we were running this from the top-level working directory anyway.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 builtin/pull.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

Johannes Schindelin <johannes.schindelin@gmx.de> 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.

Junio C Hamano <gitster@pobox.com> writes:

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.

Hi Junio,

On Thu, 10 Mar 2016, Junio C Hamano wrote:

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.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

It tells the reader of this function that the caller has already moved to the top-level and as a633fca0 (Call setup_git_directory() much earlier, 2006-07-28) says, gives you the "prefix" (i.e. pathname of $PWD relative to the project root level). When you read the function, hence, you know "prefix" can be used to tell where originally the command was run from, if you want to learn it.

In other words, I didn't mean to argue anything like what you are saying. Either I phrased poorly, or you misread it.

For the purpose of letting "git pull --rebase" make sure that there is no difference between the index and the working tree, we'd want a tree-wide diff, so we do not want to limit the diff with pathspec. Not passing "prefix" to init_revisions() _is_ the right thing. Again, I think I said that in the message you are responding to, and either I phrased poorly, or you misread it.

In any case, that call to init_revisions() should have imitated what index_differs_from() and do_diff_cache() in diff-lib.c do, i.e. pass NULL as the prefix to say "I do not want any path/subdirectory limitation".

And there is no such idea. Again, perhaps I phrased the whole thing poorly or you misread it under the assumption that whenever I disagree with what you say, it is more likely what I say is incorrect.

I was talking about this sequence:

    $ edit rerere.c
    ... time passes ...
    $ cd Documentation/
    $ git pull --rebase
    error: Cannot pull with rebase: You have unstaged changes.
    ... oh, where do I have changes?
    $ git status -suno
     M ../rerere.c

which you may want to optimize the human-end-user experience by allowing 'pull --rebase' to say "You have unstaged changes in ../rerere.c" or something along that line [*1*] so that the user does not have to give a separate "git status" there.

And for that, the code that gives the error message needs to be able to access the "prefix" (i.e. pathname of $PWD relative to the project root level) to make that path relative in the output.

[Footnote]

*1* By "something along that line" I mean that you'd need to work out the details of what to do when there are too many of them, for example you wouldn't list everything but indicate that the list is truncated in some way.

Junio C Hamano <gitster@pobox.com> writes:

Oh, sorry, I think it is me who uses confusing phrasing, not your reading skills. What I meant by the above was:

 - We do want tree-wide diff.

 - We do not want to limit to a subtree.

 - Passing prefix to init_revisions() mean "if we have pathspec,
   they are relative to this prefix".

 - That may hint to the reader that the diff we are going to run may
   be limited to some subset to the tree, which is not what we are
   doing.

 - Hence, we should pass NULL to init_revisions() to make it
   explicit that we are not limiting.

 - And the part of your patch to pass NULL to init_revisions() is
   correct.

But the function itself should take prefix, even if it is not going to use it to call init_revisions(), because it makes it possible to do a better reporting later.