* Re: What is a reasonable mixed workflow for git/git-cvsserver?
From: Martin Langhoff @ 2007-07-23 14:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <AD8AD244-0B20-44E9-AEE6-9D2A75BC5091@zib.de>
On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:
> If several people commit to the same shared branch exported by
> git-cvsserver they most likely will generate a series of unsorted
> commits, as they did in the past on a single cvs branch. The
> commits will probably deal with various topics, include bug fixes,
> and some are likely more experimental and not really ready for a
> stable branch.
Keep the good commit message practices ;-) in my projects I tend to
mimic the linux and git "style" for commit msgs.
> My question is how to deal with this shared branch on the git
> side. Should a core developer rebuild a sane history from such
> a shared/mixed/unsorted branch by cherry picking the commits
> to one or more topic branches?
I think that's usually frowned upon. As the committer did his/her work
on a particular state of the tree, and tested it. So every commit at
least *should* be of a working state. Once you rewrite history as a
"normal" practice, that flies out of the window. And it's a big loss.
In a sense, it's a "history that looks tidy but is false". And it's
extra work too. I very strongly prefer good commit messages, and the
real history.
> If one did so, how could one
> bring the git-ish history back to the people connected by cvs?
> Am I allowed to reset branches exported by git-cvsserver?
> Probably not?
Indeed not. Junio rewinds/rebases pu (the proposed updates branch
mentioned earlier) regularly, but you can only do that in a pure-git
project, and with fairly experienced git users (so if they get caught
with commits on top of a rewound pu branch they'll know what to do).
cvsserver doesn't know what to do with rewinds/rebases and, more
importantly, cvs clients can't cope with it. And that is something we
cannot fix, unfortunately.
cheers,
martin
> Steffen
>
>
^ permalink raw reply
* [PATCH v2] Teach git-commit about commit message templates.
From: Steven Grimm @ 2007-07-23 13:32 UTC (permalink / raw)
To: git
These are useful in organizations that enforce particular formats
for commit messages, e.g., to specify bug IDs or test plans.
Use of the template is not enforced; it is simply used as the
initial content when the editor is invoked.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
Updated based on feedback from Dscho. This depends on his
patch to add the --strip-comments option to git-stripspace.
That seemed like a pretty uncontroversial change to me, but
I can easily switch back to "grep -v" to remove the
dependency if desired.
I am using diff > /dev/null rather than git diff --quiet
because the latter doesn't work at the moment (see the test
case I just sent to the list.)
Documentation/git-commit.txt | 8 ++++
git-commit.sh | 40 ++++++++++++++----
t/t7500-commit.sh | 96 ++++++++++++++++++++++++++++++++++++++++++
| 4 ++
t/t7500/add-content | 3 +
t/t7500/add-signed-off | 3 +
6 files changed, 146 insertions(+), 8 deletions(-)
create mode 100755 t/t7500-commit.sh
create mode 100755 t/t7500/add-comments
create mode 100755 t/t7500/add-content
create mode 100755 t/t7500/add-signed-off
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 8e0e7e2..3f36c67 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -74,6 +74,14 @@ OPTIONS
-m <msg>|--message=<msg>::
Use the given <msg> as the commit message.
+-t <file>|--template=<file>::
+ Use the contents of the given file as the initial version
+ of the commit message. The editor is invoked and you can
+ make subsequent changes. If a message is specified using
+ the `-m` or `-F` options, this option has no effect. The
+ template file may also be specified using the `commit.template`
+ configuration variable.
+
-s|--signoff::
Add Signed-off-by line at the end of the commit message.
diff --git a/git-commit.sh b/git-commit.sh
index 92749df..5a471e1 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
-USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [--template <file>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
@@ -87,6 +87,7 @@ signoff=
force_author=
only_include_assumed=
untracked_files=
+templatefile="`git config commit.template`"
while case "$#" in 0) break;; esac
do
case "$1" in
@@ -248,6 +249,13 @@ $1"
signoff=t
shift
;;
+ -t|--t|--te|--tem|--temp|--templ|--templa|--templat|--template)
+ case "$#" in 1) usage ;; esac
+ shift
+ templatefile="$1"
+ no_edit=
+ shift
+ ;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=t
shift
@@ -321,6 +329,14 @@ t,,[1-9]*)
die "No paths with -i does not make sense." ;;
esac
+if test ! -z "$templatefile" -a -z "$log_given"
+then
+ if test ! -f "$templatefile"
+ then
+ die "Commit template file does not exist."
+ fi
+fi
+
################################################################
# Prepare index to have a tree to be committed
@@ -454,6 +470,9 @@ then
elif test -f "$GIT_DIR/SQUASH_MSG"
then
cat "$GIT_DIR/SQUASH_MSG"
+elif test "$templatefile" != ""
+then
+ cat "$templatefile"
fi | git stripspace >"$GIT_DIR"/COMMIT_EDITMSG
case "$signoff" in
@@ -565,17 +584,22 @@ then
s///
q
}
- /^#/d
' "$GIT_DIR"/COMMIT_EDITMSG
else
cat "$GIT_DIR"/COMMIT_EDITMSG
fi |
-git stripspace >"$GIT_DIR"/COMMIT_MSG
-
-if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
- git stripspace |
- wc -l` &&
- test 0 -lt $cnt
+git stripspace --strip-comments >"$GIT_DIR"/COMMIT_MSG
+
+# Make sure the commit message has actual new content (something other than
+# comments, Signed-off-by lines, and lines from the template.)
+grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
+ git stripspace > "$GIT_DIR"/COMMIT_BAREMSG
+trap 'rm -f "$GIT_DIR"/COMMIT_BAREMSG' 0
+
+if test -s "$GIT_DIR"/COMMIT_BAREMSG &&
+ test -z "$templatefile" ||
+ ! (git stripspace --strip-comments < "$templatefile" |
+ diff - "$GIT_DIR"/COMMIT_BAREMSG > /dev/null)
then
if test -z "$TMP_INDEX"
then
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
new file mode 100755
index 0000000..f11ada8
--- /dev/null
+++ b/t/t7500-commit.sh
@@ -0,0 +1,96 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Steven Grimm
+#
+
+test_description='git-commit
+
+Tests for selected commit options.'
+
+. ./test-lib.sh
+
+commit_msg_is () {
+ test "`git log --pretty=format:%s%b -1`" = "$1"
+}
+
+# A sanity check to see if commit is working at all.
+test_expect_success 'a basic commit in an empty tree should succeed' '
+ echo content > foo &&
+ git add foo &&
+ git commit -m "initial commit"
+'
+
+test_expect_success 'nonexistent template file should return error' '
+ echo changes >> foo &&
+ git add foo &&
+ ! git commit --template "$PWD"/notexist
+'
+
+test_expect_success 'nonexistent template file in config should return error' '
+ git config commit.template "$PWD"/notexist &&
+ ! git commit &&
+ git config --unset commit.template
+'
+
+# From now on we'll use a template file that exists.
+TEMPLATE="$PWD"/template
+
+test_expect_success 'unedited template should not commit' '
+ echo "template line" > "$TEMPLATE" &&
+ ! git commit --template "$TEMPLATE"
+'
+
+test_expect_success 'unedited template with comments should not commit' '
+ echo "# comment in template" >> "$TEMPLATE" &&
+ ! git commit --template "$TEMPLATE"
+'
+
+test_expect_success 'a Signed-off-by line by itself should not commit' '
+ ! GIT_EDITOR=../t7500/add-signed-off git commit --template "$TEMPLATE"
+'
+
+test_expect_success 'adding comments to a template should not commit' '
+ ! GIT_EDITOR=../t7500/add-comments git commit --template "$TEMPLATE"
+'
+
+test_expect_success 'adding real content to a template should commit' '
+ GIT_EDITOR=../t7500/add-content git commit --template "$TEMPLATE" &&
+ commit_msg_is "template linecommit message"
+'
+
+test_expect_success '-t option should be short for --template' '
+ echo "short template" > "$TEMPLATE" &&
+ echo "new content" >> foo &&
+ git add foo &&
+ GIT_EDITOR=../t7500/add-content git commit -t "$TEMPLATE" &&
+ commit_msg_is "short templatecommit message"
+'
+
+test_expect_success 'config-specified template should commit' '
+ echo "new template" > "$TEMPLATE" &&
+ git config commit.template "$TEMPLATE" &&
+ echo "more content" >> foo &&
+ git add foo &&
+ GIT_EDITOR=../t7500/add-content git commit &&
+ git config --unset commit.template &&
+ commit_msg_is "new templatecommit message"
+'
+
+test_expect_success 'explicit commit message should override template' '
+ echo "still more content" >> foo &&
+ git add foo &&
+ GIT_EDITOR=../t7500/add-content git commit --template "$TEMPLATE" \
+ -m "command line msg" &&
+ commit_msg_is "command line msg<unknown>"
+'
+
+test_expect_success 'commit message from file should override template' '
+ echo "content galore" >> foo &&
+ git add foo &&
+ echo "standard input msg" |
+ GIT_EDITOR=../t7500/add-content git commit \
+ --template "$TEMPLATE" --file - &&
+ commit_msg_is "standard input msg<unknown>"
+'
+
+test_done
--git a/t/t7500/add-comments b/t/t7500/add-comments
new file mode 100755
index 0000000..a72e65c
--- /dev/null
+++ b/t/t7500/add-comments
@@ -0,0 +1,4 @@
+#!/bin/sh
+echo "# this is a new comment" >> "$1"
+echo "# and so is this" >> "$1"
+exit 0
diff --git a/t/t7500/add-content b/t/t7500/add-content
new file mode 100755
index 0000000..2fa3d86
--- /dev/null
+++ b/t/t7500/add-content
@@ -0,0 +1,3 @@
+#!/bin/sh
+echo "commit message" >> "$1"
+exit 0
diff --git a/t/t7500/add-signed-off b/t/t7500/add-signed-off
new file mode 100755
index 0000000..e1d856a
--- /dev/null
+++ b/t/t7500/add-signed-off
@@ -0,0 +1,3 @@
+#!/bin/sh
+echo "Signed-off-by: foo <bar@frotz>" >> "$1"
+exit 0
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* [PATCH] Test case for "git diff" outside a git repo
From: Steven Grimm @ 2007-07-23 13:22 UTC (permalink / raw)
To: git
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
git-diff --quiet is pretty broken right now. If you do
"strace git diff --quiet file1 file2" you will see that
it never calls open() on either file! And it always
returns a zero exit code whether or not the files are
different.
I'm trying to follow the code to figure out what's going on,
but meanwhile, here's a test case. Perhaps someone more
familiar with the diff code will beat me to a fix.
t/t4021-diff-norepo.sh | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
create mode 100755 t/t4021-diff-norepo.sh
diff --git a/t/t4021-diff-norepo.sh b/t/t4021-diff-norepo.sh
new file mode 100755
index 0000000..dfee3d7
--- /dev/null
+++ b/t/t4021-diff-norepo.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description='test git diff outside a repo'
+
+. ./test-lib.sh
+
+rm -rf .git
+
+test_expect_success setup '
+
+ echo content1 >file1a &&
+ echo content1 >file1b &&
+ echo content2 >file2
+'
+
+test_expect_success 'zero return value with --quiet for different files' '
+
+ git diff --quiet file1a file2
+'
+
+test_expect_success 'nonzero return value with --quiet for identical files' '
+
+ ! git diff --quiet file1a file1b >/dev/null
+'
+
+test_done
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* index-pack died on pread
From: Michal Rokos @ 2007-07-23 12:52 UTC (permalink / raw)
To: GIT
Hello,
it's more and more common that I get an index-pack death for pread
that returns 0... Did anybody encountered the same?
Some more details:
# uname -a
HP-UX aa B.11.11 U 9000/800 1009938148 unlimited-user license
# git --version
git version 1.5.2.4
# git-clone git://git.kernel.org/pub/scm/git/git
Initialized empty Git repository in /home/tpiiuser/mr/git/.git/
remote: Generating pack...
remote: Done counting 55910 objects.
remote: Deltifying 55910 objects...
remote: 100% (55910/55910) done
Indexing 55910 objects...
remote: Total 55910 (delta 39003), reused 55304 (delta 38552)
100% (55910/55910) done
Resolving 39003 deltas...
fatal: cannot pread pack file: No such file or directory (n=0,
errno=2, fd=3, ptr=40452958, len=428, rdy=0, off=123601)
fatal: index-pack died with error code 128
fetch-pack from 'git://git.kernel.org/pub/scm/git/git' failed.
... please note that I added printing details to die() for pread.
HPUX pread manpage seems to be here:
http://modman.unixdev.net/?sektion=2&page=pread&manpath=HP-UX-11.11
Michal
PS: Please CC me.
^ permalink raw reply
* [ANNOUNCE]: PyGit and libgit-thin
From: Luiz Fernando N. Capitulino @ 2007-07-23 12:35 UTC (permalink / raw)
To: git, Shawn O. Pearce
Hi there,
I'm the student working on the gsoc libfication project with Shawn and it
has reached the point where I need some feedback in order to decide
what to do next.
The project's goal was/is to change what is needed in GIT in order to make
it easier to use as library. This is useful for 'external'
applications which wants
to be able to perform GIT operations w/o having to fork-exec GIT process (and
also w/o having to parse git's programs output). Example of such applications
are language bindings and IDEs' plugins.
However, the need for this is not a consensus. Some disagree (Linus included
I think) and IIRC Junio has stated that he'd probably be against a stable API.
So, in order to make things simple and have a clear separation of what is
additional interface not needed by GIT we (Shawn and I) have decided to work
on a new library which uses git's low-level interface.
That library is called libgit-thin and currently it's capable of
revision listing,
commit parsing and some other things.
To demonstrate how to use the library, I've also written a python module which
exports to python all the library's functionality.
Now I need to know whether this' really useful to other people and if so, what
would be missing for you to start using it.
The project can be found at:
http://repo.or.cz/w/git/libgit-gsoc.git
Look into the 'libgit-thin' directory. Note that it's a fork of
Junio's tree, so if you have
his repository around do:
$ git clone --reference /path/to/junio/repo git://repo.or.cz/git/libgit-gsoc.git
A demo of the python's module is available here:
http://repo.or.cz/w/git/libgit-gsoc.git?a=blob;f=libgit-thin/pygit/demo.txt;h=f4f9cb726e06ac18a3bf125f3caa7c50dd095361;hb=HEAD
Please, keep in mind that the library's code is still experimental and most of
the python module's code is untested.
It's also important to say that there's no much documentation
available, you'll have
to know a bit about git's implementation for this stuff to be useful for you.
Thanks a lot for reading this and any kind of feedback is welcome.
--
Luiz Fernando N. Capitulino
^ permalink raw reply
* [PATCH] Teach "git stripspace" the --strip-comments option
From: Johannes Schindelin @ 2007-07-23 11:58 UTC (permalink / raw)
To: git, gitster
With --strip-comments (or short -s), git stripspace now removes lines
beginning with a '#', too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-stripspace.txt | 5 ++++-
builtin-stripspace.c | 7 ++++++-
t/t0030-stripspace.sh | 5 +++++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt
index 1306d7b..5212358 100644
--- a/Documentation/git-stripspace.txt
+++ b/Documentation/git-stripspace.txt
@@ -8,7 +8,7 @@ git-stripspace - Filter out empty lines
SYNOPSIS
--------
-'git-stripspace' < <stream>
+'git-stripspace' [-s | --strip-comments] < <stream>
DESCRIPTION
-----------
@@ -16,6 +16,9 @@ Remove multiple empty lines, and empty lines at beginning and end.
OPTIONS
-------
+-s\|--strip-comments::
+ In addition to empty lines, also strip lines starting with '#'.
+
<stream>::
Byte stream to act on.
diff --git a/builtin-stripspace.c b/builtin-stripspace.c
index 5571687..916355c 100644
--- a/builtin-stripspace.c
+++ b/builtin-stripspace.c
@@ -76,6 +76,11 @@ int cmd_stripspace(int argc, const char **argv, const char *prefix)
{
char *buffer;
unsigned long size;
+ int strip_comments = 0;
+
+ if (argc > 1 && (!strcmp(argv[1], "-s") ||
+ !strcmp(argv[1], "--strip-comments")))
+ strip_comments = 1;
size = 1024;
buffer = xmalloc(size);
@@ -84,7 +89,7 @@ int cmd_stripspace(int argc, const char **argv, const char *prefix)
die("could not read the input");
}
- size = stripspace(buffer, size, 0);
+ size = stripspace(buffer, size, strip_comments);
write_or_die(1, buffer, size);
if (size)
putc('\n', stdout);
diff --git a/t/t0030-stripspace.sh b/t/t0030-stripspace.sh
index b1c9003..cad95f3 100755
--- a/t/t0030-stripspace.sh
+++ b/t/t0030-stripspace.sh
@@ -392,4 +392,9 @@ test_expect_success \
git diff expect actual
'
+test_expect_success 'strip comments, too' '
+ test ! -z "$(echo "# comment" | git stripspace)" &&
+ test -z "$(echo "# comment" | git stripspace -s)"
+'
+
test_done
--
1.5.3.rc2.32.g35c5b
^ permalink raw reply related
* Re: [PATCH] Teach git-commit about commit message templates.
From: Johannes Schindelin @ 2007-07-23 11:58 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <46A48949.1020501@midwinter.com>
Hi,
On Mon, 23 Jul 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > Ah, I missed that. But IIRC your patch does not wrap that logic behind test
> > ! -z "$templatefile", right? So this is my modified suggestion:
> >
> > test ! -z "$templatefile" && {
> > grep -vie '^Signed-off-by:' < "$GIT_DIR"/COMMIT_MSG" > "$GIT_DIR"/tmp1
> > grep -ve '^#' < "$templatefile" > "$GIT_DIR"/tmp1
> > trap 'rm "$GIT_DIR"/tmp[12]' 0
> > cmp "$GIT_DIR"/tmp[12] &&
> > die "Unchanged message; will not commit"
> > }
> >
>
> So you are suggesting I do this in addition to the existing git-commit
> stripping of Signed-off-by: lines? I can certainly do that, but I didn't want
> to make two passes over the commit message doing exactly the same stripping.
>
> Hmm, maybe I should outline my understanding of the current (unpatched)
> behavior and what I want it to do. Currently:
>
> * Strip off all comment lines (happens when COMMIT_MSG is created)
> * Strip off all Signed-off-by: lines
> * Trim whitespace
> * If the result has no content (`wc -l` == 0), abort.
>
> With the patch, my intent was:
>
> * Strip off all comment lines
> * Strip off all Signed-off-by: lines
> * Trim whitespace
> * If the result has no content (! -s file), abort.
> * If a template file was specified:
> * Strip off all comment and Signed-off-by: lines from the template
> * Trim whitespace from the template
> * If the resulting trimmed template is the same as the trimmed commit
> message, abort.
>
> So I guess before getting to the specifics of the code, I'll ask: does the
> above make sense as a design? I wanted to preserve the existing behavior in
> the absence of a template.
Yes, I think that makes sense.
> Since the existing code is already stripping Signed-off-by: lines to test for
> a zero-length commit message, I figured I should reuse that work. However,
> it's no big deal to do it twice if people feel that results in more readable
> code -- certainly no human will ever notice the time it takes to re-grep the
> commit message.
Okay, but I was really confused by the big if thing.
I'd make sure that COMMIT_BAREMSG is removed with a trap, and really try
to just enhance the
if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
git stripspace |
wc -l` &&
test 0 -lt $cnt
so that it reads something like
if test -s "$GIT_DIR"/COMMIT_BAREMSG &&
test -z "$templatefile" ||
(grep -ve '^#' < "$templatefile" |
git stripspace |
git diff --quiet - "$GIT_DIR"/COMMIT_BAREMSG)
then
...
(Totally untested, of course.) Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: What is a reasonable mixed workflow for git/git-cvsserver?
From: Steffen Prohaska @ 2007-07-23 11:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90707230359u5fac77a4i7b6a350d3bb29e3b@mail.gmail.com>
On Jul 23, 2007, at 12:59 PM, Martin Langhoff wrote:
>> What is a reasonable way to handle the unsorted commits
>> from a shared branch in a more git-ish way? I googled a bit
>> but didn't find a good explanation on the web.
>
> I am not sure what you mean by unsorted commits... "proposed patches"?
> The git project itself has a proposed-updates branch that might serve
> as an example. And repo.or.cz has the strange concept of the mob
> branch that you might want to have a look at.
The mob branch seems to be related, although I do not plan for
an anonymous mob but only for the cvs mob ...
If several people commit to the same shared branch exported by
git-cvsserver they most likely will generate a series of unsorted
commits, as they did in the past on a single cvs branch. The
commits will probably deal with various topics, include bug fixes,
and some are likely more experimental and not really ready for a
stable branch.
My question is how to deal with this shared branch on the git
side. Should a core developer rebuild a sane history from such
a shared/mixed/unsorted branch by cherry picking the commits
to one or more topic branches? If one did so, how could one
bring the git-ish history back to the people connected by cvs?
Am I allowed to reset branches exported by git-cvsserver?
Probably not?
Steffen
^ permalink raw reply
* [PATCH] Use Peter J. Weinberger's hash function in xdiff
From: Marco Costalba @ 2007-07-23 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
It seems a little bit faster then current one:
WITH CURRENT ONE
git tree
$ time git diff v0.99.. > /dev/null
0.91user 0.02system 0:01.03elapsed 91%CPU
(0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3594minor)pagefaults 0swaps
Linux tree
$ time git diff v2.6.22.. > /dev/null
13.61user 0.19system 0:13.90elapsed 99%CPU
(0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+27279minor)pagefaults 0swaps
WITH NEW ONE
git tree
$ time git diff v0.99.. > /dev/null
0.87user 0.01system 0:00.98elapsed 90%CPU
(0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3594minor)pagefaults 0swaps
Linux tree
$ time git diff v2.6.22.. > /dev/null
13.26user 0.21system 0:13.57elapsed 99%CPU
(0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+27277minor)pagefaults 0swaps
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
This patch is not intended for inclusion, the time diff is very small,
but it would be interestiing to understand from where it comes from
possibly from people more versed then me in hashing functions.
BTW this modified Weinberger's hash function is the one used in Qt
library, for the QHash class.
xdiff/xutils.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 2ade97b..c19ab6e 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -270,24 +270,32 @@ static unsigned long
return ha;
}
+/*
+ This function is based on Peter J. Weinberger's hash function
+ (from the Dragon Book). The constant 24 in the original function
+ was replaced with 23 to produce fewer collisions on input such as
+ "a", "aa", "aaa", "aaaa", ...
+*/
unsigned long xdl_hash_record(char const **data, char const *top, long flags) {
- unsigned long ha = 5381;
+
+ unsigned long ha = 0;
+ unsigned long g;
char const *ptr = *data;
if (flags & XDF_WHITESPACE_FLAGS)
return xdl_hash_record_with_whitespace(data, top, flags);
- for (; ptr < top && *ptr != '\n'; ptr++) {
- ha += (ha << 5);
- ha ^= (unsigned long) *ptr;
+ while (ptr < top && *ptr != '\n') {
+ ha = (ha << 4) + *ptr++;
+ if ((g = (ha & 0xf0000000)) != 0)
+ ha ^= g >> 23;
+ ha &= ~g;
}
*data = ptr < top ? ptr + 1: ptr;
-
return ha;
}
-
unsigned int xdl_hashbits(unsigned int size) {
unsigned int val = 1, bits = 0;
--
1.5.3.rc2.29.gc4640f-dirty
^ permalink raw reply related
* Re: What is a reasonable mixed workflow for git/git-cvsserver?
From: Martin Langhoff @ 2007-07-23 10:59 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <E8B0B250-A428-4CDC-A4D2-FFCF45953076@zib.de>
On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:
> What's a reasonable workflow when some people use git and
> other people use git-cvsserver simultaneously?
It was written on the concept that the core developers would switch to
git and occassional committers and less sophisticated SCM users like
translators would be able to continue using cvs.
Basically, cvs users can no longer tag or open new branches. So your
plan is exactly what we set out to support. Switching branches is not
possibe -- that's unfortunate, but emulating CVS's branching is a
bridge too far :-)
> What is a reasonable way to handle the unsorted commits
> from a shared branch in a more git-ish way? I googled a bit
> but didn't find a good explanation on the web.
I am not sure what you mean by unsorted commits... "proposed patches"?
The git project itself has a proposed-updates branch that might serve
as an example. And repo.or.cz has the strange concept of the mob
branch that you might want to have a look at.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Steven Grimm @ 2007-07-23 10:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707231136530.14781@racer.site>
Johannes Schindelin wrote:
> Ah, I missed that. But IIRC your patch does not wrap that logic behind
> test ! -z "$templatefile", right? So this is my modified suggestion:
>
> test ! -z "$templatefile" && {
> grep -vie '^Signed-off-by:' < "$GIT_DIR"/COMMIT_MSG" > "$GIT_DIR"/tmp1
> grep -ve '^#' < "$templatefile" > "$GIT_DIR"/tmp1
> trap 'rm "$GIT_DIR"/tmp[12]' 0
> cmp "$GIT_DIR"/tmp[12] &&
> die "Unchanged message; will not commit"
> }
>
So you are suggesting I do this in addition to the existing git-commit
stripping of Signed-off-by: lines? I can certainly do that, but I didn't
want to make two passes over the commit message doing exactly the same
stripping.
Hmm, maybe I should outline my understanding of the current (unpatched)
behavior and what I want it to do. Currently:
* Strip off all comment lines (happens when COMMIT_MSG is created)
* Strip off all Signed-off-by: lines
* Trim whitespace
* If the result has no content (`wc -l` == 0), abort.
With the patch, my intent was:
* Strip off all comment lines
* Strip off all Signed-off-by: lines
* Trim whitespace
* If the result has no content (! -s file), abort.
* If a template file was specified:
* Strip off all comment and Signed-off-by: lines from the template
* Trim whitespace from the template
* If the resulting trimmed template is the same as the trimmed commit
message, abort.
So I guess before getting to the specifics of the code, I'll ask: does
the above make sense as a design? I wanted to preserve the existing
behavior in the absence of a template.
Since the existing code is already stripping Signed-off-by: lines to
test for a zero-length commit message, I figured I should reuse that
work. However, it's no big deal to do it twice if people feel that
results in more readable code -- certainly no human will ever notice the
time it takes to re-grep the commit message.
-Steve
^ permalink raw reply
* Re: Feedback on native Win32 git from a Perl perspective
From: Martin Langhoff @ 2007-07-23 10:48 UTC (permalink / raw)
To: Adam Kennedy; +Cc: git
In-Reply-To: <46A4337E.2090303@phase-n.com>
On 7/23/07, Adam Kennedy <adam@phase-n.com> wrote:
> The main problem is that on Windows for the most part there is just no
> concept of "first install $something" (be that a run-time, cygwin, or
> whatever).
Agreed. And then you get in trouble if the stuff you are bundling
conflicts with software tht the user has already, or installs later...
> For the Vanilla/Strawberry Perl installers (http://vanillaperl.com/) the
> approach we ended up with to get full toolchain functionality out of the
> box was to bundle a copy of the MinGW packages we needed, as well as
> bundling a copy of dmake.
>
> The approach ActivePerl takes is to not bundle any of these parts,
I was a longtime ActivePerl user. I remember the pain.
>From the page you link, you are shipping Strawberry Perl for the
simple install with all included cases, and vanilla for people who
want to package their own perl or get Just Perl.
Sounds like a good plan -- hopefully bundling minGW isn't too hard.
m
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-23 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <Pine.LNX.4.64.0707231129010.14781@racer.site>
Hi,
On Mon, 23 Jul 2007, Johannes Schindelin wrote:
> struct stat st;
> int i = 0;
>
> while (i++ < 10 && !lstat(path, &st) && S_ISLNK(st.st_mode)) {
> ssize_t sz;
> static char target[PATH_MAX];
> sz = readlink(path, target, sizeof(target));
> if (sz < 0)
> die("Cannot readlink %s", path);
> else
> path = target;
Probably this should be "make_absolute_path(target)" after applying the
minipatch I provided elsewhere.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Johannes Schindelin @ 2007-07-23 10:40 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <46A481B4.7000502@midwinter.com>
Hi,
On Mon, 23 Jul 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > Up until here, I was with you. But this feels very wrong.
> >
> > Why not compare COMMIT_MSG to the templatefile, if there is one? I.e.
> >
> > test ! -z "$templatefile" && cmp "$GIT_DIR"/COMMIT_MSG "$templatefile" &&
> > die "Unchanged message; will not commit"
> >
>
> The template can itself have comments -- instructions or explanations of
> fields to fill in, for example -- and since comments have been stripped
> from COMMIT_MSG at this point, a comparison against such a template
> would always fail.
Ah, I missed that. But IIRC your patch does not wrap that logic behind
test ! -z "$templatefile", right? So this is my modified suggestion:
test ! -z "$templatefile" && {
grep -vie '^Signed-off-by:' < "$GIT_DIR"/COMMIT_MSG" > "$GIT_DIR"/tmp1
grep -ve '^#' < "$templatefile" > "$GIT_DIR"/tmp1
trap 'rm "$GIT_DIR"/tmp[12]' 0
cmp "$GIT_DIR"/tmp[12] &&
die "Unchanged message; will not commit"
}
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-23 10:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <7v1wezohi4.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 22 Jul 2007, Junio C Hamano wrote:
> @@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)
> static int lock_file(struct lock_file *lk, const char *path)
> {
> int fd;
> + struct stat st;
> +
> + if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
> + ssize_t sz;
> + static char target[PATH_MAX];
> + sz = readlink(path, target, sizeof(target));
> + if (sz < 0)
> + warning("Cannot readlink %s", path);
> + else
> + path = target;
> + }
I wonder if we should not make this a while loop:
struct stat st;
int i = 0;
while (i++ < 10 && !lstat(path, &st) && S_ISLNK(st.st_mode)) {
ssize_t sz;
static char target[PATH_MAX];
sz = readlink(path, target, sizeof(target));
if (sz < 0)
die("Cannot readlink %s", path);
else
path = target;
}
if (i == 10)
die ("Too deep symlink depth: %s", path);
(As you see, I would not warn, but die if readlink fails.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Steven Grimm @ 2007-07-23 10:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707231059490.14781@racer.site>
Johannes Schindelin wrote:
> Up until here, I was with you. But this feels very wrong.
>
> Why not compare COMMIT_MSG to the templatefile, if there is one? I.e.
>
> test ! -z "$templatefile" && cmp "$GIT_DIR"/COMMIT_MSG "$templatefile" &&
> die "Unchanged message; will not commit"
>
The template can itself have comments -- instructions or explanations of
fields to fill in, for example -- and since comments have been stripped
from COMMIT_MSG at this point, a comparison against such a template
would always fail. And, consistent with the current behavior, simply
adding a Signed-off-by: line shouldn't count as supplying a commit message.
I could do this test before stripping comments from COMMIT_MSG, but then
I'd still fail the comparison if the user just deleted some comment
lines manually, which also seems wrong to me -- the comments should be
totally ignored when doing this comparison, IMO. Plus that wouldn't
ignore Signed-off-by: lines.
If I'm coming at the design the wrong way, I'm of course happy to adjust
it, but insensitivity to both comments and Signed-off-by: lines seemed
like the right behavior from the user's POV to me, and I didn't see a
cleaner way to do it.
Thanks for looking at the patch!
-Steve
^ permalink raw reply
* Re: What is a reasonable mixed workflow for git/git-cvsserver?
From: Johannes Schindelin @ 2007-07-23 10:16 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <E8B0B250-A428-4CDC-A4D2-FFCF45953076@zib.de>
Hi,
On Mon, 23 Jul 2007, Steffen Prohaska wrote:
> What's a reasonable workflow when some people use git and other people
> use git-cvsserver simultaneously?
This is what we did here:
We cvsimported the whole stuff (but we did not have your problems, since
there was only one branch). Then we initialised a shared repository with
that branch, turned on git-cvsserver (and found a few bugs, but that was
long ago, and AFAIR all our issues were fixed) and went to work.
There were a few committing via cvs, and a few others committing via git.
One person only tracked via cvs, not contributing code, just reviewing
and testing.
We did not have the need to impose certain restrictions, such as git-shell
(to prevent invoking other programs), or hooks refusing a push that
touches parts the person pushing has no business changing.
But we had the option to go there, if needed. So far, all went fine. And
I'm convinced that it is partly because of the trust model. After all, I
still have my local repository. And that I can trust at all times.
So if a poisonous person (instead of thrashing the mailing list with long
mails) would have decided to corrupt the repo, we would have realised that
pretty quickly, repaired the damage without much effort, and kicked out
that person.
Needless to say that all our devs converted to Git. And I'm happy to say
that they're all happy with it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Johannes Schindelin @ 2007-07-23 10:04 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20070723041741.GA22461@midwinter.com>
Hi,
On Sun, 22 Jul 2007, Steven Grimm wrote:
> @@ -572,10 +591,35 @@ else
> fi |
> git stripspace >"$GIT_DIR"/COMMIT_MSG
>
> -if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
> - git stripspace |
> - wc -l` &&
> - test 0 -lt $cnt
> +# Test whether the commit message has any content we didn't supply.
> +have_commitmsg=
> +grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
> + git stripspace > "$GIT_DIR"/COMMIT_BAREMSG
Up until here, I was with you. But this feels very wrong.
Why not compare COMMIT_MSG to the templatefile, if there is one? I.e.
test ! -z "$templatefile" && cmp "$GIT_DIR"/COMMIT_MSG "$templatefile" &&
die "Unchanged message; will not commit"
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-gui-i18n: Fix translation of the context menu
From: Johannes Schindelin @ 2007-07-23 9:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070723035122.GB32566@spearce.org>
Hi,
On Sun, 22 Jul 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > diff --git a/git-gui.sh b/git-gui.sh
> > index 075a2b9..52170ee 100755
> > --- a/git-gui.sh
> > +++ b/git-gui.sh
> > @@ -2457,9 +2457,9 @@ bind_button3 $ui_diff "
> > set cursorX %x
> > set cursorY %y
> > if {\$ui_index eq \$current_diff_side} {
> > - $ctxm entryconf $ui_diff_applyhunk -label [mc {Unstage Hunk From Commit}]
> > + $ctxm entryconf $ui_diff_applyhunk -label \"[mc "Unstage Hunk From Commit"]\"
>
> That's the wrong change to do here, as you are going to eval
> the result of the translation. If the translation had a Tcl
> special character (\, $, [) in it then we'd actually execute that.
> Instead the [ should be escaped:
>
> > + $ctxm entryconf $ui_diff_applyhunk -label \[mc "Unstage Hunk From Commit"\]
>
> But you aren't a Tcl programmer, so its OK. ;-)
Heh.
Thanks,
Dscho
^ permalink raw reply
* Re: RFC: git pull or git rebase?
From: Michael S. Tsirkin @ 2007-07-23 9:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: Michael S. Tsirkin, Junio C Hamano, git
In-Reply-To: <81b0412b0707230207k2fa33eb3hdc23319d1f8dbd80@mail.gmail.com>
> Quoting Alex Riesen <raa.lkml@gmail.com>:
> Subject: Re: RFC: git pull or git rebase?
>
> On 7/23/07, Michael S. Tsirkin <mst@dev.mellanox.co.il> wrote:
> >However, I wonder whether this happens to others, too.
> >Would it make sense to add a branch attribute that says
> >"do not pull this branch" or "do not rebase this branch"?
> >Maybe even make git do the right thing automatically,
> >so that git would look at this attribute and perform
> >pull or rebase as appropriate?
>
> If you have a recent enough git, it will refuse to pull into
> a branch for which there is no configured remote branch.
> Exactly for a reason like yours.
Aha. I created the tree by git clone, so my master
is configured to merge from origin automatically.
--
MST
^ permalink raw reply
* Re: [PATCH] Initial Italian translation of git-gui.pot
From: Michael @ 2007-07-23 9:09 UTC (permalink / raw)
To: Marco Costalba; +Cc: Johannes Schindelin, Paolo Ciarrocchi, git
In-Reply-To: <e5bfff550707221525w3234c5edte3c3d58b97d4d970@mail.gmail.com>
On Monday 23 July 2007 00:25, Marco Costalba wrote:
> There are some words that in my opinion it would be better do not
> translate but to leave in english, expecially on computer stuff
> italian people it's already used to the original english word.
Those who want to use the English version can always do
LANG=en_US git gui
...but since there are going to be very few non-IT people that use
git, I guess most SCM's vocabulary can be left untranslated. The
most difficult words to translate (and so probably they should be
left unchanged) in this context are "merge" and "commit".
Thinking about it, shouldn't we add an help page in git gui with
a "mini glossary" (a short version of the git glossary) in it?
Maybe something like this:
http://it.wikipedia.org/wiki/Controllo_versione#Glossario
(but more centered on git, of course).
I wonder what other SCM (or SCM gui) projects do (if they are into
i18n at all).
> In our example "resettare" it's not italian, it's a italianized (very
> ugly) form of "to reset" and it would be really better to use "reset".
Yes. I even think that "reset" is kind of common in Italy (at
least for most people that use some electronic device). But maybe
I'm wrong.
^ permalink raw reply
* Re: RFC: git pull or git rebase?
From: Alex Riesen @ 2007-07-23 9:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20070723052223.GA20614@mellanox.co.il>
On 7/23/07, Michael S. Tsirkin <mst@dev.mellanox.co.il> wrote:
> However, I wonder whether this happens to others, too.
> Would it make sense to add a branch attribute that says
> "do not pull this branch" or "do not rebase this branch"?
> Maybe even make git do the right thing automatically,
> so that git would look at this attribute and perform
> pull or rebase as appropriate?
If you have a recent enough git, it will refuse to pull into
a branch for which there is no configured remote branch.
Exactly for a reason like yours.
^ permalink raw reply
* Re: [PATCH] Initial Italian translation of git-gui.pot
From: Paolo Teti @ 2007-07-23 9:00 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Marco Costalba, Johannes Schindelin, Michael, git
In-Reply-To: <4d8e3fd30707221530v46989d88mcc65cacbc66a4e1c@mail.gmail.com>
2007/7/23, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>:
> On 7/23/07, Marco Costalba <mcostalba@gmail.com> wrote:
> > On 7/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > Forse "parte" e troppo generale per dire "hunk"?
> > >
> >
> > There are some words that in my opinion it would be better do not
> > translate but to leave in english, expecially on computer stuff
> > italian people it's already used to the original english word.
>
> Agree. We just have to agree on which words keep in English.
I'm not in love with translation of 'programming tools', but is better
to keep in English
at least words like: 'Commit', 'Reset', 'Merge', 'Commit Message' and 'Hunk'
Also is better to avoid adding context or extra words during translation .
For example in translation like "Rescan" to "Riesamina il database" the word
"database" is superfluous.
"Rescan"-> "Riesamina".. is ok
Is like the typical menu item File -> Save.. The word 'Save' has a
precise context and is
superfluous to traslate it as "Salva File" (that sound like "File ->
Save File").
Paolo
^ permalink raw reply
* Re: git-apply versus git-am
From: Junio C Hamano @ 2007-07-23 8:54 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
In-Reply-To: <a2e879e50707230054m60d45293ua1d57887367914c1@mail.gmail.com>
"Sean Kelley" <svk.sweng@gmail.com> writes:
> Why doesn't git-apply include an option for a signoff line like git-am?
>
> git-applymbox /tmp/mbox ~/.signoff
>
> Or am I missing something? (most likely the case!)
applymbox is going away.
^ permalink raw reply
* Re: [PATCH] describe: Add unlisted option
From: Junio C Hamano @ 2007-07-23 8:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Yasushi SHOJI, git
In-Reply-To: <20070723074736.GJ32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> I was actually going to suggest removing these options, that
>> were primarily meant for debugging and tweaking while we figure
>> out what the optimum default should be. Do you think they are
>> worth keeping?
>
> Yea, I do. I'd like to keep them in the code as sometimes I do
> look at their output. I'll even help maintain them, because they
> change oh so often. ;-)
>
> But if you really want them gone, I won't stop you.
Nah, I already noticed your Ack and inferred that you would want
to keep them. Haven't applied the patches yet, though.
^ 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