* [PATCHv7 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-21 19:34 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224617694-29277-4-git-send-email-giuseppe.bilotta@gmail.com>
This patch makes it possible to use an URL such as
project/action/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
project/action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent (e.g. 'shortlog') can now get all of their parameters
from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9da547d..59449de 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -549,7 +549,12 @@ sub evaluate_path_info {
'history',
);
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ # we want to catch
+ # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
+ my ($parentrefname, $parentpathname, $refname, $pathname) =
+ ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
+
+ # first, analyze the 'current' part
if (defined $pathname) {
# we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but:
@@ -564,7 +569,13 @@ sub evaluate_path_info {
$input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} ||= "blob_plain";
+ # the default action depends on whether we had parent info
+ # or not
+ if ($parentrefname) {
+ $input_params{'action'} ||= "blobdiff_plain";
+ } else {
+ $input_params{'action'} ||= "blob_plain";
+ }
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
@@ -584,6 +595,27 @@ sub evaluate_path_info {
$input_params{'hash'} ||= $refname;
}
}
+
+ # next, handle the 'parent' part, if present
+ if (defined $parentrefname) {
+ # a missing pathspec defaults to the 'current' filename, allowing e.g.
+ # someproject/blobdiff/oldrev..newrev:/filename
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $input_params{'file_parent'} ||= $parentpathname;
+ } else {
+ $input_params{'file_parent'} ||= $input_params{'file_name'};
+ }
+ # we assume that hash_parent_base is wanted if a path was specified,
+ # or if the action wants hash_base instead of hash
+ if (defined $input_params{'file_parent'} ||
+ grep { $_ eq $input_params{'action'} } @wants_base) {
+ $input_params{'hash_parent_base'} ||= $parentrefname;
+ } else {
+ $input_params{'hash_parent'} ||= $parentrefname;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv7 5/5] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-21 19:34 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224617694-29277-5-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 28 ++++++++++++++++++++++++----
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 59449de..9d1af7e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -766,6 +766,7 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
+ # - hash_parent or hash_parent_base:/file_parent
# - hash or hash_base:/filename
# When the script is the root DirectoryIndex for the domain,
@@ -785,17 +786,36 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:/file_name or hash
+ # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
+ # stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
+ || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ # skip the file_parent if it's the same as the file_name
+ delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'});
+ delete $params{'file_parent'};
+ }
+ $href .= "..";
+ delete $params{'hash_parent'};
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
* [JGIT PATCH] Detect repository states according to post Git 1.5
From: Robin Rosenberg @ 2008-10-21 20:13 UTC (permalink / raw)
To: tomi.pakarinen; +Cc: spearce, git
In-Reply-To: <f299b4f30810211109q7f2919f2r1d5cd8faf0048154@mail.gmail.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Seems we need this patch too in order to detect repository states. The new
resolution is more granular that before, though I suggest that one should
be restrictive when interpreting the state and not assume that these states
are the only ones. The methods on RepositoryState are the /only/ valid
ways of deciding what to, or not to, do. This implies we need to extend this
class somewhat, but I'm no hurry yet so we can think about what methods
we need.
.../src/org/spearce/jgit/lib/Repository.java | 17 +++++++++++++
.../src/org/spearce/jgit/lib/RepositoryState.java | 25 +++++++++++++++++++-
2 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index dfce1b8..26748e2 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -1017,14 +1017,31 @@ public GitIndex getIndex() throws IOException {
* @return an important state
*/
public RepositoryState getRepositoryState() {
+ // Pre Git-1.6 logic
if (new File(getWorkDir(), ".dotest").exists())
return RepositoryState.REBASING;
if (new File(gitDir,".dotest-merge").exists())
return RepositoryState.REBASING_INTERACTIVE;
+
+ // From 1.6 onwards
+ if (new File(getDirectory(),"rebase-apply/rebasing").exists())
+ return RepositoryState.REBASING_REBASING;
+ if (new File(getDirectory(),"rebase-apply/applying").exists())
+ return RepositoryState.APPLY;
+ if (new File(getDirectory(),"rebase-apply").exists())
+ return RepositoryState.REBASING;
+
+ if (new File(getDirectory(),"rebase-merge/interactive").exists())
+ return RepositoryState.REBASING_INTERACTIVE;
+ if (new File(getDirectory(),"rebase-merge").exists())
+ return RepositoryState.REBASING_MERGE;
+
+ // Both versions
if (new File(gitDir,"MERGE_HEAD").exists())
return RepositoryState.MERGING;
if (new File(gitDir,"BISECT_LOG").exists())
return RepositoryState.BISECTING;
+
return RepositoryState.SAFE;
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryState.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryState.java
index c32c381..a916924 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryState.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryState.java
@@ -40,6 +40,9 @@
/**
* Important state of the repository that affects what can and cannot bed
* done. This is things like unhandled conflicted merges and unfinished rebase.
+ *
+ * The granularity and set of states are somewhat arbitrary. The methods
+ * on the state are the only supported means of deciding what to do.
*/
public enum RepositoryState {
/**
@@ -62,7 +65,7 @@
},
/**
- * An unfinished rebase. Must resolve, skip or abort before normal work can take place
+ * An unfinished rebase or am. Must resolve, skip or abort before normal work can take place
*/
REBASING {
public boolean canCheckout() { return false; }
@@ -72,6 +75,26 @@
},
/**
+ * An unfinished rebase. Must resolve, skip or abort before normal work can take place
+ */
+ REBASING_REBASING {
+ public boolean canCheckout() { return false; }
+ public boolean canResetHead() { return false; }
+ public boolean canCommit() { return true; }
+ public String getDescription() { return "Rebase"; }
+ },
+
+ /**
+ * An unfinished apply. Must resolve, skip or abort before normal work can take place
+ */
+ APPLY {
+ public boolean canCheckout() { return false; }
+ public boolean canResetHead() { return false; }
+ public boolean canCommit() { return true; }
+ public String getDescription() { return "Apply mailbox"; }
+ },
+
+ /**
* An unfinished rebase with merge. Must resolve, skip or abort before normal work can take place
*/
REBASING_MERGE {
--
1.6.0.2.308.gef4a
^ permalink raw reply related
* Re: [PATCH, RFC] diff: add option to show context between close chunks
From: René Scharfe @ 2008-10-21 20:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <48FD721D.9030105@viscovery.net>
Johannes Sixt schrieb:
> René Scharfe schrieb:
>> I have to admit my main motivation was that one line gap, where a chunk
>> header hid an interesting line of context. Showing it didn't change the
>> length of the patch, so I found this to be a sad wastage.
>
> "Wastage" is relative. For a given patch, the one line of context that was
> hidden by the hunk header would be welcome by a human reader, but it is
> not necessarily useful if the patch is to be applied, in particular, if it
> is applied to a version of the file that has *more* than one line between
> the hunk contexts. This is the reason that diff does not produce 7 lines
> of context between changes in -U3 mode ("you asked for 3 lines of context,
> you get 3 lines of context").
Yes, that's an interesting example of the possible "merge conflicts" I
mentioned in my original mail, and one I didn't think of. And since I
don't do any merges myself, I don't know how much of a problem this is.
As Daniel writes, one could teach git-apply to ignore extra context. It
should even be possible to infer the -U option used to create a patch
and to remove any extra lines (which might get complicated for patches
that change both the start and the end of a file, though).
Also, I'd like to know how many patches of a given repo would be have
created such a problem, but I can't think of a way to count them at the
moment. I need some sleep first.
> BTW, nomenclature seems to have settled at the word "hunk", not "chunk".
While http://en.wikipedia.org/wiki/Diff uses both and defines "chunk" as
"change hunk", the GNU patch(1) manpage uses "hunk" throughout. "Hunk"
it is, then. :)
René
^ permalink raw reply
* Re: [PATCH, RFC] diff: add option to show context between close chunks
From: René Scharfe @ 2008-10-21 20:48 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, Git Mailing List, Davide Libenzi
In-Reply-To: <20081021112040.GB17363@coredump.intra.peff.net>
Jeff King schrieb:
> On Tue, Oct 21, 2008 at 12:12:17AM -0700, Junio C Hamano wrote:
>
>> Yeah. René wanted this for _human consumption_, not mechanical patch
>> application, so "hardcoding" literally there in the very low level of the
>> diff callchain is not quite right (it would affect format-patch which is
>> primarily for mechanical application).
>>
>> I guess you could make the hardcoded value 1 for everybody else and 0 for
>> format-patch.
>
> I see your reasoning, but at the same time, a large portion of patches I
> read are from format-patch (and René even said that he was trying to
> save the user from the "apply then diff just to look at the patch"
> annoyance). And I have personally, as a patch submitter, created some
> format-patch output sent to the git list with -U5 to combine hunks and
> make it more readable for reviewers.
>
> Not to mention that I sometimes apply or post the output of "git diff".
Well, yes, perhaps I was trying to get ahead of myself. I sure would
like to see everyone create patches with fused hunks (because they are
easier to read), but step 1 is to have the option to create such patches
at all. We should then try it out for some time or verify its
usefulness statistically and only then turn it on by default. Or
perhaps throw it away, depending on the results.
And I consider the output of format-patch and git-diff to be intended
primarily for human consumption.
> To me that it implies that either:
>
> - the increased chance of conflict is not a problem in practice, and we
> should have the option on by default everywhere
>
> - it is a problem, in which case we should ask the user to turn on the
> feature manually instead of second-guessing how they will use the
> resulting patch (which they might not even know, since they are
> making assumptions about how other people might use the patch, and
> they must decide for their situation between shipping something that
> is more readable but slightly more conflict prone, or as easy to
> apply as possible)
To decide which one it is, I'd like to see numbers: how many times would
a patch with fused hunks have led to a problem for e.g. the kernel repo?
What is the optimal default value (0, 1, even more)? Before even
thinking about how to get these stats, I'd better head for bed for
today, though..
René
^ permalink raw reply
* [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Alexander Gavrilov @ 2008-10-21 20:55 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Currently git-blame outputs text from the commit messages
(e.g. the author name and the summary string) as-is, without
even providing any information about the encoding used for
the data. It makes interpreting the data in multilingual
environment very difficult.
This commit changes the blame implementation to recode the
messages using the rules used by other commands like git-log.
Namely, the target encoding can be specified through the
i18n.commitEncoding or i18n.logOutputEncoding options, or
directly on the command line using the --encoding parameter.
Converting the encoding before output seems to be more
friendly to the porcelain tools than simply providing the
value of the encoding header, and does not require changing
the output format.
If anybody needs the old behavior, it is possible to
achieve it by specifying --encoding=none.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
I intentionally forced binary encoding for files
with the localized strings, to avoid any possible
corruption.
-- Alexander
Documentation/blame-options.txt | 7 +++
Documentation/i18n.txt | 6 +-
builtin-blame.c | 16 +++++--
commit.h | 2 +
pretty.c | 21 ++++++---
t/t8005-blame-i18n.sh | 92 +++++++++++++++++++++++++++++++++++++++
t/t8005/cp1251.txt | Bin 0 -> 68 bytes
t/t8005/sjis.txt | Bin 0 -> 100 bytes
t/t8005/utf8.txt | Bin 0 -> 100 bytes
9 files changed, 130 insertions(+), 14 deletions(-)
create mode 100755 t/t8005-blame-i18n.sh
create mode 100644 t/t8005/cp1251.txt
create mode 100644 t/t8005/sjis.txt
create mode 100644 t/t8005/utf8.txt
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 5428111..1ab1b96 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -49,6 +49,13 @@ of lines before or after the line given by <start>.
Show the result incrementally in a format designed for
machine consumption.
+--encoding=<encoding>::
+ Specifies the encoding used to output author names
+ and commit summaries. Setting it to `none` makes blame
+ output unconverted data. For more information see the
+ discussion about encoding in the linkgit:git-log[1]
+ manual page.
+
--contents <file>::
When <rev> is not specified, the command annotates the
changes starting backwards from the working tree copy.
diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
index d2970f8..2cdacd9 100644
--- a/Documentation/i18n.txt
+++ b/Documentation/i18n.txt
@@ -37,9 +37,9 @@ of `i18n.commitencoding` in its `encoding` header. This is to
help other people who look at them later. Lack of this header
implies that the commit log message is encoded in UTF-8.
-. 'git-log', 'git-show' and friends looks at the `encoding`
- header of a commit object, and tries to re-code the log
- message into UTF-8 unless otherwise specified. You can
+. 'git-log', 'git-show', 'git-blame' and friends look at the
+ `encoding` header of a commit object, and try to re-code the
+ log message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
`i18n.logoutputencoding` in `.git/config` file, like this:
+
diff --git a/builtin-blame.c b/builtin-blame.c
index 48cc0c1..2457e71 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1431,7 +1431,7 @@ static void get_commit_info(struct commit *commit,
int detailed)
{
int len;
- char *tmp, *endp;
+ char *tmp, *endp, *reencoded, *message;
static char author_buf[1024];
static char committer_buf[1024];
static char summary_buf[1024];
@@ -1449,24 +1449,29 @@ static void get_commit_info(struct commit *commit,
die("Cannot read commit %s",
sha1_to_hex(commit->object.sha1));
}
+ reencoded = reencode_commit_message(commit, NULL);
+ message = reencoded ? reencoded : commit->buffer;
ret->author = author_buf;
- get_ac_line(commit->buffer, "\nauthor ",
+ get_ac_line(message, "\nauthor ",
sizeof(author_buf), author_buf, &ret->author_mail,
&ret->author_time, &ret->author_tz);
- if (!detailed)
+ if (!detailed) {
+ free(reencoded);
return;
+ }
ret->committer = committer_buf;
- get_ac_line(commit->buffer, "\ncommitter ",
+ get_ac_line(message, "\ncommitter ",
sizeof(committer_buf), committer_buf, &ret->committer_mail,
&ret->committer_time, &ret->committer_tz);
ret->summary = summary_buf;
- tmp = strstr(commit->buffer, "\n\n");
+ tmp = strstr(message, "\n\n");
if (!tmp) {
error_out:
sprintf(summary_buf, "(%s)", sha1_to_hex(commit->object.sha1));
+ free(reencoded);
return;
}
tmp += 2;
@@ -1478,6 +1483,7 @@ static void get_commit_info(struct commit *commit,
goto error_out;
memcpy(summary_buf, tmp, len);
summary_buf[len] = 0;
+ free(reencoded);
}
/*
diff --git a/commit.h b/commit.h
index 4c05864..3a7b06a 100644
--- a/commit.h
+++ b/commit.h
@@ -65,6 +65,8 @@ enum cmit_fmt {
extern int non_ascii(int);
struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
+extern char *reencode_commit_message(const struct commit *commit,
+ const char **encoding_p);
extern void get_commit_format(const char *arg, struct rev_info *);
extern void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
diff --git a/pretty.c b/pretty.c
index 1e79943..f6ff312 100644
--- a/pretty.c
+++ b/pretty.c
@@ -783,6 +783,20 @@ void pp_remainder(enum cmit_fmt fmt,
}
}
+char *reencode_commit_message(const struct commit *commit, const char **encoding_p)
+{
+ const char *encoding;
+
+ encoding = (git_log_output_encoding
+ ? git_log_output_encoding
+ : git_commit_encoding);
+ if (!encoding)
+ encoding = "utf-8";
+ if (encoding_p)
+ *encoding_p = encoding;
+ return logmsg_reencode(commit, encoding);
+}
+
void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
struct strbuf *sb, int abbrev,
const char *subject, const char *after_subject,
@@ -799,12 +813,7 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
return;
}
- encoding = (git_log_output_encoding
- ? git_log_output_encoding
- : git_commit_encoding);
- if (!encoding)
- encoding = "utf-8";
- reencoded = logmsg_reencode(commit, encoding);
+ reencoded = reencode_commit_message(commit, &encoding);
if (reencoded) {
msg = reencoded;
}
diff --git a/t/t8005-blame-i18n.sh b/t/t8005-blame-i18n.sh
new file mode 100755
index 0000000..4470a92
--- /dev/null
+++ b/t/t8005-blame-i18n.sh
@@ -0,0 +1,92 @@
+#!/bin/sh
+
+test_description='git blame encoding conversion'
+. ./test-lib.sh
+
+. "$TEST_DIRECTORY"/t8005/utf8.txt
+. "$TEST_DIRECTORY"/t8005/cp1251.txt
+. "$TEST_DIRECTORY"/t8005/sjis.txt
+
+test_expect_success 'setup the repository' '
+ # Create the file
+ echo "UTF-8 LINE" > file &&
+ git add file &&
+ git commit --author "$UTF8_NAME <utf8@localhost>" -m "$UTF8_MSG" &&
+
+ echo "CP1251 LINE" >> file &&
+ git add file &&
+ git config i18n.commitencoding cp1251 &&
+ git commit --author "$CP1251_NAME <cp1251@localhost>" -m "$CP1251_MSG" &&
+
+ echo "SJIS LINE" >> file &&
+ git add file &&
+ git config i18n.commitencoding shift-jis &&
+ git commit --author "$SJIS_NAME <sjis@localhost>" -m "$SJIS_MSG"
+'
+
+cat >expected <<EOF
+author $SJIS_NAME
+summary $SJIS_MSG
+author $SJIS_NAME
+summary $SJIS_MSG
+author $SJIS_NAME
+summary $SJIS_MSG
+EOF
+
+test_expect_success \
+ 'blame respects i18n.commitencoding' '
+ git blame --incremental file | \
+ grep "^\(author\|summary\) " > actual &&
+ test_cmp actual expected
+'
+
+cat >expected <<EOF
+author $CP1251_NAME
+summary $CP1251_MSG
+author $CP1251_NAME
+summary $CP1251_MSG
+author $CP1251_NAME
+summary $CP1251_MSG
+EOF
+
+test_expect_success \
+ 'blame respects i18n.logoutputencoding' '
+ git config i18n.logoutputencoding cp1251 &&
+ git blame --incremental file | \
+ grep "^\(author\|summary\) " > actual &&
+ test_cmp actual expected
+'
+
+cat >expected <<EOF
+author $UTF8_NAME
+summary $UTF8_MSG
+author $UTF8_NAME
+summary $UTF8_MSG
+author $UTF8_NAME
+summary $UTF8_MSG
+EOF
+
+test_expect_success \
+ 'blame respects --encoding=utf-8' '
+ git blame --incremental --encoding=utf-8 file | \
+ grep "^\(author\|summary\) " > actual &&
+ test_cmp actual expected
+'
+
+cat >expected <<EOF
+author $SJIS_NAME
+summary $SJIS_MSG
+author $CP1251_NAME
+summary $CP1251_MSG
+author $UTF8_NAME
+summary $UTF8_MSG
+EOF
+
+test_expect_success \
+ 'blame respects --encoding=none' '
+ git blame --incremental --encoding=none file | \
+ grep "^\(author\|summary\) " > actual &&
+ test_cmp actual expected
+'
+
+test_done
diff --git a/t/t8005/cp1251.txt b/t/t8005/cp1251.txt
new file mode 100644
index 0000000000000000000000000000000000000000..ce41e98b811b09c135115529b41e227ce5ec4ff6
GIT binary patch
literal 68
zcmZ<`Ff=kXjQ4Z&b+uJG@#w)@h4W88eR%ii#dn2^FP^*uvXr=-A!>Ys-EEaFJ^lFU
W-J^F;6+XUu_weV_w=bS5aRC6=1t)(1
literal 0
HcmV?d00001
diff --git a/t/t8005/sjis.txt b/t/t8005/sjis.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2ccfbad207c6e96b1f4f528031d9e4938d364b92
GIT binary patch
literal 100
zcmWIc@(hmmbM$q!Rci5UDQYQbsZ(ePXen)JX=!R{018yLbSkt20jUxo7c8X26%5kk
k8|)6$6AV<^3{(tK+R##}0OT|PVPQ)*P@)c~tyGB%00x;U@Bjb+
literal 0
HcmV?d00001
diff --git a/t/t8005/utf8.txt b/t/t8005/utf8.txt
new file mode 100644
index 0000000000000000000000000000000000000000..f46cfc56d80797740c3ec15e166add052f905fcb
GIT binary patch
literal 100
zcmWFyakGf`bM$q!Rk|?a!lnxwF6>pfF#p2Vi%l0BF6;ve?6}yjaADzv9T&D-*as0(
t;tB<6@(p$e>RAL-+IX=EtaRUntqK<#fy{juHeT$!u=T=Tpth|_TmU(XJDmUk
literal 0
HcmV?d00001
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Eric Wong @ 2008-10-21 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, git, jsogo
In-Reply-To: <20081018224728.GD3107@atjola.homenet>
Thanks to Jose Carlos Garcia Sogo and Björn Steinbrink for the
bug report.
On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote:
> Hi,
>
> Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
> svn repo fails for him:
> https://sucs.org/~welshbyte/svn/backuptool/trunk
>
> I can reproduce that here with:
> git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
>
> The error message I get is:
> Apache got a malformed URI: Unusable URI: it does not refer to this
> repository at /usr/local/libexec/git-core/git-svn line 4057
>
> 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>...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
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 {
my ($uri) = @_;
my @tmp;
foreach (split m{/}, $uri) {
- s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
+ s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
push @tmp, $_;
}
join('/', @tmp);
@@ -3537,7 +3537,7 @@ sub repo_path {
sub url_path {
my ($self, $path) = @_;
if ($self->{url} =~ m#^https?://#) {
- $path =~ s/([^a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg;
+ $path =~ s/([^~a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg;
}
$self->{url} . '/' . $self->repo_path($path);
}
@@ -3890,7 +3890,7 @@ sub escape_uri_only {
my ($uri) = @_;
my @tmp;
foreach (split m{/}, $uri) {
- s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
+ s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
push @tmp, $_;
}
join('/', @tmp);
--
Eric Wong
^ permalink raw reply related
* Re: git 1.6.0.2 make test fails at t1301 under mac os x 10.4.
From: Johannes Schindelin @ 2008-10-21 21:24 UTC (permalink / raw)
To: Fergus McMenemie; +Cc: git
In-Reply-To: <p06240800c523ac94cb4d@[192.168.47.9]>
Hi,
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
^ permalink raw reply
* 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
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