* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Junio C Hamano @ 2005-12-13 18:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051213170015.GD22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Thank you both for the patch, but I'd be much more comfortable if at
> least quotes (both ' and "), backslashes, ? and * would be prohibited in
> the names as well.
I second that, and thanks for pointing it out. Any objections?
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.1
From: Paul Dickson @ 2005-12-13 18:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051213165645.GC22159@pasky.or.cz>
On Tue, 13 Dec 2005 17:56:45 +0100, Petr Baudis wrote:
> Dear diary, on Tue, Dec 13, 2005 at 02:26:36AM CET, I got a letter
> where Paul Dickson <paul@permanentmail.com> said that...
> > Any chance of man files? I'm more use to type man than cg-help.
>
> You can make the man files by
>
> make doc
>
> and install them by
>
> make install-doc
>
>
> This isn't done by default so that you won't need asciidoc for the
> build. This is exactly the same way in GIT.
See my messages about 0.99.9m and xmlto (and asciidoc). They are
currently required for building the RPMs. Perhaps the spec file needs
updating.
Thanks for the peek into your input queue.
-Paul
^ permalink raw reply
* git-merge fails when trying to merge from a tag
From: Carl Baldwin @ 2005-12-13 17:55 UTC (permalink / raw)
To: git
Greetings,
I just tried to merge using a tag object. I expected this to work just fine
since the tag refers to a commit object and is therefore committish. The very
same merge command except with '^{}' appended to the tag name to select the
commit object worked just fine. Below you'll find some interesting output.
Cheers,
Carl
PS I used git-bisect for the first time this morning. I was VERY impressed.
Anyway, on to the output...
% git --version
git version 0.99.9m
% git merge "Merging release-0.3.1" HEAD refs/tags/release-0.3.1
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with refs/tags/release-0.3.1
Merging:
df17837d378c5ee07a26c97ac1bfc3fb3f7bacbb Fix test of string
f2aa1e01ae0f1b0ea9354f2ea2c7444b5efc8ac5 Merging release-0.2.1
found 1 common ancestor(s):
43c6310a463aee1c2cbd882b81a596e429bc7f6c Commit msg
Auto-merging scripts/config.sh
fatal: 4c29c70d1d290807c2757eabaefb607b8fd7b595 is not a valid 'commit' object
% git-cat-file tag 4c29c70d1d290807c2757eabaefb607b8fd7b595
object f2aa1e01ae0f1b0ea9354f2ea2c7444b5efc8ac5
type commit
tag release-0.3.1
tagger Carl N. Baldwin <carl@ecbaldwin.net> 1134493064 -0700
... (The rest of the tag object looks just as you'd expect)
% git checkout -f # To reset changes done by failed merge
% git merge "Merging release-0.3.1" HEAD refs/tags/release-0.3.1^{}
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with refs/tags/release-0.3.1^{}
Merging:
df17837d378c5ee07a26c97ac1bfc3fb3f7bacbb Fix test of string
f2aa1e01ae0f1b0ea9354f2ea2c7444b5efc8ac5 Merging release-0.2.1
found 1 common ancestor(s):
43c6310a463aee1c2cbd882b81a596e429bc7f6c Commit msg
Auto-merging scripts/config.sh
Merge 5612809ea11c9709e3a5282f8002c1f993e127d6, made by recursive.
scripts/config.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9m aka 1.0rc5
From: Paul Dickson @ 2005-12-13 17:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslsxbl1p.fsf@assigned-by-dhcp.cox.net>
On Mon, 12 Dec 2005 21:52:50 -0800, Junio C Hamano wrote:
> Paul Dickson <paul@permanentmail.com> writes:
>
> >> I would suspect groff (as used by man).
> >>
> >> $ zcat /usr/share/man/man1/git-repack.1.gz|grep '^[A-Z][a-z]* by'
> >
> > I think it's up one level to the creator of the man files:
> >
> > .SH "DESCRIPTION"
> > This script is used to combine all objects that do not currently reside in a "pack", into a pack..sp
>
> Hmph. In the same environment as before:
>
> $ rm -f git-repack.1
> $ make git-repack.1
> rm -f doc.dep+ doc.dep
> perl ./build-docdep.perl >doc.dep+
> mv doc.dep+ doc.dep
> asciidoc -b docbook -d manpage -f asciidoc.conf git-repack.txt
> xmlto man git-repack.xml
> Writing git-repack.1 for refentry
> rm git-repack.xml
> $ make git-repack.xml
> asciidoc -b docbook -d manpage -f asciidoc.conf git-repack.txt
> $ grep osdl git-repack.1 git-repack.xml
> git-repack.1:Written by Linus Torvalds <torvalds@osdl\&.org>
> git-repack.xml:<simpara>Written by Linus Torvalds <torvalds@osdl.org></simpara>
> $ exit
>
> And it is the same on kernel.org machine I have account on.
>
I filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175592
Apparently, it's a docbook style issue.
-Paul
^ permalink raw reply
* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Petr Baudis @ 2005-12-13 17:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Atukunda, git
In-Reply-To: <7vy82p9rnb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Dec 13, 2005 at 12:13:12PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Martin Atukunda <matlads@dsmagic.com> writes:
>
> > The egrep pattern used by cg-tag is too restrictive. While it will prevent
> > control characters from being specified as a tag name, it will also reject
> > nearly anything written in a non-English language, as noted by -hpa
> >...
> > -(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
> > +git-check-ref-format $name || \
> > die "name contains invalid characters"
>
> Perhaps you meant to say:
>
> git-check-ref-format "$name"
>
> instead; after all you are dealing with potentially garbage
> input from the user here.
>
> While you are at it, you might want to also quote $_git/refs/tags
> immediately follows the part that you patched, and there is
> another.
Thank you both for the patch, but I'd be much more comfortable if at
least quotes (both ' and "), backslashes, ? and * would be prohibited in
the names as well. Any chance of also implementing this policy upstream?
Taken to the extreme, using such a names for tags might be perceived as
a possible security vulnerability wrt. the less shell-savy users. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.1
From: Petr Baudis @ 2005-12-13 16:56 UTC (permalink / raw)
To: Paul Dickson; +Cc: git
In-Reply-To: <20051212182636.d3b73900.paul@permanentmail.com>
Dear diary, on Tue, Dec 13, 2005 at 02:26:36AM CET, I got a letter
where Paul Dickson <paul@permanentmail.com> said that...
> On Mon, 12 Dec 2005 02:12:10 +0100, Petr Baudis wrote:
>
> > this is Cogito version 0.16.1, the next stable release of the
> > human-friendly version control UI for the Linus' GIT tool.
>
> Can the -help argument be supported too? It's pretty annoying to end up
> typing -help and having that used as a tag or commit.
Both -h and --help is supported. -help should always yield "unknown
argument", but supporting it directly would be inconsistent and might
make the users think that they can actually use that for all the long
arguments.
> Any chance of man files? I'm more use to type man than cg-help.
You can make the man files by
make doc
and install them by
make install-doc
This isn't done by default so that you won't need asciidoc for the
build. This is exactly the same way in GIT.
> How about giving instructions in the edited commit message about how to
> abort the commit. I've figured out you can just delete all the
> referenced files, but this was just by accident. (0.15.1) I had my emacs
> segfault and that commit was performed too.
Thanks for the idea:
+[ "$commitalways" ] && echo "CG: Do not save this file and just quit if
you want to abort the commit." >>$LOGMSG
> Any chance a creating a very simple cg-mv? Having to switch is a lower
> level (git) to perform this function takes time (verifying the
> functionality).
Yes. That's planned for 0.17, and I have the patch in my queue.
> Is there a cogito equivalent of "git-branch foo"? It seems cg-branch-add
> does everything but that.
cg-switch, but it's not in 0.16. It's in the 0.17pre git tree and will
be in 0.17.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Randal L. Schwartz @ 2005-12-13 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5k1bf40.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Junio C Hamano <junkio@cox.net> writes:
>> The only Plumbing support is that ls-files takes --exclude-from=
>> and --exclude-per-directory= options. It is up to the Porcelain
>> layer what names to use.
>>
>> We agreed upon a convention to use .gitignore as per-directory
>> and .git/info/exclude (I think this came from existing practice
>> by Cogito back then) as the tree-wide fallback, when these two
>> flags were introduced to ls-files, for interoperability across
>> Porcelains.
Junio> ... and as Linus pointed out already, the barebone Porcelain-ish
Junio> that ship with git follows that convention as well.
I see now that grepping "gitignore" shows git-add.sh and
git-status.sh. gitignore is indeed doc'ed in git-add.txt, but not in
git-status.txt. Must've snuck in recently. I'm trying to watch
"git-whatchanged -p Documentation/*", but I miss things sometimes.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] define MAXPATHLEN for hosts that don't support it
From: Martin Atukunda @ 2005-12-13 12:21 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
---
git-compat-util.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
e7aa01129989561dcd069db41a2da4a133dcff61
diff --git a/git-compat-util.h b/git-compat-util.h
index 4185b12..ead0ede 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -110,4 +110,7 @@ static inline int sane_case(int x, int h
return x;
}
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 256
+#endif
#endif
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Martin Atukunda @ 2005-12-13 11:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vy82p9rnb.fsf@assigned-by-dhcp.cox.net>
On Tuesday 13 December 2005 14:13, Junio C Hamano wrote:
> Martin Atukunda <matlads@dsmagic.com> writes:
> > The egrep pattern used by cg-tag is too restrictive. While it will
> > prevent control characters from being specified as a tag name, it will
> > also reject nearly anything written in a non-English language, as noted
> > by -hpa ...
> > -(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
> > +git-check-ref-format $name || \
> > die "name contains invalid characters"
>
> Perhaps you meant to say:
>
> git-check-ref-format "$name"
>
Yes. i've just finished preparing a new patch with this exact change. But your
patch is much better.
- Martin -
--
Due to a shortage of devoted followers, the production of great leaders has
been discontinued.
^ permalink raw reply
* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Junio C Hamano @ 2005-12-13 11:13 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <11344712912199-git-send-email-matlads@dsmagic.com>
Martin Atukunda <matlads@dsmagic.com> writes:
> The egrep pattern used by cg-tag is too restrictive. While it will prevent
> control characters from being specified as a tag name, it will also reject
> nearly anything written in a non-English language, as noted by -hpa
>...
> -(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
> +git-check-ref-format $name || \
> die "name contains invalid characters"
Perhaps you meant to say:
git-check-ref-format "$name"
instead; after all you are dealing with potentially garbage
input from the user here.
While you are at it, you might want to also quote $_git/refs/tags
immediately follows the part that you patched, and there is
another.
-- >8 --
[PATCH] cg-tag: shell variable quoting.
Scripts sometimes tend to be loose in variable quoting, and
often they are justifiable (e.g. the variables are already
validated before used unquoted); but when checking the input, we
should try to be strict.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/cg-tag b/cg-tag
index da4f2d5..1efb50d 100755
--- a/cg-tag
+++ b/cg-tag
@@ -28,7 +28,7 @@
USAGE="cg-tag [-d DESCRIPTION] [-s [-k KEYNAME]] TAG_NAME [OBJECT_ID]"
-. ${COGITO_LIB}cg-Xlib || exit 1
+. "${COGITO_LIB}cg-Xlib" || exit 1
sign=
keyname=
@@ -54,10 +54,10 @@ id=$(cg-object-id -n "$id") || exit 1
type=$(git-cat-file -t "$id")
id=${id% *}
-(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
- die "name contains invalid characters"
+git-check-ref-format "$name" ||
+ die "name $name contains invalid characters"
-mkdir -p $_git/refs/tags
+mkdir -p "$_git/refs/tags"
[ -s "$_git/refs/tags/$name" ] && die "tag already exists ($name)"
[ "$id" ] || id="$(cat "$_git/$(git-symbolic-ref HEAD)")"
@@ -83,7 +83,7 @@ if [ "$sign" ]; then
fi
cat "$tagdir/tag.asc" >>"$tagdir/tag"
fi
-if ! git-mktag <"$tagdir/tag" >$_git/refs/tags/$name; then
+if ! git-mktag <"$tagdir/tag" >"$_git/refs/tags/$name"; then
rm -rf "$tagdir"
die "error creating tag"
fi
^ permalink raw reply related
* [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Martin Atukunda @ 2005-12-13 10:54 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
The egrep pattern used by cg-tag is too restrictive. While it will prevent
control characters from being specified as a tag name, it will also reject
nearly anything written in a non-English language, as noted by -hpa
Signed-off-by: Martin Atukunda <matlads@dsmagic.com>
---
cg-tag | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
187670279068e7177149765a7f736cc565a1fe19
diff --git a/cg-tag b/cg-tag
index da4f2d5..73616b8 100755
--- a/cg-tag
+++ b/cg-tag
@@ -54,7 +54,7 @@ id=$(cg-object-id -n "$id") || exit 1
type=$(git-cat-file -t "$id")
id=${id% *}
-(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
+git-check-ref-format $name || \
die "name contains invalid characters"
mkdir -p $_git/refs/tags
--
0.99.9.GIT
^ permalink raw reply related
* Re: as promised, docs: git for the confused
From: Junio C Hamano @ 2005-12-13 8:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmn5bmlk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The only Plumbing support is that ls-files takes --exclude-from=
> and --exclude-per-directory= options. It is up to the Porcelain
> layer what names to use.
>
> We agreed upon a convention to use .gitignore as per-directory
> and .git/info/exclude (I think this came from existing practice
> by Cogito back then) as the tree-wide fallback, when these two
> flags were introduced to ls-files, for interoperability across
> Porcelains.
... and as Linus pointed out already, the barebone Porcelain-ish
that ship with git follows that convention as well.
Now those commands are not Porcelain, so please do not call them
with any bathroom fixture names ;-).
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: H. Peter Anvin @ 2005-12-13 7:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0512122124290.15597@g5.osdl.org>
Linus Torvalds wrote:
>
> So the git "mini-porcelain" layer does in fact use .gitignore and friends.
>
"Mini-porcelain"... bidet?
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9m aka 1.0rc5
From: Junio C Hamano @ 2005-12-13 5:52 UTC (permalink / raw)
To: Paul Dickson; +Cc: git
In-Reply-To: <20051212195408.40af06f1.paul@permanentmail.com>
Paul Dickson <paul@permanentmail.com> writes:
>> I would suspect groff (as used by man).
>>
>> $ zcat /usr/share/man/man1/git-repack.1.gz|grep '^[A-Z][a-z]* by'
>
> I think it's up one level to the creator of the man files:
>
> .SH "DESCRIPTION"
> This script is used to combine all objects that do not currently reside in a "pack", into a pack..sp
Hmph. In the same environment as before:
$ rm -f git-repack.1
$ make git-repack.1
rm -f doc.dep+ doc.dep
perl ./build-docdep.perl >doc.dep+
mv doc.dep+ doc.dep
asciidoc -b docbook -d manpage -f asciidoc.conf git-repack.txt
xmlto man git-repack.xml
Writing git-repack.1 for refentry
rm git-repack.xml
$ make git-repack.xml
asciidoc -b docbook -d manpage -f asciidoc.conf git-repack.txt
$ grep osdl git-repack.1 git-repack.xml
git-repack.1:Written by Linus Torvalds <torvalds@osdl\&.org>
git-repack.xml:<simpara>Written by Linus Torvalds <torvalds@osdl.org></simpara>
$ exit
And it is the same on kernel.org machine I have account on.
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Linus Torvalds @ 2005-12-13 5:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7vzmn5bmlk.fsf@assigned-by-dhcp.cox.net>
On Mon, 12 Dec 2005, Junio C Hamano wrote:
>
> The only Plumbing support is that ls-files takes --exclude-from=
> and --exclude-per-directory= options. It is up to the Porcelain
> layer what names to use.
The only _core_ plumbing support is the git-ls-files option, but some of
the git helper functions do use it. Notably, "git add" and "git status"
both use those options, which in turn then indirectly means that when
using "git commit" the commit message template won't list ignored files
etc.
So the git "mini-porcelain" layer does in fact use .gitignore and friends.
Linus
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Junio C Hamano @ 2005-12-13 5:19 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86d5k1y7dp.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> ... I also don't see any direct support for .gitignore files
> in any of the plumbing. Am I missing something there?
No, you are not missing anything.
The only Plumbing support is that ls-files takes --exclude-from=
and --exclude-per-directory= options. It is up to the Porcelain
layer what names to use.
We agreed upon a convention to use .gitignore as per-directory
and .git/info/exclude (I think this came from existing practice
by Cogito back then) as the tree-wide fallback, when these two
flags were introduced to ls-files, for interoperability across
Porcelains.
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Randal L. Schwartz @ 2005-12-13 3:59 UTC (permalink / raw)
To: Joshua N Pritikin; +Cc: git
In-Reply-To: <20051213035842.GF10371@always.joy.eth.net>
>>>>> "Joshua" == Joshua N Pritikin <jpritikin@pobox.com> writes:
Joshua> I don't remmeber which documentation I read but after spending a month
Joshua> with cogito, I felt like I was ready for git. The only thing I miss
Joshua> from cogito is colorized diff output. ;-)
Yes, that fits my experience as well. I also don't see any direct
support for .gitignore files in any of the plumbing. Am I missing
something there?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Joshua N Pritikin @ 2005-12-13 3:58 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86y82qyrqs.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
On Mon, Dec 12, 2005 at 12:39:39PM -0800, Randal L. Schwartz wrote:
> I learned more by reading the cg-tutorial, at least from the user
> perspective. I then went back to the git-tutorial, and was able to
> finally understand that these commands are worth ignoring. :)
I don't remmeber which documentation I read but after spending a month
with cogito, I felt like I was ready for git. The only thing I miss
from cogito is colorized diff output. ;-)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Junio C Hamano @ 2005-12-13 3:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0512122114090.26663@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> However I added the possibility for (1) to use the destination file as
> well as the "source" file for block copy in patch_delta().
Ah, I've been wondering where that one came from.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9m aka 1.0rc5
From: Paul Dickson @ 2005-12-13 2:54 UTC (permalink / raw)
To: git
In-Reply-To: <20051212192013.9ef4c8b2.paul@permanentmail.com>
On Mon, 12 Dec 2005 19:20:13 -0700, Paul Dickson wrote:
> $ rpm -q xmlto asciidoc man groff
> xmlto-0.0.18-9
> asciidoc-7.0.2-1.fc5
> man-1.6b-1
> groff-1.18.1.1-5
>
> I would suspect groff (as used by man).
>
> $ zcat /usr/share/man/man1/git-repack.1.gz|grep '^[A-Z][a-z]* by'
>
I think it's up one level to the creator of the man files:
.SH "DESCRIPTION"
This script is used to combine all objects that do not currently reside in a "pack", into a pack..sp
A pack is a collection of objects, individually compressed, with delta compression applied, stored in a single file, with
an associated index file..sp
Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc..sp
Results in:
DESCRIPTION
This script is used to combine all objects that do not currently reside
in a "pack", into a pack..sp A pack is a collection of objects,
individually compressed, with delta compression applied, stored in a
single file, with an associated index file..sp Packs are used to reduce
the load on mirror systems, backup engines, disk storage, etc..sp
It's only the .sp function.
So it's likely my version of asciidoc or xmlto.
-Paul
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Nicolas Pitre @ 2005-12-13 2:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0512121758410.15597@g5.osdl.org>
On Mon, 12 Dec 2005, Linus Torvalds wrote:
>
>
> On Mon, 12 Dec 2005, Linus Torvalds wrote:
> >
> > As mentioned, pack-objects.c needs to check the size heuristics before
> > doing diff_delta() _anyway_, for performance reasons as well as simply
> > because the secondary use of diff_delta() is to estimate how big the
> > delta is, and it's always pointless to generate a delta that is
> > guaranteed to be bigger than the file (which is always the case with
> > either side being an empty file - the size difference will inevitably
> > be bigger than the size of the resulting file).
>
> Side note: this isn't technically entirely true. A binary diff that has a
> source file that is empty could in theory be smaller than the destination
> file simply because it may involve a certain amount of automatic
> compression in the form of "insert 100 spaces" kind of diff encoding. I'm
> not sure whether xdelta actually does something like that, but it's
> certainly possible at least in theory.
xdelta doesn't. It only has two functions currently:
1) copy x bytes from offset y in source file to current position in
destination file;
2) paste the x following bytes straight from the delta stream to
current position into the destination file.
Of course in the GIT context files are buffers.
However I added the possibility for (1) to use the destination file as
well as the "source" file for block copy in patch_delta(). However
diff_delta() currently doesn't use that capability. But if it did then
the "insert 100 spaces" would be:
- paste \x20\x20\x20\x20 to dest
(delta = 5 bytes, dest = 4 bytes)
- copy 4 bytes from offset 0 of dest to dest
(delta = 7 bytes, dest = 8 bytes)
- copy 8 bytes from offset 0 of dest to dest
(delta = 9 bytes, dest = 16 bytes)
- copy 16 bytes from offset 0 of dest to dest
(delta = 11 bytes, dest = 32 bytes)
- copy 32 bytes from offset 0 of dest to dest
(delta = 13 bytes, dest = 64 bytes)
- copy 36 bytes from offset 0 of dest to dest
(delta = 15 bytes, dest = 100 bytes)
And yet that could be optimized further with a better size for the
initial paste. However adding that capability to diff_delta() might
make it significantly slower for still unknown gain for real life data.
But I should write the code some day.
Nicolas
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9m aka 1.0rc5
From: Paul Dickson @ 2005-12-13 2:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5k1dax6.fsf@assigned-by-dhcp.cox.net>
On Mon, 12 Dec 2005 17:48:37 -0800, Junio C Hamano wrote:
> $ dpkg -l asciidoc xmlto
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
> ||/ Name Version Description
> +++-==============-==============-============================================
> ii asciidoc 7.0.2-4 Highly configurable text format for writing
> ii xmlto 0.0.18-5 XML-to-any converter
> $ grep '^[A-Z][a-z]* by' git-repack.1
> Written by Linus Torvalds <torvalds@osdl\&.org>
> Documentation by Ryan Anderson <ryan@michonline\&.com>
$ rpm -q xmlto asciidoc man groff
xmlto-0.0.18-9
asciidoc-7.0.2-1.fc5
man-1.6b-1
groff-1.18.1.1-5
I would suspect groff (as used by man).
$ zcat /usr/share/man/man1/git-repack.1.gz|grep '^[A-Z][a-z]* by'
-Paul
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Linus Torvalds @ 2005-12-13 2:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512121720150.15597@g5.osdl.org>
On Mon, 12 Dec 2005, Linus Torvalds wrote:
>
> As mentioned, pack-objects.c needs to check the size heuristics before
> doing diff_delta() _anyway_, for performance reasons as well as simply
> because the secondary use of diff_delta() is to estimate how big the
> delta is, and it's always pointless to generate a delta that is
> guaranteed to be bigger than the file (which is always the case with
> either side being an empty file - the size difference will inevitably
> be bigger than the size of the resulting file).
Side note: this isn't technically entirely true. A binary diff that has a
source file that is empty could in theory be smaller than the destination
file simply because it may involve a certain amount of automatic
compression in the form of "insert 100 spaces" kind of diff encoding. I'm
not sure whether xdelta actually does something like that, but it's
certainly possible at least in theory.
Of course, even if the delta in such a case may be smaller than the
resulting file, such a delta is still not interesting: even from a packing
angle, if the resulting file has patterns that makes it easy to generate a
small delta against an empty file, the fact is, such a regular end result
will _compress_ better than the delta will, assuming any decent
compression mechanism.
So from a packing standpoint, generating the delta is still the wrong
thing to do - you're better off with just compressing the undeltified
result.
And from a similarity-estimation standpoint, going from an empty file to
anything else is also obviously not interesting either. An empty file
cannot be "similar" to anything else (except perhaps another empty file,
and even that is a matter of taste).
I just wanted to correct the technicality that delta's can certainly be
smaller than the result at least if the delta format allows for that kind
of encoding.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9m aka 1.0rc5
From: Junio C Hamano @ 2005-12-13 1:48 UTC (permalink / raw)
To: Paul Dickson; +Cc: git
In-Reply-To: <20051212183723.c4b09964.paul@permanentmail.com>
Paul Dickson <paul@permanentmail.com> writes:
> On Sun, 11 Dec 2005 18:34:20 -0800, Junio C Hamano wrote:
>
>> GIT 0.99.9m aka 1.0rc5 is found at usual places:
>
> Is it just me or do most paragraphs (blocks of text) end with a ".sp"?
Not for me.
$ rm -f git-repack.1
$ make git-repack.1
asciidoc -b docbook -d manpage -f asciidoc.conf git-repack.txt
xmlto man git-repack.xml
Writing git-repack.1 for refentry
rm git-repack.xml
$ dpkg -l asciidoc xmlto
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii asciidoc 7.0.2-4 Highly configurable text format for writing
ii xmlto 0.0.18-5 XML-to-any converter
$ grep '^[A-Z][a-z]* by' git-repack.1
Written by Linus Torvalds <torvalds@osdl\&.org>
Documentation by Ryan Anderson <ryan@michonline\&.com>
$ exit
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Junio C Hamano @ 2005-12-13 1:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512121720150.15597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So I think your diffcore-break.c patch is much more appropriate: it also
> fixes the bug, but it fixes it by virtue of realizing that the delta
> cannot matter and thus should never even be computed.
Agreed, redone and pushed out.
^ 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