{"thread":{"id":"10370","subject":"[PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","startedAt":"2007-10-19T00:45:27Z","lastAt":"2007-10-19T21:57:26Z","messageCount":38,"participants":["Shawn O. Pearce","Jeff King","Sam Vilain","David Symonds","Nicolas Pitre","Linus Torvalds","Wincent Colaiuta"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"56454","messageId":"20071019004527.GA12930@spearce.org","threadId":"10370","inReplyTo":null,"subject":"[PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T00:45:27Z","receivedAt":"2007-10-19T00:45:27Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Recently I was referred to the Grammar Police as the git-pack-objects\nprogress message 'Deltifying %u objects' is considered to be not\nproper English to at least some small but vocal segment of the\nEnglish speaking population.  Techncially we are applying delta\ncompression to these objects at this stage, so the new term is\nslightly more acceptable to the Grammar Police but is also just\nas correct.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n\n To go on top of your 'np/progress' series that is currently in next.\n I think it might keep us out of trouble with certain individuals...\n\n builtin-pack-objects.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex 15d3750..f79fc0b 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -1718,7 +1718,7 @@ static void prepare_pack(int window, int depth)\n \tif (nr_deltas && n > 1) {\n \t\tunsigned nr_done = 0;\n \t\tif (progress)\n-\t\t\tstart_progress(&progress_state, \"Deltifying objects\",\n+\t\t\tstart_progress(&progress_state, \"Delta compressing objects\",\n \t\t\t\t\tnr_deltas);\n \t\tqsort(delta_list, n, sizeof(*delta_list), type_size_sort);\n \t\tll_find_deltas(delta_list, n, window+1, depth, &nr_done);\n-- \n1.5.3.4.1249.g895be\n"},{"id":"56470","messageId":"20071019021255.GD3290@coredump.intra.peff.net","threadId":"10370","inReplyTo":"20071019004527.GA12930@spearce.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T02:12:55Z","receivedAt":"2007-10-19T02:12:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 08:45:27PM -0400, Shawn O. Pearce wrote:\n\n> Recently I was referred to the Grammar Police as the git-pack-objects\n> progress message 'Deltifying %u objects' is considered to be not\n> proper English to at least some small but vocal segment of the\n> English speaking population.  Techncially we are applying delta\n> compression to these objects at this stage, so the new term is\n> slightly more acceptable to the Grammar Police but is also just\n> as correct.\n\nBoo. I _like_ \"deltifying\". Sure, it's probably not in the dictionary,\nbut that's how languages change: saying \"delta compressing\" all the time\nwill get awkward, so people invent a new word using existing rules to\nexplain a common phenomenon.\n\nAnyway, if you want to please the Grammar Police, should it not be\n\"Delta-compressing\"?  \"Delta\" is not an adverb here, but rather the\nphrase acts as a compound verb (i.e., the two words work in place of a\nsingle verb). Although \"Delta-compressing objects\" just looks stupid.\n\n-Peff\n"},{"id":"56473","messageId":"47181430.2080907@vilain.net","threadId":"10370","inReplyTo":"20071019021255.GD3290@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-10-19T02:19:28Z","receivedAt":"2007-10-19T02:19:28Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jeff King wrote:\n> Boo. I _like_ \"deltifying\". Sure, it's probably not in the dictionary,\n> but that's how languages change: saying \"delta compressing\" all the time\n> will get awkward, so people invent a new word using existing rules to\n> explain a common phenomenon.\n\nThis is not very considerate to non-native speakers, though, who might\nnot grasp the neogolism.\n\nPerhaps just \"compressing\" if it gets awkward.\n\nSam.\n"},{"id":"56474","messageId":"20071019022154.GY14735@spearce.org","threadId":"10370","inReplyTo":"20071019021255.GD3290@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T02:21:54Z","receivedAt":"2007-10-19T02:21:54Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 18, 2007 at 08:45:27PM -0400, Shawn O. Pearce wrote:\n> \n> > Recently I was referred to the Grammar Police as the git-pack-objects\n> > progress message 'Deltifying %u objects' is considered to be not\n> > proper English to at least some small but vocal segment of the\n> > English speaking population.  Techncially we are applying delta\n> > compression to these objects at this stage, so the new term is\n> > slightly more acceptable to the Grammar Police but is also just\n> > as correct.\n> \n> Boo. I _like_ \"deltifying\". Sure, it's probably not in the dictionary,\n> but that's how languages change: saying \"delta compressing\" all the time\n> will get awkward, so people invent a new word using existing rules to\n> explain a common phenomenon.\n\nMy eyes have gotten used to \"Deltifying\" but I have to admit that\nin my early Git days I thought it looked damn odd.  Today I'm far\ntoo familiar with Git to really notice this as a problem now.\n\nI really don't have an opinion either way.  Actually I think the\nentire progress system of git-pack-objects should be reduced even\nfurther so that users aren't exposed to the internal phases we\nare going through.  Most of them just don't care.  They just\nwant to know when its going to be done[*1*].\n\n> Anyway, if you want to please the Grammar Police, should it not be\n> \"Delta-compressing\"?  \"Delta\" is not an adverb here, but rather the\n> phrase acts as a compound verb (i.e., the two words work in place of a\n> single verb). Although \"Delta-compressing objects\" just looks stupid.\n\nYea, that is just stupid.  And is why I didn't use a - in my patch.\n\n\n*1*: Yes, yes, I know that's hard to predict and impossible in\nthe really important cases (like network transfer of not yet\ncompressed data).  So just telling them that we are working and\nhave recently done something useful towards finishing our goal is\nmore than enough.  Its like putting mirrors on the wall in a lobby;\nfolks won't notice how long it takes for the elevator to arrive as\nthey are too busy preening themselves.\n\n-- \nShawn.\n"},{"id":"56475","messageId":"ee77f5c20710181924j7c538468r75f0f17968af7b01@mail.gmail.com","threadId":"10370","inReplyTo":"47181430.2080907@vilain.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-10-19T02:24:44Z","receivedAt":"2007-10-19T02:24:44Z","isPatch":true,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On 19/10/2007, Sam Vilain <sam@vilain.net> wrote:\n> Jeff King wrote:\n> > Boo. I _like_ \"deltifying\". Sure, it's probably not in the dictionary,\n> > but that's how languages change: saying \"delta compressing\" all the time\n> > will get awkward, so people invent a new word using existing rules to\n> > explain a common phenomenon.\n>\n> This is not very considerate to non-native speakers, though, who might\n> not grasp the neogolism.\n>\n> Perhaps just \"compressing\" if it gets awkward.\n\nForward thinking, that's probably most sensible, since git 4.7 might\nnot use delta compression, but maybe wavelet compression, or other\nscheme entirely. Using deltas is an implementation detail, after all.\n\n\nDave.\n"},{"id":"56476","messageId":"20071019022529.GA8298@coredump.intra.peff.net","threadId":"10370","inReplyTo":"47181430.2080907@vilain.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T02:25:29Z","receivedAt":"2007-10-19T02:25:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2007 at 03:19:28PM +1300, Sam Vilain wrote:\n\n> This is not very considerate to non-native speakers, though, who might\n> not grasp the neogolism.\n> \n> Perhaps just \"compressing\" if it gets awkward.\n\nI would have thought it would be easier for non-native speakers, since\nit has a precise meaning which I assumed we defined in a glossary (but\nnow I see that we don't, though that can be corrected). But of course,\nI'm a native speaker (and AIUI, so are you), so perhaps we should wait\nfor somebody else to comment.\n\nBut I do agree that making sense to non-native speakers should be a\npriority when phrasing things like this.\n\n-Peff\n"},{"id":"56479","messageId":"20071019023425.GB8298@coredump.intra.peff.net","threadId":"10370","inReplyTo":"20071019022154.GY14735@spearce.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T02:34:25Z","receivedAt":"2007-10-19T02:34:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 10:21:54PM -0400, Shawn O. Pearce wrote:\n\n> My eyes have gotten used to \"Deltifying\" but I have to admit that\n> in my early Git days I thought it looked damn odd.  Today I'm far\n> too familiar with Git to really notice this as a problem now.\n\nOK, I will confess I found it a little odd at first, but I think it's a\nstraightforward and playful extension of the language, which is\nsomething I like. But you know, we have the corporate git customers to\nthink about these days. ;)\n\n> I really don't have an opinion either way.  Actually I think the\n> entire progress system of git-pack-objects should be reduced even\n> further so that users aren't exposed to the internal phases we\n> are going through.  Most of them just don't care.  They just\n> want to know when its going to be done[*1*].\n\nOn a similar note, some complaints with progress meters, even after\nrecent patches:\n  - When fetching, one progress meter says \"Indexing\" which, while\n    technically true, is almost certainly blocking on \"Downloading\". In\n    fact, it is not clear from the existing messages exactly _when_ we\n    are downloading, and when we are just computing, which is something\n    I think a user might want to know. Objections to changing this\n    (though perhaps index-pack will need to be told when it is\n    downloading and when it is just indexing)? Objections to a\n    throughput indicator?\n  - Running git-gc, we now get something like:\n      Counting objects: 62317, done.\n      Deltifying objects: 100% (18042/18042), done.\n      Writing objects: 100% (62317/62317), done.\n      Total 62317 (delta 43861), reused 61404 (delta 43036)\n      Pack pack-32f8ac40c1a5ec146e45c657cb16f53fdd354095 created.\n      Removing unused objects 100%...\n      Done.\n    Can we get rid of total statistics (I think this is useful for some\n    power users, but perhaps there should be a verbosity level), the\n    name of the pack file (same deal), and the totally useless \"Done.\"?\n\n-Peff\n"},{"id":"56480","messageId":"20071019023426.GA14735@spearce.org","threadId":"10370","inReplyTo":"ee77f5c20710181924j7c538468r75f0f17968af7b01@mail.gmail.com","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T02:34:26Z","receivedAt":"2007-10-19T02:34:26Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Symonds <dsymonds@gmail.com> wrote:\n> On 19/10/2007, Sam Vilain <sam@vilain.net> wrote:\n> > Jeff King wrote:\n> > > Boo. I _like_ \"deltifying\". Sure, it's probably not in the dictionary,\n> > > but that's how languages change: saying \"delta compressing\" all the time\n> > > will get awkward, so people invent a new word using existing rules to\n> > > explain a common phenomenon.\n> >\n> > This is not very considerate to non-native speakers, though, who might\n> > not grasp the neogolism.\n> >\n> > Perhaps just \"compressing\" if it gets awkward.\n> \n> Forward thinking, that's probably most sensible, since git 4.7 might\n> not use delta compression, but maybe wavelet compression, or other\n> scheme entirely. Using deltas is an implementation detail, after all.\n\nHeh.  I just remembered that my packv4 topic had a phase it called\n\"Dictifying objects\".  Which ran before \"Deltifying objects\".  It was\njust another form of compression, but it was also timeconsuming\nand an entirely different loop so it got its own progress meter.\n\nI'm leaning to making it just say \"Compressing objects\".  Simple,\nto the point, reasonably describes the action, and most people will\nunderstand what it means: \"Oh, time to go get coffee if that number\nthere is reeeealy big...\"  :-)\n\n-- \nShawn.\n"},{"id":"56481","messageId":"20071019023645.GC8298@coredump.intra.peff.net","threadId":"10370","inReplyTo":"ee77f5c20710181924j7c538468r75f0f17968af7b01@mail.gmail.com","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T02:36:45Z","receivedAt":"2007-10-19T02:36:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2007 at 12:24:44PM +1000, David Symonds wrote:\n\n> Forward thinking, that's probably most sensible, since git 4.7 might\n> not use delta compression, but maybe wavelet compression, or other\n> scheme entirely. Using deltas is an implementation detail, after all.\n\nGit already uses two types of compression (zlib on all objects, deltas\nbetween objects in packfiles). So just saying \"compressing\" is actually\na bit ambiguous, and I think noting that what we are _actually_ doing\nright now is delta compression is worthwhile.\n\n-Peff\n"},{"id":"56483","messageId":"alpine.LFD.0.9999.0710182238470.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019021255.GD3290@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T02:45:31Z","receivedAt":"2007-10-19T02:45:31Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Jeff King wrote:\n\n> On Thu, Oct 18, 2007 at 08:45:27PM -0400, Shawn O. Pearce wrote:\n> \n> > Recently I was referred to the Grammar Police as the git-pack-objects\n> > progress message 'Deltifying %u objects' is considered to be not\n> > proper English to at least some small but vocal segment of the\n> > English speaking population.  Techncially we are applying delta\n> > compression to these objects at this stage, so the new term is\n> > slightly more acceptable to the Grammar Police but is also just\n> > as correct.\n> \n> Boo. I _like_ \"deltifying\". Sure, it's probably not in the dictionary,\n> but that's how languages change: saying \"delta compressing\" all the time\n> will get awkward, so people invent a new word using existing rules to\n> explain a common phenomenon.\n\nYet that progress display isn't solely about \"delta compressing\".  It \nalso includes the search for best object match in order to keep the \nsmallest delta possible.\n\nI'd like to add my own boo, but since I'm not a native speaker I won't \nargue too much.\n\n\nNicolas\n"},{"id":"56484","messageId":"20071019024748.GB14735@spearce.org","threadId":"10370","inReplyTo":"20071019023425.GB8298@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T02:47:48Z","receivedAt":"2007-10-19T02:47:48Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 18, 2007 at 10:21:54PM -0400, Shawn O. Pearce wrote:\n> \n> > My eyes have gotten used to \"Deltifying\" but I have to admit that\n> > in my early Git days I thought it looked damn odd.  Today I'm far\n> > too familiar with Git to really notice this as a problem now.\n> \n> OK, I will confess I found it a little odd at first, but I think it's a\n> straightforward and playful extension of the language, which is\n> something I like. But you know, we have the corporate git customers to\n> think about these days. ;)\n\nHeh.  Yeah, Git is gaining users on a daily basis.  Its good.  :)\n \n> On a similar note, some complaints with progress meters, even after\n> recent patches:\n> \n>   - When fetching, one progress meter says \"Indexing\" which, while\n>     technically true, is almost certainly blocking on \"Downloading\". In\n>     fact, it is not clear from the existing messages exactly _when_ we\n>     are downloading, and when we are just computing, which is something\n>     I think a user might want to know. Objections to changing this\n>     (though perhaps index-pack will need to be told when it is\n>     downloading and when it is just indexing)? Objections to a\n>     throughput indicator?\n\nYes!  I agree entirely.  This is actually not very difficult.\n\nI think the only time we run `git-index-pack --stdin` is from within\ngit-fetch-pack and git-receive-pack.  These are the only two points\nwhere index-pack's stdin is attached to a network socket and not\nto a file.  Its also where you'd want this to say \"Transferring\",\n\"Uploading\" or \"Downloading\".\n\nReally the important one to change here is probably the call in\nfetch-pack.c as that is the most visible and most time consuming\noperation for the average user (think git-clone on a large project).\n\nThe same change probably should also be made for unpack-objects as\nfetch-pack/receive-pack may have chosen to use that if the object\ncount is low and it wasn't instructed to keep the packfile.\n\n>   - Running git-gc, we now get something like:\n>       Counting objects: 62317, done.\n>       Deltifying objects: 100% (18042/18042), done.\n>       Writing objects: 100% (62317/62317), done.\n>       Total 62317 (delta 43861), reused 61404 (delta 43036)\n>       Pack pack-32f8ac40c1a5ec146e45c657cb16f53fdd354095 created.\n>       Removing unused objects 100%...\n>       Done.\n>     Can we get rid of total statistics (I think this is useful for some\n>     power users, but perhaps there should be a verbosity level), the\n>     name of the pack file (same deal), and the totally useless \"Done.\"?\n\nYea.  I keep forgetting to write a patch to do this.  I've had much\nthe same thought as you.\n\nThe verbosity should probably be controlled like merge-recursive's\nis, but should default to not showing the \"Total\" line or the \"Pack\n.. created\" line.  For the average user there isn't any valuable\ninformation in either line.\n\nI also think that the progress meter of git-prune-packed should be\nfixed to use the standard progress meter system.  And maybe also\nbe delayed so it doesn't trip if its going to be very quick.\n\n-- \nShawn.\n"},{"id":"56485","messageId":"alpine.LFD.0.9999.0710182247130.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019022154.GY14735@spearce.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T02:49:27Z","receivedAt":"2007-10-19T02:49:27Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Shawn O. Pearce wrote:\n\n> I really don't have an opinion either way.  Actually I think the\n> entire progress system of git-pack-objects should be reduced even\n> further so that users aren't exposed to the internal phases we\n> are going through.  Most of them just don't care.  They just\n> want to know when its going to be done[*1*].\n\nWell, with my latest patches in that area, the typical progress on \nscreen has been cut in half.  And the different phases are intertaining.\n\n\nNicolas\n"},{"id":"56487","messageId":"47181CA2.5010605@vilain.net","threadId":"10370","inReplyTo":"20071019023645.GC8298@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-10-19T02:55:30Z","receivedAt":"2007-10-19T02:55:30Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jeff King wrote:\n> On Fri, Oct 19, 2007 at 12:24:44PM +1000, David Symonds wrote:\n> \n>> Forward thinking, that's probably most sensible, since git 4.7 might\n>> not use delta compression, but maybe wavelet compression, or other\n>> scheme entirely. Using deltas is an implementation detail, after all.\n> \n> Git already uses two types of compression (zlib on all objects, deltas\n> between objects in packfiles). So just saying \"compressing\" is actually\n> a bit ambiguous, and I think noting that what we are _actually_ doing\n> right now is delta compression is worthwhile.\n\nTrue.  But then, zlib compression is also delta compressing and huffman\ncoding.  Git's delta compression is quite similar; it just uses a larger\nwindow than the sliding 64k gzip one.\n\nSam.`\n"},{"id":"56488","messageId":"20071019025913.GA9227@coredump.intra.peff.net","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182238470.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T02:59:13Z","receivedAt":"2007-10-19T02:59:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 10:45:31PM -0400, Nicolas Pitre wrote:\n\n> Yet that progress display isn't solely about \"delta compressing\".  It \n> also includes the search for best object match in order to keep the \n> smallest delta possible.\n\nIn fact, isn't that progress meter _solely_ about finding the best\nmatches? The actual deltification (that is, the creation of the deltas\nand writing of them to the packfile happens during the writing phase --\nunless, of course, we've cached the deltas during the search phase).\n\nPerhaps one of:\n\n  Finding deltas\n  Finding delta candidates\n  Matching objects\n\nor something similar (though I don't especially like any of them, I\nthink you get the idea).\n\n-Peff\n"},{"id":"56489","messageId":"alpine.LFD.0.9999.0710182251110.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019023425.GB8298@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T03:01:02Z","receivedAt":"2007-10-19T03:01:02Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Jeff King wrote:\n\n> On a similar note, some complaints with progress meters, even after\n> recent patches:\n>   - When fetching, one progress meter says \"Indexing\" which, while\n>     technically true, is almost certainly blocking on \"Downloading\". In\n>     fact, it is not clear from the existing messages exactly _when_ we\n>     are downloading, and when we are just computing, which is something\n>     I think a user might want to know. Objections to changing this\n>     (though perhaps index-pack will need to be told when it is\n>     downloading and when it is just indexing)? Objections to a\n>     throughput indicator?\n\nI have some WIP for that.\n\n>   - Running git-gc, we now get something like:\n>       Counting objects: 62317, done.\n>       Deltifying objects: 100% (18042/18042), done.\n>       Writing objects: 100% (62317/62317), done.\n>       Total 62317 (delta 43861), reused 61404 (delta 43036)\n>       Pack pack-32f8ac40c1a5ec146e45c657cb16f53fdd354095 created.\n>       Removing unused objects 100%...\n>       Done.\n>     Can we get rid of total statistics (I think this is useful for some\n>     power users, but perhaps there should be a verbosity level), the\n>     name of the pack file (same deal), and the totally useless \"Done.\"?\n\nAgreed for the pack name.  Certainly no one cares.\n\nMaybe the \"Removing unused objects\" should use the common progress \ninfrastructure?  It could even use the delayed interface, just like when \nchecking out files, so no progress at all is displayed when that \noperation completes within a certain delay.  And the removal of unused \nobjects is usually quick.\n\nBut I like the statistics.  They might be pretty handy to diagnoze \nperformance issues on remote servers for example.\n\n\nNicolas\n"},{"id":"56490","messageId":"alpine.LFD.0.9999.0710182301470.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019023426.GA14735@spearce.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T03:02:55Z","receivedAt":"2007-10-19T03:02:55Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Shawn O. Pearce wrote:\n\n> I'm leaning to making it just say \"Compressing objects\".  Simple,\n> to the point, reasonably describes the action, and most people will\n> understand what it means: \"Oh, time to go get coffee if that number\n> there is reeeealy big...\"  :-)\n\nI think this is sensible.\n\n\nNicolas\n"},{"id":"56492","messageId":"20071019030749.GA9274@coredump.intra.peff.net","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182251110.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:07:49Z","receivedAt":"2007-10-19T03:07:49Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:01:02PM -0400, Nicolas Pitre wrote:\n\n> >   - When fetching, one progress meter says \"Indexing\" which, while\n> >     technically true, is almost certainly blocking on \"Downloading\". In\n> \n> I have some WIP for that.\n\nGreat, I won't start work on it, then.\n\n> Maybe the \"Removing unused objects\" should use the common progress \n> infrastructure?  It could even use the delayed interface, just like when \n> checking out files, so no progress at all is displayed when that \n> operation completes within a certain delay.  And the removal of unused \n> objects is usually quick.\n\nAre you volunteering (I think you know the progress code best)?\nOtherwise, I will get to it, but probably not tonight.\n\n> But I like the statistics.  They might be pretty handy to diagnoze \n> performance issues on remote servers for example.\n\nThey are by far the most useful of the three lines I mentioned, but I\njust wonder if they are a bit meaningless and cluttery for light users.\nWe can always cut the others and see how it looks.\n\n-Peff\n"},{"id":"56493","messageId":"alpine.LFD.0.9999.0710182306300.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019025913.GA9227@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T03:11:26Z","receivedAt":"2007-10-19T03:11:26Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Jeff King wrote:\n\n> On Thu, Oct 18, 2007 at 10:45:31PM -0400, Nicolas Pitre wrote:\n> \n> > Yet that progress display isn't solely about \"delta compressing\".  It \n> > also includes the search for best object match in order to keep the \n> > smallest delta possible.\n> \n> In fact, isn't that progress meter _solely_ about finding the best\n> matches? The actual deltification (that is, the creation of the deltas\n> and writing of them to the packfile happens during the writing phase --\n> unless, of course, we've cached the deltas during the search phase).\n\nWell, to find which combination is the smallest you actually have to \ncreate deltas.\n\n> Perhaps one of:\n> \n>   Finding deltas\n>   Finding delta candidates\n>   Matching objects\n> \n> or something similar (though I don't especially like any of them, I\n> think you get the idea).\n\nI think we might sidestep the issue entirely by remaining somewhat vague \nand simply saying \"compressing objects\" for that phase.  This is the \npart responsible for the reduction of a Git repository from 3GB down to \n200MB anyway.\n\n\nNicolas\n"},{"id":"56494","messageId":"20071019031535.GB9274@coredump.intra.peff.net","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182306300.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:15:35Z","receivedAt":"2007-10-19T03:15:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:11:26PM -0400, Nicolas Pitre wrote:\n\n> I think we might sidestep the issue entirely by remaining somewhat vague \n> and simply saying \"compressing objects\" for that phase.  This is the \n> part responsible for the reduction of a Git repository from 3GB down to \n> 200MB anyway.\n\nOK. I liked it a little more specific, but perhaps users really don't\ncare what's going on. And it seems there is some support of simply\n\"compressing\", so that's probably reasonable.\n\nI think that is going to make the statistics line doubly confusing,\nthough, since we never even use the word \"delta\" (or any wacky\nverbifications based on it), and then they get a line about numbers of\nnew and reused deltas.\n\n-Peff\n"},{"id":"56495","messageId":"20071019031737.GD14735@spearce.org","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182247130.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T03:17:37Z","receivedAt":"2007-10-19T03:17:37Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre <nico@cam.org> wrote:\n> On Thu, 18 Oct 2007, Shawn O. Pearce wrote:\n> \n> > I really don't have an opinion either way.  Actually I think the\n> > entire progress system of git-pack-objects should be reduced even\n> > further so that users aren't exposed to the internal phases we\n> > are going through.  Most of them just don't care.  They just\n> > want to know when its going to be done[*1*].\n> \n> Well, with my latest patches in that area, the typical progress on \n> screen has been cut in half.  And the different phases are intertaining.\n\nYup.  Your patches were a big improvement.  But I'm now sitting here\nwondering if we shouldn't just allow a progress meter to overwrite\nthe prior one.  Then you only see the current task and progress,\nor the final output if we have nothing further to say about that.\n\nHmmph.  Maybe something like this:\n\nI like how it comes out in the end, but it really screws with the\nsideband protocol.  Like horribly.  I got a whole ton of \"remote:\nremote: remote: remote: remote: remote:\" during a remote clone.\n\ndiff --git a/progress.c b/progress.c\nindex 7629e05..099fc14 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -37,8 +37,6 @@ static void clear_progress_signal(void)\n \n static int display(struct progress *progress, unsigned n, int done)\n {\n-\tchar *eol;\n-\n \tif (progress->delay) {\n \t\tif (!progress_update || --progress->delay)\n \t\t\treturn 0;\n@@ -55,18 +53,26 @@ static int display(struct progress *progress, unsigned n, int done)\n \t}\n \n \tprogress->last_value = n;\n-\teol = done ? \", done.   \\n\" : \"   \\r\";\n-\tif (progress->total) {\n+\tif (done) {\n+\t\tsize_t c = strlen(progress->title);\n+\t\twhile (c--)\n+\t\t\tfputc(' ', stderr);\n+\t\tfputs(\"            \", stderr);\n+\t\tfor (; n > 0; n /= 10)\n+\t\t\tfputs(\"  \", stderr);\n+\t\tfputc('\\r', stderr);\n+\t\treturn 1;\n+\t} else if (progress->total) {\n \t\tunsigned percent = n * 100 / progress->total;\n \t\tif (percent != progress->last_percent || progress_update) {\n \t\t\tprogress->last_percent = percent;\n \t\t\tfprintf(stderr, \"%s: %3u%% (%u/%u)%s\", progress->title,\n-\t\t\t\tpercent, n, progress->total, eol);\n+\t\t\t\tpercent, n, progress->total, \"   \\r\");\n \t\t\tprogress_update = 0;\n \t\t\treturn 1;\n \t\t}\n \t} else if (progress_update) {\n-\t\tfprintf(stderr, \"%s: %u%s\", progress->title, n, eol);\n+\t\tfprintf(stderr, \"%s: %u%s\", progress->title, n, \"   \\r\");\n \t\tprogress_update = 0;\n \t\treturn 1;\n \t}\n\n-- \nShawn.\n"},{"id":"56498","messageId":"alpine.LFD.0.9999.0710182312160.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019030749.GA9274@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T03:24:41Z","receivedAt":"2007-10-19T03:24:41Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Jeff King wrote:\n\n> On Thu, Oct 18, 2007 at 11:01:02PM -0400, Nicolas Pitre wrote:\n> \n> > Maybe the \"Removing unused objects\" should use the common progress \n> > infrastructure?  It could even use the delayed interface, just like when \n> > checking out files, so no progress at all is displayed when that \n> > operation completes within a certain delay.  And the removal of unused \n> > objects is usually quick.\n> \n> Are you volunteering (I think you know the progress code best)?\n> Otherwise, I will get to it, but probably not tonight.\n\nIf I do it that won't be today either.\n\n> > But I like the statistics.  They might be pretty handy to diagnoze \n> > performance issues on remote servers for example.\n> \n> They are by far the most useful of the three lines I mentioned, but I\n> just wonder if they are a bit meaningless and cluttery for light users.\n> We can always cut the others and see how it looks.\n\nFrankly, I think effort should be spent on the refs update display at \nthis point.  Something that looks like:\n\n* refs/heads/origin: fast forward to branch 'master' of git://gi\nt.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n  old..new: 66ffb04..4fa4d23\n\n[ note that I arbitrarily cut the long line before the 80th column to \n  show the effect within an email ]\n\nYou usually get long lines that gets wrapped, so that means 3 lines of \nscreen space for one updated branches.  Is the \"66ffb04..4fa4d23\" \ninformation really useful?  Might someone ever care?\n\n\nNicolas\n"},{"id":"56500","messageId":"alpine.LFD.0.9999.0710182325300.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019031535.GB9274@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T03:27:53Z","receivedAt":"2007-10-19T03:27:53Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Jeff King wrote:\n\n> On Thu, Oct 18, 2007 at 11:11:26PM -0400, Nicolas Pitre wrote:\n> \n> > I think we might sidestep the issue entirely by remaining somewhat vague \n> > and simply saying \"compressing objects\" for that phase.  This is the \n> > part responsible for the reduction of a Git repository from 3GB down to \n> > 200MB anyway.\n> \n> OK. I liked it a little more specific, but perhaps users really don't\n> care what's going on. And it seems there is some support of simply\n> \"compressing\", so that's probably reasonable.\n> \n> I think that is going to make the statistics line doubly confusing,\n> though, since we never even use the word \"delta\" (or any wacky\n> verbifications based on it), and then they get a line about numbers of\n> new and reused deltas.\n\nWell, at least the statistics are real, and we're not inventing anything \nhere.\n\n\nNicolas\n"},{"id":"56501","messageId":"20071019033228.GA10697@coredump.intra.peff.net","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182312160.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:32:28Z","receivedAt":"2007-10-19T03:32:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:24:41PM -0400, Nicolas Pitre wrote:\n\n> Frankly, I think effort should be spent on the refs update display at \n> this point.  Something that looks like:\n\nAlso agreed.\n\n> * refs/heads/origin: fast forward to branch 'master' of git://gi\n> t.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n>   old..new: 66ffb04..4fa4d23\n>\n> [...]\n>\n> You usually get long lines that gets wrapped, so that means 3 lines of \n> screen space for one updated branches.  Is the \"66ffb04..4fa4d23\" \n> information really useful?  Might someone ever care?\n\nI have used it occasionally when tracking repos to see what new commits\nhave happened. Usually I use a separate branch to mark \"what I've seen\"\n(i.e., fetch, gitk origin..master, pull), but if it's a branch that I'm\nnot actively tracking, the display is useful.\n\nWhat is really useless in that line is the fact that _every_ ref is\ngoing to have the name of the remote, even though we only support\nfetching from one remote at a time. Perhaps something like:\n\nFetching from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n * refs/heads/origin: fast forward to branch 'master'\n\nalthough that URL is almost a line by itself. :)\n\nAlso, why do we abbreviate \"refs/heads/master\" from the remote, but we\ndon't abbreviate refs/heads/origin for the local? Maybe something like:\n\n  * local heads/origin -> remote heads/master (fast forward)\n\nor for separate remote\n\n  * local remotes/origin/master -> remote heads/master (fast forward)\n\nThoughts?\n\n-Peff\n"},{"id":"56502","messageId":"20071019033327.GF14735@spearce.org","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182312160.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T03:33:27Z","receivedAt":"2007-10-19T03:33:27Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre <nico@cam.org> wrote:\n> Frankly, I think effort should be spent on the refs update display at \n> this point.  Something that looks like:\n> \n> * refs/heads/origin: fast forward to branch 'master' of git://gi\n> t.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n>   old..new: 66ffb04..4fa4d23\n> \n> [ note that I arbitrarily cut the long line before the 80th column to \n>   show the effect within an email ]\n> \n> You usually get long lines that gets wrapped, so that means 3 lines of \n> screen space for one updated branches.  Is the \"66ffb04..4fa4d23\" \n> information really useful?  Might someone ever care?\n\nThe reason its formatted the way it is today is someone can grab\nthat line into a copy-paste buffer and throw it onto a \"git-log\"\nor \"gitk\" command line with ease to see what new stuff has come in.\n\nMe, I just use the reflog if I care (`origin@{1}..origin`) to see\nwhat a fetch changed in the tracking branch.\n\nHowever I *don't* need the remote branch name or the remote URL,\nespecially if we are storing it into a tracking branch.  That's most\nlikely coming from a configured remote that the user fetches from\nfrequently.  I don't think about Linus' URL, I think about the fact\nthat in my linux-2.6 repository his directory is my origin remote.\n\nMaybe something like this would be more useful:\n\n * origin: fast-forwarded: 66ffb04..4fa4d23\n\nOr if you are using refs/remotes style tracking branches:\n\n * origin/master: fast-forwarded: 66ffb04..4fa4d23\n * origin/pu: forcing update: 66ffb04..4fa4d23\n\nToo terse?  Yea, probably.  But it is a whole lot shorter.\n\n\nMy other pet peeve here is the display from send-pack and\nreceive-pack when you push a ref.  Hello?\n\n  updating 'refs/heads/master'\n    from de61e42b539ffbd28d2a2ba827bb0eb79767057b\n    to   d7e56dbc4f60f6bd238e8612783541d89f006fb7\n  ...\n  refs/heads/master: de61e42b539ffbd28d2a2ba827bb0eb79767057b -> d7e56dbc4f60f6bd238e8612783541d89f006fb7\n\nThat's like 4 too many SHA-1 strings for the average user.\n\n-- \nShawn.\n"},{"id":"56504","messageId":"alpine.LFD.0.9999.0710182328580.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019031737.GD14735@spearce.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T03:38:59Z","receivedAt":"2007-10-19T03:38:59Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Shawn O. Pearce wrote:\n\n> Nicolas Pitre <nico@cam.org> wrote:\n> > On Thu, 18 Oct 2007, Shawn O. Pearce wrote:\n> > \n> > > I really don't have an opinion either way.  Actually I think the\n> > > entire progress system of git-pack-objects should be reduced even\n> > > further so that users aren't exposed to the internal phases we\n> > > are going through.  Most of them just don't care.  They just\n> > > want to know when its going to be done[*1*].\n> > \n> > Well, with my latest patches in that area, the typical progress on \n> > screen has been cut in half.  And the different phases are intertaining.\n> \n> Yup.  Your patches were a big improvement.  But I'm now sitting here\n> wondering if we shouldn't just allow a progress meter to overwrite\n> the prior one.  Then you only see the current task and progress,\n> or the final output if we have nothing further to say about that.\n\nAnd then you've lost some diagnostic clue (the absolute numbers) about \nthe actual number of objects that were listed for \"deltification\" for \nexample.\n\nAnd imagine that you see the progress moving slowly because the remote \nserver is a NSLU2, but it says 80%.  Then you go for a coffee and the \nprogress says 20% when you return because it now has moved to a \ndifferent phase.  Rather counter intuitive.\n\n\nNicolas\n"},{"id":"56506","messageId":"20071019034124.GA11095@coredump.intra.peff.net","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182328580.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:41:24Z","receivedAt":"2007-10-19T03:41:24Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:38:59PM -0400, Nicolas Pitre wrote:\n\n> > Yup.  Your patches were a big improvement.  But I'm now sitting here\n> > wondering if we shouldn't just allow a progress meter to overwrite\n> > the prior one.  Then you only see the current task and progress,\n> > or the final output if we have nothing further to say about that.\n> \n> And then you've lost some diagnostic clue (the absolute numbers) about \n> the actual number of objects that were listed for \"deltification\" for \n> example.\n> \n> And imagine that you see the progress moving slowly because the remote \n> server is a NSLU2, but it says 80%.  Then you go for a coffee and the \n> progress says 20% when you return because it now has moved to a \n> different phase.  Rather counter intuitive.\n\nObligatory me too: I totally agree with Nicolas here.\n\n-Peff\n"},{"id":"56507","messageId":"20071019034501.GG14735@spearce.org","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182328580.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T03:45:01Z","receivedAt":"2007-10-19T03:45:01Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre <nico@cam.org> wrote:\n> On Thu, 18 Oct 2007, Shawn O. Pearce wrote:\n> > Yup.  Your patches were a big improvement.  But I'm now sitting here\n> > wondering if we shouldn't just allow a progress meter to overwrite\n> > the prior one.  Then you only see the current task and progress,\n> > or the final output if we have nothing further to say about that.\n> \n> And then you've lost some diagnostic clue (the absolute numbers) about \n> the actual number of objects that were listed for \"deltification\" for \n> example.\n\nLeave the \"Total\" line.  Add to it the number of objects we had to\nconsider for deltification as part of the packing.\n \n> And imagine that you see the progress moving slowly because the remote \n> server is a NSLU2, but it says 80%.  Then you go for a coffee and the \n> progress says 20% when you return because it now has moved to a \n> different phase.  Rather counter intuitive.\n\nYea, I didn't consider that.  That's where you need to show the\nnumber of steps and which one you are on, so the meter looks\nmore like:\n\n\tStep 1/3: Counting objects: .... \\r\n\tStep 2/4: Compressing objects: ... \\r\n\tStep 3/3: Writing objects: .... \\r\n\nonly all smashed into one line of course, so only the most recent\none is being displayed.\n\n-- \nShawn.\n"},{"id":"56509","messageId":"alpine.LFD.0.9999.0710182340550.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019033228.GA10697@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T03:50:39Z","receivedAt":"2007-10-19T03:50:39Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Jeff King wrote:\n\n> On Thu, Oct 18, 2007 at 11:24:41PM -0400, Nicolas Pitre wrote:\n> \n> > You usually get long lines that gets wrapped, so that means 3 lines of \n> > screen space for one updated branches.  Is the \"66ffb04..4fa4d23\" \n> > information really useful?  Might someone ever care?\n> \n> I have used it occasionally when tracking repos to see what new commits\n> have happened. Usually I use a separate branch to mark \"what I've seen\"\n> (i.e., fetch, gitk origin..master, pull), but if it's a branch that I'm\n> not actively tracking, the display is useful.\n\nMaybe we should have a shortcut notation for <ref>@{1}..<ref> instead?\nI end up using that all the time since the fetch result has long \nscrolled off the screen when I want to look at what was fetched.\n\nUsully this llooks like:\n\n\tgit pull\n\tgit log @{1}..\n\nBut using origin/master@{1}..origin/master is a bit cumbersome.\n\n> What is really useless in that line is the fact that _every_ ref is\n> going to have the name of the remote, even though we only support\n> fetching from one remote at a time. Perhaps something like:\n> \n> Fetching from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n>  * refs/heads/origin: fast forward to branch 'master'\n> \n> although that URL is almost a line by itself. :)\n\nIt is, therefore I'd skip \"Fetching from \" entirely.\n\n> Also, why do we abbreviate \"refs/heads/master\" from the remote, but we\n> don't abbreviate refs/heads/origin for the local? Maybe something like:\n> \n>   * local heads/origin -> remote heads/master (fast forward)\n> \n> or for separate remote\n> \n>   * local remotes/origin/master -> remote heads/master (fast forward)\n\nThat looks fine for a push.  I'd say \"remote foo -> local bar\" for a \nfetch.\n\n\nNicolas\n"},{"id":"56511","messageId":"20071019035647.GA18717@coredump.intra.peff.net","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182340550.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:56:47Z","receivedAt":"2007-10-19T03:56:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:50:39PM -0400, Nicolas Pitre wrote:\n\n> Maybe we should have a shortcut notation for <ref>@{1}..<ref> instead?\n> I end up using that all the time since the fetch result has long \n> scrolled off the screen when I want to look at what was fetched.\n\nI must confess to never using reflogs in that case...for some reason\nthey just never come to mind. But now that you and Shawn mention them,\nthere's really no reason to leave the hash..hash for the fetch.\n\nAs for a shortcut notation, what about allowing '..' notation inside a\nreflog. I.e., <ref>@{a..b} is the same as <ref>@{a}..<ref>@{b}? So you\ncould perhaps do origin/master@{1..}?\n\nI'm not sure if there are syntactic issues with parsing out the '..' (or\n'...') operator.\n\n> > although that URL is almost a line by itself. :)\n> It is, therefore I'd skip \"Fetching from \" entirely.\n\nYes, I was tempted to suggest that. I think it might need some context,\ndepending on what comes right before it.\n\n> That looks fine for a push.  I'd say \"remote foo -> local bar\" for a \n> fetch.\n\nAgreed.\n\n-Peff\n"},{"id":"56513","messageId":"alpine.LFD.0.9999.0710182354300.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019034501.GG14735@spearce.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T04:02:13Z","receivedAt":"2007-10-19T04:02:13Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Shawn O. Pearce wrote:\n\n> Nicolas Pitre <nico@cam.org> wrote:\n> > And imagine that you see the progress moving slowly because the remote \n> > server is a NSLU2, but it says 80%.  Then you go for a coffee and the \n> > progress says 20% when you return because it now has moved to a \n> > different phase.  Rather counter intuitive.\n> \n> Yea, I didn't consider that.  That's where you need to show the\n> number of steps and which one you are on, so the meter looks\n> more like:\n> \n> \tStep 1/3: Counting objects: .... \\r\n> \tStep 2/4: Compressing objects: ... \\r\n> \tStep 3/3: Writing objects: .... \\r\n> \n> only all smashed into one line of course, so only the most recent\n> one is being displayed.\n\nYet you might not know in advance how many steps there'll be.  You might \nor might not have the deltification phase (I simply can't let that term \ngo...), pack indexing also have 1 or 2 steps, and if objects are \nunpacked instead then you have only one step.\n\nGiven the asynchronous nature of the sideband messages, I think that \ncould only create messed up displays.  Some messages are terminated with \n\\n and others with \\r.\n\n\nNicolas\n"},{"id":"56515","messageId":"alpine.LFD.0.999.0710182111030.26902@woody.linux-foundation.org","threadId":"10370","inReplyTo":"20071019035647.GA18717@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-19T04:21:55Z","receivedAt":"2007-10-19T04:21:55Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 18 Oct 2007, Jeff King wrote:\n> \n> As for a shortcut notation, what about allowing '..' notation inside a\n> reflog. I.e., <ref>@{a..b} is the same as <ref>@{a}..<ref>@{b}? So you\n> could perhaps do origin/master@{1..}?\n\nI'd love it, but the way our current SHA1 parser works, I don't think it \ncan really do it.\n\nBasically, we currently assume that a SHA1 expression always expands to a \n*single* SHA1.\n\nAnd then, on top of that SHA1 expression parser, we then have a totally \nseparate logic (which is *not* part of the SHA1 expression parser itself) \nthat handles the \"a..b\" and \"a...b\" cases.\n\nIn other words, all the magic \"head@{xyz}\" logic is all in sha1_name.c, \nbut that never handles any ranges at all.\n\nAnd then the range handling is a separate thing in revision.c and \nbuiltin-rev-parse.c.\n\nSo I think your syntax is wonderful, but it would require moving the \ncomplex range handling into sha1_name.c, and would also require that file \nto get a more complex interface (right now all the sha1_name.c routines \njust take the \"fill in this one SHA1 hash\" approach, but \"..\" and \"...\" \nmeans that you have multiple objects *and* you can mark one of them as \nbeing \"negated\" etc..)\n\n> I'm not sure if there are syntactic issues with parsing out the '..' (or\n> '...') operator.\n\nSee above: I don't think we have syntax problems per se: it's just that \nright now the \"complex\" parser (the one that knows about ^, ~, and @{x} \netc) simply cannot do anything but a single SHA1 due to internal interface \nissues.\n\n\t\tLinus\n"},{"id":"56516","messageId":"20071019042930.GA16487@coredump.intra.peff.net","threadId":"10370","inReplyTo":"alpine.LFD.0.999.0710182111030.26902@woody.linux-foundation.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T04:29:30Z","receivedAt":"2007-10-19T04:29:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 09:21:55PM -0700, Linus Torvalds wrote:\n\n> I'd love it, but the way our current SHA1 parser works, I don't think it \n> can really do it.\n> \n> Basically, we currently assume that a SHA1 expression always expands to a \n> *single* SHA1.\n\nAh, right. I hadn't thought of that. While it would be a nice\nconvenience feature, it's probably not worth the deep internal hackery\nthat would be required.\n\n-Peff\n"},{"id":"56519","messageId":"20071019050335.GA17222@spearce.org","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182251110.19446@xanadu.home","subject":"[PATCH] Stop displaying \"Pack pack-$ID created.\" during git-gc","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T05:03:35Z","receivedAt":"2007-10-19T05:03:35Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Discussion on the list tonight came to the conclusion that showing\nthe name of the packfile we just created during git-repack is not\na very useful message for any end-user.  For the really technical\nfolk who need to have the name of the newest packfile they can use\nsomething such as `ls -t .git/objects/pack | head -2` to find the\nmost recently created packfile.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n\n Nicolas Pitre <nico@cam.org> wrote:\n > On Thu, 18 Oct 2007, Jeff King wrote:\n > >     Can we get rid of total statistics (I think this is useful for some\n > >     power users, but perhaps there should be a verbosity level), the\n > >     name of the pack file (same deal), and the totally useless \"Done.\"?\n >\n > Agreed for the pack name.  Certainly no one cares.\n\n This makes it so.\n\n git-repack.sh |    3 ---\n 1 files changed, 0 insertions(+), 3 deletions(-)\n\ndiff --git a/git-repack.sh b/git-repack.sh\nindex e72adc4..7220635 100755\n--- a/git-repack.sh\n+++ b/git-repack.sh\n@@ -83,9 +83,6 @@ for name in $names ; do\n \tfullbases=\"$fullbases pack-$name\"\n \tchmod a-w \"$PACKTMP-$name.pack\"\n \tchmod a-w \"$PACKTMP-$name.idx\"\n-\tif test \"$quiet\" != '-q'; then\n-\t    echo \"Pack pack-$name created.\"\n-\tfi\n \tmkdir -p \"$PACKDIR\" || exit\n \n \tfor sfx in pack idx\n-- \n1.5.3.4.1249.g895be\n"},{"id":"56520","messageId":"20071019050940.GH14735@spearce.org","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710182340550.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T05:09:40Z","receivedAt":"2007-10-19T05:09:40Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre <nico@cam.org> wrote:\n> On Thu, 18 Oct 2007, Jeff King wrote:\n> > Also, why do we abbreviate \"refs/heads/master\" from the remote, but we\n> > don't abbreviate refs/heads/origin for the local? Maybe something like:\n> > \n> >   * local heads/origin -> remote heads/master (fast forward)\n> > \n> > or for separate remote\n> > \n> >   * local remotes/origin/master -> remote heads/master (fast forward)\n> \n> That looks fine for a push.  I'd say \"remote foo -> local bar\" for a \n> fetch.\n\nThe fetch side is easy to change on top of the db/fetch-pack series\nthat is currently in next.\n\nWhat's hard is the remote side.  receive-pack on the remote side\ndoesn't have the local's refname but it prints its own message upon\na successful update.\n\n-- \nShawn.\n"},{"id":"56561","messageId":"B51EC920-D767-4192-AB25-685201B93CC9@wincent.com","threadId":"10370","inReplyTo":"20071019034501.GG14735@spearce.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-19T11:44:56Z","receivedAt":"2007-10-19T11:44:56Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 19/10/2007, a las 5:45, Shawn O. Pearce escribió:\n\n> Nicolas Pitre <nico@cam.org> wrote:\n>>\n>> And imagine that you see the progress moving slowly because the  \n>> remote\n>> server is a NSLU2, but it says 80%.  Then you go for a coffee and the\n>> progress says 20% when you return because it now has moved to a\n>> different phase.  Rather counter intuitive.\n>\n> Yea, I didn't consider that.  That's where you need to show the\n> number of steps and which one you are on, so the meter looks\n> more like:\n>\n> \tStep 1/3: Counting objects: .... \\r\n> \tStep 2/4: Compressing objects: ... \\r\n> \tStep 3/3: Writing objects: .... \\r\n>\n> only all smashed into one line of course, so only the most recent\n> one is being displayed.\n\nLooks good, although as Nicholas pointed out you might not know in  \nadvanced how many steps there are.\n\nSo I still think that Nicholas' original point is valid is here, and  \nif you overwrite old progress bars with new ones then you may falsely  \ngive the impression of \"going backwards\".\n\nCheers,\nWincent\n"},{"id":"56562","messageId":"alpine.LFD.0.9999.0710190753040.19446@xanadu.home","threadId":"10370","inReplyTo":"20071019042930.GA16487@coredump.intra.peff.net","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T11:58:51Z","receivedAt":"2007-10-19T11:58:51Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Jeff King wrote:\n\n> On Thu, Oct 18, 2007 at 09:21:55PM -0700, Linus Torvalds wrote:\n> \n> > I'd love it, but the way our current SHA1 parser works, I don't think it \n> > can really do it.\n> > \n> > Basically, we currently assume that a SHA1 expression always expands to a \n> > *single* SHA1.\n> \n> Ah, right. I hadn't thought of that. While it would be a nice\n> convenience feature, it's probably not worth the deep internal hackery\n> that would be required.\n\nWhat about a preprocessor that could match <1>@{<2>..<3>} in the \nargument list and substitute that with <1>@{<2>}..<1>@{<3>} before it is \nactually parsed?\n\n\nNicolas\n"},{"id":"56610","messageId":"alpine.LFD.0.999.0710191157560.26902@woody.linux-foundation.org","threadId":"10370","inReplyTo":"alpine.LFD.0.9999.0710190753040.19446@xanadu.home","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-19T19:00:15Z","receivedAt":"2007-10-19T19:00:15Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 19 Oct 2007, Nicolas Pitre wrote:\n> On Fri, 19 Oct 2007, Jeff King wrote:\n> > \n> > Ah, right. I hadn't thought of that. While it would be a nice\n> > convenience feature, it's probably not worth the deep internal hackery\n> > that would be required.\n> \n> What about a preprocessor that could match <1>@{<2>..<3>} in the \n> argument list and substitute that with <1>@{<2>}..<1>@{<3>} before it is \n> actually parsed?\n\nCould be done, but I almost think it would be better to just make the \nsha1_name.c interfaces take some extended data structure which allows \nlooking up multiple SHA1's at the same time.\n\nSure, we'd leave the \"simple\" interfaces around for users that simply want \njust one SHA1 value, but that would allow us to remove duplicate code from \nrevision.c and rev-parse.c. And it would allow us to generally make the \nSHA1 parsing fancier: there may well be other expressions that are worth \ndoing.\n\n\t\tLinus\n"},{"id":"56638","messageId":"alpine.LFD.0.999.0710191446440.26902@woody.linux-foundation.org","threadId":"10370","inReplyTo":"alpine.LFD.0.999.0710191157560.26902@woody.linux-foundation.org","subject":"Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-19T21:57:26Z","receivedAt":"2007-10-19T21:57:26Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 19 Oct 2007, Linus Torvalds wrote:\n> \n> Could be done, but I almost think it would be better to just make the \n> sha1_name.c interfaces take some extended data structure which allows \n> looking up multiple SHA1's at the same time.\n\nBtw, I knew I had wanted this in the past, but I had forgotten why. I now \nremembered.\n\nThe thing is, sometimes you want an expression for \"all the parents of X\". \nWe don't have that, and again, the current internal implementation of \nsha1_name.c makes it essentially impossible to do within that interface \n(ie you can do it on *top* of that interface in revision.c, but it cannot \nbe a general SHA1 expression).\n\nSo wouldn't it be nice to have a \"commit^*\" expression to go with \n\"commit^\" and \"commit^2\" etc? One that would name all the parents. It's \nuseful, for example, for saying that you still want to see that commit, \nbut not any of its parents:\n\n\tgit log commit^*..\n\ncould basically work to show that commit (and all subsequent commits), but \nnot the commits leading up to it. Right now, you can't easily say that in \nthe git \"sha1 expression algebra\".\n\nThere are some other cases where you'd like to have things expand to more \nthan one commit. We currently do those with special flags, like --all, but \nin many ways it would be really nice to be able to do SHA1 operations on \nthem. If we were to make the SHA1 arithmetic able to handle multiple \nSHA1's (instead of just one), I could see us being able to do things like\n\n\tgit diff {master,pu}:Makefile\n\nas a way of saying\n\n\tgit diff master:Makefile pu:Makefile\n\nwhich already works - simply because we could make the \":name\" be able to \noperate on multiple commit SHA1's and turn them into multiple blob (or \ntree) SHA1's.\n\n(The above may not sound very useful, but\n\n\tgit diff {ORIG_HEAD...MERGE_HEAD}:file\n\nwould essentially expand to \"base version of file\", ORIG_HEAD:file and \nMERGE_HEAD:file, and we could fairly easily teach diff to do a nice \nthree-way diff for things like this! So it does have potential to be a \nreasonably powerful model)\n\n\t\t\tLinus\n"}]}