From: Stefan Beller <stefanbeller@googlemail.com>
To: Junio C Hamano <gitster@pobox.com>, 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: Wed, 09 Oct 2013 20:27:58 +0200 [thread overview]
Message-ID: <5255A02E.3050405@googlemail.com> (raw)
In-Reply-To: <xmqqioxzxnjh.fsf@gitster.dls.corp.google.com>
Reigniting the discussion from three weeks ago:
I found it at http://git-blame.blogspot.de/search?q=leftover
On 09/17/2013 09:20 PM, Junio C Hamano wrote:
>
> 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.
I think forbidding such a checkout is a bit hard:
$ git checkout <branch>
fatal: checkout not possible, because of said reason (dangling pwd)
$ cd ../.. # go to top level or somewhere else unaffected
$ git checkout <branch> # this will work
Wouldn't it be better to navigate to the 'nearest' possible working dir on checkout?
Such a workflow would emerge:
$ git checkout <branch> # this includes the "cd .." of the previous step, it just went the dir structure up, until a valid dir was found.
warning: the current working directory is not part of the tree, navigating to $(PWD)
Personally I feel this is more what you'd actually want.
This discussion will become interesting once we have a commit (mostly?) renaming a folder:
dir1/* => dir2/*
If you're checking out accross such a change, we'd end up in the top level
directory, which is safe, but maybe not fully optimal. But still better than forbidding
it in the first run.
Stefan
next prev parent reply other threads:[~2013-10-09 18:28 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
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 [this message]
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=5255A02E.3050405@googlemail.com \
--to=stefanbeller@googlemail.com \
--cc=git@cryptocrack.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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).