Re: Please default to 'commit -a' when no changes were added

Re: Please default to 'commit -a' when no changes were added

[Jonathan Nieder]

[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?

diff --git a/builtin/commit.c b/builtin/commit.c
index c5ab683..9cb5489 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -396,7 +396,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
 }
 
 static int run_status(FILE *fp, const char *index_file, const char *prefix, int nowarn,
-		      struct wt_status *s)
+		      struct wt_status *s, int simple)
 {
 	unsigned char sha1[20];
 
@@ -415,6 +415,13 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
 
 	wt_status_collect(s);
 
+	if (simple) {
+		if (s->commitable)
+			die("internal error: are there changes or not?");
+		wt_status_print_nochanges(s);
+		return 0;
+	}
+
 	switch (status_format) {
 	case STATUS_FORMAT_SHORT:
 		wt_shortstatus_print(s, null_termination);
@@ -670,7 +677,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 
 		saved_color_setting = s->use_color;
 		s->use_color = 0;
-		commitable = run_status(fp, index_file, prefix, 1, s);
+		commitable = run_status(fp, index_file, prefix, 1, s, 0);
 		s->use_color = saved_color_setting;
 	} else {
 		unsigned char sha1[20];
@@ -692,7 +699,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 
 	if (!commitable && !in_merge && !allow_empty &&
 	    !(amend && is_a_merge(head_sha1))) {
-		run_status(stdout, index_file, prefix, 0, s);
+		run_status(stdout, index_file, prefix, 0, s, 1);
 		return 0;
 	}
 
@@ -946,7 +953,7 @@ static int dry_run_commit(int argc, const char **argv, const char *prefix,
 	const char *index_file;
 
 	index_file = prepare_index(argc, argv, prefix, 1);
-	commitable = run_status(stdout, index_file, prefix, 0, s);
+	commitable = run_status(stdout, index_file, prefix, 0, s, 0);
 	rollback_index_files();
 
 	return commitable ? 0 : 1;
diff --git a/wt-status.c b/wt-status.c
index 8ca59a2..b50bf71 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -589,6 +589,24 @@ static void wt_status_print_tracking(struct wt_status *s)
 	color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
 }
 
+void wt_status_print_nochanges(struct wt_status *s)
+{
+	if (s->amend)
+		fprintf(s->fp, "# No changes\n");
+	else if (s->nowarn)
+		; /* nothing */
+	else if (s->workdir_dirty)
+		printf("no changes added to commit (use \"git add\" and/or \"git commit -a\")\n");
+	else if (s->untracked.nr)
+		printf("nothing added to commit but untracked files present (use \"git add\" to track)\n");
+	else if (s->is_initial)
+		printf("nothing to commit (create/copy files and use \"git add\" to track)\n");
+	else if (!s->show_untracked_files)
+		printf("nothing to commit (use -u to show untracked files)\n");
+	else
+		printf("nothing to commit (working directory clean)\n");
+}
+
 void wt_status_print(struct wt_status *s)
 {
 	const char *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");
-		else if (s->nowarn)
-			; /* nothing */
-		else if (s->workdir_dirty)
-			printf("no changes added to commit (use \"git add\" and/or \"git commit -a\")\n");
-		else if (s->untracked.nr)
-			printf("nothing added to commit but untracked files present (use \"git add\" to track)\n");
-		else if (s->is_initial)
-			printf("nothing to commit (create/copy files and use \"git add\" to track)\n");
-		else if (!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);
 }
 
 static void wt_shortstatus_unmerged(int null_termination, struct string_list_item *it,
diff --git a/wt-status.h b/wt-status.h
index 9120673..f249955 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -59,6 +59,8 @@ void wt_status_prepare(struct wt_status *s);
 void wt_status_print(struct wt_status *s);
 void wt_status_collect(struct wt_status *s);
 
+void wt_status_print_nochanges(struct wt_status *s);
+
 void wt_shortstatus_print(struct wt_status *s, int null_termination);
 void wt_porcelain_print(struct wt_status *s, int null_termination);
 

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Jonathan Nieder <jrnieder@gmail.com> writes:

> [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.

Then you would type C-X C-c or :q or whatever exits your editor. No harm
done. Also, as you say below, git can output quite a long list of things
in the message. With my proposed change you would get the list inside
your editor and could scroll through it and check if it can all go as a
single commit or not. Imho doing nothing as it does now is the least
usefull thing to do.

> 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?

I have never ever needed anything but

git commit -a
git commit <file> <file> ...

I do commit often and commit early and I start and finish one thing
before I start another. Also I keep my files small so they do one thing
and do it well. Overall that means I don't end up with multiple changes
in a single file so I never need to cherry pick changes for a commit.

So I don't think people should be forced to utilize the index. Imho that
is a matter of the workflow people use. Some people work better with the
index and some people (or projects) don't need it.



Alternatively an option to take all changes but only if the index is
empty would be helpfull. Then people could define an alias for that or
set the option in the config. Other than setting -a that would allow
using an index when needed and commit everything in the normal case
without having to change the command used to commit.

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Nicolas Pitre]

On Thu, 22 Apr 2010, Goswin von Brederlow wrote:

> I have never ever needed anything but
> 
> git commit -a
> git commit <file> <file> ...

When I was using CVS/SVN that's what I thought too.

> I do commit often and commit early and I start and finish one thing
> before I start another. Also I keep my files small so they do one thing
> and do it well. Overall that means I don't end up with multiple changes
> in a single file so I never need to cherry pick changes for a commit.

Good for you.  I'm not that disciplined. Hence I often end up working on 
more than one thing in parallel.  The index is just so incredibly useful 
in that case.  I'm also a big fan of 'git add -e'.

> So I don't think people should be forced to utilize the index. Imho that
> is a matter of the workflow people use. Some people work better with the
> index and some people (or projects) don't need it.

Exact.  It is therefore not progress to impose some inconvenience to one 
work flow in order to make another one easier.  And in this case we're 
talking about the difference between having to type an additional -a vs 
the risk of creating a commit with unexpected content.

> Alternatively an option to take all changes but only if the index is
> empty would be helpfull. Then people could define an alias for that or
> set the option in the config. Other than setting -a that would allow
> using an index when needed and commit everything in the normal case
> without having to change the command used to commit.

But you're proposing to change the semantics for that command.  And I 
also suspect that you're trying to make the index more hidden while what 
we're actually trying to do is to promote it.

What _you_ can do though, is this:

	git config --global alias.ci "commit -a"


Nicolas

Re: Please default to 'commit -a' when no changes were added

[Sverre Rabbelier]

Heya,

On Thu, Apr 22, 2010 at 21:03, Nicolas Pitre <nico@fluxnic.net> wrote:
> Good for you.  I'm not that disciplined. Hence I often end up working on
> more than one thing in parallel.  The index is just so incredibly useful
> in that case.  I'm also a big fan of 'git add -e'.

Speaking of which... how about having just 'git commit' drop you in
interactive commit mode?

-- 
Cheers,

Sverre Rabbelier

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Nicolas Pitre <nico@fluxnic.net> writes:

> On Thu, 22 Apr 2010, Goswin von Brederlow wrote:
>
>> I have never ever needed anything but
>> 
>> git commit -a
>> git commit <file> <file> ...
>
> When I was using CVS/SVN that's what I thought too.
>
>> I do commit often and commit early and I start and finish one thing
>> before I start another. Also I keep my files small so they do one thing
>> and do it well. Overall that means I don't end up with multiple changes
>> in a single file so I never need to cherry pick changes for a commit.
>
> Good for you.  I'm not that disciplined. Hence I often end up working on 
> more than one thing in parallel.  The index is just so incredibly useful 
> in that case.  I'm also a big fan of 'git add -e'.

As soon as you do 'git add -e' then you have an index. In that case a
'git commit' would use the index. There would be no change in worflow or
behaviour for you.

>> So I don't think people should be forced to utilize the index. Imho that
>> is a matter of the workflow people use. Some people work better with the
>> index and some people (or projects) don't need it.
>
> Exact.  It is therefore not progress to impose some inconvenience to one 
> work flow in order to make another one easier.  And in this case we're 
> talking about the difference between having to type an additional -a vs 
> the risk of creating a commit with unexpected content.

Is there a risk? You do get an editor with all the files affected listed
giving you a big fat warning what you are about to commit. Yes I
sometimes do start to commit wrongly too (no matter what RCS used) but
then I just close the editor to abort and commit the things seperately.

>> Alternatively an option to take all changes but only if the index is
>> empty would be helpfull. Then people could define an alias for that or
>> set the option in the config. Other than setting -a that would allow
>> using an index when needed and commit everything in the normal case
>> without having to change the command used to commit.
>
> But you're proposing to change the semantics for that command.  And I 
> also suspect that you're trying to make the index more hidden while what 
> we're actually trying to do is to promote it.

Yes, it would hide the index. But you are not just promoting it. You are
forcing people to always use it, even if only through the -a option.

> What _you_ can do though, is this:
>
> 	git config --global alias.ci "commit -a"

But then when I accidentally use 'git ci' while having an index the
index gets ignored and all changed files get commited in one big mess.
Given how seldom I need an index (so far never) the risk of using 'git
ci' accidentally is way to high. Same with typing -a. I do it so often
that when I actualy don't want it I will probably type it anyway out of
habbit.

My way would be safe in that it will never ignore an index if there is
one. And if it is a new option then it would not alter the existing
semantic, just add to it. Call the option --smart-a or --a-if-empty.

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Nicolas Pitre]

On Thu, 22 Apr 2010, Goswin von Brederlow wrote:

> Nicolas Pitre <nico@fluxnic.net> writes:
> 
> > On Thu, 22 Apr 2010, Goswin von Brederlow wrote:
> >
> >> I do commit often and commit early and I start and finish one thing
> >> before I start another. Also I keep my files small so they do one thing
> >> and do it well. Overall that means I don't end up with multiple changes
> >> in a single file so I never need to cherry pick changes for a commit.
> >
> > Good for you.  I'm not that disciplined. Hence I often end up working on 
> > more than one thing in parallel.  The index is just so incredibly useful 
> > in that case.  I'm also a big fan of 'git add -e'.
> 
> As soon as you do 'git add -e' then you have an index. In that case a
> 'git commit' would use the index. There would be no change in worflow or
> behaviour for you.

But the point is if I did not use 'git add'.

> >> So I don't think people should be forced to utilize the index. Imho that
> >> is a matter of the workflow people use. Some people work better with the
> >> index and some people (or projects) don't need it.
> >
> > Exact.  It is therefore not progress to impose some inconvenience to one 
> > work flow in order to make another one easier.  And in this case we're 
> > talking about the difference between having to type an additional -a vs 
> > the risk of creating a commit with unexpected content.
> 
> Is there a risk? You do get an editor with all the files affected listed
> giving you a big fat warning what you are about to commit. Yes I
> sometimes do start to commit wrongly too (no matter what RCS used) but
> then I just close the editor to abort and commit the things seperately.

Yes, but this is a much greater burden to 1) not forget to empty the 
editor, and 2) actually save the empty file.  Simply exiting the editor 
will cause unwanted commit.

