* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 3:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710182328580.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
> > Yup. Your patches were a big improvement. But I'm now sitting here
> > wondering if we shouldn't just allow a progress meter to overwrite
> > the prior one. Then you only see the current task and progress,
> > or the final output if we have nothing further to say about that.
>
> And then you've lost some diagnostic clue (the absolute numbers) about
> the actual number of objects that were listed for "deltification" for
> example.
Leave the "Total" line. Add to it the number of objects we had to
consider for deltification as part of the packing.
> And imagine that you see the progress moving slowly because the remote
> server is a NSLU2, but it says 80%. Then you go for a coffee and the
> progress says 20% when you return because it now has moved to a
> different phase. Rather counter intuitive.
Yea, I didn't consider that. That's where you need to show the
number of steps and which one you are on, so the meter looks
more like:
Step 1/3: Counting objects: .... \r
Step 2/4: Compressing objects: ... \r
Step 3/3: Writing objects: .... \r
only all smashed into one line of course, so only the most recent
one is being displayed.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 3:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710182328580.19446@xanadu.home>
On Thu, Oct 18, 2007 at 11:38:59PM -0400, Nicolas Pitre wrote:
> > Yup. Your patches were a big improvement. But I'm now sitting here
> > wondering if we shouldn't just allow a progress meter to overwrite
> > the prior one. Then you only see the current task and progress,
> > or the final output if we have nothing further to say about that.
>
> And then you've lost some diagnostic clue (the absolute numbers) about
> the actual number of objects that were listed for "deltification" for
> example.
>
> And imagine that you see the progress moving slowly because the remote
> server is a NSLU2, but it says 80%. Then you go for a coffee and the
> progress says 20% when you return because it now has moved to a
> different phase. Rather counter intuitive.
Obligatory me too: I totally agree with Nicolas here.
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 3:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071019033500.GB10697@coredump.intra.peff.net>
On 18 Oct 2007, at 11:35:00 PM, Jeff King wrote:
> Right, I mean regular "mv", not "git-mv". The only thing that doesn't
> accomplish is moving the "from" entry in the index to the "to" entry
> (but I'm not sure that's such a good idea). Perhaps I've lost
> sight of
> your original goal. Can you state more succintly what you are
> trying to
> accomplish?
I think you're right.
Anyway, succinctly:
> What you want to happen is the following:
>
> git show HEAD:A.txt > path/B.txt
> git add path/B.txt
> mv A.txt B.txt
> git rm A.txt
Better:
> mv A.txt path/B.txt
> Point the index entry for A.txt to path/B.txt
I hope that's right.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 3:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git
In-Reply-To: <20071019031737.GD14735@spearce.org>
On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
> >
> > > I really don't have an opinion either way. Actually I think the
> > > entire progress system of git-pack-objects should be reduced even
> > > further so that users aren't exposed to the internal phases we
> > > are going through. Most of them just don't care. They just
> > > want to know when its going to be done[*1*].
> >
> > Well, with my latest patches in that area, the typical progress on
> > screen has been cut in half. And the different phases are intertaining.
>
> Yup. Your patches were a big improvement. But I'm now sitting here
> wondering if we shouldn't just allow a progress meter to overwrite
> the prior one. Then you only see the current task and progress,
> or the final output if we have nothing further to say about that.
And then you've lost some diagnostic clue (the absolute numbers) about
the actual number of objects that were listed for "deltification" for
example.
And imagine that you see the progress moving slowly because the remote
server is a NSLU2, but it says 80%. Then you go for a coffee and the
progress says 20% when you return because it now has moved to a
different phase. Rather counter intuitive.
Nicolas
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Jeff King @ 2007-10-19 3:35 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <7E3647F4-E61C-4FBE-9AA7-81CDBE324308@MIT.EDU>
On Thu, Oct 18, 2007 at 11:26:32PM -0400, Michael Witten wrote:
>>> touch the working tree". Here we want to touch the working tree
>>> in the sense of moving the file. So --cached is not the correct
>>> option name.
>>
>> Doesn't "mv" do that?
>
> We only want to move it, not also add its dirty contents.
Right, I mean regular "mv", not "git-mv". The only thing that doesn't
accomplish is moving the "from" entry in the index to the "to" entry
(but I'm not sure that's such a good idea). Perhaps I've lost sight of
your original goal. Can you state more succintly what you are trying to
accomplish?
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 3:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710182312160.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> Frankly, I think effort should be spent on the refs update display at
> this point. Something that looks like:
>
> * refs/heads/origin: fast forward to branch 'master' of git://gi
> t.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> old..new: 66ffb04..4fa4d23
>
> [ note that I arbitrarily cut the long line before the 80th column to
> show the effect within an email ]
>
> You usually get long lines that gets wrapped, so that means 3 lines of
> screen space for one updated branches. Is the "66ffb04..4fa4d23"
> information really useful? Might someone ever care?
The reason its formatted the way it is today is someone can grab
that line into a copy-paste buffer and throw it onto a "git-log"
or "gitk" command line with ease to see what new stuff has come in.
Me, I just use the reflog if I care (`origin@{1}..origin`) to see
what a fetch changed in the tracking branch.
However I *don't* need the remote branch name or the remote URL,
especially if we are storing it into a tracking branch. That's most
likely coming from a configured remote that the user fetches from
frequently. I don't think about Linus' URL, I think about the fact
that in my linux-2.6 repository his directory is my origin remote.
Maybe something like this would be more useful:
* origin: fast-forwarded: 66ffb04..4fa4d23
Or if you are using refs/remotes style tracking branches:
* origin/master: fast-forwarded: 66ffb04..4fa4d23
* origin/pu: forcing update: 66ffb04..4fa4d23
Too terse? Yea, probably. But it is a whole lot shorter.
My other pet peeve here is the display from send-pack and
receive-pack when you push a ref. Hello?
updating 'refs/heads/master'
from de61e42b539ffbd28d2a2ba827bb0eb79767057b
to d7e56dbc4f60f6bd238e8612783541d89f006fb7
...
refs/heads/master: de61e42b539ffbd28d2a2ba827bb0eb79767057b -> d7e56dbc4f60f6bd238e8612783541d89f006fb7
That's like 4 too many SHA-1 strings for the average user.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 3:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710182312160.19446@xanadu.home>
On Thu, Oct 18, 2007 at 11:24:41PM -0400, Nicolas Pitre wrote:
> Frankly, I think effort should be spent on the refs update display at
> this point. Something that looks like:
Also agreed.
> * refs/heads/origin: fast forward to branch 'master' of git://gi
> t.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> old..new: 66ffb04..4fa4d23
>
> [...]
>
> You usually get long lines that gets wrapped, so that means 3 lines of
> screen space for one updated branches. Is the "66ffb04..4fa4d23"
> information really useful? Might someone ever care?
I have used it occasionally when tracking repos to see what new commits
have happened. Usually I use a separate branch to mark "what I've seen"
(i.e., fetch, gitk origin..master, pull), but if it's a branch that I'm
not actively tracking, the display is useful.
What is really useless in that line is the fact that _every_ ref is
going to have the name of the remote, even though we only support
fetching from one remote at a time. Perhaps something like:
Fetching from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
* refs/heads/origin: fast forward to branch 'master'
although that URL is almost a line by itself. :)
Also, why do we abbreviate "refs/heads/master" from the remote, but we
don't abbreviate refs/heads/origin for the local? Maybe something like:
* local heads/origin -> remote heads/master (fast forward)
or for separate remote
* local remotes/origin/master -> remote heads/master (fast forward)
Thoughts?
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 3:27 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019031535.GB9274@coredump.intra.peff.net>
On Thu, 18 Oct 2007, Jeff King wrote:
> On Thu, Oct 18, 2007 at 11:11:26PM -0400, Nicolas Pitre wrote:
>
> > I think we might sidestep the issue entirely by remaining somewhat vague
> > and simply saying "compressing objects" for that phase. This is the
> > part responsible for the reduction of a Git repository from 3GB down to
> > 200MB anyway.
>
> OK. I liked it a little more specific, but perhaps users really don't
> care what's going on. And it seems there is some support of simply
> "compressing", so that's probably reasonable.
>
> I think that is going to make the statistics line doubly confusing,
> though, since we never even use the word "delta" (or any wacky
> verbifications based on it), and then they get a line about numbers of
> new and reused deltas.
Well, at least the statistics are real, and we're not inventing anything
here.
Nicolas
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 3:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071019032407.GA10622@coredump.intra.peff.net>
On 18 Oct 2007, at 11:24:07 PM, Jeff King wrote:
> On Thu, Oct 18, 2007 at 11:19:59PM -0400, Shawn O. Pearce wrote:
>
>> touch the working tree". Here we want to touch the working tree
>> in the sense of moving the file. So --cached is not the correct
>> option name.
>
> Doesn't "mv" do that?
We only want to move it, not also add its dirty contents.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 3:24 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019030749.GA9274@coredump.intra.peff.net>
On Thu, 18 Oct 2007, Jeff King wrote:
> On Thu, Oct 18, 2007 at 11:01:02PM -0400, Nicolas Pitre wrote:
>
> > Maybe the "Removing unused objects" should use the common progress
> > infrastructure? It could even use the delayed interface, just like when
> > checking out files, so no progress at all is displayed when that
> > operation completes within a certain delay. And the removal of unused
> > objects is usually quick.
>
> Are you volunteering (I think you know the progress code best)?
> Otherwise, I will get to it, but probably not tonight.
If I do it that won't be today either.
> > But I like the statistics. They might be pretty handy to diagnoze
> > performance issues on remote servers for example.
>
> They are by far the most useful of the three lines I mentioned, but I
> just wonder if they are a bit meaningless and cluttery for light users.
> We can always cut the others and see how it looks.
Frankly, I think effort should be spent on the refs update display at
this point. Something that looks like:
* refs/heads/origin: fast forward to branch 'master' of git://gi
t.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
old..new: 66ffb04..4fa4d23
[ note that I arbitrarily cut the long line before the 80th column to
show the effect within an email ]
You usually get long lines that gets wrapped, so that means 3 lines of
screen space for one updated branches. Is the "66ffb04..4fa4d23"
information really useful? Might someone ever care?
Nicolas
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Jeff King @ 2007-10-19 3:24 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michael Witten, git
In-Reply-To: <20071019031959.GE14735@spearce.org>
On Thu, Oct 18, 2007 at 11:19:59PM -0400, Shawn O. Pearce wrote:
> touch the working tree". Here we want to touch the working tree
> in the sense of moving the file. So --cached is not the correct
> option name.
Doesn't "mv" do that?
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Shawn O. Pearce @ 2007-10-19 3:19 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <A2C1BF08-4CC8-4F98-9CA8-B81B2FBFE9E4@mit.edu>
Michael Witten <mfwitten@MIT.EDU> wrote:
>
> On 18 Oct 2007, at 9:54:19 PM, Shawn O. Pearce wrote:
>
> >Elsewhere in git we use the --cached command line option to mean
> >"only make the change in the index".
>
> It seems like --cached should be phased out in favor of --index/ed
No, --index is something else.
But I was originally *way* wrong to propose --cached for this usage
in git-mv. --cached means "apply *ONLY* to the index" and "do *NOT*
touch the working tree". Here we want to touch the working tree
in the sense of moving the file. So --cached is not the correct
option name.
--index is used in Git for places were we update *both* the index
and the working directory (git-apply --index). So actually I should
have suggested "git-mv --index". Whoops.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 3:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710182247130.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
>
> > I really don't have an opinion either way. Actually I think the
> > entire progress system of git-pack-objects should be reduced even
> > further so that users aren't exposed to the internal phases we
> > are going through. Most of them just don't care. They just
> > want to know when its going to be done[*1*].
>
> Well, with my latest patches in that area, the typical progress on
> screen has been cut in half. And the different phases are intertaining.
Yup. Your patches were a big improvement. But I'm now sitting here
wondering if we shouldn't just allow a progress meter to overwrite
the prior one. Then you only see the current task and progress,
or the final output if we have nothing further to say about that.
Hmmph. Maybe something like this:
I like how it comes out in the end, but it really screws with the
sideband protocol. Like horribly. I got a whole ton of "remote:
remote: remote: remote: remote: remote:" during a remote clone.
diff --git a/progress.c b/progress.c
index 7629e05..099fc14 100644
--- a/progress.c
+++ b/progress.c
@@ -37,8 +37,6 @@ static void clear_progress_signal(void)
static int display(struct progress *progress, unsigned n, int done)
{
- char *eol;
-
if (progress->delay) {
if (!progress_update || --progress->delay)
return 0;
@@ -55,18 +53,26 @@ static int display(struct progress *progress, unsigned n, int done)
}
progress->last_value = n;
- eol = done ? ", done. \n" : " \r";
- if (progress->total) {
+ if (done) {
+ size_t c = strlen(progress->title);
+ while (c--)
+ fputc(' ', stderr);
+ fputs(" ", stderr);
+ for (; n > 0; n /= 10)
+ fputs(" ", stderr);
+ fputc('\r', stderr);
+ return 1;
+ } else if (progress->total) {
unsigned percent = n * 100 / progress->total;
if (percent != progress->last_percent || progress_update) {
progress->last_percent = percent;
fprintf(stderr, "%s: %3u%% (%u/%u)%s", progress->title,
- percent, n, progress->total, eol);
+ percent, n, progress->total, " \r");
progress_update = 0;
return 1;
}
} else if (progress_update) {
- fprintf(stderr, "%s: %u%s", progress->title, n, eol);
+ fprintf(stderr, "%s: %u%s", progress->title, n, " \r");
progress_update = 0;
return 1;
}
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 3:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710182306300.19446@xanadu.home>
On Thu, Oct 18, 2007 at 11:11:26PM -0400, Nicolas Pitre wrote:
> I think we might sidestep the issue entirely by remaining somewhat vague
> and simply saying "compressing objects" for that phase. This is the
> part responsible for the reduction of a Git repository from 3GB down to
> 200MB anyway.
OK. I liked it a little more specific, but perhaps users really don't
care what's going on. And it seems there is some support of simply
"compressing", so that's probably reasonable.
I think that is going to make the statistics line doubly confusing,
though, since we never even use the word "delta" (or any wacky
verbifications based on it), and then they get a line about numbers of
new and reused deltas.
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 3:11 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019025913.GA9227@coredump.intra.peff.net>
On Thu, 18 Oct 2007, Jeff King wrote:
> On Thu, Oct 18, 2007 at 10:45:31PM -0400, Nicolas Pitre wrote:
>
> > Yet that progress display isn't solely about "delta compressing". It
> > also includes the search for best object match in order to keep the
> > smallest delta possible.
>
> In fact, isn't that progress meter _solely_ about finding the best
> matches? The actual deltification (that is, the creation of the deltas
> and writing of them to the packfile happens during the writing phase --
> unless, of course, we've cached the deltas during the search phase).
Well, to find which combination is the smallest you actually have to
create deltas.
> Perhaps one of:
>
> Finding deltas
> Finding delta candidates
> Matching objects
>
> or something similar (though I don't especially like any of them, I
> think you get the idea).
I think we might sidestep the issue entirely by remaining somewhat vague
and simply saying "compressing objects" for that phase. This is the
part responsible for the reduction of a Git repository from 3GB down to
200MB anyway.
Nicolas
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 3:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710182251110.19446@xanadu.home>
On Thu, Oct 18, 2007 at 11:01:02PM -0400, Nicolas Pitre wrote:
> > - When fetching, one progress meter says "Indexing" which, while
> > technically true, is almost certainly blocking on "Downloading". In
>
> I have some WIP for that.
Great, I won't start work on it, then.
> Maybe the "Removing unused objects" should use the common progress
> infrastructure? It could even use the delayed interface, just like when
> checking out files, so no progress at all is displayed when that
> operation completes within a certain delay. And the removal of unused
> objects is usually quick.
Are you volunteering (I think you know the progress code best)?
Otherwise, I will get to it, but probably not tonight.
> But I like the statistics. They might be pretty handy to diagnoze
> performance issues on remote servers for example.
They are by far the most useful of the three lines I mentioned, but I
just wonder if they are a bit meaningless and cluttery for light users.
We can always cut the others and see how it looks.
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 2:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071019015419.GV14735@spearce.org>
On 18 Oct 2007, at 9:54:19 PM, Shawn O. Pearce wrote:
> Elsewhere in git we use the --cached command line option to mean
> "only make the change in the index".
It seems like --cached should be phased out in favor of --index/ed
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 3:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Sam Vilain, Jeff King, git
In-Reply-To: <20071019023426.GA14735@spearce.org>
On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
> I'm leaning to making it just say "Compressing objects". Simple,
> to the point, reasonably describes the action, and most people will
> understand what it means: "Oh, time to go get coffee if that number
> there is reeeealy big..." :-)
I think this is sensible.
Nicolas
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 3:01 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019023425.GB8298@coredump.intra.peff.net>
On Thu, 18 Oct 2007, Jeff King wrote:
> On a similar note, some complaints with progress meters, even after
> recent patches:
> - When fetching, one progress meter says "Indexing" which, while
> technically true, is almost certainly blocking on "Downloading". In
> fact, it is not clear from the existing messages exactly _when_ we
> are downloading, and when we are just computing, which is something
> I think a user might want to know. Objections to changing this
> (though perhaps index-pack will need to be told when it is
> downloading and when it is just indexing)? Objections to a
> throughput indicator?
I have some WIP for that.
> - Running git-gc, we now get something like:
> Counting objects: 62317, done.
> Deltifying objects: 100% (18042/18042), done.
> Writing objects: 100% (62317/62317), done.
> Total 62317 (delta 43861), reused 61404 (delta 43036)
> Pack pack-32f8ac40c1a5ec146e45c657cb16f53fdd354095 created.
> Removing unused objects 100%...
> Done.
> Can we get rid of total statistics (I think this is useful for some
> power users, but perhaps there should be a verbosity level), the
> name of the pack file (same deal), and the totally useless "Done."?
Agreed for the pack name. Certainly no one cares.
Maybe the "Removing unused objects" should use the common progress
infrastructure? It could even use the delayed interface, just like when
checking out files, so no progress at all is displayed when that
operation completes within a certain delay. And the removal of unused
objects is usually quick.
But I like the statistics. They might be pretty handy to diagnoze
performance issues on remote servers for example.
Nicolas
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 2:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710182238470.19446@xanadu.home>
On Thu, Oct 18, 2007 at 10:45:31PM -0400, Nicolas Pitre wrote:
> Yet that progress display isn't solely about "delta compressing". It
> also includes the search for best object match in order to keep the
> smallest delta possible.
In fact, isn't that progress meter _solely_ about finding the best
matches? The actual deltification (that is, the creation of the deltas
and writing of them to the packfile happens during the writing phase --
unless, of course, we've cached the deltas during the search phase).
Perhaps one of:
Finding deltas
Finding delta candidates
Matching objects
or something similar (though I don't especially like any of them, I
think you get the idea).
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Sam Vilain @ 2007-10-19 2:55 UTC (permalink / raw)
To: Jeff King; +Cc: David Symonds, Shawn O. Pearce, git, Nicolas Pitre
In-Reply-To: <20071019023645.GC8298@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Oct 19, 2007 at 12:24:44PM +1000, David Symonds wrote:
>
>> Forward thinking, that's probably most sensible, since git 4.7 might
>> not use delta compression, but maybe wavelet compression, or other
>> scheme entirely. Using deltas is an implementation detail, after all.
>
> Git already uses two types of compression (zlib on all objects, deltas
> between objects in packfiles). So just saying "compressing" is actually
> a bit ambiguous, and I think noting that what we are _actually_ doing
> right now is delta compression is worthwhile.
True. But then, zlib compression is also delta compressing and huffman
coding. Git's delta compression is quite similar; it just uses a larger
window than the sliding 64k gzip one.
Sam.`
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Shawn O. Pearce @ 2007-10-19 2:49 UTC (permalink / raw)
To: Christian Couder
Cc: Linus Torvalds, David Kastrup, Geert Bosch, David Symonds,
Wincent Colaiuta, Johan Herland, git, Marius Storm-Olsen,
Ren? Scharfe, Junio Hamano, Johannes Schindelin
In-Reply-To: <200710190449.49477.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> Le jeudi 18 octobre 2007, Linus Torvalds a écrit :
> > Well, this has been debated to death, but I actually think that "skip" is
> > a good choice, exactly because it's an action.
>
> I will happily provide a new patch series with "skip" instead of "dunno"
> if/when Shawn says that the discussion is over.
I had concluded yesterday that this discussion is likely over and
that skip is the term we all were OK with. But unfortunately you
just found out that vger is unable to read my mind and send such
an email to the mailing list. :-)
Please make it so.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 2:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git
In-Reply-To: <20071019022154.GY14735@spearce.org>
On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
> I really don't have an opinion either way. Actually I think the
> entire progress system of git-pack-objects should be reduced even
> further so that users aren't exposed to the internal phases we
> are going through. Most of them just don't care. They just
> want to know when its going to be done[*1*].
Well, with my latest patches in that area, the typical progress on
screen has been cut in half. And the different phases are intertaining.
Nicolas
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 2:47 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nicolas Pitre
In-Reply-To: <20071019023425.GB8298@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Oct 18, 2007 at 10:21:54PM -0400, Shawn O. Pearce wrote:
>
> > My eyes have gotten used to "Deltifying" but I have to admit that
> > in my early Git days I thought it looked damn odd. Today I'm far
> > too familiar with Git to really notice this as a problem now.
>
> OK, I will confess I found it a little odd at first, but I think it's a
> straightforward and playful extension of the language, which is
> something I like. But you know, we have the corporate git customers to
> think about these days. ;)
Heh. Yeah, Git is gaining users on a daily basis. Its good. :)
> On a similar note, some complaints with progress meters, even after
> recent patches:
>
> - When fetching, one progress meter says "Indexing" which, while
> technically true, is almost certainly blocking on "Downloading". In
> fact, it is not clear from the existing messages exactly _when_ we
> are downloading, and when we are just computing, which is something
> I think a user might want to know. Objections to changing this
> (though perhaps index-pack will need to be told when it is
> downloading and when it is just indexing)? Objections to a
> throughput indicator?
Yes! I agree entirely. This is actually not very difficult.
I think the only time we run `git-index-pack --stdin` is from within
git-fetch-pack and git-receive-pack. These are the only two points
where index-pack's stdin is attached to a network socket and not
to a file. Its also where you'd want this to say "Transferring",
"Uploading" or "Downloading".
Really the important one to change here is probably the call in
fetch-pack.c as that is the most visible and most time consuming
operation for the average user (think git-clone on a large project).
The same change probably should also be made for unpack-objects as
fetch-pack/receive-pack may have chosen to use that if the object
count is low and it wasn't instructed to keep the packfile.
> - Running git-gc, we now get something like:
> Counting objects: 62317, done.
> Deltifying objects: 100% (18042/18042), done.
> Writing objects: 100% (62317/62317), done.
> Total 62317 (delta 43861), reused 61404 (delta 43036)
> Pack pack-32f8ac40c1a5ec146e45c657cb16f53fdd354095 created.
> Removing unused objects 100%...
> Done.
> Can we get rid of total statistics (I think this is useful for some
> power users, but perhaps there should be a verbosity level), the
> name of the pack file (same deal), and the totally useless "Done."?
Yea. I keep forgetting to write a patch to do this. I've had much
the same thought as you.
The verbosity should probably be controlled like merge-recursive's
is, but should default to not showing the "Total" line or the "Pack
.. created" line. For the average user there isn't any valuable
information in either line.
I also think that the progress meter of git-prune-packed should be
fixed to use the standard progress meter system. And maybe also
be delayed so it doesn't trip if its going to be very quick.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 2:45 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019021255.GD3290@coredump.intra.peff.net>
On Thu, 18 Oct 2007, Jeff King wrote:
> On Thu, Oct 18, 2007 at 08:45:27PM -0400, Shawn O. Pearce wrote:
>
> > Recently I was referred to the Grammar Police as the git-pack-objects
> > progress message 'Deltifying %u objects' is considered to be not
> > proper English to at least some small but vocal segment of the
> > English speaking population. Techncially we are applying delta
> > compression to these objects at this stage, so the new term is
> > slightly more acceptable to the Grammar Police but is also just
> > as correct.
>
> Boo. I _like_ "deltifying". Sure, it's probably not in the dictionary,
> but that's how languages change: saying "delta compressing" all the time
> will get awkward, so people invent a new word using existing rules to
> explain a common phenomenon.
Yet that progress display isn't solely about "delta compressing". It
also includes the search for best object match in order to keep the
smallest delta possible.
I'd like to add my own boo, but since I'm not a native speaker I won't
argue too much.
Nicolas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox