From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:41
[topic: making ‘git commit’ more helpful when there are no changes
registered in the index]
Hi Goswin,
Goswin von Brederlow wrote:
in most (all but git?) RCS a plain 'commit' without any arguments
commits all changes (to registered files).
Yes, but they are wrong. :)
no changes added to commit (use "git add" and/or "git commit -a")
[...]
Imho in most cases where no changes
were added people do want to commit all modified files. And if not
then exiting the editor to abort is easy enough.
I absent-mindedly type ‘git commit’ having forgotten to update the
index with my changes fairly often. Then I add the appropriate
changes, which is almost never all of them. I don’t think this is so
unusual.
Starting out, I can see how it would be comforting to people if
‘git commit’ would default to -a behavior if they ignore the index.
That is logically a different operation, though, so it would also send
a wrong message and make it harder in the long run to get used to the
interface.
Instead, I think it would be better to focus on making the error
message more helpful. Right now there is a screen full of status
before the advice, which might make it easy to get scared before
reading it.
Here’s a very rough patch to suppress that screenful. What do you
think?
@@ -589,6 +589,24 @@ static void wt_status_print_tracking(struct wt_status *s)color_fprintf_ln(s->fp,color(WT_STATUS_HEADER,s),"#");}+voidwt_status_print_nochanges(structwt_status*s)+{+if(s->amend)+fprintf(s->fp,"# No changes\n");+elseif(s->nowarn)+;/* nothing */+elseif(s->workdir_dirty)+printf("no changes added to commit (use \"git add\" and/or \"git commit -a\")\n");+elseif(s->untracked.nr)+printf("nothing added to commit but untracked files present (use \"git add\" to track)\n");+elseif(s->is_initial)+printf("nothing to commit (create/copy files and use \"git add\" to track)\n");+elseif(!s->show_untracked_files)+printf("nothing to commit (use -u to show untracked files)\n");+else+printf("nothing to commit (working directory clean)\n");+}+voidwt_status_print(structwt_status*s){constchar*branch_color=color(WT_STATUS_HEADER,s);
@@ -629,22 +647,8 @@ void wt_status_print(struct wt_status *s)if(s->verbose)wt_status_print_verbose(s);-if(!s->commitable){-if(s->amend)-fprintf(s->fp,"# No changes\n");-elseif(s->nowarn)-;/* nothing */-elseif(s->workdir_dirty)-printf("no changes added to commit (use \"git add\" and/or \"git commit -a\")\n");-elseif(s->untracked.nr)-printf("nothing added to commit but untracked files present (use \"git add\" to track)\n");-elseif(s->is_initial)-printf("nothing to commit (create/copy files and use \"git add\" to track)\n");-elseif(!s->show_untracked_files)-printf("nothing to commit (use -u to show untracked files)\n");-else-printf("nothing to commit (working directory clean)\n");-}+if(!s->commitable)+wt_status_print_nochanges(s);}staticvoidwt_shortstatus_unmerged(intnull_termination,structstring_list_item*it,
I'd also concur that "default to commit -a" would be a most undesireable
astonishment for me. Please don't go that way. Thanks.
(Not that I believe it stands a chance of upstream integration, but to avoid
downstream distro-specific shipwrecks.)
--
Matthias Andree
From: Michael Witten <hidden> Date: 2016-06-15 22:48:41
On Fri, Apr 23, 2010 at 13:59, Matthias Andree [off-list ref] wrote:
I'd also concur that "default to commit -a" would be a most undesireable
The proposal was not "default to commit -a" but rather "default to
commit -a when the index has not been explicitly updated with
something like git add".
Just sayin'.
On Fri, Apr 23, 2010 at 13:59, Matthias Andree [off-list ref] wrote:
quoted
I'd also concur that "default to commit -a" would be a most undesireable
The proposal was not "default to commit -a" but rather "default to
commit -a when the index has not been explicitly updated with
something like git add".
Which is the same:
default (n) (5b) "a selection automatically used by a computer program
in the absence of a choice made by the user" (Merriam-Webster)
No previous "git add" => default "git commit -a". Exactly what I don't
want. It makes the software appear at nondeterministic as you add to
the "if"s and "but"s, and it breaks established practice.
It is not desirable to break established workflows for the sake of
newcomers' convenience.
From: Eric Raymond <hidden> Date: 2016-06-15 22:48:41
Matthias Andree [off-list ref]:
Am 23.04.2010 21:34, schrieb Michael Witten:
quoted
On Fri, Apr 23, 2010 at 13:59, Matthias Andree [off-list ref] wrote:
quoted
I'd also concur that "default to commit -a" would be a most undesireable
The proposal was not "default to commit -a" but rather "default to
commit -a when the index has not been explicitly updated with
something like git add".
Which is the same:
default (n) (5b) "a selection automatically used by a computer program
in the absence of a choice made by the user" (Merriam-Webster)
No previous "git add" => default "git commit -a". Exactly what I don't
want. It makes the software appear at nondeterministic as you add to
the "if"s and "but"s, and it breaks established practice.
It is not desirable to break established workflows for the sake of
newcomers' convenience.
Speaking as a relative newcomer, I concur. Commands that are simpler
to mentally model, because they don't have a lot of exception cases,
are better.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
From: Michael Witten <hidden> Date: 2016-06-15 22:48:41
On Fri, Apr 23, 2010 at 17:18, Matthias Andree [off-list ref] wrote:
Am 23.04.2010 21:34, schrieb Michael Witten:
quoted
On Fri, Apr 23, 2010 at 13:59, Matthias Andree [off-list ref] wrote:
quoted
I'd also concur that "default to commit -a" would be a most undesireable
The proposal was not "default to commit -a" but rather "default to
commit -a when the index has not been explicitly updated with
something like git add".
Which is the same:
default (n) (5b) "a selection automatically used by a computer program
in the absence of a choice made by the user" (Merriam-Webster)
No previous "git add" => default "git commit -a". Exactly what I don't
want. It makes the software appear at nondeterministic as you add to
the "if"s and "but"s, and it breaks established practice.
It wasn't at all clear that's what you meant.
It is not desirable to break established workflows for the sake of
newcomers' convenience.
It's not entirely clear (to me) that Goswin's proposal really breaks
established workflow.
From: Michael Witten <hidden> Date: 2016-06-15 22:48:41
On Fri, Apr 23, 2010 at 17:25, Eric Raymond [off-list ref] wrote:
Commands that are simpler
to mentally model, because they don't have a lot of exception cases,
are better.
The UNIX philosophy: "Provide mechanism, not policy."
Some goofball touched upon this subject in a little-read book called
"The Art of Unix Programming", specifically:
What Unix Gets Wrong
http://www.faqs.org/docs/artu/ch01s04.html
...
But the cost of the mechanism-not-policy
approach is that when the user can set policy,
the user must set policy. Nontechnical end-users
frequently find Unix's profusion of options and
interface styles overwhelming and retreat to
systems that at least pretend to offer them
simplicity.
In the short term, Unix's laissez-faire approach
may lose it a good many nontechnical users. In
the long term, however, it may turn out that this
‘mistake’ confers a critical advantage — because
policy tends to have a short lifetime, mechanism
a long one. Today's fashion in interface look-and-feel
too often becomes tomorrow's evolutionary dead
end (as people using obsolete X toolkits will tell
you with some feeling!). So the flip side of the flip
side is that the “mechanism, not policy” philosophy
may enable Unix to renew its relevance long after
competitors more tied to one set of policy or
interface choices have faded from view.[6]
:-D
Sincerely,
Michael Witten
From: Eric Raymond <hidden> Date: 2016-06-15 22:48:42
Michael Witten [off-list ref]:
On Fri, Apr 23, 2010 at 17:25, Eric Raymond [off-list ref] wrote:
quoted
Commands that are simpler
to mentally model, because they don't have a lot of exception cases,
are better.
The UNIX philosophy: "Provide mechanism, not policy."
And commands that are simple, orthogonal, and easy to mentally model do that.
You get to provide the policy you want by scripting them.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
From: Eric Raymond <hidden> Date: 2016-06-15 22:48:42
Michael Witten [off-list ref]:
On Fri, Apr 23, 2010 at 23:38, Eric Raymond [off-list ref] wrote:
quoted
And commands that are simple, orthogonal, and easy to mentally model do that.
You get to provide the policy you want by scripting them.
Just to clarify, I wasn't trying to contradict your conclusions.
I thought you might be, then realized you might not be, and tried to stick
to saying nomething neutrally affirmative that would be appropriate in
either case.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:42
Jonathan Nieder [off-list ref] writes:
Starting out, I can see how it would be comforting to people if
‘git commit’ would default to -a behavior if they ignore the index.
That is logically a different operation, though, so it would also send
a wrong message and make it harder in the long run to get used to the
interface.
I agree that making 'git commit' do 'git commit -a' if there are no
staged changes would be a bad change.
Instead, I think it would be better to focus on making the error
message more helpful. Right now there is a screen full of status
before the advice, which might make it easy to get scared before
reading it.
Here’s a very rough patch to suppress that screenful. What do you
think?
It's a pity that people didn't concentrate on this part: improving
error message...
On a bit unrelated note what I'd like to have is 'git commit -a'
(optional) safety against accidentally getting rid of staged changes.
I'd like for 'git commit -a' to *fail* if there are staged changes for
tracked files, excluding added, removed and renamed files. If you
have some staged changes you would get an error message:
$ git add tracked-file
$ git commit -a
fatal: There are staged changes to tracked files
hint: To commit staged changes, use 'git commit'
hint: To commit all changes, use 'git commit -f -a'
Perhaps this behavior would be turned on only if some config option,
like commit.preserveIndex or something like that is set to true...
--
Jakub Narebski
Poland
ShadeHawk on #git
El 24/04/2010, a las 11:40, Jakub Narebski escribió:
It's a pity that people didn't concentrate on this part: improving
error message...
On a bit unrelated note what I'd like to have is 'git commit -a'
(optional) safety against accidentally getting rid of staged changes.
I'd like for 'git commit -a' to *fail* if there are staged changes for
tracked files, excluding added, removed and renamed files. If you
have some staged changes you would get an error message:
$ git add tracked-file
$ git commit -a
fatal: There are staged changes to tracked files
hint: To commit staged changes, use 'git commit'
hint: To commit all changes, use 'git commit -f -a'
Perhaps this behavior would be turned on only if some config option,
like commit.preserveIndex or something like that is set to true...
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.
Where do we stop here with the hand-holding? Would you also want a fatal error here?:
$ git add foo
$ git commit -- bar
fatal: There are staged changes to tracked files
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.
Cheers,
Wincent
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:42
Dnia sobota 24. kwietnia 2010 13:10, Wincent Colaiuta napisał:
El 24/04/2010, a las 11:40, Jakub Narebski escribió:
quoted
It's a pity that people didn't concentrate on this part: improving
error message...
On a bit unrelated note what I'd like to have is 'git commit -a'
(optional) safety against accidentally getting rid of staged
changes.
I'd like for 'git commit -a' to *fail* if there are staged changes for
tracked files, excluding added, removed and renamed files. If you
have some staged changes you would get an error message:
$ git add tracked-file
$ git commit -a
fatal: There are staged changes to tracked files
hint: To commit staged changes, use 'git commit'
hint: To commit all changes, use 'git commit -f -a'
Perhaps this behavior would be turned on only if some config option,
like commit.preserveIndex or something like that is set to true...
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.
What you cant recover by undoing commit is the state of index before
accidental 'git commit -a' instead of 'git commit'.
Where do we stop here with the hand-holding? Would you also want
a fatal error here?:
$ git add foo
$ edit foo # without this safety would not trigger for "git commit -a"
$ git commit bar
fatal: There are staged changes to tracked files
No, I wouldn't. First, there is much less chance of mistake here, IMHO,
and second you don't loose staged changes to 'foo' here.
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.
Note that in original post there was patch restructuring a bit this info,
for relevant information to be more visible.
--
Jakub Narebski
Poland
From: Tor Arntsen <hidden> Date: 2016-06-15 22:48:42
On Fri, Apr 23, 2010 at 21:34, Michael Witten [off-list ref] wrote:
The proposal was not "default to commit -a" but rather "default to
commit -a when the index has not been explicitly updated with
something like git add".
For what it's worth, from another relative newcomer: The above would
actually cause trouble sometimes for me. Having learned to use git
add+git commit, and working on several things at once:
edit file1
edit file2
edit file3
git add file3
git commit -m"fixed file3"
In the above sequence (relative newcomer, but not entirely) I
occasionally forget to do the 'git add file3' part (I just mistakenly
thought I did). The way it works now means nothing happens, which is
good. The way I understand the proposal I would instead end up with a
commit of all my changed files, which is exactly not what I want.
I can't stop thinking that it should be easy for anyone who wants the
proposed behaviour to make an alias, or certainly a wrapper. Problem
solved, without changing the way it works now.
-Tor
What you cant recover by undoing commit is the state of index before
accidental 'git commit -a' instead of 'git commit'.
Has a reflog equivilant for the index, to allow resetting it to a
previous state, ever been discussed?
I don't grok its data structure -- could that be done efficiently?
--
see shy jo
From: Mike Hommey <hidden> Date: 2016-06-15 22:48:42
On Sat, Apr 24, 2010 at 10:28:48AM -0400, Joey Hess wrote:
Jakub Narebski wrote:
quoted
What you cant recover by undoing commit is the state of index before
accidental 'git commit -a' instead of 'git commit'.
Has a reflog equivilant for the index, to allow resetting it to a
previous state, ever been discussed?
I don't grok its data structure -- could that be done efficiently?
Updating the index creates blobs, so the file states are definitely
already kept. What is missing is trees that could be referred to by a
log.
Mike
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:42
On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:
El 24/04/2010, a las 11:40, Jakub Narebski escribió:
quoted
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
On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:
quoted
El 24/04/2010, a las 11:40, Jakub Narebski escribió:
quoted
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.
quoted
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).
Yes I have occasionally committed more than I meant to, but rarely much more, and almost never due to using "git commit -a", seeing as I hardly ever use it. I am of the "commit early and often" school, and my most common pattern is committing tiny batches of changes which I review frequently with "git diff" and then again by staging them with "git add --patch" (aliased as "git patch" seeing as I use it so often).
quoted
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. ;-)
Are you not a big fan of "subject line + justification" commit message format? Consider it one of the perks of using the format: your editor will show you a nice summary that gives you yet another chance to double-check what you're about to commit.
Cheers,
Wincent
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:42
On Sat, Apr 24, 2010 at 06:59:33PM +0200, Wincent Colaiuta wrote:
El 24/04/2010, a las 18:42, Petr Baudis escribió:
quoted
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).
Yes I have occasionally committed more than I meant to, but rarely much more, and almost never due to using "git commit -a", seeing as I hardly ever use it. I am of the "commit early and often" school, and my most common pattern is committing tiny batches of changes which I review frequently with "git diff" and then again by staging them with "git add --patch" (aliased as "git patch" seeing as I use it so often).
I also commit early and often, but I just do the review with "git diff"
and then commit right away, I guess I don't see much value to do another
pass staging everything using "git add -p".
quoted
quoted
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. ;-)
Are you not a big fan of "subject line + justification" commit message format? Consider it one of the perks of using the format: your editor will show you a nice summary that gives you yet another chance to double-check what you're about to commit.
I'm a huge fan of "subject line + justification", so I use multiple -m
parameters; frequently, for simple changes subject line is enough, in
most of the other cases the justification is a one-liner as well, and
only in the rest of the cases I defer to the editor.
--
Petr "Pasky" Baudis
When I feel like exercising, I just lie down until the feeling
goes away. -- xed_over
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:48:42
On Sat, 24 Apr 2010, Petr Baudis wrote:
On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:
quoted
El 24/04/2010, a las 11:40, Jakub Narebski escribió:
quoted
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.
quoted
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).
In that case the deficiency is in the fact that no reflog preserves the
intermediate state of the index, not the fact that you might be allowed
to do it. Strictly speaking there is no intermediate ref to log, but a
synthetic commit could be created for this case just like a stash but
stored in the current branch's reflog.
Nicolas
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:42
On Sat, Apr 24, 2010 at 02:35:17PM -0400, Nicolas Pitre wrote:
In that case the deficiency is in the fact that no reflog preserves the
intermediate state of the index, not the fact that you might be allowed
to do it. Strictly speaking there is no intermediate ref to log, but a
synthetic commit could be created for this case just like a stash but
stored in the current branch's reflog.
Possibly, but I don't see how is this better than the check - it is less
user friendly, most importantly because user that has not seen this
twice has no idea that anything *was* saved to a reflog.
Are there valid user scenarios where you customize your index, then want
to override that using -a without thinking twice?
--
Petr "Pasky" Baudis
When I feel like exercising, I just lie down until the feeling
goes away. -- xed_over
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:48:42
On Sat, 24 Apr 2010, Petr Baudis wrote:
On Sat, Apr 24, 2010 at 02:35:17PM -0400, Nicolas Pitre wrote:
quoted
In that case the deficiency is in the fact that no reflog preserves the
intermediate state of the index, not the fact that you might be allowed
to do it. Strictly speaking there is no intermediate ref to log, but a
synthetic commit could be created for this case just like a stash but
stored in the current branch's reflog.
Possibly, but I don't see how is this better than the check - it is less
user friendly, most importantly because user that has not seen this
twice has no idea that anything *was* saved to a reflog.
Possibly. But the fact that some data could be lost here is a flaw.
The reflog is the safety net making sure that whatever the user does is
not completely destructive.
Are there valid user scenarios where you customize your index, then want
to override that using -a without thinking twice?
Admittedly there aren't many. And in those few hypothetical cases then
requiring -f would be acceptable.
Nicolas
From: Jacob Helwig <hidden> Date: 2016-06-15 22:48:42
On Sat, Apr 24, 2010 at 11:54, Petr Baudis [off-list ref] wrote:
Are there valid user scenarios where you customize your index, then want
to override that using -a without thinking twice?
Depends on what you consider "customizing your index". I add files to
the index all the time as I'm working on things, then commit -a at the
end "without thinking twice".
For example:
1) Hack on something.
2) git add $thing
3) Run full test-suite.
4) Fix a failing module.
5) git add $fixed-module-and-tests
6) Repeat 3-5 until there's only one module failing.
7) Fix last failing module.
8) git commit -a
I doubt I'm the only one that stages things as a way of marking them
as "done", and using git commit -a to "check-off" the last "todo"
item.
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:48:42
On Sat, 24 Apr 2010, Jacob Helwig wrote:
On Sat, Apr 24, 2010 at 11:54, Petr Baudis [off-list ref] wrote:
quoted
Are there valid user scenarios where you customize your index, then want
to override that using -a without thinking twice?
Depends on what you consider "customizing your index". I add files to
the index all the time as I'm working on things, then commit -a at the
end "without thinking twice".
For example:
1) Hack on something.
2) git add $thing
3) Run full test-suite.
4) Fix a failing module.
5) git add $fixed-module-and-tests
6) Repeat 3-5 until there's only one module failing.
7) Fix last failing module.
8) git commit -a
I doubt I'm the only one that stages things as a way of marking them
as "done", and using git commit -a to "check-off" the last "todo"
item.
Sure. But do you happen to often "commit -a" more changes to an already
previously modified and staged (but not committed yet) file?
Nicolas
From: Jacob Helwig <hidden> Date: 2016-06-15 22:48:42
On Sat, Apr 24, 2010 at 12:44, Nicolas Pitre [off-list ref] wrote:
On Sat, 24 Apr 2010, Jacob Helwig wrote:
quoted
On Sat, Apr 24, 2010 at 11:54, Petr Baudis [off-list ref] wrote:
quoted
Are there valid user scenarios where you customize your index, then want
to override that using -a without thinking twice?
Depends on what you consider "customizing your index". I add files to
the index all the time as I'm working on things, then commit -a at the
end "without thinking twice".
For example:
1) Hack on something.
2) git add $thing
3) Run full test-suite.
4) Fix a failing module.
5) git add $fixed-module-and-tests
6) Repeat 3-5 until there's only one module failing.
7) Fix last failing module.
8) git commit -a
I doubt I'm the only one that stages things as a way of marking them
as "done", and using git commit -a to "check-off" the last "todo"
item.
Sure. But do you happen to often "commit -a" more changes to an already
previously modified and staged (but not committed yet) file?
It's not uncommon. It's not the 90% case, either.
Specifically, I'd do this if I needed to make additional changes to a
file that I originally thought was "done", while working on that last
failing module.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:42
Dnia sobota 24. kwietnia 2010 18:42, Petr Baudis napisał:
On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:
quoted
El 24/04/2010, a las 11:40, Jakub Narebski escribió:
quoted
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.
Isn't it how (most of) backwards incompatibile changes are made, first
adding an option for new behaviour, then later (optionally) changing
the default?
quoted
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).
That is the situation this *optional* safety is meant to protect against:
when somebody sometimes use "git add" + "git commit", but sometimes
use "git commit -a", to protect carefully index against accidental
"git commit -a" instead of "git commit".
Is it worth additional code complication? Shoult it be turned on by
default? Does it promote unsafe workflow of committing untested changes?
quoted
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. ;-)
So restructuring commit message template so the information is more
visible in the case of accidental "git commit -a" wouldn't always help...
--
Jakub Narebski
Poland