Compare that with simply adding -a to your commit command when told so.

> >> Alternatively an option to take all changes but only if the index is
> >> empty would be helpfull. Then people could define an alias for that or
> >> set the option in the config. Other than setting -a that would allow
> >> using an index when needed and commit everything in the normal case
> >> without having to change the command used to commit.
> >
> > But you're proposing to change the semantics for that command.  And I 
> > also suspect that you're trying to make the index more hidden while what 
> > we're actually trying to do is to promote it.
> 
> Yes, it would hide the index. But you are not just promoting it. You are
> forcing people to always use it, even if only through the -a option.

Well, sure.

And you might be glad that the -a option is there at all.  When this was 
debated, the concensus was that the index is what makes Git so 
different, and actually *better* than the alternatives.

Concerns were raised about natural human resistance to change and the 
fact that some people would have problem adapting to a different model.  
So the -a argument was added as a compromize, although the concensus was 
much less strong in that case.

And experience so far has shown that the vast majority of new Git users 
started to really appreciate the index once they've past the initial 
hurdle of getting used to a different concept.

So we can say that Git's index is one of its major feature.  You should 
learn to use it or stick to -a, but please don't try to make Git into 
what it was meant to be different from.

> > What _you_ can do though, is this:
> >
> > 	git config --global alias.ci "commit -a"
> 
> But then when I accidentally use 'git ci' while having an index the
> index gets ignored and all changed files get commited in one big mess.

Not at all.  You will end up in the same text editor with the same 
opportunity to abort the messed up commit as you are claiming above.  
Except now this is your own burden instead of mine.  See?  One's gain is 
another one's loss.

However in this case this would happen because you mixed up an 
index-using workflow with a non-index-using workflow.  While with your 
suggested change the messed up commit could occur without mixing up 
workflows.

So either you use the index or you don't.  And of course I'd strongly 
suggest you truly consider using it.

> Given how seldom I need an index (so far never) the risk of using 'git
> ci' accidentally is way to high. Same with typing -a. I do it so often
> that when I actualy don't want it I will probably type it anyway out of
> habbit.

This is a strawman.  If you do not use the index and never used it so 
far, why are you so afraid of this ci alias?  Please get over it.


Nicolas

Re: Please default to 'commit -a' when no changes were added

[Junio C Hamano]

Goswin von Brederlow <goswin-v-b@web.de> writes:

>> Exact.  It is therefore not progress to impose some inconvenience to one 
>> work flow in order to make another one easier.  And in this case we're 
>> talking about the difference between having to type an additional -a vs 
>> the risk of creating a commit with unexpected content.
>
> Is there a risk?

Absolutely.

Think of this sequence:

    ... edit edit edit to enhance the program a lot
    ... oops, noticed that there is a small typo in hello.c
    ... fix and do "git add hello.c" (at least I thought I did)
    ... edit edit edit to enhance the program a lot more.
    ... it is a good time to get rid of the trivial fix first.
    $ git commit -m 'hello.c: typofix the message'
    ... oops, I mistyped the earlier one as "git ad hello.c" and
    ... didn't notice it.

which is just an example.

And the problem is a lot bigger at the _conceptual_ level.

We promise to the user that "git commit" without paths (nor -a which is
merely a short hand to specify all the paths that have changed) to commit
only what has been added to the index.  If you earlier did "git add foo"
and "git add bar", changes made to these two files are the only changes
that are committed.  If you did only "git add foo", then changes made to
this one file are the only changes that are committed.  If you haven't
added anything yet, there is no change to be committed.

Special casing the last case (and only the last case) breaks consistency a
big way.  It is one more pitfall that users need to worry about.

Re: Please default to 'commit -a' when no changes were added

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Think of this sequence:

There's another case where it would be hard to decide what's "The
Right Thing":

vi existing-file.c # do some changes
vi new-file.c      # create the file
git add new-file.c
git commit

If you take the SVN semantics, the last "git commit" should commit the
changes to existing-file.c. But keeping the current Git semantics, it
doesn't. There are valid reasons why a user can type the above
sequence with today's Git, and changing it would be backward
incompatible, and would make the senario a lot more painfull.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Please default to 'commit -a' when no changes were added

[Adam Brewster]

>> What _you_ can do though, is this:
>>
>>       git config --global alias.ci "commit -a"
>
> But then when I accidentally use 'git ci' while having an index the
> index gets ignored and all changed files get commited in one big mess.
> Given how seldom I need an index (so far never) the risk of using 'git
> ci' accidentally is way to high. Same with typing -a. I do it so often
> that when I actualy don't want it I will probably type it anyway out of
> habbit.
>
> My way would be safe in that it will never ignore an index if there is
> one. And if it is a new option then it would not alter the existing
> semantic, just add to it. Call the option --smart-a or --a-if-empty.
>

Consider

$ echo -e '#!/bin/bash\nif git diff-tree --quiet HEAD; then git commit
-a; else git commit; fi' > `git --exec-path`/git-ci
$ chmod 555 `git --exec-path`/git-ci

Adam

Re: Please default to 'commit -a' when no changes were added

[Michael Witten]

On Thu, Apr 22, 2010 at 16:40, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> There's another case where it would be hard to decide what's "The
> Right Thing":
>
> vi existing-file.c # do some changes
> vi new-file.c      # create the file
> git add new-file.c
> git commit
>
> If you take the SVN semantics

The original feature request is pretty specific and still backwards
compatible with this case; indeed, the feature request is almost
99.9999% backwards compatible from what I've skimmed.

