Jeff King <peff@xxxxxxxx> writes:
> I agree that we agreed to disagree. But there is still one open
> question: would you take a patch for a "full-tree" config variable that
> would impact add (and probably grep) for 1.7.0?
Unless there is a simple and sane way for script writers (and by "script",
I do not mean "Porcelain that is supposed to be written using only the
plumbing", but things like scripts you would give to "git bisect run",
which would freely use Porcelains like "git reset" etc.) to defeat the
configuration without much pain, I am fairly negative on adding any
configuration variable of that nature.
We could probably declare "In 1.X.0 everything will be relative to the
root and you have to give an explicit '.' if you mean the cwd".
Three questions:
#1 What are the commands that will be affected, other than "add -u" and
"grep"? Are there others?
#2 Do all the commands in the answer to #1 currently behave exactly the
same when run without any path parameter and when run with a single
'.'?
#3 Do all the commands that are already relative to the root currently
limit their action to the cwd when run with a single '.'?
If the number of commands in the answer to #1 is not too excessive, it is
a plus, but even if it is more than just several, we will be getting
consistency and sanity if #2 and #3 hold. However, if there are even a
single violator in #2 and #3, we would need to fix them first before we
can proceed. And the transition clock starts ticking after everything is
fixed (if such a fix is indeed needed). As usual, I'd prefer to keep the
clock running for at least 6 months, preferrably longer, and during that
time, we may need the usual "You invoked me without any paths, but this
command will start behaving differently in 1.X.0, you have been warned."
A command line option to explicitly ask full-tree can be added anytime
without waiting for 1.7.0. I do not think it will be ready for 1.6.5 but
we can always have 1.6.6 if needed.
--
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