[PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()

[PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()

[Johannes Schindelin]

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(-)

diff --git a/builtin/pull.c b/builtin/pull.c
index 10eff03..4ed46b3 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -308,12 +308,12 @@ static enum rebase_type config_get_rebase(void)
 /**
  * Returns 1 if there are unstaged changes, 0 otherwise.
  */
-static int has_unstaged_changes(const char *prefix)
+static int has_unstaged_changes()
 {
 	struct rev_info rev_info;
 	int result;
 
-	init_revisions(&rev_info, prefix);
+	init_revisions(&rev_info, NULL);
 	DIFF_OPT_SET(&rev_info.diffopt, IGNORE_SUBMODULES);
 	DIFF_OPT_SET(&rev_info.diffopt, QUICK);
 	diff_setup_done(&rev_info.diffopt);
@@ -324,7 +324,7 @@ static int has_unstaged_changes(const char *prefix)
 /**
  * Returns 1 if there are uncommitted changes, 0 otherwise.
  */
-static int has_uncommitted_changes(const char *prefix)
+static int has_uncommitted_changes()
 {
 	struct rev_info rev_info;
 	int result;
@@ -332,7 +332,7 @@ static int has_uncommitted_changes(const char *prefix)
 	if (is_cache_unborn())
 		return 0;
 
-	init_revisions(&rev_info, prefix);
+	init_revisions(&rev_info, NULL);
 	DIFF_OPT_SET(&rev_info.diffopt, IGNORE_SUBMODULES);
 	DIFF_OPT_SET(&rev_info.diffopt, QUICK);
 	add_head_to_pending(&rev_info);
@@ -345,7 +345,7 @@ static int has_uncommitted_changes(const char *prefix)
  * If the work tree has unstaged or uncommitted changes, dies with the
  * appropriate message.
  */
-static void die_on_unclean_work_tree(const char *prefix)
+static void die_on_unclean_work_tree()
 {
 	struct lock_file *lock_file = xcalloc(1, sizeof(*lock_file));
 	int do_die = 0;
@@ -355,12 +355,12 @@ static void die_on_unclean_work_tree(const char *prefix)
 	update_index_if_able(&the_index, lock_file);
 	rollback_lock_file(lock_file);
 
-	if (has_unstaged_changes(prefix)) {
+	if (has_unstaged_changes()) {
 		error(_("Cannot pull with rebase: You have unstaged changes."));
 		do_die = 1;
 	}
 
-	if (has_uncommitted_changes(prefix)) {
+	if (has_uncommitted_changes()) {
 		if (do_die)
 			error(_("Additionally, your index contains uncommitted changes."));
 		else
@@ -842,7 +842,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 
 		git_config_get_bool("rebase.autostash", &autostash);
 		if (!autostash)
-			die_on_unclean_work_tree(prefix);
+			die_on_unclean_work_tree();
 
 		if (get_rebase_fork_point(rebase_fork_point, repo, *refspecs))
 			hashclr(rebase_fork_point);
-- 
2.7.2.windows.1.8.g47d64e6.dirty

Re: [PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()

[Junio C Hamano]

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

> 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.

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.

Re: [PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()

[Junio C Hamano]

Junio C Hamano <gitster@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.

Re: [PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()

[Johannes Schindelin]

Hi Junio,

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

> Junio C Hamano <gitster@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.

Re: [PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()

[Junio C Hamano]

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

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".

> 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.

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.

Re: [PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()

[Junio C Hamano]

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

> 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.

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.