* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Junio C Hamano @ 2008-10-21 21:53 UTC (permalink / raw)
To: Eric Wong; +Cc: Björn Steinbrink, git, jsogo
In-Reply-To: <20081021211131.GA21606@yp-box.dyndns.org>
Eric Wong <normalperson@yhbt.net> writes:
>> strace revealed that git-svn url-encodes ~ while svn does not do that.
>>
>> For svn we have:
>> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
>> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
>>
>> While git-svn shows:
>> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
>> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
This looks like an XML based request sequence to me (and svn is talking
WebDAV here, right?); it makes me wonder what exact quoting rules are used
there. I would expect $path in <S:src-path>$path</S:src-path> to quote
a letters in it e.g. '<' as "<" --- which is quite different from what
the s/// substitutions in the patch seem to be doing.
> diff --git a/git-svn.perl b/git-svn.perl
> index ef6d773..a97049a 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -852,7 +852,7 @@ sub escape_uri_only {
> - s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
> + s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
Admittedly I do not know git-svn (nor Perl svn bindings it uses), and I
suspect that some of the XML-level escaping is done in the libsvn side,
but it would be nice if somebody can at least verify that the code after
the patch works with repositories with funny characters in pathnames
(perhaps list all the printables including "<&>?*!@.+-%^"). Even nicer
would be a log message that says "the resulting code covers all cases
because it follows _that_ spec to escape _all_ problematic letters",
pointing at some in svn (or libsvn-perl) resource.
The patch may make a path with '~' work, but it (neither in the patch text
nor in the commit log message) does not have much to give readers enough
confidence that the code after the patch is the _final_ one, as opposed to
being just a band-aid for a single symptom that happened to have been
discovered this time.
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Alex Riesen @ 2008-10-21 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SLONIK.AZ, Andreas Ericsson, git
In-Reply-To: <7vej29zy2r.fsf@gitster.siamese.dyndns.org>
2008/10/21 Junio C Hamano <gitster@pobox.com>:
> "Leo Razoumov" <slonik.az@gmail.com> writes:
>
>> Even though the old behavior is "long established", it introduces
>> unnecessary ambiguity. If I have two repos
>> ...
>
> Of course. Now you know why people don't name such a pair of repositories
> like that ;-).
FWIW, I support Leo on that. The "established" behavior is stupid.
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Junio C Hamano @ 2008-10-21 22:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: SLONIK.AZ, Andreas Ericsson, git
In-Reply-To: <81b0412b0810211506y400ba750k2613ba19f01fb57@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> 2008/10/21 Junio C Hamano <gitster@pobox.com>:
>> "Leo Razoumov" <slonik.az@gmail.com> writes:
>>
>>> Even though the old behavior is "long established", it introduces
>>> unnecessary ambiguity. If I have two repos
>>> ...
>>
>> Of course. Now you know why people don't name such a pair of repositories
>> like that ;-).
>
> FWIW, I support Leo on that. The "established" behavior is stupid.
I am not inclined to respond to such an emotional argument. On the other
hand, it is fair to say that the existing behaviour is established,
because it is backed by a long history, which you can objectively verify.
If you think about it deeper, you will realize that it is not even clear
if it is "stupid".
More importantly, the behaviour is consistent with the way how "git fetch"
and "git clone" DWIMs the repository name by suffixing .git when the input
lacks it. And this DWIMmery comes from the expectations that:
(1) people name their repository project.git; and
(2) people like using and seeing short names (iow, "clone
git://$somewhere/project" is preferred over "clone
git://$somewhere/project.git");
If a repository whose real location is git://$somewhere/project.git is
cloned/fetched as git://$somewhere/project by people, recording the merge
source using the shorter name used by people to fetch from it is more
consistent. The patch breaks this consistency [*1*].
What is clear is that you would confuse yourself if you have two
repositories A and A.git next to each other, and that is primarily because
it breaks the above expectation.
git core-level rarely imposes such policies, but what Porcelains do is a
different matter.
Hence the suggestion: don't do it.
[Footnote]
*1* It would be a different matter if the patch at the same time removed
the fetch/clone DWIMmery. At least such a patch would be internally self
consistent.
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Alex Riesen @ 2008-10-21 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SLONIK.AZ, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
2008/10/22 Junio C Hamano <gitster@pobox.com>:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>>
>> FWIW, I support Leo on that. The "established" behavior is stupid.
>
> I am not inclined to respond to such an emotional argument. On the other
> hand, it is fair to say that the existing behaviour is established,
> because it is backed by a long history, which you can objectively verify.
I found it illogical (well, stupid) and inconvinient
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
Good idea.
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Junio C Hamano @ 2008-10-21 23:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: SLONIK.AZ, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> More importantly, the behaviour is consistent with the way how "git fetch"
> and "git clone" DWIMs the repository name by suffixing .git when the input
> lacks it. And this DWIMmery comes from the expectations that:
>
> (1) people name their repository project.git; and
>
> (2) people like using and seeing short names (iow, "clone
> git://$somewhere/project" is preferred over "clone
> git://$somewhere/project.git");
>
> If a repository whose real location is git://$somewhere/project.git is
> cloned/fetched as git://$somewhere/project by people, recording the merge
> source using the shorter name used by people to fetch from it is more
> consistent. The patch breaks this consistency [*1*].
> ...
> [Footnote]
>
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
Actually, after looking at what the involved codepaths do, I am inclined
to change my mind. Somehow I thought the transport.c infrastructure DWIMs
and uses the result of DWIMmery throughout the program (iow, at the point
in the codepath the patch touches, we cannot tell what the user originally
asked for), which is not the case at all. That changes everything.
The current behaviour is Ok if you match your behaviour to the original
expectations, but:
* if you clone from "git://$somewhere/project" originally, your
remote.origin.url will not end with ".git";
* or equivalently, if your remote.origin.url does not end with ".git".
and when you fetch in such a repository with or without the patch, the
results are the same. URL without trailing ".git".
So the change in the behaviour is only when you originally explicitly
asked to clone "git://$somewhere/project.git". With the change, that wish
is preserved. Without the change, ".git" is unconditionally dropped.
The situation is the same if you explicitly ask to fetch from a URL that
ends with ".git" (or "/.git"). With the change, the explicit ".git" is
preserved; without it, it is dropped.
So I now think the patch (if it were massaged into an applicable shape
with proper log message and sign-off) is an improvement.
Alex, thanks for sanity checking ;-)
^ permalink raw reply
* [PATCH] Implement git remote mv
From: Miklos Vajna @ 2008-10-22 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The new rename subcommand does the followings:
1) Renames the remote.foo configuration section to remote.bar
2) Updates the remote.bar.fetch refspecs
3) Updates the branch.*.remote settings
4) Renames the tracking branches.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-remote.txt | 6 +++
builtin-remote.c | 102 ++++++++++++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 14 ++++++
3 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index bb99810..4b5542a 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git remote' [-v | --verbose]
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote mv' <old> <new>
'git remote rm' <name>
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
@@ -61,6 +62,11 @@ only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, `git push` will always behave as if `\--mirror`
was passed.
+'mv'::
+
+Rename the remote named <old> to <new>. All remote tracking branches and
+configuration settings for the remote are updated.
+
'rm'::
Remove the remote named <name>. All remote tracking branches and
diff --git a/builtin-remote.c b/builtin-remote.c
index 6b3325d..4a23738 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -10,6 +10,7 @@
static const char * const builtin_remote_usage[] = {
"git remote",
"git remote add <name> <url>",
+ "git remote mv <old> <new>",
"git remote rm <name>",
"git remote show <name>",
"git remote prune <name>",
@@ -329,6 +330,105 @@ static int add_branch_for_removal(const char *refname,
return 0;
}
+struct rename_info {
+ const char *old;
+ const char *new;
+ struct string_list *remote_branches;
+};
+
+static int read_remote_branches(const char *refname,
+ const unsigned char *sha1, int flags, void *cb_data)
+{
+ struct rename_info *rename = cb_data;
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ if(!prefixcmp(refname, buf.buf))
+ string_list_append(xstrdup(refname), rename->remote_branches);
+
+ return 0;
+}
+
+static int mv(int argc, const char **argv)
+{
+ struct option options[] = {
+ OPT_END()
+ };
+ struct remote *oldremote, *newremote;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
+ struct string_list remote_branches = { NULL, 0, 0, 0 };
+ struct rename_info rename = { argv[1], argv[2], &remote_branches };
+ int i;
+
+ if (argc != 3)
+ usage_with_options(builtin_remote_usage, options);
+
+ oldremote = remote_get(rename.old);
+ if (!oldremote)
+ die("No such remote: %s", rename.old);
+
+ newremote = remote_get(rename.new);
+ if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
+ die("remote %s already exists.", rename.new);
+
+ strbuf_addf(&buf, "refs/heads/test:refs/remotes/%s/test", rename.new);
+ if (!valid_fetch_refspec(buf.buf))
+ die("'%s' is not a valid remote name", rename.new);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s", rename.old);
+ strbuf_addf(&buf2, "remote.%s", rename.new);
+ if (git_config_rename_section(buf.buf, buf2.buf) < 1)
+ return error("Could not rename config section '%s' to '%s'",
+ buf.buf, buf2.buf);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", rename.new);
+ if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
+ return error("Could not remove config section '%s'", buf.buf);
+ for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
+ char *ptr;
+
+ strbuf_reset(&buf2);
+ strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
+ ptr = strstr(buf2.buf, rename.old);
+ if (ptr)
+ strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
+ rename.new, strlen(rename.new));
+ if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+ return error("Could not append '%s'", buf.buf);
+ }
+
+ read_branches();
+ for (i = 0; i < branch_list.nr; i++) {
+ struct string_list_item *item = branch_list.items + i;
+ struct branch_info *info = item->util;
+ if (info->remote && !strcmp(info->remote, rename.old)) {
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%s.remote", item->string);
+ if (git_config_set(buf.buf, rename.new)) {
+ return error("Could not set '%s'", buf.buf);
+ }
+ }
+ }
+
+ for_each_ref(read_remote_branches, &rename);
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, item->string);
+ strbuf_splice(&buf, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf2);
+ strbuf_addf(&buf2, "remote: renamed %s to %s",
+ item->string, buf.buf);
+ if (rename_ref(item->string, buf.buf, buf2.buf))
+ die("renaming '%s' failed", item->string);
+ }
+
+ return 0;
+}
+
static int remove_branches(struct string_list *branches)
{
int i, result = 0;
@@ -696,6 +796,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show_all();
else if (!strcmp(argv[0], "add"))
result = add(argc, argv);
+ else if (!strcmp(argv[0], "mv"))
+ result = mv(argc, argv);
else if (!strcmp(argv[0], "rm"))
result = rm(argc, argv);
else if (!strcmp(argv[0], "show"))
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c449663..9b11fd3 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -324,4 +324,18 @@ test_expect_success 'reject adding remote with an invalid name' '
'
+# The first three tests if the config is properly updated, the last one
+# checks if the branches are renamed.
+
+test_expect_success 'rename a remote' '
+
+ git clone one four &&
+ (cd four &&
+ git remote mv origin upstream &&
+ git remote show |grep -q upstream &&
+ git config remote.upstream.fetch |grep -q upstream &&
+ test $(git config branch.master.remote) = "upstream" &&
+ git for-each-ref|grep -q refs/remotes/upstream)
+
+'
test_done
--
1.6.0.2
^ permalink raw reply related
* git history and file moves
From: Lin Ming @ 2008-10-22 2:02 UTC (permalink / raw)
To: git; +Cc: Moore, Robert
I'm looking for a way to move files to a new directory and have the
full history follow the file automatically. Is this possible?
I know about --follow, but I want the history to just follow the file
transparently. Also, we have a git web interface and we want the full
history for the moved files to be available.
Thanks,
Lin Ming
^ permalink raw reply
* Re: [PATCH] rebase-i-p: only list commits that require rewriting in todo
From: Stephen Haberman @ 2008-10-22 5:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vej2a3kl5.fsf@gitster.siamese.dyndns.org>
> >> + cat "$TODO" | grep -v "${rev:0:7}" > "${TODO}2" ; mv "${TODO}2"
> >> "$TODO"
> >
> > Substring expansion (like ${rev:0:7}) is not portable. At least it
> > doesn't work on FreeBSD /bin/sh, and "it's not even in POSIX", I
> > believe.
>
> True.
Thanks--sorry about that. rev:0:7 was a cute/stupid optimization to
avoid an extra `git rev-parse` call.
> I do not remember the individual patches in the series, but I have to
> say that the script at the tip of the topic is, eh, less than ideal.
Agreed. The previous dropped commits check was nicer, with just one
pass, as todo already had all of the non-dropped of the commits in it.
Now that todo has to include all commits initially to do parent probing,
the dropped commits check requires two passes, dropping lines from todo,
etc., and is a good deal uglier.
> Here is a small untested patch to fix a few issues I spotted while reading
> it for two minutes.
>
> * Why filter output from "rev-list --left-right A...B" and look for the
> ones that begin with ">"? Wouldn't "rev-list A..B" give that?
Oh--right. I was being too careful about keeping the existing rev-list
call and only changing what I needed that I didn't step back realize
that.
> * The abbreviated SHA-1 are made with "rev-list --abbrev=7" into $TODO in
> an earlier invocation, and it can be more than 7 letters to avoid
> ambiguity. Not just that "${r:0:7} is not even in POSIX", but use of
> it here is actively wrong.
Ah, didn't think of that.
> * There is no point in catting a single file and piping it into grep.
Right, right, I've been trying to get out of that habit.
> diff --git i/git-rebase--interactive.sh w/git-rebase--interactive.sh
> index 848fbe7..a563dea 100755
> --- i/git-rebase--interactive.sh
> +++ w/git-rebase--interactive.sh
> @@ -635,8 +635,8 @@ first and then run 'git rebase --continue' again."
> sed -n "s/^>//p" > "$DOTEST"/not-cherry-picks
> # Now all commits and note which ones are missing in
> # not-cherry-picks and hence being dropped
> - git rev-list $UPSTREAM...$HEAD --left-right | \
> - sed -n "s/^>//p" | while read rev
> + git rev-list $UPSTREAM..$HEAD |
> + while read rev
> do
> if test -f "$REWRITTEN"/$rev -a "$(grep "$rev" "$DOTEST"/not-cherry-picks)" = ""
> then
> @@ -645,7 +645,8 @@ first and then run 'git rebase --continue' again."
> # just the history of its first-parent for others that will
> # be rebasing on top of it
> git rev-list --parents -1 $rev | cut -d' ' -f2 > "$DROPPED"/$rev
> - cat "$TODO" | grep -v "${rev:0:7}" > "${TODO}2" ; mv "${TODO}2" "$TODO"
> + short=$(git rev-list -1 --abbrev-commit --abbrev=7 $rev)
> + grep -v "^[a-z][a-z]* $short" <"$TODO" > "${TODO}2" ; mv "${TODO}2" "$TODO"
> rm "$REWRITTEN"/$rev
> fi
> done
Looks good--I applied this locally and it passes t3404, t3410, and
t3411. Do I need to do anything else with this, e.g. resubmit/append on
top of the previous series, or do you have it taken care of?
Thanks for reviewing this, and Jeff too. I appreciate the feedback.
I will be bullish about the use cases I'd like to see work (these
preserve merges tweaks and the config setting for `git pull`), but
humble about my patches. This one especially is not elegant, it just
passes the tests. I've been re-reading it looking for a better way to
do it and nothing is jumping out at me. Let me know if you know of a
better approach or would like me to try something else.
Thanks,
Stephen
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.0.3
From: Junio C Hamano @ 2008-10-22 5:43 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.0.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.0.3.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.0.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.0.3.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.0.3-1.fc9.$arch.rpm (RPM)
This one is larger than usual, as I took two weeks off since 1.6.0.2.
----------------------------------------------------------------
GIT v1.6.0.3 Release Notes
==========================
Fixes since v1.6.0.2
--------------------
* "git archive --format=zip" did not honor core.autocrlf while
--format=tar did.
* Continuing "git rebase -i" was very confused when the user left modified
files in the working tree while resolving conflicts.
* Continuing "git rebase -i" was also very confused when the user left
some staged changes in the index after "edit".
* "git rebase -i" now honors the pre-rebase hook, just like the
other rebase implementations "git rebase" and "git rebase -m".
* "git rebase -i" incorrectly aborted when there is no commit to replay.
* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
with the output redirected to /dev/null.
* "git diff --no-index" on binary files no longer outputs a bogus
"diff --git" header line.
* "git diff" hunk header patterns with multiple elements separated by LF
were not used correctly.
* Hunk headers in "git diff" default to using extended regular
expressions, fixing some of the internal patterns on non-GNU
platforms.
* New config "diff.*.xfuncname" exposes extended regular expressions
for user specified hunk header patterns.
* "git gc" when ejecting otherwise unreachable objects from packfiles into
loose form leaked memory.
* "git index-pack" was recently broken and mishandled objects added by
thin-pack completion processing under memory pressure.
* "git index-pack" was recently broken and misbehaved when run from inside
.git/objects/pack/ directory.
* "git stash apply sash@{1}" was fixed to error out. Prior versions
would have applied stash@{0} incorrectly.
* "git stash apply" now offers a better suggestion on how to continue
if the working tree is currently dirty.
* "git for-each-ref --format=%(subject)" fixed for commits with no
no newline in the message body.
* "git remote" fixed to protect printf from user input.
* "git remote show -v" now displays all URLs of a remote.
* "git checkout -b branch" was confused when branch already existed.
* "git checkout -q" once again suppresses the locally modified file list.
* "git clone -q", "git fetch -q" asks remote side to not send
progress messages, actually making their output quiet.
* Cross-directory renames are no longer used when creating packs. This
allows more graceful behavior on filesystems like sshfs.
* Stale temporary files under $GIT_DIR/objects/pack are now cleaned up
automatically by "git prune".
* "git merge" once again removes directories after the last file has
been removed from it during the merge.
* "git merge" did not allocate enough memory for the structure itself when
enumerating the parents of the resulting commit.
* "git blame -C -C" no longer segfaults while trying to pass blame if
it encounters a submodule reference.
* "git rm" incorrectly claimed that you have local modifications when a
path was merely stat-dirty.
* "git svn" fixed to display an error message when 'set-tree' failed,
instead of a Perl compile error.
* "git submodule" fixed to handle checking out a different commit
than HEAD after initializing the submodule.
* The "git commit" error message when there are still unmerged
files present was clarified to match "git write-tree".
* "git init" was confused when core.bare or core.sharedRepository are set
in system or user global configuration file by mistake. When --bare or
--shared is given from the command line, these now override such
settings made outside the repositories.
* Some segfaults due to uncaught NULL pointers were fixed in multiple
tools such as apply, reset, update-index.
* Solaris builds now default to OLD_ICONV=1 to avoid compile warnings;
Solaris 8 does not define NEEDS_LIBICONV by default.
* "Git.pm" tests relied on unnecessarily more recent version of Perl.
* "gitweb" triggered undef warning on commits without log messages.
* "gitweb" triggered undef warnings on missing trees.
* "gitweb" now removes PATH_INFO from its URLs so users don't have
to manually set the URL in the gitweb configuration.
* Bash completion removed support for legacy "git-fetch", "git-push"
and "git-pull" as these are no longer installed. Dashless form
("git fetch") is still however supported.
Many other documentation updates.
----------------------------------------------------------------
Changes since v1.6.0.2 are as follows:
Abhijit Bhopatkar (1):
Documentation: Clarify '--signoff' for git-commit
Alec Berryman (2):
git-svn: factor out svnserve test code for later use
git-svn: Always create a new RA when calling do_switch for svn://
Alex Riesen (3):
Remove empty directories in recursive merge
Add remove_path: a function to remove as much as possible of a path
Use remove_path from dir.c instead of own implementation
Alexander Gavrilov (1):
builtin-blame: Fix blame -C -C with submodules.
Björn Steinbrink (1):
force_object_loose: Fix memory leak
Brandon Casey (14):
t9700/test.pl: avoid bareword 'STDERR' in 3-argument open()
t9700/test.pl: remove File::Temp requirement
diff.c: return pattern entry pointer rather than just the hunk header pattern
diff.c: associate a flag with each pattern and use it for compiling regex
diff.*.xfuncname which uses "extended" regex's for hunk header selection
t4018-diff-funcname: test syntax of builtin xfuncname patterns
builtin-prune.c: prune temporary packs in <object_dir>/pack directory
git-stash.sh: don't default to refs/stash if invalid ref supplied
builtin-merge.c: allocate correct amount of memory
git-stash.sh: fix flawed fix of invalid ref handling (commit da65e7c1)
remote.c: correct the check for a leading '/' in a remote name
t4018-diff-funcname: rework negated last expression test
t4018-diff-funcname: demonstrate end of line funcname matching flaw
xdiff-interface.c: strip newline (and cr) from line before pattern matching
Charles Bailey (2):
Add new test to demonstrate git archive core.autocrlf inconsistency
Make git archive respect core.autocrlf when creating zip format archives
Chris Frey (1):
Documentation: clarify the details of overriding LESS via core.pager
Dan McGee (1):
contrib: update packinfo.pl to not use dashed commands
Daniel Barkalow (1):
Check early that a new branch is new and valid
David Soria Parra (1):
Solaris: Use OLD_ICONV to avoid compile warnings
Deskin Miller (2):
maint: check return of split_cmdline to avoid bad config strings
git init: --bare/--shared overrides system/global config
Dmitry Potapov (4):
git-rebase-interactive: do not squash commits on abort
git-rebase--interactive: auto amend only edited commit
make prefix_path() never return NULL
do not segfault if make_cache_entry failed
Eric Raible (1):
completion: git commit should list --interactive
Eric Wong (1):
git-svn: fix handling of even funkier branch names
Fabrizio Chiarello (1):
builtin-clone: fix typo
Garry Dolley (1):
Clarified gitattributes documentation regarding custom hunk header.
Giuseppe Bilotta (1):
gitweb: remove PATH_INFO from $my_url and $my_uri
Heikki Orsila (2):
Start conforming code to "git subcmd" style part 3
Cosmetical command name fix
Imre Deak (1):
builtin-apply: fix typo leading to stack corruption
Jakub Narebski (2):
gitweb: Fix two 'uninitialized value' warnings in git_tree()
gitweb: Add path_info tests to t/t9500-gitweb-standalone-no-errors.sh
Jeff King (3):
Makefile: do not set NEEDS_LIBICONV for Solaris 8
git apply --directory broken for new files
tests: shell negation portability fix
Joey Hess (1):
gitweb: avoid warnings for commits without body
Johan Herland (2):
for-each-ref: Fix --format=%(subject) for log message without newlines
Use strchrnul() instead of strchr() plus manual workaround
Johannes Schindelin (2):
git rm: refresh index before up-to-date check
rebase -i: do not fail when there is no commit to cherry-pick
Johannes Sixt (2):
git-remote: do not use user input in a printf format string
git-push.txt: Describe --repo option in more detail
Jonas Fonseca (2):
checkout: Do not show local changes when in quiet mode
git-check-attr(1): add output and example sections
Junio C Hamano (15):
discard_cache: reset lazy name_hash bit
diff Porcelain: do not disable auto index refreshing on -C -C
diff --quiet: make it synonym to --exit-code >/dev/null
Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set
Fix permission bits on sources checked out with an overtight umask
checkout: do not lose staged removal
diff/diff-files: do not use --cc too aggressively
Start draft release notes for 1.6.0.3
diff: use extended regexp to find hunk headers
diff hunk pattern: fix misconverted "\{" tex macro introducers
Update draft release notes to 1.6.0.3
diff(1): clarify what "T"ypechange status means
Hopefully the final draft release notes update before 1.6.0.3
Fix testcase failure when extended attributes are in use
GIT 1.6.0.3
Linus Torvalds (1):
fix bogus "diff --git" header from "diff --no-index"
Luc Heinrich (1):
git-svn: call 'fatal' correctly in set-tree
Matt McCutchen (1):
t1301-shared-repo.sh: don't let a default ACL interfere with the test
Michael J Gruber (1):
make "git remote" report multiple URLs
Michael Prokop (1):
Replace svn.foo.org with svn.example.com in git-svn docs (RFC 2606)
Mikael Magnusson (4):
Typo "bogos" in format-patch error message.
git-repack uses --no-repack-object, not --no-repack-delta.
Fix a few typos in relnotes
Typo "does not exists" when git remote update remote.
Miklos Vajna (2):
test-lib: fix color reset in say_color()
Add testcase to ensure merging an early part of a branch is done properly
Nanako Shiraishi (2):
docs: describe pre-rebase hook
Teach rebase -i to honor pre-rebase hook
Nicolas Pitre (2):
fix pread()'s short read in index-pack
rehabilitate 'git index-pack' inside the object store
Petr Baudis (1):
Do not perform cross-directory renames when creating packs
Ping Yin (1):
git-submodule: Fix "Unable to checkout" for the initial 'update'
Rafael Garcia-Suarez (1):
Clarify commit error message for unmerged files
SZEDER Gábor (5):
t0024: add executable permission
Documentation: remove '\' in front of short options
rebase -i: proper prepare-commit-msg hook argument when squashing
rebase -i: remove leftover debugging
bash: remove fetch, push, pull dashed form leftovers
Samuel Tardieu (1):
Do not use errno when pread() returns 0
Shawn O. Pearce (3):
Update release notes for 1.6.0.3
Update release notes for 1.6.0.3
test-lib: fix broken printf
Stephen Haberman (1):
Clarify how the user can satisfy stash's 'dirty state' check.
Thomas Rast (1):
sha1_file: link() returns -1 on failure, not errno
Todd Zullinger (1):
Use dashless git commands in setgitperms.perl
Tuncer Ayaz (1):
Fix fetch/clone --quiet when stdout is connected
Yann Dirson (1):
Bust the ghost of long-defunct diffcore-pathspec.
martin f. krafft (1):
Improve git-log documentation wrt file filters
^ permalink raw reply
* Re: [PATCH] rebase-i-p: only list commits that require rewriting in todo
From: Junio C Hamano @ 2008-10-22 5:48 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Jeff King, git
In-Reply-To: <20081022000113.bacc1923.stephen@exigencecorp.com>
Stephen Haberman <stephen@exigencecorp.com> writes:
> Looks good--I applied this locally and it passes t3404, t3410, and
> t3411. Do I need to do anything else with this, e.g. resubmit/append on
> top of the previous series, or do you have it taken care of?
I've queued it on top of your series and merged the result in 'next'.
Further improvements should be done the same way.
> I will be bullish about the use cases I'd like to see work (these
> preserve merges tweaks and the config setting for `git pull`), but
> humble about my patches. This one especially is not elegant, it just
> passes the tests.
That's perfectly fine. We can start from sound ideas (the behaviour we would want
to see) and incrementally improve the implementation.
Thanks.
^ permalink raw reply
* Re: git 1.6.0.2 make test fails at t1301 under mac os x 10.4.
From: Fergus McMenemie @ 2008-10-22 6:11 UTC (permalink / raw)
To: git
Johannes,
Thanks for the prompt response. On the systems that work:-
>fergus:pwd
>/usr/local/packages/git-1.6.0.2
>fergus:mkdir y
>fergus:dir y
>total 0
>drwxr-xr-x 2 fergus fergus 68 21 Oct 22:52 ./
>drwxr-xr-x 692 fergus fergus 23528 21 Oct 22:52 ../
>fergus:id
>uid=501(fergus) gid=501(fergus) groups=501(fergus),98(_lpadmin),101(com.apple.sharepoint.group.1),66(_uucp),80(admin)
on the system that fails I see
>fergus:mkdir y
>fergus:dir y
>total 0
>drwxr-xr-x 2 fergus wheel 68 Oct 21 22:52 ./
>drwxr-xr-x 693 fergus wheel 23562 Oct 21 22:52 ../
>fergus:id
>uid=501(fergus) gid=501(fergus) groups=501(fergus), 81(appserveradm), 79(appserverusr), 80(admin)
Looking into this further, creating a file/dir on a BSD based system such
as OSX, the group ownership of the file/dir is taken from the enclosing
dirs group. Unlike say Solaris or Linux where it is based on your primary
group. I had not noticed this difference before!
All test passed, after changing the group ownership.
>On Tue, 21 Oct 2008, Fergus McMenemie wrote:
>
>> >++ mkdir sub
>> >++ cd sub
>> >++ umask 002
>> >++ git init --shared=1
>> >fatal: Could not make /usr/local/packages/git-1.6.0.2/t/trash
>> >directory/sub/.git/refs writable by group
>
>I guess this is the problem.
>
>Could you inspect what owner/group that directory has?
>
>Ciao,
>Dscho
--
===============================================================
Fergus McMenemie Email:fergus@twig.me.uk
Techmore Ltd Phone:(UK) 07721 376021
Unix/Mac/Intranets Analyst Programmer
===============================================================
^ permalink raw reply
* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Mike Hommey @ 2008-10-22 6:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Björn Steinbrink, git, jsogo
In-Reply-To: <7vtzb5wr6v.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 21, 2008 at 02:53:28PM -0700, Junio C Hamano wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> >> strace revealed that git-svn url-encodes ~ while svn does not do that.
> >>
> >> For svn we have:
> >> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> >> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
> >>
> >> While git-svn shows:
> >> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> >> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
>
> This looks like an XML based request sequence to me (and svn is talking
> WebDAV here, right?);
XML based would be &126;, not %7E.
Anyways, aren't there ready-to-use url quoting functions in perl ?
Mike
^ permalink raw reply
* [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 6:17 UTC (permalink / raw)
To: git
Git recently started printing the branch name when creating commits:
[irq/urgent]: created 3786fc7: "irq: make variable static"
very nice idea IMO! Having it all on one line allows me to double-check
that i indeed queued up a patch in the intended topic branch. Had it
read:
[irq/urgent]: created 3786fc7: "printk: make variable static"
i'd have noticed the mistake immediately.
this welcome enhancement made me remember of three usage problems i had
with Git recently:
1)
Btw., it would be nice if there was an easier way to get a similar git
log display in the ASCII space. For example i frequently ask the
question "which topic branch did commit XYZ originate from?". All i have
now is a pretty crude script that displays this for a given file:
earth4:~/tip> tip-log --no-merges linus.. kernel/sched.c | grep ^#
# core/kill-the-BKL: ffda12a: sched: optimize group load balancer
# core/locking: ffda12a: sched: optimize group load balancer
...
(see the script attached below)
but it's very slow with 233 branches, obviously, so i only use it as a
last resort mechanism.
What i'd _love_ to see is just an ASCII representation of where a commit
"came from" into the current branch. The first-hop branch it was
committed to.
it doesnt even have to be correct in the sha1 sense - i.e. it's enough
for me if the merge commit log is parsed. (and hence it wont be correct
if a branch ceases to exist or is renamed - but that is OK, i keep the
branch space static)
any ideas how to achieve that? I'd love to have output like this, if i
do this from tip/master (the master integration branch):
# mockup
earth4:~/tip> gll --no-merges kernel/sched.c
ffda12a: [sched/core] sched: optimize group load balancer
8cd162c: [sched/clock] sched: only update rq->clock while holding
0a16b60: [tracing/sched] tracing, sched: LTTng instrumentation
a5d8c34: [sched/debug] sched debug: add name to sched_domain sysctl entries
34b3ede: [sched/core] sched: remove redundant code in cpu_cgroup_create()
... and i dont want to embedd the branch name in every single commit.
The semantics seem well-specified to me: walk down the merge tree a
particular commit came from, and use the branch name that is mentioned
in a merge commit's comment section 'closest' to this commit.
That information is not 'trustable' in the sha1 sense because merge
commits can be modified manually and because the momentary name of a
branch might not be correct anymore - but with a sane topical setup this
would be a very powerful visualization tool.
It would be a nice tool that makes it easy to check the proper structure
of topical branches, after the fact. Weird, incorrectly queued up
commits would stick out _immediately_:
34b3ede: [x86/xen] sched: remove redundant code in cpu_cgroup_create()
2)
and while at ASCII representation - this made me remember a problem i
frequently have with octopus merges: it's _very_ difficult currently to
'backtrack' along a higher-order octopus in the git log ASCII space.
I dont use the newfangled flashy GUIs all that frequently and i recently
tried to go back to double-check the history of this order-21 octopus
merge in the upstream Linux kernel:
commit e496e3d645c93206faf61ff6005995ebd08cc39c
Merge: b159d7a... 5bbd4c3... 175e438... 516cbf3... af2d237... 9b15684... 5b7e41f... 1befdef... a03352d... 7b22ff5... 2c7e9fd... 91030ca... dd55235... b3e15bd... 20211e4... efd327a... c7ffa6c... e51a1ac... 5df4551... d99e901... e621bd1...
Author: Ingo Molnar <mingo@elte.hu>
Date: Mon Oct 6 18:17:07 2008 +0200
Merge branches 'x86/alternatives', 'x86/cleanups', 'x86/commandline', 'x86/crashdump', 'x86/debug', 'x86/defconfig', 'x86/doc', 'x86/exports', 'x86/fpu', 'x86/gart', 'x86/idle', 'x86/mm', 'x86/mtrr', 'x86/nmi-watchdog', 'x86/oprofile', 'x86/paravirt', 'x86/reboot', 'x86/sparse-fixes', 'x86/tsc', 'x86/urgent' and 'x86/vmalloc' into x86-v28-for-linus-phase1
i wanted to know the history of the 'x86/idle' topical commits. But it
was not easy to line up the sha1's to the branch names. So i had to
manually edit the commit log, i manually lined up all 21 sha1's to each
other, just to be able to figure out branch #11 in that lineup.
Is there some more efficient way to do that? Perhaps some git log output
that matches up the topic names with the sha1's? [for the cases where
the octopus merge commit log message still has a reasonable format]
3)
Similarly, when doing Octopus merges, and if the merge _fails_, it's
hard to see exactly which branch failed. For example, when preparing for
the v2.6.28 merge window i did something like this at a certain stage:
git merge x86/alternatives x86/cleanups x86/commandline \
x86/crashdump x86/debug x86/defconfig x86/doc \
x86/exports x86/fpu x86/gart x86/xen x86/idle x86/mm \
x86/mtrr x86/nmi-watchdog x86/oprofile x86/paravirt \
x86/reboot x86/sparse-fixes x86/tsc x86/urgent \
x86/vmalloc
I got a conflicted octopus merge somewhere in the middle of it. But it
only displayed sha1's when doing the merge. When i did a git log of that
sha1 it was not obvious at first sight which current branch maps to that
sha1. So i had to binary-search for the branch that caused the conflict
(!), to figure out that in the above sequence the 'x86/xen' bit is what
was causing trouble.
It would be very nice if the Octopus merge tool displayed not only the
sha1's that it is merging, but also the refspec that it is processing.
And when it fails it would be nice if it displayed a for-dummies
"Octopus merge failed when trying to merge x86/xen" kind of thing.
So mapping back sha1's to topic branch names does not seem to be very
easy at the moment. I realize that it is a fundamentally hard thing to
do, and the information is not reliable because branch names are
temporary - but in a sane branch setup it would be very nice to have
tools for that, to keep topics nice and tidy, and to annotate git logs
with the topical information.
Maybe there are already tools for that, it's just that i'm ignorant
about them?
Ingo
--------------->
for N in $(git branch | grep -vE ' master$| base$|for-linus|auto|linux-next|tmp' | cut -c3-); do
ITEMS=$(git rev-list --reverse linus..$N -- $@)
for M in $ITEMS; do
echo
echo "# $N: $(git log -1 --pretty=format:"%h: %s" $M $@)"
echo
git log -1 --pretty=email --no-merges $M $@ | cat
done
done | grep ^#
^ permalink raw reply
* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Junio C Hamano @ 2008-10-22 6:24 UTC (permalink / raw)
To: Mike Hommey; +Cc: Eric Wong, Björn Steinbrink, git, jsogo
In-Reply-To: <20081022061325.GC8225@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Tue, Oct 21, 2008 at 02:53:28PM -0700, Junio C Hamano wrote:
>
>> >> For svn we have:
>> >> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
>> >> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
>> >>
>> >> While git-svn shows:
>> >> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
>> >> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
>>
>> This looks like an XML based request sequence to me (and svn is talking
>> WebDAV here, right?);
>
> XML based would be &126;, not %7E.
Read what you quoted again and realize you are agreeing with me ;-).
The former (with "~") is what svn expects, the latter (with %7E) is what
git-svn incorrectly threw at the server causing problems. I am wondering
the whole %xx escaping thing, which does not seem to match what svn seems
to expect.
> Anyways, aren't there ready-to-use url quoting functions in perl ?
My question is not about correct "url quoting", but if using "url quoting"
is correct in this context.
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Ingo Molnar @ 2008-10-22 7:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Junio C Hamano, git
In-Reply-To: <20081022182149.f89fe88d.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Wed, 22 Oct 2008 06:32:27 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > This seems to have been caused by a git-rerere bug - it mis-matched a
> > timers tree conflict resolution. I cleared out that resolution (it had
> > nothing to do with stackprotector), re-did the conflict resolution
> > (which was about overlapping additions of header files), and pushed out
> > a new stackprotector tree - the delta below has the expected result.
>
> I wondered how you could have possibly got that result - aren't
> computers wonderful! :-)
heh, yes :)
this is the second time i met a git-rerere mismatch - the first one was
half a year ago.
Unfortunately i failed at generating a reproducer back then and even now
- as to resolve this problem i manually removed the preimage and
postimage, so it's gone now.
I've Cc:-ed Junio and the Git list as a general FYI - but it must be
frustrating to get such a bugreport, because i have no reproducer.
git-rerere sometimes seems to be picking up the wrong resolution. VERY
rarely.
It seems random and content dependent. Once it happened to
arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170
successful resolutions i have in my tree right now. And i do many
conflict resolutions every day - and it happened only once every 6
months or so.
(the arch/x86/kernel/traps_32.c one happened regularly, that's why i
thought it's content sha1 dependent, and not some corruption.)
Next time it happens i'll be on the watchout and will save the complete
tree.
Ingo
^ permalink raw reply
* Re: [PATCH] git-remote: list branches in vertical lists
From: Johannes Sixt @ 2008-10-22 7:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0810211847410.22125@pacific.mpi-cbg.de.mpi-cbg.de>
From: Johannes Sixt <j6t@kdbg.org>
Previously, branches were listed on a single line in each section. But
if there are many branches, then horizontal, line-wrapped lists are very
inconvenient to scan for a human. This makes the lists vertical, i.e one
branch per line is printed.
Since "git remote" is porcelain, we can easily make this
backwards-incompatible change.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Johannes Schindelin schrieb:
> On Tue, 21 Oct 2008, Johannes Sixt wrote:
>> This does mean that users' scripts must be updated because the output
>> format changed, but the result is friendlier to the eye *and* easier to
>> parse.
>
> My initial reaction to that was: add an option, and keep the old behavior
> then.
>
> But on second thought: No script has any business scanning the output of
> git-remote. That command is a pure convenience wrapper, and scripts
> trying to list remote branches should use git show-ref instead.
>
> So I'd say: replace the last comment with
>
> Since "git remote" is porcelain, we can easily make this
> backwards-incompatible change.
Here we go.
Note the new email address, too. I'm afraid the old one, @telecom.at, goes
out of service by the end of the year.
-- Hannes
Documentation/user-manual.txt | 4 +++-
builtin-remote.c | 11 +++++------
t/t5505-remote.sh | 14 +++++++++-----
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 08d1310..645d752 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4356,7 +4356,9 @@ $ git remote show example # get details
* remote example
URL: git://example.com/project.git
Tracked remote branches
- master next ...
+ master
+ next
+ ...
$ git fetch example # update branches from example
$ git branch -r # list all remote branches
-----------------------------------------------
diff --git a/builtin-remote.c b/builtin-remote.c
index 90a4e35..1b1697b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -416,10 +416,9 @@ static void show_list(const char *title, struct string_list *list,
return;
printf(title, list->nr > 1 ? "es" : "", extra_arg);
- printf("\n ");
- for (i = 0; i < list->nr; i++)
- printf("%s%s", i ? " " : "", list->items[i].string);
printf("\n");
+ for (i = 0; i < list->nr; i++)
+ printf(" %s\n", list->items[i].string);
}
static int get_remote_ref_states(const char *name,
@@ -515,17 +514,17 @@ static int show(int argc, const char **argv)
show_list(" Tracked remote branch%s", &states.tracked, "");
if (states.remote->push_refspec_nr) {
- printf(" Local branch%s pushed with 'git push'\n ",
+ printf(" Local branch%s pushed with 'git push'\n",
states.remote->push_refspec_nr > 1 ?
"es" : "");
for (i = 0; i < states.remote->push_refspec_nr; i++) {
struct refspec *spec = states.remote->push + i;
- printf(" %s%s%s%s", spec->force ? "+" : "",
+ printf(" %s%s%s%s\n",
+ spec->force ? "+" : "",
abbrev_branch(spec->src),
spec->dst ? ":" : "",
spec->dst ? abbrev_branch(spec->dst) : "");
}
- printf("\n");
}
/* NEEDSWORK: free remote */
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index e5137dc..e6cf2c7 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -28,7 +28,7 @@ tokens_match () {
}
check_remote_track () {
- actual=$(git remote show "$1" | sed -n -e '$p') &&
+ actual=$(git remote show "$1" | sed -e '1,/Tracked/d') &&
shift &&
tokens_match "$*" "$actual"
}
@@ -118,9 +118,11 @@ cat > test/expect << EOF
New remote branch (next fetch will store in remotes/origin)
master
Tracked remote branches
- side master
+ side
+ master
Local branches pushed with 'git push'
- master:upstream +refs/tags/lastbackup
+ master:upstream
+ +refs/tags/lastbackup
EOF
test_expect_success 'show' '
@@ -147,9 +149,11 @@ cat > test/expect << EOF
Remote branch merged with 'git pull' while on branch master
master
Tracked remote branches
- master side
+ master
+ side
Local branches pushed with 'git push'
- master:upstream +refs/tags/lastbackup
+ master:upstream
+ +refs/tags/lastbackup
EOF
test_expect_success 'show -n' '
--
1.6.0.2.1573.gdf533
^ permalink raw reply related
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Santi Béjar @ 2008-10-22 7:39 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022061730.GA5749@elte.hu>
On Wed, Oct 22, 2008 at 8:17 AM, Ingo Molnar <mingo@elte.hu> wrote:
[...]
> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
>
> 1)
>
> Btw., it would be nice if there was an easier way to get a similar git
> log display in the ASCII space. For example i frequently ask the
> question "which topic branch did commit XYZ originate from?". All i have
> now is a pretty crude script that displays this for a given file:
>
> earth4:~/tip> tip-log --no-merges linus.. kernel/sched.c | grep ^#
> # core/kill-the-BKL: ffda12a: sched: optimize group load balancer
> # core/locking: ffda12a: sched: optimize group load balancer
> ...
>
> (see the script attached below)
>
> but it's very slow with 233 branches, obviously, so i only use it as a
> last resort mechanism.
>
> What i'd _love_ to see is just an ASCII representation of where a commit
> "came from" into the current branch. The first-hop branch it was
> committed to.
>
> it doesnt even have to be correct in the sha1 sense - i.e. it's enough
> for me if the merge commit log is parsed. (and hence it wont be correct
> if a branch ceases to exist or is renamed - but that is OK, i keep the
> branch space static)
>
> any ideas how to achieve that? I'd love to have output like this, if i
> do this from tip/master (the master integration branch):
>
> # mockup
>
> earth4:~/tip> gll --no-merges kernel/sched.c
> ffda12a: [sched/core] sched: optimize group load balancer
> 8cd162c: [sched/clock] sched: only update rq->clock while holding
> 0a16b60: [tracing/sched] tracing, sched: LTTng instrumentation
> a5d8c34: [sched/debug] sched debug: add name to sched_domain sysctl entries
> 34b3ede: [sched/core] sched: remove redundant code in cpu_cgroup_create()
>
> ... and i dont want to embedd the branch name in every single commit.
>
> The semantics seem well-specified to me: walk down the merge tree a
> particular commit came from, and use the branch name that is mentioned
> in a merge commit's comment section 'closest' to this commit.
>
> That information is not 'trustable' in the sha1 sense because merge
> commits can be modified manually and because the momentary name of a
> branch might not be correct anymore - but with a sane topical setup this
> would be a very powerful visualization tool.
>
> It would be a nice tool that makes it easy to check the proper structure
> of topical branches, after the fact. Weird, incorrectly queued up
> commits would stick out _immediately_:
>
> 34b3ede: [x86/xen] sched: remove redundant code in cpu_cgroup_create()
>
If you still have the tip of the branches you want to know, you can
get a similar output with:
$ git log --pretty=oneline builtin-checkout.c | git name-rev --stdin
828e32b82e3e2bb10d6d730d3abe505063b481f6 (remotes/origin/HEAD~17) Fix
mismerge at cdb22c4 in builtin-checkout.c
f285a2d7ed6548666989406de8f0e7233eb84368 (remotes/spearce/master~2)
Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer
048f2762007d022defceb6850a44bc1bd5ccebf7 (remotes/spearce/master~24)
do not segfault if make_cache_entry failed
(sorry if it is refilled)
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Andreas Ericsson @ 2008-10-22 7:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, SLONIK.AZ, git
In-Reply-To: <81b0412b0810211543p6cb8c4ej49fb7fe70c3e2917@mail.gmail.com>
Alex Riesen wrote:
> 2008/10/22 Junio C Hamano <gitster@pobox.com>:
>> "Alex Riesen" <raa.lkml@gmail.com> writes:
>>> FWIW, I support Leo on that. The "established" behavior is stupid.
>> I am not inclined to respond to such an emotional argument. On the other
>> hand, it is fair to say that the existing behaviour is established,
>> because it is backed by a long history, which you can objectively verify.
>
> I found it illogical (well, stupid) and inconvinient
>
>> *1* It would be a different matter if the patch at the same time removed
>> the fetch/clone DWIMmery. At least such a patch would be internally self
>> consistent.
>
> Good idea.
No. Bad idea. That would not only break people's fetch configurations if
they've done clone on repos without passing .git, but also mean users
would have to remember if a particular server names their bare repos
"project.git".
If you remove *all* DWIMmery from fetch/clone, you'd also break people's
expectations when they're fetching from each other, as they'd have to pass
"git://devpeer/project/.git" instead of just "git://devpeer/project", which
is what *looks* sane.
A good idea would be to always report the name the user used. 'git clone'
already does that, recording the non-DWIMmed URL in the remotes config.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 7:56 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0810220039g51d61e92l5ba254b57723d3b6@mail.gmail.com>
* Santi Béjar <santi@agolina.net> wrote:
> > It would be a nice tool that makes it easy to check the proper
> > structure of topical branches, after the fact. Weird, incorrectly
> > queued up commits would stick out _immediately_:
> >
> > 34b3ede: [x86/xen] sched: remove redundant code in cpu_cgroup_create()
> >
>
> If you still have the tip of the branches you want to know, you can
> get a similar output with:
>
> $ git log --pretty=oneline builtin-checkout.c | git name-rev --stdin
> 828e32b82e3e2bb10d6d730d3abe505063b481f6 (remotes/origin/HEAD~17) Fix
> mismerge at cdb22c4 in builtin-checkout.c
> f285a2d7ed6548666989406de8f0e7233eb84368 (remotes/spearce/master~2)
> Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer
> 048f2762007d022defceb6850a44bc1bd5ccebf7 (remotes/spearce/master~24)
> do not segfault if make_cache_entry failed
>
> (sorry if it is refilled)
i didnt know about git name-rev, nice tool!
below is sample output from tip/master. Would there be a way to reformat
it into a compact form, like:
d80f55f6: (master) Merge branch 'tracing/urgent'
17d80fd0: (tracing/urgent) tracing: create tracers menu
The most useful angle would be if git log --format had a way to print
the reverse name. Then i could do a git-log-line script like:
git log --pretty=format:"%h: %20N %s" $@
where %N prints the reverse name.
While at it: it would be nice if git log had a way to crop string
output. For example i'd love to use:
git log --pretty=format:"%h: %60s" $@
which would print out at most 60 characters from the first commit line.
That way i can see it properly on an 80 width terminal and can paste it
into email without linewraps, etc. But --pretty=format does not seem to
know width restrictions.
Ingo
d80f55f6711ab57ac5f4e147f9782a7351847ec1 (master) Merge branch 'tracing/urgent'
17d80fd07d35ae1d231b3378ee4f00ace54f9d31 (tracing/urgent) tracing: create tracers menu
debfcaf93ed500a051489db6646d71f29fe86a68 (tracing/urgent~1) Merge branch 'tracing/ftrace' into tracing/urgent
722fb95f2f57cdd4c6910675a7f342066ff131f7 (master~1) Merge branch 'tracing/core'
d24fdbbb398764fccaec317d6e354a5111493940 (tracing/core) Merge branch 'linus' into tracing/core
3e66b5d4a4c2265832d5e6fc0e36488fb1f06d84 (master~2) Merge branch 'kmemcheck'
22993cab5b465ad75fc17056141cf94ff57b4767 (master~3) Merge branch 'x86/uv'
b0f209898f1a177bd503d49215b8c6628797a81c (x86/uv) x86, uv: use consistent names for region size and conherence id on x86 and ia64
e811da01227ab5cf84aa616f1ce528533b6204f1 (master~4) Merge branch 'irq/urgent'
e85cd2b2ced8e0643a2ca769552b6f6e0cbbb470 (master~5) Merge branch 'core/urgent'
a56d4858686da0c97086c93d3f50d4020405c02b (core/urgent) printk: make variable static
3786fc710c32b61464c322e5cd0c3d1d34ae72d0 (irq/urgent) irq: make variable static
df4a3963c2f91586ff96f8962bccee4d14cb1100 (master~6) Merge branch 'x86/urgent'
8bcad30f2e6d4c20f7e71d2e2ac77acc0f0931e5 (x86/urgent) x86: make variables static
eefa4b484d1678e11c16d17b7e2d9e10bbfc1c3e (remotes/origin/HEAD) Merge branch 'out-of-tree'
50f971ad73ea9550b1d8e34006bd11c7e108b24f (out-of-tree) qa: disable jffs2 for now
c55c135163a1fb1869beefbce887c01fe50d31ed (remotes/origin/HEAD~1) range-hrtimers: merge timers/urgent
490bd253db3da535fb7e8129d8d648290d27206c (remotes/origin/HEAD~2) Merge branch 'timers/urgent'
aed24c813ce374751c0818be922c785ec9f83dea (remotes/origin/HEAD~3) NOHZ: restart tick device from irq_enter()
c4bd822e7b12a9008241d76db45b665f2fef180c (timers/urgent) NOHZ: fix thinko in the timer restart code path
fca45353be469acb7f961fd3b2b244f400098a7d (kmemcheck) kmemcheck: document the shadow member of struct page
50987b4becd23c0716631602c36a1be5ed74576c (kmemcheck~1) kmemcheck: update Kconfig help text
f899dff87c5f03c8fc9145a9472b7e7f7173bbaa (kmemcheck~2) kmemcheck: update documentation
af3f8f7ec6d1a35c9a99a50e4faafdc18249412c (kmemcheck~3) kmemcheck: fix mis-merge in sysctl table
24a528ca7f1473368bf97c67a697227e57170a7f (remotes/origin/HEAD~4) Merge branch 'linus'
439bbef95d7987acb821954db8f8c858c6bf6246 (remotes/origin/HEAD~5) Merge branch 'tracing/urgent'
ed8491f0e2c3378e2a84ddf5bb2d60b2e7c04113 (remotes/origin/HEAD~5^2) ftrace: fix section mismatch warning.
8b1c190e9605035b4efb1f3bc6684cbae9b87dda (remotes/origin/HEAD~6) Merge branch 'irq/urgent'
1bc1b5f7823035666d341b269dede4507b81a0bb (remotes/origin/HEAD~7) Merge branch 'core/urgent'
5f86515158ca86182c1dbecd546f1848121ba135 (core-fixes-for-linus) rcupdate: fix bug of rcu_barrier*()
b6f3b7803a9231eddc36d0a2a6d2d8105ef89344 (auto-sparseirq-next) genirq: NULL struct irq_desc's member 'name' in dynamic_irq_cleanup()
e9f95e637320efe1936b647308ddf4ec5b8e0311 (auto-sparseirq-next~1) genirq: fix off by one and coding style
935ddf564701da409ca960bf2f54db528daa79a3 (remotes/origin/HEAD~8) Merge branch 'irq/urgent'
8ca7f02cdb97f1fe581768593ba2288a2d0fe32f (remotes/origin/HEAD~8^2) genirq: fix off by one and coding style
be5272d9410fcbc57edbc9b2d212332ed9e76dff (remotes/origin/HEAD~9) Merge branch 'out-of-tree'
b6ec630b689e5f4694d8ea1f38798926a960dc2e (out-of-tree~1) net9p: work around build breakage
11f46c9d6d27ab4d359bafa0b9df0cc5e1ba4a1d (remotes/origin/HEAD~10) Merge branch 'x86/doc'
ff2904fb6daeefecb6f8c2c8c63ea41b833c1ded (remotes/origin/HEAD~10^2) Merge branch 'linus' into x86/doc
197ec4d0ce943259c11900aa0ee45cf4252d009a (remotes/origin/HEAD~11) Merge branch 'out-of-tree'
ae4038719e87e6cf2f815aa735909b615abd9121 (out-of-tree~2) mm fix: Re: unable to handle kernel NULL pointer derefence at 00000000
a331daffa5dd61e29bbc50ef258753c325815f69 (remotes/origin/HEAD~12) Merge branch 'x86/urgent'
27945ca30442e84d866735dde5cec3b0ba148d62 (remotes/origin/HEAD~13) Merge branch 'x86/pci-ioapic-boot-irq-quirks'
ee2caf0cee7f09953630209d63434eadd97b3f8f (remotes/origin/HEAD~14) manual merge of x86/doc
e523b1fdc81ba1aed0f9800e12d99a1c0f6fcd86 (remotes/origin/HEAD~15) Merge branch 'x86/cleanups'
1a6e0823a6863b9312faf6aa42f9913d25c65f66 (remotes/origin/HEAD~16) Merge branch 'warnings/simple'
d9067316e80df04a850e2cc6e92f43cb149700cc (remotes/origin/HEAD~17) Merge branch 'warnings/infrastructure'
a3a2394fadfc13818182ab0f8bfdbbfd01e84b57 (remotes/origin/HEAD~18) Merge branch 'warnings/complex'
64cf0f977c72dbe309a089439071c1d2714f6653 (remotes/origin/HEAD~19) Merge branch 'warnings/bug'
5cbb06a3ff222d3ffe6fe57f6f490bee31ae83ee (remotes/origin/HEAD~20) Merge branch 'tracing/urgent'
1c667db03bee74b1b25715a192f9b297761a9e00 (remotes/origin/HEAD~21) Merge branch 'tracing/markers'
1aa708f1c974d338b4bce75eec7f77ef3b748171 (remotes/origin/HEAD~22) Merge branch 'tracing/ftrace'
440c31d907ecdf4f7d7d213656e08f7a67e0c18d (remotes/origin/HEAD~23) Merge branch 'tracing/core'
396cc143ac608aa82cdf2d942a3d00d2ac333db2 (remotes/origin/HEAD~24) Merge branch 'timers/rtc'
22022cb8b6c8fdfe3cdc12f310203a28190f24de (remotes/origin/HEAD~25) manual merge of timers/range-hrtimers
f908633285b8e73cff179a52bc4f73d3d9b565f5 (remotes/origin/HEAD~26) manual merge of stackprotector
00f6c5901c6ac11c63b9057639756d3e4d2dc613 (remotes/origin/HEAD~27) Merge branch 'sched/urgent'
d4d79dc6ad5d9f43038ad7c717866c8fcae0173e (remotes/origin/HEAD~28) Merge branch 'safe-poison-pointers'
1552b31f9c6ee9e5e5cb92dea77e084aa13ff05a (remotes/origin/HEAD~29) Merge branch 'oprofile'
1ef89f7f876568c2d15731ae5ee39d384deabb05 (remotes/origin/HEAD~30) manual merge of kmemcheck-v2
1f92ca40e95515ee1f7685fb7049ecfc8c797ca0 (remotes/origin/HEAD~31) Merge branch 'irq/urgent'
a16fc956cb5021500a8d02547a99488c894f1413 (remotes/origin/HEAD~32) Merge branch 'irq/genirq-v3'
728b75cc6dfa6178bbbf20838eda60032a78fc2c (remotes/origin/HEAD~33) manual merge of irq/genirq
61b15a6bddc8625b6beda35e2d923d2844f59b95 (remotes/origin/HEAD~34) manual merge of cpus4096
62dd3c84287f6b59fe2f1e40c26a0d7e5d63516c (remotes/origin/HEAD~35) Merge branch 'core/urgent'
0868e883d967ac6c54e35a817c23a40a603d7551 (remotes/origin/HEAD~36) Merge branch 'core/percpu'
6eb9b1d2e751f3857229e48144fdc394ffaa6fe7 (remotes/origin/HEAD~37) Merge branch 'core/locking'
f89beb7bc5eba16660141122b34d99fe89fe9c65 (remotes/origin/HEAD~38) Merge branch 'core/futexes'
c483bd39bfcc57c931226955d4e83b71a4e01ce9 (remotes/origin/HEAD~39) Merge branch 'core/debug'
75e7035e679c462c0c9c6a1cb0dc60fbcc58d3d4 (remotes/origin/HEAD~40) Revert "NOHZ: restart tick device from irq_enter()"
39fc6adb39ea36f746b6c4137dc38012878ce02e (remotes/origin/HEAD~41) Merge branch 'out-of-tree'
8422ac179506d38eb3f432809e806dd012581270 (out-of-tree~3) staging: fix p80211wext_event_associated() build failure
d9c32f25101f22574aa861cb7f3fe58ebdf52232 (out-of-tree~4) qa: cx88: disable for now
e63003c9ec406578631c6322346ca0e326d99d46 (out-of-tree~5) qa: always-enable CONFIG_FILE_LOCKING
0be9b16320ac42f968245e55383a5dd9238b9c39 (out-of-tree~6) pci: fix: BUG: unable to handle kernel NULL pointer dereference, IP: pci_create_slot+0x28/0x170
d4d92fcc681f2a9b788fe228df1f9da3ef0cc111 (out-of-tree~7) dvb: disable dm1105
b56b096cb3b258eebc63ce36ba9ee332a1427d79 (out-of-tree~8) mfd: disable another driver
892cff77716a359fc2f6e159d846893d07bf11f4 (out-of-tree~9) drivers/mfd/Kconfig: turn off broken driver
93e60b49d3df9f8bab5079e9e796bce3c604e3ed (out-of-tree~10) security: initialize skb->sk_security by default
3cdfa5c3b0e1d60925497ced0cf908a2f078732c (out-of-tree~11) rtx2x00: disable for now
c8d7def4258375d88f0b6f06cc6f10c3a514a285 (out-of-tree~12) drm: fix leak of uninitialized data to userspace
17bc3f7bf083e754e5c6210eab7af9ce7ed02ebc (out-of-tree~13) Revert "Revert parts of "x86: update mptable""
ac2716510df12c6fa0e6b99ebb4aa68584a1a751 (out-of-tree~14) pnp: Huge number of "io resource overlap" messages
ced6e773aa88b80b0c6b519a84f1e85ff15e3416 (out-of-tree~15) acpi: don't load acpi_cpufreq if acpi=off
f6d62717fa9c6572f257720abac383a7ae5fdb62 (out-of-tree~16) wd.c: work around broken build
1327b0cc9ad75c246f6e4198cf9c1731afda4146 (out-of-tree~17) net, wd.c: fix undefined reference to `NS8390p_init'
75acfc78aa1a3ac46f473e39b8b294309f8a80c9 (out-of-tree~18) misdn: work around build bug
81ba9c8488248a766f7151eba1664e9d93f49701 (out-of-tree~19) hp-plus.c: work around build failure
70027001c8e97565fad148f371505f022eb1e779 (out-of-tree~20) USB: work around crash
985d392693af6bbd6bdabcad65d24edb3b64c4ed (out-of-tree~21) work around build breakage
18eed0ffd132f50660e7c1c16c48ec2af312de00 (out-of-tree~22) i2c: work around boot crash in amd756_s4882_init()
32347630cbf94685c4eaae6d645ba720a8b31d2b (out-of-tree~23) i2c workaround: turn off I2C_NFORCE2_S4985 for now
7120b52e90e1837e09bb4621f105022f940b856a (out-of-tree~24) work around this crash for now:
3966803bcaa7a7b82ac05959c66ce12ea5953111 (out-of-tree~25) ACPI: don't walk tables if ACPI was disabled
3ac23f215a2b1710ae7b4ee5569ddfe303386a4f (out-of-tree~26) ACPI, x86: disable the C2C3_FFH access mode if MWAIT is unsupported
1d8d02e53965633d7465e4d3881365d5f114cfd9 (out-of-tree~27) x86: enable speedstep for Intel Pentium M processor 7x0 [1.6-2.26 GHz] (Sonoma) processors
899b5030558b8dc21a171e2e8129e0a93fb08860 (out-of-tree~28) init: root mount fix
6894676b3486f75d8e0c0c777fa9d8bf883eec70 (out-of-tree~29) net: use numa_node in net_devcice->dev instead of parent
da684332e2dc25966ac39d0c57f21715db0eb80e (out-of-tree~30) tip: add -tip tag
c267f4dff573d67eb9a8645b5045d971a0a3bc7b (warnings/complex) fix warning in fs/ext4/extents.c
8501db35588df4f35d67d8ba207422006a214ae7 (warnings/complex~1) work around warning in fs/xfs/xfs_rtalloc.c
7cf87ad9e9dc30304ec862b45156e93d2c255911 (warnings/complex~2) fix warning in drivers/net/mlx4/mcg.c
6e0ffadd6edcdc2bfc8a526a4f6f7644815fd1ed (warnings/complex~3) fix warning in drivers/net/mlx4/profile.c
faad95db248fffe94b691a9c8f9cd0193584633a (warnings/complex~4) fix warning in arch/x86/kernel/setup.c
4f4e11e8dce3f4d76f7196b2af7f8c28067f902b (warnings/complex~5) fix warning in drivers/isdn/i4l/isdn_ppp.c
4b9fa1a9927b4fec31c68b2d7d20384a01363b47 (warnings/complex~6) fix warning in arch/x86/kernel/early-quirks.c
159583619a768eb78ec81bf9ca96fa0096699083 (warnings/complex~7) fix warning in drivers/base/platform.c
bfbde60a78f6d467e41c557b44ec741d92ba61f0 (warnings/complex~8) fix warning in drivers/pci/pci-driver.c
6ddae344a73fcff60c840dd4e429bf55562b41f3 (warnings/complex~9) #ifdef complications in drivers/acpi/sleep/main.c
4b57d6ee2dc9a1062521298ad2d87b24aa5d12e4 (warnings/complex~10) fix warning in net/ax25/sysctl_net_ax25.c
b5532a323def96dda020cc19d326c2d456b3befc (warnings/complex~11) fix warnings in drivers/acpi/sbs.c
ec9e8767ceacedbac9a1ed60d815e9f37ea98a31 (warnings/complex~12) fix warning in sound/pci/cs46xx/cs46xx_lib.c
76a62692c3328c2870949b07ee10dff764701faf (warnings/complex~13) fix warning in net/sunrpc/xprtrdma/verbs.c
d41b73d05e0f4c99255e18de064adeac79e32af2 (warnings/complex~14) fix warning in net/bluetooth/rfcomm/sock.c
035aca6532256d0b5a31c7dfc989c3af223aae9e (warnings/complex~15) fix warning in drivers/video/matrox/matroxfb_crtc2.c
3e67d911f11fb73d716bffc6d056730ced7b9f11 (warnings/complex~16) fix warning in drivers/char/rtc.c
8f845313ba091a6041e666c611ef9bb751d91723 (warnings/complex~17) fix warning in ipc/ipc_sysctl.c
34483bdb925851a069c8ad32801a52382f3a6d31 (warnings/complex~18) fix warning in drivers/usb/misc/vstusb.c
98fa7e0f5af226c5343b5bcdd4c5435c120acd8e (warnings/complex~19) fix warning in drivers/message/fusion/mptbase.c
956ae9e7f7535aa15a9e5f2dce1c7dc0dada2be2 (warnings/complex~20) fix warning in kernel/profile.c
e698275468fae57af762b81dbc64fac09909e1ec (warnings/complex~21) fix warning in drivers/net/wireless/ray_cs.c
830ecfa8290ba6d332bd809b330977338190abbe (warnings/complex~22) fix warning in sound/pci/hda/patch_sigmatel.c
76b04a364261b872602ce73c659534b1cde1b7ae (warnings/complex~23) fix warning in drivers/scsi/advansys.c
2020ebad843222e5e965d1a76584da5737da1e89 (warnings/complex~24) fix warning in arch/x86/kernel/cpu/intel_cacheinfo.c
aca9c3a12781b0184be4d2bf4f906206394710db (warnings/complex~25) fix warning in drivers/isdn/i4l/isdn_common.c
d489f40fdffc0432a4deffa8c6b538c5d6c76990 (warnings/complex~26) fix warning in drivers/net/wan/syncppp.c
32a1ce224a376395351d534f5a3cdbf09a1bb0a8 (warnings/complex~27) fix warning in net/netfilter/nf_conntrack_proto_sctp.c
055231c21d70848060852892d63bb0ed1db22ac5 (warnings/complex~28) fix warning in net/netfilter/ipvs/ip_vs_ctl.c
2262c8b220ab3b07ae07775b7ccb676ed24ac5f6 (warnings/complex~29) fix warning in drivers/char/rocket.c
6f9fecb3d70400c5f99c1a1d09ffcce84483f611 (warnings/complex~30) fix warning in arch/x86/kernel/scx200_32.c
1fdf3e8b2702553b5c99cd57fd7445de3b976b9c (warnings/complex~31) fix warning in drivers/net/atlx/atl2.c
fa8e55eb6d126214b56c1291b6163bb698be094f (warnings/complex~32) include/linux/init.h: fix warning in drivers/crypto/hifn_795x.c
5a74eb70b93ead02290817d85f0064df833d429f (warnings/complex~33) fix warning in drivers/video/aty/atyfb_base.c, #2
cc499e1b8c2a2e4b6f2bfbfaea1bf14b3d8ca9ee (warnings/complex~34) fix warning in drivers/video/aty/atyfb_base.c
dee28be5adf98095ffba0681b9d50b5193530787 (warnings/complex~35) fix warning in fs/coda/sysctl.c
6bbf3e6297bfac50ab1f26c95dded0163a7f5351 (warnings/complex~36) fix warning in net/netfilter/nf_conntrack_proto_tcp.c
47ac1136e2314d7c65d65b114a17751728f61f93 (warnings/complex~37) fix warning in drivers/media/dvb/dvb-usb/anysee.c
d569696a616ac0ca0b440d84071f83e77b00f452 (warnings/complex~38) fix warning in drivers/net/wireless/iwlwifi/iwl-scan.c
15d50b15843ccea15667f0bff5eb54d389a445f9 (warnings/complex~39) lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c
5a0d58611372742163d2727812f36527321abfe3 (warnings/complex~40) fix warning in drivers/watchdog/w83697ug_wdt.c
0faf3f9d4728e23b877279f3a239d8c9c59cd5dd (warnings/complex~41) fix warning in drivers/net/wireless/libertas_tf/if_usb.c
609d5948fd3f59132f48de6360fc46d0bbecd8a7 (warnings/complex~42) fix warning in drivers/mfd/ucb1400_core.c
8858ab02a18e82675cec3a99984767ef7445084f (warnings/complex~43) fix warning in drivers/scsi/dtc.c
129e100e56a451534307b800ece2cc9ffbfa0fae (warnings/complex~44) fix warning in drivers/isdn/sc/timer.c
a70d2056f7d297e2ae39b89d72e7a3b7734cfa9e (warnings/complex~45) fix warning in drivers/isdn/sc/ioctl.c
4646ee0cad4328de4d4c30f838dc27109b54dcd3 (warnings/complex~46) fix warning in drivers/net/depca.c
ca9a950c830f529766cc422a29c4822271eb5406 (warnings/complex~47) fix warning in drivers/net/3c523.c
2e4f5630f57f155cbd07771c3a305f48b991f90c (warnings/complex~48) fix warning in drivers/scsi/g_NCR5380.c
7f941db396f1fdc0e010916b5a613b5b7d522c14 (warnings/complex~49) fix warning in drivers/isdn/sc/shmem.c
cc2efdd1b01a3caa7ce93d301d9a3e23ea0457ee (warnings/complex~50) fix warning in drivers/mca/mca-legacy.c
24842fb0217e3cf2988de77830ae1adee295a167 (warnings/complex~51) fix warning in drivers/isdn/icn/icn.c
c85193d4a954684f4269c4ed4f6f7b391d63797e (warnings/complex~52) fix warning in drivers/infiniband/hw/amso1100/c2_vq.c
299711a947ae5f818fa5f3e3d2c4fe22466a03ca (warnings/complex~53) fix warning in drivers/input/touchscreen/htcpen.c
dd4c80c5dedf66d1840fc372a9f7418f32d138df (warnings/complex~54) fix warning in drivers/isdn/sc/init.c
ec5aa2f441bacc89b2e0e9e4971c6c9aa460942a (warnings/complex~55) fix warning in drivers/watchdog/i6300esb.c
ee5aa63192e5b545c0f89c84dbfdb5cc4deea113 (warnings/complex~56) fix warning in kernel/power/main.c
e16a7ed48454125ff97a644742398022f72321dd (warnings/complex~57) fix warning in fs/compat_binfmt_elf.c
606c6806381192653211492b07592df9430c7865 (warnings/complex~58) fix warning in drivers/pci/search.c
037abd9c198336c3aa9024de149e6b640877be2f (warnings/complex~59) fix warning in drivers/isdn/hardware/eicon/message.c
f72bccd1611f4dafd875e993cff5017a4a73ec6d (warnings/complex~60) warnings: disable i2o on 64bit
8077af8b47a9ec1c76997a9516f0335638ee51c0 (warnings/complex~61) warnings: fix xfs posix acl
0b3682ba33c59a362901b478bdab965da888b350 (auto-sparseirq-next~2) genirq: fix set_irq_type() when recording trigger type
2515ddc6db8eb49a79f0fe5e67ff09ac7c81eab4 (kmemcheck-v2) binfmt_elf_fdpic: Update for cputime changes.
a50c22eed593f474e75f693381e4d42e81762de8 (kmemcheck-v2~1) mm: remove duplicated #include's
e798ba57e9f423dddbf1bdeb20a62bdd0593890f (kmemcheck-v2~2) Export tiny shmem_file_setup for DRM-GEM
653c03168348ac7aebb969931f87ba281749d7dd (kmemcheck-v2~3) misc: replace remaining __FUNCTION__ with __func__
e8848a170fd432bdda176a2d568919d4bba90467 (kmemcheck-v2~4) fix CONFIG_HIGHMEM compile error in drivers/gpu/drm/i915/i915_gem.c
f6f286f33e843862c559bfea9281318c4cdec6b0 (kmemcheck-v2~5) fix WARN() for PPC
5f41b8cdc6ef33b3432cee36264d628a80398362 (kmemcheck-v2~6) kexec: fix crash_save_vmcoreinfo_init build problem
e3d2f927f788adcdabc42f8a1616f6cc56c53bbe (kmemcheck-v2~7) Merge git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6
a9b6148d25f15ddfe9d7a7f3e526fdb64e7cf7da (auto-core-next-base) USB: Fix unused label warnings in drivers/usb/host/ehci-hcd.c
9b7530cc329eb036cfa589930c270e85031f554c (auto-core-next-base~1) i915: cleanup coding horrors in i915_gem_gtt_pwrite()
1ae87786800b5e0411847974b211797b6ada63c4 (auto-core-next-base~2) Fix sprintf format warnings in drm_proc.c
2bea2e4abf2fe8bc7384103aeaad91089109cfba (auto-core-next-base~3) Merge branch 'bkl-removal' of git://git.lwn.net/linux-2.6
a0bfb673dca8a2b4324fe11e678ec6d6a9ad67e0 (auto-core-next-base~4) Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
92b29b86fe2e183d44eb467e5e74a5f718ef2e43 (auto-core-next-base~5) Merge branch 'tracing-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
b9d7ccf56be1ac77b71a284a1c0e6337f9a7aff0 (auto-core-next-base~6) Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
9301975ec251bab1ad7cfcb84a688b26187e4e4a (auto-core-next-base~7) Merge branch 'genirq-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
7110879cf2afbfb7af79675f5ff109e63d631c25 (auto-core-next-base~8) Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
99ebcf8285df28f32fd2d1c19a7166e70f00309c (auto-core-next-base~9) Merge branch 'v28-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
72558dde738b06cc01e16b3247a9659ca739e22d (auto-core-next-base~10) Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
b91385236c00031c64b42b44db8068ad38a5ea11 (auto-core-next-base~11) Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx
d67ae206ef05198824c2a306c0c0edf2d2088920 (auto-core-next-base~12) Merge git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog
1d9a8a47d659f053abeca9ece45651b4d94780c8 (auto-core-next-base~13) Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse
f07767fd0f95c385108fa4c456a9cb216a424fec (auto-core-next-base~14) byteorder: remove direct includes of linux/byteorder/swab[b].h
f4432c5caec5fa95ea7eefd00f8e6cee17e2e023 (auto-core-next-base~15) Update email addresses.
6da0b38f4433fb0f24615449d7966471b6e5eae0 (auto-core-next-base~16) fs/Kconfig: move ext2, ext3, ext4, JBD, JBD2 out
54b1d646d442289d8d49e04bc2f10ba122ff6aa4 (warnings/simple) sound/soc/codecs/tlv320aic23.c: remove unused variable
0be735b3ff71e13e24b82420f23a1b3b0a207ffb (warnings/simple~1) net/mac80211/rc80211_minstrel_debugfs.c: fix return type
04271505e03535e1fd085c96085fcee41e7c415f (warnings/simple~2) [vfs] fs.h: fops_get()/fops_put(): use pointer comparison
f81ee5ca545020daf0ddfff3744199b87bbd8c70 (warnings/simple~3) include/linux/fs.h: improve type checking of __mandatory_lock()
5baf34fc63c31ef676e0a764415b10e5cc1c7a4b (warnings/simple~4) net/netlabel/netlabel_addrlist.c: add type checking to audit_log_format()
d58cbf52cb25e215c0e34048bda8ec481bdce4af (warnings/simple~5) fs/afs/dir.c: fix uninitialized variable use
19be5d76a014ce0e743848a42cbb3b579c0ad8d7 (warnings/simple~6) drivers/video/cirrusfb.c: remove unused variables
d138e44e2f8d0f26e04b0386d328d9cc7e33d82e (warnings/simple~7) drivers/net/wireless/b43/phy_g.c: type check debug printouts
f11adf3c65aff25074d5d3a90d72cdfc40d66b50 (warnings/simple~8) drivers/ide/pci/hpt366.c: remove unused variable
ecd05381e26b9a61e49fa485baea1595bd3d1b40 (warnings/simple~9) x86: fix default_spin_lock_flags() prototype
0d468300dc97d6aec084799ffe39253ac366f1e4 (auto-core-next-base~17) Remove empty imacfb.c file
96499871f45b9126157b1a5c512d6e30f1635225 (auto-core-next-base~4^2) PCI: fix pci_ioremap_bar() on s390
db7a6d8d01b21829d28638258cbbc9553210bac1 (auto-core-next-base~18) Update .gitignore files for generated targets
270c66be9b4a6f2be53ef3aec5dc8e7b07782ec9 (auto-core-next-base~4^2~1) PCI: fix AER capability check
0927678f55c9a50c296f7e6dae85e87b8236e155 (auto-core-next-base~4^2~2) PCI: use pci_find_ext_capability everywhere
1543c90c39360df333a21bfbbdfe812ae23b8167 (auto-core-next-base~4^2~3) PCI: remove #ifdef DEBUG around dev_dbg call
bd1d9855be3ab8a5c2b31053d464b7fe63e6963b (auto-core-next-base~4^2~4) PCI hotplug: fix get_##name return value problem
e5665a45fa28d0114f61b5d534a3b2678592219d (auto-core-next-base~4^2~5) PCI: document the pcie_aspm kernel parameter
aa42d7c6138afdc54f74e971456a0fbfec16b77b (auto-core-next-base~4^2~6) PCI: introduce an pci_ioremap(pdev, barnr) function
e9f82cb75096ae30658a72d473bf170bf4d3bb2e (auto-core-next-base~4^2~7) powerpc/PCI: Add legacy PCI access via sysfs
f19aeb1f3638b7bb4ca21eb361f004fac2bfe259 (auto-core-next-base~4^2~8) PCI: Add ability to mmap legacy_io on some platforms
f393d9b130423a7a47c751b26df07ceaa5dc76a9 (auto-core-next-base~4^2~9) PCI: probing debug message uniformization
58c3a727cb73b75a9104d295f096cca12959a5a5 (auto-core-next-base~4^2~10) PCI: support PCIe ARI capability
201de56eb22f1ff3f36804bc70cbff220b50f067 (auto-core-next-base~4^2~11) PCI: centralize the capabilities code in probe.c
280c73d3691fb182fa55b0160737c2c0feb79471 (auto-core-next-base~4^2~12) PCI: centralize the capabilities code in pci-sysfs.c
e354597cce8d219d135d65e585dc4f30323486b9 (auto-core-next-base~4^2~13) PCI: fix 64-vbit prefetchable memory resource BARs
557848c3c03ad1d1e66cb3b5b06698e3a9ebc33c (auto-core-next-base~4^2~14) PCI: replace cfg space size (256/4096) by macros.
022edd86d7c864bc8fadc3c8ac4e6a464472ab05 (auto-core-next-base~4^2~15) PCI: use resource_size() everywhere.
c322b28a04c084a467a862766f74c40c917a721c (auto-core-next-base~4^2~16) PCI: use same arg names in PCI_VDEVICE comment
5d9bc1fa47f0c1561f1d7c0bdff5e24860852b42 (auto-core-next-base~4^2~17) PCI hotplug: rpaphp: make debug var unique
c9bbb4abb658daf6cc6f92fb4751a7796a5aab75 (auto-core-next-base~4^2~18) PCI: use %pF instead of print_fn_descriptor_symbol() in quirks.c
c8761fe80ed052634153438405c9048611ae7ae1 (auto-core-next-base~4^2~19) PCI: fix hotplug get_##name return value problem
11d587429e9cbb40ac20d7ed8126c66da0d7aba5 (auto-core-next-base~4^2~20) PCI: fix sparse warning in pci_remove_behind_bridge
50cbfa511a21cac1909b6b4c955fa39d1da81457 (auto-core-next-base~4^2~21) PCI: fix MSI-HOWTO.txt info about MSI-X MMIO space
ec84f1268fcf16c4a852fdb38b3a541748644918 (auto-core-next-base~4^2~22) PCI: fix -Wakpm warnings in pci_pm_init debug output
cef354db0d7a7207ea78c716753d9216a9c2b7e1 (auto-core-next-base~4^2~23) PCI: connect struct pci_dev to struct pci_slot
93ff68a55aa92180a765d6c51c3303f6200167a6 (auto-core-next-base~4^2~24) PCI: make CPU list affinity visible
5993760f7fc75b77e4701f1e56dc84c0d6cf18d5 (auto-core-next-base~4^2~25) PCI: utilize calculated results when detecting MSI features
7f2feec140f1f1e4f701e013a2bf8284a9ec2a3c (auto-core-next-base~4^2~26) PCI: pciehp: replace printk with dev_printk
83e9ad540b9ee23919961f9500ca254220b78d09 (auto-core-next-base~4^2~27) PCI: pciehp: change name tag of "hpdriver_portdrv" variable
37a84ec668ba251ae02cf2c2c664baf6b247ae1f (auto-core-next-base~4^2~28) x86/PCI: irq and pci_ids patch for Intel Ibex Peak DeviceIDs
f7a10e32a1a7ae240fa3925c5727d224eba3e31d (auto-core-next-base~4^2~29) PCI: pciehp: fix irq initialization
c01156061bdd5976397dfb173f8c70ae351a6cb6 (auto-core-next-base~4^2~30) PCI: Document that most pci options are shared between i386 and x86-64
c9ed77eeba8ec2541a40918210bcc676acacd43a (auto-core-next-base~4^2~31) PCI: tidy PME support messages
2fd39aa7c2f3d696814abb3e8962c759eee484f3 (auto-core-next-base~4^2~32) PCI: ibmphp: list_for_each to list_for_each_entry-checkpatch cleanups
a8d2dbd38481e0c35c6bdd8196dd38a42ae45d02 (auto-core-next-base~4^2~33) PCI: ibmphp: list_for_each to list_for_each_entry
34a2e15e95fce6d6f4d30162f53a0ceb25d5bbaf (auto-core-next-base~4^2~34) PCI: follow lspci device/vendor style
d768cb6929773060171eee8397a63883f60ddc07 (auto-core-next-base~4^2~35) x86/PCI: follow lspci device/vendor style
16dbef4a831782466b10d4ae56837c5ba17d1948 (auto-core-next-base~4^2~36) PCI: change MSI-x vector to 32bit
0235c4fc7fc6f621dc0dd89eba102ad5aa373390 (auto-core-next-base~4^2~37) PCI PM: Introduce function pci_wake_from_d3
3d137310245e4cdc3e8c8ba1bea2e145a87ae8e3 (auto-core-next-base~4^2~38) PCI: allow quirks to be compiled out
b41d6cf38e27a940d998d989526a9748de1bf028 (auto-core-next-base~4^2~39) PCI: Check dynids driver_data value for validity
edbc25caaa492a82e19baa915f1f6b0a0db6554d (auto-core-next-base~4^2~40) PCI: remove dynids.use_driver_data
592b7a88564a2167a144265bf68df0123c0e4e98 (tmp.master.prev~2^2) doc/x86: fix doc subdirs
921974982a7aab561a1c3ff1763af7470874ba8e (auto-core-next-base~19) Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
7d67474e506598fe26e0c262acf02132dc730517 (auto-core-next-base~20) Merge git://git.infradead.org/battery-2.6
252883e512c6d8fbc03b6738f1620fda44c4d472 (auto-core-next-base~21) epca: Add infinite break support
^ permalink raw reply
* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Eric Wong @ 2008-10-22 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, git, jsogo
In-Reply-To: <7vtzb5wr6v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> >> strace revealed that git-svn url-encodes ~ while svn does not do that.
> >>
> >> For svn we have:
> >> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> >> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
> >>
> >> While git-svn shows:
> >> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> >> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
>
> This looks like an XML based request sequence to me (and svn is talking
> WebDAV here, right?); it makes me wonder what exact quoting rules are used
> there. I would expect $path in <S:src-path>$path</S:src-path> to quote
> a letters in it e.g. '<' as "<" --- which is quite different from what
> the s/// substitutions in the patch seem to be doing.
I agree. I haven't checked if the SVN libraries do proper XML escaping
for us (but the problem hasn't shown up yet :). I was already
completely disappointed that git-svn had to do its own escaping when
transmitting data using the SVN libraries (and dependent on the protocol
being used, too!).
> > diff --git a/git-svn.perl b/git-svn.perl
> > index ef6d773..a97049a 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -852,7 +852,7 @@ sub escape_uri_only {
> > - s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
> > + s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
>
> Admittedly I do not know git-svn (nor Perl svn bindings it uses), and I
> suspect that some of the XML-level escaping is done in the libsvn side,
> but it would be nice if somebody can at least verify that the code after
> the patch works with repositories with funny characters in pathnames
> (perhaps list all the printables including "<&>?*!@.+-%^"). Even nicer
> would be a log message that says "the resulting code covers all cases
> because it follows _that_ spec to escape _all_ problematic letters",
> pointing at some in svn (or libsvn-perl) resource.
Help with looking at what SVN does and writing testcases would
definitely be appreciated on this matter. Or perhaps this can be done
at GitTogether :)
> The patch may make a path with '~' work, but it (neither in the patch text
> nor in the commit log message) does not have much to give readers enough
> confidence that the code after the patch is the _final_ one, as opposed to
> being just a band-aid for a single symptom that happened to have been
> discovered this time.
This is definitely a band-aid fix until I or somebody else takes the
time to figure out:
1. exactly which characters need to be escaped
2. for which protocols those characters need to be escaped
3. which part(s) of the URI they need to be escaped for
(repository root vs SVN path)
4. which versions of SVN needs more (or less) escaping rules
(I vote for somebody else, especially for #4 :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 8:20 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <1224622557-6669-1-git-send-email-angavrilov@gmail.com>
On Wed, Oct 22, 2008 at 12:55:57AM +0400, Alexander Gavrilov wrote:
> +test_expect_success \
> + 'blame respects i18n.commitencoding' '
> + git blame --incremental file | \
> + grep "^\(author\|summary\) " > actual &&
> + test_cmp actual expected
Even though it is POSIX, using backslashed grouping in 'grep' isn't
portable. It fails at least on Solaris 8, and you have to do:
egrep "^(author|summary) "
instead. Of course, I can't get your test to pass even with that change,
but I think that is just a broken iconv on Solaris.
-Peff
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Stephen Rothwell @ 2008-10-22 8:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Junio C Hamano, git
In-Reply-To: <20081022072923.GC27637@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]
On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> I've Cc:-ed Junio and the Git list as a general FYI - but it must be
> frustrating to get such a bugreport, because i have no reproducer.
>
> git-rerere sometimes seems to be picking up the wrong resolution. VERY
> rarely.
>
> It seems random and content dependent. Once it happened to
> arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170
> successful resolutions i have in my tree right now. And i do many
> conflict resolutions every day - and it happened only once every 6
> months or so.
>
> (the arch/x86/kernel/traps_32.c one happened regularly, that's why i
> thought it's content sha1 dependent, and not some corruption.)
>
> Next time it happens i'll be on the watchout and will save the complete
> tree.
I think rerere matches preimages on the SHA1 of the conflict (or its
reverse), so sufficiently similar pieces of code will match. I would
expect things like ext2/3/4 to be candidates. Did the traps_32.c one
match one for traps_64.c?
I may be mistaken, but I once followed the code in rerere to try to
figure out how to fix a resolution.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Stephen Rothwell @ 2008-10-22 8:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Junio C Hamano, git
In-Reply-To: <20081022192725.5f5de711.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
On Wed, 22 Oct 2008 19:27:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I think rerere matches preimages on the SHA1 of the conflict (or its
> reverse), so sufficiently similar pieces of code will match. I would
> expect things like ext2/3/4 to be candidates. Did the traps_32.c one
> match one for traps_64.c?
Or, of course similar conflicts in different merges in different branches
of the same tree are really asking for it ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Ingo Molnar @ 2008-10-22 8:31 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Junio C Hamano, git
In-Reply-To: <20081022192725.5f5de711.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > I've Cc:-ed Junio and the Git list as a general FYI - but it must be
> > frustrating to get such a bugreport, because i have no reproducer.
> >
> > git-rerere sometimes seems to be picking up the wrong resolution. VERY
> > rarely.
> >
> > It seems random and content dependent. Once it happened to
> > arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170
> > successful resolutions i have in my tree right now. And i do many
> > conflict resolutions every day - and it happened only once every 6
> > months or so.
> >
> > (the arch/x86/kernel/traps_32.c one happened regularly, that's why i
> > thought it's content sha1 dependent, and not some corruption.)
> >
> > Next time it happens i'll be on the watchout and will save the complete
> > tree.
>
> I think rerere matches preimages on the SHA1 of the conflict (or its
> reverse), so sufficiently similar pieces of code will match. I would
> expect things like ext2/3/4 to be candidates. Did the traps_32.c one
> match one for traps_64.c?
>
> I may be mistaken, but I once followed the code in rerere to try to
> figure out how to fix a resolution.
the traps_32.c one was that git-rerere put in a traps_64.c end result.
So i ended up with a 32-bit kernel that tried to build a 64-bit piece of
code - fireworks. That condition persisted - i had to fix it up manually
all the time i integrated that portion of the tree. That too was i think
centered around a header file chunk - perhaps the #include section of
traps_32.c and traps_64.c was similar enough in that section?
Ingo
^ permalink raw reply
* [JGIT PATCH 1/3] Fix retrieval of test resources for paths containing spaces
From: Jonas Fonseca @ 2008-10-22 8:32 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
The use of URL.getPath() can be problematic when the repository path
contains spaces since they get encoded as %20, which will lead to a "No
such file" error when resolving to a local file. The fix first tries to
convert the resource URL to a URI (added in Java 1.5), which is then
used to construct the File instance. As a fallback use the old behavior
if a URISyntaxException is thrown.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../tst/org/spearce/jgit/util/JGitTestUtil.java | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
index bf2471d..eee0c14 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
@@ -38,6 +38,7 @@
package org.spearce.jgit.util;
import java.io.File;
+import java.net.URISyntaxException;
import java.net.URL;
public abstract class JGitTestUtil {
@@ -57,7 +58,11 @@ public static File getTestResourceFile(final String fileName) {
// loaded previously
return new File("tst", fileName);
}
- return new File(url.getPath());
+ try {
+ return new File(url.toURI());
+ } catch(URISyntaxException e) {
+ return new File(url.getPath());
+ }
}
private static ClassLoader cl() {
--
1.6.0.2.1166.g8d97a.dirty
--
Jonas Fonseca
^ permalink raw reply related
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