non-empty index with git commit -a

Heya,

Can we please fix this?

$ hack hack hack
$ git add -p # carefully add my changes
$ git commit -am "Add feature foo"
$ DAAAMN YOUUU FINGERS!!

I remember bringing this up before, but I can't remember what the
discussion ended up coming to.

-- 
Cheers,

Sverre Rabbelier

On Tue, Feb 15, 2011 at 10:43:53PM +0000, Sverre Rabbelier wrote:

Can we please fix this?

$ hack hack hack
$ git add -p # carefully add my changes
$ git commit -am "Add feature foo"
$ DAAAMN YOUUU FINGERS!!

I remember bringing this up before, but I can't remember what the
discussion ended up coming to.

How do you differentiate this from:

  $ hack hack hack
  $ git add -p ;# carefully add my changes
  $ hack hack hack
  $ git diff ;# ok, everything looks good
  $ git commit -am "Add feature foo"

? IOW, I don't think git can know that you are making a mistake in your
case, since from its perspectives those same actions might be
reasonable. The real problem is that your intermediate index state is
never saved. Do we need an index reflog? :)

-Peff

Jeff King wrote:

On Tue, Feb 15, 2011 at 10:43:53PM +0000, Sverre Rabbelier wrote:

quoted

Can we please fix this?

$ hack hack hack
$ git add -p # carefully add my changes
$ git commit -am "Add feature foo"
$ DAAAMN YOUUU FINGERS!!

I remember bringing this up before, but I can't remember what the
discussion ended up coming to.

How do you differentiate this from:

  $ hack hack hack
  $ git add -p ;# carefully add my changes
  $ hack hack hack
  $ git diff ;# ok, everything looks good
  $ git commit -am "Add feature foo"

?

If I remember the discussion[1] correctly, by requiring a separate
add -u step (or commit -f -a) if the "I don't trust my fingers"
configuration is enabled.

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

On Tue, Feb 15, 2011 at 09:20:47PM -0600, Jonathan Nieder wrote:

Jeff King wrote:

quoted

On Tue, Feb 15, 2011 at 10:43:53PM +0000, Sverre Rabbelier wrote:

quoted

quoted

Can we please fix this?

$ hack hack hack
$ git add -p # carefully add my changes
$ git commit -am "Add feature foo"
$ DAAAMN YOUUU FINGERS!!

I remember bringing this up before, but I can't remember what the
discussion ended up coming to.

How do you differentiate this from:

  $ hack hack hack
  $ git add -p ;# carefully add my changes
  $ hack hack hack
  $ git diff ;# ok, everything looks good
  $ git commit -am "Add feature foo"

?

If I remember the discussion[1] correctly, by requiring a separate
add -u step (or commit -f -a) if the "I don't trust my fingers"
configuration is enabled.

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

Thanks for the link, I didn't recall that discussion. I have no problem
with a config option that requires an extra step, but such a safety
valve should definitely be optional, since the current behavior is part
of a perfectly reasonable workflow.

-Peff

Heya,

On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder [off-list ref] wrote:

If I remember the discussion[1] correctly, by requiring a separate
add -u step (or commit -f -a) if the "I don't trust my fingers"
configuration is enabled.

That would definitely work for me. The question then is, should git
consider the index precious by default, or not? That is, should that
value default to true in 1.8?

-- 
Cheers,

Sverre Rabbelier

On Wed, Feb 16, 2011 at 3:18 PM, Sverre Rabbelier [off-list ref] wrote:

Heya,

On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder [off-list ref] wrote:

quoted

If I remember the discussion[1] correctly, by requiring a separate
add -u step (or commit -f -a) if the "I don't trust my fingers"
configuration is enabled.

That would definitely work for me. The question then is, should git
consider the index precious by default, or not? That is, should that
value default to true in 1.8?

Is it insane that "git commit -a" still commits everything, but then

1. If old index is different from old HEAD, keeps index as is and warn users
2. If old index is the same as old HEAD, update index with new HEAD

?
-- 
Duy

Nguyen Thai Ngoc Duy wrote:

On Wed, Feb 16, 2011 at 3:18 PM, Sverre Rabbelier [off-list ref] wrote:

quoted

On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder [off-list ref] wrote:

quoted

quoted

If I remember the discussion[1] correctly, by requiring a separate
add -u step (or commit -f -a) if the "I don't trust my fingers"
configuration is enabled.

That would definitely work for me. The question then is, should git
consider the index precious by default, or not? That is, should that
value default to true in 1.8?

Is it insane that "git commit -a" still commits everything, but then

1. If old index is different from old HEAD, keeps index as is and warn users
2. If old index is the same as old HEAD, update index with new HEAD

