On Fri, Aug 24, 2018 at 7:42 AM Duy Nguyen wrote:
>
> On Fri, Aug 24, 2018 at 5:02 AM Jacob Keller wrote:
> >
> > On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote:
> > > I think the above example forgets "-a" on the final "git commit"
> > > step. With it added, I can understand the concern
On Fri, Aug 24, 2018 at 5:02 AM Jacob Keller wrote:
>
> On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote:
> > I think the above example forgets "-a" on the final "git commit"
> > step. With it added, I can understand the concern (and I am sure
> > you would, too).
> >
> > The user is trying
On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote:
> I think the above example forgets "-a" on the final "git commit"
> step. With it added, I can understand the concern (and I am sure
> you would, too).
>
> The user is trying to add everything done in the working tree, and
> "commit -a"
On Mon, Aug 20, 2018 at 8:43 AM Nguyễn Thái Ngọc Duy wrote:
> Instead, let's handle just this problem for now. This new option
> commit.preciousDirtyIndex, if set to false, will not allow `commit -a`
> to continue if the final index is different from the existing one. I
> don't think this can be
Duy Nguyen writes:
> On Thu, Aug 23, 2018 at 4:15 AM Jonathan Nieder wrote:
>> > The remaining question becomes scripts. A script might do
>> >
>> > ... modify old-file and create new-file ...
>> > git add new-file
>> > git commit -m "some great message"
>> >
>> > which would
On Thu, Aug 23, 2018 at 4:15 AM Jonathan Nieder wrote:
> > The remaining question becomes scripts. A script might do
> >
> > ... modify old-file and create new-file ...
> > git add new-file
> > git commit -m "some great message"
> >
> > which would trip this error. For that
A few quick corrections:
Jonathan Nieder wrote:
> I'm starting to lean toward having this on unconditionally, with a
> message that points the user who really doesn't want to clobber their
... who really *does* want to clobber their index ...
> index toward "git add -u", as a good idea. I
Duy Nguyen wrote:
> On Mon, Aug 20, 2018 at 9:30 PM Jonathan Nieder wrote:
>> I frequently use "git commit -a" this way intentionally, so I would be
>> unlikely to turn this config on. That leads me to suspect it's not a
>> good candidate for configuration:
>>
>> - it's not configuration for
On Mon, Aug 20, 2018 at 9:30 PM Jonathan Nieder wrote:
>
> Hi,
>
> Nguyễn Thái Ngọc Duy wrote:
>
> > So many times I have carefully cherry picked changes to the index with
> > `git add -p` then accidentally did `git commit -am ` (usually by
> > retrieving a command from history and pressing
Hi,
Nguyễn Thái Ngọc Duy wrote:
> So many times I have carefully cherry picked changes to the index with
> `git add -p` then accidentally did `git commit -am ` (usually by
> retrieving a command from history and pressing Enter too quickly)
> which destroyed beautiful index.
>
> One way to
On Mon, Aug 20, 2018 at 11:41 AM Nguyễn Thái Ngọc Duy wrote:
> One way to deal with this is some form of `git undo` that allows me to
> retrieve the old index. That's not a lot of work by itself. The problem
> is designing that `git undo` interface because there are more undo
> options that this.
Nguyễn Thái Ngọc Duy writes:
> +commit.preciousDirtyIndex::
> + If some changes are partially staged in the index (i.e.
> + "git commit -a" and "git commit" commit different changes), reject
> + "git commit -a".
Or perhaps better yet, go into yes/no interaction to confirm if you
So many times I have carefully cherry picked changes to the index with
`git add -p` then accidentally did `git commit -am ` (usually by
retrieving a command from history and pressing Enter too quickly)
which destroyed beautiful index.
One way to deal with this is some form of `git undo` that
13 matches
Mail list logo
