* Git error on Cygwin
From: Claudio Scordino @ 2007-07-30 17:18 UTC (permalink / raw)
To: git
Hi all,
I just installed cygwin on Windows XP and I have the following error when
using git-clone.
(Consider that the same command on the same repository works on Linux).
Regards,
Claudio
$ git-clone <username>@<host>:/<path>/<project>
Initialized empty Git repository in /home/Claudio/<project>/.git/
<username>@<host>'s password:
remote: Generating pack...
remote: Done counting 30387 objects.
remote: Deltifying 30387 objects...
remote: 100% (30387/30387) done
Indexing 30387 objects...
remote: Total 30387 (delta 4446), reused 30188 (delta 4351)
100% (30387/30387) done
Resolving 4446 deltas...
100% (4446/4446) done
3 [main] git-read-tree 2160 C:\cygwin\bin\git-read-tree.exe: *** fatal
error - could not load shell32, Win32 error 487
/usr/bin/git-clone: line 404: 2160 Hangup git-read-tree -m -u
$v HEAD HEAD
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: David Kastrup @ 2007-07-31 6:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig Boston, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301629230.4161@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 30 Jul 2007, Craig Boston wrote:
>>
>> # On branch cvs_RELENG_4
>> nothing to commit (working directory clean)
>> git: 67.65 seconds
>
> So I _seriously_ hope that about 65 of those 67 seconds was the "cvs
> update -d" or something like that.
>
> Anything that takes a minute in git is way way *way* too slow. Any
> half-way normal git operations should take less than a second.
I tried a git-add . on a TeX live tree (lots of itsy files). About
80% of the processor time was wait.
I think that SHA1 is costly enough that the processor(s) could get
saturated when enough is done in parallel.
Potential for multithreading is here enough to make any Summer of Code
student weep with joy:
a) one thread for opendir/readdir at every directory level
b) one thread for stating the files in readdir order (more likely to
correspond to the disk layout than sorted order)
c) one thread on each directory level doing a mergesort on a different
link field (some merge passes could be parallelized even, but let's
not get overexcited)
d) asynch I/O requesting the data for all files to be submitted to
SHA1
e) one thread (but no more threads than there are CPUs) per
independent file/tree for doing SHA1
f) asynch I/O reading the index sequentially
g) one thread doing a merge pass of already sorted stuff (this can
start once the top level directory has been read and sorted
completely, possibly having to stop until a complete subdirectory
comes in).
h) asynch I/O writing out the results of the merge sequentially
In fact, git-ls-files|git-add --stdin is already exploiting a bit of
parallelism (and will probably profit from CFS by making much more use
of the buffering capacity of the pipe). It is counterintuitive that
hand-built chains work more efficiently than explicit git commands.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 5/5] Split out the actual commit creation from the option parsing etc.
From: Junio C Hamano @ 2007-07-31 4:43 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11858309332705-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> @@ -85,40 +129,20 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> parents++;
> }
>
> - /* Not having i18n.commitencoding is the same as having utf-8 */
> - encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
> + buffer = NULL;
> + if (read_fd(0, &buffer, &len))
> + die("Could not read commit message from standard input");
>
> - strbuf_init(&sb);
> - strbuf_printf(&sb, "tree %s\n", sha1_to_hex(tree_sha1));
> + commit_sha1 = create_commit(tree_sha1,
> + parent_sha1, parents,
> + xstrdup(git_author_info(1)),
> + xstrdup(git_committer_info(1)),
> + buffer, len);
Hmph, the series was so nice so far, but here we have a few new
leak, presumably so small per process invocation that we do not
care about?
^ permalink raw reply
* Re: [PATCH 4/5] Make builtin-commit-tree use a strbuf instead of hand-rolled realloc buffer.
From: Junio C Hamano @ 2007-07-31 4:39 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11858309322915-git-send-email-krh@redhat.com>
Very nice.
^ permalink raw reply
* Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
From: Junio C Hamano @ 2007-07-31 4:36 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11858309322006-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> +static void inline strbuf_grow(struct strbuf *sb, size_t extra)
> +{
> + while (sb->alloc < sb->len + extra)
> sb->alloc = sb->alloc * 3 / 2 + 16;
> + sb->buf = xrealloc(sb->buf, sb->alloc);
> +}
Somehow this while () loop to compute the growth factor bothers
me but that is probably a minor detail.
> +void strbuf_printf(struct strbuf *sb, const char *fmt, ...)
> +{
> + char one_line[2048];
> + va_list args;
> + int len;
Such a nice abstraction so far, and then at the highest level of
callchain we have this hardcoded limit?
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Theodore Tso @ 2007-07-31 4:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig Boston, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301825130.4161@woody.linux-foundation.org>
On Mon, Jul 30, 2007 at 06:44:13PM -0700, Linus Torvalds wrote:
> > 1st or maybe 2nd-gen Willamette CPU
> > 512MB memory (stupid motherboard that won't accept more)
> > Slow disks in RAID-5 configuration
> > Running ZFS with less than half of the recommended minimum memory, to
> > the point where I had to reduce the number of vnodes that the kernel is
> > allowed to cache to avoid running out of KVA
>
> Oh, ok. Solaris.
>
> With slow pathname lookup, and hard limits on the inode cache sizes.
>
> Git really normally avoids reading the data, so even in 512M you should
> _easily_ be able to cache the metadata (directory and inodes), which is
> all you need. But yeah, Linux will probably do that a whole lot more
> aggressively than Solaris does.
I also have a suspicion that ZFS's "never overwrite metadata" is
causing its inodes to be be scattered all over the disk, so the lack
of cacheing is hurting even more than it would for other filesystems.
(Put another way, there's probably a really good reason for ZFS's
minimum memory recommendations.)
Craig, it might be interesting to see what sort of results you get if
you use UFS instead of ZFS in your low-memory constrained
environment...
- Ted
^ permalink raw reply
* Re: [PATCH 1/5] Add test case for basic commit functionality.
From: Junio C Hamano @ 2007-07-31 4:18 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11858309261111-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> +# Pick a date so we get consistent commits. 7/7/07 means good luck!
> +export GIT_AUTHOR_DATE="July 7, 2007"
> +export GIT_COMMITTER_DATE="July 7, 2007"
Other scripts use test_tick for consistent commits; just to let
you know, the above is as good if you intend to use only one
timestamp.
> +echo "bongo bongo" >file
> +test_expect_success \
> + "initial status" \
> + "git-add file && \
> + git-status | grep 'Initial commit'"
We tend to prefer to have the "create testfile" part also in the
test.
> +test_expect_failure \
> + "fail initial amend" \
> + "git-commit -m initial --amend"
Does it fail because it is initial, or because these two
options, "-m <msg>" and "--amend", are incompatible?
> +echo "bongo bongo bongo" >file
Ditto.
> +cat >msg <<EOF
> +
> +
> +
> +Signed-off-by: hula
> +EOF
... except <<here text are left outside of test_expect_success
because there were reports that some shells cannot grok here
text in eval correctly.
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: Josef Sipek @ 2007-07-31 4:05 UTC (permalink / raw)
To: Eric Lesh; +Cc: git
In-Reply-To: <1185851481271-git-send-email-eclesh@ucla.edu>
On Mon, Jul 30, 2007 at 08:11:18PM -0700, Eric Lesh wrote:
...
> diff --git a/Documentation/guilt-guard.txt b/Documentation/guilt-guard.txt
> new file mode 100644
> index 0000000..6290bf7
> --- /dev/null
> +++ b/Documentation/guilt-guard.txt
> @@ -0,0 +1,40 @@
> +guilt-guard(1)
> +===============
Extra = ;)
> +
> +NAME
> +----
> +guilt-guard - Assign guards to patches
> +
> +SYNOPSIS
> +--------
> +include::usage-guilt-guard.txt[]
> +
> +DESCRIPTION
> +-----------
> +Assign guards to the specified patch, or to the patch on top of the
> +stack if no patch is given on the command line.
> +
> +An unguarded patch is always pushed.
> +
> +A positive guard begins with a +. A patch with a positive guard is
> +pushed *only if* the guard is selected.
> +
> +A negative guard begins with a -. A patch with a negative guard is
> +always pushed, *unless* the guard is selected.
> +
> +OPTIONS
> +-------
> +-l|--list::
> + List all patches and their guards
> +-n|--none::
> + Remove all guards from a patch
I generally try to keep an empty line between the options. I don't think it
affects rendering, but just for consistency.
> +
> +Author
> +------
> +Written by Eric Lesh <eclesh@ucla.edu>
> +
> +Documentation
> +-------------
> +Documentation by Eric Lesh <eclesh@ucla.edu>
> +
> +include::footer.txt[]
> diff --git a/guilt b/guilt
> index 700c167..6af590c 100755
> --- a/guilt
> +++ b/guilt
> @@ -187,6 +187,72 @@ get_series()
> " $series
> }
>
> +get_guarded_series()
> +{
> + get_series | while read p
> + do
> + check_guards "$p" && echo "$p"
> + done
> +}
> +
> +# usage: check_guards <patch>
> +# Returns 0 if the patch should be pushed
> +check_guards()
> +{
> + get_guards "$1" | while read guard
> + do
> + pos=`printf %s $guard | grep -e "^+"`
> + guard=`printf %s $guard | sed -e 's/^[+-]//'`
> + if [ "$pos" ]; then
> + # Push +guard *only if* guard selected
> + push=`grep -e "^$guard\$" "$guards_file" >/dev/null 2>/dev/null; echo $?`
> + [ $push -ne 0 ] && return 1
grep -e "^$guard\$" "$guards_file" >/dev/null 2>/dev/null
[ $? -ne 0 ] && return 1
Much cleaner looking :) Or even:
grep -e ....... || return 1
> + else
> + # Push -guard *unless* guard selected
> + push=`grep -e "^$guard\$" "$guards_file" >/dev/null 2>/dev/null; echo $?`
> + [ $push -eq 0 ] && return 1
Ditto.
> + fi
> + return 0
> + done
> + return $?
I'd throw in a small comment above the outter return to make sure no one
tries to clean things up and remove it.
> +}
> +
> +# usage: get_guards <patch>
> +get_guards()
> +{
> + sed -n -e "\,^$1[[:space:]]*#, {
> + s,^$1[[:space:]]*,,
> + s,#[^+-]*,,g
> +
> + p
> + }
> + " $series
Three things...
1) I generally preserve the sed script indentation
2) I like having the whole script start at col 0, syntax highlighting makes
it readable enough.
3) quote the "$series" in case there's whitespace in the repo path or branch
name
This is what I'd make it look like if I were to write it, but that's me just
nitpicking at this point :)
sed -n -e "
line 1 {
line 2
line 4
}
" "$series"
> +}
> +
> +# usage: set_guards <patch> <guards...>
> +set_guards()
> +{
> + p="$1"
Again, be careful about namespace polution.
> + shift
> + for x in "$@"; do
> + if [ -z $(printf %s "$x" | grep -e "^[+-]") ]; then
Out of curiosity, why printf and not echo?
> + echo "'$x' is not a valid guard name"
> + else
> + sed -i -e "s,^\($p[[:space:]]*.*\)$,\1 #$x," "$series"
The regexp is in double quotes, so you should escape the $ (EOL), as well as
all the \. Yep, this is shell scripting at its worst.
> + fi
> + done
> +}
> +
> +# usage: unset_guards <patch> <guards...>
> +unset_guards()
> +{
> + p="$1"
Namespace..
> + shift
> + for x in "$@"; do
> + sed -i -e "/^$p[[:space:]]/s/ #$x//" "$series"
> + done
> +}
> +
> # usage: do_make_header <hash>
> do_make_header()
> {
> diff --git a/guilt-guard b/guilt-guard
> new file mode 100755
> index 0000000..a0cac2e
> --- /dev/null
> +++ b/guilt-guard
> @@ -0,0 +1,69 @@
> +#!/bin/sh
> +#
> +# Copyright (c) Eric Lesh, 2007
> +#
> +
> +USAGE="[-l|--list|-n|--none|[<patchname>] [(+|-)<guard>...]]"
> +. `dirname $0`/guilt
> +
> +print_guards()
> +{
> + guards=`get_guards "$1"`
> + echo "$1: $guards"
echo "$1: `get_guards \"$1\"`"
Eliminates assignment & namespace polution :) Not really a problem here as
this is a guilt-guard only function.
> +}
> +
> +if [ "$1" == "-l" ] || [ "$1" == "--list" ]; then
> + get_series | while read patch; do
> + print_guards "$patch"
> + done
> + exit 0
> +elif [ "$1" == "-n" ] || [ "$1" == "--none" ]; then
> + patch="$2"
> + if [ -z "$patch" ]; then
> + patch=`get_top`
> + fi
> + unset_guards "$patch" `get_guards "$patch"`
> + exit 0
> +fi
> +
> +case $# in
> + 0)
> + if [ ! -s "$applied" ]; then
> + die "No patches applied."
> + fi
> + print_guards `get_top`
Quote the `get_top` in case the topmost patch has whitespace in it. Yeah,
it's annoying, but safety first :)
> + ;;
> + 1)
> + if [ -z $(printf %s "$1" | grep -e '^[+-]') ]; then
> + if [ -z $(get_series | grep -e "^$1\$") ]; then
> + die "Patch $1 does not exist."
> + else
> + print_guards "$1"
> + fi
> + else
> + patch=`get_top`
> + if [ -z "$patch" ]; then
> + die "You must specify a patch."
> + fi
> + unset_guards "$patch" `get_guards "$patch"`
> + set_guards "$patch" "$1"
> + fi
> + ;;
> + *)
> + if [ -z $(printf %s "$1" | grep -e '^[+-]') ]; then
> + if [ -z $(get_series | grep -e "^$1\$") ]; then
> + die "Patch $1 does not exist."
> + else
> + patch="$1"
> + fi
> + shift
> + else
> + patch=`get_top`
> + if [ -z "$patch" ]; then
> + die "You must specify a patch."
> + fi
> + fi
> + unset_guards "$patch" `get_guards "$patch"`
> + set_guards "$patch" "$@"
> + ;;
> +esac
> --
> 1.5.2
Josef 'Jeff' Sipek, falling asleep after a loooong day.
--
We have joy, we have fun, we have Linux on a Sun...
^ permalink raw reply
* Re: [GUILT PATCH 1/5] get_series: Remove comments from end of series lines
From: Josef Sipek @ 2007-07-31 3:50 UTC (permalink / raw)
To: Eric Lesh; +Cc: git
In-Reply-To: <11858514812742-git-send-email-eclesh@ucla.edu>
On Mon, Jul 30, 2007 at 08:11:17PM -0700, Eric Lesh wrote:
...
> @@ -290,14 +296,17 @@ series_insert_patch()
> # usage: series_remove_patch <patchname>
> series_remove_patch()
> {
> - grep -v "^$1\$" < "$series" > "$series.tmp"
> + grep -v "^$1[[:space:]]*#*" < "$series" > "$series.tmp"
> mv "$series.tmp" "$series"
> }
I haven't tested it, but I believe that this change would be very
bad...suppose you have series with patches "foo" and "foo-2". Now if you try
to remove foo, the regexp would end up being:
"^foo[ ]*#*"
This would match both patches!
> # usage: series_rename_patch <oldname> <newname>
> series_rename_patch()
> {
> - awk -v old="$1" -v new="$2" \
> + # Rename the patch, but preserve comments on the line
> + old=$(grep -e "^$1[[:space:]]*" $series)
This could match multiple lines.
> + new=$(echo "$old" | sed -e "s,^$1,$2,")
One more comment about sed...there are a number of place in guilt that take
patch names and create regexps from them, but don't make sure things get
properly escaped. I guess all the sed changes should be done in one go.
Also, beware that this is in a function, so setting $new and $old affects
the _all_ of guilt. One way around it would be a force subshell to execute
using parenthesis around the contents of the function body.
> + awk -v old="$old" -v new="$new" \
> '{ if ($0 == old) print new; else print $0 }' \
> "$series" > "$series.tmp"
>
> diff --git a/regression/050-series.sh b/regression/050-series.sh
> index eb23540..4c47e9d 100755
> --- a/regression/050-series.sh
> +++ b/regression/050-series.sh
> @@ -26,7 +26,7 @@ modify
> add
>
> remove
> -mode
> +mode # and text
> #sure
> DONE
> }
Good :)
Jeff.
--
NT is to UNIX what a doughnut is to a particle accelerator.
^ permalink raw reply
* Re: [GUILT PATCH v2 0/5] Add guards to guilt
From: Josef Sipek @ 2007-07-31 3:42 UTC (permalink / raw)
To: Eric Lesh; +Cc: git
In-Reply-To: <1185851481190-git-send-email-eclesh@ucla.edu>
On Mon, Jul 30, 2007 at 08:11:16PM -0700, Eric Lesh wrote:
...
> I did everything (maybe?) you suggested except implement a
> safe_sed wrapper and a validate_guards function. The sed stuff is
> maybe better for a later patch that covers most sed usage in guilt,
Agreed.
> and the validate_guards isn't really necessary given the small number
> of times it's called. If you would prefer either of those to get
> done, let me know.
I'll look at the patches and complain there if it seems like something
that should be done. :)
Josef 'Jeff' Sipek.
--
I already backed up the [server] once, I can do it again.
^ permalink raw reply
* [GUILT PATCH v2 0/5] Add guards to guilt
From: Eric Lesh @ 2007-07-31 3:11 UTC (permalink / raw)
To: jsipek; +Cc: git
Changes in v2
- get_series returns guarded series, get_full_series gives
full series. Most commands want the guarded series anyway.
- more options for guilt-select (better hg compatability)
- rename guilt-guards to guilt-guard (better hg compatability)
- a couple bug fixes
- an extra patch that adds a test suite
This series adds Mercurial Queues-like guards to guilt. It allows you
to assign guards to related patches in the series file to selectively
push patches.
See Chapter 13 of the HG Book for more info.
(http://hgbook.red-bean.com/hgbookch13.html)
Guards are appended as "#+foo" or "#-foo" to the end of the patch name
in the series file, so they are compatible with quilt. The
guard setting and unsetting functions also respect comments on the
patch line, so they aren't mangled when you use guards.
This changes `get_series` to return the guarded series of patches that
will be actually be applied. `get_full_series` returns the full
series file.
If you change guards on a patch or select a different guard while
patches are applied, some commands might get confused. See
`guilt-select --pop` and `guilt-select --reapply` to avoid having to
`guilt-pop -a` yourself.
I did everything (maybe?) you suggested except implement a
safe_sed wrapper and a validate_guards function. The sed stuff is
maybe better for a later patch that covers most sed usage in guilt,
and the validate_guards isn't really necessary given the small number
of times it's called. If you would prefer either of those to get
done, let me know.
[PATCH 1/5] get_series: Remove comments from end of series lines
This just strips everything but the patch name from get_series,
to hide comments or guards on the line.
[PATCH 2/5] guilt-guard: Assign guards to patches in series
This adds the guilt-guard command and utility functions to
guilt. Introduces get_guarded_series, which is removed in
patch 4.
[PATCH 3/5] guilt-select: Select guards to apply when pushing patches
This puts selected guards in .git/patch/$branch/guards, and
adds a $guards_file variable to guilt.
[PATCH 4/5] get_series: return guarded patches only
Actually distinguish between guarded and non-guarded patches in
a number of commands by making get_series return the guarded
series, and introducing get_full_series to return the unguarded
series. Lots of changes.
If anything breaks, it's in this patch. Hopefully.
[PATCH 5/5] Guards test suite
Test stuff that uses get_series or get_full_series.
^ permalink raw reply
* [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: Eric Lesh @ 2007-07-31 3:11 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <1185851481190-git-send-email-eclesh@ucla.edu>
guilt-guard will assign guards to a patch. They work so that:
* Patches with no guards are always pushed.
* Patches with positive guards (i.e. +foo) are pushed *only if* the
guard is selected.
* Patches with negative guards (i.e. -foo) are pushed *unless* the
guard is selected.
This also introduces a number of guard-related utility functions into
guilt. get_guarded_series is used to get the list of patches that are
applicable given the current guard status. It replaces get_series in
a later patch.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
Documentation/guilt-guard.txt | 40 +++++++++++++++++++++++
guilt | 66 +++++++++++++++++++++++++++++++++++++++
guilt-guard | 69 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 175 insertions(+), 0 deletions(-)
create mode 100644 Documentation/guilt-guard.txt
create mode 100755 guilt-guard
diff --git a/Documentation/guilt-guard.txt b/Documentation/guilt-guard.txt
new file mode 100644
index 0000000..6290bf7
--- /dev/null
+++ b/Documentation/guilt-guard.txt
@@ -0,0 +1,40 @@
+guilt-guard(1)
+===============
+
+NAME
+----
+guilt-guard - Assign guards to patches
+
+SYNOPSIS
+--------
+include::usage-guilt-guard.txt[]
+
+DESCRIPTION
+-----------
+Assign guards to the specified patch, or to the patch on top of the
+stack if no patch is given on the command line.
+
+An unguarded patch is always pushed.
+
+A positive guard begins with a +. A patch with a positive guard is
+pushed *only if* the guard is selected.
+
+A negative guard begins with a -. A patch with a negative guard is
+always pushed, *unless* the guard is selected.
+
+OPTIONS
+-------
+-l|--list::
+ List all patches and their guards
+-n|--none::
+ Remove all guards from a patch
+
+Author
+------
+Written by Eric Lesh <eclesh@ucla.edu>
+
+Documentation
+-------------
+Documentation by Eric Lesh <eclesh@ucla.edu>
+
+include::footer.txt[]
diff --git a/guilt b/guilt
index 700c167..6af590c 100755
--- a/guilt
+++ b/guilt
@@ -187,6 +187,72 @@ get_series()
" $series
}
+get_guarded_series()
+{
+ get_series | while read p
+ do
+ check_guards "$p" && echo "$p"
+ done
+}
+
+# usage: check_guards <patch>
+# Returns 0 if the patch should be pushed
+check_guards()
+{
+ get_guards "$1" | while read guard
+ do
+ pos=`printf %s $guard | grep -e "^+"`
+ guard=`printf %s $guard | sed -e 's/^[+-]//'`
+ if [ "$pos" ]; then
+ # Push +guard *only if* guard selected
+ push=`grep -e "^$guard\$" "$guards_file" >/dev/null 2>/dev/null; echo $?`
+ [ $push -ne 0 ] && return 1
+ else
+ # Push -guard *unless* guard selected
+ push=`grep -e "^$guard\$" "$guards_file" >/dev/null 2>/dev/null; echo $?`
+ [ $push -eq 0 ] && return 1
+ fi
+ return 0
+ done
+ return $?
+}
+
+# usage: get_guards <patch>
+get_guards()
+{
+ sed -n -e "\,^$1[[:space:]]*#, {
+ s,^$1[[:space:]]*,,
+ s,#[^+-]*,,g
+
+ p
+ }
+ " $series
+}
+
+# usage: set_guards <patch> <guards...>
+set_guards()
+{
+ p="$1"
+ shift
+ for x in "$@"; do
+ if [ -z $(printf %s "$x" | grep -e "^[+-]") ]; then
+ echo "'$x' is not a valid guard name"
+ else
+ sed -i -e "s,^\($p[[:space:]]*.*\)$,\1 #$x," "$series"
+ fi
+ done
+}
+
+# usage: unset_guards <patch> <guards...>
+unset_guards()
+{
+ p="$1"
+ shift
+ for x in "$@"; do
+ sed -i -e "/^$p[[:space:]]/s/ #$x//" "$series"
+ done
+}
+
# usage: do_make_header <hash>
do_make_header()
{
diff --git a/guilt-guard b/guilt-guard
new file mode 100755
index 0000000..a0cac2e
--- /dev/null
+++ b/guilt-guard
@@ -0,0 +1,69 @@
+#!/bin/sh
+#
+# Copyright (c) Eric Lesh, 2007
+#
+
+USAGE="[-l|--list|-n|--none|[<patchname>] [(+|-)<guard>...]]"
+. `dirname $0`/guilt
+
+print_guards()
+{
+ guards=`get_guards "$1"`
+ echo "$1: $guards"
+}
+
+if [ "$1" == "-l" ] || [ "$1" == "--list" ]; then
+ get_series | while read patch; do
+ print_guards "$patch"
+ done
+ exit 0
+elif [ "$1" == "-n" ] || [ "$1" == "--none" ]; then
+ patch="$2"
+ if [ -z "$patch" ]; then
+ patch=`get_top`
+ fi
+ unset_guards "$patch" `get_guards "$patch"`
+ exit 0
+fi
+
+case $# in
+ 0)
+ if [ ! -s "$applied" ]; then
+ die "No patches applied."
+ fi
+ print_guards `get_top`
+ ;;
+ 1)
+ if [ -z $(printf %s "$1" | grep -e '^[+-]') ]; then
+ if [ -z $(get_series | grep -e "^$1\$") ]; then
+ die "Patch $1 does not exist."
+ else
+ print_guards "$1"
+ fi
+ else
+ patch=`get_top`
+ if [ -z "$patch" ]; then
+ die "You must specify a patch."
+ fi
+ unset_guards "$patch" `get_guards "$patch"`
+ set_guards "$patch" "$1"
+ fi
+ ;;
+ *)
+ if [ -z $(printf %s "$1" | grep -e '^[+-]') ]; then
+ if [ -z $(get_series | grep -e "^$1\$") ]; then
+ die "Patch $1 does not exist."
+ else
+ patch="$1"
+ fi
+ shift
+ else
+ patch=`get_top`
+ if [ -z "$patch" ]; then
+ die "You must specify a patch."
+ fi
+ fi
+ unset_guards "$patch" `get_guards "$patch"`
+ set_guards "$patch" "$@"
+ ;;
+esac
--
1.5.2
^ permalink raw reply related
* [GUILT PATCH 5/5] Guards test suite
From: Eric Lesh @ 2007-07-31 3:11 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <1185851481190-git-send-email-eclesh@ucla.edu>
The guards patches touch a lot of guilt, so make sure they don't muck
anything up.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
regression/070-guards.sh | 184 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 184 insertions(+), 0 deletions(-)
create mode 100755 regression/070-guards.sh
diff --git a/regression/070-guards.sh b/regression/070-guards.sh
new file mode 100755
index 0000000..d6917f2
--- /dev/null
+++ b/regression/070-guards.sh
@@ -0,0 +1,184 @@
+#!/bin/bash
+#
+# Test the commands that use get_*_series, while applying guards
+#
+
+source scaffold
+source generic_test_data
+
+function prepare_for_tests
+{
+ # generic_test_data's patches all depend on each other
+ # that's no good for guards testing
+
+ echo "abc" > def
+ git-add def
+ git-commit -s -m "initial" 2> /dev/null > /dev/null
+
+ cat << DONE > .git/patches/master/first
+diff --git a/first b/first
+new file mode 100644
+index 0000000..9c59e24
+--- /dev/null
++++ b/first
+@@ -0,0 +1 @@
++first
+DONE
+
+ cat << DONE > .git/patches/master/second
+diff --git a/second b/second
+new file mode 100644
+index 0000000..e019be0
+--- /dev/null
++++ b/second
+@@ -0,0 +1 @@
++second
+DONE
+
+ cat << DONE > .git/patches/master/third
+diff --git a/third b/third
+new file mode 100644
+index 0000000..234496b
+--- /dev/null
++++ b/third
+@@ -0,0 +1 @@
++third
+DONE
+
+ cat << DONE > .git/patches/master/fourth
+diff --git a/fourth b/fourth
+new file mode 100644
+index 0000000..285a4e6
+--- /dev/null
++++ b/fourth
+@@ -0,0 +1 @@
++fourth
+DONE
+
+ cat << DONE > .git/patches/master/series
+first
+second
+third
+fourth
+DONE
+
+ touch -d "$GIT_COMMITTER_DATE" .git/patches/master/first
+ touch -d "$GIT_COMMITTER_DATE" .git/patches/master/second
+ touch -d "$GIT_COMMITTER_DATE" .git/patches/master/third
+ touch -d "$GIT_COMMITTER_DATE" .git/patches/master/fourth
+}
+
+function expected_applied_none
+{
+ echo "first"
+ echo "second"
+ echo "third"
+ echo "fourth"
+}
+
+function expected_applied_positive
+{
+ echo "second"
+ echo "third"
+ echo "fourth"
+}
+
+function expected_applied_positive_selected
+{
+ echo "first"
+ echo "second"
+ echo "third"
+ echo "fourth"
+}
+
+function expected_applied_negative
+{
+ echo "first"
+ echo "second"
+ echo "third"
+ echo "fourth"
+}
+
+function expected_applied_negative_selected
+{
+ echo "second"
+ echo "third"
+ echo "fourth"
+}
+
+function expected_next
+{
+ echo "second"
+}
+
+function expected_unapplied
+{
+ echo "second"
+ echo "third"
+ echo "fourth"
+}
+
+empty_repo
+cd $REPODIR
+guilt-init
+
+prepare_for_tests
+
+# test with no guarded patches and no guards selected
+guilt-push -a > /dev/null
+guilt-applied > /tmp/reg.$$
+expected_applied_none | diff -u - /tmp/reg.$$
+echo -n "[none] "
+
+# test with one positive guarded patch and no guards selected
+guilt-pop -a > /dev/null
+guilt-guard first +foo
+guilt-push -a > /dev/null
+guilt-applied > /tmp/reg.$$
+expected_applied_positive | diff -u - /tmp/reg.$$
+echo -n "[positive] "
+
+# test with one positive guarded patch with that guard selected
+guilt-pop -a > /dev/null
+guilt-select foo
+guilt-push -a > /dev/null
+guilt-applied > /tmp/reg.$$
+expected_applied_positive_selected | diff -u - /tmp/reg.$$
+echo -n "[positive selected] "
+
+# test with one negative guarded patch and no guards selected
+guilt pop -a > /dev/null
+guilt-select -n
+guilt-guard first -foo
+guilt-push -a > /dev/null
+guilt-applied > /tmp/reg.$$
+expected_applied_negative | diff -u - /tmp/reg.$$
+echo -n "[negative] "
+
+# test with one negative guarded patch with that guard selected
+guilt pop -a > /dev/null
+guilt-select foo
+guilt-push -a > /dev/null
+guilt-applied > /tmp/reg.$$
+expected_applied_negative_selected | diff -u - /tmp/reg.$$
+echo -n "[negative selected] "
+
+# test that guilt-next works
+guilt-pop -a > /dev/null
+guilt-select -n
+guilt-guard first +foo
+guilt-next > /tmp/reg.$$
+expected_next | diff -u - /tmp/reg.$$
+echo -n "[next] "
+
+# test that guilt-unapplied works
+guilt-pop -a > /dev/null
+guilt-select -n
+guilt-guard first +foo
+guilt-unapplied > /tmp/reg.$$
+expected_unapplied | diff -u - /tmp/reg.$$
+echo -n "[unapplied] "
+
+rm -f /tmp/reg.$$
+
+complete_test
--
1.5.2
^ permalink raw reply related
* [GUILT PATCH 3/5] guilt-select: Select guards to apply when pushing patches
From: Eric Lesh @ 2007-07-31 3:11 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <1185851481190-git-send-email-eclesh@ucla.edu>
guilt-select chooses guards that alter which patches will be applied
with a guilt-push. The selected guards are stored in
.git/patches/$branch/guards.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
Documentation/guilt-select.txt | 47 ++++++++++++++++++++++++++++++++++++
Documentation/guilt.txt | 5 +++-
guilt | 1 +
guilt-select | 52 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 104 insertions(+), 1 deletions(-)
create mode 100644 Documentation/guilt-select.txt
create mode 100755 guilt-select
diff --git a/Documentation/guilt-select.txt b/Documentation/guilt-select.txt
new file mode 100644
index 0000000..12f19b4
--- /dev/null
+++ b/Documentation/guilt-select.txt
@@ -0,0 +1,47 @@
+guilt-select(1)
+===============
+
+NAME
+----
+guilt-select - Select guards to apply when pushing patches
+
+SYNOPSIS
+--------
+include::usage-guilt-select.txt[]
+
+DESCRIPTION
+-----------
+Select guards to apply when pushing patches.
+
+Guards are selected without the + or - prefix. Patches are applied in
+the following way:
+
+* An unguarded patch is always applied.
+
+* A patch with a positive guard is applied *only* if the guard is
+selected with guilt-select.
+
+* A patch with a negative guard is applied *unless* the guard is
+selected with guilt-select.
+
+OPTIONS
+-------
+-n|--none::
+ Remove all selected guards
+--pop::
+ Pop back to the first guarded patch
+--reapply::
+ Pop back to first guarded patch, select a new guard, and
+ push
+-s|--series::
+ List all guards listed in the series file
+
+Author
+------
+Written by Eric Lesh <eclesh@ucla.edu>
+
+Documentation
+-------------
+Documentation by Eric Lesh <eclesh@ucla.edu>
+
+include::footer.txt[]
diff --git a/Documentation/guilt.txt b/Documentation/guilt.txt
index 31dbc0e..11c2ca9 100644
--- a/Documentation/guilt.txt
+++ b/Documentation/guilt.txt
@@ -33,7 +33,10 @@ PATCHES DIRECTORY
In Guilt, all the patches are stored in .git/patches/$branch/, where $branch
is the name of the branch being worked on. This means that one can have a
independent series of patches for each branch present in the repository.
-Each of these per-branch directories contains 2 special files:
+Each of these per-branch directories contains 3 special files:
+
+guards: This file contains any guards that should be applied to the
+series when pushing. It is only present when guards are selected.
series: This file contains a list of all the patch filenames relative to the
per-branch patch directory. Empty and commented out lines are ignored.
diff --git a/guilt b/guilt
index 6af590c..b289026 100755
--- a/guilt
+++ b/guilt
@@ -666,6 +666,7 @@ fi
# very useful files
series="$GUILT_DIR/$branch/series"
applied="$GUILT_DIR/$branch/status"
+guards_file="$GUILT_DIR/$branch/guards"
# determine an editor to use for anything interactive (fall back to vi)
editor="vi"
diff --git a/guilt-select b/guilt-select
new file mode 100755
index 0000000..378ca98
--- /dev/null
+++ b/guilt-select
@@ -0,0 +1,52 @@
+#!/bin/sh
+#
+# Copyright (c) Eric Lesh, 2007
+#
+
+USAGE="[-n|--none|-s|--series|[--pop|--reapply] <guards...>]"
+. `dirname $0`/guilt
+
+select_guards()
+{
+ for x in "$@"; do
+ if [ $(printf %s "$x" | grep -e "^[+-]") ]; then
+ die "'$x' cannot begin with + or -."
+ fi
+ done
+ echo "$@" | sed -e 's/ /\n/g' | sort | uniq > "$guards_file"
+}
+
+if [ $# == 0 ]; then
+ if [ -s "$guards_file" ]; then
+ cat "$guards_file"
+ else
+ echo >&2 "No guards applied"
+ fi
+ exit 0
+fi
+
+case $1 in
+ -n|--none)
+ rm -f "$guards_file"
+ ;;
+ --pop)
+ guilt-pop -a
+ shift
+ select_guards "$@"
+ ;;
+ --reapply)
+ top=`get_top`
+ guilt-pop -a
+ shift
+ select_guards "$@"
+ guilt-push "$top"
+ ;;
+ -s|--series)
+ (get_series | while read patch; do
+ get_guards "$patch"
+ done) | sed -e 's/ /\n/g' | sort | uniq
+ ;;
+ *)
+ select_guards "$@"
+ ;;
+esac
--
1.5.2
^ permalink raw reply related
* [GUILT PATCH 4/5] get_series: return guarded patches only
From: Eric Lesh @ 2007-07-31 3:11 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <1185851481190-git-send-email-eclesh@ucla.edu>
This renames get_guarded_series to get_series, and introduces
get_full_series for when the full series is needed. Many guilt
scripts Just Work with that change. Those that don't are fixed up.
With this patch, guards are respected everywhere in guilt.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
guilt | 6 +++---
guilt-export | 2 +-
guilt-guard | 6 +++---
| 4 ++--
guilt-push | 4 ++--
guilt-select | 2 +-
guilt-series | 6 ++++--
7 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/guilt b/guilt
index b289026..d618980 100755
--- a/guilt
+++ b/guilt
@@ -171,7 +171,7 @@ get_prev()
fi
}
-get_series()
+get_full_series()
{
# ignore all lines matching:
# - empty lines
@@ -187,9 +187,9 @@ get_series()
" $series
}
-get_guarded_series()
+get_series()
{
- get_series | while read p
+ get_full_series | while read p
do
check_guards "$p" && echo "$p"
done
diff --git a/guilt-export b/guilt-export
index 2c0a9fd..c872d7f 100755
--- a/guilt-export
+++ b/guilt-export
@@ -18,7 +18,7 @@ fi
trap "rm -rf \"$target_dir\"" 0
mkdir -p "$target_dir"
-get_series | tee "$target_dir/series" | while read p; do
+get_full_series | tee "$target_dir/series" | while read p; do
silent mkdir -p "`dirname $target_dir/$p`" || true
cp "$GUILT_DIR/$branch/$p" "$target_dir/$p"
done
diff --git a/guilt-guard b/guilt-guard
index a0cac2e..a427e25 100755
--- a/guilt-guard
+++ b/guilt-guard
@@ -13,7 +13,7 @@ print_guards()
}
if [ "$1" == "-l" ] || [ "$1" == "--list" ]; then
- get_series | while read patch; do
+ get_full_series | while read patch; do
print_guards "$patch"
done
exit 0
@@ -35,7 +35,7 @@ case $# in
;;
1)
if [ -z $(printf %s "$1" | grep -e '^[+-]') ]; then
- if [ -z $(get_series | grep -e "^$1\$") ]; then
+ if [ -z $(get_full_series | grep -e "^$1\$") ]; then
die "Patch $1 does not exist."
else
print_guards "$1"
@@ -51,7 +51,7 @@ case $# in
;;
*)
if [ -z $(printf %s "$1" | grep -e '^[+-]') ]; then
- if [ -z $(get_series | grep -e "^$1\$") ]; then
+ if [ -z $(get_full_series | grep -e "^$1\$") ]; then
die "Patch $1 does not exist."
else
patch="$1"
--git a/guilt-header b/guilt-header
index 5716265..540cf2a 100755
--- a/guilt-header
+++ b/guilt-header
@@ -31,8 +31,8 @@ esac
[ -z "$patch" ] && die "No patches applied."
# check that patch exists in the series
-ret=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
-if [ $ret -eq 0 ]; then
+ret=`get_full_series | grep -ne "^$patch\$" | cut -d: -f1`
+if [ -z "$ret" ]; then
die "Patch $patch is not in the series"
fi
diff --git a/guilt-push b/guilt-push
index ad3616b..e4004e0 100755
--- a/guilt-push
+++ b/guilt-push
@@ -26,7 +26,7 @@ if [ "$patch" = "--all" ] || [ "$patch" = "-a" ]; then
eidx=`get_series | wc -l`
if [ $eidx -eq 0 ]; then
- die "There are no patches to push"
+ die "There are no patches to push."
fi
elif [ -z "$patch" ]; then
# we are supposed to push only the next patch onto the stack
@@ -39,7 +39,7 @@ else
eidx=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
if [ -z "$eidx" ]; then
- die "Patch $patch is not in the series"
+ die "Patch $patch is not in the series or is guarded."
fi
fi
diff --git a/guilt-select b/guilt-select
index 378ca98..57373c7 100755
--- a/guilt-select
+++ b/guilt-select
@@ -42,7 +42,7 @@ case $1 in
guilt-push "$top"
;;
-s|--series)
- (get_series | while read patch; do
+ (get_full_series | while read patch; do
get_guards "$patch"
done) | sed -e 's/ /\n/g' | sort | uniq
;;
diff --git a/guilt-series b/guilt-series
index 9c34a08..85ef15d 100755
--- a/guilt-series
+++ b/guilt-series
@@ -36,12 +36,12 @@ elif [ ! -z "$gui" ]; then
gitk $range
elif [ -z "$verbose" ]; then
- get_series
+ get_full_series
else
prefix="+"
top=`get_top`
- get_series |
+ get_full_series |
while read patch; do
if [ -z "$top" ]; then
echo " $patch"
@@ -49,6 +49,8 @@ else
if [ "$patch" = "$top" ]; then
echo "= $patch"
prefix=" "
+ elif [ $(check_guards "$patch"; echo $?) -eq 1 ]; then
+ echo " $patch"
else
echo "$prefix $patch"
fi
--
1.5.2
^ permalink raw reply related
* [GUILT PATCH 1/5] get_series: Remove comments from end of series lines
From: Eric Lesh @ 2007-07-31 3:11 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <1185851481190-git-send-email-eclesh@ucla.edu>
Also make sure that series_remove_patch and series_rename_patch do the
right thing if there are comments on the line.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
guilt | 15 ++++++++++++---
regression/050-series.sh | 2 +-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/guilt b/guilt
index 7f2b93c..700c167 100755
--- a/guilt
+++ b/guilt
@@ -178,7 +178,13 @@ get_series()
# - whitespace only
# - optional whitespace followed by '#' followed by more
# optional whitespace
- grep -ve '^[[:space:]]*\(#.*\)*$' "$series"
+ # also remove comments from end of lines
+ sed -n -e "/^[[:space:]]*\(#.*\)*\$/ ! {
+ s/[[:space:]]*#.*\$//
+
+ p
+ }
+ " $series
}
# usage: do_make_header <hash>
@@ -290,14 +296,17 @@ series_insert_patch()
# usage: series_remove_patch <patchname>
series_remove_patch()
{
- grep -v "^$1\$" < "$series" > "$series.tmp"
+ grep -v "^$1[[:space:]]*#*" < "$series" > "$series.tmp"
mv "$series.tmp" "$series"
}
# usage: series_rename_patch <oldname> <newname>
series_rename_patch()
{
- awk -v old="$1" -v new="$2" \
+ # Rename the patch, but preserve comments on the line
+ old=$(grep -e "^$1[[:space:]]*" $series)
+ new=$(echo "$old" | sed -e "s,^$1,$2,")
+ awk -v old="$old" -v new="$new" \
'{ if ($0 == old) print new; else print $0 }' \
"$series" > "$series.tmp"
diff --git a/regression/050-series.sh b/regression/050-series.sh
index eb23540..4c47e9d 100755
--- a/regression/050-series.sh
+++ b/regression/050-series.sh
@@ -26,7 +26,7 @@ modify
add
remove
-mode
+mode # and text
#sure
DONE
}
--
1.5.2
^ permalink raw reply related
* Re: [RFH PATCH] Teach the emacs git mode about core.excludesfile
From: Matthieu Moy @ 2007-07-31 1:58 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Alexandre Julliard, git
In-Reply-To: <20070731011100.23561.27554.stgit@yoghurt>
Karl Hasselström <kha@treskal.com> writes:
> If there is a core.excludesfile option specified, let the emacs git
> mode take exclude patterns from that file, since that's what the docs
> say, and what everyone else is already doing.
>
> Signed-off-by: Karl Hasselström <kha@treskal.com>
> ---
>
> This is a Request For Help. The patch works, but is clearly the work
> of someone who is not very fluent in elisp. Just look at all that
> duplicated code I've introduced!
>
> contrib/emacs/git.el | 19 ++++++++++++++++---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 53dd703..357e6d2 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -589,6 +589,13 @@ Return the list of files that haven't been handled."
> (when node (push (ewoc-data node) unmerged-files))))
> (git-set-files-state unmerged-files 'unmerged))))
>
> +(defun git-core-excludesfile ()
> + "The file core.excludesfile, or nil if it isn't specified."
> + (let ((fn (git-config "core.excludesfile")))
> + (if (and fn (file-readable-p fn))
> + fn
> + nil)))
> +
> (defun git-update-status-files (files &optional default-state)
> "Update the status of FILES from the index."
> (unless git-status (error "Not in git-status buffer."))
> @@ -600,9 +607,15 @@ Return the list of files that haven't been handled."
> (git-run-ls-unmerged status files)
> (when (and (or (not files) remaining-files)
> (file-readable-p ".git/info/exclude"))
> - (setq remaining-files (git-run-ls-files status remaining-files
> - 'unknown "-o" "--exclude-from=.git/info/exclude"
> - (concat "--exclude-per-directory=" git-per-dir-ignore-file))))
What you're looking for probably looks like that:
(let ((ce (git-core-excludesfile)))
(setq remaining-files (apply 'git-run-ls-files
`(,status ,remaining-files
unknown "-o" ... ,@(when ce
(list ce))))))
(the magic is in the backquote and the ,@ in `(... ,@(...)))
(totally untested, probably bogus)
--
Matthieu
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-31 1:44 UTC (permalink / raw)
To: Craig Boston; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20070731011707.GA91930@nowhere>
On Mon, 30 Jul 2007, Craig Boston wrote:
> >
> > So I _seriously_ hope that about 65 of those 67 seconds was the "cvs
> > update -d" or something like that.
>
> No, the only thing included in that is
>
> git ls-files -o | git update-index --add --stdin
> git commit -a -m "${COMMITMSG}"
Ouch.
> > Anything that takes a minute in git is way way *way* too slow. Any
> > half-way normal git operations should take less than a second.
>
> That said, I don't think it's git's fault. I think most of the time is
> spent calling stat() on all the files. The machine that took 60 seconds
> isn't what I'd call top-of-the-line:
>
> 1st or maybe 2nd-gen Willamette CPU
> 512MB memory (stupid motherboard that won't accept more)
> Slow disks in RAID-5 configuration
> Running ZFS with less than half of the recommended minimum memory, to
> the point where I had to reduce the number of vnodes that the kernel is
> allowed to cache to avoid running out of KVA
Oh, ok. Solaris.
With slow pathname lookup, and hard limits on the inode cache sizes.
Git really normally avoids reading the data, so even in 512M you should
_easily_ be able to cache the metadata (directory and inodes), which is
all you need. But yeah, Linux will probably do that a whole lot more
aggressively than Solaris does.
[ And to be honest, any CVS update would probably have blown the caches on
Linux too - I don't know what all CVS ends up doing, but from past
experience, I'll bet it's not good ]
But just for comparison, on a lowly 480MB mac-mini (running Linux, not OS
X, of course - and the 480MB is because the graphics is UMA and takes
part of the 512MB total), and the kernel archive (which is just 22k files,
not 37k), with a laptop drive:
- cold-cache "git status":
real 0m17.975s
user 0m1.098s
sys 0m0.539s
- rerunning it immediately afterwards:
real 0m1.079s
user 0m0.896s
sys 0m0.183s
so the target really _should_ generally be one second.
But yeah, in order to hit that target, you definitely do want to keep the
metadata cached, and I guess that means more than 512M on Solaris.
Linus
^ permalink raw reply
* [RFH PATCH] Teach the emacs git mode about core.excludesfile
From: Karl Hasselström @ 2007-07-31 1:13 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
If there is a core.excludesfile option specified, let the emacs git
mode take exclude patterns from that file, since that's what the docs
say, and what everyone else is already doing.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
This is a Request For Help. The patch works, but is clearly the work
of someone who is not very fluent in elisp. Just look at all that
duplicated code I've introduced!
contrib/emacs/git.el | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 53dd703..357e6d2 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -589,6 +589,13 @@ Return the list of files that haven't been handled."
(when node (push (ewoc-data node) unmerged-files))))
(git-set-files-state unmerged-files 'unmerged))))
+(defun git-core-excludesfile ()
+ "The file core.excludesfile, or nil if it isn't specified."
+ (let ((fn (git-config "core.excludesfile")))
+ (if (and fn (file-readable-p fn))
+ fn
+ nil)))
+
(defun git-update-status-files (files &optional default-state)
"Update the status of FILES from the index."
(unless git-status (error "Not in git-status buffer."))
@@ -600,9 +607,15 @@ Return the list of files that haven't been handled."
(git-run-ls-unmerged status files)
(when (and (or (not files) remaining-files)
(file-readable-p ".git/info/exclude"))
- (setq remaining-files (git-run-ls-files status remaining-files
- 'unknown "-o" "--exclude-from=.git/info/exclude"
- (concat "--exclude-per-directory=" git-per-dir-ignore-file))))
+ (let ((ce (git-core-excludesfile)))
+ (if ce
+ (setq remaining-files (git-run-ls-files status remaining-files
+ 'unknown "-o" "--exclude-from=.git/info/exclude"
+ (concat "--exclude-per-directory=" git-per-dir-ignore-file)
+ (concat "--exclude-from=" ce)))
+ (setq remaining-files (git-run-ls-files status remaining-files
+ 'unknown "-o" "--exclude-from=.git/info/exclude"
+ (concat "--exclude-per-directory=" git-per-dir-ignore-file))))))
; mark remaining files with the default state (or remove them if nil)
(when remaining-files
(if default-state
^ permalink raw reply related
* Re: [RFC (take 2) Git User's Survey 2007
From: Shawn O. Pearce @ 2007-07-31 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Paolo Ciarrocchi
In-Reply-To: <7v7iohicvh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Might be nice to know how many people are interested in the
> > Eclipse plugin. But aside from that, I don't think its worth
> > including much about it. Maybe just have a checkbox under
> > some heading like:
> >
> > What features is Git currently missing for your needs?
>
> Intresting.
>
> If we make this a Web based survey (and I think that is the
> sensible thing to do --- many people do not want to send ballot
> over mail), I wonder if we can randomize these multi-selection
> answers to get unskewed results...
Yes. I think its already been agreed upon to make this a web based
survey, as that is easy to submit and accumlate the results through.
Many web based survey systems allow you to randomize the order of
the answers, for exactly the reason you state.
Personally I've always found such surveys to be annoying, but on
the other hand it really forces me to slow down and read the thing
when I can't just binary search through the answers looking for
what I think should be there.
--
Shawn.
^ permalink raw reply
* [RFH PATCH] Teach the emacs git mode about core.excludesfile
From: Karl Hasselström @ 2007-07-31 1:30 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
If there is a core.excludesfile option specified, let the emacs git
mode take exclude patterns from that file, since that's what the docs
say, and what everyone else is already doing.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
The patch works, but the code is anything but pretty. I need help from
someone who actually knows elisp!
(Apologies if this patch reaches the list twice; the first copy I sent
was seemingly lost, so I tried another route.)
contrib/emacs/git.el | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 53dd703..357e6d2 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -589,6 +589,13 @@ Return the list of files that haven't been handled."
(when node (push (ewoc-data node) unmerged-files))))
(git-set-files-state unmerged-files 'unmerged))))
+(defun git-core-excludesfile ()
+ "The file core.excludesfile, or nil if it isn't specified."
+ (let ((fn (git-config "core.excludesfile")))
+ (if (and fn (file-readable-p fn))
+ fn
+ nil)))
+
(defun git-update-status-files (files &optional default-state)
"Update the status of FILES from the index."
(unless git-status (error "Not in git-status buffer."))
@@ -600,9 +607,15 @@ Return the list of files that haven't been handled."
(git-run-ls-unmerged status files)
(when (and (or (not files) remaining-files)
(file-readable-p ".git/info/exclude"))
- (setq remaining-files (git-run-ls-files status remaining-files
- 'unknown "-o" "--exclude-from=.git/info/exclude"
- (concat "--exclude-per-directory=" git-per-dir-ignore-file))))
+ (let ((ce (git-core-excludesfile)))
+ (if ce
+ (setq remaining-files (git-run-ls-files status remaining-files
+ 'unknown "-o" "--exclude-from=.git/info/exclude"
+ (concat "--exclude-per-directory=" git-per-dir-ignore-file)
+ (concat "--exclude-from=" ce)))
+ (setq remaining-files (git-run-ls-files status remaining-files
+ 'unknown "-o" "--exclude-from=.git/info/exclude"
+ (concat "--exclude-per-directory=" git-per-dir-ignore-file))))))
; mark remaining files with the default state (or remove them if nil)
(when remaining-files
(if default-state
^ permalink raw reply related
* git-gui i18n / 0.9.x plans
From: Shawn O. Pearce @ 2007-07-31 1:28 UTC (permalink / raw)
To: Christian Stimming, Johannes Schindelin; +Cc: git
Now that git-gui 0.8.0 has been released I have updated both the
maint and master branches to 0.8.0. maint will carry the 0.8.0
development forward, and is strictly for bug fixes to the current
non-i18n codebase. I'm unlikely to make changes here except to
address current critical issues.
Regarding future development for the off-in-the-future 0.9.0 release
I'd like to see the i18n work merge in before we do anything else
major to git-gui. I'm likely to shift my focus to fast-import this
week, which means git-gui will probably see no major activity from
me for about the next two weeks. As soon as the i18n team has
something rebased onto current master that is ready for merging,
I'll bring it over. Yes, that's a promise on my part to try and
keep my tree frozen for a little while. :)
Other things I'd like to do in 0.9.0, but may or may not actually
do myself:
- Automatically refetch tracking branches in merge
- Text mode log viewer:
`git-log`, `git-log -g`
- File monitor on WinNT (to avoid costly Rescan on large projects)
- Remove more porcelain shell dependencies:
`git-merge`, `git-repack`, `git-remote prune`
- UI for cherry-pick/revert
- Generational GC for 'Compress Database'
- Integration with git-stash
- Hunk splitting/selection
- UI for git-tag
- Push specific tags by name (rather than by --tags)
- Pull from arbitrary URL/branch pair
Those are roughly ordered by how much I think myself and my fellow
day-job coworkers want these features, so that's probably roughly
the order I'll try to work through them after the i18n current
changes are merged in. Of course patches are also welcome. :)
I haven't yet settled on whether the first i18n enabled version would
be 0.9.0 or a 0.8.1/2. That's one reason why I want to get the i18n
changes merged early. If we have a few high quality translations
ready to go I'd rather ship them in a 0.8.x maint release than hang
onto them for another 1-2 months while the major features of the
0.9.0 release get worked on and stablized.
--
Shawn.
^ permalink raw reply
* Re: [RFC (take 2) Git User's Survey 2007
From: Junio C Hamano @ 2007-07-31 1:24 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, git, Paolo Ciarrocchi
In-Reply-To: <20070731010921.GY20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Might be nice to know how many people are interested in the
> Eclipse plugin. But aside from that, I don't think its worth
> including much about it. Maybe just have a checkbox under
> some heading like:
>
> What features is Git currently missing for your needs?
> [ ] Eclipse plugin
> [ ] wizhbang foo thing
> [ ] Other: ________________________
Intresting.
If we make this a Web based survey (and I think that is the
sensible thing to do --- many people do not want to send ballot
over mail), I wonder if we can randomize these multi-selection
answers to get unskewed results...
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Craig Boston @ 2007-07-31 1:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301629230.4161@woody.linux-foundation.org>
On Mon, Jul 30, 2007 at 04:30:22PM -0700, Linus Torvalds wrote:
> > # On branch cvs_RELENG_4
> > nothing to commit (working directory clean)
> > git: 67.65 seconds
>
> So I _seriously_ hope that about 65 of those 67 seconds was the "cvs
> update -d" or something like that.
No, the only thing included in that is
git ls-files -o | git update-index --add --stdin
git commit -a -m "${COMMITMSG}"
> Anything that takes a minute in git is way way *way* too slow. Any
> half-way normal git operations should take less than a second.
That said, I don't think it's git's fault. I think most of the time is
spent calling stat() on all the files. The machine that took 60 seconds
isn't what I'd call top-of-the-line:
1st or maybe 2nd-gen Willamette CPU
512MB memory (stupid motherboard that won't accept more)
Slow disks in RAID-5 configuration
Running ZFS with less than half of the recommended minimum memory, to
the point where I had to reduce the number of vnodes that the kernel is
allowed to cache to avoid running out of KVA
A simple find(1) over the CVS checkout directory takes almost as long.
I don't think it has enough memory to cache the whole thing. Actually I
know it can't since maxvnodes is set to 25,000 and there's 37,000 files
in the cvs checkout, so it will have to pull some directory entries from
disk regardless.
Just to be sure, I copied the cvs checkout directory and git repository
to a newer, faster dual-core machine with plenty of memory available for
caching.
The first run of 'git status' (cold cache):
git status 1.08s user 3.68s system 13% cpu 34.043 total
The second run:
git status 1.05s user 2.68s system 85% cpu 4.373 total
Based on that I'm fairly confident that most of the 60 seconds is being
spent waiting on data from the disks. On a tmpfs filesystem I can get
it even faster (1.897 seconds)
As it's a file server for which network is the usual bottleneck, and all
the git operations will be running out of cron, I'm not too worried
about it.
Craig
^ permalink raw reply
* Re: [RFC (take 2) Git User's Survey 2007
From: Shawn O. Pearce @ 2007-07-31 1:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <200707310245.56077.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
> > But I *seriously* object to calling egit a porcelain. egit is a
> > complete reimplementation of git in Java.
>
> O.K. I was not sure where to put egit (if put it at all).
> Implementations? Currently we have core-git in C, egit in Java (what is
> the progress report on this front?), and there was GSoC project of
> Git.NET (but it didn't start I think).
Right, that's an accurate state of affairs. Today egit can make
commits on the current branch. Yay, progress. :)
> Do you want question about egit in the survey?
Might be nice to know how many people are interested in the
Eclipse plugin. But aside from that, I don't think its worth
including much about it. Maybe just have a checkbox under
some heading like:
What features is Git currently missing for your needs?
[ ] Eclipse plugin
[ ] wizhbang foo thing
[ ] Other: ________________________
?
--
Shawn.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox