git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Steffen Jost <jost@tcs.ifi.lmu.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Per Lundberg <per.lundberg@hibox.tv>,
	Joshua Jensen <jjensen@workspacewhiz.com>,
	Matthieu Moy <git@matthieu-moy.fr>,
	Clemens Buchacher <drizzd@gmx.net>,
	Holger Hellmuth <hellmuth@ira.uka.de>,
	Kevin Ballard <kevin@sb.org>
Subject: Re: [PATCH 1/1] Introduce "precious" file concept
Date: Wed, 20 Feb 2019 10:36:51 +0100	[thread overview]
Message-ID: <6c40dcc2-5ef1-7cfb-858d-029b72fa3709@tcs.ifi.lmu.de> (raw)
In-Reply-To: <87h8cy6cme.fsf@evledraar.booking.com>

On 20.02.19 10:19, Ævar Arnfjörð Bjarmason wrote:
> Most git users are at the level of only knowing very basic
> add/commit/pull/push command interaction. I feel strongly that we need
> to make our tools safe to use by default, and not require some
> relatively advanced "precious"/attribute facility to be carefully
> configured in advance so we don't throw away uncommitted work on the
> likes of merge/checkout.
> 
> 1. https://public-inbox.org/git/87zhuf3gs0.fsf@evledraar.gmail.com/
> 2. https://public-inbox.org/git/871s7r4wuv.fsf@evledraar.gmail.com/
> 

+1
Please consider that silently deleting files is a no-go.

I teach computer science, and our switch from subversion to git for our second year programming projects caused a lot of grief, so much that my colleagues consider switching back to subversion as the point of first contact with revisioning.

Silently deleting partially revisioned files is a major source: students regularly destroy IDE or OS specific config files that they cannot restore themselves. (Project participants use all kinds of different IDEs on different OSs and thus have all kinds of weird hidden files that always manage to get checked into the repository, wreaking havoc on another's machine. So they get deleted and thus disturb the student that needed those files.) We do provide a huge .gitignore that ought to prevent this, but despite numerous warnings they only add it later, which then causes previously checked-in files to be lost upon switching between branches.

Please, by default, issue at least a warning before files are irrevocably los - or maybe keep a local snapshot of everything for the last few checkout in order to undo them?


Thanks,
  Steffen.

-- 
+49-89-2180-9139
http://www.tcs.ifi.lmu.de/~jost/

Lehr- und Forschungseinheit für Theoretische Informatik
Ludwig-Maximilians-Universität München
Oettingenstr. 67 (E111)
80538 München
BAVARIA

  reply	other threads:[~2019-02-20  9:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-16 11:49 [PATCH 0/1] Introduce "precious" file attribute Nguyễn Thái Ngọc Duy
2019-02-16 11:49 ` [PATCH 1/1] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2019-02-16 19:36   ` Ævar Arnfjörð Bjarmason
2019-02-17  9:31     ` Duy Nguyen
2019-02-18  9:53       ` Ævar Arnfjörð Bjarmason
2019-02-18 10:14         ` Duy Nguyen
2019-02-19 18:08       ` Junio C Hamano
2019-02-20  1:35         ` Duy Nguyen
2019-02-20  8:31           ` Clemens Buchacher
2019-02-20 22:32           ` Junio C Hamano
2019-02-20  9:19         ` Ævar Arnfjörð Bjarmason
2019-02-20  9:36           ` Steffen Jost [this message]
2019-02-20  9:41           ` Duy Nguyen
2019-02-20 10:46             ` Ævar Arnfjörð Bjarmason
2019-02-20 11:11             ` Clemens Buchacher
2019-02-22  9:46               ` Duy Nguyen
2019-02-20 22:39             ` Junio C Hamano
2019-02-22  9:35               ` Duy Nguyen
2019-02-22 18:07                 ` Junio C Hamano

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=6c40dcc2-5ef1-7cfb-858d-029b72fa3709@tcs.ifi.lmu.de \
    --to=jost@tcs.ifi.lmu.de \
    --cc=avarab@gmail.com \
    --cc=drizzd@gmx.net \
    --cc=git@matthieu-moy.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hellmuth@ira.uka.de \
    --cc=jjensen@workspacewhiz.com \
    --cc=kevin@sb.org \
    --cc=pclouds@gmail.com \
    --cc=per.lundberg@hibox.tv \
    /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).