* 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
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-26 14:33 UTC (permalink / raw)
To: git
In-Reply-To: <3af572ac0812251053q3b3c27e1i109a780fa657dd1f@mail.gmail.com>
On Thu, 25 Dec 2008, Pau Garcia i Quiles wrote:
> Works for me both in Hardy and Intrepid. If you have trouble building
> from source, there are binary package for Hardy and Intrepid in my
> PPA:
> http://launchpad.net/~pgquiles/+archive
Thanks you head up. No problem now, but I'll bookmark your page.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩281 劉禹錫 春詞
新妝宜面下朱樓 深鎖春光一院愁 行到中庭數花朵 蜻蜓飛上玉搔頭
^ permalink raw reply
* getting started, happy with cmd line on windows [Scanned]
From: Conor Rafferty @ 2008-12-26 13:52 UTC (permalink / raw)
To: git
We want to use git to
a) archive old versions of our project that have till now had no SCM
applied
b) moving forward, provide robust SCM on new versions of project
Just to get familiar, I created a folder, ran
$ git init
then created a few files: ABC.txt, AC.txt, BC.txt, C.txt This mimics our
real life sitch for purpose (a), files are in version A, but not in
version B, which introduces new files, whick might not be in version C
$ git add *c*.txt
$ git commit -m "version A"
so now ABC.txt and AC.txt are in the repo, at a commit with comment
"version A"
$ git show
confirms this
$ git status
confirms that BC.txt and C.txt have not been tracked - great, as
designed
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 ?
NB along the way I also tagged this first commit as "tag_versionA"
also tried
$ git checkout tag_versionA
which changed HEAD back to version A, but didn't create the files
Seems like I'm missing some fundamental concepts here - from other
SCM's, I understood fetch or checkout would copy files into your working
dir that were replicas of the versions stored in repository
--
<http://www.altmore.co.uk/xNON_SITE/SignatureFiles/AltmoreIT_signature_l
ogo.JPG>
Conor Rafferty BSc (Hons.)
REGIONAL MANAGER
Altmore IT Recruitment
Townsend Enterprise Park
28 Townsend Street
Belfast BT13 2ES
T: +44 (0)28 9032 8400
E: conor.rafferty@altmore.co.uk
W: www.altmore.co.uk <http://www.altmore.co.uk/>
LinkedIn: http://www.linkedin.com/in/conorrafferty
________________________________
This electronic message contains information from Altmore IT Recruitment
which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are
not the intended recipient be aware that any disclosure, copying
distribution or use of the contents of this information is prohibited.
If you have received this electronic message in error, please notify us
by telephone or email (to the numbers or address above) immediately.
^ permalink raw reply
* Re: Why does git-describe warn about something that you can't control?
From: René Scharfe @ 2008-12-26 13:44 UTC (permalink / raw)
To: demerphq; +Cc: git, Shawn O. Pearce
In-Reply-To: <9b18b3110812260350q6870700du982ec3a7a91950e2@mail.gmail.com>
demerphq schrieb:
> On the perl.git repo if I use git-describe --all on some commits I get
> warnings like this:
>
> $ git describe --all 3417e4f8422bcf13f799ce1acef44b27ccbef3d8
> warning: tag 'perl-5.005_04' is really 'tags/perl-5.005_04' here
> perl-5.005_04
>
> Except there doesnt seem to be any explanation for why the warning is
> being produced (it almost, but not quite looks random for the commits
> im looking at), how to silence it, or how to force git-describe to for
> instance use "tags/perl-5.8.0" instead so the warning is not
> generated.
>
> I think this behaviour is confusing, either the warning should go
> away, or it should be improved and complemented by a switch to force
> git-describe to use the qualified tagname instead, or at the very
> least a switch to silence the warning (which is really annoying when
> you are doing git-describe on hundreds of commits in a go).
The warning was introduced by 212945d4 ("Teach git-describe to verify
annotated tag names before output") by Shawn (cc:'d).
The following patch should fix your issue by making describe ignore the
"tags/" path prefix of, well, tags, which is only present if you call
it with the option --all.
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);
}
^ permalink raw reply related
* [PATCH] Add a commit.signoff configuration variable to always use --signoff.
From: Adeodato Simó @ 2008-12-26 12:56 UTC (permalink / raw)
To: git, gitster
Signed-off-by: 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.
Well, it seemed easy enough to do, so I went ahead. Comments would be
welcome.
Documentation/config.txt | 6 ++++++
Documentation/git-commit.txt | 3 ++-
builtin-commit.c | 5 +++++
3 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 52786c7..6d195a3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -591,6 +591,12 @@ color.ui::
commit.template::
Specify a file to use as the template for new commit messages.
+commit.signoff::
+ If set, 'git-commit' will always add a Signed-off-by line. If
+ you don't want it always active, you can still set it in the
+ repository specific configuration file for projects that require
+ a Signed-off-by line for all commits.
+
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index b5d81be..abab839 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -96,7 +96,8 @@ OPTIONS
-s::
--signoff::
Add Signed-off-by line by the committer at the end of the commit
- log message.
+ log message. This overrides the `commit.signoff` configuration
+ variable.
-n::
--no-verify::
diff --git a/builtin-commit.c b/builtin-commit.c
index e88b78f..fc09539 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -929,6 +929,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
if (!strcmp(k, "commit.template"))
return git_config_string(&template_file, k, v);
+ if (!strcmp(k, "commit.signoff")) {
+ signoff = git_config_bool(k, v);
+ return 0;
+ }
+
return git_status_config(k, v, cb);
}
--
1.6.1.307.g07803
^ permalink raw reply related
* Re: Managing several threads of the same project in GIT
From: Sitaram Chamarty @ 2008-12-26 12:35 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20081226T110416-269@post.gmane.org>
On 2008-12-26, pggrd <git@paggard.com> wrote:
> most of the code in the project is shared between the threads
> in certain files there are different code parts to meet client requirements
> but even those files share the rest of the code
How different are the chunks of code per client? A few
minor differences, or large chunks of code?
> What I need to be able to do is:
> - to get code for any thread I like at any time
> - to be able to develop each thread separately
> - to be able to merge certain changes from one thread to another, at the same
> time without loosing the changes specific to the thread,
> and keep track of merge history
> With GIT strategy to treat content as a single unity - if
> you will try to merge branches - everything will be merged
> thus overwriting the changes that need to stay. But in the
> example above, if I make a change in the shared code in
> one thread, I need to be able to populate this change to
> all the threads, but this change only.
Seems largely the same as maintaining an older release and
backporting changes from the main trunk to it (or sometimes
the other direction), while keeping them distinct. Which
happens all the time...
However, a maint release eventually atrophies -- changes
stop coming in, and eventually your last customer using it
has upgraded and the branch becomes unused.
You can't do that with your "client branch", so eventually
this will start diverging further and further from the
trunk.
The way to mitigate that is to have your main trunk contain
only the stuff that is common to *all* your clients, and let
each client branch maintain differences from this. So in
effect, those "topic branches" are never getting merged back
to the mainline. When you make changes that should go to
every client, you make them on the master and merge them
into the "topic branch" (your client branch). When you want
a commit from client A to be used for client B, you
cherry-pick (cherry-pick from within gitk is pretty neat for
occasional, manual, cherry picks).
The only caveat I see is that once in a while you'll want to
just rebase each client branch against the master just for
sanity. This should be done on one repository, and be a
coordinated thing so that all the developers who're working
on that particular client branch can re-fetch. You might
end up doing this once in a few months so it's not bad I
guess.
Sitaram
PS: I think all this will work, but others with more
experience need to weigh in... it's always a bad idea to ask
questions during the holidays, you never know who's manning
the support lines ;-)
PPS: As Santi said in the other reply, you should also
consider making these changes part of a single code base,
with some sort of configuration deciding what actually gets
done. Would be cleaner in the long run I guess...
^ permalink raw reply
* Strange large push operation.
From: Brice Figureau @ 2008-12-26 12:23 UTC (permalink / raw)
To: git
Hi,
I'm a git user since about a year, but I can't say I'm really familiar
with its internals. I am using git v 1.5.6.5
I have a quite large bare remote repository (around 1GiB, about 86k
objects), and I have a clone on my development computer (which was
cloned a long time ago). I use ssh to push/pull between those repositories.
About 2 months ago, we created a remote branch (let's call it 'branch')
and pursued development on this branch and also on master, with a few
regular merge points from master to 'branch'.
Two days ago, I wanted to start developping a new feature, and as such
created a local branch from this branch, which we'll call 'newbranch'. I
cherrypicked a couple of old (4 months) commits that were in another
local branch, and then added more small commits (about 10 sloc of
changes on it) on top of these.
Then I wanted to push this newbranch as a remote branch with:
$ git push origin newbranch:refs/heads/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).
Is there a way to check what objects are sent to origin and why?
What could be the cause of the issue?
What's wrong with those repositories?
I tried to git gc both repositories, I also git fsck both repositories
(and found 5 unreachables objects in the local one, should I care?). I
also upgraded the remote git to latest 1.6.0.6 but this didn't change
anything. I also tried --thin but that didn't change anything.
So what should I do to push only the changes between branch and newbranch?
Many thanks for any answer,
--
Brice Figureau
^ permalink raw reply
* [PATCH] git-shortlog.txt: improve documentation about .mailmap files
From: Adeodato Simó @ 2008-12-26 11:55 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <1230290283-6268-1-git-send-email-dato@net.com.org.es>
The previous .mailmap example made it seem like .mailmap files are only
useful for commits with a wrong address for an author, when they are about
fixing the real name. Explained this better in the text, and replaced the
existing example with a new one that hopefully makes things clearer.
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
Now with a Signed-off-by line. 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.
Documentation/git-shortlog.txt | 31 ++++++++++++++++++++++++-------
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 7ccf31c..69e10a4 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -48,15 +48,32 @@ OPTIONS
FILES
-----
-If the file `.mailmap` exists, it will be used for mapping author
-email addresses to a real author name. One mapping per line, first
-the author name followed by the email address enclosed by
-'<' and '>'. Use hash '#' for comments. Example:
+If a file `.mailmap` exists in the toplevel directory of the repository,
+it will be used for mapping author email addresses to a canonical real
+name. This can be used to coalesce together commits by the same person
+where their name was spelled differently (whether with the same email
+address or not).
+
+The format of the file is one mapping per line, first the desired author
+name followed by the email address enclosed by '<' and '>'. Use hash '#'
+for comments. For example, if your history contains commits by these
+committers:
+
+------------
+Author: Joe Developer <joe@random.com>
+Author: Joe R. Developer <joe@random.com>
+Author: Jane Doe <jane@the-does.name>
+Author: Jane Doe <jane@laptop.(none)>
+Author: Jane D. <jane@desktop.(none)>
+------------
+
+Then a proper `.mailmap` file would be:
------------
-# Keep alphabetized
-Adam Morrow <adam@localhost.localdomain>
-Eve Jones <eve@laptop.(none)>
+# Note how we don't need an entry for <jane@laptop.(none)>, because the
+# real name of that author is correct already, and coalesced directly.
+Jane Doe <jane@desktop.(none)>
+Joe R. Developer <joe@random.com>
------------
Author
--
1.6.1
^ permalink raw reply related
* Why does git-describe warn about something that you can't control?
From: demerphq @ 2008-12-26 11:50 UTC (permalink / raw)
To: git
On the perl.git repo if I use git-describe --all on some commits I get
warnings like this:
$ git describe --all 3417e4f8422bcf13f799ce1acef44b27ccbef3d8
warning: tag 'perl-5.005_04' is really 'tags/perl-5.005_04' here
perl-5.005_04
Except there doesnt seem to be any explanation for why the warning is
being produced (it almost, but not quite looks random for the commits
im looking at), how to silence it, or how to force git-describe to for
instance use "tags/perl-5.8.0" instead so the warning is not
generated.
I think this behaviour is confusing, either the warning should go
away, or it should be improved and complemented by a switch to force
git-describe to use the qualified tagname instead, or at the very
least a switch to silence the warning (which is really annoying when
you are doing git-describe on hundreds of commits in a go).
Details for the perl repo are in my signature.
Yves
--
git clone git://perl5.git.perl.org/perl
^ 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