git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Lukas Fleischer <git@cryptocrack.de>
Cc: "Burton\, Ross" <ross.burton@intel.com>, git@vger.kernel.org
Subject: Re: Bisect needing to be at repo top-level?
Date: Tue, 17 Sep 2013 12:20:50 -0700	[thread overview]
Message-ID: <xmqqioxzxnjh.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20130917175813.GA14173@blizzard> (Lukas Fleischer's message of "Tue, 17 Sep 2013 19:58:13 +0200")

Lukas Fleischer <git@cryptocrack.de> writes:

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

No.  As the line you snipped from your quote says, it is just a
guess without running "git log -- git-bisect.sh git-bisect-script".

Also it points at things one needs to watch out for and think about
when attempting to update "git bisect" to make it possible to run it
anywhere in the working tree.

> why do we allow running git-checkout(1)
> from a subdirectory?

Oversight?

At least on Linux, if you checkout a revision with "foo/" directory,
chdir to it and then checkout a revision with "foo" file to nuke
your current place, I know "git checkout" will happily do so and you
will still be in a directory that is connected nowhere.  Your ".."
is probably pointing at the top-level, but there is no reverse, so
"cd ../foo" may or may not work from that state, and it would lead
to an interesting confusion.

We may want to check the condition and forbid such a checkout.

  reply	other threads:[~2013-09-17 19:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-17 16:31 Bisect needing to be at repo top-level? Burton, Ross
2013-09-17 17:27 ` Junio C Hamano
2013-09-17 17:58   ` Lukas Fleischer
2013-09-17 19:20     ` Junio C Hamano [this message]
2013-09-19 13:15       ` Ben Aveling
2013-09-19 22:46         ` Ben Aveling
2013-09-19 23:04           ` Junio C Hamano
2013-10-09 18:27       ` Stefan Beller
2013-10-09 18:55         ` Jeff King
2013-10-09 19:01           ` Stefan Beller
2013-09-17 18:38   ` Burton, Ross

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=xmqqioxzxnjh.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@cryptocrack.de \
    --cc=git@vger.kernel.org \
    --cc=ross.burton@intel.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).