?

Yes, I think that would be very confusing. :)

My take on Sverre's question: this doesn't seem to fit the "bad choice
made long ago and finally we have a chance to fix it" mold.  More like
"nice new feature that could break muscle memory".  So I don't think
it makes sense to tie it to 1.8.

If I were writing the patch, I'd provide the configuration and hope
that the experience of using it could help with deciding on a good
default behavior.

On Wed, Feb 16, 2011 at 08:18:18AM +0000, Sverre Rabbelier wrote:

On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder [off-list ref] wrote:

quoted

If I remember the discussion[1] correctly, by requiring a separate
add -u step (or commit -f -a) if the "I don't trust my fingers"
configuration is enabled.

That would definitely work for me. The question then is, should git
consider the index precious by default, or not? That is, should that
value default to true in 1.8?

If we do not consider the index precious, then no, it should not be the
default. If we do consider it precious, then isn't this option fixing
one small case and leaving all of the others untouched?

I can just as easily run "git add -u", or "git add -p" on top of some
changes and then realize afterwards that I actually wanted the previous
index state.

The solution for that would be an index reflog.

-Peff

Heya,

On Wed, Feb 16, 2011 at 08:51, Jeff King [off-list ref] wrote:

I can just as easily run "git add -u", or "git add -p" on top of some
changes and then realize afterwards that I actually wanted the previous
index state.

I disagree, those are all index manipulation tools, `git commit -a` is not.

-- 
Cheers,

Sverre Rabbelier

On Wed, Feb 16, 2011 at 09:52:23AM +0000, Sverre Rabbelier wrote:

On Wed, Feb 16, 2011 at 08:51, Jeff King [off-list ref] wrote:

quoted

I can just as easily run "git add -u", or "git add -p" on top of some
changes and then realize afterwards that I actually wanted the previous
index state.

I disagree, those are all index manipulation tools, `git commit -a` is not.

So? Your question was whether index state is precious. If it's precious,
shouldn't we be keeping a history of it?

-Peff

Heya,

On Wed, Feb 16, 2011 at 09:54, Jeff King [off-list ref] wrote:

So? Your question was whether index state is precious. If it's precious,
shouldn't we be keeping a history of it?

I don't think it's quite _that_ precious, but the only operation that
I regularly use that can blow away my carefully constructed index as
side effect of doing something else is `git commit -a`.

-- 
Cheers,

Sverre Rabbelier

On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:

On Wed, Feb 16, 2011 at 09:54, Jeff King [off-list ref] wrote:

quoted

So? Your question was whether index state is precious. If it's precious,
shouldn't we be keeping a history of it?

I don't think it's quite _that_ precious, but the only operation that
I regularly use that can blow away my carefully constructed index as
side effect of doing something else is `git commit -a`.

OK, so how precious is it? :)

If you want to have an option that specifically prevents the "git commit
-a" muscle memory thing, then go for it. I'm guessing it is the most
common "oops" one. Even with an index reflog, you might want it on top.

But it just seems silly to me to not protect at the same time against
the other ways you can lose state from the index.

-Peff

Jeff King venit, vidit, dixit 16.02.2011 11:06:

On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:

quoted

On Wed, Feb 16, 2011 at 09:54, Jeff King [off-list ref] wrote:

quoted

So? Your question was whether index state is precious. If it's precious,
shouldn't we be keeping a history of it?

I don't think it's quite _that_ precious, but the only operation that
I regularly use that can blow away my carefully constructed index as
side effect of doing something else is `git commit -a`.

OK, so how precious is it? :)

Maybe it's a bit precious, but not overly...

If you want to have an option that specifically prevents the "git commit
-a" muscle memory thing, then go for it. I'm guessing it is the most
common "oops" one. Even with an index reflog, you might want it on top.

But it just seems silly to me to not protect at the same time against
the other ways you can lose state from the index.

-Peff

so that keeping one backup would be enough? I.e. an automated way of
doing "cp index index.bak" before an index update and some "reset"
incarnation to revive the copy?

Michael

On Wed, Feb 16, 2011 at 03:41:35PM +0100, Michael J Gruber wrote:

quoted

If you want to have an option that specifically prevents the "git commit
-a" muscle memory thing, then go for it. I'm guessing it is the most
common "oops" one. Even with an index reflog, you might want it on top.

But it just seems silly to me to not protect at the same time against
the other ways you can lose state from the index.

so that keeping one backup would be enough? I.e. an automated way of
doing "cp index index.bak" before an index update and some "reset"
incarnation to revive the copy?

No, I am not proposing one backup. I am proposing a reflog with multiple
entries that would be expired on the regular reflog schedule.

-Peff