* [PATCH 03/15] git-note: (Administrivia) Add git-note to Makefile, .gitignore, etc.
From: Johan Herland @ 2007-05-27 14:11 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano
In-Reply-To: <200705271608.02122.johan@herland.net>
Teach Makefile, .gitignore, Documentation/cmd-list.perl and
generate-cmdlist.sh on the existence of the git-note command.
The patch also does some unrelated whitespace cleanup in
Documentation/cmd-list.perl and an alphabetizing fix in .gitignore,
just to keep things neat and tidy.
Signed-off-by: Johan Herland <johan@herland.net>
---
.gitignore | 3 ++-
Documentation/cmd-list.perl | 5 +++--
Makefile | 2 +-
generate-cmdlist.sh | 1 +
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/.gitignore b/.gitignore
index 4dc0c39..0f34b94 100644
--- a/.gitignore
+++ b/.gitignore
@@ -82,8 +82,9 @@ git-merge-subtree
git-mergetool
git-mktag
git-mktree
-git-name-rev
git-mv
+git-name-rev
+git-note
git-pack-redundant
git-pack-objects
git-pack-refs
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 443802a..dc7e8b3 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -103,13 +103,13 @@ git-diff-files plumbinginterrogators
git-diff-index plumbinginterrogators
git-diff mainporcelain
git-diff-tree plumbinginterrogators
-git-fast-import ancillarymanipulators
+git-fast-import ancillarymanipulators
git-fetch mainporcelain
git-fetch-pack synchingrepositories
git-fmt-merge-msg purehelpers
git-for-each-ref plumbinginterrogators
git-format-patch mainporcelain
-git-fsck ancillaryinterrogators
+git-fsck ancillaryinterrogators
git-gc mainporcelain
git-get-tar-commit-id ancillaryinterrogators
git-grep mainporcelain
@@ -140,6 +140,7 @@ git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
git-mv mainporcelain
git-name-rev plumbinginterrogators
+git-note mainporcelain
git-pack-objects plumbingmanipulators
git-pack-redundant plumbinginterrogators
git-pack-refs ancillarymanipulators
diff --git a/Makefile b/Makefile
index 29243c6..c2f9f22 100644
--- a/Makefile
+++ b/Makefile
@@ -209,7 +209,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
- git-lost-found.sh git-quiltimport.sh
+ git-lost-found.sh git-quiltimport.sh git-note.sh
SCRIPT_PERL = \
git-add--interactive.perl \
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 975777f..0a37fd0 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -26,6 +26,7 @@ init
log
merge
mv
+note
prune
pull
push
--
1.5.2.101.gee49f
^ permalink raw reply related
* [PATCH 02/15] git-note: (Documentation) Add git-note manual page
From: Johan Herland @ 2007-05-27 14:10 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano
In-Reply-To: <200705271608.02122.johan@herland.net>
The manual page describes the operation of the git-note command, as well
as some discussion around the design and usage of git notes.
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/git-note.txt | 95 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 95 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-note.txt
diff --git a/Documentation/git-note.txt b/Documentation/git-note.txt
new file mode 100644
index 0000000..077d526
--- /dev/null
+++ b/Documentation/git-note.txt
@@ -0,0 +1,95 @@
+git-note(1)
+===========
+
+NAME
+----
+git-note - Create, list or delete git note objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git-note' [-m <msg> | -F <file>] [<head>]
+'git-note' -l [<name>...]
+'git-note' -d <name>...
+
+
+DESCRIPTION
+-----------
+Adds a 'note' in `.git/refs/notes/` on an existing git object.
+
+A 'note' is an annotation associated with an existing git object.
+The note is similar in form to a commit message.
+
+Unless `-l` or `-d` is passed, the command creates a 'note' object,
+and requires the note message. Unless `-m <msg>` or `-F <file>` is
+given, an editor is started for the user to type in the note message.
+
+`-l [<name>...]` lists notes associated with the given <name>s. If no
+<name> is given, all notes are listed. The given <name> may itself be
+a note object, in which case it is listed along with its associated
+notes (if any).
+
+`-d <name>...` deletes the notes associated with the given <name>s.
+The given <name> may itself be a note object, in which case it is
+deleted along with its associated notes (if any).
+
+
+OPTIONS
+-------
+-d <name>...::
+ Delete existing notes associated with the given name(s).
+
+-l [<name>...]::
+ List notes associated with the given name(s). List all notes id no
+ name is given.
+
+-m <msg>::
+ Use the given note message (instead of prompting)
+
+-F <file>::
+ Take the note message from the given file (instead of prompting).
+ Use '-' to read the message from the standard input.
+
+
+DISCUSSION
+----------
+A git note provides an after-the-fact text annotation associated with an
+exiting object in the git object database. The note itself is also stored
+in the database (as a special case of a tag object). Note object are therefore
+-- as all other objects in the database -- immutable, i.e. once added they
+cannot be edited, although they can be deleted.
+
+As with regular tag objects, notes are useless unless they have a
+corresponding reference stored in `.git/refs`. For notes, these references
+are stored in a hierarchy under `.git/refs/notes`. For each object that has
+one or more associated notes, there is a subdirectory under
+`.git/refs/notes` named after the object identifier (SHA1 sum). The
+object's subdirectory contains one file per note associated with that object.
+The end result is that notes are easily accessible from the name/identifier
+of the object they are associated with.
+
+Note that deleting a note with `git-note -d` only deletes the reference to
+the note. The note itself is still present in the object database, but will
+be considered unreachable by gitlink:git-fsck[1], and may be removed with
+gitlink:git-prune[1].
+
+
+USE CASE
+--------
+Notes may be used to add any kind of extra information to existing git
+objects that may not become apparent until 'after' the original object is
+created. A common use case is to add -- for example -- information on bugs
+to existing commit objects. E.g. making notes like "This commit closes
+bug #123", or "This commit opens bug #456". These messages may then be
+parsed by custom tools that interoperate with a bug tracker, etc.
+
+
+Author
+------
+Written by Johan Herland <johan@herland.net>.
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
--
1.5.2.101.gee49f
^ permalink raw reply related
* [PATCH 01/15] git-note: Add git-note command for adding/listing/deleting git notes
From: Johan Herland @ 2007-05-27 14:09 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano
In-Reply-To: <200705271608.02122.johan@herland.net>
Synopsis:
'git-note' [-m <msg> | -F <file>] [<head>]
'git-note' -l [<name>...]
'git-note' -d <name>...
'git-note' without any parameters creates 'note' associated with HEAD.
Specifying an object name/ref to 'git-note' will cause the note to
be associated with that object instead.
`git-note -l [<name>...]` lists notes associated with the given <name>s.
If no <name> is given, all notes are listed. The given <name> may itself
be a note object, in which case it is listed along with its associated
notes (if any).
`git-note -d <name>...` deletes the notes associated with the given
<name>s. The given <name> may itself be a note object, in which case it is
deleted along with its associated notes (if any).
git-note.sh is partly based on git-tag.sh
Signed-off-by: Johan Herland <johan@herland.net>
---
git-note.sh | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 227 insertions(+), 0 deletions(-)
create mode 100755 git-note.sh
diff --git a/git-note.sh b/git-note.sh
new file mode 100755
index 0000000..4f539e2
--- /dev/null
+++ b/git-note.sh
@@ -0,0 +1,227 @@
+#!/bin/sh
+
+USAGE='-l [<name>...] | -d <name>... | [-m <msg> | -F <file>] [<head>]'
+LONG_USAGE='Add, delete and show git object notes
+ -l list/show notes associated with the given object.
+ -d delete the notes associated with the given object.
+ -m use the given note message (instead of prompting).
+ -F Take the note message from the given file (instead of prompting).
+For -l and -d, the given <name> may be a note object itself, in which case
+it will be included in the listing/deletion.
+When <head> is not given, it defaults to HEAD.'
+SUBDIRECTORY_OK='Yes'
+. git-sh-setup
+
+
+# Show the note identified by $1
+show_note () {
+ authordate=$(git-cat-file -p $1 | grep -m1 '^tagger ' | cut -c8-)
+ echo
+ echo "--- by $authordate"
+ git-cat-file -p $1 | tail -n+6
+ return 0
+}
+
+# Show notes below the refs/notes directory given in $1
+show_notes_below_dir () {
+ prev_object=
+ for note_data in $(git-for-each-ref --shell \
+ --sort=-taggerdate --sort=*authordate \
+ --format='note=%(objectname);object=%(*objectname);object_type=%(*objecttype);object_tag=%(*tag);' \
+ $1)
+ do
+ eval "$note_data"
+
+ # Separate note objects from regular tags
+ if test "$object_type" = "tag" -a -n "$(echo "$object_tag" | grep '^note-')"; then
+ object_type="note"
+ object_tag=""
+ fi
+
+ description=
+ # Create description based on object type
+ case "$object_type" in
+ commit)
+ description="$(git-show --pretty='format:%h (%s) by %an <%ae> on %aD' $object | head -n1)"
+ ;;
+ tag)
+ description="$object ($object_tag)"
+ ;;
+ *)
+ description="$object"
+ ;;
+ esac
+
+ if test "$object" != "$prev_object"; then
+ test -z "$prev_object" || echo
+ echo "=== Notes on $object_type $description"
+ fi
+ show_note $note
+ prev_object="$object"
+ done
+ return 0
+}
+
+# Show the notes associated with the objects in $@
+show_associated_notes () {
+ if test "$#" = "0"; then
+ show_notes_below_dir "refs/notes"
+ return 0
+ fi
+
+ while case "$#" in 0) break ;; esac
+ do
+ obj=$(git-rev-parse --verify "$1") || \
+ die "error: failed to find object named '$1'"
+
+ # If $obj is a note itself, handle it first
+ if test "$(git-cat-file -t $obj)" = "tag"; then
+ if test -n "$(git-cat-file -p $obj | grep '^tag note-')"; then
+ echo
+ echo "=== Note $obj"
+ show_note "$obj"
+ fi
+ fi
+
+ # List all notes associated with $obj.
+ show_notes_below_dir "refs/notes/$obj"
+
+ shift
+ done
+ return 0
+}
+
+# Delete the noteref in $1 pointing to the note identified by the SHA1 in $2
+delete_note () {
+ git-update-ref -m "note: delete" -d "$1" "$2"
+ return 0
+}
+
+# Delete all notes associated with object in $1
+delete_object_notes () {
+ for note_data in $(git-for-each-ref --shell \
+ --sort=taggerdate --sort=*authordate \
+ --format='note=%(objectname);object=%(*objectname);object_type=%(*objecttype);noteref=%(refname)' \
+ refs/notes/$1)
+ do
+ eval "$note_data"
+ echo "Deleting note $note associated with $object_type $object"
+ delete_note "$noteref" "$note"
+ done
+
+ # Try to get rid of $object's directory below refs/notes as well
+ if test -d "$GIT_DIR/refs/notes/$1"; then
+ rmdir "$GIT_DIR/refs/notes/$1"
+ fi
+ return 0
+}
+
+# Delete the notes associated with the objects in $@
+delete_associated_notes () {
+ while case "$#" in 0) break ;; esac
+ do
+ obj=$(git-rev-parse --verify "$1") || \
+ die "error: failed to find object named '$1'"
+
+ # If $obj is a note itself, handle it first
+ if test "$(git-cat-file -t $obj)" = "tag"; then
+ objref="$(git-cat-file -p $obj | grep -m1 '^object ' | cut -c8-)"
+ if test -n "$objref"; then
+ echo "Deleting note $obj"
+ delete_note "refs/notes/$objref/$obj" "$obj"
+ fi
+ fi
+
+ # Delete all notes associated with $obj
+ delete_object_notes "$obj"
+
+ shift
+ done
+ return 0
+}
+
+message_given=
+message=
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ -l)
+ shift
+ show_associated_notes "$@"
+ exit $?
+ ;;
+ -d)
+ shift
+ if test "$#" = "0"; then
+ die "error: option -d needs one or more objects"
+ fi
+ delete_associated_notes "$@"
+ exit $?
+ ;;
+ -m)
+ shift
+ message="$1"
+ if test "$#" = "0"; then
+ die "error: option -m needs an argument"
+ else
+ message_given=1
+ fi
+ ;;
+ -F)
+ shift
+ if test "$#" = "0"; then
+ die "error: option -F needs an argument"
+ else
+ message="$(cat "$1")"
+ message_given=1
+ fi
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+done
+
+object=$(git-rev-parse --verify --default HEAD "$@") || exit 1
+type=$(git-cat-file -t $object) || exit 1
+tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
+
+# Process note message
+trap 'rm -f "$GIT_DIR"/NOTE_TMP* "$GIT_DIR"/NOTE_FINALMSG "$GIT_DIR"/NOTE_EDITMSG' 0
+
+if test -z "$message_given"; then
+ ( echo ""
+ echo "#"
+ echo "# Write a note on $type $object"
+ echo "#" ) > "$GIT_DIR/NOTE_EDITMSG"
+ ${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/NOTE_EDITMSG" || exit
+else
+ printf '%s\n' "$message" >"$GIT_DIR/NOTE_EDITMSG"
+fi
+
+grep -v '^#' <"$GIT_DIR/NOTE_EDITMSG" |
+git-stripspace >"$GIT_DIR/NOTE_FINALMSG"
+
+test -s "$GIT_DIR/NOTE_FINALMSG" -o -n "$message_given" || {
+ echo >&2 "No note?"
+ exit 1
+}
+
+name="note-`( printf 'object %s\ntagger %s\n\n' "$tagger"; \
+ cat "$GIT_DIR/NOTE_FINALMSG" ) \
+ | sha1sum | cut -d" " -f1`"
+
+git-check-ref-format "notes/$object/$name" ||
+ die "Failed to create a valid note name. (internal git-note error)"
+
+( printf 'object %s\ntype %s\ntag %s\ntagger %s\n\n' \
+ "$object" "$type" "$name" "$tagger";
+ cat "$GIT_DIR/NOTE_FINALMSG" ) >"$GIT_DIR/NOTE_TMP"
+rm -f "$GIT_DIR/NOTE_FINALMSG"
+note=$(git-mktag < "$GIT_DIR/NOTE_TMP")
+
+git-update-ref "refs/notes/$object/$note" "$note"
--
1.5.2.101.gee49f
^ permalink raw reply related
* [PATCH 00/15] git-note: A mechanisim for providing free-form after-the-fact annotations on commits
From: Johan Herland @ 2007-05-27 14:08 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano
In-Reply-To: <alpine.LFD.0.98.0705101116480.3986@woody.linux-foundation.org>
On Thursday 10 May 2007, Linus Torvalds wrote:
> On Thu, 10 May 2007, Johan Herland wrote:
> >
> > BTW, I'm wondering whether anybody has ever thought about allowing
> > after-the-fact annotations on commits. Kinda like free-form
> > continuations on the commit message. It would allow people to make
> > notes on previous commits that were either forgotten at commit-time, or
> > only became apparent after the commit was done.
>
> We kind of have some of that.
>
> Tag objects can be used that way, and the "grafts" file is a very special
> case.
>
> But if you want to do it on a larger scale, you'd need something that is
> really optimized for that. For example, git internally now has a notion of
> "decorating" arbitrary objects with arbitrary data, and if you just had an
> efficient file format to create such decorations (for blame or other
> special ops), the *code* is easy to write. It's how
>
> git log --decorate
>
> works right now (the "data" is just the tag names, but you could make it
> read other decorations, and the git data structures are very efficient,
> and allow different types of decorations to be used independently of
> each other).
I've been working on combining tag objects and --decorate into a useful
proof-of-concept that provides the after-the-fact commit annotations I
requested above, and here's the result:
<quote src="Documentation/git-note.txt">
A git note provides an after-the-fact text annotation associated with an
exiting object in the git object database. The note itself is also stored
in the database (as a special case of a tag object). Note object are therefore
-- as all other objects in the database -- immutable, i.e. once added they
cannot be edited, although they can be deleted.
As with regular tag objects, notes are useless unless they have a
corresponding reference stored in `.git/refs`. For notes, these references
are stored in a hierarchy under `.git/refs/notes`. For each object that has
one or more associated notes, there is a subdirectory under
`.git/refs/notes` named after the object identifier (SHA1 sum). The
object's subdirectory contains one file per note associated with that object.
The end result is that notes are easily accessible from the name/identifier
of the object they are associated with.
Note that deleting a note with `git-note -d` only deletes the reference to
the note. The note itself is still present in the object database, but will
be considered unreachable by gitlink:git-fsck[1], and may be removed with
gitlink:git-prune[1].
</quote>
Here are some more details from the design notes I based my work on:
- Notes must not run counter to the existing design (and design goals) of git
- A note is itself stored as a git tag object:
- "object" has SHA1 of this note's object (as with regular tag objects)
- "type" has type of this note's object (as with regular tag objects)
- "tag" is fundamentally unimportant to the note. However, in order
to provide a unique tag name (so as not to be confused with any
other tag object) this is automatically set to "note-{$sha1}",
where {$sha1} is the SHA1 sum of the "object" and "tagger" fields
and the note message. If uniqueness of tag names within tag objects
is not important, we may consider dropping this
- "tagger" has the note author and date (same as regular tag objects)
- The rest of the tag object contains the note message, similar in
form to a commit message
- External mapping of objects to associated notes is kept below .git/refs/notes:
- One file per note object (as with tag refs in .git/refs/tags)
- Located at .git/refs/notes/{$object-sha1}/{$note-sha1}
- File contains SHA1 of the note object (same as refs in .git/refs/tags)
- Yes, this means that the filename (minus directory part) is identical
to the contents of the file
Some of the properties that result from the above decisions:
- A note is uniquely identified by its SHA1 sum (as are all other git objects)
- Notes are trivially packable
- The entire set of note refs can be fully recreated by trawling the object db
for tag objects with the tag name field matching the "note-{$sha1}" pattern
- Notes behave like regular tags under clone/push/fetch
- Notes are automatically checked by fsck (although some extra checking has
has been added)
- Little impact to existing git architecture
However, there are still some remaining questions:
- Is the creation of a unique tag name (i.e. the 'tag' field _inside_ the
object) for note objects really necessary? Which parts of the system rely
on these names to be unique across tag objects?
- Should notes have their own object type instead of piggy-backing on "tag"?
- What about having a note object type with minimal header fields, and make
tags just a special case of a note object with an extra tag name header?
- What about notes on notes? How are tags on tags treated? How should they be
treated?
- Currently noted objects (notees?) are treated as reachable from their
associated notes, i.e. like tags. This means that an otherwise dangling
object will not be detected and removed if it has associated notes.
This may not be what we want. If not, the following needs to be done:
- Notes should probably have their own object type at this point
- An object is no longer considered reachable from the associated notes
This mostly affects git-fsck and git-prune, which should now be able
to remove dangling objects with notes
Finally, here's the shortlog of the patches that will follow this email:
Johan Herland (15):
git-note: Add git-note command for adding/listing/deleting git notes
git-note: (Documentation) Add git-note manual page
git-note: (Administrivia) Add git-note to Makefile, .gitignore, etc.
git-note: (Plumbing) Add plumbing-level support for git notes
git-note: (Plumbing) Add support for git notes to git-rev-parse and git-show-ref
git-note: (Documentation) Explain the new '--notes' option to git-rev-parse and git-show-ref
git-note: (Almost plumbing) Add support for git notes to git-pack-refs and git-fsck
git-note: (Decorations) Add note decorations to "git-{log,show,whatchanged} --decorate"
git-note: (Documentation) Explain new behaviour of --decorate in git-{log,show,whatchanged}
git-note: (Transfer) Teach git-clone how to clone notes
git-note: (Transfer) Teach git-fetch to auto-follow notes
git-note: (Transfer) Teach git-push to push notes when --all or --notes is given
git-note: (Documentation) Explain the new --notes option to git-push
git-note: (Tests) Add tests for git-note and associated functionality
git-note: Add display of notes to gitk
.gitignore | 3 +-
Documentation/cmd-list.perl | 5 +-
Documentation/git-log.txt | 3 +-
Documentation/git-note.txt | 95 ++++++++++++
Documentation/git-push.txt | 7 +-
Documentation/git-rev-parse.txt | 5 +-
Documentation/git-show-ref.txt | 14 +-
Documentation/git-show.txt | 4 +
Documentation/git-whatchanged.txt | 4 +
Makefile | 2 +-
builtin-fetch--tool.c | 11 ++
builtin-fsck.c | 61 ++++++++
builtin-log.c | 108 +++++++++++++-
builtin-pack-refs.c | 5 +-
builtin-push.c | 20 ++-
builtin-rev-parse.c | 5 +
builtin-show-ref.c | 16 ++-
commit.h | 7 +
generate-cmdlist.sh | 1 +
git-clone.sh | 5 +-
git-fetch.sh | 27 ++++
git-note.sh | 227 +++++++++++++++++++++++++++
git-parse-remote.sh | 4 +-
gitk | 38 +++++-
log-tree.c | 67 ++++++++-
refs.c | 20 +++
refs.h | 4 +
t/t3850-note.sh | 303 +++++++++++++++++++++++++++++++++++++
28 files changed, 1033 insertions(+), 38 deletions(-)
create mode 100644 Documentation/git-note.txt
create mode 100755 git-note.sh
create mode 100755 t/t3850-note.sh
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: MinGW port updated to 1.5.2
From: Aaron Gray @ 2007-05-27 13:38 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4659249D.8040106@xs4all.nl>
> Aaron Gray escreveu:
>>> Aaron Gray escreveu:
>>>>> Aaron Gray escreveu:
>>>>>>>> GIT_EXTERNAL_DIFF works now.
>>>>>>>
>>>>>>> http://lilypond.org/git/binaries/mingw/
>>>>>>>
>>>>>>> uploading as I speak. Untested.
>>>>>>
>>>>>> This installs to "C:\Program Files\Git" and is not availiable on the
>>>>>> path. What is going on here please ?
>>>>>
>>>>> this uses the same buildscripts as before, so if it worked, it should
>>>>> still work. The path should point to $PF/Git/usr/bin/ ; you might
>>>>> need to
>>>>> log out and log in again for the path to visible.
>>>>
>>>> Still not working properly.
>>>>
>>>> From CMD.EXE, neither 'git clone' and 'git-clone' are accessable.
>
>>> - what is the value of the PATH variable in CMD ?
>>
>> Path=C:\Program
>> Files\GreenBorder\;C:\windows\system32;C:\windows;C:\windows\Sys
>> tem32\Wbem;C:\Program Files\ATI Technologies\ATI Control
>> Panel;c:\Program Files\
>> Microsoft SQL Server\90\Tools\binn\;C:\GnuWin32\bin;C:\Program
>> Files\QuickTime\Q
>> TSystem\;C:\Utils;C:\Program
>> Files\MakeMsi\;c:\MinGW\bin;C:\MinGW\usr\bin;C:\Pro
>> gram Files\Git\usr\bin;C:\Program Files\Git\usr\bin
>
> Can you troubleshoot this for me? As you can see, you have
>
> C:\Program Files\Git\usr\bin
>
> in the path. That AFAIK should be enough to have git.exe run
> inside CMD. Maybe I'm missing something, but that is as far as my
> windows knowledge goes.
Git runs, 'git init' runs, but 'git clone' or 'git-clone' do not.
'git init' reports it cannot find '/usr/share/git-core/templates/'
I have no idea whats wrong and do not have the time to try to debug it at
present.
Aaron
^ permalink raw reply
* [PATCH] cvsserver: Fix some typos in asciidoc documentation
From: Frank Lichtenheld @ 2007-05-27 12:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <1180269190126-git-send-email-frank@lichtenheld.de>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-cvsserver.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index ca7579d..e5005f0 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -86,7 +86,7 @@ write access to the log file and to the database (see
SSH, the users of course also need write access to the git repository itself.
[[configaccessmethod]]
-All configuration variables can also be overriden for a specific method of
+All configuration variables can also be overridden for a specific method of
access. Valid method names are "ext" (for SSH access) and "pserver". The
following example configuration would disable pserver access while still
allowing access over SSH.
@@ -128,7 +128,7 @@ Database Backend
git-cvsserver uses one database per git head (i.e. CVS module) to
store information about the repository for faster access. The
-database doesn't contain any persitent data and can be completly
+database doesn't contain any persistent data and can be completely
regenerated from the git repository at any time. The database
needs to be updated (i.e. written to) after every commit.
--
1.5.2-rc3.GIT
^ permalink raw reply related
* [PATCH] cvsserver: Correct inetd.conf example in asciidoc documentation
From: Frank Lichtenheld @ 2007-05-27 12:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <1180269190126-git-send-email-frank@lichtenheld.de>
While the given example worked, it made us look rather
incompetent. Give the correct reason why one needs the
more complex syntax and change the example to reflect
that.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-cvsserver.txt | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index d22844b..9f0d990 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -46,11 +46,13 @@ INSTALLATION
cvspserver stream tcp nowait nobody git-cvsserver pserver
------
-Note: In some cases, you need to pass the 'pserver' argument twice for
-git-cvsserver to see it. So the line would look like
+Note: Some inetd servers let you specify the name of the executable
+independently of the value of argv[0] (i.e. the name the program assumes
+it was executed with). In this case the correct line in /etc/inetd.conf
+looks like
------
- cvspserver stream tcp nowait nobody git-cvsserver pserver pserver
+ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
------
No special setup is needed for SSH access, other than having GIT tools
--
1.5.2-rc3.GIT
^ permalink raw reply related
* Various git-cvsserver patches
From: Frank Lichtenheld @ 2007-05-27 12:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Frank Lichtenheld (5):
cvsserver: Correct inetd.conf example in asciidoc documentation
cvsserver: Note that CVS_SERVER can also be specified as method variable
cvsserver: Fix some typos in asciidoc documentation
t9400: Work around CVS' deficiencies
cvsserver: Handle 'cvs login'
Documentation/git-cvsserver.txt | 27 ++++++++++++++++++---------
git-cvsserver.perl | 8 +++++---
t/t9400-git-cvsserver-server.sh | 33 +++++++++++++++++++++++++++++++--
3 files changed, 54 insertions(+), 14 deletions(-)
The first three patches are some fixes/improvements to the asciidoc
documentation. Just some random stuff that I noticed while working
on git-cvsserver.
The forth one is a good example how much CVS actually sucks
regarding data security and deterministic behaviour.
All of these should be suitable for maint.
The fifth is a small feature enhancement for git-cvsserver. It
adds support for 'cvs login' over pserver.
I think this is trivial enough to go to master directly, but feel free
to let it rot in next first.
^ permalink raw reply
* [PATCH] t9400: Work around CVS' deficiencies
From: Frank Lichtenheld @ 2007-05-27 12:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <1180269190126-git-send-email-frank@lichtenheld.de>
If we are too fast with our changes, the file in
the working copy might still have the same mtime
as noted in the CVS/Entries. This will cause CVS
to happily report to the server that the file is
unmodified which can lead to data loss (and in
our case test failure).
CVS sucks!
Work around that by sleeping for a second.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t9400-git-cvsserver-server.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 7f9c6e2..76a9b1a 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -250,6 +250,7 @@ test_expect_success 'cvs update (merge)' \
git commit -q -m "Merge test (merge)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
+ sleep 1 && touch merge &&
GIT_CONFIG="$git_config" cvs -Q update &&
diff -q merge ../expected'
@@ -292,6 +293,7 @@ test_expect_success 'cvs update (merge no-op)' \
git commit -q -m "Merge test (no-op)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
+ sleep 1 && touch merge &&
GIT_CONFIG="$git_config" cvs -Q update &&
diff -q merge ../merge'
--
1.5.2-rc3.GIT
^ permalink raw reply related
* [PATCH] cvsserver: Note that CVS_SERVER can also be specified as method variable
From: Frank Lichtenheld @ 2007-05-27 12:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <1180269190126-git-send-email-frank@lichtenheld.de>
Reasonably new versions of the cvs CLI client allow one to
specifiy CVS_SERVER as a method variable directly in
CVSROOT. This is way more convinient than using an
environment variable since it gets saved in CVS/Root.
Since I only discovered this by accident I guess there
might be others out there that learnt CVS on the 1.11
series (or even earlier) and profit from such a note
about cvs improvements in the last couple years.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-cvsserver.txt | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 9f0d990..ca7579d 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -57,7 +57,17 @@ looks like
------
No special setup is needed for SSH access, other than having GIT tools
in the PATH. If you have clients that do not accept the CVS_SERVER
-env variable, you can rename git-cvsserver to cvs.
+environment variable, you can rename git-cvsserver to cvs.
+
+Note: Newer cvs versions (>= 1.12.11) also support specifying
+CVS_SERVER directly in CVSROOT like
+
+------
+cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
+------
+This has the advantage that it will be saved in your 'CVS/Root' files and
+you don't need to worry about always setting the correct environment
+variable.
--
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
--
1.5.2-rc3.GIT
^ permalink raw reply related
* [PATCH] cvsserver: Handle 'cvs login'
From: Frank Lichtenheld @ 2007-05-27 12:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <1180269190126-git-send-email-frank@lichtenheld.de>
Since this is a trivial variation of the general pserver
authentication, there is really no reason not to support
it.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 8 +++++---
t/t9400-git-cvsserver-server.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 1de5177..2b4825a 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -95,9 +95,10 @@ $state->{method} = 'ext';
if (@ARGV && $ARGV[0] eq 'pserver') {
$state->{method} = 'pserver';
my $line = <STDIN>; chomp $line;
- unless( $line eq 'BEGIN AUTH REQUEST') {
+ unless( $line =~ /^BEGIN (AUTH|VERIFICATION) REQUEST$/) {
die "E Do not understand $line - expecting BEGIN AUTH REQUEST\n";
}
+ my $request = $1;
$line = <STDIN>; chomp $line;
req_Root('root', $line) # reuse Root
or die "E Invalid root $line \n";
@@ -109,10 +110,11 @@ if (@ARGV && $ARGV[0] eq 'pserver') {
}
$line = <STDIN>; chomp $line; # validate the password?
$line = <STDIN>; chomp $line;
- unless ($line eq 'END AUTH REQUEST') {
- die "E Do not understand $line -- expecting END AUTH REQUEST\n";
+ unless ($line eq "END $request REQUEST") {
+ die "E Do not understand $line -- expecting END $request REQUEST\n";
}
print "I LOVE YOU\n";
+ exit if $request eq 'VERIFICATION'; # cvs login
# and now back to our regular programme...
}
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 76a9b1a..e9ef315 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -67,6 +67,22 @@ git
END AUTH REQUEST
EOF
+cat >login-anonymous <<EOF
+BEGIN VERIFICATION REQUEST
+$SERVERDIR
+anonymous
+
+END VERIFICATION REQUEST
+EOF
+
+cat >login-git <<EOF
+BEGIN VERIFICATION REQUEST
+$SERVERDIR
+git
+
+END VERIFICATION REQUEST
+EOF
+
test_expect_success 'pserver authentication' \
'cat request-anonymous | git-cvsserver pserver >log 2>&1 &&
tail -n1 log | grep -q "^I LOVE YOU$"'
@@ -80,6 +96,19 @@ test_expect_success 'pserver authentication failure (non-anonymous user)' \
fi &&
tail -n1 log | grep -q "^I HATE YOU$"'
+test_expect_success 'pserver authentication (login)' \
+ 'cat login-anonymous | git-cvsserver pserver >log 2>&1 &&
+ tail -n1 log | grep -q "^I LOVE YOU$"'
+
+test_expect_success 'pserver authentication failure (login/non-anonymous user)' \
+ 'if cat login-git | git-cvsserver pserver >log 2>&1
+ then
+ false
+ else
+ true
+ fi &&
+ tail -n1 log | grep -q "^I HATE YOU$"'
+
#--------------
# CONFIG TESTS
--
1.5.2-rc3.GIT
^ permalink raw reply related
* Re: [PATCH] Fix git-svn to handle svn not reporting the md5sum of a file, and test.
From: A Large Angry SCM @ 2007-05-27 11:49 UTC (permalink / raw)
To: James Y Knight; +Cc: git, normalperson, Junio C Hamano
In-Reply-To: <1179981426176-git-send-email-foom@fuhm.net>
James Y Knight wrote:
> ---
> git-svn.perl | 2 +-
> t/t9112-git-svn-md5less-file.sh | 45 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 46 insertions(+), 1 deletions(-)
> create mode 100755 t/t9112-git-svn-md5less-file.sh
[...]
The new test fails here (Suse 9.3 fully patched) w/ the following:
*** t9112-git-svn-md5less-file.sh ***
* ok 1: load svn dumpfile
* ok 2: initialize git-svn
* FAIL 3: fetch revisions from svn
git-svn fetch
* failed 1 among 3 test(s)
make[1]: *** [t9112-git-svn-md5less-file.sh] Error 1
^ permalink raw reply
* [PATCH] Add test case for $Id$ expanded in the repository
From: Andy Parkins @ 2007-05-27 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <200705271150.50147.andyparkins@gmail.com>
This test case would have caught the bug fixed by revision
c23290d5.
It puts various forms of $Id$ into a file in the repository,
without allowing git to collapse them to uniformity. Then enables the
$Id$ expansion on checkout, and checks that what is checked out has
coped with the various forms.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
t/t0021-conversion.sh | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index 6c26fd8..a839f4e 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -45,4 +45,40 @@ test_expect_success check '
test "z$id" = "z$embedded"
'
+# If an expanded ident ever gets into the repository, we want to make sure that
+# it is collapsed before being expanded again on checkout
+test_expect_success expanded_in_repo '
+ {
+ echo "File with expanded keywords"
+ echo "\$Id\$"
+ echo "\$Id:\$"
+ echo "\$Id: 0000000000000000000000000000000000000000 \$"
+ echo "\$Id: NoSpaceAtEnd\$"
+ echo "\$Id:NoSpaceAtFront \$"
+ echo "\$Id:NoSpaceAtEitherEnd\$"
+ echo "\$Id: NoTerminatingSymbol"
+ } > expanded-keywords &&
+
+ {
+ echo "File with expanded keywords"
+ echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
+ echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
+ echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
+ echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
+ echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
+ echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
+ echo "\$Id: NoTerminatingSymbol"
+ } > expected-output &&
+
+ git add expanded-keywords &&
+ git commit -m "File with keywords expanded" &&
+
+ echo "expanded-keywords ident" >> .gitattributes &&
+
+ rm -f expanded-keywords &&
+ git checkout -- expanded-keywords &&
+ cat expanded-keywords &&
+ cmp expanded-keywords expected-output
+'
+
test_done
--
1.5.2.86.g99b5-dirty
^ permalink raw reply related
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-27 10:52 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Johannes Sixt, git
In-Reply-To: <46592B92.9060403@xs4all.nl>
Hi,
On Sun, 27 May 2007, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
>
> > I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.)
> > Worked out of the box:
> >
> > http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz
> > http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz
> >
>
> GCC barfs on:
>
> ((Tcl_Obj **) objv) += (async + 3);
Ah yes, I was using MinGW's own GCC, which is GCC 3.something.
It is a new "feature" of GCC 4.x to disallow constructs like these.
(Probably because GCC people think that other people are not intelligent
enough to understand such constructs, and therefore prohibit their use.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix mishandling of $Id$ expanded in the repository copy in convert.c
From: Andy Parkins @ 2007-05-27 10:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vveefiex4.fsf@assigned-by-dhcp.cox.net>
On Saturday 2007, May 26, Junio C Hamano wrote:
> Wouldn't it be sufficient to:
>
> (1) prepare a file with "$Id$", use ident in .gitattributes,
> check it in and commit;
>
> (2) remove it from the working tree, check it out with
> "checkout -f";
>
> (3) temorarily move away .gitattributes, modify the file, and
> check it in;
>
> (4) move .gitattributes back into its place, and commit.
I'm glad to have you confirm that. I wasn't sure if git would do
something clever and reading the .gitattributes from the same commit as
the file for which is being checked out.
If the above would work, then even simpler:
(1) Commit a file with $Id: blah blah blah $ in it.
(2) Add a .gitattributes with ident
(3) Check out.
Patch to follow.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-27 10:46 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Jakub Narebski, git
In-Reply-To: <4659259D.4000803@xs4all.nl>
Hi,
On Sun, 27 May 2007, Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>
> >> Instead, we have a Makefile that relies on an esoteric combination of
> >> perl and shell scripting inside Makefiles.
> >
> > The idea is to be able to get reasonable defaults (depending on system
> > of
>
> This saves the user on Linux or similar platform one ./configure call.
It works on Linux, Cygwin, MinGW, last time I checked MacOSX, IRIX, and I
imagine Solaris, AIX and even other platforms, out of the box.
> For the rest it means editing makefiles. I'm not sure if that is an
> improvement over the standard
>
> configure ; make ; make install
ATM you have to do autoconf before that. But that should work, really.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] Lazily open pack index files on demand
From: Martin Koegler @ 2007-05-27 10:46 UTC (permalink / raw)
To: Dana How; +Cc: Shawn O. Pearce, Junio C Hamano, git
Dana How wrote:
> (1c) Do not deltify naughty blobs. Naughty blobs are those
> blobs marked "nodelta" or very large blobs.
I don't like the idea to exclude any blobs from delta by default, if
the delta could be done. If the "very large blobs" are text files with
very few difference, they deltifiy very well.
Additionlly, how do you want to define "very large blobs"?
For a system with eg. 256MB of RAM, deltifiny a blob with some hundred
MBs is a problem whereas it is no problem, if you have some GB of RAM.
mfg Martin Kögler
^ permalink raw reply
* svn-cp equivalent for history on a single file from a git-svn user.
From: Robin H. Johnson @ 2007-05-27 10:14 UTC (permalink / raw)
To: Git Mailing List; +Cc: jokey
[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]
Not a problem I ran into directly, but fellow Gentoo developer did
(CC'd), and I couldn't find a reasonable answer as the person that they
were asking hard Git questions of (I _think_ I saw it somewhere on the
web before, but I can't find it atm).
I'm personally a CVS and then Git guy, with SVN usage as a distant
relative. I wouldn't personally host a project in SVN [and I find
git-svn to be a miracle-worker in helping me out].
Some rough problem background:
- They have a SVN repo, with a few areas under trunk. Relevant to us are
'submitted' and 'reviewed'. Under each, the unique content is in
directories that are treated as single units.
- It is normal to have both portions checked out at once.
- There are users that can put stuff into the 'submitted' portion.
- There are a subset of users that can commit stuff to 'reviewed'.
- The reviewer subset of users is orthogonal to the people that can
commit to 'reviewed'.
- $Header$ expansion is disabled in the SVN repo.
- Git v1.5.1.4
Problem:
The Git docs say to use plain 'cp' where svn-cp would be used, as Git
detects copies after-the-fact. However, doing so in Git does not appear
to sanely preserve the history in Git, or when the files are committed
back to the SVN tree (git-svn dcommit).
Here's an example of their process done purely with SVN.
('submitted' = sunrise).
http://overlays.gentoo.org/proj/sunrise/changeset/3687
Specifically of interest are the portions that have '(copied from
$OLDPATH)'
'svn log' produces this output:
http://rafb.net/p/bETJkV31.html
The bottom two entries are relevant to the file in it's location inside
the 'submitted' tree, and were copied to the history in the 'reviewed'
tree.
Here's the same thing, done with plain cp per the Git documentation.
The files that previously showed 'copied from ...' just show up as new,
and their history has remained separate.
http://overlays.gentoo.org/proj/sunrise/changeset/3687
If one looks at the SVN log between the two styles on a file that is
newly added, the SVN case includes the history of the file in the old
location, whereas Git does not. Git only has the commit that introduced
it at it's present location.
'svn-cp' revision list:
http://overlays.gentoo.org/proj/sunrise/log/reviewed/app-admin/blockhosts/blockhosts-2.0.3.ebuild?rev=3687
'git using plain cp' revision list:
http://overlays.gentoo.org/proj/sunrise/log/reviewed/dev-libs/dswifi/dswifi-0.3.1.ebuild?rev=3749
Git SHOULD have included this history:
http://overlays.gentoo.org/proj/sunrise/log/sunrise/dev-libs/dswifi/dswifi-0.3.1.ebuild?rev=3749
While researching this for the other guy, I notice a related defect in
SVN's svn-cp implementation, but pertaining to existing files.
- The actions of 'svn-cp' that create a new file copy the existing
history.
- The actions of 'svn-cp' that do NOT create a new file only applies the
changes as a single commit, without copying any history.
Thinking about the problem from the perspective of what it's supposed to
do, I think the correct action in BOTH cases would be to take the
portions of both commits that lead to the present state of the file in
'submitted', and tell Git that they are relevant to the history of the
file in 'reviewed'. As to how best to go about this, I'm not certain.
--
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Jim Meyering @ 2007-05-27 9:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0705260910220.26602@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, 26 May 2007, Jim Meyering wrote:
>>
>> Each git command should report such a failure.
>> Some already do, but with the patch below, they all do, and we
>> won't have to rely on code in each command's implementation to
>> perform the right incantation.
>
> The patch is wrong.
What you should have said is that the patch is fine in principle, since
it does fix a pretty serious bug (important tools ignoring ENOSPC),
but you'd prefer that it continue to ignore EPIPE.
With a name like yours, being more positive would go a long way toward
encouraging (or rather *not discouraging*) contributions.
> Some write errors are expected and GOOD.
>
> For example, EPIPE should not be reported. It's normal. The user got
> bored. It might be hidden by the SIGPIPE killing us, but regardless,
> reporting it for the normal log/diff thing is just not correct. EPIPE
> isn't an error, it's a "ok, nobody is listening any more".
I have to disagree. There may be precedent for hiding EPIPE errors,
but that is not the norm among command line tools wrt piped stdout.
First of all, one has to work just to get such an error. These days,
most people use a shell that doesn't ignore, handle or block SIGPIPE, so
direct use of a program like git-log or git-diff gets the signal directly,
and there's no EPIPE error. E.g., try "cat", and you see it gets SIGPIPE
(141=128+SIGPIPE(13)):
$ seq 90000|(cat; echo $? >&2) | head -1 > /dev/null
141
However, you can tweak your shell to handle/ignore SIGPIPE. Also,
some porcelain scripts do ignore SIGPIPE. Then, a program run in that
environment does see EPIPE. Consider how a few other non-interactive
programs work when one of their stdout-writing syscalls fails with EPIPE:
Try GNU diff and sed:
[now, using shorter ":" in place of more realistic head -1]
$ (trap '' PIPE; seq 90000|diff - /dev/null;echo $? >&2)| :
diff: standard output: Broken pipe
2
$ (trap '' PIPE; seq 90000|sed s/a/b/; echo $? 1>&2)| :
/bin/sed: couldn't write 5 items to stdout: Broken pipe
seq: write error: Broken pipe
4
Try tee (from GNU coreutils):
$ (trap '' PIPE; seq 90000|tee /dev/null; echo $? >&2) | :
tee: standard output: Broken pipe
tee: write error
1
sort, tac, cut, fold, od, head, tail, tr, uniq, etc. all work the same
way, if you're using the coreutils. But perhaps that's not fair, since
I maintain the coreutils. And there is some variance among how other-
vendor versions of those tools work. E.g., Solaris 10's /bin/cat
diagnoses the error, but neither /bin/sort nor /bin/diff do.
As for version control tools, monotone does what I'd expect in
this situation: "mtn diff" reports the failure and exits nonzero.
svn and cvs also report the error, although they both exit successfully
in spite of that. I tried both log and diff commands for each tool.
cvs catches the signal, svn doesn't.
mercurial and darcs totally ignore the write error and SIGPIPE,
so there is no way to determine from stderr or exit code whether
their writes complete normally.
For any tool whose output might be piped to another, the pipe-writing
tool should exit nonzero for any write error. Otherwise, its exit code
ends up being a lie, pretending success but, in effect, covering up for
a failure. In general, I've found that papering over syscall failures
makes higher-level problems harder to diagnose.
Do you really want git-log to continue to do this?
$ (trap '' PIPE; git-log; echo $? >&2 ) | :
0
With my patch, it does this:
$ (trap '' PIPE; ./git-log; echo $? >&2 ) | :
fatal: write failure on standard output: Broken pipe
128
> Also, PLEASE don't do this:
>
>> + if (0 <= fcntl(fileno (stdout), F_GETFD)
Since Junio is making an effort to "conform",
I too will make the effort when contributing to git.
^ permalink raw reply
* Re: GIT on MinGW problem
From: Steven Grimm @ 2007-05-27 7:21 UTC (permalink / raw)
To: hanwen; +Cc: git, Jakub Narebski
In-Reply-To: <46592CFE.40303@xs4all.nl>
Han-Wen Nienhuys wrote:
>> On systems like Cygwin the fork+exec overheads are very high
> A well written configure script is able to detect presence
> of a linkable libcurl.
>
IMO the reasons configure is so unwieldy, at least as it's set up in
most open source projects, are that a) it spends 95% of its time
checking for things that basically never vary (yes, I have stdlib.h,
thank you) and that b) it doesn't remember the results from previous
runs on the same host (I'm just changing the install path; my ints won't
have stopped being 32 bits as a result.) I wonder if we could satisfy
most people with a configure script -- maybe not based on autoconf --
that is limited in scope to just the things that are currently tweakable
in the git Makefile.
If configure ran only, say, 10-15 tests, I bet the fork+exec overhead on
Cygwin would be perfectly tolerable.
-Steve
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-27 7:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <20070527063902.GB28023@spearce.org>
Shawn O. Pearce escreveu:
>
> On systems like Cygwin the fork+exec overheads are very high;
> running a "simple" configure script can take longer than it
> takes me to compile Git from scratch. Editing config.mak is
> quite easy; so is passing your choices on the command line to
> `make install`.
>
> Personally I find:
>
> make NO_CURL=1 install
>
> easier than:
>
> ./configure --without-curl && make install
NO_CURL is a nonstandard option. Every package does it
differently, so this requires users to delve through either
INSTALL or Makefile.
A well written configure script is able to detect presence
of a linkable libcurl.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-27 6:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0705262311380.4648@racer.site>
Johannes Schindelin escreveu:
> I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.)
> Worked out of the box:
>
> http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz
> http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz
>
GCC barfs on:
((Tcl_Obj **) objv) += (async + 3);
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW problem
From: Shawn O. Pearce @ 2007-05-27 6:39 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Jakub Narebski, git
In-Reply-To: <4659259D.4000803@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> Jakub Narebski escreveu:
>
> >> Instead, we have a Makefile that relies on an esoteric combination of
> >> perl and shell scripting inside Makefiles.
> >
> > The idea is to be able to get reasonable defaults (depending on system of
>
> This saves the user on Linux or similar platform one ./configure call. For
> the rest it means editing makefiles. I'm not sure if that is an improvement
> over the standard
>
> configure ; make ; make install
[side note: can you please not send both To the list and CC the
list on the same message? Pick one, we're all getting two copies
of messages from you.]
On systems like Cygwin the fork+exec overheads are very high;
running a "simple" configure script can take longer than it
takes me to compile Git from scratch. Editing config.mak is
quite easy; so is passing your choices on the command line to
`make install`.
Personally I find:
make NO_CURL=1 install
easier than:
./configure --without-curl && make install
--
Shawn.
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-27 6:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f3agkk$bhn$1@sea.gmane.org>
Jakub Narebski escreveu:
>> Instead, we have a Makefile that relies on an esoteric combination of
>> perl and shell scripting inside Makefiles.
>
> The idea is to be able to get reasonable defaults (depending on system of
This saves the user on Linux or similar platform one ./configure call. For
the rest it means editing makefiles. I'm not sure if that is an improvement
over the standard
configure ; make ; make install
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: MinGW port updated to 1.5.2
From: Han-Wen Nienhuys @ 2007-05-27 6:26 UTC (permalink / raw)
To: Aaron Gray; +Cc: git
In-Reply-To: <004201c79fe7$f16b47b0$0200a8c0@AMD2500>
Aaron Gray escreveu:
>> Aaron Gray escreveu:
>>>> Aaron Gray escreveu:
>>>>>>> GIT_EXTERNAL_DIFF works now.
>>>>>>
>>>>>> http://lilypond.org/git/binaries/mingw/
>>>>>>
>>>>>> uploading as I speak. Untested.
>>>>>
>>>>> This installs to "C:\Program Files\Git" and is not availiable on the
>>>>> path. What is going on here please ?
>>>>
>>>> this uses the same buildscripts as before, so if it worked, it should
>>>> still work. The path should point to $PF/Git/usr/bin/ ; you might
>>>> need to
>>>> log out and log in again for the path to visible.
>>>
>>> Still not working properly.
>>>
>>> From CMD.EXE, neither 'git clone' and 'git-clone' are accessable.
>> - what is the value of the PATH variable in CMD ?
>
> Path=C:\Program
> Files\GreenBorder\;C:\windows\system32;C:\windows;C:\windows\Sys
> tem32\Wbem;C:\Program Files\ATI Technologies\ATI Control
> Panel;c:\Program Files\
> Microsoft SQL Server\90\Tools\binn\;C:\GnuWin32\bin;C:\Program
> Files\QuickTime\Q
> TSystem\;C:\Utils;C:\Program
> Files\MakeMsi\;c:\MinGW\bin;C:\MinGW\usr\bin;C:\Pro
> gram Files\Git\usr\bin;C:\Program Files\Git\usr\bin
Can you troubleshoot this for me? As you can see, you have
C:\Program Files\Git\usr\bin
in the path. That AFAIK should be enough to have git.exe run
inside CMD. Maybe I'm missing something, but that is as far as my
windows knowledge goes.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ 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