{"thread":{"id":"1870","subject":"GIT - breaking backward compatibility","startedAt":"2005-09-20T02:07:28Z","lastAt":"2005-09-23T06:02:59Z","messageCount":12,"participants":["Junio C Hamano","Brian Gerst","Linus Torvalds","Sven Verdoolaege","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8946","messageId":"7vpsr4cx0f.fsf@assigned-by-dhcp.cox.net","threadId":"1870","inReplyTo":null,"subject":"GIT - breaking backward compatibility","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-20T02:07:28Z","receivedAt":"2005-09-20T02:07:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I raised the following issues in my previous messages but did\nnot hear many opinions [*1*].  I do not want to take it as a\nblank check from the community to do whatever I please.  So here\nis a recap.\n\n * Tools renaming plan calls for removal of the backward\n   compatible command names (e.g. git-fsck-cache and\n   git-update-cache) sometime in the future.  This is scheduled\n   for 0.99.8 around beginning of October.  If somebody wants\n   extended amnesty period, this can be pushed back but unless I\n   hear otherwise...\n\n * After reviewing the current set of commands, the following do\n   not seem to be useful anymore; Linus said he feels they can\n   go, and nobody else objected:\n\n   git-diff-helper git-diff-stages git-export git-rev-tree\n\n   I'd like to remove them before 1.0, and planning to do it\n   within the 0.99.8 timeframe unless I hear otherwise.\n\n * After Brian Gerst posted a patch to show 'modified' files in\n   ls-files [*2*], there was a brief discussion to change the\n   tagged output markings to make them more readable, but\n   neither Cogito nor StGIT seems to use tagged output.  I am\n   currently thinking about removing '-t' altogether.\n\n   Again, unless I hear otherwise, I'd like to remove it within\n   the 0.99.8 timeframe.\n\n\nBTW, independent from any of these I'll be doing a 0.99.7a\nsoonish for \"fixes only\" on top of 0.99.7.\n\n\n[Footnote]\n\n*1* Well, Pasky indicated he does not like some of the terms in\nthe glossary in his recent Cogito release announcement, but that\nwas unfortunately after the fact.\n\n*2* I haven't taken this patch not because I do not think\nshowing 'modified' file is a bad idea but because showing cache\ndirty files as 'modified' did not feel right to me.  I think\ndoing what 'git-update-index --refresh' does without actually\nrefreshing the cache status bits would be the right way to go.\n"},{"id":"8962","messageId":"432F8C33.5080603@didntduck.org","threadId":"1870","inReplyTo":"7vpsr4cx0f.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT - breaking backward compatibility","fromName":"Brian Gerst","fromEmail":"bgerst@didntduck.org","sentAt":"2005-09-20T04:12:35Z","receivedAt":"2005-09-20T04:12:35Z","isPatch":false,"sender":{"key":"bgerst@didntduck.org","avatar":null},"body":"Junio C Hamano wrote:\n> I raised the following issues in my previous messages but did\n> not hear many opinions [*1*].  I do not want to take it as a\n> blank check from the community to do whatever I please.  So here\n> is a recap.\n> \n>  * Tools renaming plan calls for removal of the backward\n>    compatible command names (e.g. git-fsck-cache and\n>    git-update-cache) sometime in the future.  This is scheduled\n>    for 0.99.8 around beginning of October.  If somebody wants\n>    extended amnesty period, this can be pushed back but unless I\n>    hear otherwise...\n> \n>  * After reviewing the current set of commands, the following do\n>    not seem to be useful anymore; Linus said he feels they can\n>    go, and nobody else objected:\n> \n>    git-diff-helper git-diff-stages git-export git-rev-tree\n> \n>    I'd like to remove them before 1.0, and planning to do it\n>    within the 0.99.8 timeframe unless I hear otherwise.\n> \n>  * After Brian Gerst posted a patch to show 'modified' files in\n>    ls-files [*2*], there was a brief discussion to change the\n>    tagged output markings to make them more readable, but\n>    neither Cogito nor StGIT seems to use tagged output.  I am\n>    currently thinking about removing '-t' altogether.\n> \n>    Again, unless I hear otherwise, I'd like to remove it within\n>    the 0.99.8 timeframe.\n> \n> \n> BTW, independent from any of these I'll be doing a 0.99.7a\n> soonish for \"fixes only\" on top of 0.99.7.\n> \n> \n> [Footnote]\n> \n> *1* Well, Pasky indicated he does not like some of the terms in\n> the glossary in his recent Cogito release announcement, but that\n> was unfortunately after the fact.\n> \n> *2* I haven't taken this patch not because I do not think\n> showing 'modified' file is a bad idea but because showing cache\n> dirty files as 'modified' did not feel right to me.  I think\n> doing what 'git-update-index --refresh' does without actually\n> refreshing the cache status bits would be the right way to go.\n\nEssentially what I want to do is:\n\ngit-ls-files --others | xargs git-update-index --add --\ngit-ls-files --deleted | xargs git-update-index --remove --\ngit-ls-files --modified | xargs git-update-index --\n\nThis will completely resync the index and cache to the working tree \nstate after applying a patch.  git-update-index --refresh only updates \nthe stat info in the index.  It does _not_ write a new cache object if \nthe file contents have actually changed.\n\nCogito would benefit from this too.  It currently uses git-diff-index \nand some ugly sed expressions in cg-commit to detect modified files.\n\nIf your objection is to calling the files modifed, then call it dirty or \nsomething else.\n\n--\n\t\t\t\tBrian Gerst\n"},{"id":"8965","messageId":"Pine.LNX.4.58.0509192131260.2553@g5.osdl.org","threadId":"1870","inReplyTo":"432F8C33.5080603@didntduck.org","subject":"Re: GIT - breaking backward compatibility","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-20T04:33:15Z","receivedAt":"2005-09-20T04:33:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Sep 2005, Brian Gerst wrote:\n> \n> Essentially what I want to do is:\n> \n> git-ls-files --others | xargs git-update-index --add --\n> git-ls-files --deleted | xargs git-update-index --remove --\n> git-ls-files --modified | xargs git-update-index --\n> \n> This will completely resync the index and cache to the working tree \n> state after applying a patch.\n\nIt will also be extremely inefficient.\n\nIf you really have a _patch_, then \"git-apply --index\" is what you want to \napply it with. It applies a patch _and_ updates the index as appropriate. \nIt's how git-applymbox can apply hundreds of patches in short order.\n\n\t\tLinus\n"},{"id":"8967","messageId":"432F92FC.4000405@didntduck.org","threadId":"1870","inReplyTo":"Pine.LNX.4.58.0509192131260.2553@g5.osdl.org","subject":"Re: GIT - breaking backward compatibility","fromName":"Brian Gerst","fromEmail":"bgerst@didntduck.org","sentAt":"2005-09-20T04:41:32Z","receivedAt":"2005-09-20T04:41:32Z","isPatch":false,"sender":{"key":"bgerst@didntduck.org","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Tue, 20 Sep 2005, Brian Gerst wrote:\n> \n>>Essentially what I want to do is:\n>>\n>>git-ls-files --others | xargs git-update-index --add --\n>>git-ls-files --deleted | xargs git-update-index --remove --\n>>git-ls-files --modified | xargs git-update-index --\n>>\n>>This will completely resync the index and cache to the working tree \n>>state after applying a patch.\n> \n> \n> It will also be extremely inefficient.\n> \n> If you really have a _patch_, then \"git-apply --index\" is what you want to \n> apply it with. It applies a patch _and_ updates the index as appropriate. \n> It's how git-applymbox can apply hundreds of patches in short order.\n> \n> \t\tLinus\n> \n\nThat would be great, if git-apply accepted fuzzy patches.  I am trying \nto apply the -mm series patches, which often are slightly out of date. \nAndrew doesn't rebase them until they won't apply at all.\n\n--\n\t\t\t\tBrian Gerst\n"},{"id":"8969","messageId":"Pine.LNX.4.58.0509192156310.2553@g5.osdl.org","threadId":"1870","inReplyTo":"432F92FC.4000405@didntduck.org","subject":"Re: GIT - breaking backward compatibility","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-20T05:03:00Z","receivedAt":"2005-09-20T05:03:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Sep 2005, Brian Gerst wrote:\n> \n> That would be great, if git-apply accepted fuzzy patches.  I am trying \n> to apply the -mm series patches, which often are slightly out of date. \n> Andrew doesn't rebase them until they won't apply at all.\n\nPatches welcome..\n\nActually, fuzzy patches themselves are pretty easy to do (yeah, the\n\"memcmp\" needs to become something smarter - not a huge deal), but one big\nissue is what the \"priority\" should be.\n\nShould we prefer an exact match that is a hundred lines away from the line \nindicated, over a fuzzy patch that is right where we indicated? What if \nit's 50 lines and 10 lines? What if there's one that applies with fuzz 1 \nthat is further away from one that applies with fuzz 2? \n\nPersonally I don't much like fuzzy patches. I think it's perfectly valid \nto say \"try exact patch by default, and do that really fast\", and then \nfall back on something slower for the fuzzy case.\n\nIn other words: I'd suggest you use git-apply --index by default. It fails\nvery gracefully: if will apply _all_ of a patch, or it won't apply\nanything at all (that means that if the last of a hundred files will \nfail, git-apply will not have modified any of the first 99 either).\n\nIn other words, git-apply has _none_ of that traditional \"patch\" crap\nbehaviour. It does patch application _right_.\n\nOf course it does. I wrote it.\n\n\t\tLinus\n"},{"id":"8974","messageId":"7vu0gg8dmv.fsf@assigned-by-dhcp.cox.net","threadId":"1870","inReplyTo":"432F8C33.5080603@didntduck.org","subject":"Re: GIT - breaking backward compatibility","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-20T06:19:36Z","receivedAt":"2005-09-20T06:19:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gerst <bgerst@didntduck.org> writes:\n\n> Junio C Hamano wrote:\n\n[Long quotation snipped]\n\nBrian, you did not have to quote the whole thing if you wanted\nto respond to only one bullet point in my footnotes.\n\n> Essentially what I want to do is:\n>\n> git-ls-files --others | xargs git-update-index --add --\n> git-ls-files --deleted | xargs git-update-index --remove --\n> git-ls-files --modified | xargs git-update-index --\n>\n> This will completely resync the index and cache to the working tree \n> state after applying a patch.  git-update-index --refresh only updates \n> the stat info in the index.  It does _not_ write a new cache object if \n> the file contents have actually changed.\n\nFirst of all, what I meant to say with 'update-index --refresh'\nwas not the refreshing part itself, but the fact that says\n'needs update' -- meaning it knows those paths have been truly\nmodified.\n\nForgetting 'use git-apply' comment from Linus for now,... if you\nare going to do the above in separate steps, then the last one\nis already available (but not as an option to 'git-ls-files'):\n\n    git-diff-files -r --name-only -z | xargs -0 git-update-index --\n\n> If your objection is to calling the files modifed, then call it dirty or \n> something else.\n\nI was not talking about the name, but the semantics.\n\n* The user may be interested in cache-dirty files, but I suspect\n  that is a very limited audience.  I do not offhand think of a\n  good reason to want to know which files are cache-dirty\n  without wanting to know if they are really modified, except\n  when debugging git itself.  If you really want to know that,\n  you can always say `git-diff-files`, or if you want to be\n  pickier, `git-diff-files --diff-filter=M --name-only`.\n\n* Showing a list of *truly* 'modified' files, disregarding the\n  false hits from cache-dirty but otherwise unmodified files,\n  would be another useful thing.  But that is something\n  `git-update-cache --refresh` already gives you.\n\n* As a front-end, `git status` shows you list of modifications\n  between HEAD and cache, and between cache and working tree.\n  The latter is done with `git-diff-files` after running\n  `git-update-cache --refresh`.  This probably gives the most\n  useful information to the end user.\n\nHaving said all that, `git-ls-files`, especially with `-t` flag,\nis a handy way to know the status of all files in the working\ntree with a single command.  What it does not currently give us\nthat would be nicer to have as an addition is not cache-dirty\nstatus, but *true* 'modified' flag.  Although this is something\navailable from `git-update-cache --refresh` as I said earlier,\nit would still be nice to be able to get it out of a single\ncommand invocation, together with files in other status.\n\nSo that is what I have on the proposed updates branch tonight.\nDoes it more-or-less do what you wanted?\n"},{"id":"8979","messageId":"20050920071116.GJ15165MdfPADPa@greensroom.kotnet.org","threadId":"1870","inReplyTo":"7v3bo06xv4.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT - breaking backward compatibility","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-09-20T07:11:16Z","receivedAt":"2005-09-20T07:11:16Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Mon, Sep 19, 2005 at 11:45:35PM -0700, Junio C Hamano wrote:\n> Sven Verdoolaege <skimo@kotnet.org> writes:\n> \n> > What tool can be used as a replacement for git-diff-stages ?\n> \n> If we removed it, you would probably end up scripting it by\n> using output from git-ls-files --stage (or --unmerged), and\n> comparing the mode and SHA1 for the stages, and if you want -p\n> output then git-unpack-file and diff too.\n\nOK, that was basically what I had planed to do, until I noticed\nin your mail that there was a tool called git-diff-stages.\nI just thought your removing it meant that it had become\na special case of some other tool.\n\n> But the real question was how useful what git-diff-stages does\n> is.  Comparing stage3 (or stage1) and working tree might be\n> suseful, but comparing stage<n> and stage<m> is what the command\n> is about.  Since those stages are present after/during an\n> incomplete merge, probably the user or script is trying to\n> figure out what happened by inspecting the trees being merged --\n> if that is the case, instead of inspecting what the merge\n> algorithm which did not complete used to apply its heuristics\n> (which is essentially what is left in those stages), you or your\n> script can run 'git-diff-tree' across trees involved in the\n> merge directly.\n\nBut the merge heuristics usually do a pretty good job\nso the user would have to perform fewer manual merge operations\nif she starts off from the result of the failed merge.\n(And if it turns out that the merge heuristics really didn't\nwork, she can still throw the results away.)\n\nThe reason I'm asking is that I used dirdiff to do a \"difficult\"\nmerge which required some manual intervention.\nThe way I used it now, was to load the merge base, the two\nheads and the working directory (containing the result of the\nfailed merge) in dirdiff and then to merge the final\nresult into the working directory.\n\nI still need to look at the merging stuff in more detail,\nbut I figured that it would actually be more interesting\nif dirdiff could perform the merge on the index rather than\nthe working directory.\nWhat do you think ?\n\nskimo\n"},{"id":"8981","messageId":"20050920072928.GA17621@pasky.or.cz","threadId":"1870","inReplyTo":"432F92FC.4000405@didntduck.org","subject":"Re: GIT - breaking backward compatibility","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-20T07:29:28Z","receivedAt":"2005-09-20T07:29:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 06:41:32AM CEST, I got a letter\nwhere Brian Gerst <bgerst@didntduck.org> told me that...\n> Linus Torvalds wrote:\n> >\n> >On Tue, 20 Sep 2005, Brian Gerst wrote:\n> >\n> >>Essentially what I want to do is:\n> >>\n> >>git-ls-files --others | xargs git-update-index --add --\n> >>git-ls-files --deleted | xargs git-update-index --remove --\n> >>git-ls-files --modified | xargs git-update-index --\n> >>\n> >>This will completely resync the index and cache to the working tree \n> >>state after applying a patch.\n> >\n> >\n> >It will also be extremely inefficient.\n> >\n> >If you really have a _patch_, then \"git-apply --index\" is what you want to \n> >apply it with. It applies a patch _and_ updates the index as appropriate. \n> >It's how git-applymbox can apply hundreds of patches in short order.\n> >\n> >\t\tLinus\n> >\n> \n> That would be great, if git-apply accepted fuzzy patches.  I am trying \n> to apply the -mm series patches, which often are slightly out of date. \n> Andrew doesn't rebase them until they won't apply at all.\n\ncg-patch will process fuzzy patches and update the cache properly. It\ndoesn't handle rename/copy patches yet, though.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"8988","messageId":"20050920130848.GA1884@pasky.or.cz","threadId":"1870","inReplyTo":"432F8C33.5080603@didntduck.org","subject":"Re: GIT - breaking backward compatibility","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-20T13:08:48Z","receivedAt":"2005-09-20T13:08:48Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 06:12:35AM CEST, I got a letter\nwhere Brian Gerst <bgerst@didntduck.org> told me that...\n> Cogito would benefit from this too.  It currently uses git-diff-index \n> and some ugly sed expressions in cg-commit to detect modified files.\n\nActually, I think most of it is unnecessary - it was around from very\nearly days, some of it from even before the time when we started\nrecording adds/removed in the cache. It just doesn't break anything so I\nkept it around just to be sure, but I'll remove it soon - I want to\nwrite some cg-commit regression tests first.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"8989","messageId":"20050920132351.GB1884@pasky.or.cz","threadId":"1870","inReplyTo":"7vpsr4cx0f.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT - breaking backward compatibility","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-20T13:23:51Z","receivedAt":"2005-09-20T13:23:51Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 04:07:28AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> I raised the following issues in my previous messages but did\n> not hear many opinions [*1*].  I do not want to take it as a\n> blank check from the community to do whatever I please.  So here\n> is a recap.\n\nWhen I'm active on the mailing list, you can be sure that I'd complain\nif I didn't like it. ;-)\n\n>  * Tools renaming plan calls for removal of the backward\n>    compatible command names (e.g. git-fsck-cache and\n>    git-update-cache) sometime in the future.  This is scheduled\n>    for 0.99.8 around beginning of October.  If somebody wants\n>    extended amnesty period, this can be pushed back but unless I\n>    hear otherwise...\n\nI think the start of October is fine for Cogito. Cogito users usually\nupgrade both Cogito and GIT at once, it seems.\n\n>  * After reviewing the current set of commands, the following do\n>    not seem to be useful anymore; Linus said he feels they can\n>    go, and nobody else objected:\n> \n>    git-diff-helper git-diff-stages git-export git-rev-tree\n> \n>    I'd like to remove them before 1.0, and planning to do it\n>    within the 0.99.8 timeframe unless I hear otherwise.\n\nCogito does not use any of those.\n\n>  * After Brian Gerst posted a patch to show 'modified' files in\n>    ls-files [*2*], there was a brief discussion to change the\n>    tagged output markings to make them more readable, but\n>    neither Cogito nor StGIT seems to use tagged output.  I am\n>    currently thinking about removing '-t' altogether.\n> \n>    Again, unless I hear otherwise, I'd like to remove it within\n>    the 0.99.8 timeframe.\n\nWell, if it should be kept, it should certainly be in sync with\ngit-diff-* tag letters. But Cogito uses only the diff tag letters and\nI'm not sure if tag letters for all files in repository would really be\nuseful for anything.\n\n> [Footnote]\n> \n> *1* Well, Pasky indicated he does not like some of the terms in\n> the glossary in his recent Cogito release announcement, but that\n> was unfortunately after the fact.\n\nYes. I would complain loudly during the discussion, but I unwisely\nskipped it at first and then didn't read the list for a few weeks.\nMy fault, I have to make the best way out of the terminology mess I'm\nin now.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9116","messageId":"20050922144124.GJ21019@pasky.or.cz","threadId":"1870","inReplyTo":"7vpsr4cx0f.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT - breaking backward compatibility","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-22T14:41:24Z","receivedAt":"2005-09-22T14:41:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 04:07:28AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n>  * Tools renaming plan calls for removal of the backward\n>    compatible command names (e.g. git-fsck-cache and\n>    git-update-cache) sometime in the future.  This is scheduled\n>    for 0.99.8 around beginning of October.  If somebody wants\n>    extended amnesty period, this can be pushed back but unless I\n>    hear otherwise...\n\nActually, could we please keep the old git-ssh-* stuff for a bit\n(perhaps a lot) longer? The other renames are fine because people\nusually keep their git-core and porcelain versions in sync, but the\ngit-ssh-* stuff is about network interoperability and you are forcing\nother people to upgrade their installations, which may be troublesome\nfor them in the case their distribution didn't package the new stuff yet\nor whatever.  It's just two commands after all, so could we please have\nthem for at least another month or so?\n\nThanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9151","messageId":"7vfyrwjp7w.fsf@assigned-by-dhcp.cox.net","threadId":"1870","inReplyTo":"20050922144124.GJ21019@pasky.or.cz","subject":"Re: GIT - breaking backward compatibility","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-23T06:02:59Z","receivedAt":"2005-09-23T06:02:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Actually, could we please keep the old git-ssh-* stuff for a bit\n> (perhaps a lot) longer?\n\nYeah, I think that's very sensible.  Thanks!\n\nUpdated the renames plan in the TODO document.\n"}]}