git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jacob Keller <jacob.keller@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Git mailing list <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content
Date: Tue, 18 Sep 2018 12:41:30 -0700	[thread overview]
Message-ID: <CA+P7+xq1zMM=S+HBTAfTJcPVo35PtUCq+staQ8SnSXxP0RShXA@mail.gmail.com> (raw)
In-Reply-To: <xmqq7ejk6i46.fsf@gitster-ct.c.googlers.com>

On Mon, Sep 17, 2018 at 12:26 PM Junio C Hamano <gitster@pobox.com> 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 bringing up the above was that
> we should have the same degree of protection against "add $path" or
> "add -u".
>
> Of course, "index log" is interesting and it may even turn out to be
> useful (I was skeptical about "reference log" the same way, but it
> turned out to be useful without burdening the system too heavily),
> and it may even remove the need for the "do not accidentally lose
> information by adding more to the index" protection.  But until that
> happens, if we are to have such a protection, we would wnat to give
> the same degree of protection to "commit" and "add".

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 never heard of it, and struggle with the
concept.

I personally think having the nice "it looks like you're about to
throw away all your changes, are you sure" style of protection using
something like --clobber-index is useful as a mode, even if we have an
index log of sorts. Having it be default helps new people, even if it
does get in the way of someone who knows what they're doing. Having it
be configurable, to me, sort of defeats the point, since it means
having to tell people to turn this on.

I personally don't mind having to type an extended option to clobber
when I know it's what I want, but I can see that being painful.

However, if we had a reflog for the index, this becomes less of a
problem since recovery is much easier.

Thanks,
Jake

  reply	other threads:[~2018-09-18 19:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-20 15:41 [PATCH/RFC] commit: new option to abort -a something is already staged Nguyễn Thái Ngọc Duy
2018-08-20 15:55 ` Junio C Hamano
2018-08-20 17:48 ` Eric Sunshine
2018-08-20 19:30 ` Jonathan Nieder
2018-08-21 14:43   ` Duy Nguyen
2018-08-23  2:11     ` Jonathan Nieder
2018-08-23  2:15       ` Jonathan Nieder
2018-08-23 14:49         ` Duy Nguyen
2018-08-23 15:28           ` Junio C Hamano
2018-08-24  3:02             ` Jacob Keller
2018-08-24 14:42               ` Duy Nguyen
2018-08-24 23:23                 ` Jacob Keller
2018-08-24  2:59 ` Jacob Keller
2018-09-16  6:31 ` [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content Nguyễn Thái Ngọc Duy
2018-09-16  6:31   ` [PATCH v2 1/1] commit: do not clobber the index Nguyễn Thái Ngọc Duy
2018-09-17 17:09   ` [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content Junio C Hamano
2018-09-17 17:29     ` Duy Nguyen
2018-09-17 18:15       ` Jeff King
2018-09-17 18:41         ` Duy Nguyen
2018-09-18 17:35           ` Jeff King
2018-09-18 19:36         ` Jacob Keller
2018-09-18 23:19           ` Jeff King
2018-09-19 16:12             ` Duy Nguyen
2018-09-19 16:16               ` Jeff King
2018-09-17 19:26       ` Junio C Hamano
2018-09-18 19:41         ` Jacob Keller [this message]
2018-09-18 21:11           ` Eckhard Maaß
2018-09-18 19:33     ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+P7+xq1zMM=S+HBTAfTJcPVo35PtUCq+staQ8SnSXxP0RShXA@mail.gmail.com' \
    --to=jacob.keller@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).