* Re: [PATCH] git-mailinfo may corrupt patch headers on attached files
From: Linus Torvalds @ 2008-07-06 21:52 UTC (permalink / raw)
To: Don Zickus; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1215379261-10802-1-git-send-email-dzickus@redhat.com>
On Sun, 6 Jul 2008, Don Zickus wrote:
>
> I noticed this the other day, just never got a chance to send the fix out.
> This might be the same problem I ran into.
Ack. This patch does indeed seem to fix the test-case I had. Thanks,
Linus
^ permalink raw reply
* [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-06 21:22 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
This makes rebase act a little more like merge when working on the
current branch. This is particularly useful for `git pull --rebase`
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
ARG! This is what v3 was supposed to be. I should make sure I am sending in
the correct patch. (Tip: run format-patch again after a commit --amend.) Bad
weekend for me, apparently trying to do too many things at once. Sorry for
all the noise.
To recap:
If I followed the discussion correctly the first time I sent in this patch,
the two issues were:
- Ugly "echo > ORIG_HEAD" instead of pretty "git update-ref ORIG_HEAD"
- Setting ORIG_HEAD at the wrong place
This version (as opposed to v2, or the embarrassingly identital "v3") uses
the correct variable. $orig_head looks like the right name, but it stores the
branch. $prev_head stores the actual SHA1, which is what I was looking for.
git-rebase.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..1048f7e 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -434,3 +434,4 @@ do
done
finish_rb_merge
+git update-ref ORIG_HEAD $prev_head
--
1.5.6.2.348.gcff8f.dirty
^ permalink raw reply related
* [PATCH] git-mailinfo may corrupt patch headers on attached files
From: Don Zickus @ 2008-07-06 21:21 UTC (permalink / raw)
To: git; +Cc: torvalds, Don Zickus
In-Reply-To: <alpine.LFD.1.10.0807061036500.3016@woody.linux-foundation.org>
Boundary lines in emails are treated as a special case. As a result of
processing the boundary line a new line will be read into the buffer.
The string length variable 'len' is evaluated before the boundary case, thus
there is the possibility the length of the string does not match the new
line read in (in the boundary line case). This causes a partial output of
the line to the patch file.
The fix is trivial, evaluate the length of the string right before
processing it.
Signed-off-by: Don Zickus <dzickus@redhat.com>
---
I noticed this the other day, just never got a chance to send the fix out.
This might be the same problem I ran into.
Cheers,
Don
builtin-mailinfo.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 2894e34..cedda18 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -795,7 +795,7 @@ static void handle_body(void)
int rc = 0;
static char newline[2000];
static char *np = newline;
- int len = strlen(line);
+ int len;
/* Skip up to the first boundary */
if (content_top->boundary) {
@@ -814,6 +814,9 @@ static void handle_body(void)
return;
}
+ /* line may have changed after handling boundary, check len */
+ len = strlen(line);
+
/* Unwrap transfer encoding */
len = decode_transfer_encoding(line, sizeof(line), len);
if (len < 0) {
--
1.5.6.rc2.48.g13da
^ permalink raw reply related
* [PATCH v2] Add a test for "git stash branch"
From: Abhijit Menon-Sen @ 2008-07-06 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <7v1w26eqn5.fsf@gitster.siamese.dyndns.org>
Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
At 2008-07-06 12:53:02 -0700, gitster@pobox.com wrote:
>
> The title is probably not 'stash apply' but 'stash branch'.
Fixed, thanks.
> Don't you want to also validate that: [...]
Done.
-- ams
t/t3903-stash.sh | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..bd1cdab 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,65 @@ test_expect_success 'stash pop' '
test 0 = $(git stash list | wc -l)
'
+cat > expect << EOF
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..1fe912c
+--- /dev/null
++++ b/file2
+@@ -0,0 +1 @@
++bar2
+EOF
+
+cat > expect1 << EOF
+diff --git a/file b/file
+index 257cc56..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-foo
++bar
+EOF
+
+cat > expect2 << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..1fe912c
+--- /dev/null
++++ b/file2
+@@ -0,0 +1 @@
++bar2
+EOF
+
+test_expect_success 'stash branch' '
+ echo foo > file &&
+ git commit file -m first
+ echo bar > file &&
+ echo bar2 > file2 &&
+ git add file2 &&
+ git stash &&
+ echo baz > file &&
+ git commit file -m second &&
+ git stash branch stashbranch &&
+ test refs/heads/stashbranch = $(git symbolic-ref HEAD) &&
+ test $(git rev-parse HEAD) = $(git rev-parse master^) &&
+ git diff --cached > output &&
+ test_cmp output expect &&
+ git diff > output &&
+ test_cmp output expect1 &&
+ git add file &&
+ git commit -m alternate\ second &&
+ git diff master..stashbranch &&
+ git diff master..stashbranch > output &&
+ test_cmp output expect2 &&
+ test 0 = $(git stash list | wc -l)
+'
+
test_done
--
1.5.6
^ permalink raw reply related
* Re: Commit message for 1240f94 has mail headers
From: Miklos Vajna @ 2008-07-06 21:19 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List
In-Reply-To: <2C6B8E28-3E8A-414E-9DB7-626E9709C831@silverinsanity.com>
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
On Sun, Jul 06, 2008 at 04:00:23AM -0400, Brian Gernhardt <benabik@silverinsanity.com> wrote:
> I don't think all those mail headers are supposed to be in there. I don't
> know if it's too late to fix that, but I thought you should know.
My fault, I noticed it but I forgot to send a reminder about it before
it hit next.
Sorry.
(I suppose it won't be fixed, unless merge-in-c won't hit master before
1.6.0, which is hopefully unlikely. ;-) )
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git/refs/heads/master was not found in commit?
From: Nathan Kontny @ 2008-07-06 20:53 UTC (permalink / raw)
To: git
I'm a newb to git. I'm trying to "git svn clone" a tried and true
subversion repo but it fails after scanning
the 2069 commit, and spits out:
vendor/plugins/locking/.git/refs/heads/master was not found in commit
484775a7dc66b9c91188a5ad52c30c371ff8d702 (r2068)
Which is right. It isn't in 2068, it was checked in at 2069.
The 2069 commit was some code I had "git clone"d from github into a
subfolder of the parent project
that's checked into subversion. I've tried to replicate this behavior
by checking in this same git repo into a
smaller svn repo and doing the git svn clone, but alas that time it's
successful.
Anyone have any ideas how I can get around this? Thank you!
^ permalink raw reply
* Re: [HACK] t/test-lib.sh HACK: Add -s/--show-hack to test suite.
From: Johannes Schindelin @ 2008-07-06 20:41 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <1215375751-30853-1-git-send-email-s-beyer@gmx.net>
Hi,
On Sun, 6 Jul 2008, Stephan Beyer wrote:
> This option realizes a stupid hack that tries to run the test
> cases line by line (separated by &&).
In what way is that better than "sh -x t????-*.sh"?
Ciao,
Dscho
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Dmitry Potapov @ 2008-07-06 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Ingo Molnar, git
In-Reply-To: <7vprpqdbjx.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 06, 2008 at 01:04:18PM -0700, Junio C Hamano wrote:
> Two other shorthands for naming a set that is formed by a commit
> and its parent commits exists. `r1{caret}@` notation means all
> parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
> its all parents.
So, I would say that rev^! is shorthand for rev^@..rev, but it does not
actually work:
git rev-list 7ac749c^@..7ac749c
fatal: ambiguous argument '7ac749c^@..7ac749c': unknown revision or path
not in the working tree.
yet "^rev^@ rev" syntax does:
git rev-list ^7ac749c^@ 7ac749c
7ac749c96d143ba4f76723959892cbaddbe8ed07
Is it a bug or feature?
Puzzled...
Dmitry
^ permalink raw reply
* [PATCH] Fix grammar in git-rev-parse(1).
From: Mikael Magnusson @ 2008-07-06 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
---
Documentation/git-rev-parse.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 59e95ad..ba65bfa 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -301,9 +301,9 @@ It is the set of commits that are reachable from
either one of
`r1` or `r2` but not from both.
Two other shorthands for naming a set that is formed by a commit
-and its parent commits exists. `r1{caret}@` notation means all
+and its parent commits exist. The `r1{caret}@` notation means all
parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
-its all parents.
+all of its parents.
Here are a handful of examples:
--
1.5.6.GIT
2008/7/6 Junio C Hamano <gitster@pobox.com>:
> "Dmitry Potapov" <dpotapov@gmail.com> writes:
>
>> On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is
>>> documented anywhere, though),
>>
>> The latter is not exactly a shortcut for the former. You can try it at any
>> merge commit, and you will see different log. For instance, in Git repo:
>> ...
>> So, I believe, rev^! means --first-parent rev^..rev
>
> Not quite. From Documentation/git-rev-parse.txt:
>
> SPECIFYING RANGES
> -----------------
>
> Two other shorthands for naming a set that is formed by a commit
> and its parent commits exists. `r1{caret}@` notation means all
> parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
> its all parents.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Mikael Magnusson
^ permalink raw reply related
* [HACK] t/test-lib.sh HACK: Add -s/--show-hack to test suite.
From: Stephan Beyer @ 2008-07-06 20:22 UTC (permalink / raw)
To: git; +Cc: Stephan Beyer
This option realizes a stupid hack that tries to run the test
cases line by line (separated by &&).
Furthermore it shows the line it is testing.
With that information it is easier to find the reason
why a test fails.
This hack works as long as there are no multi-line
for/while/subshell/... in the test cases.
Note, that the -s option should only be used if a test case failed.
It is slow and error-prone.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi,
I wrote that before I started to make the sequencer prototype and
then I used this hack more than expected ;-)
Today I cherry-picked this commit into another branch and then
I thought this could be useful for others, too.
(Explicitly not for inclusion!)
So how to use it?
When running a test case in t/, add the -s option and then it shows
something like this:
--snip--[...]
-------
Testing:
! test -d "$SEQDIR"
-------
Testing:
session_ok
* FAIL 3: "pick", "squash", "ref" from stdin
next_session squashCE &&
valgrind git sequencer <todotest1 &&
! test -d "$SEQDIR" &&
session_ok &&
test -f file2 &&
test -f file3 &&
test $(git rev-parse CE) = $(git rev-parse HEAD) &&
test $(git rev-parse I) = $(git rev-parse HEAD^)
--snap--
Because of the "Testing:" lines you can explicitly see where it failed.
Regards,
Stephan
t/test-lib.sh | 45 +++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c0c5e0e..6f42106 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -86,6 +86,8 @@ do
help=t; shift ;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t; shift ;;
+ -s|--show-hack)
+ verbose=t; show_hack=t; immediate=t; shift ;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=t; shift ;;
--no-color)
@@ -225,9 +227,48 @@ test_debug () {
test "$debug" = "" || eval "$1"
}
-test_run_ () {
- eval >&3 2>&4 "$1"
+test_run__ () {
+ eval "$1"
eval_ret="$?"
+}
+
+test_run_op_ () {
+ echo "Testing:"
+ printf "%s\n" "$op_"
+ echo
+ eval "$op_"
+ eval_ret="$?"
+}
+
+test_run_hack_ () {
+ i_=1
+ j_=1
+ total_=$(printf '%s' "$1" | wc -l)
+ while test "$j_" -lt $(expr "$total_" + 1)
+ do
+ op_=$(printf '%s' "$1" | sed -n -e "$i_,$j_ p")
+ if test -n "$(printf '%s' "$op_" | sed -n -e '/<<[-\\ A-Za-z]/q;/&& *$/p;')"
+ then
+ i_=$(expr "$j_" + 1)
+ op_=$(printf '%s' "$op_" | sed -e 's/ *&& *$//')
+ test_run_op_
+ test "$eval_ret" -ne 0 && return 0
+ echo -------
+ fi
+ j_=$(expr "$j_" + 1)
+ done
+ op_="$(printf '%s' "$1" | sed -n -e "$i_,$j_ p")"
+ test_run_op_
+ return 0
+}
+
+test_run_ () {
+ if test -z "$show_hack"
+ then
+ test_run__ >&3 2>&4 "$1"
+ else
+ test_run_hack_ >&3 2>&4 "$1"
+ fi
return 0
}
--
1.5.6.363.g7ba71
^ permalink raw reply related
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Junio C Hamano @ 2008-07-06 20:04 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Jakub Narebski, Ingo Molnar, git
In-Reply-To: <37fcd2780807060916h7d8c4e6mba7f30570d527dc3@mail.gmail.com>
"Dmitry Potapov" <dpotapov@gmail.com> writes:
> On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is
>> documented anywhere, though),
>
> The latter is not exactly a shortcut for the former. You can try it at any
> merge commit, and you will see different log. For instance, in Git repo:
> ...
> So, I believe, rev^! means --first-parent rev^..rev
Not quite. From Documentation/git-rev-parse.txt:
SPECIFYING RANGES
-----------------
Two other shorthands for naming a set that is formed by a commit
and its parent commits exists. `r1{caret}@` notation means all
parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
its all parents.
^ permalink raw reply
* Re: [PATCH] Add a test for "git stash branch"
From: Junio C Hamano @ 2008-07-06 19:53 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <20080706144542.GA8677@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> writes:
> At 2008-07-06 14:54:44 +0200, Johannes.Schindelin@gmx.de wrote:
>>
>> AFAICS the previous version is in 'next' already:
>> 656b50345239293929ad8c639c5f1941c6b867ad
>
> Oh, I see, thanks. I misunderstood the request. Here's a separate patch
> to just add the test.
Oh, there is no misunderstanding. You couldn't have possibly known if the
main body of the patch will go to 'next' or just be dropped when I said
"you might also want to have tests" to you.
> +test_expect_success 'stash apply' '
> + echo foo > file &&
> + git commit file -m first
> + echo bar > file &&
> + git stash &&
> + echo baz > file &&
> + git commit file -m second &&
> + git stash branch stashbranch &&
> + git commit file -m alternate\ second &&
> + git diff master..stashbranch > output &&
> + test_cmp output expect &&
> + test 0 = $(git stash list | wc -l)
> +'
The title is probably not 'stash apply' but 'stash branch'. Don't you
want to also validate that:
- "stash branch" command switched to the new branch "stashbranch"?
- before making "alternate second", the index and the working tree have
expected contents? and
- the final shape of the history looks correctly forked (i.e.
"stashbranch" branches at the commit before "-m second" commit was
made)?
> test_done
> --
> 1.5.6
^ permalink raw reply
* Re: [PATCH 14/14] Build in merge
From: Junio C Hamano @ 2008-07-06 19:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, git, Olivier Marin
In-Reply-To: <alpine.LSU.1.00.0807061433480.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But given that you seem so sick and tired of string_list, and rather have
> a code duplication, I will not argue to that end anymore.
You are probably very confused if you think I am saying I'd rather have
duplication.
Look at "unsorted_path_list_lookup()" in builtin-merge.c and think again.
Look at "path_list_append_strategy()" in builtin-merge.c and think again.
If you are adding the same amount of code _anyway_, why not write using
more appropriate data structure for the job?
The path_list has its uses. It's wonderful when you have existing
structures that you would need to keep in core anyway and being able to
look them up via string keys. But that does not mean it is (nor should be
"improved" to be) a good match for other forms of (ab)uses.
The way it was used by initializing with pointer to a static array
location is clearly a misuse. When using ->util field to store things
other than pointers to preexisting structures, the use of the API becomes
clunky and we discussed this issue about another patch. That's all I was
saying.
^ permalink raw reply
* [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Gerrit Pape @ 2008-07-06 19:28 UTC (permalink / raw)
To: git, Eric Wong
With subversion 1.5.0 (C and perl libraries) the git-svn selftest
t9101-git-svn-props.sh fails at test 25 and 26. The following commands
cause assertions in the svn library
$ cd deeply
$ git-svn propget svn:ignore .
perl: /build/buildd/subversion-1.5.0dfsg1/subversion/libsvn_ra/ra_loader.c:674: svn_ra_get_dir: Assertion `*path != '/'' failed.
Aborted
$ git-svn propget svn:ignore ..
perl: /build/buildd/subversion-1.5.0dfsg1/subversion/libsvn_subr/path.c:120: svn_path_join: Assertion `is_canonical(component, clen)' failed.
With this commit, git-svn makes sure the path doesn't start with a
slash, and is not a dot, working around these assertions.
The breakage was reported by Lucas Nussbaum through
http://bugs.debian.org/489108
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-svn.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
I ran into this on Debian/unstable. With svn 1.5.0 the selftest fails
without the patch, with svn 1.4.6 it succeeds with and without the
patch. I'm not familar with the svn interfaces, not sure whether this
is a regression in subversion, or a bug in git-svn.
diff --git a/git-svn.perl b/git-svn.perl
index f789a6e..a366c89 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -643,6 +643,8 @@ sub canonicalize_path {
$path =~ s#/[^/]+/\.\.##g;
$path =~ s#/$##g;
$path =~ s#^\./## if $dot_slash_added;
+ $path =~ s#^/##;
+ $path =~ s#^\.$##;
return $path;
}
--
1.5.6
^ permalink raw reply related
* Re: About -X<option>
From: Junio C Hamano @ 2008-07-06 19:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pieter de Bie, Miklos Vajna, git
In-Reply-To: <alpine.LSU.1.00.0807061315310.32725@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> By allowing users to put a script in their PATH (possibly resorting to "."
> just for that script), named "git-merge-<mybackend>", the following
> becomes possible:
>
> $ echo 'git merge-recursive --theirs "$@"' > ~/bin/git-merge-X
> $ chmod a+x ~/bin/git-merge-X
> $ git merge -s X
>
> This would be even more flexible than the "-X" option, and it would
> properly keep "--theirs" out of our officially supported features.
The above "custom backend" is fine, and would be useful for _other_ things
(That's why I invented "-s" option to "git-merge" to begin with). The sad
part is that it does not have much to do with a solution about -X<option>
issue.
Imagine you want to enhance the recursive strategy so that the user can
tweak the similarity threashold used in the rename detection. You would
want to pass the equilvalent of -M<similarity> to the strategy backend
through "git merge". You could use millions of such custom merge backend
to do so:
$ echo 'git merge-recursive -M2 "$@"' >~/bin/git-merge-M2
$ echo 'git merge-recursive -M4 "$@"' >~/bin/git-merge-M4
$ echo 'git merge-recursive -M6 "$@"' >~/bin/git-merge-M6
$ ... millions of these ...
$ git merge -s M09
but that's not a solution. You are kuldging around the issue by punting
and by not solving it (iow "I did not have forsight to allow passing
options through git-merge, and as consequence, the users are forced to
have canned set of options in their backend"). You have the same issue
with "-Xsubtree=git-gui/", for example.
Being able to pick strategy backend is wonderful, and being able to define
new ones is also wonderful. But that is unrelated to what we are
discussing here. Don't confuse the issue.
I am not married to -X<option> notation. Perhaps we can borrow the way
"gcc" does this, when allowing linker and assmebler options to be passed
from the command line to the backend with -Wa,<option> and -Wl,<option>.
The issue being addressed with these notation is exactly the same as what
we are discussing, and we can follow the same model. The intermediary
(gcc and git-merge) does not have to fully understand what the option they
are passing to the backend (assembler and merge-* strategy).
^ permalink raw reply
* Re: [PATCH] fix "git-submodule add a/b/c/repository"
From: Mark Levedahl @ 2008-07-06 19:05 UTC (permalink / raw)
To: Sylvain Joyeux; +Cc: Junio C Hamano, Lars Hjemli, Ping Yin, git
In-Reply-To: <20080706161101.GB23385@jhaampe.org>
Sylvain Joyeux wrote:
> git submodule add init dir0/dir1/init
>
> Would clone dir0/dir1/init at ./init and add ./init as a submodule. This is
> actually what the current git-submodule (wrongly) does.
>
> Sylvain
>
...after some prep work...
>git submodule add init dir0/dir1/init
Adding existing repo at 'dir0/dir1/init' to the index
So, what's the problem?
Mark
^ permalink raw reply
* Re: error: unlink(.git/refs/remotes/origin/testbranch) failed: was remote does not support deleting refs
From: Dmitry Potapov @ 2008-07-06 18:34 UTC (permalink / raw)
To: Martin; +Cc: git
In-Reply-To: <48700FC2.8080307@gmx.de>
Hi,
[please do not top post]
On Sun, Jul 06, 2008 at 02:20:18AM +0200, Martin wrote:
>_
> But I get another error:
> $ git push origin :testbranch
> To ssh://myserver.com/my/path/to/repository
> - [deleted] testbranch
> error: unlink(.git/refs/remotes/origin/testbranch) failed: No such file_
> or directory
> error: Failed to delete
>_
> Any idea?
It is harmless. It is just that "git push origin :refs/heads/testbranch"
cannot remove your local reference to that branch because you already have
removed it by running "git branch -d -r origin/testbranch"
Normally you just run "git push origin :refs/heads/testbranch" without
"git branch -d -r origin/testbranch" and then you will not have this error.
Dmitry
^ permalink raw reply
* 'git am' breakage with MIME decoding
From: Linus Torvalds @ 2008-07-06 17:47 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1979 bytes --]
Ok, so I generally try to avoid MIME-encoded emails because my old legacy
tools didn't handle them, but since 'git am' is supposed to be able to
handle them, I just tried one. And it failed.
Un-encoding them in the email client and then re-doing the thing worked
fine, so it's definitely related to the MIME-decoding somehow.
I'm attaching both versions of the email so people can test it out (it
applies to v2.6.26-rc9 of the kernel), but the behaviour in short is that
the plain version (ie the one where I used my MUA to "export" the email
without MIME crud) results in the correct:
commit 97f8571e663c808ad2d01a396627235167291556
Author: Philipp Zabel <philipp.zabel@gmail.com>
Date: Sun Jul 6 01:15:34 2008 +0200
pxamci: fix byte aligned DMA transfers
The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.
...
while the MIME-encoded version results in
commit 92cdd47753abc9a6f1b8d96fedcbb5ed88b5ab57
Author: Pierre Ossman <drzeus-list@drzeus.cx>
Date: Sun Jul 6 01:15:34 2008 +0200
pxamci: fix byte aligned DMA transfers
F
The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.
...
ie notice how the "From: Philipp Zabel <philipp.zabel@gmail.com>" got
corrupted somehow. It was apparently _partially_ recognized and removed,
but it left the 'F' around, and probably because of the partial removal it
then didn't get recognized as the author, so the original email sender
(Pierre) got credit.
This is with a git version as of five minutes ago: v1.5.6.2-220-g44701c6.
Any ideas? I have not looked at it at all, since I'm not a fan of MIME,
and didn't have anything to do with the MIME-decoding code.
Linus
[-- Attachment #2: Type: TEXT/PLAIN, Size: 5661 bytes --]
From torvalds@linux-foundation.org Sat Jul 5 16:17:53 2008 -0700
Return-Path: <drzeus-list@drzeus.cx>
Received: from woody.linux-foundation.org (woody.linux-foundation.org [127.0.0.1])
by woody.linux-foundation.org (8.14.2/8.14.2) with ESMTP id m65NHrMl003556
for <torvalds@localhost>; Sat, 5 Jul 2008 16:17:53 -0700
Received: from imap1.linux-foundation.org [140.211.169.55]
by woody.linux-foundation.org with IMAP (fetchmail-6.3.8)
for <torvalds@localhost> (single-drop); Sat, 05 Jul 2008 16:17:53 -0700 (PDT)
Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13])
by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id m65NGNAD010669
for <torvalds@imap1.linux-foundation.org>; Sat, 5 Jul 2008 16:16:23 -0700
Received: from smtp.drzeus.cx (server.drzeus.cx [85.8.24.28])
by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id m65NFhCI026377
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <torvalds@linux-foundation.org>; Sat, 5 Jul 2008 16:15:46 -0700
Received: from mjolnir.drzeus.cx (wlan248.drzeus.cx [::ffff:10.8.2.248])
(AUTH: LOGIN drzeus, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by smtp.drzeus.cx with esmtp; Sun, 06 Jul 2008 01:15:39 +0200
id 0000000000128003.000000004870009B.00003DBE
Date: Sun, 6 Jul 2008 01:15:34 +0200
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Philipp Zabel <philipp.zabel@gmail.com>,
Stable branch <stable@kernel.org>
Subject: [PATCH] pxamci: fix byte aligned DMA transfers
Message-ID: <20080706011534.6dc71f5a@mjolnir.drzeus.cx>
X-Mailer: Claws Mail 3.4.0 (GTK+ 2.13.3; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=PGP-SHA1; boundary="=_freyr.drzeus.cx-15806-1215299739-0001-2"
Received-SPF: none (domain of drzeus-list@drzeus.cx does not designate permitted sender hosts)
X-Spam-Status: No, hits=-6.02 required=5 tests=AWL,BAYES_00,OSDL_HEADER_SUBJECT_BRACKETED,PATCH_SUBJECT_OSDL
X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__
X-MIMEDefang-Filter: lf$Revision: 1.188 $
X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13
X-IMAPbase: 1215365788 1
Status: RO
X-Status:
X-Keywords:
X-UID: 1
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--=_freyr.drzeus.cx-15806-1215299739-0001-2
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
From: Philipp Zabel <philipp.zabel@gmail.com>
The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.
For performance reasons all scatter-gather addresses passed to
pxamci_request should be aligned on 8-byte boundaries, but if
this can't be guaranteed, byte aligned DMA transfers in the
have to be enabled in the controller to get correct behaviour.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
---
drivers/mmc/host/pxamci.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index 65210fc..d89475d 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxamci_host *host,=
struct mmc_data *data)
unsigned int nob =3D data->blocks;
unsigned long long clks;
unsigned int timeout;
+ bool dalgn =3D 0;
u32 dcmd;
int i;
=20
@@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxamci_host *host,=
struct mmc_data *data)
host->sg_cpu[i].dcmd =3D dcmd | length;
if (length & 31 && !(data->flags & MMC_DATA_READ))
host->sg_cpu[i].dcmd |=3D DCMD_ENDIRQEN;
+ /* Not aligned to 8-byte boundary? */
+ if (sg_dma_address(&data->sg[i]) & 0x7)
+ dalgn =3D 1;
if (data->flags & MMC_DATA_READ) {
host->sg_cpu[i].dsadr =3D host->res->start + MMC_RXFIFO;
host->sg_cpu[i].dtadr =3D sg_dma_address(&data->sg[i]);
@@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxamci_host *host=
, struct mmc_data *data)
host->sg_cpu[host->dma_len - 1].ddadr =3D DDADR_STOP;
wmb();
=20
+ /*
+ * The PXA27x DMA controller encounters overhead when working with
+ * unaligned (to 8-byte boundaries) data, so switch on byte alignment
+ * mode only if we have unaligned data.
+ */
+ if (dalgn)
+ DALGN |=3D (1 << host->dma);
+ else
+ DALGN &=3D (1 << host->dma);
DDADR(host->dma) =3D host->sg_dma;
DCSR(host->dma) =3D DCSR_RUN;
}
--=20
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
--=_freyr.drzeus.cx-15806-1215299739-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkhwAJsACgkQ7b8eESbyJLjDpwCgyde8Uz/u6iHD5/JwFyH6r8hA
dvQAoMH38ZvMg355D4R0jXmUXYfJzJds
=YuR1
-----END PGP SIGNATURE-----
--=_freyr.drzeus.cx-15806-1215299739-0001-2--
[-- Attachment #3: Type: TEXT/PLAIN, Size: 2964 bytes --]
From drzeus-list@drzeus.cx Sat Jul 5 16:17:53 2008
Date: Sun, 6 Jul 2008 01:15:34 +0200
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Philipp Zabel <philipp.zabel@gmail.com>, Stable branch <stable@kernel.org>
Subject: [PATCH] pxamci: fix byte aligned DMA transfers
From: Philipp Zabel <philipp.zabel@gmail.com>
The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.
For performance reasons all scatter-gather addresses passed to
pxamci_request should be aligned on 8-byte boundaries, but if
this can't be guaranteed, byte aligned DMA transfers in the
have to be enabled in the controller to get correct behaviour.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
---
drivers/mmc/host/pxamci.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index 65210fc..d89475d 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxamci_host *host, struct mmc_data *data)
unsigned int nob = data->blocks;
unsigned long long clks;
unsigned int timeout;
+ bool dalgn = 0;
u32 dcmd;
int i;
@@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxamci_host *host, struct mmc_data *data)
host->sg_cpu[i].dcmd = dcmd | length;
if (length & 31 && !(data->flags & MMC_DATA_READ))
host->sg_cpu[i].dcmd |= DCMD_ENDIRQEN;
+ /* Not aligned to 8-byte boundary? */
+ if (sg_dma_address(&data->sg[i]) & 0x7)
+ dalgn = 1;
if (data->flags & MMC_DATA_READ) {
host->sg_cpu[i].dsadr = host->res->start + MMC_RXFIFO;
host->sg_cpu[i].dtadr = sg_dma_address(&data->sg[i]);
@@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxamci_host *host, struct mmc_data *data)
host->sg_cpu[host->dma_len - 1].ddadr = DDADR_STOP;
wmb();
+ /*
+ * The PXA27x DMA controller encounters overhead when working with
+ * unaligned (to 8-byte boundaries) data, so switch on byte alignment
+ * mode only if we have unaligned data.
+ */
+ if (dalgn)
+ DALGN |= (1 << host->dma);
+ else
+ DALGN &= (1 << host->dma);
DDADR(host->dma) = host->sg_dma;
DCSR(host->dma) = DCSR_RUN;
}
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[ Part 2, Application/PGP-SIGNATURE (Name: "signature.asc") 204 bytes. ]
[ Unable to print this part. ]
^ permalink raw reply related
* Re: [PATCH] better git-submodule status output
From: Sylvain Joyeux @ 2008-07-06 16:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Lars Hjemli, Ping Yin, Mark Levedahl, git
In-Reply-To: <alpine.LSU.1.00.0807061456100.3486@wbgn129.biozentrum.uni-wuerzburg.de>
> > Which one is the commit message ;-)?
>
> I think it is clear that Sylvain has not read
> Documentation/SubmittingPatches yet.
Sylvain *has* read SubmittingPatches but has not understood every detail of this
very long document.
If you could enlighten me on what is wrong ...
> > People who rely on working submodule support, do you have any feedback
> > on this patch?
>
> Not yet. Will test/comment when the spurious "fetch" is fixed.
I thought that the only thing that 'fetch' does is update FETCH_HEAD. My problem
is that doing the fetch is the only way to know what is the status of the
submodule w.r.t. the registered commit. If you have a better way to get that
information, I'm all ears :P
--
Sylvain
^ permalink raw reply
* Re: [PATCH] fix "git-submodule add a/b/c/repository"
From: Sylvain Joyeux @ 2008-07-06 16:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Ping Yin, Mark Levedahl, git
In-Reply-To: <7vd4lro7ct.fsf@gitster.siamese.dyndns.org>
> > +test_expect_success 'adding an already-existing repository deep in the directory hierarchy' '
> > +
> > + mkdir dir0 &&
> > + mkdir dir0/dir1 &&
> > + git clone init dir0/dir1/init &&
> > + git-submodule add dir0/dir1/init &&
> > + git-submodule status | grep "dir0/dir1/init"
> > +'
>
> I am not sure if this is fixing a sane use case. "submodule add" is
> documented to take:
>
> 'git submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
>
> and you are adding at dir0/dir1/init a submodule that will interact with "init"
> repository, so shouldn't that command line be something like:
>
> git submodule add init dir0/dir1/init
git submodule add dir0/dir1/init
Is supposed to add the repository already checked-out in dir0/dir1/init as a
submodule, at the same location.
git submodule add init dir0/dir1/init
Would clone dir0/dir1/init at ./init and add ./init as a submodule. This is
actually what the current git-submodule (wrongly) does.
Sylvain
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-06 16:29 UTC (permalink / raw)
To: Sylvain Joyeux; +Cc: Junio C Hamano, Lars Hjemli, Ping Yin, Mark Levedahl, git
In-Reply-To: <20080706160758.GA23385@jhaampe.org>
Hi,
On Sun, 6 Jul 2008, Sylvain Joyeux wrote:
> > > Which one is the commit message ;-)?
> >
> > I think it is clear that Sylvain has not read
> > Documentation/SubmittingPatches yet.
>
> Sylvain *has* read SubmittingPatches but has not understood every detail
> of this very long document.
Oh. But you should have already seen on this list that almost everybody
puts the oneline as subject, the commit message as first part of the mail
body, then a "--", optionally some personal stuff that should not go into
the commit message, and then the diffstat and all the rest.
IOW the mail body should look like the output of format-patch, optionally
some comments between "--" and the diffstat.
Write a patch for SubmittingPatches.
> > If you could enlighten me on what is wrong ...
>
> > > People who rely on working submodule support, do you have any
> > > feedback on this patch?
> >
> > Not yet. Will test/comment when the spurious "fetch" is fixed.
>
> I thought that the only thing that 'fetch' does is update FETCH_HEAD.
Uhoh. 'fetch' fetches. Which means it does not only update something.
> My problem is that doing the fetch is the only way to know what is the
> status of the submodule w.r.t. the registered commit. If you have a
> better way to get that information, I'm all ears :P
Are you sure that you understand the submodule thing enough to patch
git-submodule?
There are three states that are interesting:
- the committed submodule state:
You get this in the superproject by "git ls-tree HEAD -- <dir>"
- the local HEAD of the submodule:
(cd "<dir>" && git rev-parse --verify HEAD)
- the HEAD of the default branch of the upstream repository of the
submodule:
(cd "<dir>" && git ls-remote origin HEAD)
NOTE: this does not have to do _anything_ with the submodule: you can
easily have two independent branches (see "html" and "next" in git.git),
and the submodule is free to be pinned to whatever commit is available
in the upstream repository.
It is even possible that it is pinned to a commit that is only reachable
from a tag, not from a branch.
Hth,
Dscho
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Dmitry Potapov @ 2008-07-06 16:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ingo Molnar, git
In-Reply-To: <m3d4mcmq20.fsf@localhost.localdomain>
On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is
> documented anywhere, though),
The latter is not exactly a shortcut for the former. You can try it at any
merge commit, and you will see different log. For instance, in Git repo:
$git rev-list 7ac749c^..7ac749c
7ac749c96d143ba4f76723959892cbaddbe8ed07
006f31d77f3dd5f813557c2839b39b2aaa22b925
53b22a9e45161004ff3260782abc4ee2a5b3e730
872354dcb3ce5f34f7ddb12d2c89d26a1ea4daf0
bc7c73e29cfb38232b5b6b1d1e8d59e7145a9860
$git rev-list 7ac749c^!
7ac749c96d143ba4f76723959892cbaddbe8ed07
So, I believe, rev^! means --first-parent rev^..rev
Dmitry
^ permalink raw reply
* [PATCH v3] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-06 16:16 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <1215333658-84938-1-git-send-email-benji@silverinsanity.com>
This makes rebase act a little more like merge when working on the
current branch. This is particularly useful for `git pull --rebase`
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Okay, I apparently should stop coding after midnight, even if I think I'm
awake enough. This version uses the correct variable. $orig_head looks like
the right name, but it stores the symbolic ref. $prev_head stores the actual
SHA1, which is what I was looking for.
git-rebase.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..44db7e6 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -434,3 +434,4 @@ do
done
finish_rb_merge
+git update-ref ORIG_HEAD $orig_head
--
1.5.6.2.337.gf6537
^ permalink raw reply related
* Re: [PATCH] branch -v: Prevent garbage output on remote refs
From: Brian Gernhardt @ 2008-07-06 16:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vhcb3fhqx.fsf@gitster.siamese.dyndns.org>
On Jul 6, 2008, at 6:07 AM, Junio C Hamano wrote:
> Thanks, but I have pushed out a slightly different change.
>
> -- >8 --
> branch -r -v: do not spit out garbage
Looks good, and more importantly works. Cherry-picked it from pu onto
next. Hopefully it'll move there on it's own soon.
~~ Brian
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.6.2
From: Mikael Magnusson @ 2008-07-06 14:54 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <alpine.LNX.1.10.0807061444250.28765@fbirervta.pbzchgretzou.qr>
2008/7/6 Jan Engelhardt <jengelh@medozas.de>:
>
> On Sunday 2008-07-06 07:34, Junio C Hamano wrote:
>>Junio C Hamano (9):
>> Allow "git-reset path" when unambiguous
>> diff --check: do not discard error status upon seeing a good line
>> git-shell: accept "git foo" form
>> GIT 1.5.4.6
>> GIT 1.5.5.5
>> Start draft release notes for 1.5.6.2
>> Work around gcc warnings from curl headers
>> Fix executable bits in t/ scripts
>> GIT 1.5.6.2
>
> Three git versions?
I believe this is related to moving to the dash-less form of receive-pack et al.
--
Mikael Magnusson
^ 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