John Keeping writes:
> However, I think we do do a read_cache when using "reset --soft" since
> we go through builtin/reset.c::die_if_unmerged_cache() which dies if
> read_cache fails. So I don't think we are losing anything by moving
> this check earlier.
Thanks.
--
To unsubscribe from this li
On Wed, Sep 11, 2013 at 11:14:57AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Wed, Sep 11, 2013 at 10:08:18AM -0700, Junio C Hamano wrote:
> >> Duy Nguyen writes:
> >>
> >> > reset --soft does not go through these code paths (i.e. it does not
> >> > need index at all). If we f
John Keeping writes:
> On Wed, Sep 11, 2013 at 10:08:18AM -0700, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>> > reset --soft does not go through these code paths (i.e. it does not
>> > need index at all). If we fail to load index index in "reset --soft" I
>> > think it's ok to die(). Corru
On Wed, Sep 11, 2013 at 10:08:18AM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > reset --soft does not go through these code paths (i.e. it does not
> > need index at all). If we fail to load index index in "reset --soft" I
> > think it's ok to die(). Corrupt index is fatal anyway.
>
>
Duy Nguyen writes:
> reset --soft does not go through these code paths (i.e. it does not
> need index at all). If we fail to load index index in "reset --soft" I
> think it's ok to die(). Corrupt index is fatal anyway.
Do I smell a breakage here? Isn't "reset --soft HEAD" (or some
known good co
On Wed, Sep 11, 2013 at 6:08 PM, John Keeping wrote:
>> > -- >8 --
>> > diff --git a/builtin/reset.c b/builtin/reset.c
>> > index 9efac0f..800117f 100644
>> > --- a/builtin/reset.c
>> > +++ b/builtin/reset.c
>> > @@ -143,7 +143,6 @@ static int read_from_tree(const struct pathspec
>> > *pathspec,
On Wed, Sep 11, 2013 at 05:54:48PM +0700, Duy Nguyen wrote:
> On Wed, Sep 11, 2013 at 3:20 PM, John Keeping wrote:
> > On Wed, Sep 11, 2013 at 08:05:44AM +0200, Johannes Sixt wrote:
> >> Am 10.09.2013 21:13, schrieb John Keeping:
> >> > When using tab-completion, a directory path will often end wi
On Wed, Sep 11, 2013 at 3:20 PM, John Keeping wrote:
> On Wed, Sep 11, 2013 at 08:05:44AM +0200, Johannes Sixt wrote:
>> Am 10.09.2013 21:13, schrieb John Keeping:
>> > When using tab-completion, a directory path will often end with a
>> > trailing slash which currently confuses "git rm" when deal
On Wed, Sep 11, 2013 at 08:05:44AM +0200, Johannes Sixt wrote:
> Am 10.09.2013 21:13, schrieb John Keeping:
> > When using tab-completion, a directory path will often end with a
> > trailing slash which currently confuses "git rm" when dealing with
> > submodules. Now that we have parse_pathspec w
Am 10.09.2013 21:13, schrieb John Keeping:
> When using tab-completion, a directory path will often end with a
> trailing slash which currently confuses "git rm" when dealing with
> submodules. Now that we have parse_pathspec we can easily handle this
> by simply adding the PATHSPEC_STRIP_SUBMODUL
On Tue, Sep 10, 2013 at 09:37:45PM +0200, Jens Lehmann wrote:
> Am 10.09.2013 21:13, schrieb John Keeping:
> > When using tab-completion, a directory path will often end with a
> > trailing slash which currently confuses "git rm" when dealing with
>
> I think you meant to say "git reset" in the li
Am 10.09.2013 21:13, schrieb John Keeping:
> When using tab-completion, a directory path will often end with a
> trailing slash which currently confuses "git rm" when dealing with
I think you meant to say "git reset" in the line above. Apart from
that I'm all for it.
> submodules. Now that we ha
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses "git rm" when dealing with
submodules. Now that we have parse_pathspec we can easily handle this
by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
Signed-off-by: John Keeping
-
13 matches
Mail list logo
