On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:
> El 24/04/2010, a las 11:40, Jakub Narebski escribió:
> > I'd like for 'git commit -a' to *fail* if there are staged changes for
> > tracked files, excluding added, removed and renamed files.
Thanks for this suggestion, this is exactly what I wanted to propose!
+1 here.
I think this could even be made a default in some time, I don't see any
useful workflows this could prevent and adding -f is trivial enough for
those who really want to go forward.
> For me this is going to far. While we don't want to make it _easy_ for users
> to shoot themselves in the foot, neither do we want to make it difficult or
> impossible for them to get the tool to do things that _might_ be a mistake.
> And what's the risk here? Accidentally committing too much is not a
> destructive change, and can be easily undone.
Have you ever done this mistake? If you have done some extensive index
editing, it is actually a major PITA to restore, and can be even
destructive if your index and working tree are too much out-of-sync
(this does happen to me not so seldom while I also use -a a lot for
trivial commits).
> IMO, the fact that the commit message editor is populated with a list of
> changed files that will be included in the commit is enough for people to see
> what's actually going to happen.
BTW, I almost always use -m instead of the commit editor. ;-)
--
Petr "Pasky" Baudis
When I feel like exercising, I just lie down until the feeling
goes away. -- xed_over
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