Re: Please default to 'commit -a' when no changes were added

[Jonathan Nieder]

Adam Brewster wrote:

> Consider
> 
> $ echo -e '#!/bin/bash\nif git diff-tree --quiet HEAD; then git commit
> -a; else git commit; fi' > `git --exec-path`/git-ci
> $ chmod 555 `git --exec-path`/git-ci

Or just put it in your $PATH. :)

By the way, all this talk of “if there is an index” sounds funny to
my brainwashed ears.  Every version control system I have tried uses
an index to ensure consistency during a commit; it’s just that most
of them hide it from the user.

This may sound pedantic, I realize.

Have fun,
Jonathan

Re: Please default to 'commit -a' when no changes were added

[Jon Seymour]

On Fri, Apr 23, 2010 at 7:48 AM, Adam Brewster <adambrewster@gmail.com> wrote:

> Consider
>
> $ echo -e '#!/bin/bash\nif git diff-tree --quiet HEAD; then git commit
> -a; else git commit; fi' > `git --exec-path`/git-ci
> $ chmod 555 `git --exec-path`/git-ci
>
> Adam

Perhaps I am missing something, but I would have thought git
diff-files --quiet would be more useful in this context...

jon.

> --
> 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
>

Re: Please default to 'commit -a' when no changes were added

[Adam Brewster]

>
> Perhaps I am missing something, but I would have thought git
> diff-files --quiet would be more useful in this context...
>
> jon.
>

Maybe so.  I really just meant to suggest that if you need something
more complicated than a simple git-command, you can put whatever you
want in a shell script and use it like an alias.

Then I learned that git aliases can be pretty fancy if they start with "!sh -c".

After looking at the man pages a bit more, I think "git diff --cached
--quiet" or "git diff-index --cached --quiet HEAD" are the right
condition.  git diff-files will compare the working copy to the index,
so this sequence

  vi file1
  vi file2
  git add file1
  git ci

would call commit -a, and I think that's wrong.

I also now realize that some use needs to be made of the arguments.
As I sent it the first time, "git ci -m whatever" doesn't work as it
should.  Adding "$@" to the git commit call doesn't work either
because it breaks "git ci filename" if there is no index (it calls
"git commit -a filename").

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Nicolas Pitre <nico@fluxnic.net> writes:

> On Thu, 22 Apr 2010, Goswin von Brederlow wrote:
>
>> Nicolas Pitre <nico@fluxnic.net> writes:
>> 
>> > On Thu, 22 Apr 2010, Goswin von Brederlow wrote:
>> > Exact.  It is therefore not progress to impose some inconvenience to one 
>> > work flow in order to make another one easier.  And in this case we're 
>> > talking about the difference between having to type an additional -a vs 
>> > the risk of creating a commit with unexpected content.
>> 
>> Is there a risk? You do get an editor with all the files affected listed
>> giving you a big fat warning what you are about to commit. Yes I
>> sometimes do start to commit wrongly too (no matter what RCS used) but
>> then I just close the editor to abort and commit the things seperately.
>
> Yes, but this is a much greater burden to 1) not forget to empty the 
> editor, and 2) actually save the empty file.  Simply exiting the editor 
> will cause unwanted commit.
>
> Compare that with simply adding -a to your commit command when told so.

That is not how it works in other RCS. Initialy the editor only contains
comments listing the affected files. If you do not alter the file then
the commit aborts. I agree that having to empty the file and save it
would be a greater burden.

>> >> Alternatively an option to take all changes but only if the index is
>> >> empty would be helpfull. Then people could define an alias for that or
>> >> set the option in the config. Other than setting -a that would allow
>> >> using an index when needed and commit everything in the normal case
>> >> without having to change the command used to commit.
>> >
>> > But you're proposing to change the semantics for that command.  And I 
>> > also suspect that you're trying to make the index more hidden while what 
>> > we're actually trying to do is to promote it.
>> 
>> Yes, it would hide the index. But you are not just promoting it. You are
>> forcing people to always use it, even if only through the -a option.
>
> Well, sure.
>
> And you might be glad that the -a option is there at all.  When this was 
> debated, the concensus was that the index is what makes Git so 
> different, and actually *better* than the alternatives.
>
> Concerns were raised about natural human resistance to change and the 
> fact that some people would have problem adapting to a different model.  
> So the -a argument was added as a compromize, although the concensus was 
> much less strong in that case.
>
> And experience so far has shown that the vast majority of new Git users 
> started to really appreciate the index once they've past the initial 
> hurdle of getting used to a different concept.
>
> So we can say that Git's index is one of its major feature.  You should 
> learn to use it or stick to -a, but please don't try to make Git into 
> what it was meant to be different from.
>
>> > What _you_ can do though, is this:
>> >
>> > 	git config --global alias.ci "commit -a"
>> 
>> But then when I accidentally use 'git ci' while having an index the
>> index gets ignored and all changed files get commited in one big mess.
>
> Not at all.  You will end up in the same text editor with the same 
> opportunity to abort the messed up commit as you are claiming above.  
> Except now this is your own burden instead of mine.  See?  One's gain is 
> another one's loss.
>
> However in this case this would happen because you mixed up an 
> index-using workflow with a non-index-using workflow.  While with your 
> suggested change the messed up commit could occur without mixing up 
> workflows.

No, with my suggested change (either change of the default or the extra
option) it would be smart enough to do the right thing on its own.

> So either you use the index or you don't.  And of course I'd strongly 
> suggest you truly consider using it.
>
>> Given how seldom I need an index (so far never) the risk of using 'git
>> ci' accidentally is way to high. Same with typing -a. I do it so often
>> that when I actualy don't want it I will probably type it anyway out of
>> habbit.
>
> This is a strawman.  If you do not use the index and never used it so 
> far, why are you so afraid of this ci alias?  Please get over it.
>
>
> Nicolas

You all say the index is such a great thing. So I might use it
eventually. Other people might use it 1 out of 10 times. Yet other
people use it 9 out of 10 times. Can you at least accept that the use of
the index feature is different for each person?

My suggested change, with the --a-if-empty option, would not impose
anything on existing usage. But it would benefit those that rarely use
an index and would like git to be smart enough to know when to use the
index and when not. Yes, it would mean the use of the index ideology is
not force upon people anymore. But isn't that a good thing? Free
software is about freedom. That should include the freedom not to use
the index method.

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Think of this sequence:
>
> There's another case where it would be hard to decide what's "The
> Right Thing":
>
> vi existing-file.c # do some changes
> vi new-file.c      # create the file
> git add new-file.c
> git commit
>
> If you take the SVN semantics, the last "git commit" should commit the
> changes to existing-file.c. But keeping the current Git semantics, it
> doesn't. There are valid reasons why a user can type the above
> sequence with today's Git, and changing it would be backward
> incompatible, and would make the senario a lot more painfull.

For SVN users it gets much worse:

vi existing-file.c # do some changes
vi new-file.c      # create the file
git add new-file.c
vi new-file.c      # do some more changes
git commit

A SVN user would expect the current working copies of existing-file.c
and new-file.c to be commited. Instead only new-file.c is commited and
only the fist modification.

While this case is still highly confusing to non git users I do see that
it can't be easily changed. And my suggestion doesn't change it. The
call to "git add" creates an index so the commit would only act on the
index.

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Adam Brewster <adambrewster@gmail.com> writes:

>>> What _you_ can do though, is this:
>>>
>>>       git config --global alias.ci "commit -a"
>>
>> But then when I accidentally use 'git ci' while having an index the
>> index gets ignored and all changed files get commited in one big mess.
>> Given how seldom I need an index (so far never) the risk of using 'git
>> ci' accidentally is way to high. Same with typing -a. I do it so often
>> that when I actualy don't want it I will probably type it anyway out of
>> habbit.
>>
>> My way would be safe in that it will never ignore an index if there is
>> one. And if it is a new option then it would not alter the existing
>> semantic, just add to it. Call the option --smart-a or --a-if-empty.
>>
>
> Consider
>
> $ echo -e '#!/bin/bash\nif git diff-tree --quiet HEAD; then git commit
> -a; else git commit; fi' > `git --exec-path`/git-ci
> $ chmod 555 `git --exec-path`/git-ci
>
> Adam

