{"thread":{"id":"3645","subject":"seperate commits for objects already updated in index?","startedAt":"2006-03-14T16:37:40Z","lastAt":"2006-03-15T19:43:12Z","messageCount":11,"participants":["Paul Jakma","Linus Torvalds","Junio C Hamano","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17543","messageId":"Pine.LNX.4.64.0603141634010.5276@sheen.jakma.org","threadId":"3645","inReplyTo":null,"subject":"seperate commits for objects already updated in index?","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2006-03-14T16:37:40Z","receivedAt":"2006-03-14T16:37:40Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"Hi,\n\nDumb question, imagine you made changes to a few files, and ran \nupdate-index at various stages in between:\n\n$ git status\n#\n# Updated but not checked in:\n# (will commit)\n#\n# modified: foo/ChangeLog\n# modified: foo/whatever\n# modified: bar/ChangeLog\n# modified: bar/other\n\nThe changes in bar/ are unrelated to the changes in foo/ - how do you \ncommit each seperately? Git doesn't seem to want to let me:\n\n $ git commit -o bar\n Different in index and the last commit:\n M bar/ChangeLog\n M bar/other\n You might have meant to say 'git commit -i paths...', perhaps?\n\ngit commit on its own wants to commit all the above files.\n\nwhat's the silly thing I've missed?\n\nThanks.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nNever tell a lie unless it is absolutely convenient.\n"},{"id":"17544","messageId":"Pine.LNX.4.64.0603140856120.3618@g5.osdl.org","threadId":"3645","inReplyTo":"Pine.LNX.4.64.0603141634010.5276@sheen.jakma.org","subject":"Re: seperate commits for objects already updated in index?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-14T17:00:30Z","receivedAt":"2006-03-14T17:00:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Mar 2006, Paul Jakma wrote:\n\n> Hi,\n> \n> Dumb question, imagine you made changes to a few files, and ran update-index\n> at various stages in between:\n> \n> $ git status\n> #\n> # Updated but not checked in:\n> # (will commit)\n> #\n> # modified: foo/ChangeLog\n> # modified: foo/whatever\n> # modified: bar/ChangeLog\n> # modified: bar/other\n> \n> The changes in bar/ are unrelated to the changes in foo/ - how do you commit\n> each seperately? Git doesn't seem to want to let me:\n> \n> $ git commit -o bar\n> Different in index and the last commit:\n> M bar/ChangeLog\n> M bar/other\n> You might have meant to say 'git commit -i paths...', perhaps?\n> \n> git commit on its own wants to commit all the above files.\n> \n> what's the silly thing I've missed?\n\nYou've already marked them all modified in the index (using \ngit-update-index), so git commit thinks you are confused by naming them \nagain and saying \"only\".\n\nThe simplest thing to do is to do\n\n\tgit reset\n\nto reset your index back to your HEAD (but obviously DON'T use the \"-f\" \nflag, which will also force the working tree!). That will make your index \nclean, and undo the fact that you've already marked things to be committed \nwith \"git-update-index\".\n\nThen you can just do\n\n\tgit commit -o bar\n\nand everything should be fine, because then git doesn't think you're doing \nsomething insane.\n\n\t\tLinus\n"},{"id":"17545","messageId":"Pine.LNX.4.64.0603141703080.5276@sheen.jakma.org","threadId":"3645","inReplyTo":"Pine.LNX.4.64.0603140856120.3618@g5.osdl.org","subject":"Re: seperate commits for objects already updated in index?","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2006-03-14T17:04:55Z","receivedAt":"2006-03-14T17:04:55Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Tue, 14 Mar 2006, Linus Torvalds wrote:\n\n> The simplest thing to do is to do\n>\n> \tgit reset\n>\n> to reset your index back to your HEAD (but obviously DON'T use the \"-f\"\n> flag, which will also force the working tree!).\n\nAh, of course! (I knew I was being dumb ;) ).\n\n> Then you can just do\n>\n> \tgit commit -o bar\n>\n> and everything should be fine, because then git doesn't think you're doing\n> something insane.\n\nYep, thank you!\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nThe less a statesman amounts to, the more he loves the flag.\n \t\t-- Kin Hubbard\n"},{"id":"17547","messageId":"Pine.LNX.4.64.0603140915290.3618@g5.osdl.org","threadId":"3645","inReplyTo":"Pine.LNX.4.64.0603141703080.5276@sheen.jakma.org","subject":"Re: seperate commits for objects already updated in index?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-14T17:20:22Z","receivedAt":"2006-03-14T17:20:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Mar 2006, Paul Jakma wrote:\n\n> On Tue, 14 Mar 2006, Linus Torvalds wrote:\n> \n> > The simplest thing to do is to do\n> > \n> > \tgit reset\n> > \n> > to reset your index back to your HEAD (but obviously DON'T use the \"-f\"\n> > flag, which will also force the working tree!).\n> \n> Ah, of course! (I knew I was being dumb ;) ).\n\nWell, I actually think git is being somewhat of an ass, for no really good \nreason. It's true that you are doing something pretty strange by _both_ \nusing \"git-update-index\" and \"git commit -o\" but the fact is, at least \nwhen adding files, that would be expected (ie you have to mark a file \nin the index to add it).\n\nI also think that test is historical, from before Junio cleaned up how \n\"git commit\" worked - it _used_ to be that \"git commit\" would work in the \ncurrent index, but these days it generates a new index to commit when you \ndo \"-o\", so there's really no _technical_ reason to refuse the partial \ncommit any more as far as I can see.\n\nSo I don't know. I don't think you were being dumb, I think git could have \nbeen friendlier to you.\n\n\t\tLinus\n"},{"id":"17549","messageId":"Pine.LNX.4.64.0603141723240.5276@sheen.jakma.org","threadId":"3645","inReplyTo":"Pine.LNX.4.64.0603140915290.3618@g5.osdl.org","subject":"Re: seperate commits for objects already updated in index?","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2006-03-14T17:27:19Z","receivedAt":"2006-03-14T17:27:19Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Tue, 14 Mar 2006, Linus Torvalds wrote:\n\n> Well, I actually think git is being somewhat of an ass, for no \n> really good reason. It's true that you are doing something pretty \n> strange by _both_ using \"git-update-index\" and \"git commit -o\" but \n> the fact is, at least when adding files, that would be expected (ie \n> you have to mark a file in the index to add it).\n\nWell, I tend to work on one thing, then notice something else \nunrelated (or in a support file), fix/tweak that, etc.. I use the \nindex for 'way-point' diffs, rather than commit things I havn't quite \ntested yet (or dont know whether they'll be useful yet).\n\n> I also think that test is historical, from before Junio cleaned up \n> how \"git commit\" worked - it _used_ to be that \"git commit\" would \n> work in the current index, but these days it generates a new index \n> to commit when you do \"-o\", so there's really no _technical_ reason \n> to refuse the partial commit any more as far as I can see.\n\nAha. So that check possibly could just be removed?\n\n> So I don't know. I don't think you were being dumb, I think git \n> could have been friendlier to you.\n\n:)\n\ngit reset works just fine too.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nA day for firm decisions!!!!! Or is it?\n"},{"id":"17558","messageId":"7vwtewk2jp.fsf@assigned-by-dhcp.cox.net","threadId":"3645","inReplyTo":"Pine.LNX.4.64.0603140915290.3618@g5.osdl.org","subject":"Re: seperate commits for objects already updated in index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-14T23:51:54Z","receivedAt":"2006-03-14T23:51:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I also think that test is historical, from before Junio cleaned up how \n> \"git commit\" worked - it _used_ to be that \"git commit\" would work in the \n> current index, but these days it generates a new index to commit when you \n> do \"-o\", so there's really no _technical_ reason to refuse the partial \n> commit any more as far as I can see.\n>\n> So I don't know. I don't think you were being dumb, I think git could have \n> been friendlier to you.\n\nI have to go back to the list archive, but if I recall correctly\nthe refusal was added to be friendlier -- by being safer -- and\nwas not there in the earlier round of -o/-i proposal.\n"},{"id":"17559","messageId":"7vy7zcie5c.fsf@assigned-by-dhcp.cox.net","threadId":"3645","inReplyTo":"7vwtewk2jp.fsf@assigned-by-dhcp.cox.net","subject":"Re: seperate commits for objects already updated in index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-15T03:24:15Z","receivedAt":"2006-03-15T03:24:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The background behind this is around beginning of February 2006,\nthe thread \"Two ideas\" by Carl Worth. And the current behaviour\nis defined by this commit. I'll talk about a possible\nimprovement but first, here is what it does:\n\ncommit 130fcca63fe8e7e087e7419907e018cbbaf434a3\nAuthor: Junio C Hamano \nDate: Sun Feb 5 00:07:44 2006 -0800\n\n ...\n\n - \"git commit paths...\" acquires a new semantics. This is an\n incompatible change that needs user training, which I am\n still a bit reluctant to swallow, but enough people seem to\n have complained that it is confusing to them. It\n \n 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds\n trained git users that the traditional semantics now needs\n -i flag.\n \n 2. refuses to run if named paths... are different in HEAD and\n the index (ditto about reminding). Added paths are OK.\n \n 3. reads HEAD commit into a temporary index file.\n \n 4. updates named paths... from the working tree in this\n temporary index.\n \n 5. does the same updates of the paths... from the working\n tree to the real index.\n \n 6. makes a commit using the temporary index that has the\n current HEAD as the parent, and updates the HEAD with this\n new commit.\n\n ...\n\nThe check that prevents you from doing\n\n\t$ edit A B\n\t$ git update-index A B\n $ git commit -o B\n\nis the rule #2, which I think could use further improvement. It\nis to address the \"committing skewed files\" issue Carl brought\nup in that thread.\n\nIt might be better to further check if the working tree file is\nthe same as the index, and to allow a commit in such a case.\n\nThe intent of rule #2 is to prevent this from happening:\n\n\t$ edit A B\n $ git update-index A B\n $ edit B again\n $ git commit -o B\n\nWhen this happens, the real index will have _old_ contents of B\nthat never was committed, and does not match what is in the\nindex. But after the commit, we will match the real index to\nwhat was committed, so we will _lose_ the index entry for B\nbefore the second edit you explicitly told git to remember by\nsaying 'update-index'.\n\nOn the other hand, in your original sequence:\n\n\t$ edit A B\n $ git update-index A B\n $ git commit -o B\n\nB being committed would be different between HEAD and index, but\nthat is what we are going to commit anyway, so after this\ncommit, B will be in sync with the updated HEAD.\n\nTo put it in another way, \"commit -o\" is a short-hand for people\nwho do not want to run update-index themselves (IOW, people who\njust want to use git without worrying about the index file). If\nyou use update-index to mark \"this is what I want to commit\"\nyourself, you should do so consistently. If you are not ready\nto commit A but you want to commit B, do not mark both of them\nand expect \"commit -o\" to do magic fixups.\n"},{"id":"17562","messageId":"Pine.LNX.4.64.0603151312030.5276@sheen.jakma.org","threadId":"3645","inReplyTo":"7vy7zcie5c.fsf@assigned-by-dhcp.cox.net","subject":"Re: seperate commits for objects already updated in index?","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2006-03-15T13:28:48Z","receivedAt":"2006-03-15T13:28:48Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Tue, 14 Mar 2006, Junio C Hamano wrote:\n\n\n\n> It might be better to further check if the working tree file is the \n> same as the index, and to allow a commit in such a case.\n\nThat would be a nice improvement.\n\n> The intent of rule #2 is to prevent this from happening:\n>\n> \t$ edit A B\n> $ git update-index A B\n> $ edit B again\n> $ git commit -o B\n\n> When this happens, the real index will have _old_ contents of B \n> that never was committed, and does not match what is in the index. \n> But after the commit, we will match the real index to what was \n> committed, so we will _lose_ the index entry for B before the \n> second edit you explicitly told git to remember by saying \n> 'update-index'.\n\nThat would indeed be annoying, and I'd obviously prefer to have to \nrun 'git reset' than have the above happen!\n\nHowever, I'd have expected that any porcelain command would \nsynchronise index with HEAD after a commit. See below for my (still \nnewbie-ish ;) ) user-level mental model of git.\n\n> On the other hand, in your original sequence:\n>\n> \t$ edit A B\n> $ git update-index A B\n> $ git commit -o B\n>\n> B being committed would be different between HEAD and index, but \n> that is what we are going to commit anyway, so after this commit, B \n> will be in sync with the updated HEAD.\n\nRight. So if the file in the index and working tree are the same \n(hey, i just ran update-index after all), then that check could be \nloosened. The only thing the commit can do is bring the /3rd/ piece \nof the puzzle (HEAD) in sync :).\n\n> To put it in another way, \"commit -o\" is a short-hand for people \n> who do not want to run update-index themselves (IOW, people who \n> just want to use git without worrying about the index file). If \n> you use update-index to mark \"this is what I want to commit\" \n> yourself, you should do so consistently. If you are not ready to \n> commit A but you want to commit B, do not mark both of them and \n> expect \"commit -o\" to do magic fixups.\n\nI guess my problem here is that I consider the index to be a 'weak' \ncache.\n\nI like to use it for intermediate way-points or \"weak commits\", \nhowever if I commit to HEAD I /really/ want what (I consider to be) \nthe two /strong/ sources of file information (HEAD and working file) \nto be synchronised, and the 'weak' cache updated then to match.\n\nI wasn't expecting the 'weak' cache of the index to prevent me \nsynchronising my 'strong' sources (HEAD and working file). I was \nexpecting the 'weak' cache to be updated to the 'strong' ones.\n\nIf I want to synchronise this 'weak' cache, I'll do so explicitely \n(though, there isn't a user-obvious distinction in commands for this, \nthere's no obvious \"git-commit-index\"). Maybe part of the problem \nhere is that git-commit tries to hide the index/working-tree/HEAD \ndistinction? I don't know.\n\nAnyway, if git-commit can lift \"Rule 2\" where file in working tree \nand index match, that'd be great - but I can easily live with \ngit-reset till then. ;)\n\nThanks for the informative email!\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nA violent man will die a violent death.\n \t\t-- Lao Tsu\n"},{"id":"17563","messageId":"44181DFE.7080204@op5.se","threadId":"3645","inReplyTo":"7vy7zcie5c.fsf@assigned-by-dhcp.cox.net","subject":"Re: seperate commits for objects already updated in index?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-15T14:00:30Z","receivedAt":"2006-03-15T14:00:30Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> The background behind this is around beginning of February 2006,\n> the thread \"Two ideas\" by Carl Worth. And the current behaviour\n> is defined by this commit. I'll talk about a possible\n> improvement but first, here is what it does:\n> \n> commit 130fcca63fe8e7e087e7419907e018cbbaf434a3\n> Author: Junio C Hamano \n> Date: Sun Feb 5 00:07:44 2006 -0800\n> \n> \n> 2. refuses to run if named paths... are different in HEAD and\n> the index (ditto about reminding). Added paths are OK.\n> \n> \n> The check that prevents you from doing\n> \n> \t$ edit A B\n> \t$ git update-index A B\n> $ git commit -o B\n> \n> is the rule #2, which I think could use further improvement. It\n> is to address the \"committing skewed files\" issue Carl brought\n> up in that thread.\n> \n> It might be better to further check if the working tree file is\n> the same as the index, and to allow a commit in such a case.\n> \n> The intent of rule #2 is to prevent this from happening:\n> \n> \t$ edit A B\n> $ git update-index A B\n> $ edit B again\n> $ git commit -o B\n> \n> When this happens, the real index will have _old_ contents of B\n> that never was committed, and does not match what is in the\n> index. But after the commit, we will match the real index to\n> what was committed, so we will _lose_ the index entry for B\n> before the second edit you explicitly told git to remember by\n> saying 'update-index'.\n> \n\nCan't this be done by updating .git/index first and then use the \ntemporary index to commit? Then .git/index would match the current tree \nand everybody would be happy with very little tweaking. Doing the \ntemporary index commit first could cause data-loss as described above if \nthe updating of .git/index somehow fails and the user is unaware of it \n(or what to do to fix it).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"17567","messageId":"7vlkvbik8f.fsf@assigned-by-dhcp.cox.net","threadId":"3645","inReplyTo":"44181DFE.7080204@op5.se","subject":"Re: seperate commits for objects already updated in index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-15T19:25:04Z","receivedAt":"2006-03-15T19:25:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Can't this be done by updating .git/index first and then use the\n> temporary index to commit? Then .git/index would match the current\n> tree and everybody would be happy with very little tweaking. Doing the\n> temporary index commit first could cause data-loss as described above\n> if the updating of .git/index somehow fails and the user is unaware of\n> it (or what to do to fix it).\n\nYou have to think about how to rewind it when the user decides\nlater not to commit by for example giving an empty commit\nmessage or killing the editor. The order of things need to be\nto populate the index to be committed so that we can give\npreview in the commit log template upon 'commit -v', spawn the\neditor and get the final version of log, and then make a\ncommit. So it may or may not be doable -- I haven't thought\nabout it through, and currently have not much incentive nor\ninclination to think about it myself right now.\n"},{"id":"17568","messageId":"44186E50.6090400@op5.se","threadId":"3645","inReplyTo":"7vlkvbik8f.fsf@assigned-by-dhcp.cox.net","subject":"Re: seperate commits for objects already updated in index?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-15T19:43:12Z","receivedAt":"2006-03-15T19:43:12Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson writes:\n> \n> \n>>Can't this be done by updating .git/index first and then use the\n>>temporary index to commit? Then .git/index would match the current\n>>tree and everybody would be happy with very little tweaking. Doing the\n>>temporary index commit first could cause data-loss as described above\n>>if the updating of .git/index somehow fails and the user is unaware of\n>>it (or what to do to fix it).\n> \n> \n> You have to think about how to rewind it when the user decides\n> later not to commit by for example giving an empty commit\n> message or killing the editor. The order of things need to be\n> to populate the index to be committed so that we can give\n> preview in the commit log template upon 'commit -v', spawn the\n> editor and get the final version of log, and then make a\n> commit. So it may or may not be doable -- I haven't thought\n> about it through, and currently have not much incentive nor\n> inclination to think about it myself right now.\n> \n\ncp .git/index .git/pre-commit-index\n\nand roll it back if the user aborts. Should work, but like you I don't \nneed that functionality, so...\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}