* 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
* Re: Proposed git mv behavioral change
From: Shawn O. Pearce @ 2007-10-19 1:57 UTC (permalink / raw)
To: Michael Witten; +Cc: lmage11, git
In-Reply-To: <D2EAAC6D-567D-454A-AECA-C90FA2C369AE@mit.edu>
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.
For good reason. Its strictly a mapping of file name to some basic
stat information (used to determine if the file has been modified
by the user or not) and the SHA-1 of the staged blob. That's it.
No history. The shortcut the original poster was asking about
wouldn't confuse Git one bit.
--
Shawn.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Shawn O. Pearce @ 2007-10-19 1:54 UTC (permalink / raw)
To: lmage11; +Cc: git
In-Reply-To: <c594999b2337.2337c594999b@nyroc.rr.com>
Line wrapping email at under 80 columns would be nice. It makes it
easier to read the message, and more importantly, easier to quote
a few times during discussion.
lmage11@twcny.rr.com wrote:
> Therefore, I propose that git mv's behavior be changed. I think it
> would make far more sense for a move to only change the actual name
> of the file and to not pull in unstaged changes. In other words,
> I'd like the index entry for the original file name to be removed
> and an index entry to be added with a different name, but using the
> exact same blob hash as the original file. 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.
I'm somewhat hesistant to change existing behavior, as users may
be used to it or relying upon it within their scripts. But you
make an excellent argument about why the current git-mv behavior
is perhaps less than ideal.
Elsewhere in git we use the --cached command line option to mean
"only make the change in the index". For example the git-apply
--cached option. You could start a patch that uses --cached to
trigger the new behavior you propose and see if people are interested
in changing the default once the feature is working and available
for experimentation.
> I'm willing to look into what changes would need to be made to the
> code for this change to happen; I'm not asking for someone to do
> all the work for me. :)
>
> So... Yeah. I'd like to know what people think about this before
> I put a significant amount of effort into it. After all, we know
> how lazy programmers are... :)
See builtin-mv.c around l.264-283. This is where we are removing
the old names from the index (in memory) and inserting the new
names. Instead of calling add_file_to_cache() you would want
to use something like add_cacheinfo() in builtin-update-index.c,
specifying the old sha1, ce_flags and ce_mode.
I'm sure Junio could probably give you a better starting point
than I can, as he's more familiar with this sort of code, but that
should still get you looking in the right direction and maybe get
a working implementation together that you can share for discussion.
--
Shawn.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 1:47 UTC (permalink / raw)
To: lmage11; +Cc: git
In-Reply-To: <c594999b2337.2337c594999b@nyroc.rr.com>
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.
Anyway,
Let's say you have a file, A.txt, with contents:
A
You edit this file so that it has contents:
A_dirty
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
Is this correct?
Michael Witten
^ permalink raw reply
* [PATCH] Avoid invoking diff drivers during git-stash
From: Shawn O. Pearce @ 2007-10-19 1:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <47171A21.9030003@viscovery.net>
git-stash needs to restrict itself to plumbing when running automated
diffs as part of its operation as the user may have configured a
custom diff driver that opens an interactive UI for certain/all
files. Doing that during scripted actions is very unfriendly to
the end-user and may cause git-stash to fail to work.
Reported by Johannes Sixt
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Johannes Sixt <j.sixt@viscovery.net> wrote:
> (1) Looking at git-stash.sh I see a few uses of 'git diff' in
> apply_stash(). Shouldn't these use one of git-diff-{tree,index,files)? The
> reason is that porcelain 'git diff' invokes custom diff drivers (that in my
> case run a UI program), whereas the plumbing does not.
>
> Is there a particular reason to use porcelain 'git diff'?
Does this fix the problem?
git-stash.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 7ba6162..def3163 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -110,7 +110,7 @@ show_stash () {
w_commit=$(git rev-parse --verify "$s") &&
b_commit=$(git rev-parse --verify "$s^") &&
- git diff $flags $b_commit $w_commit
+ git diff-tree $flags $b_commit $w_commit
}
apply_stash () {
@@ -139,7 +139,7 @@ apply_stash () {
unstashed_index_tree=
if test -n "$unstash_index" && test "$b_tree" != "$i_tree"
then
- git diff --binary $s^2^..$s^2 | git apply --cached
+ git diff-tree --binary $s^2^..$s^2 | git apply --cached
test $? -ne 0 &&
die 'Conflicts in index. Try without --index.'
unstashed_index_tree=$(git-write-tree) ||
@@ -162,7 +162,7 @@ apply_stash () {
git read-tree "$unstashed_index_tree"
else
a="$TMP-added" &&
- git diff --cached --name-only --diff-filter=A $c_tree >"$a" &&
+ git diff-index --cached --name-only --diff-filter=A $c_tree >"$a" &&
git read-tree --reset $c_tree &&
git update-index --add --stdin <"$a" ||
die "Cannot unstage modified files"
--
1.5.3.4.1249.g895be
^ permalink raw reply related
* Re: git stash apply usability issues
From: Shawn O. Pearce @ 2007-10-19 1:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <47171A21.9030003@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> (2) when 'git stash apply' runs merge-recursive, it treats the current
> state as 'ours' and the stash as 'theirs'. IMHO it should be the other way
> round: I have stashed away changes to a binary file. Then committed a
> different modification to it, and now want to apply the stash. This results
> in a conflict that leaves the current state in the working tree, but I had
> preferred that the stashed binary file were in the working tree now.
>
> What do other git-stash users think about changing the order?
The current order is the same order that git-rebase uses. I'm not
saying its correct, just that its the same as rebase. I think rebase
is also backwards and if we change git-stash we should also change
git-rebase at the same time (though probably not in the same commit).
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gc: improve wording of --auto notification
From: Jeff King @ 2007-10-19 1:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, Brian Gernhardt, git
In-Reply-To: <20071019012430.GT14735@spearce.org>
On Thu, Oct 18, 2007 at 09:24:30PM -0400, Shawn O. Pearce wrote:
> I think what you have is many times better. It doesn't tell the
> user that they can prevent having this activate at the wrong time
> by just running git-gc every so often, but if the message (and
> the subsequent packing itself) is annoying they'll read the manual
> entry and hopefully figure that out on their own.
Yes, I tried many wordings of "this is annoying and you want to avoid
it," but explaining the situation takes way too much time for such a
commonly seen message. And I think some people will actually prefer it
that way.
BTW, the git-gc manpage needs some cleanup. Patches to follow.
-Peff
^ permalink raw reply
* Re: [PATCH] git-gc: improve wording of --auto notification
From: Shawn O. Pearce @ 2007-10-19 1:24 UTC (permalink / raw)
To: Jeff King; +Cc: Steven Grimm, Brian Gernhardt, git
In-Reply-To: <20071019011211.GC3290@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> Shawn said:
> > A patch against spearce/master to revert the prior message and insert
> > something that is perhaps more reasonable would be most appreciated.
>
> Geez, you really _are_ the maintainer now, prodding your minions to
> write trivial patches for you. :)
Heh. But didn't I just post a different trivial patch to the
mailing list not 15 minutes ago? :-)
> I don't see any point in reverting the
> other patch separately, since we can just improve the message.
I agree. No point in pissing in the snow multiple times over a
simple language change. I was perhaps a little too aggressive in
applying Steven's first patch. Which I also now see git-am actually
split the From line incorrectly and doesn't actually show Steven's
name in the author field. Arrgh.
> I tried not to use the word "avoid" since I think we don't want to imply
> that auto-gc sucks. It doesn't, but some people might prefer to run it
> manually, and we should let them know it's an option. I'm open to
> wording improvements.
I think what you have is many times better. It doesn't tell the
user that they can prevent having this activate at the wrong time
by just running git-gc every so often, but if the message (and
the subsequent packing itself) is annoying they'll read the manual
entry and hopefully figure that out on their own.
> fprintf(stderr, "Packing your repository for optimum "
> + "performance. You may also\n"
> + "run \"git gc\" manually. See "
> + "\"git help gc\" for more information.\n");
--
Shawn.
^ permalink raw reply
* Re: Application to install man pages.
From: Shawn O. Pearce @ 2007-10-19 1:16 UTC (permalink / raw)
To: Evan Carroll; +Cc: git
In-Reply-To: <428b865e0710181159i7a12f2b7y22619f0eaf36d2c1@mail.gmail.com>
Evan Carroll <me@evancarroll.com> wrote:
> This is a one liner but might help for simply a quick install of the
> git manpages.
...
> +#/bin/sh
> + cp -R --copy-contents ./man* /usr/local/man
> --
Isn't this covered by the "make -C Documentation quick-install"?
Which is what "make quick-install-doc" does in the top level Makefile.
--
Shawn.
^ 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