% if git diff-tree --quiet HEAD; then git commit -a; else git commit; fi
7a15ef233c9ea900c9176f4a09260bb64a7e40cb
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   debian/changelog
#       modified:   debian/control
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       debian/files
no changes added to commit (use "git add" and/or "git commit -a")


That does not do the right thing but I was thinking along the same lines
for a personal fix.

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Adam Brewster wrote:
>
>> Consider
>> 
>> $ echo -e '#!/bin/bash\nif git diff-tree --quiet HEAD; then git commit
>> -a; else git commit; fi' > `git --exec-path`/git-ci
>> $ chmod 555 `git --exec-path`/git-ci
>
> Or just put it in your $PATH. :)
>
> By the way, all this talk of “if there is an index” sounds funny to
> my brainwashed ears.  Every version control system I have tried uses
> an index to ensure consistency during a commit; it’s just that most
> of them hide it from the user.
>
> This may sound pedantic, I realize.
>
> Have fun,
> Jonathan

Other RCS use an index of files they track. Git uses an index of patch
chunks to commit. Same name, totaly different concept.

Or am I understanding that wrong?

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Tomas Carnecky]

On 4/23/10 11:09 AM, Goswin von Brederlow wrote:
> For SVN users it gets much worse:
>
> vi existing-file.c # do some changes
> vi new-file.c      # create the file
> git add new-file.c
> vi new-file.c      # do some more changes
> git commit
>
> A SVN user would expect the current working copies of existing-file.c
> and new-file.c to be commited. Instead only new-file.c is commited and
> only the fist modification.

But is compatibility with the SVN interface really what we want to aim 
for? Just because their interface works that way doesn't mean it's the 
correct way.

tom

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Jon Seymour <jon.seymour@gmail.com> writes:

> On Fri, Apr 23, 2010 at 7:48 AM, Adam Brewster <adambrewster@gmail.com> wrote:
>
>> Consider
>>
>> $ echo -e '#!/bin/bash\nif git diff-tree --quiet HEAD; then git commit
>> -a; else git commit; fi' > `git --exec-path`/git-ci
>> $ chmod 555 `git --exec-path`/git-ci
>>
>> Adam
>
> Perhaps I am missing something, but I would have thought git
> diff-files --quiet would be more useful in this context...
>
> jon.

% git diff-files; git diff-files --quiet; echo $?
:100644 100644 09f06ca1503da57f89331ddc44f0a3c60313c531 0000000000000000000000000000000000000000 M      debian/changelog
:100644 100644 978b107709d1e45b5240a86960587d2a61d8afe6 0000000000000000000000000000000000000000 M      debian/control
1

% git add debian/control

% git diff-files; git diff-files --quiet; echo $?
:100644 100644 09f06ca1503da57f89331ddc44f0a3c60313c531 0000000000000000000000000000000000000000 M      debian/changelog
1

% git add debian/changelog 

% git diff-files; echo $? 
0

Doesn't tell me if there is an index prepared alraedy or not. Only tells
me if there are changes that are not in the index.

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Matthieu Moy]

Goswin von Brederlow <goswin-v-b@web.de> writes:

> For SVN users it gets much worse:
>
> vi existing-file.c # do some changes
> vi new-file.c      # create the file
> git add new-file.c
> vi new-file.c      # do some more changes
> git commit
>
> A SVN user would expect the current working copies of existing-file.c
> and new-file.c to be commited. Instead only new-file.c is commited and
> only the fist modification.
>
> While this case is still highly confusing to non git users I do see that
> it can't be easily changed. And my suggestion doesn't change it. The
> call to "git add" creates an index so the commit would only act on the
> index.

But then, you'd still have the confusion for people expecting the SVN
semantics. They'd use "git commit-without-dash-a" happily untill they
have to add a new file, and the day the do a "git add" on a new file,
commit doesn't add their changes to existing files, and ... WTF!?

Don't get me wrong: I do agree that not everybody have a use for the
index. Typically, I teach Git to students, who are light-years away
from understanding what "clean commit, small and related changes"
means. They have no use for the index, they just use Git as a way to
share code, and possibly as a backup mechanism. I just teach them
"always use the -a option of 'git commit' for now, you'll learn about
the power of 'git commit-without-dash-a' later". Unless when they
forget to say "-a", it just works. And it even works when they add new
files, when they resolve conflicts after a merge, ... which your
proposal does not solve.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Please default to 'commit -a' when no changes were added

[Miles Bader]

Goswin von Brederlow <goswin-v-b@web.de> writes:
> You all say the index is such a great thing. So I might use it
> eventually. Other people might use it 1 out of 10 times. Yet other
> people use it 9 out of 10 times. Can you at least accept that the use of
> the index feature is different for each person?

In my case, I use the index extremely often, for complex commits that I
want to split up -- but I _also_ use "-a" maybe 30-40% of the time, for
simple commits that don't need splitting.

I think the "default to -a if index is empty and there are no args"
behavior sounds perfect.  It would have no real adverse effects as far
as I can see, and would make git a little more convenient for everybody.

-miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Please default to 'commit -a' when no changes were added

[Tor Arntsen]

On Fri, Apr 23, 2010 at 11:09, Goswin von Brederlow <goswin-v-b@web.de> wrote:

> For SVN users it gets much worse:
>
> vi existing-file.c # do some changes
> vi new-file.c      # create the file
> git add new-file.c
> vi new-file.c      # do some more changes
> git commit
>
> A SVN user would expect the current working copies of existing-file.c
> and new-file.c to be commited. Instead only new-file.c is commited and
> only the fist modification.

I come from CVS, i.e. a similar background.

> While this case is still highly confusing to non git users I do see that
> it can't be easily changed. And my suggestion doesn't change it. The
> call to "git add" creates an index so the commit would only act on the
> index.

