seperate commits for objects already updated in index?

Hi,

Dumb question, imagine you made changes to a few files, and ran 
update-index at various stages in between:

$ git status
#
# Updated but not checked in:
#   (will commit)
#
#       modified: foo/ChangeLog
#       modified: foo/whatever
#       modified: bar/ChangeLog
#       modified: bar/other

The changes in bar/ are unrelated to the changes in foo/ - how do you 
commit each seperately? Git doesn't seem to want to let me:

   $ git commit -o bar
   Different in index and the last commit:
   M       bar/ChangeLog
   M       bar/other
   You might have meant to say 'git commit -i paths...', perhaps?

git commit on its own wants to commit all the above files.

what's the silly thing I've missed?

Thanks.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Never tell a lie unless it is absolutely convenient.

On Tue, 14 Mar 2006, Paul Jakma wrote:

Hi,

Dumb question, imagine you made changes to a few files, and ran update-index
at various stages in between:

$ git status
#
# Updated but not checked in:
#   (will commit)
#
#       modified: foo/ChangeLog
#       modified: foo/whatever
#       modified: bar/ChangeLog
#       modified: bar/other

The changes in bar/ are unrelated to the changes in foo/ - how do you commit
each seperately? Git doesn't seem to want to let me:

  $ git commit -o bar
  Different in index and the last commit:
  M       bar/ChangeLog
  M       bar/other
  You might have meant to say 'git commit -i paths...', perhaps?

git commit on its own wants to commit all the above files.

what's the silly thing I've missed?

You've already marked them all modified in the index (using 
git-update-index), so git commit thinks you are confused by naming them 
again and saying "only".

The simplest thing to do is to do

	git reset

to reset your index back to your HEAD (but obviously DON'T use the "-f" 
flag, which will also force the working tree!). That will make your index 
clean, and undo the fact that you've already marked things to be committed 
with "git-update-index".

Then you can just do

	git commit -o bar

and everything should be fine, because then git doesn't think you're doing 
something insane.

		Linus

On Tue, 14 Mar 2006, Linus Torvalds wrote:

The simplest thing to do is to do

	git reset

to reset your index back to your HEAD (but obviously DON'T use the "-f"
flag, which will also force the working tree!).

Ah, of course! (I knew I was being dumb ;) ).

Then you can just do

	git commit -o bar

and everything should be fine, because then git doesn't think you're doing
something insane.

Yep, thank you!

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
The less a statesman amounts to, the more he loves the flag.
 		-- Kin Hubbard

On Tue, 14 Mar 2006, Paul Jakma wrote:

On Tue, 14 Mar 2006, Linus Torvalds wrote:

quoted

The simplest thing to do is to do

	git reset

to reset your index back to your HEAD (but obviously DON'T use the "-f"
flag, which will also force the working tree!).

Ah, of course! (I knew I was being dumb ;) ).

Well, I actually think git is being somewhat of an ass, for no really good 
reason. It's true that you are doing something pretty strange by _both_ 
using "git-update-index" and "git commit -o" but the fact is, at least 
when adding files, that would be expected (ie you have to mark a file 
in the index to add it).

I also think that test is historical, from before Junio cleaned up how 
"git commit" worked - it _used_ to be that "git commit" would work in the 
current index, but these days it generates a new index to commit when you 
do "-o", so there's really no _technical_ reason to refuse the partial 
commit any more as far as I can see.

So I don't know. I don't think you were being dumb, I think git could have 
been friendlier to you.

		Linus

On Tue, 14 Mar 2006, Linus Torvalds wrote:

Well, I actually think git is being somewhat of an ass, for no 
really good reason. It's true that you are doing something pretty 
strange by _both_ using "git-update-index" and "git commit -o" but 
the fact is, at least when adding files, that would be expected (ie 
you have to mark a file in the index to add it).

Well, I tend to work on one thing, then notice something else 
unrelated (or in a support file), fix/tweak that, etc.. I use the 
index for 'way-point' diffs, rather than commit things I havn't quite 
tested yet (or dont know whether they'll be useful yet).

I also think that test is historical, from before Junio cleaned up 
how "git commit" worked - it _used_ to be that "git commit" would 
work in the current index, but these days it generates a new index 
to commit when you do "-o", so there's really no _technical_ reason 
to refuse the partial commit any more as far as I can see.

Aha. So that check possibly could just be removed?

So I don't know. I don't think you were being dumb, I think git 
could have been friendlier to you.

:)

git reset works just fine too.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
A day for firm decisions!!!!!  Or is it?