* Re: commit.template
From: Junio C Hamano @ 2008-12-27 0:13 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: jidanni, git
In-Reply-To: <20081227090727.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting jidanni@jidanni.org:
>
>> NS> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
>>
>> No. I want in fact just to use "Signed-off-by: jidanni@jidanni.org",
>
> I think everybody on the list now understands that you desperately want to be different. I think it would be beneficial for you to try making a difference in areas that matter, instead of just trying to be different in how your name is spelled.
>
> Just my two yen ;-)
Even though I soft-of-kind-of understand that you are frustrated for
getting that response after offering an advice to satisfy his earlier
wish:
"Thanks but I want to be http://zh.wikipedia.org/wiki/積丹尼"
made in $gmane/103591, you do not sound so harsh and play a bad girl.
Be civil and friendly around here, please...
^ permalink raw reply
* Re: commit.template
From: Nanako Shiraishi @ 2008-12-27 0:07 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87tz8qsgn2.fsf_-_@jidanni.org>
Quoting jidanni@jidanni.org:
> NS> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
>
> No. I want in fact just to use "Signed-off-by: jidanni@jidanni.org",
I think everybody on the list now understands that you desperately want to be different. I think it would be beneficial for you to try making a difference in areas that matter, instead of just trying to be different in how your name is spelled.
Just my two yen ;-)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: commit.template
From: jidanni @ 2008-12-27 0:01 UTC (permalink / raw)
To: bss; +Cc: git, nanako3
In-Reply-To: <200812261750.12204.bss@iguanasuicide.net>
OK, both
>> 1) man git-config mentions
>> commit.template
and
BSS> git commit --help tells how this configuration option is used, in the
BSS> documentation of the "-t" option.
should
>> mention what file is being used presently
as one needs a template in order to modify a template... in case
someone one day wants to. Not me. I'm happy already.
^ permalink raw reply
* Re: getting started, happy with cmd line on windows [Scanned]
From: Junio C Hamano @ 2008-12-26 23:50 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gj3of4$pr3$3@ger.gmane.org>
"Zorba" <cr@altmore.co.uk> writes:
> Now, I went back and read the manual pages for git-checkout and think I see
> how to do it....
>
> $ <import code>
> $ git init
> $ git commit
> $ git tag versionA <commitID>
> $ hack hack hack
> ...
> now ready to start coding, want "last known good"
> $ rm *.*
> $ git checkout versionA .
>
> This worked fine when versionA had only files and no dirs - but will it work
> ok still if versionA is a proper tree ?
> (more of a unix question I suppose - will "." suffice as the path ?)
Drop "rm *.*". Instead, probably what you want is
> $ <import code>
> $ git init
> $ git commit
which is a good way to make an initial import.
> $ git tag versionA <commitID>
> $ hack hack hack
> ...
and you futzed with the codebase without any intention of committing;
it is nice to be able to experiment freely.
After you are done experimenting,
$ git reset --hard versionA
if you did not make any commit, or even if you did commit while you were
experimenting, if you do not want these experimental commits at all.
No need for "rm *.*" anywhere.
^ permalink raw reply
* Re: commit.template
From: Boyd Stephen Smith Jr. @ 2008-12-26 23:50 UTC (permalink / raw)
To: git; +Cc: jidanni, nanako3
In-Reply-To: <87tz8qsgn2.fsf_-_@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On Friday 2008 December 26 16:42:09 jidanni@jidanni.org wrote:
> NS> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
>
> No. I want in fact just to use "Signed-off-by: jidanni@jidanni.org",
> but apparently
> 1) man git-config mentions
> commit.template
> Specify a file to use as the template for new commit messages.
>
> but doesn't mention what file is being used presently, so one can know
> what to adjust.
git commit --help tells how this configuration option is used, in the
documentation of the "-t" option.
> 3) Making a line without a name would probably break other things.
Well, then use your legal name -- unicode is allowed.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: commit.template
From: Junio C Hamano @ 2008-12-26 23:44 UTC (permalink / raw)
To: jidanni; +Cc: nanako3, git
In-Reply-To: <87tz8qsgn2.fsf_-_@jidanni.org>
jidanni@jidanni.org writes:
> NS> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
>
> No. I want in fact just to use "Signed-off-by: jidanni@jidanni.org",
That won't fly well, provided if you want your patches in git.git tree.
^ permalink raw reply
* Re: getting started, happy with cmd line on windows [Scanned]
From: Zorba @ 2008-12-26 23:13 UTC (permalink / raw)
To: git
In-Reply-To: <495508B9.7070103@lsrfire.ath.cx>
> I then deleted all files from the working directory, so I can pull out
> ONLY the ones in version A.
> I tried both fetch and checkout - but nothing was copied into working
> dir How do I do this ?
git treats deleted files just like edited files: as having been changed
in preparation for the next commit. You can get back all of the tracked
files using this command:
$ git reset --hard
It undoes _all_ changes: tracked edited files will be reverted to their
in-repository state, deleted files created again. You can also check
out individual files like this:
$ git checkout ABC.txt
If you just want to get rid of untracked files, you'd use the command
"git clean".
In general, if you switch your work tree from one revision to another
(git checkout), git tries to minimize the I/O needed. Files that are
the same in both aren't touched.
>>>>>>>>>>>>>>>>>>>
Hi Rene,
Thanks for taking the time.
My workflow is such that I inherit projects that are hard to debug and I
need to hack around a lot changing a lot of files to output tracking msgs
just to learn the code's functionality (e,g, PHP on a webserver), but these
changes I never intend to keep. After learning the code, I want to go back
to a "last known good". I.e. a previous stable version and start making
proper changes.
In other SCMs, there was a way to "discard" all local changes, after the
hacking phase, without EVER having had to commit.
For a while it seemed like you were telling me I had to COMMIT my hacked
code (against all my instincts :-), and THEN rollback ($ git reset --hard).
Now, I went back and read the manual pages for git-checkout and think I see
how to do it....
$ <import code>
$ git init
$ git commit
$ git tag versionA <commitID>
$ hack hack hack
...
now ready to start coding, want "last known good"
$ rm *.*
$ git checkout versionA .
This worked fine when versionA had only files and no dirs - but will it work
ok still if versionA is a proper tree ?
(more of a unix question I suppose - will "." suffice as the path ?)
^ permalink raw reply
* Re: [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: jidanni @ 2008-12-26 23:08 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vmyeilj3z.fsf@gitster.siamese.dyndns.org>
OK, the two letters are related by an algorithm.
^ permalink raw reply
* commit.template
From: jidanni @ 2008-12-26 22:42 UTC (permalink / raw)
To: nanako3; +Cc: git
In-Reply-To: <20081227070232.6117@nanako3.lavabit.com>
NS> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
No. I want in fact just to use "Signed-off-by: jidanni@jidanni.org",
but apparently
1) man git-config mentions
commit.template
Specify a file to use as the template for new commit messages.
but doesn't mention what file is being used presently, so one can know
what to adjust.
2) .git/hooks/commit-msg etc. don't seem to control that line.
3) Making a line without a name would probably break other things.
^ permalink raw reply
* Re: [PATCH] Add a commit.signoff configuration variable to always use --signoff.
From: Adeodato Simó @ 2008-12-26 22:10 UTC (permalink / raw)
To: git
In-Reply-To: <20081227070228.6117@nanako3.lavabit.com>
* Nanako Shiraishi [Sat, 27 Dec 2008 07:02:28 +0900]:
> There was a discussion in
> "http://thread.gmane.org/gmane.comp.version-control.git/32503/focus=32522"
> about automatically adding S-o-b line.
Ah, thanks for the pointer.
> Even though Junio said in his response "it certainly is a
> possibility", another solution that he referred to as "cleaner and
> more useful" in his message was made available in version 1.5.3 after
> this discussion.
Oh, a template file? I certainly hadn't thought of that, though I'd
still like to hear if my patch would be suitable for inclusion, because
it's much more straightforward to use (and to discover).
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
- I love you, Shirley, I'm not ashamed to say.
- If you love me, then you'll want me to be happy. Even if I'm not with you.
- I don't love you that much.
-- Denny Crane and Shirley Schmidt
^ permalink raw reply
* Re: [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: Nanako Shiraishi @ 2008-12-26 22:02 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <E1LGFoE-0001EZ-0F@jidanni.org>
Quoting jidanni@jidanni.org:
> Signed-off-by: jidanni <jidanni@jidanni.org>
Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Add a commit.signoff configuration variable to always use --signoff.
From: Nanako Shiraishi @ 2008-12-26 22:02 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <1230296219-16408-1-git-send-email-dato@net.com.org.es>
Quoting Adeodato Simó <dato@net.com.org.es>:
> I wrote:
>> Has there even been talk of a commit.signoff configuration variable
>> to always add a S-o-b line? This could allow to enable it on a
>> per-project basis, which would be cool.
There was a discussion in "http://thread.gmane.org/gmane.comp.version-control.git/32503/focus=32522" about automatically adding S-o-b line.
Even though Junio said in his response "it certainly is a possibility", another solution that he referred to as "cleaner and more useful" in his message was made available in version 1.5.3 after this discussion.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] describe: Avoid unnecessary warning when using --all
From: Shawn O. Pearce @ 2008-12-26 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: demerphq, rene.scharfe, git
In 212945d4 ("Teach git-describe to verify annotated tag names
before output") git-describe learned how to output a warning if
an annotated tag object was matched but its internal name doesn't
match the local ref name.
However, "git describe --all" causes the local ref name to be
prefixed with "tags/", so we need to skip over this prefix before
comparing the local ref name with the name recorded inside of the
tag object.
Patch-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
IMHO, suitable for maint...
builtin-describe.c | 2 +-
t/t6120-describe.sh | 6 ++++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index d2cfb1b..3a007ed 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -158,7 +158,7 @@ static void display_name(struct commit_name *n)
n->tag = lookup_tag(n->sha1);
if (!n->tag || parse_tag(n->tag) || !n->tag->tag)
die("annotated tag %s not available", n->path);
- if (strcmp(n->tag->tag, n->path))
+ if (strcmp(n->tag->tag, all ? n->path + 5 : n->path))
warning("tag '%s' is really '%s' here", n->tag->tag, n->path);
}
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index e6c9e59..8c7e081 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -100,6 +100,12 @@ check_describe B --tags HEAD^^2^
check_describe B-0-* --long HEAD^^2^
check_describe A-3-* --long HEAD^^2
+: >err.expect
+check_describe A --all A^0
+test_expect_success 'no warning was displayed for A' '
+ test_cmp err.expect err.actual
+'
+
test_expect_success 'rename tag A to Q locally' '
mv .git/refs/tags/A .git/refs/tags/Q
'
--
1.6.1.302.gccd4d
^ permalink raw reply related
* Re: [PATCH] ls-tree: add --full-tree option
From: Junio C Hamano @ 2008-12-26 21:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Deskin Miller
In-Reply-To: <49553561.4030902@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> I'm saying that if a script has to be fixed to use --full-tree, then
> it can be fixed just as well by appending the colon to the ${rev}.
I do not agree with your "just as well"; an existing script that feeds a
tree object to the plumbing would be broken by such a change.
But I think perhaps you were responding to the first paragraph of the
commit log message that you omitted from your quote?
JC> The established behaviour of "git ls-tree $commit" run from a
JC> subdirectory "sub/dir" in a work tree is to...
If that is the case, I understand what you meant.
The patch is about the behaviour of the command for not just $commit but
any $tree_ish, so "git ls-tree ${commit}:" shares the exact same issue
(i.e. historical background that forbids us from changing the behaviour
without an explicit option, and that --full-tree can be a way to help new
scripts without breaking existing scripts' expectations).
I've updated the commit log message with s/$commit/$tree_ish/;
> OTOH, you had yourself argued somewhat in favor of the current ls-tree
> behavior:
>
> http://thread.gmane.org/gmane.comp.version-control.git/46232/focus=46400
That's not really "somewhat in favor". I can be (and am more often than
not) sympathetic without agreeing to the end result. My sympathy extends
from "I can sort-of-kind-of imagine that it may hurt, and even though I do
not think your approach is a way to properly address it at all, I'd agree
it might be nice to have some solution to the issue" to "I do not think it
is feasible to change this anymore, but I wish we could, too."
In any case, the quoted message was from May 2007, way before v1.6.0 when
we learned the hard way that people do not want any change.
I really hate "take it or leave it", especially when it is not my itch to
scratch, but in this case, I think I've spent enough time making myself
clear that I think (1) that the current behaviour is a result of misguided
attempt for interactive user expectation, which shouldn't have made to the
plumbing, (2) that we cannot change the default behaviour now even (1) is
true; and (3) that the only possible approach to help new scripts would be
a new option.
^ permalink raw reply
* Re: [PATCH] Add support for changing packed_git_window_size at process start time
From: Shawn O. Pearce @ 2008-12-26 21:36 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1229927143.14882.17.camel@starfruit>
"R. Tyler Ballance" <tyler@slide.com> wrote:
> Ah, gotcha, sounds like a good idea. I went ahead and added the change
> and I'm still getting the memory issues.
:-|
> I'm not as familiar with using gdb(1), so I'm having trouble tracking
> down the issue in a limited session, I get loads of issues like the
> following when trying to step through an execution of `git log`
>
> Is there a means in which I can cause a core dump on an ENOMEM error passed back from mmap(2)? That or a way to impose these limits on the gdb git-subprocess but not on the gdb process?
Look at xmmap in git's code. All of our mmap calls go through that
function and try to release pack windows if we get an error back
from mmap(), then it retries the mmap request. xmalloc likewise
does the same thing for malloc requests; xcalloc for calloc, xstrdup
for strdup. We have a number of these x variant functions to handle
memory allocation.
You might be be able to put a setrlimit call into main() in git.c to
drop the rlimit for Git to a lower limit than it inherited from gdb,
allowing you to start gdb with a much higher ulimit so it doesn't
barf when trying to inspect the git child.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: Junio C Hamano @ 2008-12-26 21:30 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87skoau1su.fsf@jidanni.org>
jidanni@jidanni.org writes:
>>>>>> "JCH" == Junio C Hamano <gitster@pobox.com> writes:
>
> JCH> If that is the case, please justify why you think it is better not to say
> JCH> "first two letters" the documentation.
> OK, I saw
> $ ls 3d
> 05a66c3..
> 189066f..
> If it were the first to letters, it would be
> $ ls 3d
> 3d05a66c3..
> 3d189066f..
> Ah, you mean it snaps them off to form the directory name?! OK, please
> note that.
If you read the description again, you will notice that the entry explains
what these directories are; it is not a description about the files in
these directories.
> As far as all your other points and messed up To:, OK, next time I will do better.
When sending the fixed-up patch, please send it in an applicable form. I
do not know how you stripped "Documentation/" from the front, but your
patch was against {a,b}/gitrepository-layout.txt.
Thanks.
^ permalink raw reply
* Re: [PATCH] ls-tree: add --full-tree option
From: Johannes Sixt @ 2008-12-26 19:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Deskin Miller
In-Reply-To: <7vmyejpb6o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j6t@kdbg.org> writes:
>
>> On Freitag, 26. Dezember 2008, Junio C Hamano wrote:
>>> This new option makes the command operate on the full tree object,
>>> regardless of where in the work tree it is run from. It also implies the
>>> behaviour that is triggered by the existing --full-name option.
>> What's wrong with using 'git ls-tree ${rev}:'?
>>
>> Except that it does not work...
>
> Hmph... you seem to be describing the exact issue they discussed on #git,
> which triggered the patch in the message you are responding to. I am not
> sure what to say to your "What's wrong with...".
I'm saying that if a script has to be fixed to use --full-tree, then it
can be fixed just as well by appending the colon to the ${rev}.
Not even porcelain 'git show ${rev}:' "is allowed" to insert the prefix.
Dscho has argued the case passionately in the past:
http://thread.gmane.org/gmane.comp.version-control.git/68786/focus=68846
Therefore, plumbing 'ls-tree ${rev}:' shouldn't do that, either.
OTOH, you had yourself argued somewhat in favor of the current ls-tree
behavior:
http://thread.gmane.org/gmane.comp.version-control.git/46232/focus=46400
I'm personally more in line with Dscho, and think that the current
ls-tree behavior is a terrible bug.
-- Hannes
^ permalink raw reply
* Re: [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: jidanni @ 2008-12-26 20:19 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7veizuog2z.fsf@gitster.siamese.dyndns.org>
>>>>> "JCH" == Junio C Hamano <gitster@pobox.com> writes:
JCH> If that is the case, please justify why you think it is better not to say
JCH> "first two letters" the documentation.
OK, I saw
$ ls 3d
05a66c3..
189066f..
If it were the first to letters, it would be
$ ls 3d
3d05a66c3..
3d189066f..
Ah, you mean it snaps them off to form the directory name?! OK, please
note that.
As far as all your other points and messed up To:, OK, next time I will do better.
^ permalink raw reply
* Re: [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: Junio C Hamano @ 2008-12-26 20:07 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <E1LGFoE-0001EZ-0F@jidanni.org>
jidanni@jidanni.org writes:
> Signed-off-by: jidanni <jidanni@jidanni.org>
First off, when I tried to respond to your message, I got this:
Cc: undisclosed-recipients:;
which I had to edit it to point at the list.
I think you did "Bcc: git@vger.kernel.org" without any explicit recipient;
please don't. It wastes everybody's time.
Second, please realize that the Subject: line is one of the most important
piece of information in your patch submission. It is used as the summary
of what this change is about in the shortlog output. 2 months from now,
do you think anybody (other than you) can guess what the "first two
letters" is about among 400 other changes?
I would have preferred the Subject: and the commit log message like this
for this patch:
Subject: [PATCH] Fix description of objects/??/ directories in the repository-layout doc
These fan-out directories are no longer first two letters. Also fix
a sentence that meant to say "keep something down" but forgot "down".
That is, summarize what this patch is about on Subject: line, and explain
why the change is a good idea (in other words, why the current one is bad)
in the commit log message.
I agree with the "down" fix; thanks for catching this grammatical and
semantic error.
I however do not understand the reason behind the former "two letters"
change.
When creating a new object, the filename to hold it when its object name
is e.g. 92b35d66d0e335771c2e4a4a79f95adb844b1f91 (that's a tag object for
v1.6.1 if anybody cares) is computed by taking its first two letters "92"
and using that to choose ".git/object/92" as the containing "fan-out"
directory. The file in that directory is named using the remainder of the
object name.
The entry in the repository layout document explains what the directories
with two-letter names you find in objects/ directory are, and I do not see
a reason why you want to say "no longer first two letters". Their names
still are, and very likely continue to be, two-letter long.
Maybe I misunderstood what you wanted to say by "no longer...". Did you
mean (unlike the sample commit log message I suggested above):
Subject: [PATCH] Fix description of objects/??/ directories in the repository-layout doc
Do not say first two letters anymore. Also fix a sentence that meant
to say "keep something down" but forgot "down".
If that is the case, please justify why you think it is better not to say
"first two letters" the documentation.
Thanks.
^ permalink raw reply
* [PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Kirill Smelkov @ 2008-12-26 18:38 UTC (permalink / raw)
To: Junio C Hamano, Junio C Hamano; +Cc: Kirill Smelkov, git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6867 bytes --]
When native language (RU) is in use, subject header usually contains several
parts, e.g.
Subject: [Navy-patches] [PATCH]
=?utf-8?b?0JjQt9C80LXQvdGR0L0g0YHQv9C40YHQvtC6INC/0LA=?=
=?utf-8?b?0LrQtdGC0L7QsiDQvdC10L7QsdGF0L7QtNC40LzRi9GFINC00LvRjyA=?=
=?utf-8?b?0YHQsdC+0YDQutC4?=
This exposes several bugs in builtin-mailinfo.c that I try to fix:
1. decode_b_segment: do not append explicit NUL -- explicit NUL was preventing
correct header construction on parts concatenation via strbuf_addbuf in
decode_header_bq. Fixes:
-Subject: Изменён список пакетов необходимых для сборки
+Subject: Изменён список па
Then
2. (hackish) do not emit '\n' after processing of every header segment. It
seems we should emit previous part as-is only if it does not end with
'=?='. Fixes:
-Subject: Изменён список пакетов необходимых для сборки
+Subject: Изменён список па кетов необходимых для сборки
Sorry for low-quality patch and description. I did what I could and don't have
energy and time dig more into MIME.
Please help.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
builtin-mailinfo.c | 18 ++++++++++++++++-
t/t5100-mailinfo.sh | 2 +-
t/t5100/info0012 | 5 ++++
t/t5100/msg0012 | 7 ++++++
t/t5100/patch0012 | 30 +++++++++++++++++++++++++++++
t/t5100/sample.mbox | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index e890f7a..d138bc3 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -436,6 +436,14 @@ static struct strbuf *decode_b_segment(const struct strbuf *b_seg)
* for now we just trust the data.
*/
c = 0;
+
+ /* XXX: the following is needed not to output NUL in
+ * the resulting string
+ *
+ * This seems to be ok, but I'm not 100% sure -- that's
+ * why this is an RFC.
+ */
+ continue;
}
else
continue; /* garbage */
@@ -513,7 +521,15 @@ static int decode_header_bq(struct strbuf *it)
strbuf_reset(&piecebuf);
rfc2047 = 1;
- if (in != ep) {
+ /* XXX: the follwoing is needed not to output '\n' on every
+ * multi-line segment in Subject.
+ *
+ * I suspect this is not 100% correct, but I'm not a MIME guy
+ * -- that's why this is an RFC.
+ */
+
+ /* if in does not end with '=?=', we emit it as is */
+ if (in <= (ep-2) && !(ep[-1]=='\n' && ep[-2]=='=')) {
strbuf_add(&outbuf, in, ep - in);
in = ep;
}
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index fe14589..6825f99 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 11'
+ test `cat last` = 12'
for mail in `echo 00*`
do
diff --git a/t/t5100/info0012 b/t/t5100/info0012
new file mode 100644
index 0000000..ac1216f
--- /dev/null
+++ b/t/t5100/info0012
@@ -0,0 +1,5 @@
+Author: Dmitriy Blinov
+Email: bda@mnsspb.ru
+Subject: Изменён список пакетов необходимых для сборки
+Date: Wed, 12 Nov 2008 17:54:41 +0300
+
diff --git a/t/t5100/msg0012 b/t/t5100/msg0012
new file mode 100644
index 0000000..1dc2bf7
--- /dev/null
+++ b/t/t5100/msg0012
@@ -0,0 +1,7 @@
+textlive-* исправлены на texlive-*
+docutils заменён на python-docutils
+
+Действительно, оказалось, что rest2web вытягивает за собой
+python-docutils. В то время как сам rest2web не нужен.
+
+Signed-off-by: Dmitriy Blinov <bda@mnsspb.ru>
diff --git a/t/t5100/patch0012 b/t/t5100/patch0012
new file mode 100644
index 0000000..36a0b68
--- /dev/null
+++ b/t/t5100/patch0012
@@ -0,0 +1,30 @@
+---
+ howto/build_navy.txt | 6 +++---
+ 1 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/howto/build_navy.txt b/howto/build_navy.txt
+index 3fd3afb..0ee807e 100644
+--- a/howto/build_navy.txt
++++ b/howto/build_navy.txt
+@@ -119,8 +119,8 @@
+ - libxv-dev
+ - libusplash-dev
+ - latex-make
+- - textlive-lang-cyrillic
+- - textlive-latex-extra
++ - texlive-lang-cyrillic
++ - texlive-latex-extra
+ - dia
+ - python-pyrex
+ - libtool
+@@ -128,7 +128,7 @@
+ - sox
+ - cython
+ - imagemagick
+- - docutils
++ - python-docutils
+
+ #. на машине dinar: добавить свой открытый ssh-ключ в authorized_keys2 пользователя ddev
+ #. на своей машине: отредактировать /etc/sudoers (команда ``visudo``) примерно следующим образом::
+--
+1.5.6.5
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 4bf7947..94da4da 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -501,3 +501,55 @@ index 3e5fe51..aabfe5c 100644
--=-=-=--
+From bda@mnsspb.ru Wed Nov 12 17:54:41 2008
+From: Dmitriy Blinov <bda@mnsspb.ru>
+To: navy-patches@dinar.mns.mnsspb.ru
+Date: Wed, 12 Nov 2008 17:54:41 +0300
+Message-Id: <1226501681-24923-1-git-send-email-bda@mnsspb.ru>
+X-Mailer: git-send-email 1.5.6.5
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset=utf-8
+Content-Transfer-Encoding: 8bit
+Subject: [Navy-patches] [PATCH]
+ =?utf-8?b?0JjQt9C80LXQvdGR0L0g0YHQv9C40YHQvtC6INC/0LA=?=
+ =?utf-8?b?0LrQtdGC0L7QsiDQvdC10L7QsdGF0L7QtNC40LzRi9GFINC00LvRjyA=?=
+ =?utf-8?b?0YHQsdC+0YDQutC4?=
+
+textlive-* исправлены на texlive-*
+docutils заменён на python-docutils
+
+Действительно, оказалось, что rest2web вытягивает за собой
+python-docutils. В то время как сам rest2web не нужен.
+
+Signed-off-by: Dmitriy Blinov <bda@mnsspb.ru>
+---
+ howto/build_navy.txt | 6 +++---
+ 1 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/howto/build_navy.txt b/howto/build_navy.txt
+index 3fd3afb..0ee807e 100644
+--- a/howto/build_navy.txt
++++ b/howto/build_navy.txt
+@@ -119,8 +119,8 @@
+ - libxv-dev
+ - libusplash-dev
+ - latex-make
+- - textlive-lang-cyrillic
+- - textlive-latex-extra
++ - texlive-lang-cyrillic
++ - texlive-latex-extra
+ - dia
+ - python-pyrex
+ - libtool
+@@ -128,7 +128,7 @@
+ - sox
+ - cython
+ - imagemagick
+- - docutils
++ - python-docutils
+
+ #. на машине dinar: добавить свой открытый ssh-ключ в authorized_keys2 пользователя ddev
+ #. на своей машине: отредактировать /etc/sudoers (команда ``visudo``) примерно следующим образом::
+--
+1.5.6.5
--
tg: (2292ebd..) t/mailinfo-multiline-subject (depends on: tmp)
^ permalink raw reply related
* [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: jidanni @ 2008-12-26 16:43 UTC (permalink / raw)
Signed-off-by: jidanni <jidanni@jidanni.org>
diff --git a/gitrepository-layout.txt b/gitrepository-layout.txt
index 03c52ff..81103fc 100644
--- a/gitrepository-layout.txt
+++ b/gitrepository-layout.txt
@@ -46,6 +46,4 @@ objects/[0-9a-f][0-9a-f]::
- Traditionally, each object is stored in its own file.
- They are split into 256 subdirectories using the first
- two letters from its object name to keep the number of
- directory entries `objects` directory itself needs to
- hold. Objects found here are often called 'unpacked'
- (or 'loose') objects.
+ Traditionally, each object is stored in its own file. They are
+ split into 256 subdirectories to keep the number of directory
+ entries `objects` directory itself needs to hold down. Objects
+ found here are often called 'unpacked' (or 'loose') objects.
--
1.5.6.5
^ permalink raw reply related
* Re: a few Topgit patches
From: Uwe Kleine-König @ 2008-12-26 17:03 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Petr Baudis
In-Reply-To: <20081225145834.GA16852@lapse.rw.madduck.net>
Hi martin,
On Thu, Dec 25, 2008 at 03:58:34PM +0100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.12.23.1530 +0100]:
> > I hacked using topgit for some time now, and found the following changes
> > to topgit useful:
> >
> > Uwe Kleine-König (3):
> > tg export: implement skipping empty patches for collapse driver
> > tg export: Implement flattening patch paths for quilt mode
> > tg export (quilt): Implement numbering the patches
>
> They all look good. I am a bit concerned about the use of
> single-letter options at this stage. tg-export is bound to grow, and
> using them all up now might mean breaking compatibility later, when
> a more common option needs e.g. -f, which has already been taken.
I updated my tree to make '-f' '--flatten'. IMHO -n is nice for getting
numbered patches, but if you prefer, I will make this --numbered.
Oh, and I just noticed that documentation is missing. I will fix this
when I sent this mail.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: getting started, happy with cmd line on windows [Scanned]
From: René Scharfe @ 2008-12-26 16:39 UTC (permalink / raw)
To: Conor Rafferty; +Cc: git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D07@ALTMORE-SVR.altmore.local>
Conor Rafferty schrieb:
> I then deleted all files from the working directory, so I can pull out
> ONLY the ones in version A.
> I tried both fetch and checkout - but nothing was copied into working
> dir How do I do this ?
git treats deleted files just like edited files: as having been changed
in preparation for the next commit. You can get back all of the tracked
files using this command:
$ git reset --hard
It undoes _all_ changes: tracked edited files will be reverted to their
in-repository state, deleted files created again. You can also check
out individual files like this:
$ git checkout ABC.txt
If you just want to get rid of untracked files, you'd use the command
"git clean".
In general, if you switch your work tree from one revision to another
(git checkout), git tries to minimize the I/O needed. Files that are
the same in both aren't touched.
René
^ permalink raw reply
* Re: Strange large push operation.
From: Sitaram Chamarty @ 2008-12-26 14:48 UTC (permalink / raw)
To: git
In-Reply-To: <4954CCD6.5000105@daysofwonder.com>
On 2008-12-26, Brice Figureau <brice+git@daysofwonder.com> wrote:
> Then I wanted to push this newbranch as a remote branch with:
> $ git push origin newbranch:refs/heads/newbranch
I'd have just said "git push origin newbranch" :-)
> and obtained the following output:
> Counting objects: 12767, done.
> Compressing objects: 100% (3816/3816), done.
> writing objects: 8% (935/11682), 2.40 MiB | 324 KiB/s
> ^C
> I stopped the push because I don't get why there are so much objects to
> send while the diff between newbranch and branch is only 5 small commits
> (and it obviously wants to push a large part of the history).
Yes but you didn't actually say that the master has "branch"
-- perhaps it isn't as uptodate as you thought it was...?
Or perhaps there was a rebase or something that changed a
*lot* of stuff.
Try "git log -n 1 branch" on both machines to see if they
point to the same hash.
[Additionally, I'm not really sure if that progress is a
worst case estimate or a real estimate...]
> Is there a way to check what objects are sent to origin and why?
My all-time favourite git command is "bundle" [which should
tell you I work a lot with disconnected repos!]
Try "git bundle create /tmp/temp.bdl branch..newbranch" then
see how big that temp file is. That'll be about what goes
to the other side (assuming the other side has the same hash
for "branch").
You could even take it to the other side and do the
following:
git ls-remote temp.bdl # shows refs in bundle
git fetch temp.bdl one-of-the-refs-in-the-bundle
git merge FETCH_HEAD # merge it into current branch
> What could be the cause of the issue?
can't say. Try the following commands also to get a birds
eye view of the various branches on both sides
git fetch # update your idea of what's on remote
git branch -a -v
I also like
git log --graph --pretty=oneline --abbrev-commit --decorate --all
which I've aliased to "lg"
> (and found 5 unreachables objects in the local one, should I care?). I
Nope. Lots of reasons to have unreachable objects...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-26 14:42 UTC (permalink / raw)
To: git
In-Reply-To: <7vvdt884xu.fsf@gitster.siamese.dyndns.org>
On Thu, 25 Dec 2008, Junio C Hamano wrote:
> build process); it is plausible that it has broken checks for detecting
> the need of NO_UINTMAX_T.
>
> Relevant part of configure.ac reads like this:
>
> # Define NO_UINTMAX_T if your platform does not have uintmax_t
> AC_CHECK_TYPE(uintmax_t,
> [NO_UINTMAX_T=],
> [NO_UINTMAX_T=YesPlease],[
> #include <inttypes.h>
> ])
> AC_SUBST(NO_UINTMAX_T)
>
> and I do not see anything suspicious there...
Thanks, I guess the configure is not part of the repository and I use
a legacy configure from earlier version. After I run the make
configure again, it is now ok.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩093 駱賓王 在獄詠蟬
西路蟬聲唱 南冠客思侵 那堪玄鬢影 來對白頭吟
露重飛難進 風多響易沉 無人信高潔 誰為表予心
^ 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