I wouldn't agree it's highly confusing. As soon as you understand why
(and it shouldn't take long), it's a relief. With CVS I would
constantly make copies of my working tree so that I could sort out all
the different things I was working on at the same time (which is a
necessity when you work with development and bugfixing and customer
reports with different priorities are dropping in). It's much easier
now (with Git) to do a couple of different things at the same time.

Besides, I would argue that the SVN/CVS behaviour is creating problems
also for SVN/CVS users. Where I work it's not unusual that developers
accidentally commit different changes in the same commit, making it
hard to extract the one you want when you later wish to e.g. push a
specific change to a maintenance branch or hotfix tree.

And git add --patch is also wonderful sometimes. (Unfortunately that
won't work on systems with pre-5.8 versions of Perl, which I just
found out - but that's another story.)

I plan to create a short course for my fellow co-workers when we move
more stuff over from CVS to Git. Just an hour should do I think. I'll
clarify how the index works very early on and I believe they'll all
"get it" very quickly. I'll probably also take some parts from 'Git
from the bottom up' by John Wiegley, at least I found (after having
used Git for some time) that knowing how it works from blobs and up
actually helps a lot.

I won't join in on the discussion of any actual changes to Git, for
that I'm too fresh as Git user. I would only like to stress that I
wouldn't want the current flexibility to get limited or changed to be
more like SVN/CVS -- I come from there, remember, and I don't see why
I would wish to go back.

-Tor

Re: Please default to 'commit -a' when no changes were added

[Björn Steinbrink]

On 2010.04.22 22:37:05 +0200, Goswin von Brederlow wrote:
> Is there a risk? You do get an editor with all the files affected listed
> giving you a big fat warning what you are about to commit.

And if I happen to have two unrelated changes in a single file that's
worth nothing at all. For example, I might have changed the condition
that causes some message to be shown, and discovered a typo in the
message itself and fixed it along the way. That needs two commits, but
the list of modified files doesn't tell that.

Only "commit -v" would help there, showing the diff in the editor. But
reviewing the diff in the editor is a PITA and I lose the whole review
progress if I find something I don't want to commit and have to abort.
Using "git add [-i|-p|-e]", git helps me to keep track of the changes I
already reviewed and decided to commit.

Björn

The index (Re: Please default to 'commit -a' when no changes were added)

[Jonathan Nieder]

Goswin von Brederlow wrote:

> Other RCS use an index of files they track. Git uses an index of patch
> chunks to commit. Same name, totaly different concept.

What you say is correct in terms of how some people use the tools.
But underneath, the index is a cache that tracks the content of all
files.  To make the index not match the work tree is to deliberately
let it go stale (or to cheat and poison it, or whatever).

I am making an assumption about other version control systems and it
is probably wrong for some.  Here is the logic: suppose I

 1. Make some changes to files.
 2. Invoke “vcs commit”
 3. Pull out the power plug.

What happens?  If the version control system is sane, then either the
entire commit takes place or nothing visible happens; because
otherwise, the result is that I screwed everyone over.  The easiest
way to implement this is to make “vcs commit” two steps:

 1. Prepare the proposed changes in a staging area.
 2. Atomically commit them.

Traditionally, “atomically” means “with a lock, on the remote server
which has a steady power supply”.

In particular, the index I am talking about tends to be on the _remote_
machine.  Making it local leads to a lot of improvements.

Early in the design of git’s user interface, it took some time to
figure out how visible to make the index [1].  Personally I am happier
with the modern approach of letting people dirty the index if they
want to, but if you believe that is wrong, maybe you would like to
look at the Cogito scripts for inspiration [2].  There are still many
lessons to learn from them, I suspect.  More importantly, it might be
fun or interesting.

Hopefully that is a little clearer.
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/780/focus=918
As you can see, cogito, the most widely used front-end in early
history, did hide the index from the user.
[2] http://git.or.cz/cogito/
(warning: they have not been maintained for a while)

Re: Please default to 'commit -a' when no changes were added

[Sergei Organov]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> On 2010.04.22 22:37:05 +0200, Goswin von Brederlow wrote:
>> Is there a risk? You do get an editor with all the files affected listed
>> giving you a big fat warning what you are about to commit.
>
> And if I happen to have two unrelated changes in a single file that's
> worth nothing at all. For example, I might have changed the condition
> that causes some message to be shown, and discovered a typo in the
> message itself and fixed it along the way. That needs two commits, but
> the list of modified files doesn't tell that.
>
> Only "commit -v" would help there, showing the diff in the editor. But
> reviewing the diff in the editor is a PITA and I lose the whole review
> progress if I find something I don't want to commit and have to abort.
> Using "git add [-i|-p|-e]", git helps me to keep track of the changes I
> already reviewed and decided to commit.

And how do you check your changes for correctness before committing? I
have a habit to only commit the exact tree I've compiled, and I can
compile only the working tree, not the index, right? So for me,
committing the index sounds to be a wrong idea (unless it matches the
work-tree).

I think I'd like to have an ability to temporarily undo some of changes
putting them on shelf for later re-application (sounds like extension to
stash?). This way, when preparing perfect commit, I'd undo everything
unrelated, check (build/run) the result, then commit. Then I'd re-do
everything that was undone using single command that would take all the
changes from the shelf back to working tree. Repeat as appropriate.
Multiple shelves would be the next improvement that will allow to
immediately sort the changes into different changesets during undoing.
Just dreaming... At least that's roughly how I actually managed this
with CVS using patch and emacs, -- far from being pretty, but works.

-- Sergei.

Re: Please default to 'commit -a' when no changes were added

[Sverre Rabbelier]

Heya,

2010/4/23 Sergei Organov <osv@javad.com>:
> And how do you check your changes for correctness before committing?

git stash save -k && make all test && git stash pop

-- 
Cheers,

Sverre Rabbelier

Re: Please default to 'commit -a' when no changes were added

[Sergei Organov]

Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> 2010/4/23 Sergei Organov <osv@javad.com>:
>> And how do you check your changes for correctness before committing?
>
> git stash save -k && make all test && git stash pop

Perfect, thanks!

-- Sergei.

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> On 2010.04.22 22:37:05 +0200, Goswin von Brederlow wrote:
>> Is there a risk? You do get an editor with all the files affected listed
>> giving you a big fat warning what you are about to commit.
>
> And if I happen to have two unrelated changes in a single file that's
> worth nothing at all. For example, I might have changed the condition
> that causes some message to be shown, and discovered a typo in the
> message itself and fixed it along the way. That needs two commits, but
> the list of modified files doesn't tell that.
>
> Only "commit -v" would help there, showing the diff in the editor. But
> reviewing the diff in the editor is a PITA and I lose the whole review
> progress if I find something I don't want to commit and have to abort.
> Using "git add [-i|-p|-e]", git helps me to keep track of the changes I
> already reviewed and decided to commit.
>
> Björn

Then you would keep doing that or use git commit --interactive. The
suggested change would not affect you at all either way.

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Wincent Colaiuta]

El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
> 
> You all say the index is such a great thing. So I might use it
> eventually. Other people might use it 1 out of 10 times. Yet other
> people use it 9 out of 10 times. Can you at least accept that the use of
> the index feature is different for each person?
> 
> My suggested change, with the --a-if-empty option, would not impose
> anything on existing usage. But it would benefit those that rarely use
> an index and would like git to be smart enough to know when to use the
> index and when not. Yes, it would mean the use of the index ideology is
> not force upon people anymore. But isn't that a good thing? Free
> software is about freedom. That should include the freedom not to use
> the index method.

Not really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want.

But you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too. 

And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.

In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less "surprising" for users coming from other systems, but we'd be throwing away something valuable in the process.

I personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index "the Git way" bring, that it's hard to imagine how I ever lived without it.

Cheers,
Wincent

Re: Please default to 'commit -a' when no changes were added

[Michael Witten]

On Fri, Apr 23, 2010 at 04:22, Tomas Carnecky <tom@dbservice.com> wrote:
> But is compatibility with the SVN interface really what we want to aim for?
> Just because their interface works that way doesn't mean it's the correct
> way.

You--like a lot of others--didn't read the proposal and have not read
Goswin's replies.

Re: Please default to 'commit -a' when no changes were added

[Matthias Andree]

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

Re: Please default to 'commit -a' when no changes were added

[Michael Witten]

On Fri, Apr 23, 2010 at 13:59, Matthias Andree <matthias.andree@gmx.de> 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'.

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Wincent Colaiuta <win@wincent.com> writes:

> El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
>> 
>> You all say the index is such a great thing. So I might use it
>> eventually. Other people might use it 1 out of 10 times. Yet other
>> people use it 9 out of 10 times. Can you at least accept that the use of
>> the index feature is different for each person?
>> 
>> My suggested change, with the --a-if-empty option, would not impose
>> anything on existing usage. But it would benefit those that rarely use
>> an index and would like git to be smart enough to know when to use the
>> index and when not. Yes, it would mean the use of the index ideology is
>> not force upon people anymore. But isn't that a good thing? Free
>> software is about freedom. That should include the freedom not to use
>> the index method.
>
> Not really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want.
>
> But you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too. 
>
> And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.

But you are already rejecting it in the design phase before there even
is a patch.

> In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less "surprising" for users coming from other systems, but we'd be throwing away something valuable in the process.

If I would ask to disable the indexing feature then you would have a
point. But I am not. I'm asking to add something that allows to use git
in a less "surprising" mode that, with the --a-if-empty option, does not
alter anything else. Git would still have all its great, big, shiny,
differentiating features to set it apart from other SCMs without forcing
them down the users throat.

> I personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index "the Git way" bring, that it's hard to imagine how I ever lived without it.
>
> Cheers,
> Wincent

I personaly have to work with different SCMs every day and every time I
have to switch minds to work with each specific one. Making git commit
work less surprising would be one less thing to keep in mind.

You like that Git is different so don't use the --a-if-empty option. You
will have lost nothing by allowing that option in. So far I have read
arguments from people saying they don't want to USE the option. But no
arguments why there could not be such an option. And I'm not the only
one that would welcome such an option. Is there no room for a compromise?

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Michael Witten]

On Fri, Apr 23, 2010 at 15:17, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> But you are already rejecting it in the design phase before there even
> is a patch.
> ...
> You like that Git is different so don't use the --a-if-empty option. You
> will have lost nothing by allowing that option in. So far I have read
> arguments from people saying they don't want to USE the option. But no
> arguments why there could not be such an option. And I'm not the only
> one that would welcome such an option. Is there no room for a compromise?

My sincere advice is just to write the patch and submit it with an
example usage to illustrate your feature.

Prose aren't well received on this list (especially without concrete
code to reference).

Re: Please default to 'commit -a' when no changes were added

[Daniel Grace]

On Fri, Apr 23, 2010 at 3:17 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>> El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
>> And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.
>
> But you are already rejecting it in the design phase before there even
> is a patch.

