"Burton, Ross" [off-list ref] writes:
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is there a reason for
needing to be at the top-level, or is this an old and redundant
message?
A wild guess.
Imagine if you start from a subdirectory foo/ but the directory did
not exist in the older part of the history of the project. When
bisect needs to check out a revision that was older than the first
revision that introduced that subdirectory, what should happen?
Worse yet, if "foo" was a file in the older part of the history,
what should happen?
On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote:
"Burton, Ross" [off-list ref] writes:
quoted
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is there a reason for
needing to be at the top-level, or is this an old and redundant
message?
A wild guess.
Imagine if you start from a subdirectory foo/ but the directory did
not exist in the older part of the history of the project. When
bisect needs to check out a revision that was older than the first
revision that introduced that subdirectory, what should happen?
Worse yet, if "foo" was a file in the older part of the history,
what should happen?
If that is the real explanation, why do we allow running git-checkout(1)
from a subdirectory?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17 September 2013 18:27, Junio C Hamano [off-list ref] wrote:
"Burton, Ross" [off-list ref] writes:
quoted
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is there a reason for
needing to be at the top-level, or is this an old and redundant
message?
A wild guess.
Imagine if you start from a subdirectory foo/ but the directory did
not exist in the older part of the history of the project. When
bisect needs to check out a revision that was older than the first
revision that introduced that subdirectory, what should happen?
Worse yet, if "foo" was a file in the older part of the history,
what should happen?
"git checkout" doesn't mandate that you're at the top-level, so that's
not a very strong argument.
Ross