* Re: [PATCH (tig)] Infrastructure for tig rpm builds.
From: Jonas Fonseca @ 2007-05-29 20:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705281054.05376.jnareb@gmail.com>
Hej Jakub,
Jakub Narebski <jnareb@gmail.com> wrote Mon, May 28, 2007:
> Adds RPM_VERSION to Makefile and new make targets: tig.spec, dist, and
> rpm. A simple 'make rpm' will build the rpm. Also adds tig.spec.in
> which is used to generate tig.spec.
Thank you. :)
> Accidentally VERSION (and adding -DVERSION=$(VERSION) to CFLAGS) is
> now defined always, even if we do not compile from the "live" tig
> repository.
Yeah, this is probably a good idea; the same goes for moving version
info to a file instead of having it in tig.c.
> Minimally tested (meaning "make rpm" from tig repository works).
Trying 'make rpm' on ubuntu 7.04 I get:
$ rpmbuild -ta tig-0.6.g2463b4e.tar.gz
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: Group field must be present in package: (main package)
error: License field must be present in package: (main package)
$ ls -l /usr/src/rpm/SPECS/
total 0
-rw------- 1 root root 0 2007-05-29 21:46 tar: Pattern matching characters used in file names. Please,
Strange.
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> 'tig.spec.in' is based on 'git.spec.in' from git repository.
>
> This is the initial, minimal version. For example it does not add
> TIG-VERSION-GEN file and the rest of versioning infrastructure that is
> used in git Makefile.
I would prefer to do without. ;)
> Commands used to get version string (in RPM_VERSION) suitable as a
> version field in the rpm can, most probably, be improved. Perhaps
> (with the new git-describe output) we should put closest version tag
> as version of tig in rpm, and distance from the tag (perhaps plus 1)
> as release number (in the rpm sense).
>
> TODO: Change '--without docs' to '--with rebuild-docs' and use
> pre-generated docs when creating rpm, instead of generating them (and
> requiring asciidoc, xmlto and docbook2pdf to build rpm if we want tig
> documentation).
Yeah, once the "official" tarballs contains the version info, this
sounds like a good idea.
> P.S. I have build tig-0.6.4.g9eded37-1.i386.rpm using "make rpm" from
> tig repository, and installed it without problems, but when trying to
> build it again _without network_ it failed on building
> manual.pdf. Error log attached.
Looks like some problems with the SGML catalogs info.
> asciidoc-7.1.2-2.fc3.rf
> docbook-dtds-1.0-26
> docbook-style-dsssl-1.79-1
> docbook-style-xsl-1.68.1-1
> docbook-utils-0.6.14-4
> docbook-utils-pdf-0.6.14-4
> jadetex-3.12-13
> openjade-1.3.2-16
>
> I think we can skip generation of manual.pdf, and generate it only on
> request (e.g. "make doc-pdf"), or using doc-man and doc-html in place
> of doc in the spec file... but this is better left for the next
> commit.
Good idea, PDF is not essential and probably suboptimal to either of the
HTML versions of the manual.
> By the way, why do you use xmlto and docbook2pdf, instead of a2x from
> asciidoc package?
It is a fairly recent addition to the asciidoc. Besides, I just tried it
and it seems to be completely unusable on ubuntu because of the way it
has been packaged; it cannot find required files.
> .gitignore | 2 ++
> Makefile | 34 ++++++++++++++++++++++++++++++++--
> tig.spec.in | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 90 insertions(+), 2 deletions(-)
> create mode 100644 tig.spec.in
>
> diff --git a/.gitignore b/.gitignore
> index 8f6aa93..f7ab840 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -2,3 +2,5 @@ manual.html-chunked
> manual.pdf
> manual.toc
> tig
> +tig.spec
> +tig-*.tar.gz
> diff --git a/Makefile b/Makefile
> index 06a5d6a..45c833b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -18,8 +18,16 @@ DOCS = $(DOCS_MAN) $(DOCS_HTML) \
> ifneq (,$(wildcard .git))
> VERSION = $(shell git-describe)
> WTDIRTY = $(shell git-diff-index --name-only HEAD 2>/dev/null)
> -CFLAGS += '-DVERSION="$(VERSION)$(if $(WTDIRTY),-dirty)"'
> +else
> +GEN_VER="tig-0.6.TIG"
> +VERSION = $(shell test -f version && cat version || echo "$(GEN_VER)")
> endif
> +CFLAGS += '-DVERSION="$(VERSION)$(if $(WTDIRTY),-dirty)"'
> +RPM_VERSION = $(subst tig-,,$(VERSION))
> +RPM_VERSION := $(subst -,.,$(RPM_VERSION))
I will probably try to simplify and clean this up a bit.
> +
> +TARNAME=tig-$(RPM_VERSION)
> +
>
> all: $(PROGS)
> all-debug: $(PROGS)
> @@ -57,6 +65,9 @@ install-doc: install-doc-man install-doc-html
> clean:
> rm -rf manual.html-chunked
> rm -f $(PROGS) $(DOCS) core *.xml
> + rm -f *.spec
> + rm -rf $(TARNAME)
> + rm -f $(TARNAME).tar.gz
>
> spell-check:
> aspell --lang=en --check tig.1.txt tigrc.5.txt manual.txt
> @@ -64,7 +75,7 @@ spell-check:
> strip: all
> strip $(PROGS)
>
> -.PHONY: all all-debug doc doc-man doc-html install install-doc install-doc-man install-doc-html clean spell-check
> +.PHONY: all all-debug doc doc-man doc-html install install-doc install-doc-man install-doc-html clean spell-check dist rpm
>
> manual.html: manual.toc
> manual.toc: manual.txt
> @@ -119,3 +130,22 @@ sync-docs:
> make doc
> cg commit -m "Sync docs"
> cg switch master
> +
> +tig.spec: tig.spec.in
> + sed -e 's/@@VERSION@@/$(RPM_VERSION)/g' < $< > $@+
> + mv $@+ $@
> +
> +dist: tig.spec
> + git-archive --format=tar \
> + --prefix=$(TARNAME)/ HEAD^{tree} > $(TARNAME).tar
> + @mkdir -p $(TARNAME)
> + @cp tig.spec $(TARNAME)
> + @echo $(VERSION) > $(TARNAME)/version
> + tar rf $(TARNAME).tar \
> + $(TARNAME)/tig.spec \
> + $(TARNAME)/version
> + @rm -rf $(TARNAME)
> + gzip -f -9 $(TARNAME).tar
Does the .spec file need to be in the tarball for rpm to work? I mean,
if it can be generated from .spec.in, I would rather have the rpm target
create it?
> +rpm: dist
> + rpmbuild -ta $(TARNAME).tar.gz
> diff --git a/tig.spec.in b/tig.spec.in
> new file mode 100644
> index 0000000..2ce6cdb
> --- /dev/null
> +++ b/tig.spec.in
> @@ -0,0 +1,56 @@
> +# -*- mode: rpm-spec-mode; encoding: utf-8; -*-
> +# Pass '--without docs' to rpmbuild if you don't want the documentation
> +
> +Summary: Tig: text-mode interface for git
> +Name: tig
> +Version: @@VERSION@@
> +Release: 1%{?dist}
> +License: GPL
> +Group: Development/Tools
> +Vendor: Jonas Fonseca <fonseca@diku.dk>
> +URL: http://jonas.nitro.dk/tig/
> +Source: http://jonas.nitro.dk/tig/releases/%{name}-%{version}.tar.gz
> +BuildRequires: ncurses-devel%{!?_without_docs:, xmlto, asciidoc > 6.0.3, /usr/bin/docbook2pdf}
Is the last entry a shorthand for the doc dependencies you listed above?
> +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> +Requires: git-core, ncurses
> +
> +%description
> +Tig is a git repository browser that additionally can act as a pager
> +for output from various git commands.
> +
> +When browsing repositories, it uses the underlying git commands to
> +present the user with various views, such as summarized revision log
> +and showing the commit with the log message, diffstat, and the diff.
> +
> +Using it as a pager, it will display input from stdin and colorize it.
> +
> +%prep
> +%setup -q
> +
> +%build
> +CFLAGS="$RPM_OPT_FLAGS -DVERSION=tig-%{version}-%{release}"
> +%{__make} %{_smp_mflags} \
> + prefix=%{_prefix} \
> + all %{!?_without_docs: doc}
> +
> +%install
> +[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
> +CFLAGS="$RPM_OPT_FLAGS -DVERSION=tig-%{version}-%{release}"
> +%{__make} %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT \
> + prefix=%{_prefix} bindir=%{_bindir} mandir=%{_mandir} \
> + install %{!?_without_docs: install-doc-man}
> +
> +%clean
> +[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
> +
> +%files
> +%defattr(-,root,root)
> +%{_bindir}/*
> +%doc README COPYING INSTALL SITES BUGS TODO tigrc
I don't know if manual.txt should perhaps be included if
HTML and PDF files will not be generated.
> +%{!?_without_docs: %{_mandir}/man1/*.1*}
> +%{!?_without_docs: %{_mandir}/man5/*.5*}
> +%{!?_without_docs: %doc *.html *.pdf}
> +
> +%changelog
> +* Mon May 28 2007 Jakub Narebski <jnareb@gmail.com>
> +- Initial tig spec file
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Jim Meyering @ 2007-05-29 20:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0705281957160.26602@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, 28 May 2007, Jim Meyering wrote:
>>
>> Um... maybe you've forgotten that this patch fixes a hole in the
>> "old code" (git.c). Many git tools ignore write (ENOSPC) failures.
>
> Maybe you have not noticed, but my argument has ben about EPIPE.
Ha ha. That's a good one.
The point was that even you must see that your
"[Jim's] WHOLE patch is crap" statement was wrong.
>> 1) Continue to ignore EPIPE write failure: can obscure real errors.
>> BTW, Linus, don't you agree? You never commented on this point.
>
> THAT'S THE ONLY THING I'VE BEEN COMMENTING ON!
>
> They aren't "obscure real errors". EPIPE is neither obscure _nor_ an
> error.
Reread #1, above.
"ignore EPIPE write failure: can obscure real errors" (using "obscure"
as a verb, not an adjective) means that ignoring EPIPE failure can cause
git commands to hide/mask/paper-over a real, conceptual error like this:
# This is obviously bogus shell code:
# "cat" with an argument like this doesn't read stdin
git-rev-list HEAD | cat foo | ...
We're really on the head of a pin here, since the EPIPE test
makes a difference only when SIGPIPE is being ignored (unusual).
Note that ignoring SIGPIPE can cause gross inefficiencies or
even expose bugs. E.g., On Solaris 10, this infloops:
(trap '' PIPE; /bin/yes) |head -1
so there are good reasons *not* to ignore SIGPIPE. Add to that the fact
that the condition provoking an EPIPE is not *that* common, and you
begin to see that even if EPIPE is a little different, it doesn't matter
enough to justify polluting every application file-close test with an
EPIPE exemption.
> The code-paths where you removed EPIPE handlign have two cases:
> - SIGPIPE happens: you made no change
> - SIGPIPE diesn't happen: you broke the code.
>
> So remind me again, why the hell do you think your patch is so great and
> so important,
Whoa! I guess you had a bad day, yesterday.
I try to be humble, and certainly have not been crowing that this
tiny patch is "so great and so important." However, I did defend it
when you claimed that the whole thing was crap.
> considering that it broke real code, and made things worse?
I believe it is an IMPROVEMENT to make such mistakes detectable (exit
nonzero), and that the risk of annoying users with EPIPE diagnostics is
minimal. You seem to think there would be some outpouring of "broken
pipe" errors, but since so few Porcelains ignore SIGPIPE, I disagree.
However, it's an improvement only in the unusual event that SIGPIPE is
being ignored, which is also when an application may output the "broken
pipe" error. IMHO, these conditions are rare enough (now) that there's
no point in making an exception for EPIPE everywhere.
> And why don't you just admit that EPIPE is special, isn't an error, and
> shouldn't be complained about? If you get EPIPE on the write, it means
> "the other end didn't care". It does NOT mean "I should now do a really
> annoying message".
Sure, EPIPE is special, but it is so unusual now that it's not
worth even the small added complexity to treat it specially in all
application code.
> It's that simple. You seem to admit that SIGPIPE handling in bash should
> have been fixed, and that it was annoying to complain about it there. Why
Yes. When bash-3.0 announced each process-killing-via-SIGPIPE with e.g.,
/some/script: line 2: 31994 Broken pipe seq 99999
that was a big deal because it affected many scripts.
> can't you just admit that it's annoyign and wrong to complain about the
> same thing when it's EPIPE?
If it happened a lot, it *would* be annoying, but that's just it:
it doesn't happen much at all anymore.
Also, no one is complaining about EPIPE diagnostics from any of
the GNU coreutils, and I take that as a good indication that there
is no problem.
^ permalink raw reply
* Re: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Jim Meyering @ 2007-05-29 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Roeland, git
In-Reply-To: <7v4plwd6f0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Subject: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
>> ...
...
> I do not think anybody has much objection about the change to
> handle_internal_command() in git.c you made. Earlier we relied
> on exit(3) to close still open filehandles (while ignoring
> errors), and you made the close explicit in order to detect
> errors.
Hi Junio,
> But "to be consistent" above is not a very good justification.
I know that well, now, especially after all of my fruitless
justification on this list.
> In the presense of shells that give "annoying" behaviour (we
> have to remember that not everybody have enough privilege,
> expertise, or motivation to update /bin/sh or install their own
> copy in $HOME/bin/sh), "EPIPE is different from other errors" is
> a more practical point of view, I'd have to say. IOW, it is not
> clear if it is a good thing "to be consistent" to begin with.
In case you haven't seen it in the rest of this thread, the version of
bash you use does not change git's EPIPE-handling behavior. Using stock
bash-3.0 or bash-2.05b, you will get "Broken pipe" messages from some
scripts, but those are from bash, when it delivers the SIGPIPE signal,
and not from any application like git. The EPIPE-handling behavior can
come into play only when SIGPIPE is *ignored*.
> I would have appreciated if this were two separate patches. I
> think the EPIPE one is an independent issue. We could even make
> it a configuration option to ignore EPIPE ;-)
Ok. Even though I'm still convinced that ignoring EPIPE is no longer
justified, I've hamstrung my patch to do what people here want.
Note that I've also changed it not to print strerror(errno) when the
ferror(stdout) test is triggered. In that case, errno may well be
irrelevant. The ugliness of this addition is pretty striking, compared
to what I'm used to. FWIW, I would have liked to handle closing stdout
here with the same one-liner I use in coreutils: atexit (close_stdout);
but that requires autoconf/automake/gnulib infrastructure.
-----------------------------
From 42e3a6f676e9ae4e9640bc2ff36b7ab0b061a60e Mon Sep 17 00:00:00 2001
From: Jim Meyering <jim@meyering.net>
Date: Sat, 26 May 2007 13:43:07 +0200
Subject: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
Currently, when git-diff writes to a full device or gets an I/O error,
it fails to detect the write error:
$ git-diff |wc -c
3984
$ git-diff > /dev/full && echo ignored write failure
ignored write failure
git-log does the same thing:
$ git-log -n1 > /dev/full && echo ignored write failure
ignored write failure
Each and every git command should report such a failure.
Some already do, but with the patch below, they all do, and we
won't have to rely on code in each command's implementation to
perform the right incantation.
$ ./git-log -n1 > /dev/full
fatal: write failure on standard output: No space left on device
[Exit 128]
$ ./git-diff > /dev/full
fatal: write failure on standard output: No space left on device
[Exit 128]
You can demonstrate this with git's own --version output, too:
(but git --help detects the failure without this patch)
$ ./git --version > /dev/full
fatal: write failure on standard output: No space left on device
[Exit 128]
Note that the fcntl test (for whether the fileno may be closed) is
required in order to avoid EBADF upon closing an already-closed stdout,
as would happen for each git command that already closes stdout; I think
update-index was the one I noticed in the failure of t5400, before I
added that test.
Also, to be consistent with e.g., write_or_die, do not
diagnose EPIPE write failures.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
git.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 29b55a1..8258885 100644
--- a/git.c
+++ b/git.c
@@ -308,6 +308,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
for (i = 0; i < ARRAY_SIZE(commands); i++) {
struct cmd_struct *p = commands+i;
const char *prefix;
+ int status;
if (strcmp(p->cmd, cmd))
continue;
@@ -321,7 +322,23 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
die("%s must be run in a work tree", cmd);
trace_argv_printf(argv, argc, "trace: built-in: git");
- exit(p->fn(argc, argv, prefix));
+ status = p->fn(argc, argv, prefix);
+
+ /* Close stdout if necessary, and diagnose any failure
+ other than EPIPE. */
+ if (fcntl(fileno (stdout), F_GETFD) >= 0) {
+ errno = 0;
+ if ((ferror(stdout) || fclose(stdout))
+ && errno != EPIPE) {
+ if (errno == 0)
+ die("write failure on standard output");
+ else
+ die("write failure on standard output"
+ ": %s", strerror(errno));
+ }
+ }
+
+ exit(status);
}
}
--
1.5.2.73.g18bece
^ permalink raw reply related
* [PATCH] diff-delta: use realloc instead of xrealloc
From: Martin Koegler @ 2007-05-29 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Commit 83572c1a914d3f7a8dd66d954c11bbc665b7b923 changed many
realloc to xrealloc. This change was made in diff-delta.c too,
although the code can handle an out of memory failure.
This patch reverts this change in diff-delta.c.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
diff-delta.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff-delta.c b/diff-delta.c
index 17757d2..faf96e4 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -388,7 +388,7 @@ create_delta(const struct delta_index *index,
outsize = max_size + MAX_OP_SIZE + 1;
if (max_size && outpos > max_size)
break;
- out = xrealloc(out, outsize);
+ out = realloc(out, outsize);
if (!out) {
free(tmp);
return NULL;
--
1.5.2.846.g9a144
^ permalink raw reply related
* Re: GIT on MinGW problem
From: Nguyen Thai Ngoc Duy @ 2007-05-29 18:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Marius Storm-Olsen, git
In-Reply-To: <465C4B0E.C34795B@eudaptics.com>
On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Nguyen Thai Ngoc Duy wrote:
> > I'd suggest create a small C wrapper to launch gitk. It would be much
> > easier that way IMHO.
>
> Doh! You're right! It's even there already, right before our eyes:
>
> pointy..clicky..pointy..clicky (aka: cp gitk git-k)
>
> $ git k
>
> :)
Maybe we should teach git.c to try gitk if git-k is not found ;)
> -- Hannes
>
>
--
Duy
^ permalink raw reply
* Re: [RFC] super indexes to span multiple packfiles
From: Geert Bosch @ 2007-05-29 17:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Dana How, Nicolas Pitre
In-Reply-To: <20070529071622.GA8905@spearce.org>
[resent, my email client doesn't like Shawn's name :( ]
On May 29, 2007, at 03:16, Shawn O. Pearce wrote:
> In the single packfile case (everything repacked into one) this
> is not faster; its actually slightly slower. With a handful of
> smaller recent packfiles (such as immediately after a git-fetch)
> it breaks even with the stock code. I haven't tested it yet with
> a high number of packfiles (e.g. 20). I suspect it won't gain us
> a lot up there either...
>
> So in short this shouldn't be applied, because its not any faster,
> and is sometimes slower. But I'm tossing it out here for discussion.
> I'm also not documenting the new super-index command line program,
> because I don't think this should be applied. ;-)
A super-index should have a fan-out factor dependent on the number
of entries in the index. So an index with 2^20 entries would have
2^16 fan-outs. So there will be about 2^4 entries per fanout slot.
Each slot only contains the next byte of the key, so in this case
bit 16 through 23 (numbering bits starting at zero).
The format would look like:
* Header
* Fan-out table (approx 2 bits/object)
* Next key-byte table (1 byte/object)
* Object info (offset into packfile(s) and/or rest of object name)
So, after a single lookup to get to about the right entry, only
an expected 16 single-byte comparisons are necessary to find the
entry that is needed or return a "entry doesn't exist".
Below I repeat a previous suggestion for a new pack file index.
I'm happy to implement this, although it seems that there are
so many pending index/pack file format changes that this may
be premature. If the pack file itself will have the full SHA-1,
the
(snipped from <http://article.gmane.org/gmane.comp.version-
control.git/43545>)
Multiple Pack Index
The linear search through packs is very inefficient
with large numbers of packs. Having packs much larger
than a GB is also problematic, due to this as repacking
and otherwise modifying packs gets very expensive.
Another issue is that binary search requires many
semi-random accesses spread over the index. Finally,
most of the information actually read consists of
SHA1's that are never needed.
This proposed pack index format does not focus on reducing
used disk space, but instead aims to reduce the number
of blocks that needs to be read to perform lookups.
This is done using three techniques:
1) scale the number of fan-out bins with the number
of objects in the index, keeping the expected
number of objects in each bin constant
2) take advantage of 1) by only storing a few bits
following the common prefix in the main lookup table
as a discriminant. Store the rest of the SHA1 and
the pack offest in a separate, parallel, object table.
3) Instead of repeating the variable-length common prefix
and the discriminant, use the space for the prefix
for a pack identifier and omit the discriminant altogether.
For a repository with N objects and highest PACK_NR P,
the total space used for the index is bounded by
24 * (N + P) bytes, if N is at least 512 and N >= 512 * P.
Limits:
- Maximum number of packs: 2^27
- Maximum number of objects: 2^40
- Maximum repository size: 2^48 bytes
<PACK_INDEX>
: <IDX_PACK_LIST>
<IDX_FANOUT_BITS>
<IDX_FANOUT_TABLE>
<IDX_LOOKUP_TABLE>
<IDX_OBJECT_TABLE>
<IDX_CHECKSUM>
;
<IDX_PACK_LIST>
: <IDX_PACK_LIST_ENTRIES>
<ZERO_32> <IDX_PACK_LIST_CHECKSUM>
;
<IDX_PACK_LIST_ENTRIES>
# List of packs sorted by ascending PACK_ID
: ( <IDX_PACK_NR> <PACK_ID> ) *
;
<PACK_ID>
# 20-byte binary representation of the 40 hex-digit
# value PACK_ID_HEX, such that pack-${PACK_ID_HEX}.pack
# is the name of the pack file
;
<IDX_PACK_NR>
# 32-bit unsigned integer in network order, with the same
# value as the preceding <IDX_PACK_NR> (or zero for the
# first entry), increased by the size of the pack file in
# bytes, divided by 2^32 and rounded up.
;
<ZERO_32>
# 32-bit zero
;
<IDX_PACK_LIST_CHECKSUM>
# 20-byte SHA1 of <IDX_PACK_LIST_ENTRIES>
;
<IDX_FANOUT_BITS>
# 1 byte with the smallest value N between 8 and 35,
# such that 2^(N - 8) greater than or equal to the
# largest IDX_PACK_NR in the IDX_PACK_LIST, and such that
# 2^(N+5) is greater than or equal to the total number
# of objects in all packs.
;
<IDX_FANOUT_TABLE>
# Table of 2^${IDX_FANOUT_BITS} entries
: ( <IDX_PARTIAL_COUNT> ) *
;
<IDX_PARTIAL_COUNT>
# 40 bit, network byte order, binary integer of the count of
# objects in the pack file with the high IDX_FANOUT_BITS bits of
# the object ID less than or equal to the index of the count,
# starting from zero.
;
<IDX_LOOKUP_TABLE>
# One 8-bit key per object indexed by the pack
: ( <IDX_LOOKUP_KEY> ) *
;
<IDX_LOOKUP_KEY>
# Bits IDX_FANOUT_BITS through IDX_FANOUT_BITS + 7 of the
# object ID.
;
<IDX_OBJECT_ENTRY>
# The total width of each entry is 22 bytes
: ( <IDX_PACK_REF> <IDX_OBJECT_ID> <IDX_OFFSET> ) *
;
<IDX_PACK_REF>
# A IDX_FANOUT_BITS - 8 bit wide integer value, equal to
# PACK_NR of pack preceding the one containing the object
# (or zero, if object is in first pack) increased with the
# pack offset divided by 2^32.
;
<IDX_OBJECT_ID>
# Bits IDX_FANOUT_BITS + 8 .. 159 of the object ID
;
<IDX_OFFSET>
# 32-bits offset in network byte order
;
^ permalink raw reply
* Re: sbuild (or whatever) integration
From: Jan Hudec @ 2007-05-29 17:15 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87ps4kasku.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
On Tue, May 29, 2007 at 11:26:41 +0200, Florian Weimer wrote:
> * Jan Hudec:
>
> > IMHO generic tools won't help you much, because every other command is Debian
> > specific.
>
> Yeah, and I mainly wanted to reuse process, not code. Thanks for your
> comments.
The process is definitely sensible. Also I mentioned the git
contrib/continuous scripts to help you schedule the builds.
Regards,
Jan
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] super indexes to span multiple packfiles
From: Avi Kivity @ 2007-05-29 16:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn O. Pearce, git, Dana How, Nicolas Pitre
In-Reply-To: <9e4733910705290905m66dd3081ubda9b92a707fc903@mail.gmail.com>
Jon Smirl wrote:
>
> My work with databases leads me to believe that figuring out how to
> pack everything into a smaller space always beats efforts put into
> incrementally improving the indexing scheme. Packing into a smaller
> space reduces the total IO needs and that's always a winner.
>
Another way to achieve that is to place objects that are accessed
together nearby, and issue a larger read so as to bring them into
cache. I imagine that placing commit objects and associated tree and
blobs in history order should help here (but maybe git already does
that, I'm not familiar with the internals).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC] super indexes to span multiple packfiles
From: Nicolas Pitre @ 2007-05-29 16:31 UTC (permalink / raw)
To: Avi Kivity; +Cc: Jon Smirl, Shawn O. Pearce, git, Dana How
In-Reply-To: <465C52D3.3010605@qumranet.com>
On Tue, 29 May 2007, Avi Kivity wrote:
> Jon Smirl wrote:
> >
> > My work with databases leads me to believe that figuring out how to
> > pack everything into a smaller space always beats efforts put into
> > incrementally improving the indexing scheme. Packing into a smaller
> > space reduces the total IO needs and that's always a winner.
> >
>
> Another way to achieve that is to place objects that are accessed together
> nearby, and issue a larger read so as to bring them into cache. I imagine
> that placing commit objects and associated tree and blobs in history order
> should help here (but maybe git already does that, I'm not familiar with the
> internals).
GIT already does that indeed, except for commit objects which are all
together for better performances on history traversal operations.
After a fresh repack, the checkout of the latest revision should produce
a nearly perfect linear and contigous access into the early portion of
the same pack. Things will get more random with access to objects
further back in history of course, but those objects are less likely to
be accessed as often.
Nicolas
^ permalink raw reply
* Re: [RFC] super indexes to span multiple packfiles
From: Nicolas Pitre @ 2007-05-29 16:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn O. Pearce, git, Dana How
In-Reply-To: <9e4733910705290905m66dd3081ubda9b92a707fc903@mail.gmail.com>
On Tue, 29 May 2007, Jon Smirl wrote:
> Object's are not accessed in random order with git. Once an object
> reference hits a pack file it is very likely that following references
> will hit the same pack file. That's because you always find object
> SHA's by following the chains.
>
> So first place to look for an object is the same place the previous
> object was found. If it isn't there order the search of the pack files
> by creation data (just a heuristic). Make this list a circle and start
> the search in the pack where the previous object was found. This can
> all be done with the existing indexes.
>
> I haven't been reading all of the messages on this subject, but is
> this strategy enough to eliminate the need for a super index?
I think it could.
Personally I'm not a big fan of the super index notion. It needs extra
maintenance to keep in synch, and when it is not in synch it requires
extra work at run time to fall back to traditional lookup. And Shawn's
testing didn't provide significant performance gains either.
But a simple heuristic like the presumption that the next object is
likely to be in the same pack as the previous is the kind of thing that
could provide significant improvements with really little effort.
Nicolas
^ permalink raw reply
* Re: [RFC] super indexes to span multiple packfiles
From: Jon Smirl @ 2007-05-29 16:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Dana How, Nicolas Pitre
In-Reply-To: <20070529071622.GA8905@spearce.org>
Object's are not accessed in random order with git. Once an object
reference hits a pack file it is very likely that following references
will hit the same pack file. That's because you always find object
SHA's by following the chains.
So first place to look for an object is the same place the previous
object was found. If it isn't there order the search of the pack files
by creation data (just a heuristic). Make this list a circle and start
the search in the pack where the previous object was found. This can
all be done with the existing indexes.
I haven't been reading all of the messages on this subject, but is
this strategy enough to eliminate the need for a super index?
If you still need a super index, note that it may be good enough for
it to only contain the SHA's for objects that are externally
referenced. This index would be small and simply point to the correct
pack file index to find the object in. You could add a list of
dangling links to each packfile index to assist with building this
super index.
My work with databases leads me to believe that figuring out how to
pack everything into a smaller space always beats efforts put into
incrementally improving the indexing scheme. Packing into a smaller
space reduces the total IO needs and that's always a winner.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Sixt @ 2007-05-29 15:47 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, Marius Storm-Olsen, git
In-Reply-To: <fcaeb9bf0705290828j3703cfa9g11f2f7afb17a8c91@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> I'd suggest create a small C wrapper to launch gitk. It would be much
> easier that way IMHO.
Doh! You're right! It's even there already, right before our eyes:
pointy..clicky..pointy..clicky (aka: cp gitk git-k)
$ git k
:)
-- Hannes
^ permalink raw reply
* Re: GIT on MinGW problem
From: Nguyen Thai Ngoc Duy @ 2007-05-29 15:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Marius Storm-Olsen, git
In-Reply-To: <465C3502.BE134BC9@eudaptics.com>
On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Johannes Schindelin wrote:
> > There are at least three different cmd.exe that _I_ encountered: NT4.0,
> > 2000 and XP. All of them have different features. None of my scripts
> > worked without _heavy_ workarounding on all of them.
> >
> > But I think a .lnk file would be easier to create, and more portable,
> > right?
>
> If:
>
> 1. there is a .lnk file named gitk.lnk with target for example:
>
> D:\MSYS\1.0\mingw\bin\wish84.exe D:\MSYS\1.0\git\bin\gitk
>
> 2. you change PATHEXT to include '.LNK'.
>
> then gitk can be invoked with varying arguments from CMD. I've tested
> this only on W2k. Point 2 looks hackish and dangerous to me.
I'd suggest create a small C wrapper to launch gitk. It would be much
easier that way IMHO.
--
Duy
^ permalink raw reply
* Re: git-svn dcommit failure
From: Florian Weimer @ 2007-05-29 15:20 UTC (permalink / raw)
To: git
In-Reply-To: <20070529144742.GG1025@.intersec.eu>
* Pierre Habouzit:
> On Tue, May 29, 2007 at 11:35:10AM +0200, Florian Weimer wrote:
>> * Florian Weimer:
>>
>> > This with git-svn 1.5.1.4-2 on something that is quite close to Debian
>> > etch.
>>
>> Same issue with 1.5.2~rc3-2.
>
> Are you using ControlMaster in your ssh setup in auto/autoask mode? (I
> assume your repository is svn+ssh). If yes, then you *have* to start a
> persistent ssh connection before you do anything else:
No. It's svn+ssh (with a custom connect script), but without the
controlchan extension. Subversion works fine and lets me commit
changes.
After manually committing the offending changes via Subversion, I
git-svn has begun to work again, too (but I haven't yet tried to
change the same files).
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Sixt @ 2007-05-29 14:49 UTC (permalink / raw)
To: hanwen; +Cc: Marius Storm-Olsen, git
In-Reply-To: <f329bf540705290729q18b8ed10t5e61a65b75d3759@mail.gmail.com>
Han-Wen Nienhuys wrote:
>
> 2007/5/29, Johannes Sixt <J.Sixt@eudaptics.com>:
>
> > > I get that here too, no matter what I set the mount point to be, and
> > > without the fstab file at all.
> >
> > When I inserted '/usr/bin/sort' I had checked for 'which sort' on my
> > Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably
> > the canonical path to sort on any *nix. Will change that. But is this
> > also true for 'find'?
>
> I suggest that you add $PATH appropriately (prepending /bin and
> /usr/bin/ ) and then
> let the OS figure it out. The other option is to write an autoconf
> test to discover the proper path.
'sort' (and 'find' for that matter) is not only used by the build
scripts, but also by some shell scripts of the toolset. Hence, the path
would have to be modified for each 'git foo' invocation, IOW, by git.exe
itself. I don't like this solution.
The alternative, to force the user to put his $MSYSDIR/bin before $WINNT
(which would require admin rights, btw, because the system's PATH must
be modified), I like even less.
I've to think a bit more about this.
-- Hannes
^ permalink raw reply
* Re: GIT on MinGW problem
From: Marius Storm-Olsen @ 2007-05-29 14:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <465C2999.677860A6@eudaptics.com>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
Johannes Sixt said the following on 29.05.2007 15:24:
>> Looking at the docs for cmd's call (run 'help call'), I see now that
>> it can be written
>> %~dp0gitk
>> as well..
>
> But... the docs also say that this stuff is only available if command
> extensions are turned on. Are they on by default?
>
> (I cannot tell because I remember faintly that I fiddled with the
> corresponding registry setting in the past, but don't know whether it
> was on or off at the beginning.)
Ok, MSDN says it on by default on XP, while other docs say its on by
default without specifying any platforms. Also, it might be that the
%~dp0 construct is only supported on later versions of the cmd
extension too (I don't have NT 4, so I can't test this), so to be on
the safe side you can do this:
----
@echo off
REM This GOTO relies on the hack that command.com only supports
REM 8 character labels, so it reads 'goto _Windows'
goto :_WindowsNT
REM Command.com jumps here
:_Windows
wish84.exe "C:\Git\usr\bin\gitk" %1 %2 %3 %4 %5 %6 %7 %8 %9
REM NOTE! If you install Git in some other path, and use
REM command.com, you need to replace the path above
goto :EOF
REM Cmd.exe jumps here
:_WindowsNT
if "%1" neq "ensureExt" (
REM Call the script again with cmd /X to explicitly turn on Command Extensions
%COMSPEC% /X /C "%0 ensureExt %*"
goto :EOF
)
REM If our CMD Extension version is less than 2, we might not support the %~dp0
REM construct so, just do the normal _Windows call instead. (This should only
REM happen on old Windows NT 4, where the extension is not so sophisticated
if not cmdextversion 2 (
call :_Windows %2 %3 %4 %5 %6 %7 %8 %9
goto :EOF
)
start wish84.exe "%~dp0gitk" %2 %3 %4 %5 %6 %7 %8 %9
:EOF
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-29 14:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, git
In-Reply-To: <465C184F.F6053C0C@eudaptics.com>
2007/5/29, Johannes Sixt <J.Sixt@eudaptics.com>:
> > I get that here too, no matter what I set the mount point to be, and
> > without the fstab file at all.
>
> When I inserted '/usr/bin/sort' I had checked for 'which sort' on my
> Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably
> the canonical path to sort on any *nix. Will change that. But is this
> also true for 'find'?
I suggest that you add $PATH appropriately (prepending /bin and
/usr/bin/ ) and then
let the OS figure it out. The other option is to write an autoconf
test to discover the proper path.
> > Also, the /bin/gitk.bat file should rather be
> > @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
> > than the current hardcoded path. (Probably won't work with
> > command.com, but who uses that for development nowadays anyways, right ;-)
>
> Nice trick! But don't try this at home without parental guidance! It
> fills your screen with recursive console window invocations of itself.
>
> I put this into gitk.cmd (didn't try .bat):
>
> @start wish84.exe "%~d0%~p0gitk" %*
>
> assuming wish84 is in the PATH (which is probably a sane assumption
> because either it is part of the installer, in which case it should have
> set up the PATH, or you have Tcl/Tk installed for some other reason, in
> which case you will want to have it in the PATH, too).
>
> Futhermore, I like to have the GUI sent into the background
> automatically and without opening another console window, hence, the use
> of 'start'.
I'll have a look at this when I have time. What the hell is
%~d0%~p0
?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Sixt @ 2007-05-29 14:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0705291446170.4648@racer.site>
Johannes Schindelin wrote:
> There are at least three different cmd.exe that _I_ encountered: NT4.0,
> 2000 and XP. All of them have different features. None of my scripts
> worked without _heavy_ workarounding on all of them.
>
> But I think a .lnk file would be easier to create, and more portable,
> right?
If:
1. there is a .lnk file named gitk.lnk with target for example:
D:\MSYS\1.0\mingw\bin\wish84.exe D:\MSYS\1.0\git\bin\gitk
2. you change PATHEXT to include '.LNK'.
then gitk can be invoked with varying arguments from CMD. I've tested
this only on W2k. Point 2 looks hackish and dangerous to me.
-- Hannes
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-29 13:47 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, git
In-Reply-To: <465C2516.7040607@trolltech.com>
Hi,
On Tue, 29 May 2007, Marius Storm-Olsen wrote:
> Looking at the docs for cmd's call (run 'help call'), [...]
Which one?
There are at least three different cmd.exe that _I_ encountered: NT4.0,
2000 and XP. All of them have different features. None of my scripts
worked without _heavy_ workarounding on all of them.
But I think a .lnk file would be easier to create, and more portable,
right?
Ciao,
Dscho
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Sixt @ 2007-05-29 13:24 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, git
In-Reply-To: <465C2516.7040607@trolltech.com>
Marius Storm-Olsen wrote:
>
> Johannes Schindelin said the following on 29.05.2007 14:11:
> >> Also, the /bin/gitk.bat file should rather be
> >> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* than the current
> >> hardcoded path. (Probably won't work with command.com, but who
> >> uses that for development nowadays anyways, right ;-)
> >
> > We're open source, so we _can_ do better than leaving people stuck
> > on older hardware behind.
> >
> > And I don't know what this garbage means. (I checked with GMane,
> > and it looks the same there.) I'd rather have something readable,
> > even if it is slightly slower or has to be adjusted when
> > installing.
>
> %~d0 = expands %0 to a drive letter only
> %~p0 = expands %0 to a path only
>
> so, for
> C:\foo\bar\baz\gitk.bat
> %~d0%~p0gitk would expand to
> C:\foo\bar\baz\gitk
>
> Looking at the docs for cmd's call (run 'help call'), I see now that
> it can be written
> %~dp0gitk
> as well..
But... the docs also say that this stuff is only available if command
extensions are turned on. Are they on by default?
(I cannot tell because I remember faintly that I fiddled with the
corresponding registry setting in the past, but don't know whether it
was on or off at the beginning.)
-- Hannes
^ permalink raw reply
* Re: GIT on MinGW problem
From: Marius Storm-Olsen @ 2007-05-29 13:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0705291305540.4648@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
Johannes Schindelin said the following on 29.05.2007 14:11:
>> Also, the /bin/gitk.bat file should rather be
>> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* than the current
>> hardcoded path. (Probably won't work with command.com, but who
>> uses that for development nowadays anyways, right ;-)
>
> We're open source, so we _can_ do better than leaving people stuck
> on older hardware behind.
>
> And I don't know what this garbage means. (I checked with GMane,
> and it looks the same there.) I'd rather have something readable,
> even if it is slightly slower or has to be adjusted when
> installing.
%~d0 = expands %0 to a drive letter only
%~p0 = expands %0 to a path only
so, for
C:\foo\bar\baz\gitk.bat
%~d0%~p0gitk would expand to
C:\foo\bar\baz\gitk
Looking at the docs for cmd's call (run 'help call'), I see now that
it can be written
%~dp0gitk
as well..
Anyways, if people are critical to not supporting the command.com,
then you could do something like the following. (Note that for
command.com it would be the old behavior were you need to replace the
path if you install Git somewhere else, while for cmd.exe users it
will just work. I'm sure magic can be done to make it work with
command.com as well, but I'll leave that up to someone else to play with):
---
@echo off
REM This GOTO relies on the hack that command.com only supports
REM 8 character labels, so it reads 'goto _Windows'
goto :_WindowsNT
REM Command.com jumps here
:_Windows
wish84.exe "C:\Git\usr\bin\gitk" %1 %2 %3 %4 %5 %6 %7 %8 %9
REM NOTE! If you install Git in some other path, and use
REM command.com, you need to replace the path above
goto :EOF
REM Cmd.exe jumps here
:_WindowsNT
start wish84.exe "%~dp0gitk" %*
:EOF
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: handle non UTF-8 text
From: Jakub Narebski @ 2007-05-29 9:21 UTC (permalink / raw)
To: Petr Baudis, Martin Koegler; +Cc: git, Martin Langhoff, Martyn Smith
In-Reply-To: <20070528232139.GU4489@pasky.or.cz>
[Cc: authors of git-cvsserver]
On Tue, 29 May 2007, Petr Baudis wrote:
> On Mon, May 28, 2007 at 10:47:34PM CEST, Martin Koegler wrote:
>> gitweb assumes, that everything is in UTF-8. If a text contains invalid
>> UTF-8 character sequences, the text must be in a different encoding.
But it doesn't tell us _what_ is the encoding. For commit messages,
with reasonable new git, we have 'encoding' header if git known that
commit message was not in utf-8.
By the way, I winder why we don't have such header for tag objects
(i18n.tagEncoding ;-)...
>> This patch interprets such a text as latin1.
Meaning that it tries to recode text from latin1 (iso-8859-1) to utf-8
(not changing gitweb output encoding, which is utf-8).
It would be much better, and much easier at least for commit message
to add --encoding=utf-8 to git-rev-list / git-log invocation.
>> Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
>> ---
>> For correct UTF-8, the patch does not change anything.
>>
>> If commit/blob/... is not in UTF-8, it displays the text
>> with a very high probability correct.
It is commit (with its 'encoding' header, and `--encoding' option
we can use instead of doing it in gitweb, provided that git was
compiled with iconv support), tag (similar to commit, but IIRC
without 'encoding' header, and `--encoding' option), blob (with
no place to store encoding) and pathname in tree (which can be
different from blob encoding).
And I doubt very much about this "very high probability to be
correct".
>> As git itself is not aware of any encoding, I know no better
>> possibility to handle non UTF-8 text in gitweb.
>
> I don't think this is a reasonable approach; I actually dispute the high
> probability - in western Europe it's obvious to assume latin1, but does
> majority of users using non-ascii characters come from there? Or rather
> from central Europe (like me, Petr Baudiš? ;-))? Somewhere else?
I also don't think that hardcoding latin1 (iso-8859-1) as default
alternate encoding is a good idea. I don't think using iso-8859-1
(outside us-ascii) is _nowadays_ that common. On the other hand I think
that not all users of koi8r, eucjp or iso-2022-jp converted (and can
convert) to utf-8; latin1 users can.
And using latin1 (other encoding) _only_ when there is an invalid utf-8
sequence is not a good idea either; I think that that there are some
latin1 sequences outside us-ascii which are valid utf-8 sequences. That
kind of magic is wrong, wrong, wrong...
> If we do something like this, we should do it properly and look at
> configured i18n.commitEncoding for the project. (But as config lookup
> may be expensive, probably do it only when we need it.)
I think it would be best to make it into %feature, overridable
or not (which would look at i18n.commitEncoding instead of at
gitweb.commitEncoding, but still a feature).
About config lookup: we can either "borrow" config reading code in Perl
from git-cvsserver, perhaps via putting it into Git.pm. Or we can
implement at last core git support for dumping whole config in
unambiguous machine parseable output: "git config --dump", e.g.
key <LF> value <NUL>
or
key <NUL>
(the second for "boolean" variables without set value).
Having alternate (read-only) config parser has its advantages and
disadvantages. Advantage is that we avoid fork+exec (performance),
and having two implementations is always good for having format
standarized. Disadvantage is that is yet another code to maintain,
and that config parsing (even read-only config parsing) is a bit tricky
with current git config file format.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-29 12:11 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, git
In-Reply-To: <465C1252.9020801@trolltech.com>
Hi,
On Tue, 29 May 2007, Marius Storm-Olsen wrote:
> Johannes Sixt said the following on 29.05.2007 12:54:
> > Han-Wen Nienhuys wrote:
> > > Johannes Sixt escreveu:
> > > > * git without an correct git subcommand should list 20 or so
> > > > commands, but it doesn't. The list is just empty.
> > > there was a problem in generate cmd list, (I have sort in /bin/
> > > ). I recommend to add
> >
> > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the
> > same as /bin/sort.
> >
> > (For the curious ones: The MinGW port has to replace occurrences of
> > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be
> > picked up in shell scripts, because the latter usually comes first
> > in %PATH%^W$PATH. Same for 'find'.)
>
> I get that here too, no matter what I set the mount point to be, and without
> the fstab file at all.
>
> Also, the /bin/gitk.bat file should rather be
> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
> than the current hardcoded path. (Probably won't work with command.com, but
> who uses that for development nowadays anyways, right ;-)
We're open source, so we _can_ do better than leaving people stuck on
older hardware behind.
And I don't know what this garbage means. (I checked with GMane, and it
looks the same there.) I'd rather have something readable, even if it is
slightly slower or has to be adjusted when installing.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Sixt @ 2007-05-29 12:10 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <465C1252.9020801@trolltech.com>
Marius Storm-Olsen wrote:
>
> Johannes Sixt said the following on 29.05.2007 12:54:
> > Han-Wen Nienhuys wrote:
> >> Johannes Sixt escreveu:
> >>> * git without an correct git subcommand should list 20 or so
> >>> commands, but it doesn't. The list is just empty.
> >> there was a problem in generate cmd list, (I have sort in /bin/
> >> ). I recommend to add
> >
> > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the
> > same as /bin/sort.
> >
> > (For the curious ones: The MinGW port has to replace occurrences of
> > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be
> > picked up in shell scripts, because the latter usually comes first
> > in %PATH%^W$PATH. Same for 'find'.)
>
> I get that here too, no matter what I set the mount point to be, and
> without the fstab file at all.
When I inserted '/usr/bin/sort' I had checked for 'which sort' on my
Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably
the canonical path to sort on any *nix. Will change that. But is this
also true for 'find'?
> Also, the /bin/gitk.bat file should rather be
> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
> than the current hardcoded path. (Probably won't work with
> command.com, but who uses that for development nowadays anyways, right ;-)
Nice trick! But don't try this at home without parental guidance! It
fills your screen with recursive console window invocations of itself.
I put this into gitk.cmd (didn't try .bat):
@start wish84.exe "%~d0%~p0gitk" %*
assuming wish84 is in the PATH (which is probably a sane assumption
because either it is part of the installer, in which case it should have
set up the PATH, or you have Tcl/Tk installed for some other reason, in
which case you will want to have it in the PATH, too).
Futhermore, I like to have the GUI sent into the background
automatically and without opening another console window, hence, the use
of 'start'.
-- Hannes
^ permalink raw reply
* Re: GIT on MinGW problem
From: Marius Storm-Olsen @ 2007-05-29 11:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <465C064F.B9CE9379@eudaptics.com>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
Johannes Sixt said the following on 29.05.2007 12:54:
> Han-Wen Nienhuys wrote:
>> Johannes Sixt escreveu:
>>> * git without an correct git subcommand should list 20 or so
>>> commands, but it doesn't. The list is just empty.
>> there was a problem in generate cmd list, (I have sort in /bin/
>> ). I recommend to add
>
> Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the
> same as /bin/sort.
>
> (For the curious ones: The MinGW port has to replace occurrences of
> 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be
> picked up in shell scripts, because the latter usually comes first
> in %PATH%^W$PATH. Same for 'find'.)
I get that here too, no matter what I set the mount point to be, and
without the fstab file at all.
Also, the /bin/gitk.bat file should rather be
@"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
than the current hardcoded path. (Probably won't work with
command.com, but who uses that for development nowadays anyways, right ;-)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ 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