Re: [RFC/PATCH] git checkout $tree path

From: Jay Soffian <jaysoffian@gmail.com>
Date: Oct 4, 2011, 15:05 UTC
Message-ID: <CAG+J_Dy7gnDEK-9KAJT4M_wumS_QpzLNMVzAiOHCyEbFBU65=w@mail.gmail.com>
In-Reply-To: <20111003102647.GD16078@sigill.intra.peff.net>

On Mon, Oct 3, 2011 at 6:26 AM, Jeff King <peff@peff.net> wrote:

Show 16 quoted lines

> On Thu, Sep 29, 2011 at 03:46:31PM -0700, Junio C Hamano wrote:
>> An alternative semantics could be to first remove paths that match the
>> given pathspec from the index, then update the index with paths taken from
>> the named tree, and update the working tree. "git checkout master dir"
>> would then mean "replace anything currently in dir with whatever is in dir
>> in master". It is more dangerous, and it can easily emulated by doing:
>
> being what the user expects. As in, "master deleted this file; shouldn't
> checkout pull the deletion to my new branch when I ask it to?".
>
> But we can't distinguish those two cases without actually having a merge
> base. And this isn't a merge; it's not about picking changes from
> master, it's about saying "make dir look like it does in master". So
> in that sense, the most straightforward thing is your second
> alternative: afterwards, we should have only the files in "dir" that
> master has.

I think I'd expect the first behavior with:

$ git checkout master -- dir/*

And the second with:

$ git checkout master -- dir

$0.02.

j.