git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Paul Tan <pyokagan@gmail.com>
Subject: Re: [PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree()
Date: Mon, 14 Mar 2016 14:42:32 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1603141410590.4690@virtualbox> (raw)
In-Reply-To: <xmqqk2ladx36.fsf@gitster.mtv.corp.google.com>

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.

  reply	other threads:[~2016-03-14 13:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-10 13:24 [PATCH] pull: drop confusing prefix parameter of die_on_unclean_work_tree() Johannes Schindelin
2016-03-10 17:54 ` Junio C Hamano
2016-03-10 18:09   ` Junio C Hamano
2016-03-14 13:42     ` Johannes Schindelin [this message]
2016-03-14 16:20       ` Junio C Hamano
2016-03-14 17:11         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1603141410590.4690@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pyokagan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).