{"thread":{"id":"6687","subject":"Deprecation/Removal schedule","startedAt":"2007-02-05T06:48:17Z","lastAt":"2007-02-07T11:10:59Z","messageCount":36,"participants":["Junio C Hamano","Shawn O. Pearce","Jakub Narebski","Mark Wooding","Johannes Schindelin","Alex Riesen","Linus Torvalds","Andy Parkins","Jeff King","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33611","messageId":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","threadId":"6687","inReplyTo":null,"subject":"Deprecation/Removal schedule","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-05T06:48:17Z","receivedAt":"2007-02-05T06:48:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"We seem to have accumulated some crufts, duplicated and/or\ndisused features. I think we should start planning deprecation\nand removal.\n\nHere are potential candidates we might want to mark as\n\"scheduled for removal\". Note that I threw in a bit more than\nwhat I seriously consider bloat, so your favorite may appear in\nthe list.\n\n* git-applymbox and git-applypatch\n\n Does anybody rely on them? I think new users are all using\n git-am (this is just what _I_ think -- please consider this\n message as a poll to voice your objection).\n\n* git-whatchanged\n\n This has been identical to git-log with different default\n options.\n\n* git-p4import, git-quiltimport and contrib/gitview\n\n These have seen almost no activity since their appearance. It\n could be that they are already perfect and many people are\n using them happily, but I find it a bit hard to believe.\n\n* git-diff-stages\n\n Judging from the fact that nobody complained what it does is\n not accessible from \"git diff\" wrapper, I suspect nobody is\n interested in comparing the stages while merging (I certainly\n do not use it myself).\n\n* git-lost-found\n\n Although it has served us well, I think it is about to outlive\n its usefulness, thanks to the recent \"reflog by default\"\n change.\n\n* git-local-fetch, git-ssh-fetch and git-ssh-upload\n\n In-tree git-fetch does not use these commit walkers as the\n backend. They might be used by Cogito and people's scripts so\n I am not seriously pushing for their removal. http-fetch is\n here to stay so it's not like removing them would reduce the\n burden to maintain the commit walkers anyway.\n\n* contrib/colordiff\n\n This has long outlived its usefulness.\n"},{"id":"33612","messageId":"20070205065758.GB13472@spearce.org","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T06:57:58Z","receivedAt":"2007-02-05T06:57:58Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> We seem to have accumulated some crufts, duplicated and/or\n> disused features. I think we should start planning deprecation\n> and removal.\n> \n> Here are potential candidates we might want to mark as\n> \"scheduled for removal\". Note that I threw in a bit more than\n> what I seriously consider bloat, so your favorite may appear in\n> the list.\n\nI'm OK with everything on the list going away. But that's because\nI don't ever use them. :)\n\nI'd think we also want to remove the following older aliases:\n\n annotate\n init-db\n fsck-objects\n repo-config\n\n1 year after 1.5.0 final ships. That should give people a chance\nto upgrade their other tools (StGit, qgit, etc.).\n\n-- \nShawn.\n"},{"id":"33618","messageId":"eq6tj6$80m$2@sea.gmane.org","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-05T09:33:49Z","receivedAt":"2007-02-05T09:33:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> We seem to have accumulated some crufts, duplicated and/or\n> disused features. I think we should start planning deprecation\n> and removal.\n> \n> Here are potential candidates we might want to mark as\n> \"scheduled for removal\". Note that I threw in a bit more than\n> what I seriously consider bloat, so your favorite may appear in\n> the list.\n> \n> * git-applymbox and git-applypatch\n> \n> Does anybody rely on them? I think new users are all using\n> git-am (this is just what _I_ think -- please consider this\n> message as a poll to voice your objection).\n\nIf I remember correctly there are here because Linus is used to\ntheir interface and prefers git-applymbox to git-am. I'm not sure\nfor example if git-am --interactive is on the par of git-applymbox -q\noption (BTW. if we remove git-applymbox, we would have to remove\nreference to it in git-am(1): \"--interactive: Run interactively,\njust like git-applymbox\"). git-am also lack all git-applymbox\nsignoff options.\n\n> * git-whatchanged\n> \n> This has been identical to git-log with different default\n> options.\n\nI agree. Perhaps we should add in the documentation of git-log,\nor/and in documentation of git-config, an example of \"whatchanged\"\nalias...\n\n> * git-p4import, git-quiltimport and contrib/gitview\n> \n> These have seen almost no activity since their appearance. It\n> could be that they are already perfect and many people are\n> using them happily, but I find it a bit hard to believe.\n\nI agree with removal of gitview; I'd rather leave importers, even\nif they haven's seen any activity. If they import correctly, what\nis to work on more?\n\n> * git-diff-stages\n> \n> Judging from the fact that nobody complained what it does is\n> not accessible from \"git diff\" wrapper, I suspect nobody is\n> interested in comparing the stages while merging (I certainly\n> do not use it myself).\n\nI think you can always use \"git diff : :\".\nI'm not sure if it is useful or not (perhaps it is not advertised).\n\n> * git-lost-found\n> \n> Although it has served us well, I think it is about to outlive\n> its usefulness, thanks to the recent \"reflog by default\"\n> change.\n\nI agree. If it is needed, perhaps this functionality should be made\nas an option to git-fsck.\n\n> * contrib/colordiff\n> \n> This has long outlived its usefulness.\n\nI agree.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33619","messageId":"eq6vq5$r7v$1@sea.gmane.org","threadId":"6687","inReplyTo":"eq6tj6$80m$2@sea.gmane.org","subject":"Re: Deprecation/Removal schedule","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-05T10:11:39Z","receivedAt":"2007-02-05T10:11:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n\n>> * git-p4import, git-quiltimport and contrib/gitview\n>> \n>> These have seen almost no activity since their appearance. It\n>> could be that they are already perfect and many people are\n>> using them happily, but I find it a bit hard to believe.\n> \n> I agree with removal of gitview; I'd rather leave importers, even\n> if they haven's seen any activity. If they import correctly, what\n> is to work on more?\n\nAn alternative for importers would be to move them into contrib area\n(I think unmaintained but not obsolete programs can be there in contrib).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33620","messageId":"20070205102506.GB14234@spearce.org","threadId":"6687","inReplyTo":"eq6vq5$r7v$1@sea.gmane.org","subject":"Re: Deprecation/Removal schedule","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T10:25:06Z","receivedAt":"2007-02-05T10:25:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> An alternative for importers would be to move them into contrib area\n> (I think unmaintained but not obsolete programs can be there in contrib).\n\nSure, but we don't want to promote carrying around unmaintained\nprograms in core Git. Its additional code which must still be\ntested or fixed when changes get made, like the final removal of\nthe fsck-objects alias. Hence, its never really unmaintained...\nsomeone must do the work.\n\nHaving a maintainer means there are one or more persons in the\ncommunity who are making sure that chunk of code stays current\nwhen changes are made, and bugs are being fixed when identified.\nIt also implies the code has some use, as it is unreasonable to\nexpect a maintainer to invest time in something which has no value.\n\nThings that are really central in Git have at least 3 or 4\nmaintainers who seem to rotate the workload fairly well. But as\nyou get closer to the outer (higher) layers it seems to fall on\nJunio and a much smaller group. I'd hate to see Junio spend lots\nof time working on things nobody uses.\n\nImporters are especially problematic. They aren't the most\nheavily used programs, as people tend to convert to Git once and\nthen don't look back. But they are also one of the first things a\nuser has experience with as they testdrive Git on a copy of their\nown project. So any importers we ship `out of the box' need to\nJust Work Danngit(tm). Unfortunately they are also get the least\namount of testing.\n\n-- \nShawn.\n"},{"id":"33627","messageId":"slrnese73d.86o.mdw@metalzone.distorted.org.uk","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2007-02-05T12:00:45Z","receivedAt":"2007-02-05T12:00:45Z","isPatch":false,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Junio C Hamano wrote:\n\n> * git-whatchanged\n\nMy fingers still type `whatchanged', but I can train them. Besides, it\ncould easily be done with an alias.\n\n> * git-p4import\n\nI may have a use for p4import, if the company I work for switches to\nPerforce. If it doesn't work, I'll probably end up fixing it or\nreplacing it with something based on Shawn's fastimport, but either way\nI'm not sure it's dead yet.\n\n-- [mdw]\n"},{"id":"33631","messageId":"Pine.LNX.4.63.0702051344160.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-05T12:45:14Z","receivedAt":"2007-02-05T12:45:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 4 Feb 2007, Junio C Hamano wrote:\n\n> * git-whatchanged\n> \n> This has been identical to git-log with different default\n> options.\n\nWould it really be so bad if we just kept this alias indefinitely? We can \nstop advertising it, but it is not expensive to carry that small part of \nthe code around.\n\nSame goes for repo-config, fsck-objects, init-db.\n\nCiao,\nDscho\n"},{"id":"33636","messageId":"81b0412b0702050750m5760ce61le34acc8adfdb8081@mail.gmail.com","threadId":"6687","inReplyTo":"eq6tj6$80m$2@sea.gmane.org","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-05T15:50:56Z","receivedAt":"2007-02-05T15:50:56Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/5/07, Jakub Narebski wrote:\n> Junio C Hamano wrote:\n>\n> > * git-lost-found\n> >\n> > Although it has served us well, I think it is about to outlive\n> > its usefulness, thanks to the recent \"reflog by default\"\n> > change.\n>\n> I agree. If it is needed, perhaps this functionality should be made\n> as an option to git-fsck.\n>\n\nI have reflog off by default (and never missed it yet), so leave it\nat least as option to git-fsck, please. Besides, how do you find\nlost objects which were not mentioned in any reflog? (because\nof a bug someone made in reflog code, for example)\n"},{"id":"33637","messageId":"81b0412b0702050753q5146838bp75faf8681f1f6d56@mail.gmail.com","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-05T15:53:12Z","receivedAt":"2007-02-05T15:53:12Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/5/07, Junio C Hamano wrote:\n> * git-p4import, git-quiltimport and contrib/gitview\n>\n> These have seen almost no activity since their appearance. It\n> could be that they are already perfect and many people are\n> using them happily, but I find it a bit hard to believe.\n\nWhy not leave the importers as examples?\nThey could be useful to someone.\n"},{"id":"33639","messageId":"Pine.LNX.4.64.0702050814380.8424@woody.linux-foundation.org","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-05T16:26:21Z","receivedAt":"2007-02-05T16:26:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 4 Feb 2007, Junio C Hamano wrote:\n> \n> * git-whatchanged\n> \n> This has been identical to git-log with different default\n> options.\n\nSomebody should at least document the differences before it's depracated.\n\nI think git-whatchanged ends up being equivalent to\n\n\tgit log --full-history --raw -r\n\nbut I didn't really check if there's something else.\n\nSame goes for \"git-am\". I use \"git-applymbox\", and I'll happily switch to \ngit-am, but I'd like somebody who knows to document the differences when \nit gets deprecated. I use \"git-applymbox -u\", and I guess I just should \nchange that to \"git-am --utf8\".\n\n> * git-p4import, git-quiltimport and contrib/gitview\n> \n> These have seen almost no activity since their appearance. It\n> could be that they are already perfect and many people are\n> using them happily, but I find it a bit hard to believe.\n\nI think they're useful to keep around, if for no other reason than as \nstarting points for others.\n\nThat said, I probably agree with your other examples:\n\n> * git-diff-stages\n> * git-lost-found\n> * git-local-fetch, git-ssh-fetch and git-ssh-upload\n> * contrib/colordiff\n\nAlthough the git-ssh-fetch thing might be useful if you try to fix a tree \nthat got corrupted and is missing an object (the native git protocol won't \nhelp you, since it assumes both trees are complete, while the stupid \nobject fetching can pick out individual missing objects, I think).\n\nThat said, I don't think anybody would really ever fix their trees that \nway. It's more likely that you'd just fetch the whole repo and add the \nmissing objects that way (ie do a clone, copy the pack-file, and repack \nthe resulting mess to get a nice clean and working repository again).\n\n\t\tLinus\n"},{"id":"33643","messageId":"7vtzy0mqtl.fsf@assigned-by-dhcp.cox.net","threadId":"6687","inReplyTo":"Pine.LNX.4.64.0702050814380.8424@woody.linux-foundation.org","subject":"Re: Deprecation/Removal schedule","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-05T17:56:06Z","receivedAt":"2007-02-05T17:56:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Same goes for \"git-am\". I use \"git-applymbox\", and I'll happily switch to \n> git-am, but I'd like somebody who knows to document the differences when \n> it gets deprecated. I use \"git-applymbox -u\", and I guess I just should \n> change that to \"git-am --utf8\".\n\nTrue; by the way, for \"am\", -u is the default these days by\npopular demand. I do not offhand remember if \"applymbox\" got\ncorresponding changes (I think it did).\n\n>> * git-p4import, git-quiltimport and contrib/gitview\n>> \n>> These have seen almost no activity since their appearance. It\n>> could be that they are already perfect and many people are\n>> using them happily, but I find it a bit hard to believe.\n>\n> I think they're useful to keep around, if for no other reason than as \n> starting points for others.\n\nI strongly agree with the starting-points arguments. I was\nhoping to hear the list to form a consensus to move useful\nstarting-point examples to contrib/.\n"},{"id":"33651","messageId":"200702051924.39205.andyparkins@gmail.com","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Add --patchdepth parameter to git-am.sh","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-05T19:24:38Z","receivedAt":"2007-02-05T19:24:38Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"If the series of patches you are applying via git-am was based in a\ndifferent directory there was no way to strip the directory (as you\nwould with git-apply).\n\nThis patch adds a --patchdepth option to git-am.sh whose argument is\npassed as a \"-p\" option to git-apply.\n\nSigned-off-by: Andy Parkins \n---\nI know git-apply isn't going anywhere, but git-applypatch is. However, all\nthis talk of it made me remember this patch.\n\n git-am.sh | 13 ++++++++-----\n 1 files changed, 8 insertions(+), 5 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 1252f26..cb503fc 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -60,7 +60,7 @@ fall_back_3way () {\n mkdir \"$dotest/patch-merge-tmp-dir\"\n \n # First see if the patch records the index info that we can use.\n- git-apply -z --index-info \"$dotest/patch\" \\\n+ git-apply $patchdepth -z --index-info \"$dotest/patch\" \\\n \t>\"$dotest/patch-merge-index-info\" &&\n GIT_INDEX_FILE=\"$dotest/patch-merge-tmp-index\" \\\n git-update-index -z --index-info <\"$dotest/patch-merge-index-info\" &&\n@@ -70,7 +70,7 @@ fall_back_3way () {\n \n echo Using index info to reconstruct a base tree...\n if GIT_INDEX_FILE=\"$dotest/patch-merge-tmp-index\" \\\n-\tgit-apply $binary --cached <\"$dotest/patch\"\n+\tgit-apply $patchdepth $binary --cached <\"$dotest/patch\"\n then\n \tmv \"$dotest/patch-merge-base+\" \"$dotest/patch-merge-base\"\n \tmv \"$dotest/patch-merge-tmp-index\" \"$dotest/patch-merge-index\"\n@@ -106,7 +106,7 @@ It does not apply to blobs recorded in its index.\"\n }\n \n prec=4\n-dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary= ws= resolvemsg=\n+dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary= ws= resolvemsg= patchdepth=\n \n while case \"$#\" in 0) break;; esac\n do\n@@ -147,6 +147,9 @@ do\n \t--resolvemsg=*)\n \tresolvemsg=$(echo \"$1\" | sed -e \"s/^--resolvemsg=//\"); shift ;;\n \n+\t--patchdepth=*)\n+\tpatchdepth=-p$(echo \"$1\" | sed -e \"s/^--patchdepth=//\"); shift ;;\n+\n \t--)\n \tshift; break ;;\n \t-*)\n@@ -389,12 +392,12 @@ do\n \tfi\n \n \techo\n-\techo \"Applying '$SUBJECT'\"\n+\techo \"Applying '$SUBJECT' at depth $patchdepth\"\n \techo\n \n \tcase \"$resolved\" in\n \t'')\n-\t\tgit-apply $binary --index $ws \"$dotest/patch\"\n+\t\tgit-apply $patchdepth $binary --index $ws \"$dotest/patch\"\n \t\tapply_status=$?\n \t\t;;\n \tt)\n-- \n1.5.0.rc1.gf4b6c\n"},{"id":"33653","messageId":"20070205193700.GB8409@spearce.org","threadId":"6687","inReplyTo":"200702051924.39205.andyparkins@gmail.com","subject":"Re: [PATCH] Add --patchdepth parameter to git-am.sh","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T19:37:00Z","receivedAt":"2007-02-05T19:37:00Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> If the series of patches you are applying via git-am was based in a\n> different directory there was no way to strip the directory (as you\n> would with git-apply).\n> \n> This patch adds a --patchdepth option to git-am.sh whose argument is\n> passed as a \"-p\" option to git-apply.\n\nIs there something wrong with -p? Looking at git-am, -p is not\ncurrently accepted as an option. Its universally considered the\ndepth parameter to standard `patch`, which is why git-apply also\naccepts it over --patchdepth.\n\nI'd rather see git-am use the same arguments (when possible)\nas git-apply.\n\n-- \nShawn.\n"},{"id":"33654","messageId":"20070205194508.GD8409@spearce.org","threadId":"6687","inReplyTo":"81b0412b0702050750m5760ce61le34acc8adfdb8081@mail.gmail.com","subject":"Re: Deprecation/Removal schedule","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T19:45:08Z","receivedAt":"2007-02-05T19:45:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> I have reflog off by default (and never missed it yet), so leave it\n> at least as option to git-fsck, please. Besides, how do you find\n> lost objects which were not mentioned in any reflog? (because\n> of a bug someone made in reflog code, for example)\n\nLearn to love reflog. :-)\n\nI use it daily. Mainly `git log origin/master@{1}..origin/master`\nto see what has come in from Junio since my last fetch. The @{n}\nsyntax has (for me) been one of its best features. (Thanks Junio!)\n\nRepeat after me:\n\n There aren't any bugs in the reflog code.\n They have not been any bugs in the reflog code.\n There will never be any bugs in the reflog code.\n\nI don't think we've had a case where a commit wasn't recorded in\na reflog when it should have been. Perhaps *very* early in reflog\ndevelopment a couple of commands bypassed the reflog code, but that\nhas certainly since been fixed. The last one was git-receive-pack,\nwhich we finished in early December.\n\nIf the reflog code did fail to record something, and you needed it,\nand you hadn't git-prune'd yet, git-fsck would list the dangling\ncommit. And a copy-n-paste session with `git-log -p D --not --all`\nin another xterm would help you navigate what the dangling commits\nwere.\n\n-- \nShawn.\n"},{"id":"33677","messageId":"81b0412b0702051449l3951ee43s34bde4614c83612d@mail.gmail.com","threadId":"6687","inReplyTo":"20070205194508.GD8409@spearce.org","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-05T22:49:51Z","receivedAt":"2007-02-05T22:49:51Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/5/07, Shawn O. Pearce wrote:\n> I use it daily. Mainly `git log origin/master@{1}..origin/master`\n> to see what has come in from Junio since my last fetch. The @{n}\n> syntax has (for me) been one of its best features. (Thanks Junio!)\n\nIt looks and smells like a useful feature. I just haven't found\nany use for it yet. Besides all the good, it's another part of a repo\nneeding maintenance (constantly growing thing, like /var/log).\n\n> If the reflog code did fail to record something, and you needed it,\n> and you hadn't git-prune'd yet, git-fsck would list the dangling\n> commit. And a copy-n-paste session with `git-log -p D --not --all`\n> in another xterm would help you navigate what the dangling commits\n> were.\n\nYes, of course. I somehow missed it. Shows how often one does\ngit-fsck in cygwin, doesn't it?\n"},{"id":"33678","messageId":"20070205225505.GA9222@spearce.org","threadId":"6687","inReplyTo":"81b0412b0702051449l3951ee43s34bde4614c83612d@mail.gmail.com","subject":"Re: Deprecation/Removal schedule","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T22:55:05Z","receivedAt":"2007-02-05T22:55:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> On 2/5/07, Shawn O. Pearce wrote:\n> >I use it daily. Mainly `git log origin/master@{1}..origin/master`\n> >to see what has come in from Junio since my last fetch. The @{n}\n> >syntax has (for me) been one of its best features. (Thanks Junio!)\n> \n> It looks and smells like a useful feature. I just haven't found\n> any use for it yet. Besides all the good, it's another part of a repo\n> needing maintenance (constantly growing thing, like /var/log).\n\n`git gc` is your friend. It automatically trims the reflogs, keeping\nonly the last 90 days worth of entries. You can tune this with the\n`gc.reflogexpire` configuration parameter. Seeing as how `git gc`\nalso invokes `git repack -a -d`, `git pack-refs --prune`, etc.,\none would have to wonder why use anything else.\n\nSo its not a constantly growing thing; you can at least bound it\nby time.\n \n> >If the reflog code did fail to record something, and you needed it,\n> >and you hadn't git-prune'd yet, git-fsck would list the dangling\n> >commit. And a copy-n-paste session with `git-log -p D --not --all`\n> >in another xterm would help you navigate what the dangling commits\n> >were.\n> \n> Yes, of course. I somehow missed it. Shows how often one does\n> git-fsck in cygwin, doesn't it?\n\n:-)\n\nActually I have need for git-fsck too often on Cygwin; one of\nmy coworkers looses objects all of the time in his repository.\nI think his harddrive is failed. The zlib CRC checking we put into\npack-objects saved his bacon when it failed to repack his repository\nwith corrupt objects.\n\n-- \nShawn.\n"},{"id":"33712","messageId":"81b0412b0702060220l3887624ax762e5cba3f75fd0c@mail.gmail.com","threadId":"6687","inReplyTo":"20070205225505.GA9222@spearce.org","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-06T10:20:40Z","receivedAt":"2007-02-06T10:20:40Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/5/07, Shawn O. Pearce wrote:\n> Alex Riesen wrote:\n> > On 2/5/07, Shawn O. Pearce wrote:\n> > >I use it daily. Mainly `git log origin/master@{1}..origin/master`\n> > >to see what has come in from Junio since my last fetch. The @{n}\n> > >syntax has (for me) been one of its best features. (Thanks Junio!)\n> >\n> > It looks and smells like a useful feature. I just haven't found\n> > any use for it yet. Besides all the good, it's another part of a repo\n> > needing maintenance (constantly growing thing, like /var/log).\n>\n> `git gc` is your friend. It automatically trims the reflogs, keeping\n> only the last 90 days worth of entries. You can tune this with the\n> `gc.reflogexpire` configuration parameter.\n\ngit gc (repack -d of it) is too dangerous in a shared repo: it breaks\nthe repos which depend on the master repository, have sent (by some\nmeans) some objects over to the master, and accidentally removed\nthe reference, and were pruned afterwards.\nI'm not saying git gc is bad, I'm just saying you can't use it\nwhenever and wherever you want. Sometimes you'd prefer\nto only expire logs, only pack refs or only repack. And if I\nhave no logs, I can't forget to trim them.\n\n> So its not a constantly growing thing; you can at least bound it\n> by time.\n\nNo, I can't. git gc and reflog --expire can. I have to call them.\nAnd I don't think trimming the logs automatically is a good\nidea: 90 days of commits can be a very long file on a busy repository.\nAdd to that slow disks and stupid OS (the worst case, which matters),\nand you get a very annoyed user (if he was just angry before, having\nto use the drive and OS, he'll definitely go berserk now).\n\n> > >If the reflog code did fail to record something, and you needed it,\n> > >and you hadn't git-prune'd yet, git-fsck would list the dangling\n> > >commit. And a copy-n-paste session with `git-log -p D --not --all`\n> > >in another xterm would help you navigate what the dangling commits\n> > >were.\n> >\n> > Yes, of course. I somehow missed it. Shows how often one does\n> > git-fsck in cygwin, doesn't it?\n>\n> :-)\n>\n> Actually I have need for git-fsck too often on Cygwin; one of\n> my coworkers looses objects all of the time in his repository.\n> I think his harddrive is failed. The zlib CRC checking we put into\n> pack-objects saved his bacon when it failed to repack his repository\n> with corrupt objects.\n\nNever had that, can be hardware problem.\n\nWhat I meant is that it takes too long and I just avoid running\nfsck unless I am forced to.\n"},{"id":"33713","messageId":"Pine.LNX.4.63.0702061144430.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6687","inReplyTo":"81b0412b0702060220l3887624ax762e5cba3f75fd0c@mail.gmail.com","subject":"Re: Deprecation/Removal schedule","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-06T10:45:24Z","receivedAt":"2007-02-06T10:45:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Feb 2007, Alex Riesen wrote:\n\n> On 2/5/07, Shawn O. Pearce wrote:\n> > Alex Riesen wrote:\n> > > On 2/5/07, Shawn O. Pearce wrote:\n> > > >I use it daily. Mainly `git log origin/master@{1}..origin/master`\n> > > >to see what has come in from Junio since my last fetch. The @{n}\n> > > >syntax has (for me) been one of its best features. (Thanks Junio!)\n> > >\n> > > It looks and smells like a useful feature. I just haven't found\n> > > any use for it yet. Besides all the good, it's another part of a repo\n> > > needing maintenance (constantly growing thing, like /var/log).\n> > \n> > `git gc` is your friend. It automatically trims the reflogs, keeping\n> > only the last 90 days worth of entries. You can tune this with the\n> > `gc.reflogexpire` configuration parameter.\n> \n> git gc (repack -d of it) is too dangerous in a shared repo: it breaks\n> the repos which depend on the master repository, have sent (by some\n> means) some objects over to the master, and accidentally removed\n> the reference, and were pruned afterwards.\n\nWe no longer call git-prune automatically in git-gc. You have to say \n\"git-gc --prune\" to trigger that behaviour.\n\nHappy?\n\nCiao,\nDscho\n"},{"id":"33714","messageId":"20070206110015.GA10231@coredump.intra.peff.net","threadId":"6687","inReplyTo":"Pine.LNX.4.63.0702061144430.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Deprecation/Removal schedule","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-06T11:00:15Z","receivedAt":"2007-02-06T11:00:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 06, 2007 at 11:45:24AM +0100, Johannes Schindelin wrote:\n\n> > git gc (repack -d of it) is too dangerous in a shared repo: it breaks\n> > the repos which depend on the master repository, have sent (by some\n> > means) some objects over to the master, and accidentally removed\n> > the reference, and were pruned afterwards.\n> \n> We no longer call git-prune automatically in git-gc. You have to say \n> \"git-gc --prune\" to trigger that behaviour.\n\nrepack -d can lose objects, too:\n\n# fully packed test repo with 2 commits\nmkdir repo && cd repo\ngit init\ntouch foo\ngit add foo\ngit commit -m foo\necho bar >foo\ngit commit -a -m bar\ngit repack -a -d\n\n# remember the latest commit\ncommit=`git rev-parse HEAD`\n\n# now make it dangling\ngit reset --hard HEAD^\nsleep 1\ngit reflog expire --expire=0 HEAD refs/heads/master\n\n# now repack\ngit repack -a -d\n\n# and it's gone\ngit-show $commit\n\n-Peff\n"},{"id":"33715","messageId":"Pine.LNX.4.63.0702061202260.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6687","inReplyTo":"20070206110015.GA10231@coredump.intra.peff.net","subject":"Re: Deprecation/Removal schedule","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-06T11:03:45Z","receivedAt":"2007-02-06T11:03:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Feb 2007, Jeff King wrote:\n\n> On Tue, Feb 06, 2007 at 11:45:24AM +0100, Johannes Schindelin wrote:\n> \n> > > git gc (repack -d of it) is too dangerous in a shared repo: it breaks\n> > > the repos which depend on the master repository, have sent (by some\n> > > means) some objects over to the master, and accidentally removed\n> > > the reference, and were pruned afterwards.\n> > \n> > We no longer call git-prune automatically in git-gc. You have to say \n> > \"git-gc --prune\" to trigger that behaviour.\n> \n> repack -d can lose objects, too:\n> \n> # fully packed test repo with 2 commits\n> mkdir repo && cd repo\n> git init\n> touch foo\n> git add foo\n> git commit -m foo\n> echo bar >foo\n> git commit -a -m bar\n> git repack -a -d\n> \n> # remember the latest commit\n> commit=`git rev-parse HEAD`\n> \n> # now make it dangling\n> git reset --hard HEAD^\n\nThis is the culprit.\n\nThe solution is very easy: do not --reference a repository which resets or \ndeletes branches. IMHO this is all too obvious.\n\nCiao,\nDscho\n"},{"id":"33716","messageId":"81b0412b0702060501u41a3f707pea4bfc58220fd862@mail.gmail.com","threadId":"6687","inReplyTo":"Pine.LNX.4.63.0702061144430.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-06T13:01:52Z","receivedAt":"2007-02-06T13:01:52Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/6/07, Johannes Schindelin wrote:\n> > >\n> > > `git gc` is your friend. It automatically trims the reflogs, keeping\n> > > only the last 90 days worth of entries. You can tune this with the\n> > > `gc.reflogexpire` configuration parameter.\n> >\n> > git gc (repack -d of it) is too dangerous in a shared repo: it breaks\n> > the repos which depend on the master repository, have sent (by some\n> > means) some objects over to the master, and accidentally removed\n> > the reference, and were pruned afterwards.\n>\n> We no longer call git-prune automatically in git-gc. You have to say\n> \"git-gc --prune\" to trigger that behaviour.\n\nno. You'd have to stop calling repack as well.\n\nI mean the objects that generally have to be removed and just\naccidentally was not pinned in the shared repo.\nOr did you mean that repack will leave unreferenced objects\nbehind in objects/??/files?\n"},{"id":"33717","messageId":"81b0412b0702060509l1283fcb2j105a0580a718b2e0@mail.gmail.com","threadId":"6687","inReplyTo":"Pine.LNX.4.63.0702061202260.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-06T13:09:45Z","receivedAt":"2007-02-06T13:09:45Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/6/07, Johannes Schindelin wrote:\n> > > > git gc (repack -d of it) is too dangerous in a shared repo: it breaks\n> > > > the repos which depend on the master repository, have sent (by some\n> > > > means) some objects over to the master, and accidentally removed\n> > > > the reference, and were pruned afterwards.\n> > >\n> > > We no longer call git-prune automatically in git-gc. You have to say\n> > > \"git-gc --prune\" to trigger that behaviour.\n> >\n> > repack -d can lose objects, too:\n> >\n> > # fully packed test repo with 2 commits\n>\n> This is the culprit.\n>\n> The solution is very easy: do not --reference a repository which resets or\n> deletes branches. IMHO this is all too obvious.\n>\n\nOr just do no repack in the referenced repo.\n\nAnyway, the discussion outlived its usefulness.\nI have what I wanted (git fsck --unreachable), and nobody can force\nme to repack my shared repo, so the issue does not exist for the original\nposter.\n"},{"id":"33718","messageId":"Pine.LNX.4.63.0702061420420.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6687","inReplyTo":"81b0412b0702060509l1283fcb2j105a0580a718b2e0@mail.gmail.com","subject":"Re: Deprecation/Removal schedule","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-06T13:24:13Z","receivedAt":"2007-02-06T13:24:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Feb 2007, Alex Riesen wrote:\n\n> On 2/6/07, Johannes Schindelin wrote:\n> > > > > git gc (repack -d of it) is too dangerous in a shared repo: it breaks\n> > > > > the repos which depend on the master repository, have sent (by some\n> > > > > means) some objects over to the master, and accidentally removed\n> > > > > the reference, and were pruned afterwards.\n> > > >\n> > > > We no longer call git-prune automatically in git-gc. You have to say\n> > > > \"git-gc --prune\" to trigger that behaviour.\n> > >\n> > > repack -d can lose objects, too:\n> > >\n> > > # fully packed test repo with 2 commits\n> > \n> > This is the culprit.\n> > \n> > The solution is very easy: do not --reference a repository which resets or\n> > deletes branches. IMHO this is all too obvious.\n> > \n> \n> Or just do no repack in the referenced repo.\n\nThat is not the solution.\n\nThe error in your setup is to _rely_ on data which just _might go away_!\n\nIOW do _not_ use an unreliable repository for --reference!\n\n> Anyway, the discussion outlived its usefulness.\n> I have what I wanted (git fsck --unreachable), and nobody can force\n> me to repack my shared repo, so the issue does not exist for the original\n> poster.\n\nWell, I think unless you understand that you do something really fragile, \nthe discussion did not yet outlive its usefulness.\n\nCiao,\nDscho\n"},{"id":"33719","messageId":"81b0412b0702060532l31f88f64s812d2829f4d45844@mail.gmail.com","threadId":"6687","inReplyTo":"Pine.LNX.4.63.0702061420420.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-06T13:32:02Z","receivedAt":"2007-02-06T13:32:02Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/6/07, Johannes Schindelin wrote:\n> > Or just do no repack in the referenced repo.\n>\n> That is not the solution.\n>\n> The error in your setup is to _rely_ on data which just _might go away_!\n\nThe data cannot \"just\" go away. I'll have to \"go the data away\" manually.\n\n> IOW do _not_ use an unreliable repository for --reference!\n\nWell, that being an accident, I see no way to follow your advice.\n\n> > Anyway, the discussion outlived its usefulness.\n> > I have what I wanted (git fsck --unreachable), and nobody can force\n> > me to repack my shared repo, so the issue does not exist for the original\n> > poster.\n>\n> Well, I think unless you understand that you do something really fragile,\n> the discussion did not yet outlive its usefulness.\n\nYes, preacher.\n"},{"id":"33726","messageId":"45C896F3.5000007@op5.se","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-02-06T14:55:47Z","receivedAt":"2007-02-06T14:55:47Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> * git-lost-found\n> \n> Although it has served us well, I think it is about to outlive\n> its usefulness, thanks to the recent \"reflog by default\"\n> change.\n> \n\nNonono. Please no. This has saved me more times than I can even care\nto remember. Especially whenever I'm teaching newcomers how to git.\nI really wouldn't want to not have it there in case its needed and\nsome schmuck upgrades git and then loses something vital because he\nforgot to enable the reflog on an old repo.\n\nDoes it add significantly to the maintenance burden?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"33730","messageId":"81b0412b0702060726o17cd3521u633a6c4deb07b9d3@mail.gmail.com","threadId":"6687","inReplyTo":"45C896F3.5000007@op5.se","subject":"Re: Deprecation/Removal schedule","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-06T15:26:14Z","receivedAt":"2007-02-06T15:26:14Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/6/07, Andreas Ericsson wrote:\n> Junio C Hamano wrote:\n> >\n> > * git-lost-found\n> >\n> > Although it has served us well, I think it is about to outlive\n> > its usefulness, thanks to the recent \"reflog by default\"\n> > change.\n> >\n>\n> Nonono. Please no. This has saved me more times than I can even care\n> to remember. Especially whenever I'm teaching newcomers how to git.\n> I really wouldn't want to not have it there in case its needed and\n> some schmuck upgrades git and then loses something vital because he\n> forgot to enable the reflog on an old repo.\n\nIt's functionality is superseded by \"git fsck --unreachable\",\nsee this discussion.\n"},{"id":"33731","messageId":"Pine.LNX.4.63.0702061632180.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6687","inReplyTo":"81b0412b0702060726o17cd3521u633a6c4deb07b9d3@mail.gmail.com","subject":"Re: Deprecation/Removal schedule","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-06T15:33:27Z","receivedAt":"2007-02-06T15:33:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Feb 2007, Alex Riesen wrote:\n\n> On 2/6/07, Andreas Ericsson wrote:\n> > Junio C Hamano wrote:\n> > >\n> > > * git-lost-found\n> > >\n> > > Although it has served us well, I think it is about to outlive\n> > > its usefulness, thanks to the recent \"reflog by default\"\n> > > change.\n> > >\n> > \n> > Nonono. Please no. This has saved me more times than I can even care\n> > to remember. Especially whenever I'm teaching newcomers how to git.\n> > I really wouldn't want to not have it there in case its needed and\n> > some schmuck upgrades git and then loses something vital because he\n> > forgot to enable the reflog on an old repo.\n> \n> It's functionality is superseded by \"git fsck --unreachable\",\n> see this discussion.\n\nAFAICT lost-and-found _connects_ the objects to files, and as such is \neasier to browse after running the command (which is expensive).\n\nIf you _have_ to lose lost-and-found, why not resurrect the functionality \nas an option to fsck?\n\nCiao,\nDscho\n"},{"id":"33773","messageId":"7vsldibfva.fsf@assigned-by-dhcp.cox.net","threadId":"6687","inReplyTo":"7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-07T07:12:41Z","receivedAt":"2007-02-07T07:12:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The feature release after 1.5.0 will be 1.5.1; hopefully we can\nstick to 6-8 weeks schedule between feature releases, which\nmakes it due sometime in April, assuming that 1.5.0 will be done\nin a week or so.\n\nIn 1.5.0, you will still see git-resolve and git-diff-stages,\nbut they will be removed by 1.5.1.\n\nWe will keep the following for now, but not encourage use of\nthem to new users. There isn't any definite removal schedule\nright now and we may not even need one.\n\n\twhatchanged (use \"log --full-history --raw -r\" instead)\n\tapplymbox (use \"am\" instead)\n\tinit-db (use \"init\")\n\tfsck-objects (use \"fsck\")\n\trepo-config (use \"config\")\n\nWhen we created the contrib/ area, I said that anything there is\nsubject to periodical review for removal if kept unused and\nunmaintained. But anything that satisfies the requirements of\nits small userbase will have happy users without exposing its\nshortcomings, so I suspect removal from contrib/ by periodic\nreview would never happen in practice.\n\nI've already removed contrib/colordiff and git-merge-recur.\n\nAmong the ones I mentioned in my initial message, the ones that\nare not mentioned in this message will stay as before.\n"},{"id":"33774","messageId":"7vfy9ibcdx.fsf@assigned-by-dhcp.cox.net","threadId":"6687","inReplyTo":"200702051924.39205.andyparkins@gmail.com","subject":"Re: [PATCH] Add --patchdepth parameter to git-am.sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-07T08:27:54Z","receivedAt":"2007-02-07T08:27:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> If the series of patches you are applying via git-am was based in a\n> different directory there was no way to strip the directory (as you\n> would with git-apply).\n>\n> This patch adds a --patchdepth option to git-am.sh whose argument is\n> passed as a \"-p\" option to git-apply.\n>\n> Signed-off-by: Andy Parkins \n> ---\n> I know git-apply isn't going anywhere, but git-applypatch is. However, all\n> this talk of it made me remember this patch.\n\nI do not understand this remark, as applypatch does not have -p\neither. If we were to do this, I agree with others that this\nshould simply be called -p (we do not have name crash with\nexisting options, do we?).\n\nI am not sure how useful applying a patch though git-am with -p\nwould be. I can understand, \n\nAfter seeing that a patch does not apply because the patch was\ngenerated at the wrong level, it would be very natural to use\n\"git apply -p0 --index .dotest/patch\" and then continue with\n\"git am --resolved\". So obviously, -p to git-apply is very\nuseful, but -p given to \"am\" means all of the patches in your\nmailbox has uniformly wrong patch depth. I wonder how common\nwould that be in practice.\n\nBut other than that \"how useful would that be in practice?\"\nissue, I do not think the patch is too bad, except one hunk:\n\n> @@ -389,12 +392,12 @@ do\n> \tfi\n> \n> \techo\n> -\techo \"Applying '$SUBJECT'\"\n> +\techo \"Applying '$SUBJECT' at depth $patchdepth\"\n> \techo\n> \n\nThis is wrong if you do not use any $patchdepth.\n"},{"id":"33776","messageId":"200702070933.21804.jnareb@gmail.com","threadId":"6687","inReplyTo":"7vsldibfva.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-07T08:33:20Z","receivedAt":"2007-02-07T08:33:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> In 1.5.0, you will still see git-resolve and git-diff-stages,\n> but they will be removed by 1.5.1.\n\nWell, it is not as if we cannot obtain equivalent of git-diff-stages\nwithout this command. Stages are , and \n(git-merge-base ) so I think we can use git-diff-tree\nwith appropriate arguments...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"33782","messageId":"20070207093311.258490@gmx.net","threadId":"6687","inReplyTo":"200702070933.21804.jnareb@gmail.com","subject":"Re: Deprecation/Removal schedule","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-07T09:33:11Z","receivedAt":"2007-02-07T09:33:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nJakub wrote:\n\n> Junio C Hamano wrote:\n> \n> > In 1.5.0, you will still see git-resolve and git-diff-stages,\n> > but they will be removed by 1.5.1.\n> \n> Well, it is not as if we cannot obtain equivalent of git-diff-stages\n> without this command. Stages are , and \n> (git-merge-base ) so I think we can use git-diff-tree\n> with appropriate arguments...\n\nNot exactly. The stages are in the index. For example, when you have conflicts, the stages might not reflect _any_ tree at all! This is because _part_ of the changes could be merged, and _part_ of the changes conflict.\n\nBut it does not matter anyway. Good bye diff-stages!\n\nCiao,\nDscho\n\n-- \nDer GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! \nIdeal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer\n"},{"id":"33783","messageId":"7v64aeb95j.fsf@assigned-by-dhcp.cox.net","threadId":"6687","inReplyTo":"200702070933.21804.jnareb@gmail.com","subject":"Re: Deprecation/Removal schedule","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-07T09:37:44Z","receivedAt":"2007-02-07T09:37:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> In 1.5.0, you will still see git-resolve and git-diff-stages,\n>> but they will be removed by 1.5.1.\n>\n> Well, it is not as if we cannot obtain equivalent of git-diff-stages\n> without this command. Stages are , and \n> (git-merge-base ) so I think we can use git-diff-tree\n> with appropriate arguments...\n\nWell, sorry for wasting the bandwidth if it was not obvious from\nmy message, but that's exactly why I am announcing officially\nthat they *will* be removed with a definite timeframe.\n"},{"id":"33784","messageId":"eqc6ua$pc$1@sea.gmane.org","threadId":"6687","inReplyTo":"7vfy9ibcdx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --patchdepth parameter to git-am.sh","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-07T09:44:08Z","receivedAt":"2007-02-07T09:44:08Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Andy Parkins writes:\n> \n>> If the series of patches you are applying via git-am was based in a\n>> different directory there was no way to strip the directory (as you\n>> would with git-apply).\n>>\n>> This patch adds a --patchdepth option to git-am.sh whose argument is\n>> passed as a \"-p\" option to git-apply.\n[...]\n> \n> I do not understand this remark, as applypatch does not have -p\n> either. If we were to do this, I agree with others that this\n> should simply be called -p (we do not have name crash with\n> existing options, do we?).\n\nPerhaps options should be -p as short version, and --patchdepth \n(or --strip as in GNU patch) as long version?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33786","messageId":"200702070959.12819.andyparkins@gmail.com","threadId":"6687","inReplyTo":"7vfy9ibcdx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --patchdepth parameter to git-am.sh","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-07T09:59:11Z","receivedAt":"2007-02-07T09:59:11Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 February 07 08:27, Junio C Hamano wrote:\n\n> I do not understand this remark, as applypatch does not have -p\n> either. If we were to do this, I agree with others that this\n\nOh. That /would/ make it confusing. I didn't realise they both didn't have \nit (I thought I had used it at some point in the past, my swiss cheese \nmemory). In that case, the patch is a lot more relevant.\n\n> should simply be called -p (we do not have name crash with\n> existing options, do we?).\n\nI have no problem with it being \"-p\"; I just don't like to take valuable \nsingle letter namespace unilaterally.\n\n> After seeing that a patch does not apply because the patch was\n> generated at the wrong level, it would be very natural to use\n> \"git apply -p0 --index .dotest/patch\" and then continue with\n> \"git am --resolved\". So obviously, -p to git-apply is very\n> useful, but -p given to \"am\" means all of the patches in your\n> mailbox has uniformly wrong patch depth. I wonder how common\n> would that be in practice.\n\nI added it because I had need for it; I managed to manufacture a whole series \nof patches at the wrong patch level. It had been hard work to make them, so \nI didn't feel like making them all again just to change the depth.\n\n> But other than that \"how useful would that be in practice?\"\n> This is wrong if you do not use any $patchdepth.\n\nGuilty. As I said, I added it for my own use; so didn't mind too much about \nweird output. If I resent it would be to drop my modifications to the \nmessage (it's redundant anyway - surely you know what you specified on the \ncommand line?), so feel free to just remove that hunk.\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33788","messageId":"200702071113.31938.jnareb@gmail.com","threadId":"6687","inReplyTo":"20070207093311.258490@gmx.net","subject":"Re: Deprecation/Removal schedule","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-07T10:13:31Z","receivedAt":"2007-02-07T10:13:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> Jakub Narebski wrote:\n>> Junio C Hamano wrote:\n>> \n>>> In 1.5.0, you will still see git-resolve and git-diff-stages,\n>>> but they will be removed by 1.5.1.\n>> \n>> Well, it is not as if we cannot obtain equivalent of git-diff-stages\n>> without this command. Stages are , and \n>> (git-merge-base ) so I think we can use git-diff-tree\n>> with appropriate arguments...\n> \n> Not exactly. The stages are in the index. For example, when you have\n> conflicts, the stages might not reflect _any_ tree at all! This is\n> because _part_ of the changes could be merged, and _part_ of the\n> changes conflict. \n> \n> But it does not matter anyway. Good bye diff-stages!\n\nHmmm... I do wonder if git-diff-stages precedes introduction of combined \ndiff format...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"33792","messageId":"Pine.LNX.4.63.0702071210300.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6687","inReplyTo":"7vsldibfva.fsf@assigned-by-dhcp.cox.net","subject":"Re: Deprecation/Removal schedule","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-07T11:10:59Z","receivedAt":"2007-02-07T11:10:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Feb 2007, Junio C Hamano wrote:\n\n> There isn't any definite removal schedule right now and we may not even \n> need one.\n\nThanks!\n\nCiao,\nDscho\n"}]}