On Wed, Feb 20, 2019 at 5:05 AM Elijah Newren wrote:
>
> On Tue, Feb 19, 2019 at 11:10 AM Junio C Hamano wrote:
> >
> > Junio C Hamano writes:
> >
> > > I am getting the impression that to save typing, you would want to
> > > make "--index --worktree" the default (i.e. among the above, only
> >
On Wed, Feb 20, 2019 at 5:29 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > On Tue, Feb 19, 2019 at 11:10 AM Junio C Hamano wrote:
> >>
> >> Junio C Hamano writes:
> >>
> >> > I am getting the impression that to save typing, you would want to
> >> > make "--index --worktree" the defau
On Wed, Feb 20, 2019 at 2:10 AM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > I am getting the impression that to save typing, you would want to
> > make "--index --worktree" the default (i.e. among the above, only
> > --no-index and --no-worktree need to be spelled explicitly), but
> >
On Wed, Feb 20, 2019 at 5:36 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> As long as worktree-only mode does not lose track of a
> >> previously-untracked path in the index (perhaps use the i-t-a bit),
> >> I do not have a strong objection against making the worktree-only
> >> mode t
On Tue, Feb 19, 2019 at 2:36 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> As long as worktree-only mode does not lose track of a
> >> previously-untracked path in the index (perhaps use the i-t-a bit),
> >> I do not have a strong objection against making the worktree-only
> >> mode t
Elijah Newren writes:
>> As long as worktree-only mode does not lose track of a
>> previously-untracked path in the index (perhaps use the i-t-a bit),
>> I do not have a strong objection against making the worktree-only
>> mode the default.
>
> Could you unpack that for me a bit?
Suppose in an a
Elijah Newren writes:
> On Tue, Feb 19, 2019 at 11:03 AM Junio C Hamano wrote:
>> * --no-index --worktree ...
>>
>>Update only the working tree files without touching the index
>>(new feature that cannot be done with the current Git, although
>>"cat-file -p >path" may be close enoug
Elijah Newren writes:
> On Tue, Feb 19, 2019 at 11:10 AM Junio C Hamano wrote:
>>
>> Junio C Hamano writes:
>>
>> > I am getting the impression that to save typing, you would want to
>> > make "--index --worktree" the default (i.e. among the above, only
>> > --no-index and --no-worktree need to
On Tue, Feb 19, 2019 at 11:07 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Overall this looks good, but there's just one part that confuses me.
> > Here you seem to suggest that if you pass --source but neither --index
> > or --worktree that both the index and working tree will be wri
On Tue, Feb 19, 2019 at 11:03 AM Junio C Hamano wrote:
> * --no-index --worktree ...
>
>Update only the working tree files without touching the index
>(new feature that cannot be done with the current Git, although
>"cat-file -p >path" may be close enough at times), from the index
I
On Tue, Feb 19, 2019 at 11:10 AM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > I am getting the impression that to save typing, you would want to
> > make "--index --worktree" the default (i.e. among the above, only
> > --no-index and --no-worktree need to be spelled explicitly), but
> >
Junio C Hamano writes:
> I am getting the impression that to save typing, you would want to
> make "--index --worktree" the default (i.e. among the above, only
> --no-index and --no-worktree need to be spelled explicitly), but
> there is one glitch. Updating from the index must be spelled
> expl
Elijah Newren writes:
> Overall this looks good, but there's just one part that confuses me.
> Here you seem to suggest that if you pass --source but neither --index
> or --worktree that both the index and working tree will be written to.
> Why are "restored" changes considered ready for commit?
Duy Nguyen writes:
> On Sat, Feb 2, 2019 at 12:57 AM Junio C Hamano wrote:
>>
>> Duy Nguyen writes:
>>
>> > Of course we could just do --index and --worktree, each option
>> > restores the respective part. Then it's combinable (and extensible in
>> > the future). But then "git restore" means "g
On Tue, Feb 19, 2019 at 9:42 PM Elijah Newren wrote:
> > OK this hopefully will be the final design
> >
> > (git restore) "[--worktree] " restores worktree paths from index
> >
> > "--index " restores the index from HEAD (aka "git reset")
> >
> > "--source (--index|--worktree) " restores index or
Hi Duy,
On Mon, Feb 18, 2019 at 8:21 PM Duy Nguyen wrote:
>
> On Sat, Feb 2, 2019 at 12:57 AM Junio C Hamano wrote:
> >
> > Duy Nguyen writes:
> >
> > > Of course we could just do --index and --worktree, each option
> > > restores the respective part. Then it's combinable (and extensible in
> >
On Sat, Feb 2, 2019 at 12:57 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > Of course we could just do --index and --worktree, each option
> > restores the respective part. Then it's combinable (and extensible in
> > the future). But then "git restore" means "git restore --index
> > --work
On Sat, Feb 2, 2019 at 12:57 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > Of course we could just do --index and --worktree, each option
> > restores the respective part. Then it's combinable (and extensible in
> > the future). But then "git restore" means "git restore --index
> > --work
Duy Nguyen writes:
> Of course we could just do --index and --worktree, each option
> restores the respective part. Then it's combinable (and extensible in
> the future). But then "git restore" means "git restore --index
> --worktree" and typing "git restore --index" effectively removes the
> def
On Fri, Feb 1, 2019 at 2:05 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > I've changed my mind. I'm not using --index and --cached for "git
> > restore" (formerly "git restore-files"). So how about this?
> >
> > git restore --from= will update both the index and
> > worktree.
> >
> > gi
Duy Nguyen writes:
> I've changed my mind. I'm not using --index and --cached for "git
> restore" (formerly "git restore-files"). So how about this?
>
> git restore --from= will update both the index and worktree.
>
> git restore --from= --keep-index will not update the index
>
> git restore --
On Wed, Dec 12, 2018 at 2:23 AM Duy Nguyen wrote:
>
> On Tue, Dec 11, 2018 at 7:12 AM Elijah Newren wrote:
> >
> > On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano wrote:
> > >
> > > Duy Nguyen writes:
> > >
> > > > Elijah wanted another mode (and I agree) that modifies worktree but
> > > > leave
On 12/10, Elijah Newren wrote:
> On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
> >
> > Add a new --cached option to git checkout, which works only on the
> > index, but not the working tree, similar to what 'git reset
> > -- ... does. Indeed the tests are adapted from the 'git
> > reset
On Tue, Dec 11, 2018 at 7:12 AM Elijah Newren wrote:
>
> On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano wrote:
> >
> > Duy Nguyen writes:
> >
> > > Elijah wanted another mode (and I agree) that modifies worktree but
> > > leaves the index alone. This is most useful (or least confusing) when
> >
On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > Elijah wanted another mode (and I agree) that modifies worktree but
> > leaves the index alone. This is most useful (or least confusing) when
> > used with and would be default in restore-files. I'm not
> > saying
Duy Nguyen writes:
> Elijah wanted another mode (and I agree) that modifies worktree but
> leaves the index alone. This is most useful (or least confusing) when
> used with and would be default in restore-files. I'm not
> saying you have to implement it, but how do the new command line
> options
On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
>
> Add a new --cached option to git checkout, which works only on the
> index, but not the working tree, similar to what 'git reset
> -- ... does. Indeed the tests are adapted from the 'git
> reset' tests.
>
> In the longer term the idea is
On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
>
> Add a new --cached option to git checkout, which works only on the
> index, but not the working tree, similar to what 'git reset
> -- ... does.
Elijah wanted another mode (and I agree) that modifies worktree but
leaves the index alone. Th
Add a new --cached option to git checkout, which works only on the
index, but not the working tree, similar to what 'git reset
-- ... does. Indeed the tests are adapted from the 'git
reset' tests.
In the longer term the idea is to potentially deprecate 'git reset
-- ...', so the 'git reset' com
29 matches
Mail list logo
