Re: why is git destructive by default? (i suggest it not be!)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Dmitry Potapov
Date: Wednesday, June 25, 2008 - 11:06 am

On Tue, Jun 24, 2008 at 10:13:13PM -0000, David Jeske wrote:

Why? Let's suppose you work with CVS and you started to edit some
file and then realize than the change that you make is stupid, would
not you want just to discard these change without committing them to
CVS?

Perhaps, you are confused by thinking that git commit and cvs commit
are conceptually same commands. IMHO, far better to analogue to cvs
commit would be git push to a repository with denyNonFastForwards
policy. Git commit allows you to save your changes locally as series
of patches, but until you have not pushed them, they are not in a
permanent storage. You can change these patches, which implies that
old versions may become dangling and will be removed after reflog
expired. The idea of making of making difficult to remove some local
commits is alike the idea of an editor making difficult to remove a
line... You gain nothing from that. What editors do instead is to
provide the Undo action. Similarly, Git allows you to get back to an
old state using the reflog.

Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: why is git destructive by default? (i suggest it not be!), Dmitry Potapov, (Wed Jun 25, 11:06 am)