On Wed, Sep 19, 2018 at 06:12:23PM +0200, Duy Nguyen wrote:
> On Wed, Sep 19, 2018 at 1:19 AM Jeff King wrote:
> >
> > On Tue, Sep 18, 2018 at 12:36:06PM -0700, Jacob Keller wrote:
> >
> > > > I like that, too. It's a little more costly just because it may involve
> > > > object-db writes, but I
On Wed, Sep 19, 2018 at 1:19 AM Jeff King wrote:
>
> On Tue, Sep 18, 2018 at 12:36:06PM -0700, Jacob Keller wrote:
>
> > > I like that, too. It's a little more costly just because it may involve
> > > object-db writes, but I think in most cases it would be fine. I almost
> > > always "git stash" a
On Tue, Sep 18, 2018 at 12:36:06PM -0700, Jacob Keller wrote:
> > I like that, too. It's a little more costly just because it may involve
> > object-db writes, but I think in most cases it would be fine. I almost
> > always "git stash" away discarded changes these days instead of "git
> > reset --
On Tue, Sep 18, 2018 at 12:41:30PM -0700, Jacob Keller wrote:
> I think having both is good. There are a lot of ways to accidentally
> throw away work, and it's pretty frustrating to have it happen. But
> the reflog is also somewhat complicated, and I've definitely seen a
> lot of developers who've
On Mon, Sep 17, 2018 at 12:26 PM Junio C Hamano wrote:
> FWIW, I didn't mean to say that we should give users a way to
> recover. Your "commit -a" or "commit $path" protection just
> prevents the situation from happening, and I think it is sufficient.
>
> The sole point I wanted to raise by bring
On Mon, Sep 17, 2018 at 11:15 AM Jeff King wrote:
>
> On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
>
> > > On the other hand, if I am keeping some change that should never be
> > > in a commit in the working tree file, and building the contents in
> > > the index using "add -p" to i
On Mon, Sep 17, 2018 at 10:09 AM Junio C Hamano wrote:
>
> It usually is safer (simply because you do not have to think about
> it) to start a behaviour change like this as a strict opt-in to gain
> confidence.
I tend to agree, however.. in this case it could be considered safer
to err on the sid
On Mon, Sep 17, 2018 at 08:41:36PM +0200, Duy Nguyen wrote:
> > I think the reflog approach has been successful: give these intermediate
> > states a name. So in theory I could do something like:
> >
> > git checkout -p :@{2.minutes.ago}
> >
> > though it would probably be useful to be able to w
Duy Nguyen writes:
> On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote:
>> ...
>> On the other hand, if I am keeping some change that should never be
>> in a commit in the working tree file, and building the contents in
>> the index using "add -p" to incrementally, it would be the same
>> dis
On Mon, Sep 17, 2018 at 8:15 PM Jeff King wrote:
> On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
> > I don't see a good way to get to recover this situation. I could go
> > back to the "index log" idea, where we keep a log of index changes (or
> > just "interesting" changes). That wa
On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
> > On the other hand, if I am keeping some change that should never be
> > in a commit in the working tree file, and building the contents in
> > the index using "add -p" to incrementally, it would be the same
> > disaster as you are try
On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This is about mixing "git add -p" and "git commit -a" (or "git commit
> > ") where you may accidentally lose staged changes. After the
> > discussion with Jonathan, I'm going with a bit different approac
Nguyễn Thái Ngọc Duy writes:
> This is about mixing "git add -p" and "git commit -a" (or "git commit
> ") where you may accidentally lose staged changes. After the
> discussion with Jonathan, I'm going with a bit different approach than
> v1, this behavior now becomes default, and if the user wa
This is about mixing "git add -p" and "git commit -a" (or "git commit
") where you may accidentally lose staged changes. After the
discussion with Jonathan, I'm going with a bit different approach than
v1, this behavior now becomes default, and if the user wants the old
behavior back, they can use
14 matches
Mail list logo
