* Re: [PATCH] transplant: move a series of commits to a different parent
From: Johannes Schindelin @ 2007-06-23 20:54 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11826268772950-git-send-email-prohaska@zib.de>
Hi,
On Sat, 23 Jun 2007, Steffen Prohaska wrote:
> git-transplant.sh <onto> <from> <to>
>
> transplant starts with the contents of <onto> and puts on top of
> it the contents of files if they are touched by the series of
> commits <from>..<to>.
This reeks of rebase.
IOW, I suspect that it does almost the same as
git checkout <to>
git rebase -s ours --onto <onto> <from>^
Ciao,
Dscho
^ permalink raw reply
* Re: 100%
From: Johannes Schindelin @ 2007-06-23 20:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, David Kastrup, git
In-Reply-To: <7vk5tu4gas.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Sat, 23 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > By the same reasoning, you could say "never round down to 0%, because I
> > want to know when there is no similarity".
> >
> > You cannot be exact when you have to cut off fractions, so why try for
> > _exactly_ one number?
>
> R0 or C0 would not happen in real life, so 0% is a moot issue.
It is, but not when you look at the formula.
> However, wasn't that you who did follow that "certain numbers
> are special" logic in diffstat?
>
> You advocated "diff --stat" should draw at least one +/- for a
> patch that adds/removes lines. And I (and others) agreed
> because zero is special in the context of that application.
Actually, it was not me, but I implemented the version that we have now.
I was reasonably scared that a non-linear diffstat would end up in git,
therefore I wrote a linear one.
The important thing to not here is that the diffstat as-is makes _better_
use of the limited scale that is available.
And as you pointed out, the low end of the scale is not really
interesting. The interesting parts are those around 100%. By rounding down
you make less use of the available scale.
> I think reserving R100 to mean "identical byte sequences" has value,
> when people look at --name-status output, in the context of "similarity
> index".
Ah, whatever. You do what you want.
Yes, this interpretation has value. No, it is not the only one that has
value. I am much more used to rounding, since at the end of the day it
makes better use of the scale, it is commonly used, and therefore _I_
expect it (and no, I will not read the documentation when I expect to know
what it means).
But hey, I don't care any more. AFAIAC you can change it from rounding to
rounding down, and next year to rounding-up. We could even have an
algorithm which rounds down only in odd years, and I still would not care.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH][RESEND] git-submodule: provide easy way of adding new submodules
From: Junio C Hamano @ 2007-06-23 20:15 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, git, Junio C Hamano
In-Reply-To: <8c5c35580706231226lc887320ubce71d90dda8e9d3@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 6/21/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
>> I didn't get any reaction (negative or positive) to this patch.
>
> Sorry for the late reply, I've been buried in day-job stuff lately
> (and still is).
>
> The patch looks sane to me. I'll try to play around with it tomorrow
> and give some more feedback.
Thanks.
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: Junio C Hamano @ 2007-06-23 20:15 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: GIT
In-Reply-To: <20070623220215.6117@nanako3.bluebottle.com>
Nanako Shiraishi <nanako3@bluebottle.com> writes:
> I wrote this little script to save the changes I made, perform the update,
> and then come back to where I was, but on top of the updated commit.
>
> Here is how to use my script:
>
> $ git save
> $ git pull
> $ git save restore
Heh, I earlier said that I'd start looking at the "stash", but
haven't done anything about it so far (I was busy with the day
job). More honestly, I was being lazy, and sometimes lazy are
rewarded, with a contribution from a new git hacker.
I think this is more or less in the direction I was planning to
head to; thanks for the patch.
Having said that, I have a few comments. Style, robustness,
and portability.
> diff --git a/git-save.sh b/git-save.sh
> new file mode 100755
> index 0000000..b45652e
> --- /dev/null
> +++ b/git-save.sh
> @@ -0,0 +1,74 @@
> +#! /bin/sh
Style. "#!/bin/sh" (no space after she-bang).
> +
> +. git-sh-setup
> +require_work_tree
> +
> +function save_work () {
No noiseword "function" for portability.
When you say "#!/bin/sh", you are writing for the family of
generic Bourne shells, not specifically for korn nor bash. For
example, dash is a fine POSIX shell, but does not grok function
noiseword. When in doubt, please stay away from things not in
POSIX (e.g. function, [[, ]], ${parameter//pattern/string/}).
> + save=$( (
> + i_tree=$(git-write-tree)
> +
> + TMP=$GIT_DIR/.git-save-tmp
> + GIT_INDEX_FILE=$TMP
> + export GIT_INDEX_FILE
> +
> + git-read-tree $i_tree
> + git-add -u
> + w_tree=$(git-write-tree)
> + rm $TMP
> + git-read-tree --prefix=base/ HEAD^{tree}
> + git-read-tree --prefix=indx/ $i_tree
> + git-read-tree --prefix=work/ $w_tree
> + git-write-tree
> + rm $TMP
> + ) )
Hmph.
I see many problems here, although the basic idea is sound and
"interesting". I especially like the use of three trees in a
single commit, without any parenthood.
- $GIT_DIR could contain shell metachararcters / whitespace, so
could $TMP as well. Always quote such variables, or you risk
a surprise from "rm".
- You probably would not want to create a new "save" if your
working tree and the index are clean. To test for the
condition, you can do something like:
git-diff --quiet --cached && git-diff --quiet
- I generally prefer cleaning temporary files with "rm -f", and
also set a trap upon exit, like this:
# near the beginning of the script
TMP="$GIT_DIR/.git-save-tmp-$$"
trap 'rm -f "$TMP"' 0
... and then much later ...
save=$( (
GIT_INDEX_FILE=$TMP
export GIT_INDEX_FILE
...
) )
- I wonder what happens if any of the commands in the above
sequence errors out. For example, I think you will get a
failure from the first git-write-tree if you are in the
middle of a merge. You would want to error out as soon as
you see a problem.
- Although you keep a separate tree for the index (before the
"git add -u" to grab the working tree changes) in the saved
data, it does not seem to be used. It _might_ make sense to
replace "git add -u" with "git add ." so that work/ tree
contains even untracked (but not ignored) files, and on the
restore side unstage the paths that appear in work/ but not
in indx/. I dunno.
> +
> + head=$(git-log --abbrev-commit --pretty=oneline -n 1 HEAD)
> + if branch=$(git symbolic-ref -q HEAD); then
> + branch=${branch#refs/heads/}
> + else
> + branch='(no branch)'
> + fi &&
Minor style. Please don't write "; then\n". Line-up "then",
"elif", "else", and "fi"; it is much easier to read that way.
> + msg=$(printf 'WIP on %s "%s"' "$branch" "$head")
> +
> + saved=$(printf '%s' "$msg" | git-commit-tree "$save")
> + git update-ref -m "$msg" refs/heads/saved $saved
> + printf 'Saved %s\n' "$msg" >&2
> +}
> +
> +function list_save () {
> + git-log --abbrev-commit --pretty=oneline -g "$@" saved
> +}
I really like the way reflog is used for this. Your saves do
not necessarily tied to a single branch (so there are no
parent-child relation between each save entry), but you can
still identify what each of the save is about because your log
message has branch name in it.
The sha1 at the beginning of oneline output, although they are
abbreviated, seem not very useful in this context, by the way.
I presume your intended use case is to view "git save list"
output, and say "git save restore saved@{2}" to apply the one
third from the top. For that use, the commit object name is
irrelevant. Maybe sed it out like this to make it even
prettier?
git-log --pretty=oneline -g "$@" saved
sed -e 's/^[0-9a-f]* //'
> +function show_save () {
> + save=$(git rev-parse --verify --default saved "$1")
> + git diff-tree --stat $save:base $save:work
> +}
Nice, but after trying this myself a bit, I seriously wished for
"git save show -p", so I did it myself, like this:
show_save () {
flags=$(git rev-parse --no-revs --flags "$@")
if test -z "$flags"
then
flags=--stat
fi
save=$(git rev-parse --revs-only --no-flags --default saved "$@")
git diff-tree $flags $save:base $save:work
}
It's a dense (and ancient style) plumbing code so needs a bit of
explanation:
- The first git-rev-parse looks at "$@", discards everything
that are not options and discards object names. So 'git save
show -p some' will give you "-p" in flags.
- The second one discards flags, and grabs 'some' out of '-p
some', or defaults to "saved".
> +function restore_save () {
> + save=$(git rev-parse --verify --default saved "$1")
> + h_tree=$(git rev-parse --verify $save:base)
> + i_tree=$(git rev-parse --verify $save:indx)
> + w_tree=$(git rev-parse --verify $save:work)
> +
> + git-merge-recursive $h_tree -- HEAD^{tree} $w_tree
> +}
The same "robustness" comments for the save_work function apply
here. You probably do not want to restore on a dirty tree; the
intended use case is "stash away, pull, then restore", so I
think it is Ok to assume that you will only be restoring on a
clean state (and it would make the implementation simpler).
The three-way merge is done correctly here, and I would imagine
the users would feel the UI quite natural _if_ this merge
conflicts. "git diff" would show only the conflicted paths
(because the updates coming from the old working tree is placed
in the index for cleanly merged paths), editing a conflicted
file and "git add $that_path" would resolve. That's exactly the
same workflow for a conflicted merge.
However, I think it is a bit counterintuitive to update the
working tree change to the index if the merge did not conflict.
It might be better to run an equivalent of "git reset", so that
after "git save restore", the user can say "git diff" (not "git
diff HEAD") to view the local changes. Perhaps...
if git-merge-recursive ...
then
# Cleanly merged..
added="$TMP" &&
git-diff --cached --name-only --diff-filter=A >"$added" &&
git-read-tree HEAD &&
git-update-index --add --stdin <"$added" ||
die "Cannot unstage local modification"
git-update-index --refresh
fi
The --diff-filter dance is so that we do not "forget" newly
added files when we do "read-tree HEAD".
> +
> +if [ "$1" = list ]; then
> + shift
> + if [ "$#" = 0 ]; then
> + set x -n 10
> + shift
> + fi
> + list_save "$@"
> +elif [ "$1" = show ]; then
> + shift
> + show_save "$@"
> +elif [ "$1" = restore ]; then
> + shift
> + restore_save "$@"
> +else
> + save_work
> + git reset --hard
I am not absolutely sure if "git reset --hard" belongs here.
You can certainly type one less command in your example sequence
("stash; pull; restore"). But I suspect there may be a case
that would be more useful if "git save" did not do the reset
itself. I dunno....
> +fi
> +
> +
Style. This is a perfect place to use "case/esac".
case "$1" in
list)
do this thing
;;
...
*)
do default thing
;;
esac
Much easier to read, isn't it?
^ permalink raw reply
* Re: [PATCH][RESEND] git-submodule: provide easy way of adding new submodules
From: Junio C Hamano @ 2007-06-23 19:58 UTC (permalink / raw)
To: skimo; +Cc: git, Lars Hjemli
In-Reply-To: <20070621095300.GA27071MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> COMMANDS
> --------
> +add::
> + Add the given repository as a submodule at the given path
> + to the changeset to be committed next. In particular, the
> + repository is cloned at the specified path, added to the
> + changeset and registered in .gitmodules. If no path is
> + specified, the path is deduced from the repository specification.
> +
Somehow "git submodule add $URL $my_subdirectory" feels
unnatural, although it certainly is simpler to write the command
usage string. Wouldn't a commit on the maintenance branch of
cgit.git want to say "Add the 'maint' branch of git.git as my
submodule", for example?
The alternatives I can come up with do not feel right either, though.
git submodule $my_subdirectory $URL [$branch]
git submodule $URL [--branch $branch] $my_subdirectory
Hmmm...
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 89a3885..3df7121 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -1,13 +1,14 @@
> #!/bin/sh
> #
> -# git-submodules.sh: init, update or list git submodules
> +# git-submodules.sh: add, init, update or list git submodules
> #
> # Copyright (c) 2007 Lars Hjemli
>
> -USAGE='[--quiet] [--cached] [status|init|update] [--] [<path>...]'
> +USAGE='[--quiet] [--cached] [add <repo>|status|init|update] [--] [<path>...]'
Can a single repo added at more than one path with this syntax?
I do not see that in the code, but this implies such.
> . git-sh-setup
> require_work_tree
>
> +add=
> init=
> update=
> status=
> @@ -25,6 +26,17 @@ say()
> fi
> }
>
> +get_repo_base() {
> + (
> + cd "`/bin/pwd`" &&
> + cd "$1" || cd "$1.git" &&
> + {
> + cd .git
> + pwd
> + }
> + ) 2>/dev/null
> +}
> +
I've seen this code before elsewhere. We do not need to
refactor right now with this patch, but please mark this copy
with something like:
# NEEDSWORK: identical function exists in get_repo_base
# in clone.sh
get_repo_base () {
...
as a reminder.
> @@ -66,6 +78,44 @@ module_clone()
> }
>
> #
> +# Add a new submodule to the working tree, .gitmodules and the index
> +#
> +# $@ = repo [path]
> +#
> +module_add()
> +{
> + repo=$1
> + path=$2
> +
> + # Turn the source into an absolute path if
> + # it is local
> + if base=$(get_repo_base "$repo"); then
> + repo="$base"
> + fi
> +
> + # Guess path from repo if not specified or strip trailing slashes
> + if test -z "$path"; then
> + path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
> + else
> + path=$(echo "$path" | sed -e 's|/*$||')
> + fi
> +
> + test -e "$path" &&
> + die "'$path' already exists"
> +
> + module_clone "$path" "$repo" || exit
- module_clone catches the "$path already exists" case; but the
test is done differently. One particular case of "an empty
directory exists" is allowed there, but you are dying early
to forbid it. Is that warranted? My gut feeling is that
they should share the same check, iow, don't check yourself
but have module_clone take care of the error case.
- If $path does not exist in the worktree (because it hasn't
been checked out), but does exist in the index, what should
happen? Should it be flagged as an error (in module_clone,
not here)?
^ permalink raw reply
* Re: 100%
From: Junio C Hamano @ 2007-06-23 19:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: René Scharfe, David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706231154300.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> By the same reasoning, you could say "never round down to 0%, because I
> want to know when there is no similarity".
>
> You cannot be exact when you have to cut off fractions, so why try for
> _exactly_ one number?
R0 or C0 would not happen in real life, so 0% is a moot issue.
However, wasn't that you who did follow that "certain numbers
are special" logic in diffstat?
You advocated "diff --stat" should draw at least one +/- for a
patch that adds/removes lines. And I (and others) agreed
because zero is special in the context of that application.
I think reserving R100 to mean "identical byte sequences" has
value, when people look at --name-status output, in the context
of "similarity index".
^ permalink raw reply
* [PATCH] transplant: move a series of commits to a different parent
From: Steffen Prohaska @ 2007-06-23 19:27 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <1BD13366-B4BD-4630-9046-49567A345CBC@zib.de>
git-transplant.sh <onto> <from> <to>
transplant starts with the contents of <onto> and puts on top of
it the contents of files if they are touched by the series of
commits <from>..<to>. If a commit touches a file the content of
this file is taken as it is in the commit. No merging is
performed. Original authors, commiters, and commit messages are
preserved.
Warning: this is just a quick hack to solve _my_ problem.
- No error checking is performed.
- Removal of files is not handled.
- Whitespace in filename is not handled.
- The index is left in dirty state.
- No branch is created for the result.
- The script is not integrated with git's shell utilities.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-transplant.sh | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
create mode 100755 git-transplant.sh
This script seems to solved the problem for me. I can place
the topic branch imported from cvs to the right place.
What do you think? Is this a sane way to handle the situation?
Steffen
diff --git a/git-transplant.sh b/git-transplant.sh
new file mode 100755
index 0000000..3320071
--- /dev/null
+++ b/git-transplant.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+[[ $# == 3 ]] || { echo "$0 <onto> <from> <to>"; exit 1; }
+onto=$(git-rev-parse $1)
+from=$(git-rev-parse $2)
+to=$(git-rev-parse $3)
+
+# copied from git-filter-branch.sh
+set_ident () {
+ lid="$(echo "$1" | tr "A-Z" "a-z")"
+ uid="$(echo "$1" | tr "a-z" "A-Z")"
+ pick_id_script='
+ /^'$lid' /{
+ s/'\''/'\''\\'\'\''/g
+ h
+ s/^'$lid' \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/export GIT_'$uid'_NAME='\''&'\''/p
+
+ g
+ s/^'$lid' [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/export GIT_'$uid'_EMAIL='\''&'\''/p
+
+ g
+ s/^'$lid' [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/export GIT_'$uid'_DATE='\''&'\''/p
+
+ q
+ }
+ '
+
+ LANG=C LC_ALL=C sed -ne "$pick_id_script"
+ # Ensure non-empty id name.
+ echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
+}
+
+parent=$onto
+git-read-tree --reset $parent
+
+for commit in $(git-rev-list --reverse $from..$to)
+do
+ echo "rewriting commit $commit..."
+ git-diff-tree -r $commit | grep ^: | cut -b 9-15,57-97,100- |
+ while read mode sha path
+ do
+ echo " $mode $sha $path"
+ git-update-index --add --cacheinfo $mode $sha $path
+ done
+
+ eval "$(git-cat-file commit $commit |set_ident AUTHOR)"
+ eval "$(git-cat-file commit $commit |set_ident COMMITTER)"
+
+ parent=$(git-cat-file commit $commit | sed -e '1,/^$/d' | git-commit-tree $(git-write-tree) -p $parent)
+ echo "... new commit $parent"
+done
+
+echo ""
+echo "new head is $parent"
--
1.5.2.2.315.gc649a
^ permalink raw reply related
* Re: [PATCH][RESEND] git-submodule: provide easy way of adding new submodules
From: Lars Hjemli @ 2007-06-23 19:26 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <20070621095300.GA27071MdfPADPa@greensroom.kotnet.org>
On 6/21/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> I didn't get any reaction (negative or positive) to this patch.
Sorry for the late reply, I've been buried in day-job stuff lately
(and still is).
The patch looks sane to me. I'll try to play around with it tomorrow
and give some more feedback.
--
larsh
^ permalink raw reply
* RE: [PATCH] git-svn: allow dcommit to retain local merge information
From: Tjernlund @ 2007-06-23 17:56 UTC (permalink / raw)
To: 'Steven Grimm', 'Eric Wong'; +Cc: 'Junio C Hamano', git
> > $ echo post-merge trunk change >> trunk/testfile1
> > $ svn commit -m "trunk change after merge"
> > $ echo post-merge conflicting change >> trunk/testfile2
> > $ svn commit -m "trunk change with conflict"
> > $ cd ../gitclone
> > $ git-svn fetch
> > $ git merge -m "change with conflict" trunk
> >
> > Conflict, as expected
> >
> > $ vi testfile2
> > $ git add testfile2
> > $ git commit
> > $ git-svn dcommit
> > Transaction is out of date: Out of date: '/trunk/testfile1' in
> > transaction '9-1' at /Users/koreth/git/git-svn line 398
>
> Maybe this can help?
> http://svn.haxx.se/subusers/archive-2005-02/0096.shtml
> http://subclipse.tigris.org/faq.html#out-of-date
Could this be related to do_update vs. do_switch?
Latest subversion appears to have a working
do_switch function.
Jocke
^ permalink raw reply
* qgit: Annotate hundreds of files at terrific speed ;-)
From: Marco Costalba @ 2007-06-23 16:35 UTC (permalink / raw)
To: Git Mailing List
- pull from git://git.kernel.org/pub/scm/qgit/qgit4.git
- compile + install
- run qgit on the git repo
- select the 900 pounds gorilla called 'Makefile' from tree view ('t'
key shortcut)
- double click on it so to start file viewer and annotation
- say wahooo!
You get _all_ the hundreds (more then 800) of revisions of this
monster history annotated in the time it takes *other* ;-) tools to
annotate just one of them.
Ok. Come back to earth. I've just pushed some patches to use 'git log'
instead of 'git rev-list' as interface with git.
By using git-log with '-p' option it is possible to get a file history
_and_ corresponding diff in one pass instead of the double step
git-rev-list + git-diff-tree. Speed up it's huge.
But there are other gains:
- qgit can now be run with any command line argument known to 'git log'
- when Linus patch 'git log --follow' will be accepted by Junio the
following of file renames will come automatically
Unfortunately there are issues too:
- git-log lacks currently a --stdin option needed to pass a long list
of sha's, something that a tool sometime wants to do.
- because of the previous issue a StGIT repo under with a long list of
unapplied patches may break 'git log' loading.
- probably 'git log --follow' will come semi-automatically because an
incompatibility with '--parents' option, as pointed out by Linus,
needs a workaround. The latter is currently used to handle the grafts.
Marco
^ permalink raw reply
* (resend) [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Jim Meyering @ 2007-06-23 15:13 UTC (permalink / raw)
To: git
Hi Jun,
Here's a copy of my patch, from here:
http://thread.gmane.org/gmane.comp.version-control.git/48469/focus=48636
Jim
-----------------------------
From 42e3a6f676e9ae4e9640bc2ff36b7ab0b061a60e Mon Sep 17 00:00:00 2001
From: Jim Meyering <jim@meyering.net>
Date: Sat, 26 May 2007 13:43:07 +0200
Subject: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
Currently, when git-diff writes to a full device or gets an I/O error,
it fails to detect the write error:
$ git-diff |wc -c
3984
$ git-diff > /dev/full && echo ignored write failure
ignored write failure
git-log does the same thing:
$ git-log -n1 > /dev/full && echo ignored write failure
ignored write failure
Each and every 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.
$ ./git-log -n1 > /dev/full
fatal: write failure on standard output: No space left on device
[Exit 128]
$ ./git-diff > /dev/full
fatal: write failure on standard output: No space left on device
[Exit 128]
You can demonstrate this with git's own --version output, too:
(but git --help detects the failure without this patch)
$ ./git --version > /dev/full
fatal: write failure on standard output: No space left on device
[Exit 128]
Note that the fcntl test (for whether the fileno may be closed) is
required in order to avoid EBADF upon closing an already-closed stdout,
as would happen for each git command that already closes stdout; I think
update-index was the one I noticed in the failure of t5400, before I
added that test.
Also, to be consistent with e.g., write_or_die, do not
diagnose EPIPE write failures.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
git.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 29b55a1..8258885 100644
--- a/git.c
+++ b/git.c
@@ -308,6 +308,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
for (i = 0; i < ARRAY_SIZE(commands); i++) {
struct cmd_struct *p = commands+i;
const char *prefix;
+ int status;
if (strcmp(p->cmd, cmd))
continue;
@@ -321,7 +322,23 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
die("%s must be run in a work tree", cmd);
trace_argv_printf(argv, argc, "trace: built-in: git");
- exit(p->fn(argc, argv, prefix));
+ status = p->fn(argc, argv, prefix);
+
+ /* Close stdout if necessary, and diagnose any failure
+ other than EPIPE. */
+ if (fcntl(fileno (stdout), F_GETFD) >= 0) {
+ errno = 0;
+ if ((ferror(stdout) || fclose(stdout))
+ && errno != EPIPE) {
+ if (errno == 0)
+ die("write failure on standard output");
+ else
+ die("write failure on standard output"
+ ": %s", strerror(errno));
+ }
+ }
+
+ exit(status);
}
}
--
1.5.2.73.g18bece
^ permalink raw reply related
* Re: [PATCH] Add git-save script
From: Johannes Schindelin @ 2007-06-23 15:13 UTC (permalink / raw)
To: Bill Lear; +Cc: Nanako Shiraishi, GIT
In-Reply-To: <18045.14200.611958.870171@lisa.zopyra.com>
Hi,
On Sat, 23 Jun 2007, Bill Lear wrote:
> On Saturday, June 23, 2007 at 16:05:22 (+0100) Johannes Schindelin writes:
> >Hi,
> >
> >On Sat, 23 Jun 2007, Nanako Shiraishi wrote:
> >
> >> Here is how to use my script:
> >>
> >> $ git save
> >> $ git pull
> >> $ git save restore
> >
> >This use case has been discussed often, under the name "git-stash".
>
> Was git-stash added as a patch yet? If not, do you think Nanako's
> patch does not address the concerns that were raised in the
> discussion you refer to?
Obviously, I prefer my approach of installing an alias.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: Bill Lear @ 2007-06-23 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, GIT
In-Reply-To: <Pine.LNX.4.64.0706231605160.4059@racer.site>
On Saturday, June 23, 2007 at 16:05:22 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Sat, 23 Jun 2007, Nanako Shiraishi wrote:
>
>> Here is how to use my script:
>>
>> $ git save
>> $ git pull
>> $ git save restore
>
>This use case has been discussed often, under the name "git-stash".
Was git-stash added as a patch yet? If not, do you think Nanako's
patch does not address the concerns that were raised in the
discussion you refer to?
Bill
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: Johannes Schindelin @ 2007-06-23 15:05 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: GIT
In-Reply-To: <20070623220215.6117@nanako3.bluebottle.com>
Hi,
On Sat, 23 Jun 2007, Nanako Shiraishi wrote:
> Here is how to use my script:
>
> $ git save
> $ git pull
> $ git save restore
This use case has been discussed often, under the name "git-stash".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsimport: test case for severe branch import problem
From: Steffen Prohaska @ 2007-06-23 13:26 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <11826031071213-git-send-email-prohaska@zib.de>
On Jun 23, 2007, at 2:51 PM, Steffen Prohaska wrote:
> The conclusion is you must not rely on the existing cvsimport for
> tracking cvs branches. The history of such branches may be plain
> wrong.
> Git may display different patches than cvs would do. Merging cvs
> topic branches may yield completely wrong results. One obvious thing
> that may happen is that a merge reverts changes commited to the cvs
> trunk before the first commit to the cvs branch. And this would happen
> without any indication by git. Everything would seem to run smoothely.
This is not only a theoretical problem but I am experiencing it on a
real-world repository right now. I have a topic branch that branches
off from the wrong commit in git.
Is there an easy way to fix this? I know the right commit the branch
should have as its parent. How can I move it there? git-rebase is not
the
right command because the patches derived from my branch are already
wrong.
I would only need to attach the first commit to a different parent.
Steffen
^ permalink raw reply
* [PATCH] Add git-save script
From: Nanako Shiraishi @ 2007-06-23 13:02 UTC (permalink / raw)
To: GIT
When my boss has something to show me and I have to update, for some reason I
am always in the middle of doing something else, and git pull command refuses
to work in such a case.
I wrote this little script to save the changes I made, perform the update,
and then come back to where I was, but on top of the updated commit.
Here is how to use my script:
$ git save
$ git pull
$ git save restore
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
diff --git a/git-save.sh b/git-save.sh
new file mode 100755
index 0000000..b45652e
--- /dev/null
+++ b/git-save.sh
@@ -0,0 +1,74 @@
+#! /bin/sh
+
+. git-sh-setup
+require_work_tree
+
+function save_work () {
+ save=$( (
+ i_tree=$(git-write-tree)
+
+ TMP=$GIT_DIR/.git-save-tmp
+ GIT_INDEX_FILE=$TMP
+ export GIT_INDEX_FILE
+
+ git-read-tree $i_tree
+ git-add -u
+ w_tree=$(git-write-tree)
+ rm $TMP
+ git-read-tree --prefix=base/ HEAD^{tree}
+ git-read-tree --prefix=indx/ $i_tree
+ git-read-tree --prefix=work/ $w_tree
+ git-write-tree
+ rm $TMP
+ ) )
+
+ head=$(git-log --abbrev-commit --pretty=oneline -n 1 HEAD)
+ if branch=$(git symbolic-ref -q HEAD); then
+ branch=${branch#refs/heads/}
+ else
+ branch='(no branch)'
+ fi &&
+ msg=$(printf 'WIP on %s "%s"' "$branch" "$head")
+
+ saved=$(printf '%s' "$msg" | git-commit-tree "$save")
+ git update-ref -m "$msg" refs/heads/saved $saved
+ printf 'Saved %s\n' "$msg" >&2
+}
+
+function list_save () {
+ git-log --abbrev-commit --pretty=oneline -g "$@" saved
+}
+
+function show_save () {
+ save=$(git rev-parse --verify --default saved "$1")
+ git diff-tree --stat $save:base $save:work
+}
+
+function restore_save () {
+ save=$(git rev-parse --verify --default saved "$1")
+ h_tree=$(git rev-parse --verify $save:base)
+ i_tree=$(git rev-parse --verify $save:indx)
+ w_tree=$(git rev-parse --verify $save:work)
+
+ git-merge-recursive $h_tree -- HEAD^{tree} $w_tree
+}
+
+if [ "$1" = list ]; then
+ shift
+ if [ "$#" = 0 ]; then
+ set x -n 10
+ shift
+ fi
+ list_save "$@"
+elif [ "$1" = show ]; then
+ shift
+ show_save "$@"
+elif [ "$1" = restore ]; then
+ shift
+ restore_save "$@"
+else
+ save_work
+ git reset --hard
+fi
+
+
--
しらいし ななこ http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com
^ permalink raw reply related
* [PATCH] cvsimport: test case for severe branch import problem
From: Steffen Prohaska @ 2007-06-23 12:51 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
The result of importing branches using git-cvsimport depends
on the time of the first commit to the cvs branch. If the first
commit is done after other commits to the cvs trunk the result
of cvsimport may be wrong. git-cvsimport creates a wrong history.
The problem is quite severe because merging such a wrongly imported
branch by git may be successful without reporting any problem but the
results are wrong. The result may differ from what a simple cvs merge
(cvs up -j) yields.
This test script creates two cvs repositories and imports both to
git. The first cvs repository has the 'wrong' order of commits and
yields an error. The result of a merge in cvs and a merge in git
differs. The second cvs repository has the 'right' order and the
import to git runs as expected and merging yields the same results
in cvs and git.
The conclusion is you must not rely on the existing cvsimport for
tracking cvs branches. The history of such branches may be plain wrong.
Git may display different patches than cvs would do. Merging cvs
topic branches may yield completely wrong results. One obvious thing
that may happen is that a merge reverts changes commited to the cvs
trunk before the first commit to the cvs branch. And this would happen
without any indication by git. Everything would seem to run smoothely.
This conclusion should be stated in bold at appropriate places in
the documentation.
It's a pity because merging is what git is especially good at. But
as long as git-cvsimport may create the wrong history you can't use
git to merge cvs topic branches without double checking every detail,
which makes this approach unfeasable.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
t/t9600-cvsimport.sh | 184 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 184 insertions(+), 0 deletions(-)
create mode 100755 t/t9600-cvsimport.sh
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
new file mode 100755
index 0000000..180cd8a
--- /dev/null
+++ b/t/t9600-cvsimport.sh
@@ -0,0 +1,184 @@
+
+test_description='CVS import'
+
+. ./test-lib.sh
+
+cvs >/dev/null 2>&1
+if test $? -ne 1
+then
+ test_expect_success 'skipping git-cvsimport tests, cvs not found' :
+ test_done
+ exit
+fi
+
+CVSROOT=$(pwd)/cvsrootwrong
+CVSWORK=$(pwd)/cvsworkwrong
+CVSIMPORTED=$(pwd)/cvsimportedwrong
+export CVSROOT CVSWORK
+
+cvspscache="$HOME/.cvsps/$(echo $CVSROOT | sed -e 's%/%#%g')#src"
+rm -f $cvspscache
+
+rm -rf "$CVSROOT" "$CVSWORK"
+mkdir "$CVSROOT" &&
+cvs init &&
+mkdir "$CVSROOT/src"
+cvs -Q co -d "$CVSWORK" src &&
+rm -rf .git ||
+exit 1
+
+# sleeps are needed to fight cvsps' fuzz
+test_expect_success \
+ 'initial cvs commits, tag, and branch' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 1" >>a.txt &&
+ cvs add a.txt &&
+ cvs commit -m "cvs commit 1" &&
+ sleep 2 &&
+ echo "a: line 2" >>a.txt &&
+ echo "a: line 3" >>a.txt &&
+ echo "a: line 4" >>a.txt &&
+ echo "a: line 5" >>a.txt &&
+ cvs commit -m "cvs commit 2" &&
+ cvs tag split &&
+ cvs tag -b branch &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C $CVSIMPORTED -o cvshead src'
+
+test_expect_success \
+ 'cvs commit' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 6" >>a.txt &&
+ cvs commit -m "cvs commit 2" &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'cvs commit' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 7" >>a.txt &&
+ cvs commit -m "cvs commit 3" &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C $CVSIMPORTED -o cvshead src'
+
+test_expect_success \
+ 'cvs commit' \
+ '( cd "$CVSWORK" &&
+ cvs up -r branch &&
+ sed -e 's/2/B/' a.txt >t &&
+ mv t a.txt &&
+ cvs commit -m "cvs commit on branch" &&
+ cvs up -A &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C $CVSIMPORTED -o cvshead src'
+
+test_expect_success \
+ 'merging' \
+ '( cd "$CVSWORK" &&
+ cvs up -j branch
+ ) &&
+ (
+ cd "$CVSIMPORTED" &&
+ git-checkout cvshead &&
+ git-merge branch
+ ) &&
+ diff -q "$CVSWORK/a.txt" "$CVSIMPORTED/a.txt"'
+
+CVSROOT=$(pwd)/cvsrootright
+CVSWORK=$(pwd)/cvsworkright
+CVSIMPORTED=$(pwd)/cvsimportedright
+export CVSROOT CVSWORK
+
+cvspscache="$HOME/.cvsps/$(echo $CVSROOT | sed -e 's%/%#%g')#src"
+rm -f $cvspscache
+
+rm -rf "$CVSROOT" "$CVSWORK"
+mkdir "$CVSROOT" &&
+cvs init &&
+mkdir "$CVSROOT/src"
+cvs -Q co -d "$CVSWORK" src &&
+rm -rf .git ||
+exit 1
+
+# sleeps are needed to fight cvsps' fuzz
+test_expect_success \
+ 'initial cvs commits, tag, and branch' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 1" >>a.txt &&
+ cvs add a.txt &&
+ cvs commit -m "cvs commit 1" &&
+ sleep 2 &&
+ echo "a: line 2" >>a.txt &&
+ echo "a: line 3" >>a.txt &&
+ echo "a: line 4" >>a.txt &&
+ echo "a: line 5" >>a.txt &&
+ cvs commit -m "cvs commit 2" &&
+ cvs tag split &&
+ cvs tag -b branch &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C $CVSIMPORTED -o cvshead src'
+
+test_expect_success \
+ 'cvs commit' \
+ '( cd "$CVSWORK" &&
+ cvs up -r branch &&
+ sed -e 's/2/B/' a.txt >t &&
+ mv t a.txt &&
+ cvs commit -m "cvs commit on branch" &&
+ cvs up -A &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C $CVSIMPORTED -o cvshead src'
+
+test_expect_success \
+ 'cvs commit' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 6" >>a.txt &&
+ cvs commit -m "cvs commit 2" &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'cvs commit' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 7" >>a.txt &&
+ cvs commit -m "cvs commit 3" &&
+ sleep 2
+ )'
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C $CVSIMPORTED -o cvshead src'
+
+test_expect_success \
+ 'merging' \
+ '( cd "$CVSWORK" &&
+ cvs up -j branch
+ ) &&
+ (
+ cd "$CVSIMPORTED" &&
+ git-checkout cvshead &&
+ git-merge branch
+ ) &&
+ diff -q "$CVSWORK/a.txt" "$CVSIMPORTED/a.txt"'
+
+test_done
--
1.5.2.2.315.gc649a
^ permalink raw reply related
* Re: 100%
From: Johannes Schindelin @ 2007-06-23 12:21 UTC (permalink / raw)
To: René Scharfe; +Cc: David Kastrup, git
In-Reply-To: <467D0DE8.6030104@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 922 bytes --]
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
> As I already hinted at, the common result of comparing two files, as
> done by e.g. cmp(1), is one bit that indicates equality. This
> information is lost when using up/down rounding, but it is retained when
> rounding down. It's _not_ common to be unable to determine equality
> from the result of a file compare.
And as _I_ already hinted, this does not matter. The whole purpose to have
a number here instead of a bit is to have a larger range. In practice, I
bet that the 100% are really uninteresting. At least here, they are.
For example, if you move a Java class from one package into another, you
have to change the package name in the file. Guess what, I am perfectly
okay if the rename detector says "100% similarity" here. Because if it is
closer to 100% than to 99%, dammit, I want to see 100%, not 99%.
Nuff said about this subject.
Ciao,
Dscho
^ permalink raw reply
* Re: 100%
From: René Scharfe @ 2007-06-23 12:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706231259021.4059@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Sat, 23 Jun 2007, René Scharfe wrote:
>
>> Johannes Schindelin schrieb:
>>
>>> By the same reasoning, you could say "never round down to 0%, because
>>> I want to know when there is no similarity".
>>>
>>> You cannot be exact when you have to cut off fractions, so why try for
>>> _exactly_ one number?
>> Because completeness is special.
>
> I am not convinced. My vote is still for the _common_ practice of just
> rounding. IOW keep it as is.
As I already hinted at, the common result of comparing two files, as
done by e.g. cmp(1), is one bit that indicates equality. This
information is lost when using up/down rounding, but it is retained when
rounding down. It's _not_ common to be unable to determine equality
from the result of a file compare.
René
^ permalink raw reply
* Re: 100%
From: Johannes Schindelin @ 2007-06-23 12:00 UTC (permalink / raw)
To: René Scharfe; +Cc: David Kastrup, git
In-Reply-To: <467D06D4.9050203@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 464 bytes --]
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
> Johannes Schindelin schrieb:
>
> > By the same reasoning, you could say "never round down to 0%, because
> > I want to know when there is no similarity".
> >
> > You cannot be exact when you have to cut off fractions, so why try for
> > _exactly_ one number?
>
> Because completeness is special.
I am not convinced. My vote is still for the _common_ practice of just
rounding. IOW keep it as is.
Ciao,
Dscho
^ permalink raw reply
* Re: 100%
From: René Scharfe @ 2007-06-23 11:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706231154300.4059@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Sat, 23 Jun 2007, René Scharfe wrote:
>
>> Johannes Schindelin schrieb:
>>> On Fri, 22 Jun 2007, David Kastrup wrote:
>>>> The people I know will expect "100% identical" or even "100.0%
>>>> identical" to mean identical, period. They will be quite surprised to
>>>> hear that "99.95%" is supposed to be included.
>>> Granted, 100.0% means as close as you can get to "completely" with 4
>>> digits. But if you have an integer, you better use the complete range,
>>> rather than arbitrarily make one number more important than others.
>>>
>>> For if you see an integer, you usually assume a rounded value. If you
>>> don't, you're hopeless.
>> Why hopeless? It's a useful convention to define "100%" as "complete
>> (not rounded)".
>
> By the same reasoning, you could say "never round down to 0%, because I
> want to know when there is no similarity".
>
> You cannot be exact when you have to cut off fractions, so why try for
> _exactly_ one number?
Because completeness is special. If just one bit was available, I'd use
it to indicate equality. That's what the authors of cmp(1) did, too. :)
And 0% is not special, at least not in a useful way that I can think of.
I.e. there is no practical difference between "no two lines match" and
"one percent of the lines match". If you're really interested in
similarities with an index below 10% then you'd better work with
absolute numbers instead of rounded percentages.
If someone came around with an interest in those cases with exactly 0%
similarity, then we might need to decide between rounding up or down.
But even in that hypothetical situation I think "equality" is still more
interesting a data point than "really everything differs".
René
^ permalink raw reply
* Re: help with cvsimport
From: Johannes Schindelin @ 2007-06-23 11:27 UTC (permalink / raw)
To: Raimund Bauer; +Cc: git
In-Reply-To: <1182589892.5937.10.camel@localhost>
Hi,
On Sat, 23 Jun 2007, Raimund Bauer wrote:
> I unfortunately have to work with several cvs-repositories and was
> wondering if there was a way to have the files processed on import:
> - strip trailing whitespace
> - convert to newline-only line endings
If you want to use cvsimport incrementally, I'd rather not process the
"origin" branch like this, but rather use git-filter-branch (with a simple
index filter) to do that.
Even if you do not want to use it incrementally, it seems easier and
cleaner (if somewhat slower) to me.
So, something like
git filter-branch --index-filter 'git ls-files |
while read name; do
perl -pi -e "s/[ \009\015]*$//" "$name"
done
git add -u' cleaned-up-origin
should do.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: add example to move everything into a subdirectory
From: Johannes Schindelin @ 2007-06-23 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vwsxv8a1a.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Fri, 22 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> > index ffb31d6..297e09e 100644
> > --- a/git-filter-branch.sh
> > +++ b/git-filter-branch.sh
> > @@ -181,6 +181,14 @@
>
> Keeping your private repository out of sync with me is Ok, but can you
> fix the filemode when you have chance? The warning I get every time I
> apply a patch from you to this file about mode mismatch somewhat annoys
> me.
I am sorry! I did not even realize that I was _so_ out of sync. ATM AFAICT
there is only the "skip" hack in my repo.
Ciao,
Dscho
^ permalink raw reply
* Re: 100%
From: Johannes Schindelin @ 2007-06-23 10:56 UTC (permalink / raw)
To: René Scharfe; +Cc: David Kastrup, git
In-Reply-To: <467CF380.6060603@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 975 bytes --]
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
> Johannes Schindelin schrieb:
> > On Fri, 22 Jun 2007, David Kastrup wrote:
> >> The people I know will expect "100% identical" or even "100.0%
> >> identical" to mean identical, period. They will be quite surprised to
> >> hear that "99.95%" is supposed to be included.
> >
> > Granted, 100.0% means as close as you can get to "completely" with 4
> > digits. But if you have an integer, you better use the complete range,
> > rather than arbitrarily make one number more important than others.
> >
> > For if you see an integer, you usually assume a rounded value. If you
> > don't, you're hopeless.
>
> Why hopeless? It's a useful convention to define "100%" as "complete
> (not rounded)".
By the same reasoning, you could say "never round down to 0%, because I
want to know when there is no similarity".
You cannot be exact when you have to cut off fractions, so why try for
_exactly_ one number?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] t9500: skip gitweb tests if perl version is too old
From: Sven Verdoolaege @ 2007-06-23 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps3n3rm7.fsf@assigned-by-dhcp.pobox.com>
On Sat, Jun 23, 2007 at 03:14:08AM -0700, Junio C Hamano wrote:
> Well, "Encode::FB_CLUCK" is a bogus symbol even in recent Perl.
> IOW, the tested function does not seem to care if I give
> whatever garbage as the second parameter.
>
> But I guess you are only interested if the perl used to run
> gitweb barfs with that two parameter, so the original check
> would be the right way.
Indeed. gitweb doesn't use FB_CLUCK and if it did, we would
want to know about it (and not skip the tests).
skimo
^ 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