* Re: [PATCH] git-send-email: Add --threaded option
From: Junio C Hamano @ 2007-06-27 5:21 UTC (permalink / raw)
To: Adam Roben; +Cc: git
In-Reply-To: <11828981103069-git-send-email-aroben@apple.com>
Adam Roben <aroben@apple.com> writes:
> The --threaded option controls whether the In-Reply-To header will be set on
> any emails sent. The current behavior is to always set this header, so this
> option is most useful in its negated form, --no-threaded. This behavior can
> also be controlled through the 'sendemail.threaded' config setting.
>
> Signed-off-by: Adam Roben <aroben@apple.com>
Thanks. I've always felt that send-email has too much built-in
policy; I think this is a sensible change.
> @@ -138,8 +141,8 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
> $initial_reply_to,$initial_subject,@files,$from,$compose,$time);
>
> # Behavior modification variables
> -my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
> - $dry_run) = (1, 0, 0, 0, 0);
> +my ($threaded, $chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
> + $dry_run) = (1, 1, 0, 0, 0, 0);
While we are at it, you might want to make everything other than
quiet and dry_run overridable the same way.
^ permalink raw reply
* t9400-git-cvsserver-server failures
From: Brian Gernhardt @ 2007-06-27 3:07 UTC (permalink / raw)
To: Git Mailing List
I'm getting several failures in the git-cvsserver tests. I don't
even know where to start with that code, so here's as detailed an
error report as I can give.
The first category appears to be that several of the tests use
test_expect_failure, which expects the error codes to be less than
127 and the error it gets is 255 (-1).
* FAIL 9: req_Root failure (strict-paths)
cat request-anonymous | git-cvsserver --strict-paths pserver
$WORKDIR >log 2>&1
* FAIL 11: req_Root failure (w/o strict-paths)
cat request-anonymous | git-cvsserver pserver $WORKDIR/
gitcvs >log 2>&1
* FAIL 13: req_Root failure (base-path)
cat request-anonymous | git-cvsserver --strict-paths --base-
path $WORKDIR pserver $SERVERDIR >log 2>&1
The other seems to be that git-cvsserver is erroring with "error 1
Conflicting roots specified" unexpectedly. The log has the expected
"I LOVE YOU" line, but then also has an error line.
* FAIL 12: req_Root (base-path)
cat request-base | git-cvsserver --strict-paths --base-path
$WORKDIR/ pserver $SERVERDIR >log 2>&1 &&
tail -n1 log | grep -q "^I LOVE YOU$"
* FAIL 16: req_Root (everything together)
cat request-base | git-cvsserver --export-all --strict-paths
--base-path $WORKDIR/ pserver $SERVERDIR >log 2>&1 &&
tail -n1 log | grep -q "^I LOVE YOU$"
And, finally, one test fails because apparently the environment is
not set up as it expects.
* FAIL 14: req_Root (export-all)
cat request-anonymous | git-cvsserver --export-all pserver
$WORKDIR >log 2>&1 &&
tail -n1 log | grep -q "^I LOVE YOU$"
This fails with:
E GITCVS emulation needs to be enabled on this repo
E the repo config file needs a [gitcvs] section added, and the
parameter 'enabled' set to 1
E
error 1 GITCVS emulation disabled
E Invalid root /Users/brian/dev/git/t/trash/gitcvs.git
I checked gitcvs.git/config, and it has "[gitcvs] enabled = false".
~~ Brian
^ permalink raw reply
* Re: [PATCH 1/2] Add test script for git-stripspace.
From: Junio C Hamano @ 2007-06-27 2:32 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes.Schindelin, krh
In-Reply-To: <46801665.4050708@gmail.com>
Carlos Rica <jasampler@gmail.com> writes:
> These tests check some features that git-stripspace already has
> and those that it should manage well: Removing trailing spaces
> from lines, removing blank lines at the beginning and end,
> unifying multiple lines between paragraphs, doing the correct
> when there is no newline at the last line, etc.
>
> It seems that the implementation needs to save the whole line
> in memory to be able to manage correctly long lines with
> text and spaces conveniently distribuited on them.
>
> Signed-off-by: Carlos Rica <jasampler@gmail.com>
Thanks. That's extensive set of tests for a little utility.
> t/t0030-stripspace.sh | 355
> +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 355 insertions(+), 0 deletions(-)
> create mode 100644 t/t0030-stripspace.sh
>
> diff --git a/t/t0030-stripspace.sh b/t/t0030-stripspace.sh
> new file mode 100644
> index 0000000..abd82d7
> --- /dev/null
> +++ b/t/t0030-stripspace.sh
100755?
> @@ -0,0 +1,355 @@
> ...
> +test_expect_success \
> + 'long lines without spaces should be unchanged' '
> + echo "$ttt" >expect &&
> + cat expect | git-stripspace >actual &&
> + git diff expect actual &&
Please don't cat a single file into a pipeline.
git-stripspace <actual >expect
^ permalink raw reply
* Re: git-svn error "Unable to extract revision information from commit ...~1"
From: Junio C Hamano @ 2007-06-27 2:20 UTC (permalink / raw)
To: Steven Grimm; +Cc: Victor Bogado da Silva Lins, git
In-Reply-To: <4681C27B.8040009@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Victor Bogado da Silva Lins wrote:
>> The problem seem to be that when I merge the head with another branch
>> git-svn does not know where to follow to meet the "svn trunk".
>
> The current release of git-svn doesn't support committing merges. It
> has no clue how to walk nonlinear history, as you point out. The
> current practice is to do "git merge --squash" when merging into the
> git-svn branch that you want to use as the basis for your svn
> commit. The --squash option will make git merge the contents of the
> other branch(es) but record the resulting tree as a regular commit,
> not as a merge.
>
> There is a work-in-progress patch which might help you if you need to
> preserve merge ancestry on the git side. Search the mailing list
> archives for "[PATCH] git-svn: allow dcommit to retain local merge
> information" if you want to try it (but be aware that it is just an
> initial implementation and may have bugs; it was posted so people
> could try it out and report back any problems to the author.)
... which has been cooking in 'next' for the past two weeks.
^ permalink raw reply
* Re: [PATCH] config: add support for --bool and --int while setting values
From: Junio C Hamano @ 2007-06-27 2:18 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Johannes Sixt, git
In-Reply-To: <7vbqf2ta9f.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> Frank Lichtenheld <frank@lichtenheld.de> writes:
>
>> Something that I forgot to mention in the previous mail:
>> One real problem with the patch is that it expands the k,m,g suffixes
>> for integer values. It probably shouldn't do that.
>
> How about doing something like this, then?
Nah, that wouldn't work, as normalize_value's return value is
parsed and quoted. Grumble....
^ permalink raw reply
* Re: [PATCH 3/3] config: Add --null/-z option for null-delimted output
From: Junio C Hamano @ 2007-06-27 2:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Frank Lichtenheld, Git Mailing List
In-Reply-To: <200706260129.47518.jnareb@gmail.com>
Thanks for the sharp eyes.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-06-27 2:14 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070626133548.GB11504@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Thanks. I'll have a look at receive-pack this week. Is there
> anything in receive-pack yet which helps to use a working tree in the
> hooks? Or is this something for which the behaviour of git still has
> to be defined?
I think the behaviour for receive-pack and the environment the
hooks run in have been pretty well defined. You start in the
repository (the directory $GIT_DIR), GIT_DIR is set and points
at it.
The issue is that the introduction of WORK_TREE enviornment and
core.worktree mechanism might want to update the semantics. For
example, some people seem to run checkout (or perhaps "merge")
to update the associated working tree. Can they find out where
the root of the working tree is (because they would want to
chdir to it before saying "git checkout"), given the current
environment receive-pack sets up for them?
Earlier we said that people who use only GIT_DIR without
GIT_WORK_TREE nor core.worktree should get exactly the same
semantics with or without the WORK_TREE topic, so the above may
not be an issue.
^ permalink raw reply
* Re: [PATCH 2/3] config: Change output of --get-regexp for valueless keys
From: Junio C Hamano @ 2007-06-27 2:14 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Jakub Narebski
In-Reply-To: <11827802363555-git-send-email-frank@lichtenheld.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> Print no space after the name of a key without value.
> Otherwise keys without values are printed exactly the
> same as keys with empty values.
I think this can be defended as a bugfix even though it is a
change in the behaviour. Thanks.
^ permalink raw reply
* Re: [PATCH] git-new-workdir: Fix shell warning about operator == used with test.
From: Junio C Hamano @ 2007-06-27 2:14 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706251304.28886.simon@lst.de>
Thanks.
^ permalink raw reply
* Re: [PATCH] config: add support for --bool and --int while setting values
From: Junio C Hamano @ 2007-06-27 2:13 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Johannes Sixt, git
In-Reply-To: <20070625161401.GW19725@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> On Mon, Jun 25, 2007 at 04:06:34PM +0200, Johannes Sixt wrote:
>> Frank Lichtenheld wrote:
>> >
>> > Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
>>
>> Please excuse if I'm missing the big picture, but why do we need this
>> change?
>
> - Of course the user or script calling git-config can do the
> normalization and error checking, if they want to. But I would
> prefer to have it available in git-config.
> - I would prefer that these options wouldn't be silently ignored,
> because that can be confusing (at least it is documented now, but
> still). So we should either using them or error out. I prefer the former.
>
> Something that I forgot to mention in the previous mail:
> One real problem with the patch is that it expands the k,m,g suffixes
> for integer values. It probably shouldn't do that.
How about doing something like this, then?
git_config_int() knows that a missing value is a nonsense and
barfs on such an input, so (value ? value : "") is redundant
here. Besides, you check value == NULL much earlier in this
function.
diff --git a/builtin-config.c b/builtin-config.c
index 9973f94..33b60ec 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -148,10 +148,11 @@ char* normalize_value(const char* key, const char* value)
if (type == T_RAW)
normalized = xstrdup(value);
else {
- normalized = xmalloc(64);
- if (type == T_INT)
- sprintf(normalized, "%d",
- git_config_int(key, value?value:""));
+ normalized = xmalloc(64 + strlen(value));
+ if (type == T_INT) {
+ int v = git_config_int(key, value);
+ sprintf(normalized, "%d # %s", v, value);
+ }
else if (type == T_BOOL)
sprintf(normalized, "%s",
git_config_bool(key, value) ? "true" : "false");
^ permalink raw reply related
* Re: post-update script to update wc - version 2
From: Sam Vilain @ 2007-06-27 2:06 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <E1I3MuE-0005eO-00@www.watts.utsl.gen.nz>
Sam Vilain wrote:
> this_tree=`git-cat-file commit $commit | awk '/^tree/ { print $2; exit }'`
Of course on newer git, `git-rev-parse $commit:` will do that.
Sam.
^ permalink raw reply
* post-update script to update wc - version 2
From: Sam Vilain @ 2007-06-27 2:05 UTC (permalink / raw)
To: git
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, make this file executable by "chmod +x post-update".
git-update-server-info
export GIT_DIR=`cd $GIT_DIR; pwd`
[ `expr "$GIT_DIR" : '.*/\.git'` = 0 ] && exit 0
tree_in_revlog() {
ref=$1
tree=$2
found=$(
tail logs/$ref | while read commit rubbish
do
this_tree=`git-cat-file commit $commit | awk '/^tree/ { print $2; exit }'`
if [ "$this_tree" = "$tree" ]
then
echo $commit
fi
done
)
[ -n "$found" ] && true
}
for ref
do
active=`git-symbolic-ref HEAD`
if [ "$ref" = "$active" ]
then
echo "Pushing to checked out branch - updating working copy" >&2
success=
if ! (cd ..; git-diff-files) | grep -q .
then
# save the current index just in case
current_tree=`git-write-tree`
if tree_in_revlog $ref $current_tree
then
cd ..
if git-diff-index -R --name-status HEAD >&2 &&
git-diff-index -z --name-only --diff-filter=A HEAD | xargs -0r rm &&
git-reset --hard HEAD
then
success=1
else
echo "E:unexpected error during update" >&2
fi
else
echo "E:uncommitted, staged changes found" >&2
fi
else
echo "E:unstaged changes found" >&2
fi
if [ -z "$success" ]
then
(
echo "Non-bare repository checkout is not clean - not updating it"
echo "However I AM going to update the index. Any half-staged commit"
echo "in that checkout will be thrown away, but on the bright side"
echo "this is probably the least confusing thing for us to do and at"
echo "least we're not throwing any files somebody has changed away"
git-reset --mixed HEAD
echo
echo "This is the new status of the upstream working copy:"
git-status
) >&2
fi
fi
done
^ permalink raw reply
* Re: [PATCH 1/3] rebase -i: several cleanups
From: Junio C Hamano @ 2007-06-27 2:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706270216070.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > @@ -264,8 +269,11 @@ do
>> > echo $ONTO > "$DOTEST"/onto
>> > test t = "$VERBOSE" && : > "$DOTEST"/verbose
>> >
>> > + SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
>> > + SHORTHEAD=$(git rev-parse --short $HEAD)
>> > + SHORTONTO=$(git rev-parse --short $ONTO)
>> > cat > "$TODO" << EOF
>> > -# Rebasing $UPSTREAM..$HEAD onto $ONTO
>> > +# Rebasing $SHORTUPSTREAM)..$SHORTHEAD onto $SHORTONTO
>>
>> What is this close-paren about? Is it a typo?
>
> Darn. It _is_ a typo. I overlooked it _both_ when typing _and_ when
> looking at the result.
No worries; will fix up. I just wanted to make sure that I did
not know the notation that had some meaning.
^ permalink raw reply
* Re: Failure in t5516, tests 15 and 16
From: Brian Gernhardt @ 2007-06-27 1:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v4pkuuq5u.fsf@assigned-by-dhcp.pobox.com>
On Jun 26, 2007, at 9:44 PM, Junio C Hamano wrote:
> Can you check "cd t && sh -x t5516-fetch-push.sh -i -v"?
>
> I am suspecting that
>
> test "$( cd testrepo && git show-ref | wc -l )" = 1
>
> may have an interesting effect when "wc -l" emits extra
> whitespaces. Does this fix it for you?
Exactly right. This bit me a while back on some other test as well.
Should have thought of it this time. Removing the quotes (done
manually, as it was faster than extracting your patch from the mail)
fixed it and that test works properly now. I'm now getting errors in
some CVS test... I'll figure that out later, but it appears
completely unrelated.
I'm beginning to despise several of the OS X utilities. I wonder if
this is inherited from some BSD, or if it's all new. Doesn't matter
though, if you'd be so kind as to remove those quotes from git.git. :-)
~~ Brian
^ permalink raw reply
* Re: [PATCH 1/3] rebase -i: several cleanups
From: Junio C Hamano @ 2007-06-27 1:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706270216070.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > +die_abort () {
>> > + rm -rf "$DOTEST" 2> /dev/null
>> > + die "$1"
>> > +}
>>
>> Why "2>/dev/null" here?
>
> Just to be sure. If it does not exist, it's no error. No sense alarming
> the user.
Yeah, but isn't that exactly why you have "-f" there? On the
other hand, if $DOTEST exists but for some reason couldn't be
removed, we probably would want to know about it.
$ rm -fr no-such
$ mkdir no-such
$ echo >no-such/file
$ rm -fr no-such
$ mkdir no-such
$ echo >no-such/file
$ chmod a-w no-such
$ rm -fr no-such
rm: cannot remove `no-such/file': Permission denied
^ permalink raw reply
* [PATCH] gitk - Use a spinbox for setting tabstop settings
From: Mark Levedahl @ 2007-06-27 1:51 UTC (permalink / raw)
To: paulus; +Cc: git, Mark Levedahl
In-Reply-To: <11829090952211-git-send-email-mdl123@verizon.net>
The tabstop must be a smallish positive integer, and a spinbox is the
accepted UI control to accomplish this limiting rather than the text
entry box previously used.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index c06d327..2d6a6ef 100755
--- a/gitk
+++ b/gitk
@@ -6972,7 +6972,7 @@ proc doprefs {} {
pack $top.ntag.b $top.ntag.l -side left
grid x $top.ntag -sticky w
label $top.tabstopl -text "tabstop" -font optionfont
- entry $top.tabstop -width 10 -textvariable tabstop
+ spinbox $top.tabstop -from 1 -to 20 -width 4 -textvariable tabstop
grid x $top.tabstopl $top.tabstop -sticky w
label $top.cdisp -text "Colors: press to choose"
--
1.5.2.2.282.g9826
^ permalink raw reply related
* [PATCH] gitk - bugfix - Update selection background colorbar in prefs dialog
From: Mark Levedahl @ 2007-06-27 1:51 UTC (permalink / raw)
To: paulus; +Cc: git, Mark Levedahl
In-Reply-To: <18048.36797.283166.952377@cargo.ozlabs.ibm.com>
The callback function was incorrectly set to update the background
colorbar when updated the selection background. This did not affect the
colors chosen or their use, just their presentation in the preferences
dialog box.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 269f9b0..c06d327 100755
--- a/gitk
+++ b/gitk
@@ -7004,7 +7004,7 @@ proc doprefs {} {
grid x $top.hunksepbut $top.hunksep -sticky w
label $top.selbgsep -padx 40 -relief sunk -background $selectbgcolor
button $top.selbgbut -text "Select bg" -font optionfont \
- -command [list choosecolor selectbgcolor 0 $top.bg background setselbg]
+ -command [list choosecolor selectbgcolor 0 $top.selbgsep background setselbg]
grid x $top.selbgbut $top.selbgsep -sticky w
frame $top.buts
--
1.5.2.2.282.g9826
^ permalink raw reply related
* Re: git-svn error "Unable to extract revision information from commit ...~1"
From: Steven Grimm @ 2007-06-27 1:50 UTC (permalink / raw)
To: Victor Bogado da Silva Lins; +Cc: git
In-Reply-To: <1182884957.16012.31.camel@omicron.ep.petrobras.com.br>
Victor Bogado da Silva Lins wrote:
> The problem seem to be that when I merge the head with another branch
> git-svn does not know where to follow to meet the "svn trunk".
The current release of git-svn doesn't support committing merges. It has
no clue how to walk nonlinear history, as you point out. The current
practice is to do "git merge --squash" when merging into the git-svn
branch that you want to use as the basis for your svn commit. The
--squash option will make git merge the contents of the other branch(es)
but record the resulting tree as a regular commit, not as a merge.
There is a work-in-progress patch which might help you if you need to
preserve merge ancestry on the git side. Search the mailing list
archives for "[PATCH] git-svn: allow dcommit to retain local merge
information" if you want to try it (but be aware that it is just an
initial implementation and may have bugs; it was posted so people could
try it out and report back any problems to the author.)
-Steve
^ permalink raw reply
* Re: Failure in t5516, tests 15 and 16
From: Junio C Hamano @ 2007-06-27 1:44 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List
In-Reply-To: <CFDE3792-403B-4582-B7FB-BC142B79AE63@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Jun 22, 2007, at 10:50 AM, Brian Gernhardt wrote:
>
>> Tests 15 and 16 in script "t5516-fetch-push.sh" fails with "notice:
>> HEAD points to an unborn branch (master)". Is this just bad tests
>> or an actual failure? This is with current master
>> (45fd8bd32dd68ce6b14a406d0abbd6f56490131c) on OS X.
Can you check "cd t && sh -x t5516-fetch-push.sh -i -v"?
I am suspecting that
test "$( cd testrepo && git show-ref | wc -l )" = 1
may have an interesting effect when "wc -l" emits extra
whitespaces. Does this fix it for you?
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 08d58e1..c0fa2ba 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -226,7 +226,7 @@ test_expect_success 'push with colon-less refspec (3)' '
git branch -f frotz master &&
git push testrepo frotz &&
check_push_result $the_commit heads/frotz &&
- test "$( cd testrepo && git show-ref | wc -l )" = 1
+ test 1 = $(cd testrepo && git show-ref | wc -l)
'
test_expect_success 'push with colon-less refspec (4)' '
@@ -239,7 +239,7 @@ test_expect_success 'push with colon-less refspec (4)' '
git tag -f frotz &&
git push testrepo frotz &&
check_push_result $the_commit tags/frotz &&
- test "$( cd testrepo && git show-ref | wc -l )" = 1
+ test 1 = $(cd testrepo && git show-ref | wc -l)
'
^ permalink raw reply related
* Re: Failure in t5516, tests 15 and 16
From: Brian Gernhardt @ 2007-06-27 1:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <4FAE3A62-A0D1-4C88-8413-88F1D75A2730@silverinsanity.com>
On Jun 22, 2007, at 10:50 AM, Brian Gernhardt wrote:
> Tests 15 and 16 in script "t5516-fetch-push.sh" fails with "notice:
> HEAD points to an unborn branch (master)". Is this just bad tests
> or an actual failure? This is with current master
> (45fd8bd32dd68ce6b14a406d0abbd6f56490131c) on OS X.
Okay, I just did used the wonderful "git bisect run" to find out
where this error started happening. The answer appears to be in the
first commit the tests appeared in:
1ed10b886bc69c129c06772ee4310c00e001657f
I dislike that immensely. Can anyone help me figure out why the test
fails? There is no error message printed. I thought the "HEAD
points to an unborn branch" was the error, but that doesn't seem to
be it.
Again, the test results are below.
~~ Brian
----- 8< -----
* expecting success:
mk_test &&
if git show-ref --verify -q refs/tags/frotz
then
git tag -d frotz
fi &&
git branch -f frotz master &&
git push testrepo frotz &&
check_push_result $the_commit heads/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
Initialized empty Git repository in .git/
notice: HEAD points to an unborn branch (master)
notice: No default references
Deleted tag frotz.
updating 'refs/heads/frotz'
from 0000000000000000000000000000000000000000
to 9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
Generating pack...
Done counting 5 objects.
Deltifying 5 objects...
100% (5/5) done
Writing 5 objects...
100% (5/5) done
Total 5 (delta 0), reused 0 (delta 0)
Unpacking 5 objects...
100% (5/5) done
refs/heads/frotz: 0000000000000000000000000000000000000000 ->
9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
notice: HEAD points to an unborn branch (master)
* FAIL 15: push with colon-less refspec (3)
mk_test &&
if git show-ref --verify -q refs/tags/frotz
then
git tag -d frotz
fi &&
git branch -f frotz master &&
git push testrepo frotz &&
check_push_result $the_commit heads/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
* expecting success:
mk_test &&
if git show-ref --verify -q refs/heads/frotz
then
git branch -D frotz
fi &&
git tag -f frotz &&
git push testrepo frotz &&
check_push_result $the_commit tags/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
Initialized empty Git repository in .git/
notice: HEAD points to an unborn branch (master)
notice: No default references
Deleted branch frotz.
updating 'refs/tags/frotz'
from 0000000000000000000000000000000000000000
to 9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
Generating pack...
Done counting 5 objects.
Deltifying 5 objects...
100% (5/5) done
Writing 5 objects...
100% (5/5) done
Total 5 (delta 0), reused 0 (delta 0)
Unpacking 5 objects...
100% (5/5) done
refs/tags/frotz: 0000000000000000000000000000000000000000 ->
9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
notice: HEAD points to an unborn branch (master)
* FAIL 16: push with colon-less refspec (4)
mk_test &&
if git show-ref --verify -q refs/heads/frotz
then
git branch -D frotz
fi &&
git tag -f frotz &&
git push testrepo frotz &&
check_push_result $the_commit tags/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
* failed 2 among 16 test(s)
^ permalink raw reply
* Re: [PATCH 1/3] rebase -i: several cleanups
From: Johannes Schindelin @ 2007-06-27 1:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5tqurrw.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Tue, 26 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Support "--verbose" in addition to "-v", show short names in the list
> > comment, clean up if there is nothing to do, and add several "test_ticks"
> > in the test script.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > git-rebase--interactive.sh | 19 +++++++++++++++----
> > t/t3404-rebase-interactive.sh | 2 ++
> > 2 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index ab36572..b95fe86 100755
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -60,6 +60,11 @@ die_with_patch () {
> > die "$2"
> > }
> >
> > +die_abort () {
> > + rm -rf "$DOTEST" 2> /dev/null
> > + die "$1"
> > +}
>
> Why "2>/dev/null" here?
Just to be sure. If it does not exist, it's no error. No sense alarming
the user.
> > @@ -264,8 +269,11 @@ do
> > echo $ONTO > "$DOTEST"/onto
> > test t = "$VERBOSE" && : > "$DOTEST"/verbose
> >
> > + SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
> > + SHORTHEAD=$(git rev-parse --short $HEAD)
> > + SHORTONTO=$(git rev-parse --short $ONTO)
> > cat > "$TODO" << EOF
> > -# Rebasing $UPSTREAM..$HEAD onto $ONTO
> > +# Rebasing $SHORTUPSTREAM)..$SHORTHEAD onto $SHORTONTO
>
> What is this close-paren about? Is it a typo?
Darn. It _is_ a typo. I overlooked it _both_ when typing _and_ when
looking at the result.
Sorry.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] rebase -i: several cleanups
From: Junio C Hamano @ 2007-06-27 1:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706251856300.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Support "--verbose" in addition to "-v", show short names in the list
> comment, clean up if there is nothing to do, and add several "test_ticks"
> in the test script.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> git-rebase--interactive.sh | 19 +++++++++++++++----
> t/t3404-rebase-interactive.sh | 2 ++
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index ab36572..b95fe86 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -60,6 +60,11 @@ die_with_patch () {
> die "$2"
> }
>
> +die_abort () {
> + rm -rf "$DOTEST" 2> /dev/null
> + die "$1"
> +}
Why "2>/dev/null" here?
> @@ -264,8 +269,11 @@ do
> echo $ONTO > "$DOTEST"/onto
> test t = "$VERBOSE" && : > "$DOTEST"/verbose
>
> + SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
> + SHORTHEAD=$(git rev-parse --short $HEAD)
> + SHORTONTO=$(git rev-parse --short $ONTO)
> cat > "$TODO" << EOF
> -# Rebasing $UPSTREAM..$HEAD onto $ONTO
> +# Rebasing $SHORTUPSTREAM)..$SHORTHEAD onto $SHORTONTO
What is this close-paren about? Is it a typo?
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: Junio C Hamano @ 2007-06-27 1:05 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: GIT
In-Reply-To: <7vmyyq2zrz.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@bluebottle.com> writes:
> ...
>> + 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
>> + ) )
> ...
> - 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.
I would like to take the last part of the sentence back.
I do not think "git add ." makes much sense. The only case that
"add ." vs "add -u" may make a difference is the files that are
so new to your working tree that you haven't even added them to
the index. But they would not be in your current HEAD, and they
would not have been added in the commit you are pulling, and if
that is not the case, git-merge would complain and bail out as
usual anyway. I replied to your other message with something
about ".gitignore", but not everybody uses "ignore" mechanism
effectively, and "git add ." indeed would end up sucking all the
irrelevent cruft to w_tree for them, only to be extracted back
(because HEAD, i_tree and whichever commit you will later be
applying the stash to are not likely to have them). Maybe we
could argue that those people with nonoptimal "ignore" list
deserve it, but I do not think it is worth the potential added
aggravation.
By the way, I initially liked the clever use of a single commit
that records the three trees in it, but now I am beginning to
really hate it. I am suspecting that the primary reason you did
it that way was to reduce the number of commit objects used for
this purpose. I personally do not think it is something we
would want to optimize for.
I think it would make much more sense to represent a stash like
this:
.------o commit to represent index state
/ \
---o---o----------o
HEAD commit to represent worktree state
That is, "index" and "worktree" state are represented as one
commit each, both are direct child of the HEAD, with an added
twist of the latter being also a child of the former.
This has an interesting side effect that I can do this:
$ git show stash
to view what was in HEAD, index and working tree at the same
time (you can use "git stash show" to view the changes between
HEAD and worktree as before).
Being able to view this "evil merge" (this is a deliberately
evil merge, as you typically have huge differences between the
index and worktree when you need to stash) may not be that
interesting in the real life, but I think this is a good
demonstration of the reason why it is better to use more
straightforward ancestry structure to represent the stash. By
not using a custom tree structure that is only understood by
"git stash", the user can use existing tools that operate on
normal ancestry chains.
>> ...
>> + 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....
I now think "git reset --hard" here is fine.
^ permalink raw reply
* Re: Fix zero-object version-2 packs
From: Junio C Hamano @ 2007-06-27 0:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Tjernlund
In-Reply-To: <alpine.LFD.0.98.0706261428420.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> A pack-file can get created without any objects in it (to transfer "no
> data" - which can happen if you use a reference git repo, for example,
> or just otherwise just end up transferring only branch head information
> and already have all the objects themselves).
>
> And while we probably should never create an index for such a pack, if we
> do (and we do), the index file size sanity checking was incorrect.
>
> This fixes it.
>
> Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
>
> Tjernlund <tjernlund@tjernlund.se> wrote:
>>
>> [SNIP patch]
>>
>> Tested your patch and the error went away, many thanks
Thank you very much to both of you. Will be in 'maint'.
^ permalink raw reply
* Re: Mark Levedahl's gitk patches
From: Junio C Hamano @ 2007-06-27 0:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Mark Levedahl, Johannes Sixt, git
In-Reply-To: <18048.36797.283166.952377@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Mark Levedahl writes:
>
>> I found a bug in the highlight patch (the color picker updated the wrong
>> panel in the chooser but did set the correct color), and updated the
>> tab-stop patch to use a spin control to enforce entry of small integers
>> only. As there is possible interest, I am sending the amended series.
>
> Ah. I just pushed out a pile of patches to gitk.git including your
> three. Could you do an incremental patch on top of that for me?
I took a look at differences between your gitk.git and what I
have. It appears that our "proc readrefs" differ a bit.
Most notably, the global hash tagcontents is read when readrefs
run in the version I have, while gitk.git version fills it
lazily in showtag, where it is actually used. Because you read
the refs using "show-ref -d", you do not need to do extra forks
to figure out the objects referred to by the tags in your code.
I think what you have is a lot better from interactive latency
point of view. I'll take the version from gitk.git and push the
results out.
^ 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