This is common in open-source. If you come to the mailing list talking
about a feature, without a patch, the maintainers let you know how
likely they are to want to write or maintain that feature. You haven't
given them a patch they could trivially merge in, so it reads as if
you're asking them to write the feature. Why write a feature that they
would never use?

Writing it yourself is one way to get a feature included that the
maintainers wouldn't use themselves. But you have to realize that
they're still thinking about having to maintain that feature. Every
new feature adds work to them, making sure that their future work does
not break it. There will be some features that are just deemed not
worth that effort by the people that control the official repository.
This is why forking is sometimes (rarely, but sometimes) acceptable.

>> In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less "surprising" for users coming from other systems, but we'd be throwing away something valuable in the process.
>
> If I would ask to disable the indexing feature then you would have a
> point. But I am not. I'm asking to add something that allows to use git
> in a less "surprising" mode that, with the --a-if-empty option, does not
> alter anything else. Git would still have all its great, big, shiny,
> differentiating features to set it apart from other SCMs without forcing
> them down the users throat.

Nothing is being forced down anyones throat by Git. Git doesn't
somehow force you to use Git from here into eternity. You state later
that you *have* to use many different systems. But it's not Git that
forces you to do so.

> I personaly have to work with different SCMs every day and every time I
> have to switch minds to work with each specific one. Making git commit
> work less surprising would be one less thing to keep in mind.

This sounds to me like you should try to simplify your setup. I know
that sometime it's not possible, but you're fighting an unwinnable
battle. If you're truly using that many different systems with
overlapping functionality you are destined to be confused. Period.
Most SCMs now do a good job of migrating data and in some cases (git
svn, for instance) sharing data on an ongoing basis. There are also
tools around that handle multiple SCMs behind one consistent
interface.

> You like that Git is different so don't use the --a-if-empty option. You
> will have lost nothing by allowing that option in. So far I have read
> arguments from people saying they don't want to USE the option. But no
> arguments why there could not be such an option. And I'm not the only
> one that would welcome such an option. Is there no room for a compromise?

I'm not one of the maintainers, so maybe I'm speaking out of turn, but
as I pointed out above, they are losing something for letting in
options. They will have entered into an implied contract with their
users to keep that feature working in the future, putting a burden on
future development efforts. This is not without cost.

Daniel
http://www.doomstick.com

Re: Please default to 'commit -a' when no changes were added

[Nicolas Pitre]

On Fri, 23 Apr 2010, Goswin von Brederlow wrote:

> I personaly have to work with different SCMs every day and every time I
> have to switch minds to work with each specific one. Making git commit
> work less surprising would be one less thing to keep in mind.

Please make yourself some git aliases and your problem will be solved.  
After all, the alias mechanism was created for a reason.

> You like that Git is different so don't use the --a-if-empty option. You
> will have lost nothing by allowing that option in. So far I have read
> arguments from people saying they don't want to USE the option. But no
> arguments why there could not be such an option. And I'm not the only
> one that would welcome such an option. Is there no room for a compromise?

I suggest you have a look at all the examples (some are simple, some are 
complex) here: https://git.wiki.kernel.org/index.php/Aliases. It should 
be simple to make an alias with all the safety valves you might think 
of, and then it could even be contributed to section 7 of that page.


Nicolas

Re: Please default to 'commit -a' when no changes were added

[Matthias Andree]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

Am 23.04.2010 21:34, schrieb Michael Witten:
> On Fri, Apr 23, 2010 at 13:59, Matthias Andree <matthias.andree@gmx.de> 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".

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: Please default to 'commit -a' when no changes were added

[Eric Raymond]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

Matthias Andree <matthias.andree@gmx.de>:
> Am 23.04.2010 21:34, schrieb Michael Witten:
> > On Fri, Apr 23, 2010 at 13:59, Matthias Andree <matthias.andree@gmx.de> 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".
> 
> 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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Please default to 'commit -a' when no changes were added

[Matthias Andree]

[-- Attachment #1: Type: text/plain, Size: 4424 bytes --]

Am 23.04.2010 22:17, schrieb Goswin von Brederlow:
> Wincent Colaiuta <win@wincent.com> writes:
> 
>> El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
>>>
>>> You all say the index is such a great thing. So I might use it
>>> eventually. Other people might use it 1 out of 10 times. Yet other
>>> people use it 9 out of 10 times. Can you at least accept that the use of
>>> the index feature is different for each person?
>>>
>>> My suggested change, with the --a-if-empty option, would not impose
>>> anything on existing usage. But it would benefit those that rarely use
>>> an index and would like git to be smart enough to know when to use the
>>> index and when not. Yes, it would mean the use of the index ideology is
>>> not force upon people anymore. But isn't that a good thing? Free
>>> software is about freedom. That should include the freedom not to use
>>> the index method.
>>
>> Not really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want.
>>
>> But you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too. 
>>
>> And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.
> 
> But you are already rejecting it in the design phase before there even
> is a patch.
> 
>> In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less "surprising" for users coming from other systems, but we'd be throwing away something valuable in the process.
> 
> If I would ask to disable the indexing feature then you would have a
> point. But I am not. I'm asking to add something that allows to use git
> in a less "surprising" mode that, with the --a-if-empty option, does not
> alter anything else. Git would still have all its great, big, shiny,
> differentiating features to set it apart from other SCMs without forcing
> them down the users throat.
> 
>> I personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index "the Git way" bring, that it's hard to imagine how I ever lived without it.
>>
>> Cheers,
>> Wincent
> 
> I personaly have to work with different SCMs every day and every time I
> have to switch minds to work with each specific one. Making git commit
> work less surprising would be one less thing to keep in mind.

You are trying to make Git more difficult to understand for the user.
This is easily perceived as non-determinism.

Before introducing a code branch (à la "if $(git diff-index --quiet
HEAD)", think twice. It doubles testing efforts, it makes explanations
long-winded. What's so difficult about typing
[Arrow-Up] [Space] [-] [a] [Enter] if git commit comes up empty.

With your option, I need to remember that Git is overzealous and will
commit the whole index if nothing is staged, possibly git reset HEAD^
and clean up the mess. This is inconsistent and inefficient.

Try git gui or git citool if you can't be bothered to remember how to
add changes to your commit.  Git isn't alone.  Think BitKeeper, DARCS.
For other systems, there are extensions to help with committing, and to
emulate what DARCS has pioneered, for instance "hg record", an extension
for Mercurial.

> You like that Git is different so don't use the --a-if-empty option. You

No. I for one like the ability to stage changes and commit logically
cohesive changes without having to save files to temporary files.

> will have lost nothing by allowing that option in. So far I have read
> arguments from people saying they don't want to USE the option. But no
> arguments why there could not be such an option. And I'm not the only
> one that would welcome such an option. Is there no room for a compromise?

"Bloat". If I were the maintainer, I'd point you to aliases. If Git
itself can't do it, tossing a dozen shell lines into git's libexec would
do the job.  git diff-index --quiet is your friend.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: Please default to 'commit -a' when no changes were added

[Michael Witten]

On Fri, Apr 23, 2010 at 17:18, Matthias Andree <matthias.andree@gmx.de> wrote:
> Am 23.04.2010 21:34, schrieb Michael Witten:
>> On Fri, Apr 23, 2010 at 13:59, Matthias Andree <matthias.andree@gmx.de> 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".
>
> 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.

Re: Please default to 'commit -a' when no changes were added

[Michael Witten]

On Fri, Apr 23, 2010 at 17:25, Eric Raymond <esr@thyrsus.com> 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

Re: Please default to 'commit -a' when no changes were added

[Junio C Hamano]

Goswin von Brederlow <goswin-v-b@web.de> writes:

> But you are already rejecting it in the design phase before there even
> is a patch.

We do review both the design and the implementation on this list, and it
actually is a *good* thing if a proposal is rejected when its design is
flawed at the conceptual level.

A perfect implementation of an undesirable design is just as undesirable
as a buggy implementation of the same design.  It is a change that we do
not want to have in the system.

As to this particular proposed change to commit everything only when there
is no change between the index and the HEAD, I think it is a bad change.
As several people have already said, it adds unnecessary complexity to the
end user's mental model.

Re: Please default to 'commit -a' when no changes were added

[Eric Raymond]

Michael Witten <mfwitten@gmail.com>:
> On Fri, Apr 23, 2010 at 17:25, Eric Raymond <esr@thyrsus.com> 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."

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>

Re: Please default to 'commit -a' when no changes were added

[Michael Witten]

On Fri, Apr 23, 2010 at 23:38, Eric Raymond <esr@thyrsus.com> wrote:
> 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.

Re: Please default to 'commit -a' when no changes were added

[Eric Raymond]

Michael Witten <mfwitten@gmail.com>:
> On Fri, Apr 23, 2010 at 23:38, Eric Raymond <esr@thyrsus.com> wrote:
> > 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>

'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Jakub Narebski]

Jonathan Nieder <jrnieder@gmail.com> 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

Re: 'commit -a' safety

[Miles Bader]

Jakub Narebski <jnareb@gmail.com> writes:
> 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' 

That's bad because of the dual nature of "git add" -- someone may
normally use "-a" most of the time to commit changes, but has really no
choice other than git add to add a new file, So with this change, their
normal (and reasonable) habits would suddenly result in failure.

I think it's sort of annoying that "git add" has such a dual meaning
(instead of, for instance, having separate "add" and "stage" commands)
-- it's one of the more confusing things about learning about git
-- but oh well, it's unlikely to get changed at this point....

-Miles

-- 
Defenceless, adj. Unable to attack.

Re: 'commit -a' safety

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> I think it's sort of annoying that "git add" has such a dual meaning
> (instead of, for instance, having separate "add" and "stage" commands)

"git add -N" could be regarded as such a non-staging add command.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 'commit -a' safety

[Jakub Narebski]

On Sat, 24 April 2010, Miles Bader wrote:
> Jakub Narebski <jnareb@gmail.com> writes:

> > 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' 
> 
> That's bad because of the dual nature of "git add" -- someone may
> normally use "-a" most of the time to commit changes, but has really no
> choice other than git add to add a new file, So with this change, their
> normal (and reasonable) habits would suddenly result in failure.
> 
> I think it's sort of annoying that "git add" has such a dual meaning
> (instead of, for instance, having separate "add" and "stage" commands)
> -- it's one of the more confusing things about learning about git
> -- but oh well, it's unlikely to get changed at this point....

First, this is to be optional safety, by default turned off.  So if you
do not have problems with situation where you accidentally use 
'git commit -a' instead of 'git commit', committing not what you wanted
and prepared, you simply do not turn it on.


Second, to be more exact the safety would be triggered only if staged
change _differs_ from what is in working area.  Therefore

  $ git add file
  $ git commit -a

would not trigger this safety, while

  $ git add file
  $ edit file
  $ git commit -a
  fatal: There are staged changes

would trigger it.


Third, there is "git add -N" to mark file as tracked, but not add its
current context.

  $ git add -N file
  $ edit file
  $ git commit -a

should not trigger this safety.

-- 
Jakub Narebski
Poland

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Wincent Colaiuta]

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

