* 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
* Re: [PATCH 2/2] Documentation/git-gc: improve description of --auto
From: Jeff King @ 2007-10-19 2:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Steven Grimm, Brian Gernhardt
In-Reply-To: <20071019022909.GZ14735@spearce.org>
On Thu, Oct 18, 2007 at 10:29:09PM -0400, Shawn O. Pearce wrote:
> I personally prefer to read commands in the source as `foo` and
> feel that asciidoc should just format it correctly for the backend.
> If it isn't then we should try to work with the asciidoc folks to
> get it right...
I am hunting this down right now. asciidoc _does_ generate
XML <literal>foo</literal> for `foo`, but it looks like docbook is
throwing that away when converting to manpages. Hopefully there is an
easy tweak...
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 2:36 UTC (permalink / raw)
To: David Symonds; +Cc: Sam Vilain, Shawn O. Pearce, git, Nicolas Pitre
In-Reply-To: <ee77f5c20710181924j7c538468r75f0f17968af7b01@mail.gmail.com>
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.
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 2:34 UTC (permalink / raw)
To: David Symonds; +Cc: Sam Vilain, Jeff King, git, Nicolas Pitre
In-Reply-To: <ee77f5c20710181924j7c538468r75f0f17968af7b01@mail.gmail.com>
David Symonds <dsymonds@gmail.com> wrote:
> On 19/10/2007, Sam Vilain <sam@vilain.net> wrote:
> > Jeff King wrote:
> > > 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.
> >
> > This is not very considerate to non-native speakers, though, who might
> > not grasp the neogolism.
> >
> > Perhaps just "compressing" if it gets awkward.
>
> 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.
Heh. I just remembered that my packv4 topic had a phase it called
"Dictifying objects". Which ran before "Deltifying objects". It was
just another form of compression, but it was also timeconsuming
and an entirely different loop so it got its own progress meter.
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..." :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 2:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Nicolas Pitre
In-Reply-To: <20071019022154.GY14735@spearce.org>
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. ;)
> 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*].
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?
- 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."?
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 2:29 UTC (permalink / raw)
To: Shawn O. Pearce, Jeff King; +Cc: git
In-Reply-To: <20071019021618.GE3290@coredump.intra.peff.net>
On 18 Oct 2007, at 10:15:29 PM, Shawn O. Pearce wrote:
> git-add amounts to either inserting a new path->stat/sha1 entry
> in the index, or updating an existing entry with new stat/sha1
> information.
>
> git-rm amounts to removing a path->stat/sha1 entry from the index.
> It's just gone once the git-rm is completed. As if it was never
> there to begin with.
>
> A git-commit (really git-write-tree but same difference to the
> end-user) stores whatever is in the index as the gospel truth for
> how that commit's files should appear.
Ah. Basically my 'pseudo-code' is correct, but redundant.
On 18 Oct 2007, at 10:16:18 PM, Jeff King wrote:
> Eh? The changes will make it into history when you commit. Or
> perhaps I
> don't understand your question. Can you rephrase it?
I misunderstood the (lack) of details.
On 18 Oct 2007, at 10:15:29 PM, Shawn O. Pearce wrote:
> But its all really as simple as it seems.
It's about time I read more thoroughly through the manual!
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] Documentation/git-gc: improve description of --auto
From: Shawn O. Pearce @ 2007-10-19 2:29 UTC (permalink / raw)
To: Jeff King; +Cc: git, Steven Grimm, Brian Gernhardt
In-Reply-To: <20071019020510.GB7711@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> It is a little bit odd that there is so much low-level detail in the
> '--auto' description versus the rest of the page. But I think it reads
> OK. Also note that the previous incarnation (and my changes) use the
> `foo` form to monospace arguments, while the rest of the page uses 'foo'
> (which actually means emphasis). I think the former is more correct, but
> asciidoc renders the latter much more pleasantly in manpages. I will see
> if I can tweak asciidoc to make this look better.
I like this a lot better than what was there before. Nice work.
I have no real opinion on the asciidoc syntax.
I personally prefer to read commands in the source as `foo` and
feel that asciidoc should just format it correctly for the backend.
If it isn't then we should try to work with the asciidoc folks to
get it right...
> --auto::
> - With this option, `git gc` checks if there are too many
> - loose objects in the repository and runs
> - gitlink:git-repack[1] with `-d -l` option to pack them.
> - The threshold for loose objects is set with `gc.auto` configuration
> - variable, and can be disabled by setting it to 0. Some
> - Porcelain commands use this after they perform operation
> - that could create many loose objects automatically.
> - Additionally, when there are too many packs are present,
> - they are consolidated into one larger pack by running
> - the `git-repack` command with `-A` option. The
> - threshold for number of packs is set with
> - `gc.autopacklimit` configuration variable.
> + With this option, `git gc` checks whether any housekeeping is
> + required; if not, it exits without performing any work.
> + Some git commands run `git gc --auto` after performing
> + operations that could create many loose objects.
> ++
> +Housekeeping is required if there are too many loose objects or
> +too many packs in the repository. If the number of loose objects
> +exceeds the value of the `gc.auto` configuration variable, then
> +all loose objects are combined into a single pack using
> +`git-repack -d -l`. Setting the value of `gc.auto` to 0
> +disables automatic packing of loose objects.
> ++
> +If the number of packs exceeds the value of `gc.autopacklimit`,
> +then existing packs (except those marked with a `.keep` file)
> +are consolidated into a single pack by using the `-A` option of
> +`git-repack`. Setting `gc.autopacklimit` to 0 disables
> +automatic consolidation of packs.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 2:25 UTC (permalink / raw)
To: Sam Vilain; +Cc: Shawn O. Pearce, git, Nicolas Pitre
In-Reply-To: <47181430.2080907@vilain.net>
On Fri, Oct 19, 2007 at 03:19:28PM +1300, Sam Vilain wrote:
> This is not very considerate to non-native speakers, though, who might
> not grasp the neogolism.
>
> Perhaps just "compressing" if it gets awkward.
I would have thought it would be easier for non-native speakers, since
it has a precise meaning which I assumed we defined in a glossary (but
now I see that we don't, though that can be corrected). But of course,
I'm a native speaker (and AIUI, so are you), so perhaps we should wait
for somebody else to comment.
But I do agree that making sense to non-native speakers should be a
priority when phrasing things like this.
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: David Symonds @ 2007-10-19 2:24 UTC (permalink / raw)
To: Sam Vilain; +Cc: Jeff King, Shawn O. Pearce, git, Nicolas Pitre
In-Reply-To: <47181430.2080907@vilain.net>
On 19/10/2007, Sam Vilain <sam@vilain.net> wrote:
> Jeff King wrote:
> > 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.
>
> This is not very considerate to non-native speakers, though, who might
> not grasp the neogolism.
>
> Perhaps just "compressing" if it gets awkward.
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.
Dave.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 2:21 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nicolas Pitre
In-Reply-To: <20071019021255.GD3290@coredump.intra.peff.net>
Jeff King <peff@peff.net> 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.
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.
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*].
> Anyway, if you want to please the Grammar Police, should it not be
> "Delta-compressing"? "Delta" is not an adverb here, but rather the
> phrase acts as a compound verb (i.e., the two words work in place of a
> single verb). Although "Delta-compressing objects" just looks stupid.
Yea, that is just stupid. And is why I didn't use a - in my patch.
*1*: Yes, yes, I know that's hard to predict and impossible in
the really important cases (like network transfer of not yet
compressed data). So just telling them that we are working and
have recently done something useful towards finishing our goal is
more than enough. Its like putting mirrors on the wall in a lobby;
folks won't notice how long it takes for the elevator to arrive as
they are too busy preening themselves.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Sam Vilain @ 2007-10-19 2:19 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git, Nicolas Pitre
In-Reply-To: <20071019021255.GD3290@coredump.intra.peff.net>
Jeff King wrote:
> 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.
This is not very considerate to non-native speakers, though, who might
not grasp the neogolism.
Perhaps just "compressing" if it gets awkward.
Sam.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Jeff King @ 2007-10-19 2:16 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, git
In-Reply-To: <7F18F52A-3D57-4510-B71B-69D43480126E@MIT.EDU>
On Thu, Oct 18, 2007 at 10:07:05PM -0400, Michael Witten wrote:
> I mean to say, if only the index is changed,
> then git won't be informed about the necessary
> git-{add/rm}'s, as in the following (is this
> not so?):
Eh? The changes will make it into history when you commit. Or perhaps I
don't understand your question. Can you rephrase it?
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Shawn O. Pearce @ 2007-10-19 2:15 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <7F18F52A-3D57-4510-B71B-69D43480126E@MIT.EDU>
Michael Witten <mfwitten@MIT.EDU> wrote:
> On 18 Oct 2007, at 9:57:15 PM, Shawn O. Pearce wrote:
> >Michael Witten <mfwitten@MIT.EDU> wrote:
> >>
> >>Seems like the shortcut would lose the history and confuse git.
> >
> >No. It wouldn't. The index has no knowledge of history of anything.
>
> I mean to say, if only the index is changed,
> then git won't be informed about the necessary
> git-{add/rm}'s, as in the following (is this
> not so?):
git-add amounts to either inserting a new path->stat/sha1 entry
in the index, or updating an existing entry with new stat/sha1
information.
git-rm amounts to removing a path->stat/sha1 entry from the index.
It's just gone once the git-rm is completed. As if it was never
there to begin with.
A git-commit (really git-write-tree but same difference to the
end-user) stores whatever is in the index as the gospel truth for
how that commit's files should appear. No knowledge about add
or rm is necessary at this stage, we're just taking a copy of the
index and recording that for posterity.
So updating the index is all that is necessary to "remember" these
add and rm operations. OK, well, you also need to actually make
a commit (and not orphan that commit) to have it really stay in
your project. But its all really as simple as it seems.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 2:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Nicolas Pitre
In-Reply-To: <20071019004527.GA12930@spearce.org>
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.
Anyway, if you want to please the Grammar Police, should it not be
"Delta-compressing"? "Delta" is not an adverb here, but rather the
phrase acts as a compound verb (i.e., the two words work in place of a
single verb). Although "Delta-compressing objects" just looks stupid.
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 2:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071019015715.GW14735@spearce.org>
On 18 Oct 2007, at 9:57:15 PM, Shawn O. Pearce wrote:
> Michael Witten <mfwitten@MIT.EDU> wrote:
>> On 18 Oct 2007, at 11:47:32 AM, lmage11@twcny.rr.com wrote:
>>
>>> I don't know exactly how git manages the index
>>> internally, but a
>>> shortcut for this would be to simply rename the index entry in
>>> place.
>>
>> Seems like the shortcut would lose the history and confuse git.
>
> No. It wouldn't. The index has no knowledge of history of anything.
I mean to say, if only the index is changed,
then git won't be informed about the necessary
git-{add/rm}'s, as in the following (is this
not so?):
> You're saying that, currently, 'git-mv A.txt path/B.txt'
> does this:
>
> mv A.txt path/B.txt
> git add path/B.txt
> git rm A.txt
>
> So that A.txt is indeed moved to path/B.txt, but now
> A_dirty has been added to the index.
>
> 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
^ permalink raw reply
* [PATCH 2/2] Documentation/git-gc: improve description of --auto
From: Jeff King @ 2007-10-19 2:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Steven Grimm, Brian Gernhardt
This patch tries to make the description of --auto a little
more clear for new users, especially those referred by the
"git-gc --auto" notification message.
It also cleans up some grammatical errors and typos in the
original description, as well as rewording for clarity.
Signed-off-by: Jeff King <peff@peff.net>
---
I started by just trying to fix a couple of grammar issues, but it
seemed quite awkward, and somehow this came out. I think it reads better
than the original, but I'm open to comment.
It is a little bit odd that there is so much low-level detail in the
'--auto' description versus the rest of the page. But I think it reads
OK. Also note that the previous incarnation (and my changes) use the
`foo` form to monospace arguments, while the rest of the page uses 'foo'
(which actually means emphasis). I think the former is more correct, but
asciidoc renders the latter much more pleasantly in manpages. I will see
if I can tweak asciidoc to make this look better.
Documentation/git-gc.txt | 29 +++++++++++++++++------------
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 83843a5..872056e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -45,18 +45,23 @@ OPTIONS
few hundred changesets or so.
--auto::
- With this option, `git gc` checks if there are too many
- loose objects in the repository and runs
- gitlink:git-repack[1] with `-d -l` option to pack them.
- The threshold for loose objects is set with `gc.auto` configuration
- variable, and can be disabled by setting it to 0. Some
- Porcelain commands use this after they perform operation
- that could create many loose objects automatically.
- Additionally, when there are too many packs are present,
- they are consolidated into one larger pack by running
- the `git-repack` command with `-A` option. The
- threshold for number of packs is set with
- `gc.autopacklimit` configuration variable.
+ With this option, `git gc` checks whether any housekeeping is
+ required; if not, it exits without performing any work.
+ Some git commands run `git gc --auto` after performing
+ operations that could create many loose objects.
++
+Housekeeping is required if there are too many loose objects or
+too many packs in the repository. If the number of loose objects
+exceeds the value of the `gc.auto` configuration variable, then
+all loose objects are combined into a single pack using
+`git-repack -d -l`. Setting the value of `gc.auto` to 0
+disables automatic packing of loose objects.
++
+If the number of packs exceeds the value of `gc.autopacklimit`,
+then existing packs (except those marked with a `.keep` file)
+are consolidated into a single pack by using the `-A` option of
+`git-repack`. Setting `gc.autopacklimit` to 0 disables
+automatic consolidation of packs.
Configuration
-------------
--
1.5.3.4.1249.g895be-dirty
^ permalink raw reply related
* [PATCH 1/2] Documentation/git-gc: explain --auto in description
From: Jeff King @ 2007-10-19 2:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Steven Grimm, Brian Gernhardt
Now that git-gc --auto tells the user to look at the man
page, it makes sense to mention the auto behavior near the
top (since this is likely to be most users' first exposure
to git-gc).
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-gc.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index b9d5660..83843a5 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -19,7 +19,8 @@ created from prior invocations of gitlink:git-add[1].
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
-operating performance.
+operating performance. Some git commands may automatically run
+`git-gc`; see the `--auto` flag below for details.
OPTIONS
-------
--
1.5.3.4.1249.g895be-dirty
^ permalink raw reply related
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