{"thread":{"id":"6046","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","startedAt":"2006-12-19T20:33:07Z","lastAt":"2006-12-24T21:38:17Z","messageCount":22,"participants":["Carl Worth","Peter Baumann","Junio C Hamano","Sean","Nicolas Pitre","Shawn Pearce","Jakub Narebski","Daniel Barkalow","Sean Kelley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297514","messageId":"89b129c60612191233s5a7f36f2hd409c4b9a2bbbc5c@mail.gmail.com","threadId":"6046","inReplyTo":null,"subject":"GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Sean Kelley","fromEmail":"sean.v.kelley@gmail.com","sentAt":"2006-12-19T20:33:07Z","receivedAt":"2006-12-19T20:33:07Z","isPatch":false,"sender":{"key":"sean.v.kelley@gmail.com","avatar":null},"body":"Hi,\n\nI was wondering if someone could help me.  I had a branch on our\nremote GIT server called TestBranch.  I logged into the Remote server\nand ran:\n\n<from remote server>\ngit branch -D TestBranch\n\nBut in my local clone:\n\nkelleys@oifig:~/Work/kernel$ git pull origin\nkelleys@git.example.com's password:\nerror: no such remote ref refs/heads/TestBranch\nFetch failure: git+ssh://git.example.com/data/git/proj/kernel/mh.git\nkelleys@oifig:~/Work/kernel$\n\nAny ideas how to correct this?\n\n"},{"id":"295129","messageId":"7v64c7pmlw.fsf@assigned-by-dhcp.cox.net","threadId":"6046","inReplyTo":"89b129c60612191233s5a7f36f2hd409c4b9a2bbbc5c@mail.gmail.com","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-19T22:06:03Z","receivedAt":"2006-12-19T22:06:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sean Kelley\" <sean.v.kelley@gmail.com> writes:\n\n> Hi,\n>\n> I was wondering if someone could help me.  I had a branch on our\n> remote GIT server called TestBranch.  I logged into the Remote server\n> and ran:\n>\n> <from remote server>\n> git branch -D TestBranch\n>\n> But in my local clone:\n>\n> kelleys@oifig:~/Work/kernel$ git pull origin\n> kelleys@git.example.com's password:\n> error: no such remote ref refs/heads/TestBranch\n> Fetch failure: git+ssh://git.example.com/data/git/proj/kernel/mh.git\n> kelleys@oifig:~/Work/kernel$\n>\n> Any ideas how to correct this?\n\nIf you know remote does not have it, then probably not fetching\nfrom it would be a good idea.\n\nLook at your local $GIT_DIR/remotes/origin (or [remote \"origin\"]\nsection in $GIT_DIR/config) and remove the refspec that tells\ngit to fetch it.\n\nIn $GIT_DIR/remotes/origin, you may want to remove a like like this:\n\n\tPull: refs/heads/TestBranch:<something>\n\nIf it is coming from $GIT_DIR/config, it would probably look\nlike:\n\n\t[remote \"origin\"]\n        \tfetch = refs/heads/TestBranch:<something>\n\nand you would want to remove the \"fetch = \" line.\n"},{"id":"295880","messageId":"87wt4m2o99.wl%cworth@cworth.org","threadId":"6046","inReplyTo":"7v64c7pmlw.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-20T22:31:14Z","receivedAt":"2006-12-20T22:31:14Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 19 Dec 2006 14:06:03 -0800, Junio C Hamano wrote:\n> \"Sean Kelley\" <sean.v.kelley@gmail.com> writes:\n> > error: no such remote ref refs/heads/TestBranch\n> > Fetch failure: git+ssh://git.example.com/data/git/proj/kernel/mh.git\n> > kelleys@oifig:~/Work/kernel$\n> >\n> > Any ideas how to correct this?\n>\n> If you know remote does not have it, then probably not fetching\n> from it would be a good idea.\n\nI think a common case is just wanting to track the upstream contents,\nwhether branches appear or disappear, and being able to do that\nwithout manually maintaining a local configuration file listing the\ncurrent remote branches.\n\nPresumably the recently added globbing support would provide that\nability, correct?\n\nIs there any plan to make git-clone take advantage of this capability\nso that one can track an upstream that has branches that get\nadded/remove without having to learn how to manually maintain the\ncurrent list of branches in .git/config ?\n\n-Carl\n"},{"id":"294254","messageId":"7vmz5i6vqb.fsf@assigned-by-dhcp.cox.net","threadId":"6046","inReplyTo":"87wt4m2o99.wl%cworth@cworth.org","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T22:36:12Z","receivedAt":"2006-12-20T22:36:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> Is there any plan to make git-clone take advantage of this capability\n> so that one can track an upstream that has branches that get\n> added/remove without having to learn how to manually maintain the\n> current list of branches in .git/config ?\n\nCould you check \"log master..next\" and see if you like what has\nbeen cooking, please?\n\nThe next batch of 'master' updates will have jc/clone topic (see\nthe latest issue of \"What's cooking\" message on the list) which\nwill include what has been cooking in 'next' around this area.\n"},{"id":"295335","messageId":"87vek62n1k.wl%cworth@cworth.org","threadId":"6046","inReplyTo":"7vmz5i6vqb.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-20T22:57:27Z","receivedAt":"2006-12-20T22:57:27Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 20 Dec 2006 14:36:12 -0800, Junio C Hamano wrote:\n> Carl Worth <cworth@cworth.org> writes:\n>\n> > Is there any plan to make git-clone take advantage of this capability\n> > so that one can track an upstream that has branches that get\n> > added/remove without having to learn how to manually maintain the\n> > current list of branches in .git/config ?\n>\n> Could you check \"log master..next\" and see if you like what has\n> been cooking, please?\n\nOh, yes, there it is. (I had skimmed the log for master..next but had\nmissed it---I guess that I also searched for \"glob\" instead of\n\"wildcard\" didn't help).\n\nAnyway, yes, the description of the new stuff there looks very\ninteresting, and I'll maybe I'll start running from next a bit to see\nhow this stuff all works.\n\nI guess the big reason I wrote was that I was surprised to see your\nreply instructing Sean on how to update the config file without also\nsaying something like, \"by the way, this need to update the config\nfile like this will be going away with new work on git-clone that is\nbeing done now and is expected to be in the upcoming git 1.5\".\n\nI thought that was the case, but didn't want to say it without\nconfirming it first. Thanks for confirming it for me.\n\n-Carl\n"},{"id":"298395","messageId":"7v1wmu5ecs.fsf@assigned-by-dhcp.cox.net","threadId":"6046","inReplyTo":"87vek62n1k.wl%cworth@cworth.org","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T23:36:51Z","receivedAt":"2006-12-20T23:36:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> Anyway, yes, the description of the new stuff there looks very\n> interesting, and I'll maybe I'll start running from next a bit to see\n> how this stuff all works.\n\nGood.\n\nDo you have comments on recent changes (both on 'master' and\nsome parts of 'next') from teachability point of view?  I think\nyou are \"the guilty guy\" who defined the theme for v1.5.0 to be\n\"usability and teachability\" ;-).\n"},{"id":"29901","messageId":"87tzzp3fgh.wl%cworth@cworth.org","threadId":"6046","inReplyTo":"7v1wmu5ecs.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-21T06:55:58Z","receivedAt":"2006-12-21T06:55:58Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 20 Dec 2006 15:36:51 -0800, Junio C Hamano wrote:\n> Do you have comments on recent changes (both on 'master' and\n> some parts of 'next') from teachability point of view?  I think\n> you are \"the guilty guy\" who defined the theme for v1.5.0 to be\n> \"usability and teachability\" ;-).\n\nI'm flattered to be blamed for what I consider a very good theme for\nthe release.\n\nI don't have a lot of detailed comments right now other than to repeat\na \"good job!\" to everyone who has done a lot to improve things lately,\n(coming up with more use-oriented documentation, adding a reasonable\nshorthand \"add\"[*] for update-index, cleaning up a lot of bad error\nmessage and needless spew, making much more reasonable default clone\nbehavior, etc. etc.). I think git's really come a long ways as far as\nusability and teachability, (while nothing fundamental has really\nchanged and old-time users should hardly notice anything different).\n\nI think I'll have a few minor tweaks to suggest to the documentation\nif I get a chance to take a detailed pass over it, (which I hope to do\nbefore the new year).\n\nAnd I'd definitely like to enable \"git checkout <revision>\" with a new\ncomplaint on git-commit before the 1.5 release. I'll see if I can't\nfind time to work on implementing that.\n\n-Carl\n\n[*] I'm still somewhat unsettled that the \"new\" add command conflates\nthe notions of adding content into the index for paths that previously\ndidn't exist in the index with the notion of updating the content in\nthe index for paths that did exist already. I think those notions are\ngenerally distinct from the users point of view---the first changes a\nfile's state in a fundamental way, (from \"untracked\" to \"tracked\"),\nwhile the second merely updates its content with no change to its\nstate.\n\nOne way to see the distinction is to imagine two different useful\noperations \"add all untracked file paths to the index\" and \"update\ncontent for all tracked paths\". If we had separate commands for 'add'\nand 'update' then it would be natural to express these two variants\nwith \"git add --all\" and \"git update --all\".\n\nAs things stand now, the first operation is available already with\n\"git add .\", (and oddly, with \"git add\", and I agree that should be\nremoved). Meanwhile the second operation is not currently available in\ngit, (but I recently proposed it as \"git add -a|--all\" in response to\na request). As pointed out in that thread, there's a bit of a problem\nin that \"git add --all\" is really easy to mistake for a command that\nwould add all untracked files to the index, (since it's when adding\nnew paths that people will most often use \"git add\" so it will\nnaturally be associated with adding new paths). It's less likely for\nusers to establish the \"update content\" notion of \"git add\" since it\noften won't be needed at all, (tutorials and the git-commit\ndocumentation recommend \"commit -a\" to avoid the need to use \"git add\"\nin its updating sense).\n\nSo, to summarize, I think it's good to have a much shorter command to\ntype than \"update-index\" for the update-content-of-path-in-index\noperation. So using \"add\" for this is better than \"update-index\"\nalready. And if that's how it stays, I can certainly live with it.\n\nBut I think it might be even better if the updating notion were on a\nseparate command name (update ? stage ?), and this in spite of the\nfact that fewer commands is generally better for learnability.\n\nIt's not a major issue---and it's nothing that I would make a big fuss\nover, so feel free to ignore it if it appears a non-issue to you.\n"},{"id":"29933","messageId":"slrneokplo.nsf.Peter.B.Baumann@xp.machine.xx","threadId":"6046","inReplyTo":"87tzzp3fgh.wl%cworth@cworth.org","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-12-21T10:49:28Z","receivedAt":"2006-12-21T10:49:28Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-12-21, Carl Worth <cworth@cworth.org> wrote:\n> --pgp-sign-Multipart_Wed_Dec_20_22:55:50_2006-1\n> Content-Type: text/plain; charset=US-ASCII\n>\n> On Wed, 20 Dec 2006 15:36:51 -0800, Junio C Hamano wrote:\n>> Do you have comments on recent changes (both on 'master' and\n>> some parts of 'next') from teachability point of view?  I think\n>> you are \"the guilty guy\" who defined the theme for v1.5.0 to be\n>> \"usability and teachability\" ;-).\n>\n> I'm flattered to be blamed for what I consider a very good theme for\n> the release.\n>\n> I don't have a lot of detailed comments right now other than to repeat\n> a \"good job!\" to everyone who has done a lot to improve things lately,\n> (coming up with more use-oriented documentation, adding a reasonable\n> shorthand \"add\"[*] for update-index, cleaning up a lot of bad error\n> message and needless spew, making much more reasonable default clone\n> behavior, etc. etc.). I think git's really come a long ways as far as\n> usability and teachability, (while nothing fundamental has really\n> changed and old-time users should hardly notice anything different).\n>\n> I think I'll have a few minor tweaks to suggest to the documentation\n> if I get a chance to take a detailed pass over it, (which I hope to do\n> before the new year).\n>\n> And I'd definitely like to enable \"git checkout <revision>\" with a new\n> complaint on git-commit before the 1.5 release. I'll see if I can't\n> find time to work on implementing that.\n>\n> -Carl\n>\n> [*] I'm still somewhat unsettled that the \"new\" add command conflates\n> the notions of adding content into the index for paths that previously\n> didn't exist in the index with the notion of updating the content in\n> the index for paths that did exist already. I think those notions are\n> generally distinct from the users point of view---the first changes a\n> file's state in a fundamental way, (from \"untracked\" to \"tracked\"),\n> while the second merely updates its content with no change to its\n> state.\n>\n> One way to see the distinction is to imagine two different useful\n> operations \"add all untracked file paths to the index\" and \"update\n> content for all tracked paths\". If we had separate commands for 'add'\n> and 'update' then it would be natural to express these two variants\n> with \"git add --all\" and \"git update --all\".\n>\n\nI'm also not so confident about mixing \"add NEW files\" with \"updating\nthe contents of already known files\". I'd prefere to seperate those two\nmeanings. Having two similarly named files in my workdir, I could easly\nmisspell the filename and wouldn't even notice that I have added a NEW\nfile inspite of refreshing the contents of an already existing file.\n\n> As things stand now, the first operation is available already with\n> \"git add .\", (and oddly, with \"git add\", and I agree that should be\n> removed). Meanwhile the second operation is not currently available in\n> git, (but I recently proposed it as \"git add -a|--all\" in response to\n> a request). As pointed out in that thread, there's a bit of a problem\n> in that \"git add --all\" is really easy to mistake for a command that\n> would add all untracked files to the index, (since it's when adding\n> new paths that people will most often use \"git add\" so it will\n> naturally be associated with adding new paths). It's less likely for\n> users to establish the \"update content\" notion of \"git add\" since it\n> often won't be needed at all, (tutorials and the git-commit\n> documentation recommend \"commit -a\" to avoid the need to use \"git add\"\n> in its updating sense).\n>\n> So, to summarize, I think it's good to have a much shorter command to\n> type than \"update-index\" for the update-content-of-path-in-index\n> operation. So using \"add\" for this is better than \"update-index\"\n> already. And if that's how it stays, I can certainly live with it.\n>\n> But I think it might be even better if the updating notion were on a\n> separate command name (update ? stage ?), and this in spite of the\n> fact that fewer commands is generally better for learnability.\n>\n\nWhat about 'refresh'?\n\n> It's not a major issue---and it's nothing that I would make a big fuss\n> over, so feel free to ignore it if it appears a non-issue to you.\n>\n> --pgp-sign-Multipart_Wed_Dec_20_22:55:50_2006-1\n> Content-Type: application/pgp-signature\n> Content-Transfer-Encoding: 7bit\n>\n>\n> --pgp-sign-Multipart_Wed_Dec_20_22:55:50_2006-1--\n"},{"id":"29988","messageId":"7vbqlw92fw.fsf@assigned-by-dhcp.cox.net","threadId":"6046","inReplyTo":"slrneokplo.nsf.Peter.B.Baumann@xp.machine.xx","subject":"Re: GIT - error: no such remote ref refs/heads/TestBranch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T00:52:51Z","receivedAt":"2006-12-22T00:52:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>\nwrites:\n\n> I'm also not so confident about mixing \"add NEW files\" with \"updating\n> the contents of already known files\".\n\nFile boundaries do not matter ;-)  You are adding contents.\nSometimes new contents are contained in a file that git already\nknew about.  Other times they are contained in a file that git\ndid not know about.\n\nBut that is a phylosophical answer, not a practical one, since\nmajority of the time (unless you are talking about the first few\nweeks of a new project) you will be adding contents that happen\nto be in the files git knows about.\n\nI think the operation related but different from \"git add .\"\nCarl talks about would be useful in practice.  I do not know\nwhat the option should be called.\n\n\t\"git add --modified\"?\n        \"git add --tracked\"?\n        \"git add --updated\"?\n\nIt would work in the same way as the pre-commit step of \"git\ncommit -a\".\n"},{"id":"30004","messageId":"87d56cirs8.wl%cworth@cworth.org","threadId":"6046","inReplyTo":"7vbqlw92fw.fsf@assigned-by-dhcp.cox.net","subject":"Separating \"add path to index\" from \"update content in index\"","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-22T02:32:55Z","receivedAt":"2006-12-22T02:32:55Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 21 Dec 2006 16:52:51 -0800, Junio C Hamano wrote:\n> Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> writes:\n> > I'm also not so confident about mixing \"add NEW files\" with \"updating\n> > the contents of already known files\".\n>\n> File boundaries do not matter ;-)  You are adding contents.\n\nI don't follow.\n\nThere's more than just content here. The index contains a list of\npaths as well, and a command like \"commit -a\" iterates over that\nlist. The addition or removal of a path from that list is a conceptual\nnotion that's very important to the user and the kinds of thing a user\ndoes on a regular basis.\n\n> But that is a phylosophical answer, not a practical one, since\n> majority of the time (unless you are talking about the first few\n> weeks of a new project) you will be adding contents that happen\n> to be in the files git knows about.\n\nI don't think it's practical to write off addition of new paths as\nunimportant or uncommon except in the beginning of projects. Projects\ngrow new functionality and files get added. Code gets refactored and\nfiles get renamed. The addition or removal of paths from the index is\njust as important an operation as changing content of existing paths.\n\nAnd I still think there are remaining interface problems that git has\nin this area. For example, my most common sequence of operations when\nhacking code is as follows:\n\n\t# edit files\n\tgit diff\t# to review what I've done\n\tgit commit -a\t# to record it\n\nRecently, I did some edits and also added some new files. I did:\n\n\t# edit files and make new ones\n\tgit diff\t# only edits appear here\n\nHmm... did I forget to add those new files?\n\n\tgit add new-file.c\n\tgit diff\t# still only shows the edits\n\nAt this point I can exercise my git mental muscles and know that \"add\"\nshoves stuff into the index so what I really want is:\n\n\tgit diff HEAD\t# shows edits and new file contents\n\nRegardless of how hard those git muscles may be to come by---I still\ndon't like having to exercise them here.\n\nI complained about this when I first encountered git, and back then I\nsaid what I thought I wanted was \"git diff HEAD\" by default. I was\ntotally wrong, since diff from the index is so obviously correct for\nresolving a conflict. Junio even responded to my complaints by\nproviding a new \"git status -v -a\" but frankly I've never used\nit. That's awful awkward to use when \"git diff\" is so easy to type and\n_most_ of the time is exactly what I want.\n\nI'd really like \"git diff\" to be what I want more often. So what I'd\nlike is to be able to get the index in such a state that typing \"git\ndiff\" like I always do would show me everything I just typed,\n(regardless of whether it was in files that git had seen before or\nnot).\n\nSo, I think what I really want here is a complete separation in the\ninterface between adding a path to the index and updating content into\nthe index.\n\nWe've long had a command that updates content to the index, and it\ntakes a command-line option (--add) to allow it to first do the\nnecessary path addition as well. The symmetry I would like is if we\nhad a command, (\"git add\", say), that just did the path addition and\ncould accept a command-line option (--update, say) to get it to the\nthe updating of the content as well.\n\nAnd I think that any talk about \"git cannot accept a file name without\ncontent\" is misplaced. The proposal here does not change any internal\nmodels of git. I'm talking about an interface issue, and if the\ninterface isn't helping the user then it's wrong. That \"git diff\"\nusually shows me what I've just typed but I can't (easily[*]) get it\nto do that when I'm adding a new file is really annoying.\n\n[*] Well, I could get it to do that by carefully creating the file,\nrunning \"git add\" immediately, and only _then_ going on to type\ncontent into the file. But that's not how I work. I do a bunch of file\nmanipulations without thinking about git at all, and then when I'm\nhappy with that, only then do I want to turn to git and use \"git add\",\n\"git diff\", and \"git commit\" to get the results I want.\n\nSo I suppose I could implement the \"add path without updating content\"\nI want by doing something like:\n\n\tmv file file.tmp\n\ttouch file\n\tgit update-index --add file\n\tmv file.tmp file\n\nThere. That gives me the result I want without breaking any git\ninternals, (since I'm just building a new operation on top of existing\ngit primitives).\n\n> Carl talks about would be useful in practice.  I do not know\n> what the option should be called.\n>\n> \t\"git add --modified\"?\n>         \"git add --tracked\"?\n>         \"git add --updated\"?\n>\n> It would work in the same way as the pre-commit step of \"git\n> commit -a\".\n\nI think the best would be:\n\n\tgit update-index --all\n\nwhich would still allow room for:\n\n\tgit add --all\n\nas a consistent way to get at the current behavior of \"git add .\".\n\nSo here I'm arguing against \"git add\" being a more convenient synonym\nfor \"git update-index\". I still think it would be nice to have a more\nconvenient synonym. I've proposed \"stage\" before but that wasn't well\naccepted. Just shortening \"update-index\" to \"update\" would be\nproblematic as many other RCSs use \"update\" as a way of picking up new\ncontent that has become available on the remote end. So, the best\nsuggestion I have at this point is \"refresh\". So I'd be happy if\neither:\n\n\tgit refresh --add\nor:\n\tgit add --refresh\n\nwould provide the behavior that currently is provided by \"git add\",\n(that is, add a new path to the index and update the content of that\npath in the index from the content of the named file in the working\ntree). But it would be great if \"git add\" without the --refresh would\nadd the path without updating the content.\n\n-Carl\n"},{"id":"30006","messageId":"20061221220632.46444296.seanlkml@sympatico.ca","threadId":"6046","inReplyTo":"87d56cirs8.wl%cworth@cworth.org","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-12-22T03:06:32Z","receivedAt":"2006-12-22T03:06:32Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 21 Dec 2006 18:32:55 -0800\nCarl Worth <cworth@cworth.org> wrote:\n\n> So here I'm arguing against \"git add\" being a more convenient synonym\n> for \"git update-index\". I still think it would be nice to have a more\n> convenient synonym. I've proposed \"stage\" before but that wasn't well\n> accepted. Just shortening \"update-index\" to \"update\" would be\n> problematic as many other RCSs use \"update\" as a way of picking up new\n> content that has become available on the remote end. So, the best\n> suggestion I have at this point is \"refresh\". So I'd be happy if\n> either:\n> \n> \tgit refresh --add\n> or:\n> \tgit add --refresh\n> \n> would provide the behavior that currently is provided by \"git add\",\n> (that is, add a new path to the index and update the content of that\n> path in the index from the content of the named file in the working\n> tree). But it would be great if \"git add\" without the --refresh would\n> add the path without updating the content.\n\n\nThe end result you're trying to achieve is worthwhile, but it seems the\nnew git add capabilities have already taken root.  What do you think\nabout accepting the new behavior of add, but offer a new command, say:\n\n$ git track-file <file>\n\nWhich would do exactly as you propose in your email, add the path to\nthe index with empty content?\n\nSean\n"},{"id":"30011","messageId":"Pine.LNX.4.64.0612212337180.18171@xanadu.home","threadId":"6046","inReplyTo":"87d56cirs8.wl%cworth@cworth.org","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-22T05:06:32Z","receivedAt":"2006-12-22T05:06:32Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 21 Dec 2006, Carl Worth wrote:\n\n> So, I think what I really want here is a complete separation in the\n> interface between adding a path to the index and updating content into\n> the index.\n\nStrangely enough I think this separation is unnecessary and redundent.\n\n> We've long had a command that updates content to the index, and it\n> takes a command-line option (--add) to allow it to first do the\n> necessary path addition as well.\n\nAnd it is still there.\n\n> The symmetry I would like is if we\n> had a command, (\"git add\", say), that just did the path addition and\n> could accept a command-line option (--update, say) to get it to the\n> the updating of the content as well.\n\nAnd you can do just that with git-update-index.\n\n> And I think that any talk about \"git cannot accept a file name without\n> content\" is misplaced. The proposal here does not change any internal\n> models of git. I'm talking about an interface issue, and if the\n> interface isn't helping the user then it's wrong. That \"git diff\"\n> usually shows me what I've just typed but I can't (easily[*]) get it\n> to do that when I'm adding a new file is really annoying.\n\nThe problem lies with the git-diff interface then, not git-add.\n\n> [*] Well, I could get it to do that by carefully creating the file,\n> running \"git add\" immediately, and only _then_ going on to type\n> content into the file. But that's not how I work. I do a bunch of file\n> manipulations without thinking about git at all, and then when I'm\n> happy with that, only then do I want to turn to git and use \"git add\",\n> \"git diff\", and \"git commit\" to get the results I want.\n> \n> So I suppose I could implement the \"add path without updating content\"\n> I want by doing something like:\n> \n> \tmv file file.tmp\n> \ttouch file\n> \tgit update-index --add file\n> \tmv file.tmp file\n> \n> There. That gives me the result I want without breaking any git\n> internals, (since I'm just building a new operation on top of existing\n> git primitives).\n> \n> > Carl talks about would be useful in practice.  I do not know\n> > what the option should be called.\n> >\n> > \t\"git add --modified\"?\n> >         \"git add --tracked\"?\n> >         \"git add --updated\"?\n> >\n> > It would work in the same way as the pre-commit step of \"git\n> > commit -a\".\n> \n> I think the best would be:\n> \n> \tgit update-index --all\n> \n> which would still allow room for:\n> \n> \tgit add --all\n> \n> as a consistent way to get at the current behavior of \"git add .\".\n\nThere is no consistency needed between git-add and git-update-index.  \nThe first is for users while the second is more suited for scripting \nyour own interface.\n\n> So here I'm arguing against \"git add\" being a more convenient synonym\n> for \"git update-index\". I still think it would be nice to have a more\n> convenient synonym. I've proposed \"stage\" before but that wasn't well\n> accepted. Just shortening \"update-index\" to \"update\" would be\n> problematic as many other RCSs use \"update\" as a way of picking up new\n> content that has become available on the remote end. So, the best\n> suggestion I have at this point is \"refresh\". So I'd be happy if\n> either:\n> \n> \tgit refresh --add\n> or:\n> \tgit add --refresh\n> \n> would provide the behavior that currently is provided by \"git add\",\n> (that is, add a new path to the index and update the content of that\n> path in the index from the content of the named file in the working\n> tree). But it would be great if \"git add\" without the --refresh would\n> add the path without updating the content.\n\nI think you are trying to solve the wrong problem, or at least solve a \nproblem the wrong way.  The problem is that git-diff doesn't give you \nthe output you expect because of the index interfering in your work \nflow.  And I understand that.\n\nBut the best solution is really for git-diff to have a mode where you \ncould display a diff between the work tree and the index, _or_ the index \nand HEAD, for each file listed in the index while giving priority to the \nformer.\n\nThis would let you see a diff of everything that would be committed, \nincluding new files, if you were to do commit -a.  Maybe -a/--all should \nbe used with git-diff for such a mode by symetry with git-commit -a. (OK \n-a is already taken but I doubt it is really used and it already has a \nlonger equivalent so changing it would not do real harm).\n\nWith this, for users acustomed to \"commit -a\", the natural and pretty \nconsistent way to see a diff for such a commit before actually \nperforming it would bi \"diff -a\".  Isn't it logical?\n\n\nNicolas\n"},{"id":"30012","messageId":"7vfyb87bxg.fsf@assigned-by-dhcp.cox.net","threadId":"6046","inReplyTo":"87d56cirs8.wl%cworth@cworth.org","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T05:10:51Z","receivedAt":"2006-12-22T05:10:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> I complained about this when I first encountered git, and back then I\n> said what I thought I wanted was \"git diff HEAD\" by default. I was\n> totally wrong, since diff from the index is so obviously correct for\n> resolving a conflict. Junio even responded to my complaints by\n> providing a new \"git status -v -a\" but frankly I've never used\n> it.\n\nI guess my responding to whatever you said was wasted effort,\nand if you do not like \"git add\" this time, I should not be\nsurprised.  That's kind of sad ;-).\n\nJokes aside.\n\nI do not remember who advocated for making \"git status\" the\npreview of \"git commit\" to happen.  Was that also you?  I wonder\nhow many people use this form:\n\n\tgit status -v path1 path2...\n\nBecause if even somebody who wanted to have \"commit preview\" in\n\"git status\" does not use it for that intended purpose, I think\nwe can reuse the good command name for something more useful,\nsuch as \"git explain\".\n\n> I'd really like \"git diff\" to be what I want more often.\n\nRunning diff with index is what I do almost all the time.  I\nthink \"more often\" is different from person to person, but if\n\"git diff\" says nothing on a file that I know I added (and you\ncannot argue you do not remember it was a new file here --- you\nknow you added it and that is why you are complaining about not\nseeing it), I'd be happy that I did not accidentally edited it\nto munge what I added -- because I add a file only when it is in\na presentable, good state, in a good enough shape to take a\nsnapshot (not necessarily good enough to commit, though).\n\nAnd it is not just limited to adding the contents of a path that\nhappened to be told git for the first time.  Adding the contents\nof a path that was known to git also happens only when it is in\na presentable good state.  So running \"git diff\" and not seeing\nwhat I added before is a GOOD THING.\n\n> So I suppose I could implement the \"add path without updating content\"\n> I want by doing something like:\n>\n> \tmv file file.tmp\n> \ttouch file\n> \tgit update-index --add file\n> \tmv file.tmp file\n>\n> There. That gives me the result I want without breaking any git\n> internals, (since I'm just building a new operation on top of existing\n> git primitives).\n\nSure, what you want is \"git add --no-add newfile\", and I can\nunderstand that mode of operation if you are always going to\ncommit with \"git commit -a\".  Maybe we can have a config\nvariable that makes \"commit -a\" and \"add --no-add\" the default\nfor these two commands, and we do not have to change anything\nelse.\n\nOne minor detail I wonder about is what mode bits would you give\nto that placeholder entry.\n\n> I think the best would be:\n>\n> \tgit update-index --all\n>\n> which would still allow room for:\n>\n> \tgit add --all\n\nWasn't it you who said \"all\" is ambiguous (all known to git vs\nall in this directory)?  \n"},{"id":"30013","messageId":"20061222052156.GA15548@spearce.org","threadId":"6046","inReplyTo":"7vfyb87bxg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-22T05:21:56Z","receivedAt":"2006-12-22T05:21:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> And it is not just limited to adding the contents of a path that\n> happened to be told git for the first time.  Adding the contents\n> of a path that was known to git also happens only when it is in\n> a presentable good state.  So running \"git diff\" and not seeing\n> what I added before is a GOOD THING.\n\nYes!\n\nSadly it has taken me 12 months of working with Git to get\ncomfortable enough with that concept.\n\nActually it clicked once I realized that 'update-index' was actually\ncreating the blobs in the ODB and not 'write-tree'.  Prior to that\n\"click\" going off in my grey matter I always felt that Git screwed\nup when I did:\n\n\t$ vi foo.c\n\t$ git update-index foo.c\n\t$ git diff\n\t# what the ? where are my changes?\n\nI now make quite heavy use of the index even when hacking on code,\nand not just during merges.  But I wasn't like that just 5 months\nago...\n\n-- \nShawn.\n"},{"id":"30024","messageId":"emg4j2$f8v$1@sea.gmane.org","threadId":"6046","inReplyTo":"7vfyb87bxg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-22T08:24:36Z","receivedAt":"2006-12-22T08:24:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> And it is not just limited to adding the contents of a path that\n> happened to be told git for the first time.  Adding the contents\n> of a path that was known to git also happens only when it is in\n> a presentable good state.  So running \"git diff\" and not seeing\n> what I added before is a GOOD THING.\n\nIf I remember correctly the idea behind \"intent to add\" was to show\nonly that file was added (e.g. the \"new file\" line from extended diff\nheader) in \"git diff\" when file was added and not modified\n(and no changes to \"git diff HEAD\").\n\nAlthough I'm not sure if this wouldn't screw some use cases which\ninclude something like \"git diff > some-temporary-file\"...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30067","messageId":"87bqlvj44w.wl%cworth@cworth.org","threadId":"6046","inReplyTo":"7vfyb87bxg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-22T16:18:23Z","receivedAt":"2006-12-22T16:18:23Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"At Thu, 21 Dec 2006 21:10:51 -0800, Junio C Hamano wrote:\n> I guess my responding to whatever you said was wasted effort,\n> and if you do not like \"git add\" this time, I should not be\n> surprised.  That's kind of sad ;-).\n\nI hope I'm not coming across as always just complaining. I do think\nthe new \"git add\" thing is an improvement. So if nothing else changes,\nI still think git's better than it was before this recent round of\nimprovements.\n\n> I do not remember who advocated for making \"git status\" the\n> preview of \"git commit\" to happen.  Was that also you?  I wonder\n> how many people use this form:\n>\n> \tgit status -v path1 path2...\n\nI was involved in the discussions that led to \"status -v\", yes. As a\nnew user I was surprised that \"git diff\" didn't give a commit preview\nand you replied with the \"status -v\" idea. As things have turned out,\nI've never used \"status -v\".\n\n> Sure, what you want is \"git add --no-add newfile\", and I can\n> understand that mode of operation if you are always going to\n> commit with \"git commit -a\".  Maybe we can have a config\n> variable that makes \"commit -a\" and \"add --no-add\" the default\n> for these two commands, and we do not have to change anything\n> else.\n\nYes, you could add the \"don't update content\" as an option to git-add,\nand then all that would be left would be a discussion about which\nmodes get the default and which require configuration options, (and\nthose discussions generally don't go anywhere).\n\nBut don't you see how odd the command \"git add --no-add\" looks? What\ndoes it mean to add something without adding it? This is just\nreinforcing my position that using \"add\" to mean \"update content\"\nrather muddles things.\n\n> One minor detail I wonder about is what mode bits would you give\n> to that placeholder entry.\n\nYou could certainly grab them from the named file if it exists. If the\nuser is going to \"commit -a\" it won't matter much, right?\n\n> > I think the best would be:\n> >\n> > \tgit update-index --all\n> >\n> > which would still allow room for:\n> >\n> > \tgit add --all\n>\n> Wasn't it you who said \"all\" is ambiguous (all known to git vs\n> all in this directory)?\n\nYes. Having \"--all\" is ambiguous while \"git add\" is used for both\nadding new paths to the index _and_ updating index content. But if\n\"git add\" were restricted to just adding paths to the index as I am\nsuggesting, then there's no ambiguity at all.\n\n-Carl\n"},{"id":"30068","messageId":"87ac1fj2fn.wl%cworth@cworth.org","threadId":"6046","inReplyTo":"7vfyb87bxg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-22T16:55:08Z","receivedAt":"2006-12-22T16:55:08Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 21 Dec 2006 21:10:51 -0800, Junio C Hamano wrote:\n> Running diff with index is what I do almost all the time.\n\nYes, me too. As I said, months ago I had complained about \"git diff\"\nmeaning diff from index. But I was wrong. It really is the right thing\n\n> And it is not just limited to adding the contents of a path that\n> happened to be told git for the first time.  Adding the contents\n> of a path that was known to git also happens only when it is in\n> a presentable good state.  So running \"git diff\" and not seeing\n> what I added before is a GOOD THING.\n\nYes. Whenever consciously using the index, being able to stash stuff\nthere and not see it in \"git diff\" is definitely a good thing.\n\nAfter a thread not so long ago, someone told me privately that they\nreally wished they could see more examples of when using the index is\nobviously a net win to the user. He mentioned that the oft-cited\n\"split commit along file boundaries\" isn't compelling since the same\nbehavior can be achieved with \"commit file1 file2\".\n\nSo here's another example that I was using just yesterday:\n\n    I implemented an optimization and started testing it. It had the\n    performance characteristics I wanted, but also introduced a couple\n    few regressions noticed by the test suite.\n\n    So this code wasn't ready to commit, but I stashed it all into the\n    index. Then I went through an iterative process of fixing the\n    little regressions (off-by-one bugs, etc.), using \"git diff\" to\n    see _only_ the incremental fix, and then stashing the whole result\n    into the index again.\n\n    Then I only committed once all the regressions were fixed.\n\nNote that in the above scenario, the command I've been proposing\nrecently, (\"update the index with the content of all tracked files\"),\nwould have been quite useful.\n\nAlso note that with \"git commit --amend\" one could get a very similar\nresult by simply using the HEAD commit as the staging area instead of\nthe index. (And with reflogs, some might like that even better.)\n\nSo yes, \"git diff\" showing the difference from the index is definitely\nthe right thing. And it's useful whenever I'm consciously using the\nindex to stash some content, (as in this example), or when git does\nthat on my behalf (as in a conflicted merge).\n\nMy point is that I'm not always interested in stashing content just\nbecause I want to add a new path to the index. For example, let's say\nI sit down with my working tree and I just want to remember what I had\nbeen in the middle of doing. I examine the state of things with \"git\ndiff\". It doesn't show me the content of any newly-created files, but\nI want to see those as well. So I'd love to be able to easily get the\nindex into a state where \"git diff\" shows me that content.\n\nAnd I'm definitely not ready to stash the content of these new\nfiles---I haven't even looked at them yet---that's what I'd like \"git\ndiff\" to help me do at this point.\n\nAnyway, you already said you did understand this mode of operation. So\nI won't explain it over and over anymore. I really just wanted to\nthrow out that index-staging example for people.\n\n-Carl\n"},{"id":"30071","messageId":"Pine.LNX.4.64.0612221227420.18171@xanadu.home","threadId":"6046","inReplyTo":"87bqlvj44w.wl%cworth@cworth.org","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-22T17:28:46Z","receivedAt":"2006-12-22T17:28:46Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 22 Dec 2006, Carl Worth wrote:\n\n> I was involved in the discussions that led to \"status -v\", yes. As a\n> new user I was surprised that \"git diff\" didn't give a commit preview\n> and you replied with the \"status -v\" idea. As things have turned out,\n> I've never used \"status -v\".\n\nWhat about my diff -a proposal?  Did you miss it?\n\n\nNicolas\n"},{"id":"30112","messageId":"878xgziog0.wl%cworth@cworth.org","threadId":"6046","inReplyTo":"Pine.LNX.4.64.0612212337180.18171@xanadu.home","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-22T21:57:19Z","receivedAt":"2006-12-22T21:57:19Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:\n> On Thu, 21 Dec 2006, Carl Worth wrote:\n>\n> > So, I think what I really want here is a complete separation in the\n> > interface between adding a path to the index and updating content into\n> > the index.\n>\n> Strangely enough I think this separation is unnecessary and redundent.\n\nOne argument I would make in favor of the separation is that the two\noperations are conceptually distinct from the user point-of-view. But\nthat's really hard to nail down since all users have different points\nof view and different conceptual models, (though I think the recent\npost about similar file names and accidentally adding a file meant to\nbe untracked is evidence in favor of this argument).\n\nThere's a much less fuzzy, and strictly technical argument that can be\nmade. Right now, we document \"git add\" as being useful for two\npurposes, (\"adding new files\" and adding \"modified files...to the set\nof changes\"). These two operations can be described as:\n\n\t1. Add new path to the index, and update the content\n\n\t2. Update the content for an existing path\n\nThe technical argument for separating the notions of \"add path\" and\n\"update content\" comes from looking at how to specify path names to\nthese operations, (and recursive names in particular).\n\nBy definition, the first operation, (\"add new paths\"), must accept\npath names from the working tree as it exists in the filesystem.\nSince without this operation there's no way to get paths into the\nindex in the first place. So, any recursive operation for this\noperation should traverse the tree of files as they exist in the file\nsystem. This is quite useful in the case of creating a new directory\nin a project and wanting to add all of the files in that directory:\n\n\tgit add new-directory\n\nHowever, the second operation (\"update content\") need not be defined\nin terms of the tree in the filesystem, and is in fact quite useful\nwhen it operates on the tree that exists \"within\" git. For example, if\nI have been hacking on a feature change in a 'source' directory that's\nnot quite finished yet, and also a new test for that feature in a\n'test' directory, (that I do consider ready), then it would be\nconvenient to be able to stage all the content in that directory be\nsimilarly specifying just the directory name. For example, I'd like to\nbe able to do:\n\n\tgit update-index test\n\n(which doesn't actually work right now). But doing \"git add test\"\nwould be wrong, since it would also add any untracked files, and I\ndon't want that. This \"update content for known files\" operation\nshould recurse on the tree that git knows about, and not the tree of\nfiles in my filesystem.\n\n> > We've long had a command that updates content to the index, and it\n> > takes a command-line option (--add) to allow it to first do the\n> > necessary path addition as well.\n>\n> And it is still there.\n\nYes, update-index still exists. But we're relegating that to\nplumbing. What I'm proposing is that we should have a porcelain\ncommand that just does the \"update content for known files part\" and\nthat merging this with something that makes files \"become known\" to\ngit for the first time is a mistake.\n\n> The problem lies with the git-diff interface then, not git-add.\n\nI don't think so. I'm quite convinced that the fact that \"git diff\"\nshows the difference from the index to the working tree is correct and\ncan't really be changed. The issue I'm talking about here is that for\n\"tracked\" files git currently provides a way for me to have my edits\nof I can\n\n> > I think the best would be:\n> >\n> > \tgit update-index --all\n> >\n> > which would still allow room for:\n> >\n> > \tgit add --all\n...\n> There is no consistency needed between git-add and git-update-index.\n> The first is for users while the second is more suited for scripting\n> your own interface.\n\nBut it's not actually update-index that I want. I agree that it's a\nplumbing thing that users shouldn't use. What I want is two different\npieces of porcelain here, each focusing one one simple task. One to\nadd the path to the index, and one to update content in the index for\na path that exists.\n\n> > \tgit refresh --add\n> > or:\n> > \tgit add --refresh\n> >\n> > would provide the behavior that currently is provided by \"git add\",\n\nThat was actually a bad idea, and I'll retract that part. Neither of\nthese options should exist. We already have an all-singing,\nall-dancing git-update-index that can do anything we want. We really\ndon't need two new pieces of porcelain that also do everything\nupdate-index does but just have different defaults.\n\nMuch better would be for \"git add\" and \"git refresh\" to each just\nstick to a single task and to do it well, (git has UNIX philosophy,\nright?). So \"git add\" should just add paths to the index, \"git\nrefresh\" should just update content for existing paths in the index,\nand we don't need a lot of options for either command for users to\nhave to wade through.\n\nWith those simple commands, we could have nice, separate behavior for:\n\n\tgit add some-dir\nand:\n\tgit refresh some-dir\n\nand if someone wants the existing \"add path and update content\"\nbehavior of git add then it should be a simple matter of aliasing to\nthe combination of \"git add\" followed by \"git refresh\".\n\n> I think you are trying to solve the wrong problem, or at least solve a\n> problem the wrong way.  The problem is that git-diff doesn't give you\n> the output you expect because of the index interfering in your work\n> flow.  And I understand that.\n\nI don't think that's the right characterization. I like that \"git\ndiff\" works from the index, and I take advantage of that by\nintentionally putting content into the index. The problem is that \"git\nadd\" currently forces content into the index even if I consciously do\nnot want it there yet. I just want a way to tell \"git diff\", (and\ncommit -a), to start looking at new files, but without staging the\ncurrent content of those files into the index.\n\n> But the best solution is really for git-diff to have a mode where you\n> could display a diff between the work tree and the index, _or_ the index\n> and HEAD, for each file listed in the index while giving priority to the\n> former.\n\nI don't understand what you are proposing here. What would this mode\ndisplay? How would it decide?\n\n> With this, for users acustomed to \"commit -a\", the natural and pretty\n> consistent way to see a diff for such a commit before actually\n> performing it would bi \"diff -a\".  Isn't it logical?\n\nA new option (\"git diff -a\") doesn't help much. There's already \"git\ndiff HEAD\" and I understand what it does. The problem is having \"git\ndiff\" usually work, and then having to remember to do something else\nwhen it doesn't do the right thing.\n\n[Though a command-line option would have one advantage over HEAD which\n is that it's easier to document command-line options than a magic\n name like HEAD. This \"hard to document\" bug is something that affects\n all of the magic names, (HEAD, ORIG_HEAD, MERGE_HEAD, etc.), and\n keeps their functionality quite hidden from new users of git.]\n\n-Carl\n"},{"id":"30136","messageId":"Pine.LNX.4.64.0612222141470.20138@iabervon.org","threadId":"6046","inReplyTo":"7vfyb87bxg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-12-23T02:56:23Z","receivedAt":"2006-12-23T02:56:23Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 21 Dec 2006, Junio C Hamano wrote:\n\n> Sure, what you want is \"git add --no-add newfile\", and I can\n> understand that mode of operation if you are always going to\n> commit with \"git commit -a\".  Maybe we can have a config\n> variable that makes \"commit -a\" and \"add --no-add\" the default\n> for these two commands, and we do not have to change anything\n> else.\n\nI think there's value to a command to add an empty space with a given name \nto the staging area. If you commit without -a, I don't see any reason to \nthink that you couldn't want the sequence \"add-empty-space <new-file>\", \n\"modify <old-file>\", \"update-index <old-file>\", \"commit\", \"update-index \n<new-file>\", \"commit\". It can be useful to make sure the file isn't going \nto be forgotten, but also not get it into the next commit.\n\n> One minor detail I wonder about is what mode bits would you give\n> to that placeholder entry.\n\nI looked into this at one point. It should probably use 000000 for the \nmode, because it shouldn't read the working directory at all (you might \nactually want to add the space before creating a file at all, for \ninstance, and then make a symlink when you provide anything, surprising \nany reasonable guess at a mode). Also, this is going to show up in the \ndiff listing, and all-zero SHA1 with a mode is used there for \"read the \nworking directory\".\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"30150","messageId":"Pine.LNX.4.64.0612221709380.18171@xanadu.home","threadId":"6046","inReplyTo":"878xgziog0.wl%cworth@cworth.org","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-23T05:27:16Z","receivedAt":"2006-12-23T05:27:16Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 22 Dec 2006, Carl Worth wrote:\n\n> On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:\n> > On Thu, 21 Dec 2006, Carl Worth wrote:\n> >\n> > > So, I think what I really want here is a complete separation in the\n> > > interface between adding a path to the index and updating content into\n> > > the index.\n> >\n> > Strangely enough I think this separation is unnecessary and redundent.\n> \n> One argument I would make in favor of the separation is that the two\n> operations are conceptually distinct from the user point-of-view. But\n> that's really hard to nail down since all users have different points\n> of view and different conceptual models,\n\n... and if we want to break the CVS model and give people a better \nchance of ever grasping the git index concept I think they should not be \ndifferent.\n\n> (though I think the recent\n> post about similar file names and accidentally adding a file meant to\n> be untracked is evidence in favor of this argument).\n\nThis could be used as evidence for anything.  \"Oh I wanted to delete \nthis file but that file had a similar name and I deleted the wrong \none.\"\n\n> There's a much less fuzzy, and strictly technical argument that can be\n> made. Right now, we document \"git add\" as being useful for two\n> purposes, (\"adding new files\" and adding \"modified files...to the set\n> of changes\").\n[...]\n> The technical argument for separating the notions of \"add path\" and\n> \"update content\" comes from looking at how to specify path names to\n> these operations, (and recursive names in particular).\n\nSometimes pure _technical_ arguments don't make good _user_ interfaces. \nThe \"git add\" changes are about _usability_, not _technicality_. It is \nmuch easier to learn about one concept which is \"you add stuff to your \ncommit\" with no other distinction to make.\n\n> Yes, update-index still exists. But we're relegating that to\n> plumbing.\n\nBut plumbing is there for you to use with your own enhancements when \nthey are sophisticated enough like your workflow description seem to \nimply.\n\n> > The problem lies with the git-diff interface then, not git-add.\n> \n> I don't think so. I'm quite convinced that the fact that \"git diff\"\n> shows the difference from the index to the working tree is correct and\n> can't really be changed.\n\nI'm not proposing to change existing output either.\n\n> > There is no consistency needed between git-add and git-update-index.\n> > The first is for users while the second is more suited for scripting\n> > your own interface.\n> \n> But it's not actually update-index that I want. I agree that it's a\n> plumbing thing that users shouldn't use. What I want is two different\n> pieces of porcelain here, each focusing one one simple task. One to\n> add the path to the index, and one to update content in the index for\n> a path that exists.\n> \n> Much better would be for \"git add\" and \"git refresh\" to each just\n> stick to a single task and to do it well, (git has UNIX philosophy,\n> right?). So \"git add\" should just add paths to the index, \"git\n> refresh\" should just update content for existing paths in the index,\n> and we don't need a lot of options for either command for users to\n> have to wade through.\n\nI'm still unconvinced this is useful distinction to make in the majority \nof all cases for the majority of people.\n\n> With those simple commands, we could have nice, separate behavior for:\n> \n> \tgit add some-dir\n> and:\n> \tgit refresh some-dir\n> \n> and if someone wants the existing \"add path and update content\"\n> behavior of git add then it should be a simple matter of aliasing to\n> the combination of \"git add\" followed by \"git refresh\".\n\nI think that if you want that behavior it might be a better idea for you \nto alias those behaviors with a combination of git-ls-files and \ngit-update-index.\n\n> > But the best solution is really for git-diff to have a mode where you\n> > could display a diff between the work tree and the index, _or_ the index\n> > and HEAD, for each file listed in the index while giving priority to the\n> > former.\n> \n> I don't understand what you are proposing here. What would this mode\n> display? How would it decide?\n\nThis is something that you might not need after all.  but for people \nusing git-commit -a they might benefit from a git-diff -a that would \noutput the equivalent of what will be committed, including newly added \nfiles (already in the index) and modified files (not yet in the index).  \nIt is easy to do: for each index entry, generate a diff against the \ncorresponding file in the work tree, but if there is no difference then \ngenerate the diff against HEAD.  Modified files will be in the first \ncase while added files will be in the second case.\n\n\nNicolas\n"},{"id":"30257","messageId":"Pine.LNX.4.64.0612241602060.20138@iabervon.org","threadId":"6046","inReplyTo":"Pine.LNX.4.64.0612221709380.18171@xanadu.home","subject":"Re: Separating \"add path to index\" from \"update content in index\"","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-12-24T21:38:17Z","receivedAt":"2006-12-24T21:38:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 23 Dec 2006, Nicolas Pitre wrote:\n\n> On Fri, 22 Dec 2006, Carl Worth wrote:\n> \n> > On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:\n> > > On Thu, 21 Dec 2006, Carl Worth wrote:\n> > >\n> > > > So, I think what I really want here is a complete separation in the\n> > > > interface between adding a path to the index and updating content into\n> > > > the index.\n> > >\n> > > Strangely enough I think this separation is unnecessary and redundent.\n> > \n> > One argument I would make in favor of the separation is that the two\n> > operations are conceptually distinct from the user point-of-view. But\n> > that's really hard to nail down since all users have different points\n> > of view and different conceptual models,\n> \n> ... and if we want to break the CVS model and give people a better \n> chance of ever grasping the git index concept I think they should not be \n> different.\n\nI don't think the misunderstanding (if there is one) of the git index \nmodel is due to CVS. If I'm using a staging area for wrapping Christmas \npresents, I may assign space to items I haven't got yet: this is where I \nput the tape so I can reach it, this is where the roll of wrapping paper \ngoes, here is where the wrapping paper will be spread out, but I can't \nspread out the wrapping paper until I have the present (it just rolls back \nup), so there's nothing in the spot allocated to actual wrapping. Git \nreminds me of people who have to put a trash can in their parking spaces \nwhen their cars aren't there to keep them from being deallocated simply \nbecause they're empty.\n\nThe allocation of empty space before anything is put in it is a \nfundamental operation available in the general concept of a staging \narea. Someone coming from an index-based version-control system that \ndoesn't lack this feature would expect to have a possible status:\n\n# Changed but not updated:\n#   (use git-update-index to mark for commit)\n#\n#       new file: new-test-file\n#\n\n(And note that it can't be CVS-damage, because \"Changed but not updated\" \nisn't supported by CVS. This is a way in which git sort of has CVS-damage, \nbecause the \"new file\" operation goes straight to \"Updated but not checked \nin\", unlike everything else.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}