Re: 'commit -a' safety

[Jakub Narebski]

Dnia sobota 24. kwietnia 2010 13:10, Wincent Colaiuta napisał:
> 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.

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

Re: Please default to 'commit -a' when no changes were added

[Tor Arntsen]

On Fri, Apr 23, 2010 at 21:34, Michael Witten <mfwitten@gmail.com> 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

Re: 'commit -a' safety

[Miles Bader]

On Sat, Apr 24, 2010 at 7:26 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Third, there is "git add -N" to mark file as tracked, but not add its
> current context.
>
>  $ git add -N file
>  $ edit file
>  $ git commit -a

Meh.  It's going to still require people to change their habits, and
while requiring people to use -N whenever they think they may want to
use "commit -a" later would work, it feels awkward and artificial.

All in all, it just doesn't smell clean, and I suspect that would
prevent many people from enabling such a feature.

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: 'commit -a' safety

[Joey Hess]

Jakub Narebski wrote:
> 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

Re: 'commit -a' safety

[Mike Hommey]

On Sat, Apr 24, 2010 at 10:28:48AM -0400, Joey Hess wrote:
> Jakub Narebski wrote:
> > 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

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Petr Baudis]

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

Bug#578764: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Wincent Colaiuta]

El 24/04/2010, a las 18:42, Petr Baudis escribió:

> 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).

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).

>> 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

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Petr Baudis]

On Sat, Apr 24, 2010 at 06:59:33PM +0200, Wincent Colaiuta wrote:
> El 24/04/2010, a las 18:42, Petr Baudis escribió:
> 
> > 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".

> >> 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

Re: 'commit -a' safety

[Nicolas Pitre]

On Sat, 24 Apr 2010, Jakub Narebski wrote:

> First, this is to be optional safety, by default turned off.  So if you
> do not have problems with situation where you accidentally use 
> 'git commit -a' instead of 'git commit', committing not what you wanted
> and prepared, you simply do not turn it on.

In which case it is worthless.  No one will turn this feature on if they 
don't fully understand what it entails, and those who do understand it 
are probably not the people who would actually benefit from it.

> Second, to be more exact the safety would be triggered only if staged
> change _differs_ from what is in working area.  Therefore
> 
>   $ git add file
>   $ git commit -a
> 
> would not trigger this safety, while
> 
>   $ git add file
>   $ edit file
>   $ git commit -a
>   fatal: There are staged changes
> 
> would trigger it.

Much better yet would be a warning at the top of the summary message in 
the commit text editor.  This way you won't introduce an incompatible 
and potentially annoying behavior that no one is likely to opt-in for, 
and the warning will give a hint that you might be losing some 
intermediate state if you don't abort the commit.


Nicolas

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1577 bytes --]

On Sat, 24 Apr 2010, Petr Baudis wrote:

> 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).

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

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Petr Baudis]

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

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Nicolas Pitre]

On Sat, 24 Apr 2010, Petr Baudis wrote:

> 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.

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

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Jacob Helwig]

On Sat, Apr 24, 2010 at 11:54, Petr Baudis <pasky@suse.cz> 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.

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Nicolas Pitre]

On Sat, 24 Apr 2010, Jacob Helwig wrote:

> On Sat, Apr 24, 2010 at 11:54, Petr Baudis <pasky@suse.cz> 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.

Sure.  But do you happen to often "commit -a" more changes to an already 
previously modified and staged (but not committed yet) file?


Nicolas

Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

[Jacob Helwig]

On Sat, Apr 24, 2010 at 12:44, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sat, 24 Apr 2010, Jacob Helwig wrote:
>
>> On Sat, Apr 24, 2010 at 11:54, Petr Baudis <pasky@suse.cz> 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.
>
> 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.

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Nicolas Pitre <nico@fluxnic.net> writes:

> On Fri, 23 Apr 2010, Goswin von Brederlow wrote:
>
>> I personaly have to work with different SCMs every day and every time I
>> have to switch minds to work with each specific one. Making git commit
>> work less surprising would be one less thing to keep in mind.
>
> Please make yourself some git aliases and your problem will be solved.  
> After all, the alias mechanism was created for a reason.

I would accept an alias. But so far two people have suggested an alias
for this and both have completly failed to achived the desired result.

If you know of a test to check if an index exists or not, preferably one
that does consider new files being added or files being removed as
"index exists", then please do speak up.

>> You like that Git is different so don't use the --a-if-empty option. You
>> will have lost nothing by allowing that option in. So far I have read
>> arguments from people saying they don't want to USE the option. But no
>> arguments why there could not be such an option. And I'm not the only
>> one that would welcome such an option. Is there no room for a compromise?
>
> I suggest you have a look at all the examples (some are simple, some are 
> complex) here: https://git.wiki.kernel.org/index.php/Aliases. It should 
> be simple to make an alias with all the safety valves you might think 
> of, and then it could even be contributed to section 7 of that page.

None of the examples have anything to do with checking for an index so
that page is rather useless. I know how to set an alias. I just don't
know what to put into it.

> Nicolas

MfG
        Goswin

Re: Please default to 'commit -a' when no changes were added

[Jonathan Nieder]

Hi again,

Goswin von Brederlow wrote:

> so far two people have suggested an alias
> for this and both have completly failed to achived the desired result.

I had thought Adam already suggested using ‘git diff-index --cached
--quiet HEAD’ [1].

You can do so like this:

