Re: [PATCH v5 02/17] sparse-checkout: create 'init' subcommand
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Nov 21, 2019, 14:28 UTC
- Message-ID
- <147bf5a9-6ae5-23ea-a007-68b8046c94ea@gmail.com>
- In-Reply-To
- <20191121114936.GR23183@szeder.dev>
On 11/21/2019 6:49 AM, SZEDER Gábor wrote:
Show 34 quoted lines
> On Mon, Oct 21, 2019 at 01:56:11PM +0000, Derrick Stolee via GitGitGadget wrote: >> Getting started with a sparse-checkout file can be daunting. Help >> users start their sparse enlistment using 'git sparse-checkout init'. >> This will set 'core.sparseCheckout=true' in their config, write >> an initial set of patterns to the sparse-checkout file, and update >> their working directory. > > Enabling sparse-checkout can remove modified files: > > $ mkdir dir > $ touch foo dir/bar > $ git add . > $ git commit -m Initial > [master (root-commit) ecc81bd] Initial > 2 files changed, 0 insertions(+), 0 deletions(-) > create mode 100644 dir/bar > create mode 100644 foo > $ echo changes >dir/bar > $ ~/src/git/git sparse-checkout init > error: Entry 'dir/bar' not uptodate. Cannot update sparse checkout. > error: failed to update index with new sparse-checkout paths > $ cat dir/bar > changes > > So far so good, my changes are still there. Unfortunately, however: > > $ git add -u > $ ~/src/git/git sparse-checkout init > $ echo $? > 0 > $ ls > foo > > Uh-oh, my changes are gone.
Here, your changes are not "lost", they are staged, correct? A "git status" should report that your changes are ready for committing. This seems to be the expected behavior.
As to your other message about leaving the sparse-checkout file even when the 'init' command fails, I'll fix that by using the in-process mechanism.
-Stolee