* Re: [PATCH 1/2] Teach Git how to parse standard power of 2 suffixes.
From: Junio C Hamano @ 2006-12-31 6:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061231061232.GC6106@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> Why? Are you allowing "1024 k"? Do we want to?
>
> Yes. Why not?
Stricter input checking. Allowing extra things later is far
easier than later finding problems with a looser way we started
from and having to tighten it.
^ permalink raw reply
* Re: [PATCH 1/2] Teach Git how to parse standard power of 2 suffixes.
From: Shawn O. Pearce @ 2006-12-31 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsa0inwr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >
> >> Why? Are you allowing "1024 k"? Do we want to?
> >
> > Yes. Why not?
>
> Stricter input checking. Allowing extra things later is far
> easier than later finding problems with a looser way we started
> from and having to tighten it.
Good point. I'm currently writing tests for this btw.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Teach Git how to parse standard power of 2 suffixes.
From: Junio C Hamano @ 2006-12-31 6:30 UTC (permalink / raw)
To: git
In-Reply-To: <20061231062618.GD6106@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>> > Junio C Hamano <junkio@cox.net> wrote:
>> >
>> >> Why? Are you allowing "1024 k"? Do we want to?
>> >
>> > Yes. Why not?
>>
>> Stricter input checking. Allowing extra things later is far
>> easier than later finding problems with a looser way we started
>> from and having to tighten it.
>
> Good point. I'm currently writing tests for this btw.
I have this already in the private 'master' I am prepareing for
pushout:
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index e48a4ec..a29caa0 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -391,5 +391,15 @@ EOF
test_expect_success "rename succeeded" "diff -u expect .git/config"
+test_expect_success numbers '
+
+ git-repo-config kilo.gram 1k &&
+ git-repo-config mega.ton 1m &&
+ k=$(git-repo-config --int --get kilo.gram) &&
+ test z1024 = "z$k" &&
+ m=$(git-repo-config --int --get mega.ton) &&
+ test z1048576 = "z$m"
+'
+
test_done
--
1.5.0.rc0.g81760
^ permalink raw reply related
* Re: [PATCH 1/2] Teach Git how to parse standard power of 2 suffixes.
From: Shawn O. Pearce @ 2006-12-31 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkkoinla.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I have this already in the private 'master' I am prepareing for
> pushout:
Does it pass? I can't get something similar to work here...
I must be a moron or something.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Teach Git how to parse standard power of 2 suffixes.
From: Shawn O. Pearce @ 2006-12-31 6:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkkoinla.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> +test_expect_success numbers '
> +
> + git-repo-config kilo.gram 1k &&
> + git-repo-config mega.ton 1m &&
> + k=$(git-repo-config --int --get kilo.gram) &&
> + test z1024 = "z$k" &&
> + m=$(git-repo-config --int --get mega.ton) &&
> + test z1048576 = "z$m"
> +'
> +
I'm a moron. I copied and pasted test_expect_failure here in my
own version. Commit and push yours, its just as good as mine,
but is shorter. :-)
--
Shawn.
^ permalink raw reply
* [PATCH] Add test case for update hooks in receive-pack.
From: Shawn O. Pearce @ 2006-12-31 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Verify that the update hooks work as documented/advertised. This is
a simple set of tests to check that the update hooks run with the
parameters expected, have their STDOUT and STDERR redirected to
the client side of the connection, and that their STDIN does not
contain any data (as its actually /dev/null).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
On top of my previous series of patches for receive-pack. This test
fails unless those patches are applied. ;-)
t/t5401-update-hooks.sh | 77 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/t/t5401-update-hooks.sh b/t/t5401-update-hooks.sh
new file mode 100755
index 0000000..8a879f7
--- /dev/null
+++ b/t/t5401-update-hooks.sh
@@ -0,0 +1,77 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Shawn O. Pearce
+#
+
+test_description='Test the update hook infrastructure.'
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo This is a test. >a &&
+ git-update-index --add a &&
+ tree0=$(git-write-tree) &&
+ commit0=$(echo setup | git-commit-tree $tree0) &&
+ git-update-ref HEAD $commit0 &&
+ git-clone ./. victim &&
+ echo We hope it works. >a &&
+ git-update-index a &&
+ tree1=$(git-write-tree) &&
+ commit1=$(echo modify | git-commit-tree $tree1 -p $commit0) &&
+ git-update-ref HEAD $commit1
+ '
+
+cat >victim/.git/hooks/update <<'EOF'
+#!/bin/sh
+echo "$@" >$GIT_DIR/update.args
+read x; echo -n "$x" >$GIT_DIR/update.stdin
+echo STDOUT update
+echo STDERR update >&2
+EOF
+chmod u+x victim/.git/hooks/update
+
+cat >victim/.git/hooks/post-update <<'EOF'
+#!/bin/sh
+echo "$@" >$GIT_DIR/post-update.args
+read x; echo -n "$x" >$GIT_DIR/post-update.stdin
+echo STDOUT post-update
+echo STDERR post-update >&2
+EOF
+chmod u+x victim/.git/hooks/post-update
+
+test_expect_success push '
+ git-send-pack ./victim/.git/ master >send.out 2>send.err
+ '
+test_expect_success 'hooks ran' '
+ test -f victim/.git/update.args &&
+ test -f victim/.git/update.stdin &&
+ test -f victim/.git/post-update.args &&
+ test -f victim/.git/post-update.stdin
+ '
+
+test_expect_success 'update hook arguments' '
+ echo refs/heads/master $commit0 $commit1 \
+ | diff -u - victim/.git/update.args
+ '
+test_expect_success 'post-update hook arguments' '
+ echo refs/heads/master \
+ | diff -u - victim/.git/post-update.args
+ '
+
+test_expect_failure 'update hook stdin is /dev/null' '
+ test -s victim/.git/update.stdin
+ '
+test_expect_failure 'post-update hook stdin is /dev/null' '
+ test -s victim/.git/post-update.stdin
+ '
+
+test_expect_failure 'send-pack produced no output' '
+ test -s send.out
+ '
+test_expect_success 'send-pack stderr contains hook messages' '
+ grep "STDOUT update" send.err &&
+ grep "STDERR update" send.err &&
+ grep "STDOUT post-update" send.err &&
+ grep "STDERR post-update" send.err
+ '
+
+test_done
--
1.5.0.rc0.g7200
^ permalink raw reply related
* Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.
From: Junio C Hamano @ 2006-12-31 8:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061231061122.GB6106@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Agreed. But as you point out...
>
>> If we could outlaw $GIT_DIR/index in a bare repository, then
>> ...
>> Alas, many public repositories you would see (e.g. check
>> kernel.org) have been primed with rsync of .git/ from
>> developer's working repository and have leftover index that is
>> otherwise unused. Because of this heavy historical baggage, I
>> suspect that it is rather hard to convince people to allow us to
>> use this technique.
>
> I almost coded the require_not_bare() to look for $GIT_DIR/index
> but didn't for the reasons you point out above. It is too bad that
> we didn't enforce the existance of the index file better in the past.
This, and this,...
>> ...
>> If we outlawed working-tree commands when $GIT_DIR environment
>> exists, how much hurt are we talking about, I wonder.
>
> I wouldn't be hurt, but I don't call Porcelain-ish unless I'm
> entering commands directly on the command line, and I never set
> GIT_DIR except in scripts, and even then its very rare and is more
> to point at a bare repository than one with a working directory.
> I suspect that probably isn't true for everyone.
> ...
> Why not just tell these users to setup the working directories with
> local .git directories and not use GIT_DIR?
suggest that we might want to bite the bullet and declare that
these things are not supported anymore in v1.5.0.
So far, especially after fixing the i18n issue in response to
qgit problem report, I do not think we have any serious backward
incompatibility that the users cannot opt out of that we need to
mention in v1.5.0 announcement. Even not the incompatibilities
the 'old news' section talks about are.
I think an index file in a bare repository is not what the user
wanted to have because it was useful, but is left there because
it does not hurt. So in that sense, I do not think we need to
ask users' permission to do this change, as long as we make sure
we give them enough advance warning.
I do not offhand think of a valid workflow that relies on
setting GIT_DIR in the environment and being able to run
working-tree commands, that cannot be worked around if we declar
that GIT_DIR is for our internal use (and no, naming the
directory other people call .git to .svn does not count as a
valid workflow), but I think this may be a bit more serious
change than the index file one.
Comments?
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2006-12-31 8:07 UTC (permalink / raw)
To: git
I am happy that we are making steady progress towards v1.5.0,
especially with tonight's handful fixes from Shawn.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* The 'master' branch has these since the last announcement.
Jakub Narebski (1):
Add info about new test families (8 and 9) to t/README
Johannes Schindelin (1):
Fix yet another subtle xdl_merge() bug
Junio C Hamano (12):
Work around http-fetch built with cURL 7.16.0
t5400 send-pack test: try a bit more nontrivial transfer.
Revert "read_directory: show_both option."
Fix 'git add' with .gitignore
commit re-encoding: fix confusion between no and default conversion.
t3900: test log --encoding=none
Documentation: i18n commit log message notes.
Documentation: minor rewording for git-log and git-show pages.
Move commit reencoding parameter parsing to revision.c
commit-tree: cope with different ways "utf-8" can be spelled.
i18n: drop "encoding" header in the output after re-coding.
Documentation/config.txt (and repo-config manpage): mark-up fix.
Shawn O. Pearce (8):
Force core.filemode to false on Cygwin.
Use PATH_MAX constant for --bare.
Replace "GIT_DIR" with GIT_DIR_ENVIRONMENT.
Automatically detect a bare git repository.
Remove unnecessary argc parameter from run_command_v.
Redirect update hook stdout to stderr.
Use /dev/null for update hook stdin.
Teach Git how to parse standard power of 2 suffixes.
Theodore Ts'o (1):
Fix formatting for urls section of fetch, pull, and push manpages
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-31 8:07 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* jc/send-pack-pipeline (Fri Dec 29 12:14:30 2006 -0800) 2 commits
+ Documentation: illustrate send-pack pipeline.
+ send-pack: fix pipeline.
There was a longstanding bug that was exposed only by accident
when used with Shawn's sliding mmap changes (sp/mmap), and these
are to fix it. I'll merge this to 'master' before v1.5.0-rc1.
* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
+ Update packedGit config option documentation.
+ mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
+ pack-objects: fix use of use_pack().
+ Fix random segfaults in pack-objects.
+ Cleanup read_cache_from error handling.
+ Replace mmap with xmmap, better handling MAP_FAILED.
+ Release pack windows before reporting out of memory.
+ Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
+ Test suite for sliding window mmap implementation.
+ Create pack_report() as a debugging aid.
+ Support unmapping windows on 'temporary' packfiles.
+ Improve error message when packfile mmap fails.
+ Ensure core.packedGitWindowSize cannot be less than 2 pages.
+ Load core configuration in git-verify-pack.
+ Fully activate the sliding window pack access.
+ Unmap individual windows rather than entire files.
+ Document why header parsing won't exceed a window.
+ Loop over pack_windows when inflating/accessing data.
+ Replace use_packed_git with window cursors.
+ Refactor how we open pack files to prepare for multiple windows.
+ Create read_or_die utility routine.
+ Use off_t for index and pack file lengths.
+ Refactor packed_git to prepare for sliding mmap windows.
+ Introduce new config option for mmap limit.
+ Replace unpack_entry_gently with unpack_entry.
This is Shawn's sliding mmap series to allow smaller virtual
memory footprint to access larger packfiles. I started using
this series in production tonight. Although the size of the
series is somewhat intimidating, they are sane changes and I
think it may be worth considering for 'master'. This does not
change the user experience majorly as has almost no UI elements,
so it could go in either before or after v1.5.0.
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
A few people wanted to have this in v1.5.0, but I am a bit
reluctant to do so --- I think the behaviour of its failure mode
is rather nasty, even though it tries to help the user by
dropping the local diff in .git/LOCAL_DIFF file.
* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 6 commits
- Refresh the index before starting merge-recursive.
- Improve merge performance by avoiding in-index merges.
- Avoid git-fetch in `git-pull .` when possible.
+ Use merge-recursive in git-am -3.
+ Allow merging bare trees in merge-recursive.
+ Move better_branch_name above get_ref in merge-recursive.
I'm reasonably happy with the earlier three of this series but
not really about the latter, and I've already described why.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
These are not for 'master' for now.
^ permalink raw reply
* Re: [PATCH/RFH] send-pack: fix pipeline.
From: Junio C Hamano @ 2006-12-31 9:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612291307520.4473@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> For some reason I thought we had fixed that by just generating the object
> list internally, but I guess we don't do that. That's just stupid.
Thanks. How about this?
-- >8 --
[PATCH] send-pack: tell pack-objects to use its internal rev-list.
This means one less process in the pipeline to worry about, and
removes about 1/8 of the code.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
send-pack.c | 139 ++++++++++++++++++-----------------------------------------
1 files changed, 42 insertions(+), 97 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index 29cf736..eaa6efb 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -14,100 +14,49 @@ static int send_all;
static int force_update;
static int use_thin_pack;
-static void exec_pack_objects(void)
-{
- static const char *args[] = {
- "pack-objects",
- "--all-progress",
- "--stdout",
- NULL
- };
- execv_git_cmd(args);
- die("git-pack-objects exec failed (%s)", strerror(errno));
-}
-
-static void exec_rev_list(struct ref *refs)
-{
- static const char *args[4];
- int i = 0;
-
- args[i++] = "rev-list"; /* 0 */
- if (use_thin_pack) /* 1 */
- args[i++] = "--objects-edge";
- else
- args[i++] = "--objects";
-
- args[i++] = "--stdin";
-
- args[i] = NULL;
- execv_git_cmd(args);
- die("git-rev-list exec failed (%s)", strerror(errno));
-}
-
/*
- * Run "rev-list --stdin | pack-objects" pipe.
- */
-static void rev_list(struct ref *refs)
-{
- int pipe_fd[2];
- pid_t pack_objects_pid;
-
- if (pipe(pipe_fd) < 0)
- die("rev-list setup: pipe failed");
- pack_objects_pid = fork();
- if (!pack_objects_pid) {
- /* The child becomes pack-objects; reads from pipe
- * and writes to the original fd
- */
- dup2(pipe_fd[0], 0);
- close(pipe_fd[0]);
- close(pipe_fd[1]);
- exec_pack_objects();
- die("pack-objects setup failed");
- }
- if (pack_objects_pid < 0)
- die("pack-objects fork failed");
-
- /* We become rev-list --stdin; output goes to pipe. */
- dup2(pipe_fd[1], 1);
- close(pipe_fd[0]);
- close(pipe_fd[1]);
- exec_rev_list(refs);
-}
-
-/*
- * Create "rev-list --stdin | pack-objects" pipe and feed
- * the refs into the pipeline.
+ * Make a pack stream and spit it out into file descriptor fd
*/
-static void rev_list_generate(int fd, struct ref *refs)
+static int pack_objects(int fd, struct ref *refs)
{
int pipe_fd[2];
- pid_t rev_list_generate_pid;
+ pid_t pid;
if (pipe(pipe_fd) < 0)
- die("rev-list-generate setup: pipe failed");
- rev_list_generate_pid = fork();
- if (!rev_list_generate_pid) {
- /* The child becomes the "rev-list | pack-objects"
- * pipeline. It takes input from us, and its output
- * goes to fd.
+ return error("send-pack: pipe failed");
+ pid = fork();
+ if (!pid) {
+ /*
+ * The child becomes pack-objects --revs; we feed
+ * the revision parameters to it via its stdin and
+ * let its stdout go back to the other end.
*/
+ static const char *args[] = {
+ "pack-objects",
+ "--all-progress",
+ "--revs",
+ "--stdout",
+ NULL,
+ NULL,
+ };
+ if (use_thin_pack)
+ args[4] = "--thin";
dup2(pipe_fd[0], 0);
dup2(fd, 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
close(fd);
- rev_list(refs);
- die("rev-list setup failed");
+ execv_git_cmd(args);
+ die("git-pack-objects exec failed (%s)", strerror(errno));
}
- if (rev_list_generate_pid < 0)
- die("rev-list-generate fork failed");
- /* We feed the rev parameters to them. We do not write into
- * fd nor read from the pipe.
+ /*
+ * We feed the pack-objects we just spawned with revision
+ * parameters by writing to the pipe.
*/
close(pipe_fd[0]);
close(fd);
+
while (refs) {
char buf[42];
@@ -126,28 +75,24 @@ static void rev_list_generate(int fd, struct ref *refs)
refs = refs->next;
}
close(pipe_fd[1]);
- // waitpid(rev_list_generate_pid);
- exit(0);
-}
-/*
- * Make a pack stream and spit it out into file descriptor fd
- */
-static void pack_objects(int fd, struct ref *refs)
-{
- pid_t rev_list_pid;
+ for (;;) {
+ int status, code;
+ pid_t waiting = waitpid(pid, &status, 0);
- rev_list_pid = fork();
- if (!rev_list_pid) {
- rev_list_generate(fd, refs);
- die("rev-list setup failed");
+ if (waiting < 0) {
+ if (errno == EINTR)
+ continue;
+ return error("waitpid failed (%s)", strerror(errno));
+ }
+ if ((waiting != pid) || WIFSIGNALED(status) ||
+ !WIFEXITED(status))
+ return error("pack-objects died with strange error");
+ code = WEXITSTATUS(status);
+ if (code)
+ return -code;
+ return 0;
}
- if (rev_list_pid < 0)
- die("rev-list fork failed");
- /*
- * We don't wait for the rev-list pipeline in the parent:
- * we end up waiting for the other end instead
- */
}
static void unmark_and_free(struct commit_list *list, unsigned int mark)
@@ -379,7 +324,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
packet_flush(out);
if (new_refs)
- pack_objects(out, remote_refs);
+ ret = pack_objects(out, remote_refs);
close(out);
if (expect_status_report) {
^ permalink raw reply related
* How to commit removed file?
From: Michael S. Tsirkin @ 2006-12-31 10:24 UTC (permalink / raw)
To: git
I'd like to remove a file and commit the removal while
leaving out other changes in repository/index.
$git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
$ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
any file(s) known to git.
Did you forget to 'git add'?
A similiar thing works with "git add".
--
MST
^ permalink raw reply
* RFC: working with sparse work-copy: where to start?
From: Michael S. Tsirkin @ 2006-12-31 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi!
I've been thinking about working in a sparsely-populated work copy.
E.g. svn will let you do a checkout of a specific sub-directory
and do all your development there assuming you only care about
changes in that directory. Ideally, it would be possible to specify
a set of directories that I care about.
git does close to what I want if I do git-clone -n and then
git-checkout <subdirectory>.
However,
1. This re-creates the same directory structure that the repository has.
Especially for when this directory resides deep in the original repo
tree structure, it would be nice to be able relocate the directory anywhere.
2. The rest of the tree is checked-out whenever I pull from the central repo.
3. git-commit would list all files I didn't check out as removed.
I wonder how hard would it be to add such support?
I tried looking at 2 - is builtin-merge-file.c the only place where the checkout
is done on merge?
What other commands need to be fixed for this to work?
--
MST
^ permalink raw reply
* Gitweb - caching
From: J.H. @ 2006-12-31 10:30 UTC (permalink / raw)
To: git
There has been some recent discussion concerning the amount of resources
that gitweb is chewing through, particularly on kernel.org. I've just
pushed a small set of changes out to kernel.org that add in caching to
the gitweb thats running on it. Changes are published at
git://git.kernel.org/pub/scm/git/warthog9/gitweb.git
Thoughts or comments are welcome.
- John 'Warthog9'
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Marco Costalba @ 2006-12-31 11:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v64bsj0s4.fsf@assigned-by-dhcp.cox.net>
I'm sorry to reply only now but I have problems with my internet
connection, I am also not able to test Junio patches now.
Regarding qgit parsing 'bug' I would like to point out something that
probably is not clear.
1) Parsing routine _must_ be able to sustain the loading of more then
40000 revisions in a couple of seconds, so must be very quick. A lot
of effort has been put to index the header info at maximum speed. Now
it takes about 300ms to parse the whole linux tree. You can have this
only if the header format is 'fixed enough', it means that you would
not expect whole new lines (new '\n' chars) to appear from nowhere in
header, with the exception of log message and parents info lines of
course.
2) I _have_ to rely on headers info because that's where I get data to
show the user, that's the whole point of calling git-rev-list with
--headers option.
3) The rule of double '\n\n' as an indicator of the start of log
message it's not only very slow, it's also broken in cases of no log,
see 7b7abfe3dd81d in Linux tree.
4) We are talking of keeping back compatibility, _fixing_ qgit does
not solves the issues with current qgit users.
So please I really would ask again to *do not print that encoding
extra line if not requested to do so*
Thanks again
Marco
P.S: One way to really speed up the indexing would be if git-rev-list
prints at the beginning the length of the record, i.e. the distance
from the next '\0' terminating point. I don't know if this info is
already available to git-rev-list before to print the record or has to
find it anyway, in the latter case there is no point in doing this.
But in the former case it would be possible to avoid a costly
find('\0'), starting from the beginning of log message. Log message is
more then the half of all the record length so it would be possible to
avoid a good amount of unuseful work because only the position of the
next '\0' is needed during parsing, not the log message, that is
retrieved and shown to the user only on demand, i.e. only for the
selected revision.
^ permalink raw reply
* [PATCH, UPDATED] Fix formatting for urls section of fetch, pull, and push manpages
From: Theodore Tso @ 2006-12-31 4:11 UTC (permalink / raw)
To: git
In-Reply-To: <E1H0p79-0004T8-8V@candygram.thunk.org>
The line:
[remote "<remote>"]
was getting swallowed up by asciidoc, causing a critical line in the
explanation for how to store the .git/remotes information in .git/config
to go missing from the git-fetch, git-pull, and git-push manpages.
Put all of the examples into delimited blocks to fix this problem and to
make them look nicer.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
[Updated to make thee nroff'ed man pages look nicer]
---
Documentation/urls.txt | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 670827c..745f967 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -40,10 +40,13 @@ In addition to the above, as a short-hand, the name of a
file in `$GIT_DIR/remotes` directory can be given; the
named file should be in the following format:
+------------
URL: one of the above URL format
Push: <refspec>
Pull: <refspec>
+------------
+
Then such a short-hand is specified in place of
<repository> without <refspec> parameters on the command
line, <refspec> specified on `Push:` lines or `Pull:`
@@ -54,10 +57,13 @@ be specified for additional branch mappings.
Or, equivalently, in the `$GIT_DIR/config` (note the use
of `fetch` instead of `Pull:`):
-[remote "<remote>"]
- url = <url>
- push = <refspec>
- fetch = <refspec>
+------------
+ [remote "<remote>"]
+ url = <url>
+ push = <refspec>
+ fetch = <refspec>
+
+------------
The name of a file in `$GIT_DIR/branches` directory can be
specified as an older notation short-hand; the named
@@ -68,10 +74,15 @@ name of remote head (URL fragment notation).
without the fragment is equivalent to have this in the
corresponding file in the `$GIT_DIR/remotes/` directory.
+------------
URL: <url>
Pull: refs/heads/master:<remote>
+------------
+
while having `<url>#<head>` is equivalent to
+------------
URL: <url>
Pull: refs/heads/<head>:<remote>
+------------
--
1.5.0.rc0.g1d42
^ permalink raw reply related
* Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.
From: Theodore Tso @ 2006-12-31 12:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vk608fq9u.fsf@assigned-by-dhcp.cox.net>
On Sun, Dec 31, 2006 at 12:01:01AM -0800, Junio C Hamano wrote:
> > Why not just tell these users to setup the working directories with
> > local .git directories and not use GIT_DIR?
>
> suggest that we might want to bite the bullet and declare that
> these things are not supported anymore in v1.5.0.
While we're talking about potentially deprecating GIT_DIR for users,
out of curiosity, what valid workflows would cause users to want to
use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would
cause more confusion and support problems than anything else.
- Ted
^ permalink raw reply
* Re: [PATCH 3/4] Automatically detect a bare git repository.
From: Theodore Tso @ 2006-12-31 12:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061231043019.GC5823@spearce.org>
On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:
> Many users find it unfriendly that they can create a bare git
> repository easily with `git clone --bare` but are then unable to
> run simple commands like `git log` once they cd into that newly
> created bare repository. This occurs because we do not check to
> see if the current working directory is a git repository.
Thanks for coding this up!
If you do this, does this mean that we can also eliminate the global
variable --bare, since git will be able to figure out we're in a bare
repository all by itself?
- Ted
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Juergen Ruehle @ 2006-12-31 13:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvcfpze.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> + git-merge: preserve and merge local changes when doing fast
> forward
>
> A few people wanted to have this in v1.5.0, but I am a bit
> reluctant to do so --- I think the behaviour of its failure mode
> is rather nasty, even though it tries to help the user by
> dropping the local diff in .git/LOCAL_DIFF file.
It happened to me (not really an experienced user) for the first time
on the last pull. Though unexpected it wasn't an unpleasant
experience. The failure mode doesn't feel smooth, but after thinking
about possible improvements I couldn't come up with anything better.
It already states explicitly what it's doing including telling the
user about LOCAL_DIFF. The only thing I wasn't sure about was how to
get rid of the unmerged index entries after I fixed the conflicts
without adding the local change to the index. In the end I did an
update-index/reset combination, but perhaps repeating the list of
files with conflicting local changes after the merge and cleaning the
index instead of leaving unmerged entries in the index would be
better.
I think (because of LOCAL_DIFF) it is safe to have this in 1.5 even in
its current incarnation.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2006-12-31 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvcfpze.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 31 Dec 2006, Junio C Hamano wrote:
> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> + git-merge: preserve and merge local changes when doing fast
> forward
>
> A few people wanted to have this in v1.5.0, but I am a bit reluctant to
> do so --- I think the behaviour of its failure mode is rather nasty,
> even though it tries to help the user by dropping the local diff in
> .git/LOCAL_DIFF file.
I am not urging the inclusion in 1.5.0, but how about storing not the
diff, but the _state_ in .git/UNCOMMITTED_TREE? This would work with all
the git tools without any problem, and git-gc would eventually clean up
older intermediate stages.
Ciao,
Dscho
^ permalink raw reply
* Re: How to commit removed file?
From: Johannes Schindelin @ 2006-12-31 15:06 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20061231102444.GD26552@mellanox.co.il>
Hi,
just a guess: putting "--" before the name of the removed file should
work, no?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.
From: Johannes Schindelin @ 2006-12-31 15:13 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20061231124921.GA14286@thunk.org>
Hi,
On Sun, 31 Dec 2006, Theodore Tso wrote:
> On Sun, Dec 31, 2006 at 12:01:01AM -0800, Junio C Hamano wrote:
> > > Why not just tell these users to setup the working directories with
> > > local .git directories and not use GIT_DIR?
> >
> > suggest that we might want to bite the bullet and declare that
> > these things are not supported anymore in v1.5.0.
>
> While we're talking about potentially deprecating GIT_DIR for users,
> out of curiosity, what valid workflows would cause users to want to
> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would
> cause more confusion and support problems than anything else.
Easy, guys.
It is a valid -- indeed, useful -- thing to be able to script nice
helpers. For example, in one project I track tar balls. So, I wrote a
script which will unpack the tar ball in a directory, build a new index
from it, and commit the corresponding tree on top of the tracking branch.
This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and
GIT_DIR.
So, these things are _useful_. Please don't break them.
As for the presence of "index" in a bare repo: I think this is not a
problem, _as long_ as things continue to work as before, i.e.
$ GIT_DIR=$(pwd) git log
and
$ git --bare log
do _not_ complain if "index" is there. Now, if somebody starts git in a
bare repo, where "index" is present, it could die with a helpful message
like
It seems that this is a bare git repository, but there is an index
file present, which contradicts that assumption. If the repository
is indeed bare, please remove the index file.
Ciao,
Dscho
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Johannes Schindelin @ 2006-12-31 15:27 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550612310345j4c882b7av51879ca1175a1c6b@mail.gmail.com>
Hi,
On Sun, 31 Dec 2006, Marco Costalba wrote:
> Regarding qgit parsing 'bug' I would like to point out something that
> probably is not clear.
But it _is_ a bug!
> 1) Parsing routine _must_ be able to sustain the loading of more then
> 40000 revisions in a couple of seconds, so must be very quick. A lot
> of effort has been put to index the header info at maximum speed. Now
> it takes about 300ms to parse the whole linux tree. You can have this
> only if the header format is 'fixed enough', it means that you would
> not expect whole new lines (new '\n' chars) to appear from nowhere in
> header, with the exception of log message and parents info lines of
> course.
I don't see why this would slow down parsing _at all_. Besides, you should
really stop relying on the header format being fixed for all eternity.
There has been talk about putting more useful information into the header,
and there _are_ valid reasons to keep the header extensible.
Further, if you rely on parsing being super-fast, why not just parse
_only_ the header information that you actually need? The header still
consists of
- exactly one "tree",
- an arbitrary amount of "parent" lines,
- exactly one "author", and
- exactly one "committer" line
After that may come optional headers, but by that time you should
_already_ have stopped parsing! And the order is fixed already
(parse_commit_buffer() relies on it).
After all, you have an initial parsing for the purpose of organizing the
commits, and you can have _another_ for the purpose of displaying the
message (you can remember the offset where the first parsing stopped to
accelerate the second). The latter parsing should be done individually,
when displaying the commit.
And I still have to disagree with Junio that the encoding header is no
longer needed when displaying the commit message. The "tree" and "parent"
headers are also displayed, even if their information is already used for
purposes of displaying them.
The commit header contains information about that particular commit, and
if I ask to see the headers, I want to see them, and not be treated like
an idiot who does not know how to handle that information.
(If I ask for git-log to show everything encoded in Latin-1, it might
still be interesting to know who used which encoding. And if it is
displayed in my local encoding, but the commit header says UTF-8, I _do_
know that this is the original encoding, not the displayed one, thank you
very much!)
So please, Marco, fix that bug in qgit. Otherwise you will restrict our
ability to enhance commit objects with useful meta information _anyway_.
IOW, even if the encoding header is not shown (which I would not like),
you should fix that bug.
Ciao,
Dscho
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Marco Costalba @ 2006-12-31 15:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612311613180.22628@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Further, if you rely on parsing being super-fast, why not just parse
> _only_ the header information that you actually need? The header still
> consists of
>
> - exactly one "tree",
> - an arbitrary amount of "parent" lines,
> - exactly one "author", and
> - exactly one "committer" line
>
> After that may come optional headers,
If you intorduce the concept of an 'optional header part' you
logically and naturally _may_ also introduce the concept of disabling
the display of _that_ optional header, or better, to keep back
compatibility (I just remaind that's more then one year and an half
that git-rev-list works in that way!) you may accept the concept of an
option to show the additional optional header part. That's just what
I'm asking, no more no less.
>but by that time you should
> _already_ have stopped parsing! And the order is fixed already
> (parse_commit_buffer() relies on it).
>
> After all, you have an initial parsing for the purpose of organizing the
> commits, and you can have _another_ for the purpose of displaying the
> message (you can remember the offset where the first parsing stopped to
> accelerate the second). The latter parsing should be done individually,
> when displaying the commit.
>
The problem with your proposed algorithm is that you don't have _one_
commit but a sequence of commits to parse, so when you have parsed
until the committer line you must need to know where the next commit
starts, IOW you have to find the next '\0', that's what I was trying
to expose in my previous e-mail postscriptum.
Thanks
Marco
^ permalink raw reply
* Re: Gitweb - caching
From: Robert Fitzsimons @ 2006-12-31 17:41 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <45979136.3070901@eaglescrag.net>
> Thoughts or comments are welcome.
Interesting work, John. Some initial comments:
* It's a very intrusive set of changes.
* An infinite expiry date isn't valid for all pages.
* The other HTTP headers can change depending on the page returned.
* A single cache directory is going to have problems as the number of
cached files grows.
What are the benefits of doing this inside of gitweb instead of using
something like mod_cache or mod_perl handlers?
Robert
^ permalink raw reply
* Re: [PATCH 3/4] Automatically detect a bare git repository.
From: Martin Waitz @ 2006-12-31 17:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Theodore Tso
In-Reply-To: <20061231043019.GC5823@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
hoi :)
On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:
> We test the current working directory only after we have tried
> searching up the directory tree. This is to retain backwards
> compatibility with our previous behavior on the off chance that
> a user has a 'refs' and 'objects' subdirectories and a 'HEAD'
> file that looks like a symref, all stored within a repository's
> associated working directory.
Hmm, I have my dot files under GIT control so I can't use this mechanism
to use bare GIT repositories under ~/git/*.git.
Perhaps we should test the current directory first, but check that it
ends in .git?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 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