* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Junio C Hamano @ 2007-07-23 4:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Julian Phillips, git, gitster
In-Reply-To: <20070723035644.GC32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I live by new-workdir. I do everything with it. And today I just
> spent over an hour sorting out cases where my many, many workdirs
> have different refs than their base repositories, because their
> packed-refs files are different. Grrrrrrrrrrrrrrrrrr.
>
> So we really need to make anyone that edits packed-refs (and
> maybe also config) resolve the symlink and do the edit in the
> target directory. Then we can consider adding this workdir thing
> to core git.
This is actually not limited to packed-refs file, but applies to
other things as well.
I have been wondering if something like this patch would be
sufficient. The idea essentially is to take the lock on the
link target when we try to take a lock on something that is a
symlink pointing elsewhere.
---
lockfile.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index fb8f13b..7fc71d9 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -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;
+ }
sprintf(lk->filename, "%s.lock", path);
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= fd) {
^ permalink raw reply related
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Junio C Hamano @ 2007-07-23 4:32 UTC (permalink / raw)
To: Jason Sewall; +Cc: git, raa.lkml
In-Reply-To: <11851631511468-git-send-email-jasonsewall@gmail.com>
Jason Sewall <jasonsewall@gmail.com> writes:
> Test #7 of t9200 isn't likely to succeed because tests are executed too fast for cvs; add a delay to give it a chance to succeed.
> ---
> I think I didn't send this through the proper server, so here it is finally.
> t/t9200-git-cvsexportcommit.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
> index 4efa0c9..2096e59 100755
> --- a/t/t9200-git-cvsexportcommit.sh
> +++ b/t/t9200-git-cvsexportcommit.sh
> @@ -164,6 +164,7 @@ test_expect_success \
> git add "G g/with spaces.png" &&
> git commit -a -m "Update with spaces" &&
> id=$(git rev-list --max-count=1 HEAD) &&
> + sleep 1 &&
> (cd "$CVSWORK" &&
> git-cvsexportcommit -c $id
> test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/"
Thanks.
But this makes one wonder why only this test and nothing else is
affected. Maybe our machines are not fast enough for other
tests to execute inside a second, but in 6 months others start
to become problem and we would need a similar fix again?
I am tempted to do this instead, although it would make it much
slower.
It may be that we may want to fix this inside cvsexportcommit
itself, instead of working it around in the tests. If somebody
tries to push more than one commit from git using two
cvsexportcommit in a row, he would need to make sure that the
second run happens one or more seconds after the first run,
otherwise he will see the exact corruption in real life.
Anybody else have better ideas?
---
t/t9200-git-cvsexportcommit.sh | 29 ++++++++++++++++++-----------
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 4efa0c9..28c7dfa 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -28,6 +28,13 @@ git add empty &&
git commit -q -a -m "Initial" 2>/dev/null ||
exit 1
+git_cvsexportcommit () {
+ # CVS does not even look at files whose timestamps
+ # match the ones recorded in CVS/Entries
+ sleep 2 &&
+ git cvsexportcommit "$@"
+}
+
test_expect_success \
'New file' \
'mkdir A B C D E F &&
@@ -42,7 +49,7 @@ test_expect_success \
git commit -a -m "Test: New file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- git cvsexportcommit -c $id &&
+ git_cvsexportcommit -c $id &&
test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.1/" &&
test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "newfile2.txt/1.1/" &&
test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "newfile3.png/1.1/-kb" &&
@@ -66,7 +73,7 @@ test_expect_success \
git commit -a -m "Test: Remove, add and update" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- git cvsexportcommit -c $id &&
+ git_cvsexportcommit -c $id &&
test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
@@ -88,7 +95,7 @@ test_expect_success \
git commit -a -m "generation 2" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- ! git cvsexportcommit -c $id
+ ! git_cvsexportcommit -c $id
)'
#test_expect_success \
@@ -100,7 +107,7 @@ test_expect_success \
# git commit -a -m "generation 3" &&
# id=$(git rev-list --max-count=1 HEAD) &&
# (cd "$CVSWORK" &&
-# ! git cvsexportcommit -c $id
+# ! git_cvsexportcommit -c $id
# )'
# We reuse the state from two tests back here
@@ -114,7 +121,7 @@ test_expect_success \
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- git cvsexportcommit -c $id &&
+ git_cvsexportcommit -c $id &&
test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
@@ -132,7 +139,7 @@ test_expect_success \
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- git cvsexportcommit -c $id &&
+ git_cvsexportcommit -c $id &&
test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
@@ -153,7 +160,7 @@ test_expect_success \
git commit -a -m "With spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- git-cvsexportcommit -c $id &&
+ git_cvsexportcommit -c $id &&
test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.1/-kb with spaces.txt/1.1/"
)'
@@ -165,7 +172,7 @@ test_expect_success \
git commit -a -m "Update with spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- git-cvsexportcommit -c $id
+ git_cvsexportcommit -c $id
test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/"
)'
@@ -190,7 +197,7 @@ test_expect_success \
git commit -a -m "Går det så går det" && \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- git-cvsexportcommit -v -c $id &&
+ git_cvsexportcommit -v -c $id &&
test "$(echo $(sort Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/CVS/Entries|cut -d/ -f2,3,5))" = "gårdetsågårdet.png/1.1/-kb gårdetsågårdet.txt/1.1/"
)'
@@ -208,7 +215,7 @@ test_expect_success \
git commit -a -m "Update two" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
- ! git-cvsexportcommit -c $id
+ ! git_cvsexportcommit -c $id
)'
case "$(git repo-config --bool core.filemode)" in
@@ -225,7 +232,7 @@ test_expect_success \
git add G/off &&
git commit -a -m "Execute test" &&
(cd "$CVSWORK" &&
- git-cvsexportcommit -c HEAD
+ git_cvsexportcommit -c HEAD
test -x G/on &&
! test -x G/off
)'
^ permalink raw reply related
* [PATCH] Teach git-commit about commit message templates.
From: Steven Grimm @ 2007-07-23 4:17 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>
---
This came up at my company when someone was comparing git to
svn; we use svn's commit template feature.
I know we can abuse the pre-commit hook and stick a template in
the SQUASH_MSG file (thanks to Dscho for that idea on IRC) but
that has the annoying side effect of using the template as the
commit message if you change your mind and quit the editor
without entering anything, rather than aborting the commit.
I also know that git-commit is being builtin-ified, but as far
as I know that's still a WIP and this will work today.
This isn't perfect -- what you'd ideally want is a way to avoid
using the template for purely local "checkpoint of work in
progress" commits while still using it for commits you intend to
publish. But obviously there's no way for git to know which is
which. For local commits you can easily just empty out the
editor and type a message from scratch.
I was surprised there wasn't already a test script for commit,
but I guess it gets tested implicitly in every other script
anyway.
Documentation/git-commit.txt | 8 ++++
git-commit.sh | 54 +++++++++++++++++++++--
t/t7500-commit.sh | 96 ++++++++++++++++++++++++++++++++++++++++++
| 4 ++
t/t7500/add-content | 3 +
t/t7500/add-signed-off | 3 +
6 files changed, 163 insertions(+), 5 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..4290ae2 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
@@ -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
+
+# Is the commit message totally empty?
+if test -s "$GIT_DIR"/COMMIT_BAREMSG
+then
+ if test "$templatefile" != ""
+ then
+ # Test whether this is just the unaltered template.
+ if cnt=`sed -e '/^#/d' < "$templatefile" |
+ git stripspace |
+ diff "$GIT_DIR"/COMMIT_BAREMSG - |
+ wc -l` &&
+ test 0 -lt $cnt
+ then
+ have_commitmsg=t
+ fi
+ else
+ # No template, so the content in the commit message must
+ # have come from the user.
+ have_commitmsg=t
+ fi
+fi
+
+rm -f "$GIT_DIR"/COMMIT_BAREMSG
+
+if test "$have_commitmsg" = "t"
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
* Re: fast-import and core.autocrlf option
From: Shawn O. Pearce @ 2007-07-23 4:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Dmitry Kakurin, git
In-Reply-To: <7vwswrojzq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Right, in fast-import we only process blobs as raw blobs.
> > Its rare that we have a file path associated with the blob data
> > at the time that we are actually processing the blob itself. E.g.
> > applications can send us blobs up front, before they even start to
> > send us commits and path information.
>
> Don't the front-ends usually have path information already when
> they feed you a blob data, especially most of them operate on
> per-file history? If that is the case,...
Depends. A frontend can feed huge streams of blobs and use marks
to make us remember their SHA-1s, then later feed us those marks
and connect them to paths. Such a frontend may not have exact path
information available when it feeds the blobs to us. Then again
maybe it does. Depends on how the source information was organized.
> > So if we were to offer the CRLF->LF conversion feature in fast-import
> > it would need to be an option supplied at the time the 'data'
> > command issued, rather than based upon the gitattributes system
> > that is normally used for working tree operations.
>
> ... the "option" could be "this came from such and such path"
> instead of "this is DOS data, please apply crlf".
How do we setup .gitattributes? Should it be read from a branch
in memory, or the working directory?
If it should be read from a branch, which branch? What if the
frontend does not want the .gitattributes file in the history
of the import? Putting it into a branch just to cause CRLF->LF
translation during import would require filter-branch afterwards
to strip out the file.
I'd rather make things very explicit. If the frontend wants us to
apply a filter to a data chunk before we work further on it then
the frontend should give us the .gitattributes rules to apply as
part of the data command.
--
Shawn.
^ permalink raw reply
* [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Jason Sewall @ 2007-07-23 3:59 UTC (permalink / raw)
To: git; +Cc: gitster, raa.lkml, Jason Sewall
In-Reply-To: <7vk5ssqdy0.fsf@assigned-by-dhcp.cox.net>
Test #7 of t9200 isn't likely to succeed because tests are executed too fast for cvs; add a delay to give it a chance to succeed.
---
I think I didn't send this through the proper server, so here it is finally.
t/t9200-git-cvsexportcommit.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 4efa0c9..2096e59 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -164,6 +164,7 @@ test_expect_success \
git add "G g/with spaces.png" &&
git commit -a -m "Update with spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
+ sleep 1 &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id
test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/"
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Shawn O. Pearce @ 2007-07-23 3:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Julian Phillips, git, gitster
In-Reply-To: <Pine.LNX.4.64.0707230000020.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 22 Jul 2007, Julian Phillips wrote:
>
> > On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> >
> > > Well, I am really not interested in shooting myself in the foot, and
> > > having that option in checkout would make that much more likely. So I
> > > really, really want to have this in git-branch.
> >
> > Fair enough. Your patch - so you get to choose. I don't have any
> > strong objections (and no power to express any if I did :P) - just
> > airing my POV ;)
>
> In related news, you got me convinced that my "solution" is not
> sufficient. So I guess this patch has to wait until after 1.5.3 _and_
> after we convinced Junio to put his BASE index extension in again.
The last time we had that thing in Git it really screwed with git-gui.
I'm not looking forward to it coming back.
But anyway, I think there's something else that needs to be fixed
before this symlink workdir thing is fully in core git. Right now we
delete the .git/config and .git/packed-refs files when we edit them.
This means it is *very* unsafe to run `git-config` or `git-tag -d`
in a symlinked workdir, as the workdir will get its own config or
packed-refs file and the real repository directory won't be affected.
Now .git/config switching from symlink to real file is maybe almost
a feature.
But .git/packed-refs switching from symlink to real file is *not*
a feature. Its a massive bug.
I live by new-workdir. I do everything with it. And today I just
spent over an hour sorting out cases where my many, many workdirs
have different refs than their base repositories, because their
packed-refs files are different. Grrrrrrrrrrrrrrrrrr.
So we really need to make anyone that edits packed-refs (and
maybe also config) resolve the symlink and do the edit in the
target directory. Then we can consider adding this workdir thing
to core git.
Yes, I know, stop whining and submit a patch. I'll get around to
it soon if nobody else beats me. I just want to voice yet another
reason why this shouldn't be in 1.5.3.
--
Shawn.
^ permalink raw reply
* Re: fast-import and core.autocrlf option
From: Junio C Hamano @ 2007-07-23 3:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Dmitry Kakurin, git
In-Reply-To: <20070723034514.GZ32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Sun, 22 Jul 2007, Dmitry Kakurin wrote:
>>
>> > It looks to me that CR/LF conversion does not happen during
>> > fast-import even if I have core.autocrlf set to 'input'.
>> > Is this a bug or is there a reason for that?
>>
>> fast-import works on blobs only. So it is expected. Besides, it would
>> slow down fast-import tremendously if you wanted to introduce that
>> behaviour. Therefore I suggest just rolling your own dos2unix instead of
>> trying to play cute games with fast-import.
>
> Right, in fast-import we only process blobs as raw blobs.
> Its rare that we have a file path associated with the blob data
> at the time that we are actually processing the blob itself. E.g.
> applications can send us blobs up front, before they even start to
> send us commits and path information.
Don't the front-ends usually have path information already when
they feed you a blob data, especially most of them operate on
per-file history? If that is the case,...
> So if we were to offer the CRLF->LF conversion feature in fast-import
> it would need to be an option supplied at the time the 'data'
> command issued, rather than based upon the gitattributes system
> that is normally used for working tree operations.
... the "option" could be "this came from such and such path"
instead of "this is DOS data, please apply crlf".
^ permalink raw reply
* Re: [PATCH] git-gui-i18n: Fix translation of the context menu
From: Shawn O. Pearce @ 2007-07-23 3:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707221719430.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> There is some funny code generation going on to make the context menu,
> and the messages for this have to be doubly quoted.
>
> Noticed by Harri Ilari Tapio Liusvaara
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> git-gui.sh | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
I'll try to rewrite this hunk as a procedure, to get rid of the
double evaluation problem. However...
> 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. ;-)
--
Shawn.
^ permalink raw reply
* Re: update-po
From: Shawn O. Pearce @ 2007-07-23 3:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Johannes Schindelin, Xudong Guan, git
In-Reply-To: <7v644cosmu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> しらいしななこ <nanako3@bluebottle.com> writes:
>
> > Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> msgid "Add Existing"
> >> msgstr ""
> >>
> >
> > I had problem when translating this word "Existing" in my old translation.
> > I did not understand what that expression meaned. My old translation for
> > "Add Existing To Commit" said, because I did not understand what it meant,
> > "Add Some Existing THING To Commit", and it felt very wrong, but I could
> > not come up with anything better.
>
> I did not quite understand the "Existing" either (I do not
> use git-gui myself---I just launch it from time to time to make
> sure it does not barf on simple operations as part of the last
> minite tests before pushing changes to git.git out), and had a
> discussion on #git channel with a few people.
>
> My reading of git-gui code suggests that "Add Existing To
> Commit" is used in an item in "Commit" menu, while "Add
> Existing" is a label on the button, and they do exactly the same
> operation. It updates the index with the current contents of
> the tracked files. That is, deleted files are discarded from
> the index, and modified files are updated. IOW, "git add -u".
Yes, that's exactly correct.
> "Existing" is probably a misnomer even in the original English
> UI --- it is more about "Tracked". I think your confusion about
> "Add unexisting" is justified, because "Add Existing" operation
> is not about "existing" but "all tracked files without having me
> pick and select all of them", and the other variant, "Add To
> Commit", lets you add selected files, be they "tracked" or
> "untracked".
I agree. I'm going to change the base English version to say
"Tracked" here instead of "Existing". Its the correct term,
at least with regards to Git.
Thanks for the sanity check.
--
Shawn.
^ permalink raw reply
* Re: fast-import and core.autocrlf option
From: Shawn O. Pearce @ 2007-07-23 3:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0707230039560.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 22 Jul 2007, Dmitry Kakurin wrote:
>
> > It looks to me that CR/LF conversion does not happen during
> > fast-import even if I have core.autocrlf set to 'input'.
> > Is this a bug or is there a reason for that?
>
> fast-import works on blobs only. So it is expected. Besides, it would
> slow down fast-import tremendously if you wanted to introduce that
> behaviour. Therefore I suggest just rolling your own dos2unix instead of
> trying to play cute games with fast-import.
Right, in fast-import we only process blobs as raw blobs.
Its rare that we have a file path associated with the blob data
at the time that we are actually processing the blob itself. E.g.
applications can send us blobs up front, before they even start to
send us commits and path information.
So if we were to offer the CRLF->LF conversion feature in fast-import
it would need to be an option supplied at the time the 'data'
command issued, rather than based upon the gitattributes system
that is normally used for working tree operations.
It wouldn't be to difficult to add such an option to the data
command, but I'm not going to be able to get around to it anytime
soon. This might be an easy change for someone else to attempt if
they were interested in some Git hacking. Should all be isolated
to the cmd_data() routine in fast-import.c, and just needs to call
crlf_to_git() in convert.c, which is uh, static. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make verify-tag a builtin.
From: Johannes Schindelin @ 2007-07-23 0:52 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Junio C Hamano
In-Reply-To: <46A3F43C.3030101@gmail.com>
Hi,
On Mon, 23 Jul 2007, Carlos Rica wrote:
> +static int run_gpg_verify(const char *buf, unsigned long size, int verbose)
> +{
> + struct child_process gpg;
> + const char *args_gpg[] = {"gpg", "--verify", "FILE", "-", NULL};
> + char *path, *eol;
> + size_t len;
> + int fd, ret;
> +
> + path = xstrdup(git_path("VTAG_TMP"));
> + fd = open(path, O_CREAT | O_TRUNC | O_WRONLY, 0600);
> + if (fd < 0)
> + return error("could not create temporary file '%s': %s",
> + path, strerror(errno));
> + if (write_in_full(fd, buf, size) < 0)
> + return error("failed writing temporary file '%s': %s",
> + path, strerror(errno));
> + close(fd);
I just tested something like "gpg --verify - - < <filename>" and it
worked...
> + /* find the length without signature */
> + len = 0;
> + while (len < size && prefixcmp(buf + len, PGP_SIGNATURE "\n")) {
> + eol = memchr(buf + len, '\n', size - len);
> + len += eol ? eol - (buf + len) + 1 : size - len;
> + }
How about this instead:
const char *sig = strstr(buf, "\n" PGP_SIGNATURE "\n"));
if (!sig)
sig = buf + len;
Hmm?
But of course only if gpg does not grok "git cat-file tag <signed-tag> |
gpg --verify - -".
> + remove(path);
I think we use unlink() consistently, since we are sure it is no
directory.
> + if (type <= OBJ_NONE)
> + return error("%s: bad object type.", name);
> + if (type != OBJ_TAG)
> + return error("%s: cannot verify a non-tag object of type %s.",
> + name, typename(type));
These two can be unified into one, right?
> +int cmd_verify_tag(int argc, const char **argv, const char *prefix)
> +{
> + int i, verbose = 0, had_error = 0;
> +
> + git_config(git_default_config);
> +
> + if (argc == 1)
> + usage(builtin_verify_tag_usage);
> +
> + i = 1;
You can initialise i above.
> + if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
> + verbose = 1;
> + i++;
> + }
> +
> + signal(SIGPIPE, SIG_IGN);
> + while (i < argc)
> + if (verify_tag(argv[i++], verbose))
Heh. I thought that you only made this a separate function to help
building it into builtin-tag...
That was quick!
Ciao,
Dscho
^ permalink raw reply
* Re: update-po
From: Junio C Hamano @ 2007-07-23 0:44 UTC (permalink / raw)
To: しらいしななこ
Cc: Johannes Schindelin, Xudong Guan, git
In-Reply-To: <200707222321.l6MNL0pi005112@mi0.bluebottle.com>
しらいしななこ <nanako3@bluebottle.com> writes:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> msgid "Add Existing"
>> msgstr ""
>>
>> Actually, the 1st and the fourth copied the translation from somewhere
>> else for ja and zh_cn.
>
> I had problem when translating this word "Existing" in my old translation.
> I did not understand what that expression meaned. My old translation for
> "Add Existing To Commit" said, because I did not understand what it meant,
> "Add Some Existing THING To Commit", and it felt very wrong, but I could
> not come up with anything better.
>
> It makes me wonder if there is a corresponding "Add unexisting" command
> somewhere else, but adding something that does not exist makes no sense to
> me.
I did not quite understand the "Existing" either (I do not
use git-gui myself---I just launch it from time to time to make
sure it does not barf on simple operations as part of the last
minite tests before pushing changes to git.git out), and had a
discussion on #git channel with a few people.
My reading of git-gui code suggests that "Add Existing To
Commit" is used in an item in "Commit" menu, while "Add
Existing" is a label on the button, and they do exactly the same
operation. It updates the index with the current contents of
the tracked files. That is, deleted files are discarded from
the index, and modified files are updated. IOW, "git add -u".
"Existing" is probably a misnomer even in the original English
UI --- it is more about "Tracked". I think your confusion about
"Add unexisting" is justified, because "Add Existing" operation
is not about "existing" but "all tracked files without having me
pick and select all of them", and the other variant, "Add To
Commit", lets you add selected files, be they "tracked" or
"untracked".
Side note: I realize that "track" does not translate
well to Japanese. The literal translation E-to-J
dictionaries give us is "追跡", but looking at that word
alone gives us connotations associated with crime-drama
words, "chase" or "pursue", which is misleading. In the
context of revision control, "track" simply means "place
under version control", so probably "版管理下に置く"
(place under source control) would be the corresponding
Japanese for word "to track", but it is rather long.
We often call untracked files "files unknown to git", so the
opposite of that, "tracked file" are "files known to git".
Because we would want short-and-sweet expressions in the UI,
perhaps in Japanese translation, we can say:
"Add Existing" => "既知のファイルを再登録"
(that roughly reads "Re-Register Known Files").
Hmph, that is still too long. Maybe paraphrasing it as "Add
All Modified" would be shorter? "全ての変更を追加"
I think I like that better.
Also "staged" and "unstaged" are hard to translate words.
Googling of Japanese sites suggests that "ステージングする"
(roughly, "to perform staging") is already accepted as a verb,
so "Staged Changes (Will Be Committted)" would be "ステージング
された（コミットされる）変更" (roughly, "Changes that have been
performed <<staging>>"). Yuck.
How about this patch?
-- >8 --
[PATCH] git-gui Japanese messages: translate Add Existing, Staged and Unstaged.
Add "Existing" is probably a misnomer, so paraphrase it as "all
modifications". "To Stage" is hard to translate but "Staging"
has become Japanese word so use that word to translate "Staged"
and "Unstaged" as (roughly) "Have been (Not have been) performed
<<Staging>>".
Signed-off-by: Junio C Hamano <gitster@cox.net>
---
diff --git a/po/ja.po b/po/ja.po
index 2643acf..2f21e84 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -142,7 +142,7 @@ msgstr "コミットに追加"
#: git-gui.sh:1831
msgid "Add Existing To Commit"
-msgstr "コミットに存在するのを追加"
+msgstr "全ての変更をコミットに追加"
#: git-gui.sh:1837
msgid "Unstage From Commit"
@@ -191,19 +191,19 @@ msgstr "オンライン・ドキュメント"
#: git-gui.sh:2094
msgid "Current Branch:"
-msgstr ""
+msgstr "現在のブランチ"
#: git-gui.sh:2115
msgid "Staged Changes (Will Be Committed)"
-msgstr ""
+msgstr "ステージングされた（コミットされる）変更"
#: git-gui.sh:2135
msgid "Unstaged Changes (Will Not Be Committed)"
-msgstr ""
+msgstr "ステージングされていない（コミットされない）変更"
#: git-gui.sh:2182
msgid "Add Existing"
-msgstr ""
+msgstr "全ての変更を追加"
#: git-gui.sh:2228
msgid "Initial Commit Message:"
^ permalink raw reply related
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Johannes Schindelin @ 2007-07-23 0:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910707221711u6e965e6cr29e06fa8fb09165@mail.gmail.com>
Hi,
On Sun, 22 Jul 2007, Jon Smirl wrote:
> On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > This doesn't run on the two full kernel samples I sent you.
> >
> > You mean my script? Or your C program?
>
> Your script, I sent two big samples directly to you as attachments
> three hours ago.
Okay, I did not really test thoroughly, it seems. Sorry. Next try.
Ciao,
Dscho
-- snipsnap --
#!/usr/bin/perl
sub init_hunk {
$_ = $_[0];
$current_hunk = "";
$current_hunk_header = $_;
($start_minus, $dummy, $start_plus, $dummy) =
/^\@\@ -(\d+)(,\d+|) \+(\d+)(,\d+|) \@\@/;
$plus = $minus = $space = 0;
$skip_logs = 0;
$key = 0;
}
sub flush_hunk {
if ($plus > 0 || $minus > 0) {
if ($current_file ne "") {
print $current_file;
$current_file = "";
}
$minus += $space;
$plus += $space;
print "\@\@ -$start_minus,$minus "
. "+$start_plus,$plus \@\@\n";
print $current_hunk;
}
}
sub check_file {
$_ = $_[0];
$current_file = $_;
while (<>) {
if (/^\@\@/) {
last;
}
$current_file .= $_;
}
init_hunk $_;
# check hunks
while (<>) {
if ($skip_logs && /^\+ *\*/) {
# do nothing
} elsif ($key && /^\+.*\$$key.*\$/) {
# do nothing
} elsif (/^\@\@.*/) {
flush_hunk;
init_hunk $_;
} elsif (/^diff/) {
flush_hunk;
return;
} elsif (/^-.*\$(Id|Revision|Author|Date).*\$/) {
$key = $1;
s/^-/ /;
$current_hunk .= $_;
$space++;
$skip_logs = 0;
$key = 0;
} elsif (/^ .*\$Log.*\$/) {
$current_hunk .= $_;
$space++;
$skip_logs = 1;
$key = 0;
} elsif (/^ /) {
$current_hunk .= $_;
$space++;
$skip_logs = 0;
$key = 0;
} elsif (/^\+/) {
$current_hunk .= $_;
$plus++;
$key = 0;
} elsif (/^-/) {
$current_hunk .= $_;
$minus++;
$skip_logs = 0;
$key = 0;
} elsif (/^\\/) {
print $_;
} else {
die "Unexpected line: $_";
}
}
}
while (<>) {
if (/^diff/) {
do {
check_file $_;
} while(/^diff/);
} else {
printf $_;
}
}
^ permalink raw reply
* [PATCH] Make verify-tag a builtin.
From: Carlos Rica @ 2007-07-23 0:20 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
This replaces "git-verify-tag.sh" with "builtin-verify-tag.c".
Signal SIGPIPE is ignored because the program sometimes was
stopped because that signal when writing the input for gpg.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
Comments are welcomed.
Makefile | 3 +-
builtin-verify-tag.c | 113 ++++++++++++++++++++
builtin.h | 1 +
.../examples/git-verify-tag.sh | 0
git.c | 1 +
5 files changed, 117 insertions(+), 1 deletions(-)
create mode 100644 builtin-verify-tag.c
rename git-verify-tag.sh => contrib/examples/git-verify-tag.sh (100%)
diff --git a/Makefile b/Makefile
index 73b487f..c6ed79f 100644
--- a/Makefile
+++ b/Makefile
@@ -206,7 +206,7 @@ SCRIPT_SH = \
git-pull.sh git-rebase.sh git-rebase--interactive.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
git-sh-setup.sh \
- git-tag.sh git-verify-tag.sh \
+ git-tag.sh \
git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
@@ -367,6 +367,7 @@ BUILTIN_OBJS = \
builtin-update-ref.o \
builtin-upload-archive.o \
builtin-verify-pack.o \
+ builtin-verify-tag.o \
builtin-write-tree.o \
builtin-show-ref.o \
builtin-pack-refs.o
diff --git a/builtin-verify-tag.c b/builtin-verify-tag.c
new file mode 100644
index 0000000..586f28a
--- /dev/null
+++ b/builtin-verify-tag.c
@@ -0,0 +1,113 @@
+/*
+ * Builtin "git verify-tag"
+ *
+ * Copyright (c) 2007 Carlos Rica <jasampler@gmail.com>
+ *
+ * Based on git-verify-tag.sh
+ */
+#include "cache.h"
+#include "builtin.h"
+#include "tag.h"
+#include "run-command.h"
+#include <signal.h>
+
+static const char builtin_verify_tag_usage[] =
+ "git-verify-tag [-v|--verbose] <tag>...";
+
+#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
+
+static int run_gpg_verify(const char *buf, unsigned long size, int verbose)
+{
+ struct child_process gpg;
+ const char *args_gpg[] = {"gpg", "--verify", "FILE", "-", NULL};
+ char *path, *eol;
+ size_t len;
+ int fd, ret;
+
+ path = xstrdup(git_path("VTAG_TMP"));
+ fd = open(path, O_CREAT | O_TRUNC | O_WRONLY, 0600);
+ if (fd < 0)
+ return error("could not create temporary file '%s': %s",
+ path, strerror(errno));
+ if (write_in_full(fd, buf, size) < 0)
+ return error("failed writing temporary file '%s': %s",
+ path, strerror(errno));
+ close(fd);
+
+ /* find the length without signature */
+ len = 0;
+ while (len < size && prefixcmp(buf + len, PGP_SIGNATURE "\n")) {
+ eol = memchr(buf + len, '\n', size - len);
+ len += eol ? eol - (buf + len) + 1 : size - len;
+ }
+ if (verbose)
+ write_in_full(1, buf, len);
+
+ memset(&gpg, 0, sizeof(gpg));
+ gpg.argv = args_gpg;
+ gpg.in = -1;
+ gpg.out = 1;
+ args_gpg[2] = path;
+ if (start_command(&gpg))
+ return error("could not run gpg.");
+
+ write_in_full(gpg.in, buf, len);
+ close(gpg.in);
+ gpg.close_in = 0;
+ ret = finish_command(&gpg);
+
+ remove(path);
+ free(path);
+
+ return ret;
+}
+
+static int verify_tag(const char *name, int verbose)
+{
+ enum object_type type;
+ unsigned char sha1[20];
+ char *buf;
+ unsigned long size;
+ int ret;
+
+ if (get_sha1(name, sha1))
+ return error("tag '%s' not found.", name);
+
+ type = sha1_object_info(sha1, NULL);
+ if (type <= OBJ_NONE)
+ return error("%s: bad object type.", name);
+ if (type != OBJ_TAG)
+ return error("%s: cannot verify a non-tag object of type %s.",
+ name, typename(type));
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return error("%s: unable to read file.", name);
+
+ ret = run_gpg_verify(buf, size, verbose);
+
+ free(buf);
+ return ret;
+}
+
+int cmd_verify_tag(int argc, const char **argv, const char *prefix)
+{
+ int i, verbose = 0, had_error = 0;
+
+ git_config(git_default_config);
+
+ if (argc == 1)
+ usage(builtin_verify_tag_usage);
+
+ i = 1;
+ if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
+ verbose = 1;
+ i++;
+ }
+
+ signal(SIGPIPE, SIG_IGN);
+ while (i < argc)
+ if (verify_tag(argv[i++], verbose))
+ had_error = 1;
+ return had_error;
+}
diff --git a/builtin.h b/builtin.h
index 4cc228d..cb860a0 100644
--- a/builtin.h
+++ b/builtin.h
@@ -76,6 +76,7 @@ extern int cmd_update_index(int argc, const char **argv, const char *prefix);
extern int cmd_update_ref(int argc, const char **argv, const char *prefix);
extern int cmd_upload_archive(int argc, const char **argv, const char *prefix);
extern int cmd_upload_tar(int argc, const char **argv, const char *prefix);
+extern int cmd_verify_tag(int argc, const char **argv, const char *prefix);
extern int cmd_version(int argc, const char **argv, const char *prefix);
extern int cmd_whatchanged(int argc, const char **argv, const char *prefix);
extern int cmd_write_tree(int argc, const char **argv, const char *prefix);
diff --git a/git-verify-tag.sh b/contrib/examples/git-verify-tag.sh
similarity index 100%
rename from git-verify-tag.sh
rename to contrib/examples/git-verify-tag.sh
diff --git a/git.c b/git.c
index a647f9c..1dfe120 100644
--- a/git.c
+++ b/git.c
@@ -368,6 +368,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "update-index", cmd_update_index, RUN_SETUP },
{ "update-ref", cmd_update_ref, RUN_SETUP },
{ "upload-archive", cmd_upload_archive },
+ { "verify-tag", cmd_verify_tag, RUN_SETUP },
{ "version", cmd_version },
{ "whatchanged", cmd_whatchanged, RUN_SETUP | USE_PAGER },
{ "write-tree", cmd_write_tree, RUN_SETUP },
--
1.5.0
^ permalink raw reply related
* Re: Git tree for old kernels from before the current tree
From: Jon Smirl @ 2007-07-23 0:17 UTC (permalink / raw)
To: Michael Tharp; +Cc: H. Peter Anvin, Git Mailing List, lkml
In-Reply-To: <46A3E7BA.6030609@partiallystapled.com>
On 7/22/07, Michael Tharp <gxti@partiallystapled.com> wrote:
> H. Peter Anvin wrote:
> > Wouldn't be hard to make a git tree with all the patches all the way
> > back to 0.01 even...
>
> It'd be delightful from a completeness standpoint (and I do love
> completeness), but considering it already takes a good 20 minutes to
> clone the 2.6 tree over a respectable cable connection, I'd have to
> object on the grounds of size. Now, if it was kept off in its own tree
> for people who don't mind ravaging kernel.org resources to satisfy their
> own curiosity, that's fine too.
git has an extremely effective diffing mechanism. You may surprised at
how little it adds.
For example, git compressed the 2.6GB mozilla cvs tree down to 400MB.
I used to clone trees all the time, but now I'm much better at using
git and I haven't cloned a complete tree from kernel.org in a year.
git remote is a cool feature.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-23 0:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707230048570.14781@racer.site>
On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > This doesn't run on the two full kernel samples I sent you.
>
> You mean my script? Or your C program?
Your script, I sent two big samples directly to you as attachments
three hours ago.
Script processes them for a few pages of output and then bails out.
I have more diffs, but those two are representative of the sample
phytec patch has support for the NXP 3180 CPU which is not in the
kernel. I have a project interested in using this CPU so we are
looking at extracting the essence of 3180 support from the patch and
trying to apply it to the current kernel.
>From the phytec patch:
diff -uarN linux-2.6.10/arch/arm/vfp/entry.S
linux-2.6.10-lpc3180/arch/arm/vfp/entry.S
--- linux-2.6.10/arch/arm/vfp/entry.S 2004-12-25 05:35:27.000000000 +0800
+++ linux-2.6.10-lpc3180/arch/arm/vfp/entry.S 2006-11-20
15:49:30.000000000 +0800
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <asm/thread_info.h>
#include <asm/vfpmacros.h>
+#include <asm/constants.h>
.globl do_vfp
do_vfp:
Expected some changed $Revision line: +#define DRIVER_VERSION "$Revision: 1.2 $"
jonsmirl@jonsmirl:/extra/diffs$
>From the sonos one:
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 127a661..02dec92 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -222,7 +222,7 @@
this value.
NOTE: This does not fix shared mmaps, check out the sparc64 port for
-one way to solve this (in particular SPARC_FLAG_MMAPSHARED).
+one way to solve this (in particular arch_get_unmapped_area).
Next, you have two methods to solve the D-cache aliasing issue for all
other cases. Please keep in mind that fact that, for a given page
Expected some changed $Id line: Readme-File
/usr/src/Documentation/cdrom/aztcd
jonsmirl@jonsmirl:/extra/diffs$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: Git tree for old kernels from before the current tree
From: Jon Smirl @ 2007-07-23 0:00 UTC (permalink / raw)
To: Paul Mundt, Jan Engelhardt, Git Mailing List, lkml
In-Reply-To: <20070722211314.GA13850@linux-sh.org>
On 7/22/07, Paul Mundt <lethal@linux-sh.org> wrote:
> Anyone still sending 2.4 patches with the intent of them being moved
> forward and applied to a current kernel needs to be killfiled.
These patches are coming from companies that aren't interested in
participating in the GPL process but are being forced into releasing
code because of the license. Some of them will go out of their way to
make the changes difficult to read. All of the patches I am looking at
come from embedded systems, many of these systems are still shipping
2.4 kernels.
Most of the patches contain junk, but there are occasional diamonds.
One I'm looking at contains code for accessing encryption hardware.
The goal is to look at the vendor diffs and see if I can spot anything
useful. Spotting something useful can be hard if there are 100,000
lines of noise in the diffs, I'm also trying to spot missing drivers
so that we can ask for more code.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git tree for old kernels from before the current tree
From: Michael Tharp @ 2007-07-22 23:26 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, lkml
In-Reply-To: <46A3D5EA.2050600@zytor.com>
H. Peter Anvin wrote:
> Wouldn't be hard to make a git tree with all the patches all the way
> back to 0.01 even...
It'd be delightful from a completeness standpoint (and I do love
completeness), but considering it already takes a good 20 minutes to
clone the 2.6 tree over a respectable cable connection, I'd have to
object on the grounds of size. Now, if it was kept off in its own tree
for people who don't mind ravaging kernel.org resources to satisfy their
own curiosity, that's fine too.
-- m. tharp
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Johannes Schindelin @ 2007-07-22 23:50 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910707221645x21d74e70y3c43bc8c02a9d4ca@mail.gmail.com>
Hi,
On Sun, 22 Jul 2007, Jon Smirl wrote:
> On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > As you already did, this is my attempt at a perl script... Feel free to
> > bash my Perl capabilities, or to correct it...
>
> I don't really know Perl but Perl is probably a better language for
> this. I was doing it in C.
Yes, Perl is much much better for an application like this. You do not
have to cater for newbies, but can keep it to the technical level.
> This doesn't run on the two full kernel samples I sent you.
You mean my script? Or your C program?
> That's the problem I was having, I can catch 95% of the expanded
> keywords with my program but I have to touch up 5% by hand. I'll stare
> at this and see if I can increase my understanding of Perl.
If it is my script, please tell me what is not working. I'll fix it. In
the process, I could even add some comments...
Ciao,
Dscho
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-22 23:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707222238180.14781@racer.site>
On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> As you already did, this is my attempt at a perl script... Feel free to
> bash my Perl capabilities, or to correct it...
I don't really know Perl but Perl is probably a better language for
this. I was doing it in C.
This doesn't run on the two full kernel samples I sent you. That's the
problem I was having, I can catch 95% of the expanded keywords with my
program but I have to touch up 5% by hand. I'll stare at this and see
if I can increase my understanding of Perl.
>
> Ciao,
> Dscho
>
> -- snipsnap --
> #!/usr/bin/perl
>
> sub init_hunk {
> $_ = $_[0];
> $current_hunk = "";
> $current_hunk_header = $_;
> ($start_minus, $dummy, $start_plus, $dummy) =
> /^\@\@ -(\d+)(,\d+|) \+(\d+)(,\d+|) \@\@/;
> $plus = $minus = $space = 0;
> $skip_logs = 0;
> }
>
> sub flush_hunk {
> if ($plus > 0 || $minus > 0) {
> if ($current_file ne "") {
> print $current_file;
> $current_file = "";
> }
> $minus += $space;
> $plus += $space;
> print "\@\@ -$start_minus,$minus "
> . "+$start_plus,$plus \@\@\n";
> print $current_hunk;
> }
> }
>
> sub check_file {
> $_ = $_[0];
> $current_file = $_;
> while (<>) {
> if (/^\@\@/) {
> last;
> }
> $current_file .= $_;
> }
>
> init_hunk $_;
>
> # check hunks
> while (<>) {
> if ($skip_logs && /^\+ *\*/) {
> # do nothing
> } elsif (/^\@\@.*/) {
> flush_hunk;
> init_hunk $_;
> } elsif (/^diff/) {
> flush_hunk;
> return;
> } elsif (/^-.*\$(Id|Revision|Author|Date).*\$/) {
> $key = $1;
> s/^-/ /;
> $current_hunk .= $_;
> $space++;
> $_ = <>;
> if (!/\+.*\$Id.*\$/) {
> die "Expected some changed \$$key line: $_";
> }
> $skip_logs = 0;
> } elsif (/^ .*\$Log.*\$/) {
> $current_hunk .= $_;
> $space++;
> $skip_logs++;
> } elsif (/^ /) {
> $current_hunk .= $_;
> $space++;
> $skip_logs = 0;
> } elsif (/^\+/) {
> $current_hunk .= $_;
> $plus++;
> } elsif (/^-/) {
> $current_hunk .= $_;
> $minus++;
> $skip_logs = 0;
> } else {
> die "Unexpected line: $_";
> }
> }
> }
>
> while (<>) {
> if (/^diff/) {
> do {
> check_file $_;
> } while(/^diff/);
> } else {
> printf $_;
> }
> }
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: fast-import and core.autocrlf option
From: Johannes Schindelin @ 2007-07-22 23:41 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707221559m63fb1295jc26b1327e71687e3@mail.gmail.com>
Hi,
On Sun, 22 Jul 2007, Dmitry Kakurin wrote:
> It looks to me that CR/LF conversion does not happen during
> fast-import even if I have core.autocrlf set to 'input'.
> Is this a bug or is there a reason for that?
fast-import works on blobs only. So it is expected. Besides, it would
slow down fast-import tremendously if you wanted to introduce that
behaviour. Therefore I suggest just rolling your own dos2unix instead of
trying to play cute games with fast-import.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-22 23:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Julian Phillips
In-Reply-To: <f80mbc$si1$1@sea.gmane.org>
Hi,
[re Cc'ed Julian]
On Mon, 23 Jul 2007, Jakub Narebski wrote:
> Julian Phillips wrote:
>
> > I just think that to a user it feels like a checkout operation ... and
> > that would less confusing as an option to checkout. ?Trying to explain
> > that branch just creates a new branch, unless you give this option
> > then it creates a working copy over there seems more compilcated than
> > saying the checkout updates/creates this working copy, unless you use
> > this option to create one over there.
>
> IMVHO git-checkout is characterized that it changes _current_ working
> directory.
Actually, the name suggests that the important action is "checkout", so I
agree with Julian here.
> But having this in git-checkout would mean that you can create new
> workdir for _existing_ branch. git-branch is rather (except from
> listing) for creating new branches.
Note that it is possible to checkout the current branch with "git checkout
HEAD". Indeed, you can get the same effect with "git checkout -f HEAD" as
with "git reset --hard" AFAIK.
> It is a fact that functionalities of git-checkout (-b) and git-branch
> (--new-work-dir) intersect a bit.
Yes, I pointed that out, too. But we're not Python, so we do not have to
pretend that it is a bad thing to have several way to do the same. Which
allows us better to cater for user's expectations.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: Fix support for legacy gitweb config for snapshots
From: Junio C Hamano @ 2007-07-22 23:35 UTC (permalink / raw)
To: Matt McCutchen
Cc: Jakub Narebski, Junio C Hamano, git, Petr Baudis, Luben Tuikov
In-Reply-To: <3bbc18d20707221610q757536eet213a6d08b810b280@mail.gmail.com>
Thanks, both.
^ permalink raw reply
* Re: update-po
From: しらいしななこ @ 2007-07-22 23:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Xudong Guan, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707221352210.14781@racer.site>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> msgid "Add Existing"
> msgstr ""
>
> Actually, the 1st and the fourth copied the translation from somewhere
> else for ja and zh_cn.
I had problem when translating this word "Existing" in my old translation.
I did not understand what that expression meaned. My old translation for
"Add Existing To Commit" said, because I did not understand what it meant,
"Add Some Existing THING To Commit", and it felt very wrong, but I could
not come up with anything better.
It makes me wonder if there is a corresponding "Add unexisting" command
somewhere else, but adding something that does not exist makes no sense to
me.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4
^ permalink raw reply
* Re: [PATCH] gitweb: Fix support for legacy gitweb config for snapshots
From: Matt McCutchen @ 2007-07-22 23:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis, Luben Tuikov
In-Reply-To: <200707222341.21538.jnareb@gmail.com>
On 7/22/07, Jakub Narebski <jnareb@gmail.com> wrote:
> This commit moves legacy configuration support out of feature_snapshot
> subroutine to separate filter_snapshot_fmts subroutine. The
> filter_snapshot_fmts is used on result on result of
There's a typo: "on result" appears twice.
> On Sun, 22 July 2007, Matt McCutchen wrote:
>
> > That said: the backward compatibility code for gitweb _site_
> > configuration is broken because it is inside an if statement that only
> > runs for gitweb _repository_ configuration.
>
> Sorry for sending not fully tested code. This should fix that.
> This commit _is_ rudimentally tested.
I tested it too and it worked. I like the approach of using
filter_snapshot_fmts.
Matt
^ 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