cat <<-EOF >$HOME/bin/git-ci
#!/bin/sh
cleanindex() { git diff-index --cached --quiet HEAD; }

if test "$1" != "-h"
then
	echo >&2 usage: git ci &&
	exit 129
fi
if test "$#" != 0
then
	echo >&2 Please use git commit directly.
	if cleanindex
	then
		echo >&2 '(no staged changes)'
	else
		git diff --cached --name-status
	fi
	exit 129
fi
if cleanindex
then
	exec git commit -a
else
	exec git commit
fi
EOF
chmod +x $HOME/bin/git-ci

But dense as I am, I still can’t imagine why

echo '[alias] ci = commit -a' >>$HOME/.gitconfig

wouldn’t be better in every way (especially if Jakub’s
commit.preserveindex is enabled).

> If you know of a test to check if an index exists or not, preferably one
> that does consider new files being added or files being removed as
> "index exists", then please do speak up.

test -e .git/index

I know, not what you meant.  But the condition you are looking for is
“staged content does not match the last commit”, not “the tool has
suddenly entered a different mode”.

Hope that helps,
Jonathan

[1] Well, he did:
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145581

Re: Please default to 'commit -a' when no changes were added

[Goswin von Brederlow]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Hi again,
>
> Goswin von Brederlow wrote:
>
>> so far two people have suggested an alias
>> for this and both have completly failed to achived the desired result.
>
> I had thought Adam already suggested using ‘git diff-index --cached
> --quiet HEAD’ [1].
>
> You can do so like this:
>
> cat <<-EOF >$HOME/bin/git-ci
> #!/bin/sh
> cleanindex() { git diff-index --cached --quiet HEAD; }

Thanks. That is the missing test.

> if test "$1" != "-h"
> then
> 	echo >&2 usage: git ci &&
> 	exit 129
> fi
> if test "$#" != 0
> then
> 	echo >&2 Please use git commit directly.
> 	if cleanindex
> 	then
> 		echo >&2 '(no staged changes)'
> 	else
> 		git diff --cached --name-status
> 	fi
> 	exit 129
> fi
> if cleanindex
> then
> 	exec git commit -a
> else
> 	exec git commit
> fi
> EOF
> chmod +x $HOME/bin/git-ci
>
> But dense as I am, I still can’t imagine why
>
> echo '[alias] ci = commit -a' >>$HOME/.gitconfig
>
> wouldn’t be better in every way (especially if Jakub’s
> commit.preserveindex is enabled).

Because with the above test it knows when -a is wrong and won't use it.

>> If you know of a test to check if an index exists or not, preferably one
>> that does consider new files being added or files being removed as
>> "index exists", then please do speak up.
>
> test -e .git/index
>
> I know, not what you meant.  But the condition you are looking for is
> “staged content does not match the last commit”, not “the tool has
> suddenly entered a different mode”.
>
> Hope that helps,
> Jonathan
>
> [1] Well, he did:
> http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145581

Must have overlooked that mail, sorry.

Re: Please default to 'commit -a' when no changes were added

[Jonathan Nieder]

Goswin von Brederlow wrote:

> Must have overlooked that mail, sorry.

No problem.  Sorry for my impatience with the long thread.  Out of
this discussion there have already emerged two ideas I like a lot:

 1. a more noticeable safety for ‘git commit’ with no staged changes
 2. Jakub’s safety for ‘git commit -a’ with staged changes

Thanks.

Re: 'commit -a' safety

[Jakub Narebski]

Dnia sobota 24. kwietnia 2010 18:42, Petr Baudis napisał:
> 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.

Isn't it how (most of) backwards incompatibile changes are made, first
adding an option for new behaviour, then later (optionally) changing
the default?
 
>> 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?
 
>> 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

Re: 'commit -a' safety

[Jakub Narebski]

On Sat, 24 Apr 2010, Nicolas Pitre wrote:
> On Sat, 24 Apr 2010, Jakub Narebski wrote:
> 
> > First, this is to be optional safety, by default turned off.  So if you
> > do not have problems with situation where you accidentally use 
> > 'git commit -a' instead of 'git commit', committing not what you wanted
> > and prepared, you simply do not turn it on.
> 
> In which case it is worthless.  No one will turn this feature on if they 
> don't fully understand what it entails, and those who do understand it 
> are probably not the people who would actually benefit from it.

One would turn it after losing carefully prepared index by running 
"git commit -a" when one meant "git commit" ;-)

More seriously, it could be made default if it is not too annoying.

> > Second, to be more exact the safety would be triggered only if staged
> > change _differs_ from what is in working area.  Therefore
> > 
> >   $ git add file
> >   $ git commit -a
> > 
> > would not trigger this safety, while
> > 
> >   $ git add file
> >   $ edit file
> >   $ git commit -a
> >   fatal: There are staged changes
> > 
> > would trigger it.
> 
> Much better yet would be a warning at the top of the summary message in 
> the commit text editor.  This way you won't introduce an incompatible 
> and potentially annoying behavior that no one is likely to opt-in for, 
> and the warning will give a hint that you might be losing some 
> intermediate state if you don't abort the commit.

As Petr Baudis said, this actually work *if* you use editor to generate
commit message, and you have chance to see commit message template.
Also the information was considered not visible enought, hence patch
at the beginning of the series.

-- 
Jakub Narebski
Poland

Re: 'commit -a' safety

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> 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!

I am somewhat torn.

I have made mistake of running "commit -a" after I spent time sifting my
changes in the work tree.  I can see that I would have been helped by it
if the safety were there.

But at the same time, I also know that my development is often a cycle of
change then diff then add (to mark the part I am happy with), and when I
am happy with the output from diff, I conclude it with "commit -a" to
conclude the whole thing.  I can see that I would be irritated to if that
final step failed.

But I suspect the irritation would be relatively mild: "ah, these days I
shouldn't use 'commig -a' to conclude these incremental change-review-add
cycle; instead, I should say 'add -u' then 'commit'".

Re: 'commit -a' safety

[Miles Bader]

Jakub Narebski <jnareb@gmail.com> writes:
> More seriously, it could be made default if it is not too annoying.

But the problem is that it _does_ sound annoying...

-Miles

-- 
Politeness, n. The most acceptable hypocrisy.

Re: Please default to 'commit -a' when no changes were added

[Miles Bader]

Jonathan Nieder <jrnieder@gmail.com> writes:
> But dense as I am, I still can’t imagine why
>
> echo '[alias] ci = commit -a' >>$HOME/.gitconfig
>
> wouldn’t be better in every way (especially if Jakub’s
> commit.preserveindex is enabled).

If the latter is enabled, you can't use "git add" to add new files,
you'll have to remember to use "add -N" (or add some alias for that
too).

-Miles

-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: Please default to 'commit -a' when no changes were added

[Jonathan Nieder]

Miles Bader wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> But dense as I am, I still can’t imagine why
>>
>> echo '[alias] ci = commit -a' >>$HOME/.gitconfig
>>
>> wouldn’t be better in every way (especially if Jakub’s
>> commit.preserveindex is enabled).
>
> If the latter is enabled, you can't use "git add" to add new files,
> you'll have to remember to use "add -N" (or add some alias for that
> too).

Didn’t he first [1] propose a variant in which using ‘git add -N’ was
not necessary?  The rule was something like this: consider each entry.
If it

 - matches HEAD, or
 - matches the work tree, or
 - is an intent-to-add

then we say it is easily recoverable.  If all index entries are
easily recoverable, then let the commit -a go through.

Jonathan

[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145662

Re: 'commit -a' safety

[Jakub Narebski]

Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>> 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!
> 
> I am somewhat torn.
> 
> I have made mistake of running "commit -a" after I spent time sifting my
> changes in the work tree.  I can see that I would have been helped by it
> if the safety were there.
> 
> But at the same time, I also know that my development is often a cycle of
> change then diff then add (to mark the part I am happy with), and when I
> am happy with the output from diff, I conclude it with "commit -a" to
> conclude the whole thing.  I can see that I would be irritated to if that
> final step failed.
> 
> But I suspect the irritation would be relatively mild: "ah, these days I
> shouldn't use 'commig -a' to conclude these incremental change-review-add
> cycle; instead, I should say 'add -u' then 'commit'".

Or, 'git commit -f -a' (which means 'git commit --force --all').

-- 
Jakub Narebski
Poland