* Re: The imporantance of including http credential caching in 1.7.7
From: John Szakmeister @ 2011-09-09 10:54 UTC (permalink / raw)
To: kusmabite; +Cc: git, Kyle Neath, Jeff King
In-Reply-To: <CABPQNSbrjNR73GxE4xXFPqaVSUOaa5Drt4Je+zGY82rzajQxuw@mail.gmail.com>
On Fri, Sep 9, 2011 at 6:48 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
[snip]
> Actually, it seems recent Windows versions does have a credential
> manager, including an API:
>
> http://www.yanzzee.com/2009/09/windows-keychain.html
> http://msdn.microsoft.com/en-us/library/aa374731(v=VS.85).aspx#credentials_management_functions
Yay! It's about time they grew that feature. :-)
-John
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Erik Faye-Lund @ 2011-09-09 10:48 UTC (permalink / raw)
To: John Szakmeister; +Cc: git, Kyle Neath, Jeff King
In-Reply-To: <CAEBDL5VtVZcmQnj2CH7XzZ0YV_X61gO69-dXriGiYsAqk=NLPg@mail.gmail.com>
On Fri, Sep 9, 2011 at 12:32 PM, John Szakmeister <john@szakmeister.net> wrote:
> [Added back some of the CC's]
>
> Ted: we don't usually cull the CC list on the git mailing list.
>
> 2011/9/9 Ted Zlatanov <tzz@lifelogs.com>:
> [snip]
>> MJG> ... and one for Git on Windows? It seems we're lacking both Win and OS X
>> MJG> developers here.
>>
>> Windows doesn't have a standard keychain service, does it?
>
> No, it doesn't, but you can use the wincrypt API which allows you to
> at least encrypt the password from the user's login credentials. In
> particular, CryptProtectData() and CryptUnprotectData(). That way you
> can at least have the password stored encrypted on disk.
Actually, it seems recent Windows versions does have a credential
manager, including an API:
http://www.yanzzee.com/2009/09/windows-keychain.html
http://msdn.microsoft.com/en-us/library/aa374731(v=VS.85).aspx#credentials_management_functions
^ permalink raw reply
* Re: can Git encrypt/decrypt .gpg on push/fetch?
From: Aneesh Bhasin @ 2011-09-09 10:50 UTC (permalink / raw)
To: tzz; +Cc: git
In-Reply-To: <87lityxbg7.fsf@lifelogs.com>
Hi Ted,
2011/9/9 Ted Zlatanov <tzz@lifelogs.com>
>
> I need to store some encrypted files in Git but for some clients with
> the right GPG keys, decrypt them on checkout (possibly also encrypt them
> back on commit, but that's not as important).
>
> diff doesn't have to work, this is just for convenience. Can Git do
> this (matching only .gpg files) or do I need my own command to run after
> the checkout/fetch and before commit? It seems pretty out of Git's
> scope but perhaps others have done this before.
>
Have you looked at git hooks (e.g. here : http://progit.org/book/ch7-3.html).
You could do the encryption/decryption in pre-commit and post-checkout
hooks scripts respectively...
regards,
Aneesh
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: John Szakmeister @ 2011-09-09 10:32 UTC (permalink / raw)
To: git; +Cc: Kyle Neath, Jeff King
In-Reply-To: <87pqjaxbrm.fsf@lifelogs.com>
[Added back some of the CC's]
Ted: we don't usually cull the CC list on the git mailing list.
2011/9/9 Ted Zlatanov <tzz@lifelogs.com>:
[snip]
> MJG> ... and one for Git on Windows? It seems we're lacking both Win and OS X
> MJG> developers here.
>
> Windows doesn't have a standard keychain service, does it?
No, it doesn't, but you can use the wincrypt API which allows you to
at least encrypt the password from the user's login credentials. In
particular, CryptProtectData() and CryptUnprotectData(). That way you
can at least have the password stored encrypted on disk.
-John
^ permalink raw reply
* can Git encrypt/decrypt .gpg on push/fetch?
From: Ted Zlatanov @ 2011-09-09 10:22 UTC (permalink / raw)
To: git
I need to store some encrypted files in Git but for some clients with
the right GPG keys, decrypt them on checkout (possibly also encrypt them
back on commit, but that's not as important).
diff doesn't have to work, this is just for convenience. Can Git do
this (matching only .gpg files) or do I need my own command to run after
the checkout/fetch and before commit? It seems pretty out of Git's
scope but perhaps others have done this before.
Thanks
Ted
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Ted Zlatanov @ 2011-09-09 10:15 UTC (permalink / raw)
To: git
In-Reply-To: <4E69C8F0.9070204@drmicha.warpmail.net>
On Fri, 09 Sep 2011 10:06:08 +0200 Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> In the meantime, the best thing we can do to push it forward is to write
>> helpers. I implemented some basic ones that should work anywhere, but
>> aren't as nice as integration with existing keychains. Some people are
>> working on Linux ones. The single best thing GitHub can do to push this
>> forward right now is to provide a well-written OS X Keychain helper, and
>> to provide feedback on whether git's end of the API is good enough.
MJG> ... and one for Git on Windows? It seems we're lacking both Win and OS X
MJG> developers here.
Windows doesn't have a standard keychain service, does it?
The OS X Keychain helper should be pretty easy in terms of the system
calls (he says after a quick Google search), the hard part IMHO is
figuring out the right way to store credentials in it. There are
several ways to structure the schema.
For modern Linux systems it's best to target the Secrets API, which is
DBUS and XML-based and works with both the KDE and GNOME keychains. I
only know about it what I have learned from Michael Albinus' interface
in the Emacs source tree, but it certainly seems capable enough. This
is what Jeff King was alluding to, I think, about what I'm working on.
I have not been able to work on it so far, not for lack of trying.
My #1 target is to implement a GPG-based credential helper using a
netrc-style file. I believe that would be the most useful one, though
not the easiest one to set up for inexperienced users.
Ted
^ permalink raw reply
* [PATCH v3] date.c: Support iso8601 timezone formats
From: Haitao Li @ 2011-09-09 10:10 UTC (permalink / raw)
To: gitster; +Cc: Haitao Li, git
In-Reply-To: <1315320996-1997-1-git-send-email-lihaitao@gmail.com>
Timezone designators including additional separator (`:`) are ignored.
Actually zone designators in below formats are all valid according to
ISO8601:2004, section 4.3.2:
[+-]hh, [+-]hhmm, [+-]hh:mm
Steps to reproduce the issue this patch fixes:
$ mkdir /tmp/test
$ cd /tmp/test
$ git init
$ echo 'timezone' > file.txt
$ git add .
$ git update-index
$ git write-tree
3e168d57e1c32a4598af134430384f0587581503
# Commit the tree returned above. Give a date with colon separated
# timezone
$ echo "Test commit" | \
TZ=UTC GIT_AUTHOR_DATE='2011-09-03T12:34:56+08:00' \
git commit-tree 3e168d57e1c32a4598af134430384f0587581503 | \
xargs git show | grep Date
Date: Sat Sep 3 12:34:56 2011 +0000
while the expected result is:
Date: Sat Sep 3 12:34:56 2011 +0800
^---
This patch teaches git recognizing zone designators with hours and
minutes separated by colon, or minutes are empty.
Signed-off-by: Haitao Li <lihaitao@gmail.com>
---
date.c | 32 ++++++++++++++++++++++++++------
t/t0006-date.sh | 5 +++++
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/date.c b/date.c
index 896fbb4..f8722c1 100644
--- a/date.c
+++ b/date.c
@@ -556,15 +556,35 @@ static int match_tz(const char *date, int *offp)
int min, hour;
int n = end - date - 1;
- min = offset % 100;
- hour = offset / 100;
+ /*
+ * ISO8601:2004(E) allows time zone designator been separated
+ * by a clone in the extended format
+ */
+ if (*end == ':') {
+ if (isdigit(end[1])) {
+ hour = offset;
+ min = strtoul(end+1, &end, 10);
+ } else {
+ /* Mark as invalid */
+ n = -1;
+ }
+ } else {
+ if (n == 1 || n == 2) {
+ /* Only hours specified */
+ hour = offset;
+ min = 0;
+ } else {
+ hour = offset / 100;
+ min = offset % 100;
+ }
+ }
/*
- * Don't accept any random crap.. At least 3 digits, and
- * a valid minute. We might want to check that the minutes
- * are divisible by 30 or something too.
+ * Don't accept any random crap.. We might want to check that
+ * the minutes are divisible by 15 or something too. (Offset of
+ * Kathmandu, Nepal is UTC+5:45)
*/
- if (min < 60 && n > 2) {
+ if (n > 0 && min < 60) {
offset = hour*60+min;
if (*date == '-')
offset = -offset;
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index f87abb5..5235b7a 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -40,6 +40,11 @@ check_parse 2008-02 bad
check_parse 2008-02-14 bad
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015'
+check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +0000'
+check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
check_approxidate() {
--
1.7.5.4
^ permalink raw reply related
* Re: git-p4.skipSubmitEdit
From: Vitor Antunes @ 2011-09-09 10:05 UTC (permalink / raw)
To: git
In-Reply-To: <1315514452.10046.0.camel@uncle-pecos>
L. A. Linden Levy <alevy <at> mobitv.com> writes:
>
> Hi All,
>
> I have been using git-p4 for a while and it has allowed me to completely
> change the way I develop and still be able to use perforce which my
> company has for its main VCS. One thing that was driving me nuts was
> that "git p4 submit" cycles through all of my individual commits and
> asks me if I want to change them. The way I develop I often am checking
> in 20 to 50 different small commits each with a descriptive git comment.
> I felt like I was doing double duty by having emacs open on every commit
> into perforce. So I modified git-p4 to have an option to skip the
> editor. This option coupled with git-p4.skipSubmitEditCheck will make
> the submission non-interactive for "git p4 submit".
Hi Loren,
This option was already included in a recent commit. The name that was
used is "skipSubmitEditCheck". Please make sure you are using the most
recent version of the script.
But don't let this discourage you from submitting patches. Just makesure
you clone git's repository and apply your patch over "maint" or "master"
branches. For more details on how to submit patches you can read
Documentation/SubmittingPatches.
Vitor
^ permalink raw reply
* Re: git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)]
From: John Szakmeister @ 2011-09-09 9:55 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Lukas Sandström, Ted Zlatanov, git
In-Reply-To: <20110831023801.GB3340@sigill.intra.peff.net>
On Tue, Aug 30, 2011 at 10:38 PM, Jeff King <peff@peff.net> wrote:
[snip]
> It's "http:github.com", which has always looked a bit ugly to me. I had
> hoped they would just be opaque blobs and nobody would need to look at
> them. But when you get into things like setting the username via the
> config, then users see them, and they need to look sane. Making them
> look more like a canonicalized URL is probably a good thing.
A little feedback here: I do look into my keychain on Mac OS X. I
tend to keep most of my credentials in a separate keychain that gets
whenever my computer sleeps or the screen saver kicks on. So that
blob ends up being user-visible to some degree. Could I munge it into
something else? Sure. But I do wonder if it might be better to make
it something closer to what the user expects to see.
> After seeing the helper that Lukas posted recently on the list, I am
> wondering if they should include the username, too. I had left it
> separate, because I wanted helpers to be able to index "foo@example.com"
> and "example.com" in the same slot. I.e., to realize that the latter
> could use the same credentials cached for the former. But it also
> complicates the helpers; instead of doing:
Having the username separate is useful. At least under Mac OS X, the
"account name" field is a separate search field. It does make it
easier to fallback to just looking at the domain and path without
having to parse the unique token. But as it is, we stand a chance at
being able to reuse credentials already cached by the browser.
> credential = secure_storage_lookup(unique_token);
> return credential /* could be NULL */
>
> they have to do:
>
> for credential in secure_storage_lookup(unique_token) {
> if (!username)
> return credential; /* take first one arbitrarily */
> else if (username == credential.username)
> return credential; /* ok, matched preferred username */
> }
> return NULL;
>
> which implies that the secure storage can even store a list indexed
> under the token.
>
> So perhaps a better model is to give the helper some canonicalized URL,
> like:
>
> https://foo@example.com
>
> (where the canonicalization is important, because we want the helper to
> be able to just treat it like a string of bytes if it wants). And then
> we can naturally extend that to:
>
> https://foo@example.com/specific-repo.git
>
> if the user wants a repo-specific authentication context.
Or pass that the information via --domain and --path parameters. It'd
be nice to keep most credential backends from having to parse urls.
Not that its hard, just cumbersome. But the keychain implementation
and the gnome-keyring implementation could both benefit from having
the pieces broken out separately. Likewise, it's probably not
difficult to parse it out of the token if we needed to.
[snip good discussion]
One thing that crossed my mind while looking at this: what happens
when a command is meant to be non-interactive? Looking at the
kdewallet implementation, it appears that not only is the credential
helper intended to help do the lookup, but also ask the user for a
password, if it doesn't find anything. That doesn't seem like it
would play well in a non-interactive environment. Additionally, the
act of looking up the entry could pop up a dialog in most
keychain-like applications. Is there a need to be sensitive to the
fact that we may be run non-interactively?
-John
^ permalink raw reply
* [PATCH 2/2] pretty: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-09 8:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Alexey Shumkin
In-Reply-To: <1315558437-6295-1-git-send-email-zapped@mail.ru>
The following two ought to give the same output to a terminal:
$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'
However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format "%s". A log
messages written in an encoding i18n.commitEncoding that differs
from terminal encoding are shown corrupted with the latter even
when i18n.logOutputEncoding and terminal encoding are the same.
The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
builtin/rev-list.c | 1 +
builtin/shortlog.c | 1 +
log-tree.c | 1 +
submodule.c | 3 +++
4 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 56727e8..831077d 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -105,6 +105,7 @@ static void show_commit(struct commit *commit, void *data)
ctx.abbrev = revs->abbrev;
ctx.date_mode = revs->date_mode;
ctx.fmt = revs->commit_format;
+ ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(&ctx, commit, &buf);
if (revs->graph) {
if (buf.len) {
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index 37f3193..eba4086 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -163,6 +163,7 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
ctx.subject = "";
ctx.after_subject = "";
ctx.date_mode = DATE_NORMAL;
+ ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(&ctx, commit, &ufbuf);
buffer = ufbuf.buf;
} else if (*buffer) {
diff --git a/log-tree.c b/log-tree.c
index e945701..39913d7 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -488,6 +488,7 @@ void show_log(struct rev_info *opt)
ctx.preserve_subject = opt->preserve_subject;
ctx.reflog_info = opt->reflog_info;
ctx.fmt = opt->commit_format;
+ ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(&ctx, commit, &msgbuf);
if (opt->add_signoff)
diff --git a/submodule.c b/submodule.c
index b6dec70..26efef4 100644
--- a/submodule.c
+++ b/submodule.c
@@ -213,10 +213,13 @@ static void print_submodule_summary(struct rev_info *rev, FILE *f,
static const char format[] = " %m %s";
struct strbuf sb = STRBUF_INIT;
struct commit *commit;
+ const char *log_output_encoding;
+ log_output_encoding = get_log_output_encoding();
while ((commit = get_revision(rev))) {
struct pretty_print_context ctx = {0};
ctx.date_mode = rev->date_mode;
+ ctx.output_encoding = log_output_encoding;
strbuf_setlen(&sb, 0);
if (commit->object.flags & SYMMETRIC_LEFT) {
if (del)
--
1.7.6.1.g8f21c
^ permalink raw reply related
* [PATCH 1/2] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-09 8:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Alexey Shumkin
In-Reply-To: <1315558437-6295-1-git-send-email-zapped@mail.ru>
The following two ought to give the same output to a terminal:
$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'
However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format "%s". A log
messages written in an encoding i18n.commitEncoding that differs
from terminal encoding are shown corrupted with the latter even
when i18n.logOutputEncoding and terminal encoding are the same.
The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
t/t4041-diff-submodule-option.sh | 44 +++++----
t/t4205-log-pretty-formats.sh | 22 ++++-
t/t6006-rev-list-format.sh | 192 +++++++++++++++++++++++---------------
3 files changed, 161 insertions(+), 97 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index bf9a752..4460cff 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -1,6 +1,7 @@
#!/bin/sh
#
# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+# Copyright (c) 2011 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
#
test_description='Support for verbose submodule differences in git diff
@@ -10,6 +11,7 @@ This test tries to verify the sanity of the --submodule option of git diff.
. ./test-lib.sh
+added=$(printf "\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275")
add_file () {
sm=$1
shift
@@ -19,8 +21,12 @@ add_file () {
echo "$name" > "$name" &&
git add "$name" &&
test_tick &&
- git commit -m "Add $name"
+ git config i18n.commitEncoding cp1251 &&
+ echo "Add $name ($added $name)" \
+ | iconv -f utf-8 -t cp1251 \
+ | xargs -I{} git commit -m "{}"
done >/dev/null
+ git config --unset i18n.commitEncoding
git rev-parse --verify HEAD | cut -c1-7
cd "$owd"
}
@@ -37,7 +43,7 @@ head1=$(add_file sm1 foo1 foo2)
test_expect_success 'added submodule' "
git add sm1 &&
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 0000000...$head1 (new submodule)
EOF
test_cmp expected actual
@@ -48,27 +54,27 @@ head2=$(add_file sm1 foo3)
test_expect_success 'modified submodule(forward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head1..$head2:
- > Add foo3
+ > Add foo3 ($added foo3)
EOF
test_cmp expected actual
"
test_expect_success 'modified submodule(forward)' "
git diff --submodule=log >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head1..$head2:
- > Add foo3
+ > Add foo3 ($added foo3)
EOF
test_cmp expected actual
"
test_expect_success 'modified submodule(forward) --submodule' "
git diff --submodule >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head1..$head2:
- > Add foo3
+ > Add foo3 ($added foo3)
EOF
test_cmp expected actual
"
@@ -98,10 +104,10 @@ head3=$(
test_expect_success 'modified submodule(backward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head2..$head3 (rewind):
- < Add foo3
- < Add foo2
+ < Add foo3 ($added foo3)
+ < Add foo2 ($added foo2)
EOF
test_cmp expected actual
"
@@ -110,12 +116,12 @@ head4=$(add_file sm1 foo4 foo5) &&
head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
test_expect_success 'modified submodule(backward and forward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head2...$head4:
- > Add foo5
- > Add foo4
- < Add foo3
- < Add foo2
+ > Add foo5 ($added foo5)
+ > Add foo4 ($added foo4)
+ < Add foo3 ($added foo3)
+ < Add foo2 ($added foo2)
EOF
test_cmp expected actual
"
@@ -131,10 +137,10 @@ mv sm1-bak sm1
test_expect_success 'typechanged submodule(submodule->blob), --cached' "
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 41fbea9...0000000 (submodule deleted)
+Submodule sm1 $head4...0000000 (submodule deleted)
diff --git a/sm1 b/sm1
new file mode 100644
-index 0000000..9da5fb8
+index 0000000..$head5
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -148,7 +154,7 @@ test_expect_success 'typechanged submodule(submodule->blob)' "
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
deleted file mode 100644
-index 9da5fb8..0000000
+index $head5..0000000
--- a/sm1
+++ /dev/null
@@ -1 +0,0 @@
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 2ae9faa..96e0229 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1,6 +1,7 @@
#!/bin/sh
#
# Copyright (c) 2010, Will Palmer
+# Copyright (c) 2011, Alexey Shumkin (+ non-UTF-8 commit encoding tests)
#
test_description='Test pretty formats'
@@ -11,10 +12,13 @@ test_expect_success 'set up basic repos' '
>bar &&
git add foo &&
test_tick &&
- git commit -m initial &&
+ git config i18n.commitEncoding cp1251 &&
+ printf "initial \320\272\320\276\320\274\320\274\320\270\321\202" \
+ | iconv -f utf-8 -t cp1251 | xargs -I{} git commit -m "{}" &&
git add bar &&
test_tick &&
- git commit -m "add bar"
+ git commit -m "add bar" &&
+ git config --unset i18n.commitEncoding
'
test_expect_success 'alias builtin format' '
@@ -38,6 +42,20 @@ test_expect_success 'alias user-defined format' '
test_cmp expected actual
'
+test_expect_success 'alias user-defined tformat with %s (cp1251 encoding)' '
+ git config i18n.logOutputEncoding cp1251 &&
+ git log --oneline >expected-s &&
+ git log --pretty="tformat:%h %s" >actual-s &&
+ git config --unset i18n.logOutputEncoding &&
+ test_cmp expected-s actual-s
+'
+
+test_expect_success 'alias user-defined tformat with %s (utf-8 encoding)' '
+ git log --oneline >expected-s &&
+ git log --pretty="tformat:%h %s" >actual-s &&
+ test_cmp expected-s actual-s
+'
+
test_expect_success 'alias user-defined tformat' '
git log --pretty="tformat:%h" >expected &&
git config pretty.test-alias "tformat:%h" &&
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index d918cc0..8d99635 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -1,13 +1,34 @@
#!/bin/sh
+# Copyright (c) 2009 Jens Lehmann
+# Copyright (c) 2011 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
+
test_description='git rev-list --pretty=format test'
. ./test-lib.sh
test_tick
+added=$(printf "added (\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275) foo")
+added_cp1251=$(echo "$added" | iconv -f utf-8 -t cp1251)
+changed=$(printf "changed (\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275) foo")
+changed_cp1251=$(echo "$changed" | iconv -f utf-8 -t cp1251)
+
test_expect_success 'setup' '
-touch foo && git add foo && git commit -m "added foo" &&
- echo changed >foo && git commit -a -m "changed foo"
+ touch foo &&
+ git add foo &&
+ git config i18n.commitEncoding cp1251 &&
+ git commit -m "$added_cp1251" &&
+ head1=$(git rev-parse --verify HEAD) &&
+ head1_7=$(echo $head1 | cut -c1-7) &&
+ echo "$changed" > foo &&
+ git commit -a -m "$changed_cp1251" &&
+ head2=$(git rev-parse --verify HEAD) &&
+ head2_7=$(echo $head2 | cut -c1-7) &&
+ tree2=$(git cat-file -p HEAD | grep tree | cut -f 2 -d" ") &&
+ tree2_7=$(echo $tree2 | cut -c1-7) &&
+ head2_parent=$(git cat-file -p HEAD | grep parent | cut -f 2 -d" ") &&
+ head2_parent_7=$(echo $head2_parent | cut -c1-7) &&
+ git config --unset i18n.commitEncoding
'
# usage: test_format name format_string <expected_output
@@ -19,49 +40,49 @@ test_cmp expect.$1 output.$1
"
}
-test_format percent %%h <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format percent %%h <<EOF
+commit $head2
%h
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
%h
EOF
-test_format hash %H%n%h <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-131a310eb913d107dd3c09a65d1651175898735d
-131a310
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
+test_format hash %H%n%h <<EOF
+commit $head2
+$head2
+$head2_7
+commit $head1
+$head1
+$head1_7
EOF
-test_format tree %T%n%t <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-fe722612f26da5064c32ca3843aa154bdb0b08a0
-fe72261
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format tree %T%n%t <<EOF
+commit $head2
+$tree2
+$tree2_7
+commit $head1
4d5fcadc293a348e88f777dc0920f11e7d71441c
4d5fcad
EOF
-test_format parents %P%n%p <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format parents %P%n%p <<EOF
+commit $head2
+$head1
+$head2_parent_7
+commit $head1
EOF
# we don't test relative here
-test_format author %an%n%ae%n%ad%n%aD%n%at <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format author %an%n%ae%n%ad%n%aD%n%at <<EOF
+commit $head2
A U Thor
author@example.com
Thu Apr 7 15:13:13 2005 -0700
Thu, 7 Apr 2005 15:13:13 -0700
1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
A U Thor
author@example.com
Thu Apr 7 15:13:13 2005 -0700
@@ -69,14 +90,14 @@ Thu, 7 Apr 2005 15:13:13 -0700
1112911993
EOF
-test_format committer %cn%n%ce%n%cd%n%cD%n%ct <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format committer %cn%n%ce%n%cd%n%cD%n%ct <<EOF
+commit $head2
C O Mitter
committer@example.com
Thu Apr 7 15:13:13 2005 -0700
Thu, 7 Apr 2005 15:13:13 -0700
1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
C O Mitter
committer@example.com
Thu Apr 7 15:13:13 2005 -0700
@@ -84,86 +105,105 @@ Thu, 7 Apr 2005 15:13:13 -0700
1112911993
EOF
-test_format encoding %e <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format encoding %e <<EOF
+commit $head2
+commit $head1
EOF
-test_format subject %s <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+expected=$(printf "commit $head2\n\
+$changed\n\
+commit $head1\n\
+$added
+")
+
+test_format subject %s <<EOF
+$expected
EOF
-test_format body %b <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format body %b <<EOF
+commit $head2
+commit $head1
EOF
-test_format raw-body %B <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
+expected=$(printf "commit $head2\n\
+$changed\n\
+\n\
+commit $head1\n\
+$added
+")
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+test_format raw-body %B <<EOF
+$expected
EOF
-test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<EOF
+commit $head2
^[[31mfoo^[[32mbar^[[34mbaz^[[mxyzzy
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
^[[31mfoo^[[32mbar^[[34mbaz^[[mxyzzy
EOF
-test_format advanced-colors '%C(red yellow bold)foo%C(reset)' <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format advanced-colors '%C(red yellow bold)foo%C(reset)' <<EOF
+commit $head2
^[[1;31;43mfoo^[[m
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
^[[1;31;43mfoo^[[m
EOF
-cat >commit-msg <<'EOF'
+iconv -f utf-8 -t cp1251 > commit-msg <<EOF
Test printing of complex bodies
This commit message is much longer than the others,
-and it will be encoded in iso8859-1. We should therefore
-include an iso8859 character: ¡bueno!
+and it will be encoded in cp1251. We should therefore
+include an cp1251 character: так вот!
EOF
+
test_expect_success 'setup complex body' '
-git config i18n.commitencoding iso8859-1 &&
- echo change2 >foo && git commit -a -F commit-msg
+ git config i18n.commitencoding cp1251 &&
+ echo change2 >foo && git commit -a -F commit-msg &&
+ head3=$(git rev-parse --verify HEAD) &&
+ head3_7=$(echo $head3 | cut -c1-7)
'
-test_format complex-encoding %e <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
-iso8859-1
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format complex-encoding %e <<EOF
+commit $head3
+cp1251
+commit $head2
+cp1251
+commit $head1
+cp1251
EOF
-test_format complex-subject %s <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
-Test printing of complex bodies
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+# unset commit encoding config
+# otherwise %e does not print encoding value
+# and following test fails
+git config --unset i18n.commitencoding
+
+expected=$(printf "commit $head3\n\
+Test printing of complex bodies\n\
+commit $head2\n\
+$changed\n\
+commit $head1\n\
+$added
+")
+
+test_format complex-subject %s <<EOF
+$expected
EOF
-test_format complex-body %b <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
+test_format complex-body %b <<EOF
+commit $head3
This commit message is much longer than the others,
-and it will be encoded in iso8859-1. We should therefore
-include an iso8859 character: ¡bueno!
+and it will be encoded in cp1251. We should therefore
+include an cp1251 character: так вот!
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head2
+commit $head1
EOF
test_expect_success '%x00 shows NUL' '
- echo >expect commit f58db70b055c5718631e5c61528b28b12090cdea &&
+ echo >expect commit $head3 &&
echo >>expect fooQbar &&
git rev-list -1 --format=foo%x00bar HEAD >actual.nul &&
nul_to_q <actual.nul >actual &&
@@ -210,12 +250,12 @@ test_expect_success 'add LF before non-empty (2)' '
test_expect_success 'add SP before non-empty (1)' '
git show -s --pretty=format:"%s% bThanks" HEAD^^ >actual &&
- test $(wc -w <actual) = 2
+ test $(wc -w <actual) = 3
'
test_expect_success 'add SP before non-empty (2)' '
git show -s --pretty=format:"%s% sThanks" HEAD^^ >actual &&
- test $(wc -w <actual) = 4
+ test $(wc -w <actual) = 6
'
test_expect_success '--abbrev' '
--
1.7.6.1.g8f21c
^ permalink raw reply related
* [PATCH v2] pretty: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-09 8:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vwrf6qh49.fsf@alter.siamese.dyndns.org>
Ooops! previuos message haven't Cc-ed to Junio.
This one is CC-ed.
I discovered two more commands affected with this bug.
So I reroll this patch and tests for it.
>>(question) Does this change affect other commands, most notably
>>format-patch, and if so how?
No, it does not affect format-patch
---
builtin/rev-list.c | 1 +
builtin/shortlog.c | 1 +
log-tree.c | 1 +
submodule.c | 3 +
t/t4041-diff-submodule-option.sh | 44 +++++----
t/t4205-log-pretty-formats.sh | 22 ++++-
t/t6006-rev-list-format.sh | 192 +++++++++++++++++++++++---------------
7 files changed, 167 insertions(+), 97 deletions(-)
^ permalink raw reply
* [PATCH 2/2] pretty: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-09 8:43 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin
In-Reply-To: <1315557806-5555-1-git-send-email-zapped@mail.ru>
The following two ought to give the same output to a terminal:
$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'
However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format "%s". A log
messages written in an encoding i18n.commitEncoding that differs
from terminal encoding are shown corrupted with the latter even
when i18n.logOutputEncoding and terminal encoding are the same.
The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
builtin/rev-list.c | 1 +
builtin/shortlog.c | 1 +
log-tree.c | 1 +
submodule.c | 3 +++
4 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 56727e8..831077d 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -105,6 +105,7 @@ static void show_commit(struct commit *commit, void *data)
ctx.abbrev = revs->abbrev;
ctx.date_mode = revs->date_mode;
ctx.fmt = revs->commit_format;
+ ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(&ctx, commit, &buf);
if (revs->graph) {
if (buf.len) {
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index 37f3193..eba4086 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -163,6 +163,7 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
ctx.subject = "";
ctx.after_subject = "";
ctx.date_mode = DATE_NORMAL;
+ ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(&ctx, commit, &ufbuf);
buffer = ufbuf.buf;
} else if (*buffer) {
diff --git a/log-tree.c b/log-tree.c
index e945701..39913d7 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -488,6 +488,7 @@ void show_log(struct rev_info *opt)
ctx.preserve_subject = opt->preserve_subject;
ctx.reflog_info = opt->reflog_info;
ctx.fmt = opt->commit_format;
+ ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(&ctx, commit, &msgbuf);
if (opt->add_signoff)
diff --git a/submodule.c b/submodule.c
index b6dec70..26efef4 100644
--- a/submodule.c
+++ b/submodule.c
@@ -213,10 +213,13 @@ static void print_submodule_summary(struct rev_info *rev, FILE *f,
static const char format[] = " %m %s";
struct strbuf sb = STRBUF_INIT;
struct commit *commit;
+ const char *log_output_encoding;
+ log_output_encoding = get_log_output_encoding();
while ((commit = get_revision(rev))) {
struct pretty_print_context ctx = {0};
ctx.date_mode = rev->date_mode;
+ ctx.output_encoding = log_output_encoding;
strbuf_setlen(&sb, 0);
if (commit->object.flags & SYMMETRIC_LEFT) {
if (del)
--
1.7.6.1.g8f21c
^ permalink raw reply related
* [PATCH 1/2] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-09 8:43 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin
In-Reply-To: <1315557806-5555-1-git-send-email-zapped@mail.ru>
The following two ought to give the same output to a terminal:
$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'
However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format "%s". A log
messages written in an encoding i18n.commitEncoding that differs
from terminal encoding are shown corrupted with the latter even
when i18n.logOutputEncoding and terminal encoding are the same.
The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
t/t4041-diff-submodule-option.sh | 44 +++++----
t/t4205-log-pretty-formats.sh | 22 ++++-
t/t6006-rev-list-format.sh | 192 +++++++++++++++++++++++---------------
3 files changed, 161 insertions(+), 97 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index bf9a752..4460cff 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -1,6 +1,7 @@
#!/bin/sh
#
# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+# Copyright (c) 2011 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
#
test_description='Support for verbose submodule differences in git diff
@@ -10,6 +11,7 @@ This test tries to verify the sanity of the --submodule option of git diff.
. ./test-lib.sh
+added=$(printf "\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275")
add_file () {
sm=$1
shift
@@ -19,8 +21,12 @@ add_file () {
echo "$name" > "$name" &&
git add "$name" &&
test_tick &&
- git commit -m "Add $name"
+ git config i18n.commitEncoding cp1251 &&
+ echo "Add $name ($added $name)" \
+ | iconv -f utf-8 -t cp1251 \
+ | xargs -I{} git commit -m "{}"
done >/dev/null
+ git config --unset i18n.commitEncoding
git rev-parse --verify HEAD | cut -c1-7
cd "$owd"
}
@@ -37,7 +43,7 @@ head1=$(add_file sm1 foo1 foo2)
test_expect_success 'added submodule' "
git add sm1 &&
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 0000000...$head1 (new submodule)
EOF
test_cmp expected actual
@@ -48,27 +54,27 @@ head2=$(add_file sm1 foo3)
test_expect_success 'modified submodule(forward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head1..$head2:
- > Add foo3
+ > Add foo3 ($added foo3)
EOF
test_cmp expected actual
"
test_expect_success 'modified submodule(forward)' "
git diff --submodule=log >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head1..$head2:
- > Add foo3
+ > Add foo3 ($added foo3)
EOF
test_cmp expected actual
"
test_expect_success 'modified submodule(forward) --submodule' "
git diff --submodule >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head1..$head2:
- > Add foo3
+ > Add foo3 ($added foo3)
EOF
test_cmp expected actual
"
@@ -98,10 +104,10 @@ head3=$(
test_expect_success 'modified submodule(backward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head2..$head3 (rewind):
- < Add foo3
- < Add foo2
+ < Add foo3 ($added foo3)
+ < Add foo2 ($added foo2)
EOF
test_cmp expected actual
"
@@ -110,12 +116,12 @@ head4=$(add_file sm1 foo4 foo5) &&
head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
test_expect_success 'modified submodule(backward and forward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
+ cat >expected <<EOF
Submodule sm1 $head2...$head4:
- > Add foo5
- > Add foo4
- < Add foo3
- < Add foo2
+ > Add foo5 ($added foo5)
+ > Add foo4 ($added foo4)
+ < Add foo3 ($added foo3)
+ < Add foo2 ($added foo2)
EOF
test_cmp expected actual
"
@@ -131,10 +137,10 @@ mv sm1-bak sm1
test_expect_success 'typechanged submodule(submodule->blob), --cached' "
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 41fbea9...0000000 (submodule deleted)
+Submodule sm1 $head4...0000000 (submodule deleted)
diff --git a/sm1 b/sm1
new file mode 100644
-index 0000000..9da5fb8
+index 0000000..$head5
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -148,7 +154,7 @@ test_expect_success 'typechanged submodule(submodule->blob)' "
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
deleted file mode 100644
-index 9da5fb8..0000000
+index $head5..0000000
--- a/sm1
+++ /dev/null
@@ -1 +0,0 @@
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 2ae9faa..96e0229 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1,6 +1,7 @@
#!/bin/sh
#
# Copyright (c) 2010, Will Palmer
+# Copyright (c) 2011, Alexey Shumkin (+ non-UTF-8 commit encoding tests)
#
test_description='Test pretty formats'
@@ -11,10 +12,13 @@ test_expect_success 'set up basic repos' '
>bar &&
git add foo &&
test_tick &&
- git commit -m initial &&
+ git config i18n.commitEncoding cp1251 &&
+ printf "initial \320\272\320\276\320\274\320\274\320\270\321\202" \
+ | iconv -f utf-8 -t cp1251 | xargs -I{} git commit -m "{}" &&
git add bar &&
test_tick &&
- git commit -m "add bar"
+ git commit -m "add bar" &&
+ git config --unset i18n.commitEncoding
'
test_expect_success 'alias builtin format' '
@@ -38,6 +42,20 @@ test_expect_success 'alias user-defined format' '
test_cmp expected actual
'
+test_expect_success 'alias user-defined tformat with %s (cp1251 encoding)' '
+ git config i18n.logOutputEncoding cp1251 &&
+ git log --oneline >expected-s &&
+ git log --pretty="tformat:%h %s" >actual-s &&
+ git config --unset i18n.logOutputEncoding &&
+ test_cmp expected-s actual-s
+'
+
+test_expect_success 'alias user-defined tformat with %s (utf-8 encoding)' '
+ git log --oneline >expected-s &&
+ git log --pretty="tformat:%h %s" >actual-s &&
+ test_cmp expected-s actual-s
+'
+
test_expect_success 'alias user-defined tformat' '
git log --pretty="tformat:%h" >expected &&
git config pretty.test-alias "tformat:%h" &&
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index d918cc0..8d99635 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -1,13 +1,34 @@
#!/bin/sh
+# Copyright (c) 2009 Jens Lehmann
+# Copyright (c) 2011 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
+
test_description='git rev-list --pretty=format test'
. ./test-lib.sh
test_tick
+added=$(printf "added (\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275) foo")
+added_cp1251=$(echo "$added" | iconv -f utf-8 -t cp1251)
+changed=$(printf "changed (\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275) foo")
+changed_cp1251=$(echo "$changed" | iconv -f utf-8 -t cp1251)
+
test_expect_success 'setup' '
-touch foo && git add foo && git commit -m "added foo" &&
- echo changed >foo && git commit -a -m "changed foo"
+ touch foo &&
+ git add foo &&
+ git config i18n.commitEncoding cp1251 &&
+ git commit -m "$added_cp1251" &&
+ head1=$(git rev-parse --verify HEAD) &&
+ head1_7=$(echo $head1 | cut -c1-7) &&
+ echo "$changed" > foo &&
+ git commit -a -m "$changed_cp1251" &&
+ head2=$(git rev-parse --verify HEAD) &&
+ head2_7=$(echo $head2 | cut -c1-7) &&
+ tree2=$(git cat-file -p HEAD | grep tree | cut -f 2 -d" ") &&
+ tree2_7=$(echo $tree2 | cut -c1-7) &&
+ head2_parent=$(git cat-file -p HEAD | grep parent | cut -f 2 -d" ") &&
+ head2_parent_7=$(echo $head2_parent | cut -c1-7) &&
+ git config --unset i18n.commitEncoding
'
# usage: test_format name format_string <expected_output
@@ -19,49 +40,49 @@ test_cmp expect.$1 output.$1
"
}
-test_format percent %%h <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format percent %%h <<EOF
+commit $head2
%h
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
%h
EOF
-test_format hash %H%n%h <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-131a310eb913d107dd3c09a65d1651175898735d
-131a310
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
+test_format hash %H%n%h <<EOF
+commit $head2
+$head2
+$head2_7
+commit $head1
+$head1
+$head1_7
EOF
-test_format tree %T%n%t <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-fe722612f26da5064c32ca3843aa154bdb0b08a0
-fe72261
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format tree %T%n%t <<EOF
+commit $head2
+$tree2
+$tree2_7
+commit $head1
4d5fcadc293a348e88f777dc0920f11e7d71441c
4d5fcad
EOF
-test_format parents %P%n%p <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format parents %P%n%p <<EOF
+commit $head2
+$head1
+$head2_parent_7
+commit $head1
EOF
# we don't test relative here
-test_format author %an%n%ae%n%ad%n%aD%n%at <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format author %an%n%ae%n%ad%n%aD%n%at <<EOF
+commit $head2
A U Thor
author@example.com
Thu Apr 7 15:13:13 2005 -0700
Thu, 7 Apr 2005 15:13:13 -0700
1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
A U Thor
author@example.com
Thu Apr 7 15:13:13 2005 -0700
@@ -69,14 +90,14 @@ Thu, 7 Apr 2005 15:13:13 -0700
1112911993
EOF
-test_format committer %cn%n%ce%n%cd%n%cD%n%ct <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format committer %cn%n%ce%n%cd%n%cD%n%ct <<EOF
+commit $head2
C O Mitter
committer@example.com
Thu Apr 7 15:13:13 2005 -0700
Thu, 7 Apr 2005 15:13:13 -0700
1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
C O Mitter
committer@example.com
Thu Apr 7 15:13:13 2005 -0700
@@ -84,86 +105,105 @@ Thu, 7 Apr 2005 15:13:13 -0700
1112911993
EOF
-test_format encoding %e <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format encoding %e <<EOF
+commit $head2
+commit $head1
EOF
-test_format subject %s <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+expected=$(printf "commit $head2\n\
+$changed\n\
+commit $head1\n\
+$added
+")
+
+test_format subject %s <<EOF
+$expected
EOF
-test_format body %b <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format body %b <<EOF
+commit $head2
+commit $head1
EOF
-test_format raw-body %B <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
+expected=$(printf "commit $head2\n\
+$changed\n\
+\n\
+commit $head1\n\
+$added
+")
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+test_format raw-body %B <<EOF
+$expected
EOF
-test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<EOF
+commit $head2
^[[31mfoo^[[32mbar^[[34mbaz^[[mxyzzy
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
^[[31mfoo^[[32mbar^[[34mbaz^[[mxyzzy
EOF
-test_format advanced-colors '%C(red yellow bold)foo%C(reset)' <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format advanced-colors '%C(red yellow bold)foo%C(reset)' <<EOF
+commit $head2
^[[1;31;43mfoo^[[m
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
^[[1;31;43mfoo^[[m
EOF
-cat >commit-msg <<'EOF'
+iconv -f utf-8 -t cp1251 > commit-msg <<EOF
Test printing of complex bodies
This commit message is much longer than the others,
-and it will be encoded in iso8859-1. We should therefore
-include an iso8859 character: ¡bueno!
+and it will be encoded in cp1251. We should therefore
+include an cp1251 character: так вот!
EOF
+
test_expect_success 'setup complex body' '
-git config i18n.commitencoding iso8859-1 &&
- echo change2 >foo && git commit -a -F commit-msg
+ git config i18n.commitencoding cp1251 &&
+ echo change2 >foo && git commit -a -F commit-msg &&
+ head3=$(git rev-parse --verify HEAD) &&
+ head3_7=$(echo $head3 | cut -c1-7)
'
-test_format complex-encoding %e <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
-iso8859-1
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format complex-encoding %e <<EOF
+commit $head3
+cp1251
+commit $head2
+cp1251
+commit $head1
+cp1251
EOF
-test_format complex-subject %s <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
-Test printing of complex bodies
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+# unset commit encoding config
+# otherwise %e does not print encoding value
+# and following test fails
+git config --unset i18n.commitencoding
+
+expected=$(printf "commit $head3\n\
+Test printing of complex bodies\n\
+commit $head2\n\
+$changed\n\
+commit $head1\n\
+$added
+")
+
+test_format complex-subject %s <<EOF
+$expected
EOF
-test_format complex-body %b <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
+test_format complex-body %b <<EOF
+commit $head3
This commit message is much longer than the others,
-and it will be encoded in iso8859-1. We should therefore
-include an iso8859 character: ¡bueno!
+and it will be encoded in cp1251. We should therefore
+include an cp1251 character: так вот!
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head2
+commit $head1
EOF
test_expect_success '%x00 shows NUL' '
- echo >expect commit f58db70b055c5718631e5c61528b28b12090cdea &&
+ echo >expect commit $head3 &&
echo >>expect fooQbar &&
git rev-list -1 --format=foo%x00bar HEAD >actual.nul &&
nul_to_q <actual.nul >actual &&
@@ -210,12 +250,12 @@ test_expect_success 'add LF before non-empty (2)' '
test_expect_success 'add SP before non-empty (1)' '
git show -s --pretty=format:"%s% bThanks" HEAD^^ >actual &&
- test $(wc -w <actual) = 2
+ test $(wc -w <actual) = 3
'
test_expect_success 'add SP before non-empty (2)' '
git show -s --pretty=format:"%s% sThanks" HEAD^^ >actual &&
- test $(wc -w <actual) = 4
+ test $(wc -w <actual) = 6
'
test_expect_success '--abbrev' '
--
1.7.6.1.g8f21c
^ permalink raw reply related
* [PATCH v2] pretty: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-09 8:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vwrf6qh49.fsf@alter.siamese.dyndns.org>
I discovered two more commands affected with this bug.
So I reroll this patch and tests for it.
>>(question) Does this change affect other commands, most notably
format-patch, and if so how?
No, it does not affect format-patc
---
builtin/rev-list.c | 1 +
builtin/shortlog.c | 1 +
log-tree.c | 1 +
submodule.c | 3 +
t/t4041-diff-submodule-option.sh | 44 +++++----
t/t4205-log-pretty-formats.sh | 22 ++++-
t/t6006-rev-list-format.sh | 192 +++++++++++++++++++++++---------------
7 files changed, 167 insertions(+), 97 deletions(-)
^ permalink raw reply
* Re: git repository size / compression
From: Carlos Martín Nieto @ 2011-09-09 8:23 UTC (permalink / raw)
To: neubyr; +Cc: git
In-Reply-To: <CALFxCvzVjC+u=RDkDCQp0QqPETsv8ROE8tY=37tmMWxmQoJOEw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
On Thu, 2011-09-08 at 21:37 -0500, neubyr wrote:
> I have a test git repository with just two files in it. One of the
> file in it has a set of two lines that is repeated n times.
> e.g.:
> {{{
> $ for i in {1..5}; do cat ./lexico.txt >> lexico1.txt && cat
> ./lexico.txt >> lexico1.txt && mv ./lexico1.txt ./lexico.txt; done
> }}}
>
So you've just created some data that can be compressed quite
efficiently.
> I ran above command few times and performed commit after each run. Now
> disk usage of this repository directory is mentioned below. The 419M
> is working directory size and 2.7M is git repository/database size.
>
> {{{
> $ du -h -d 1 .
> 2.7M ./.git
> 419M .
>
> }}}
>
> Is it because of the compression performed by git before storing data
> (or before sending commit)??
>
Yes. Git stores its objects (the commit, the snapshot of the files,
etc.) compressed. When these objects are stored in a pack, the size can
be further reduced by storing some objects as deltas which describe the
difference between itself and some other object in the object-db.
> Following were results with subversion:
>
> Subversion client (redundant(?) copy exists in .svn/text-base/
> directory, hence double size in client):
> {{{
> $ du -h -d 1
> 416M ./.svn
> 832M .
> }}}
Subversion stores the "pristines" (which is the status of the files in
the latest revision) inside the .svn directory. I wouldn't call this
copy redundant, though, as it allows you to run diff locally. The
pristines are stored uncompressed, which is why you half of the space is
taken up by the .svn directory.
>
> Subversion repo/server:
> {{{
> $ du -h -d 1
> 12K ./conf
> 1.2M ./db
> 36K ./hooks
> 8.0K ./locks
> 1.2M .
> }}}
I don't know how the repository is stored in Subversion, but it may also
be compressed. You may be able to reduced your git repository size by
(re)generating packs with 'git repack' and doing some cleanups with 'git
gc', but the repository size is not often a concern.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Miles Bader @ 2011-09-09 8:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, John Szakmeister, Kyle Neath, git
In-Reply-To: <4E69C8DC.7060008@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> Agreed. Anything harder than ssh keys is right out the window,
>> because they're always the alternative these people could be using
>> (but can't or don't want to).
>
> Sue, the question was: What is easy enough? I hoped that people
> would be using gpg to check signed tags, and that there might be a
> simple, convenient gnupg installer for Win and Mac which ties into
> the respective wallet systems or provides one they use already.
I wouldn't be surprised if many people just don't check signed tags at
all -- if the repositories they're using even have them in the first
place -- particularly amongst the audience in question.
-miles
--
What the fuck do white people have to be blue about!? Banana Republic ran
out of Khakis? The Espresso Machine is jammed? Hootie and The Blowfish
are breaking up??! Shit, white people oughtta understand, their job is to
GIVE people the blues, not to get them! -- George Carlin
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Michael J Gruber @ 2011-09-09 8:06 UTC (permalink / raw)
To: Jeff King; +Cc: Kyle Neath, git
In-Reply-To: <20110908191053.GA16064@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 08.09.2011 21:10:
> On Wed, Sep 07, 2011 at 02:56:03PM +0200, Michael J Gruber wrote:
>
>> So, it's been a year or more that you've been aware of the importance
>> of this issue (from your/github's perspective), and we hear about it
>> now, at the end of the rc phase. I don't know whether
>> jk/http-auth-keyring has been done on github payroll or during spare
>> time.
>
> To be absolutely clear here, this feature was 100% paid for by GitHub
> (which isn't to say that I don't think it's a good idea. On the
> contrary, I think it's awesome; but GitHub money is what provided the
> time for me to work on it).
>
> When I started at GitHub in January, I was given a giant list of things
> that GitHub felt would make core git better, but that they hadn't the
> personnel to improve. And I was told to use my own judgement in adding
> or removing items from the list based on what I thought git needed, and
> to prioritize as I saw fit. The fact that it took six months for me to
> come up with credential patches is because that's how long it took me to
> figure out what I wanted to write, and to clear my backlog of other git
> tasks.
>
> So I think the wheels have been turning on this for quite a while from
> GitHub's perspective.
Thanks for clarifying. While it should make no difference for the
acceptance of patches, it's great to see GitHub invest into scratching
their Git itches, and thus contribute back. That's how open source works
as a business model :)
...
> In the meantime, the best thing we can do to push it forward is to write
> helpers. I implemented some basic ones that should work anywhere, but
> aren't as nice as integration with existing keychains. Some people are
> working on Linux ones. The single best thing GitHub can do to push this
> forward right now is to provide a well-written OS X Keychain helper, and
> to provide feedback on whether git's end of the API is good enough.
... and one for Git on Windows? It seems we're lacking both Win and OS X
developers here.
... continuing in the other subthread...
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Michael J Gruber @ 2011-09-09 8:05 UTC (permalink / raw)
To: Jeff King; +Cc: John Szakmeister, Kyle Neath, git
In-Reply-To: <20110908191842.GB16064@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 08.09.2011 21:18:
> On Thu, Sep 08, 2011 at 11:02:11AM -0400, John Szakmeister wrote:
>
>> On Thu, Sep 8, 2011 at 9:17 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>> [snip]
>>> It would be interesting to know what we can rely on in the user group
>>> you're thinking about (which I called ssh-challenged). Setting up ssh
>>> keys is too complicated. Can we require a working gpg setup? They do
>>> want to check sigs, don't they?
>>
>> I don't think you can require a working gpg setup (at least for not
>> addressing the ssh-challenged group).
>
> Agreed. Anything harder than ssh keys is right out the window, because
> they're always the alternative these people could be using (but can't or
> don't want to).
Sue, the question was: What is easy enough? I hoped that people would be
using gpg to check signed tags, and that there might be a simple,
convenient gnupg installer for Win and Mac which ties into the
respective wallet systems or provides one they use already.
> We could make our own gpg-based password wallet system, but I think it's
> a really bad idea, for two reasons:
>
> 1. It's reinventing the wheel. Which is bad enough as it is, but is
> doubly bad with security-related code, because it's very easy to
> screw something up when you're writing a lot of new code.
So please let's not deploy credential-store...
> 2. It's inconvenient for users. Nobody wants a separate wallet system
> with its own master password. They want to integrate with the
> wallet system they're already using. Which is generally going to be
> way nicer _anyway_, because it's going to be part of the OS and do
> helpful things like unlock the secret store using their login
> credentials.
On 1.+2.: The idea/hope was to use an existing wallet system which
people use for gnupg already to store their passphrase. If that is not
used then my suggestion does not help much (the issue of widespread
deployment), though it still is a secure version of credential-store for
those who want a desktop-independent secure credential store.
>>> So: What credential store/password wallet/etc. can we rely on for this
>>> group? Is gpg fair game?
>>
>> I think there probably need to be providers for using Keychain under
>> the Mac, gnome-keyring and kwallet under Linux, and probably something
>> using the wincrypt API under Windows. I don't think there's a
>> one-store-fits-all solution here, unfortunately. :-(
>
> Exactly. That's why the helpers communicate via pipes. They don't have
> to be included with core git at all; you should be able to just drop a
> third-party git-credential-foo into your PATH.
>
>> I'm actually tempted try and work on a couple of those myself.
>
> Please do! I mentioned a few people working on helpers elsewhere in this
> thread, so you may want to see what they've done and/or coordinate to
> avoid duplicate effort. Let me know if you have trouble finding the
> appropriate threads in the list archive.
It seemed appropriate to leverage GitHub for this:
https://github.com/gitigit/git/wiki/Git-Credentials-Hub
Feel free to add!
Cheers,
Michael
^ permalink raw reply
* Re: [PATCHv2 4/5] branch: introduce --list option
From: Michael J Gruber @ 2011-09-09 6:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vmxeewx7f.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 08.09.2011 23:17:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> Jeff King venit, vidit, dixit 07.09.2011 21:56:
>>> ...
>>>> It does make me a little nervous about the "'git branch -v'
>>>> automatically means 'git branch --list -v'" patch, though. It closes the
>>>> door in the future to us being more or less verbose about branch
>>>> creation details (and while helpful, it creates a slight inconsistency
>>>> in the interface).
>>
>> Hasn't 'git branch -v' meant listing in verbose mode for a long enough
>> time that changing it now would mean a moderately major regression?
>>
>> At least my copy of v1.7.0 seems to list with "git branch -v".
>
> Ah, nevermind.
>
> As the series is already in 'next', here is what I came up with.
I thought you'll rebuild next anyways after 1.7.7, but either way it's
fine. Thanks for holding this series in next long enough to really cook
it (and Jeff for revisiting it), it's much better now, keeping the
(undocumented, but expected) behavior of "git branch -v foo".
>
> -- >8 --
> From: Michael J Gruber <git@drmicha.warpmail.net>
> Date: Thu, 8 Sep 2011 14:09:50 -0700
> Subject: [PATCH] branch: -v does not automatically imply --list
>
> "branch -v" without other options or parameters still works in the list
> mode, but that is not because there is "-v" but because there is no
> parameter nor option.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-branch.txt | 6 +++---
> builtin/branch.c | 3 +--
> t/t3203-branch-output.sh | 8 ++++++--
> 3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> index 2b8bc84..f46013c 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -21,7 +21,7 @@ DESCRIPTION
> With no arguments, existing branches are listed and the current branch will
> be highlighted with an asterisk. Option `-r` causes the remote-tracking
> branches to be listed, and option `-a` shows both. This list mode is also
> -activated by the `--list` and `-v` options (see below).
> +activated by the `--list` option (see below).
> <pattern> restricts the output to matching branches, the pattern is a shell
> wildcard (i.e., matched using fnmatch(3))
> Multiple patterns may be given; if any of them matches, the tag is shown.
> @@ -120,10 +120,10 @@ OPTIONS
>
> -v::
> --verbose::
> - Show sha1 and commit subject line for each head, along with
> + When in list mode,
> + show sha1 and commit subject line for each head, along with
> relationship to upstream branch (if any). If given twice, print
> the name of the upstream branch, as well.
> - `--list` is implied by all verbosity options.
>
> --abbrev=<length>::
> Alter the sha1's minimum display length in the output listing.
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 98a420f..099c75c 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -712,8 +712,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> argc = parse_options(argc, argv, prefix, options, builtin_branch_usage,
> 0);
>
> - if (!delete && !rename && !force_create &&
> - (argc == 0 || (verbose && argc)))
> + if (!delete && !rename && !force_create && argc == 0)
> list = 1;
>
> if (!!delete + !!rename + !!force_create + !!list > 1)
> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> index f2b294b..76fe7e0 100755
> --- a/t/t3203-branch-output.sh
> +++ b/t/t3203-branch-output.sh
> @@ -84,12 +84,16 @@ cat >expect <<'EOF'
> two
> one
> EOF
> -test_expect_success 'git branch -v pattern shows branch summaries' '
> - git branch -v branch* >tmp &&
> +test_expect_success 'git branch --list -v pattern shows branch summaries' '
> + git branch --list -v branch* >tmp &&
> awk "{print \$NF}" <tmp >actual &&
> test_cmp expect actual
> '
>
> +test_expect_success 'git branch -v pattern does not show branch summaries' '
> + test_must_fail git branch -v branch*
> +'
> +
> cat >expect <<'EOF'
> * (no branch)
> branch-one
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Francis Moreau @ 2011-09-09 6:43 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <alpine.DEB.2.00.1109082123300.12564@debian>
On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk
<martin.von.zweigbergk@gmail.com> wrote:
> On Thu, 8 Sep 2011, Francis Moreau wrote:
>
>> On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk
>> <martin.von.zweigbergk@gmail.com> wrote:
>> >
>> > Patches that are in both sides of v2.6.39...foo will be filtered, but
>>
>> what do you mean by "both sides" ?
>
> See the section called "SPECIFYING RANGES" in "git --help
> rev-parse". It doesn't define "both sides", but what I mean by that is
> "both in v2.6.39..foo and in foo..v2.6.39". I believe that section
> will answer most of the other questions too.
>
>> Yes my use of "git rebase --onto master foo~10 foo" is equivalent to
>> "git rebase master foo, the only difference is that the --onto variant
>> allow me to limit the range of commits that I want to rebase. So I
>> still want git rebase to do its the filtering process.
>
> Ok, that is different. I think you used v2.6.39 instead of foo~10
> previously. Assuming that v2.6.39 is the merge base of foo and master
> and that foo~10 is a later commit than v2.6.39,
That's what I meant.
> you are right that
> "git rebase --onto master foo~10 foo" could potentially filter out
> patches already in foo..master, without calculating patch-ids for all
> commits in master..foo for that matter. I think that would make sense
you meant master..foo~10, didn't you ?
> and as I said, it has been on my todo list for a long time. If
please let me know when you submitting your work, I'm interested to see it.
> necessary, we could have a flag to disable the filtering e.g. when the
> user knows that master is part of a completely separate history from
> foo.
Can't git figure this out itself ? (I'm not saying the switch is useless)
Thanks
--
Francis
^ permalink raw reply
* Re: Git Bug - diff in commit message.
From: Johannes Sixt @ 2011-09-09 6:14 UTC (permalink / raw)
To: Thomas Rast; +Cc: Michael Witten, anikey, git
In-Reply-To: <201109090256.36306.trast@student.ethz.ch>
Am 9/9/2011 2:56, schrieb Thomas Rast:
> Michael Witten wrote:
>> Perhaps `git rebase' should be reimplemented to use `git cherry-pick',
>> or does that suffer from the same problem?
>
> It doesn't, since it uses a three-way merge. But there's no real
> reason to reimplement anything; just use an interactive rebase, it
> uses cherry-pick in a loop.
But you can just as well use 'git rebase -m', which uses cherry-pick (or
something equivalent, dunno).
-- Hannes
^ permalink raw reply
* Re: git rebase fails with: Patch does not have a valid e-mail address.
From: Kyle Moffett @ 2011-09-09 4:45 UTC (permalink / raw)
To: James Blackburn; +Cc: git
In-Reply-To: <CACyv8dckmRxgb9_FDTW+=1Y9bS27b3XZQCHnhjpfHiJig5p6wg@mail.gmail.com>
On Thu, Sep 8, 2011 at 07:47, James Blackburn <jamesblackburn@gmail.com> wrote:
> I'm trying to rewrite some history and git's telling me:
>
> -bash:jamesb:lc-cam-025:33079> git rebase
> 7f58969b933745d4cb9bb128bbd3fa8d441cdb92
> First, rewinding head to replay your work on top of it...
> Patch does not have a valid e-mail address.
>
> Now it's true there isn't an email address for the author - the author
> no longer works for the company, and the email address was removed
> during the conversion. Therefore the repo contains "Author <>".
I can't really speak directly on the "rebase" issue, but...
You probably don't want to remove the email address from the repository
during a rewrite. When I was converting some old CVS repositories for
my company I very intentionally looked up all of our old user emails to
be able to convert them reliably (even though most of the addresses at
that point did not work). Even for the users where I could not find a
functional address I would just pick something reasonable based on the
username convention at the time.
In cases where you can't accurately attribute the commit (IE: username
of "root" or "cvs" or something), you probably want to rewrite it using an
internal mailing list address. For example, if the kernel had been in a
CVS repository with commits by "root", I would probably rewrite those
to be created by:
Linux Kernel Developers <lkml@vger.kernel.org>
Cheers,
Kyle Moffett
^ permalink raw reply
* git repository size / compression
From: neubyr @ 2011-09-09 2:37 UTC (permalink / raw)
To: git
I have a test git repository with just two files in it. One of the
file in it has a set of two lines that is repeated n times.
e.g.:
{{{
$ for i in {1..5}; do cat ./lexico.txt >> lexico1.txt && cat
./lexico.txt >> lexico1.txt && mv ./lexico1.txt ./lexico.txt; done
}}}
I ran above command few times and performed commit after each run. Now
disk usage of this repository directory is mentioned below. The 419M
is working directory size and 2.7M is git repository/database size.
{{{
$ du -h -d 1 .
2.7M ./.git
419M .
}}}
Is it because of the compression performed by git before storing data
(or before sending commit)??
Following were results with subversion:
Subversion client (redundant(?) copy exists in .svn/text-base/
directory, hence double size in client):
{{{
$ du -h -d 1
416M ./.svn
832M .
}}}
Subversion repo/server:
{{{
$ du -h -d 1
12K ./conf
1.2M ./db
36K ./hooks
8.0K ./locks
1.2M .
}}}
--
neuby.r
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Martin von Zweigbergk @ 2011-09-09 2:23 UTC (permalink / raw)
To: Francis Moreau
Cc: Martin von Zweigbergk, Junio C Hamano, Michael J Gruber, git
In-Reply-To: <CAC9WiBiMYUfaPtrXyW=W7qaZnJqLeFO-B3od7X4u8wUrb8hfUA@mail.gmail.com>
On Thu, 8 Sep 2011, Francis Moreau wrote:
> On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk
> <martin.von.zweigbergk@gmail.com> wrote:
> >
> > Patches that are in both sides of v2.6.39...foo will be filtered, but
>
> what do you mean by "both sides" ?
See the section called "SPECIFYING RANGES" in "git --help
rev-parse". It doesn't define "both sides", but what I mean by that is
"both in v2.6.39..foo and in foo..v2.6.39". I believe that section
will answer most of the other questions too.
> Yes my use of "git rebase --onto master foo~10 foo" is equivalent to
> "git rebase master foo, the only difference is that the --onto variant
> allow me to limit the range of commits that I want to rebase. So I
> still want git rebase to do its the filtering process.
Ok, that is different. I think you used v2.6.39 instead of foo~10
previously. Assuming that v2.6.39 is the merge base of foo and master
and that foo~10 is a later commit than v2.6.39, you are right that
"git rebase --onto master foo~10 foo" could potentially filter out
patches already in foo..master, without calculating patch-ids for all
commits in master..foo for that matter. I think that would make sense
and as I said, it has been on my todo list for a long time. If
necessary, we could have a flag to disable the filtering e.g. when the
user knows that master is part of a completely separate history from
foo.
Martin
^ 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