* [PATCH 0/2] Fix the building of Info documents
From: Teemu Likonen @ 2008-12-29 8:03 UTC (permalink / raw)
To: git; +Cc: gitster
In these days Info documents are probably only used by Emacs users. I'm
one, so I wanted to fix the building of Git Info documents. And it's
even possible - to certain extent.
My real opinion is that the document conversion chain .txt - .xml -
.texi - .info. just can't work without a miracle. These patches
certainly don't do a miracle but they allow building an usable Info
version of the user manual and the man pages. As usual, there are
problems with markup conversions. For example, two dashes (--) in a
.texi file turn into one Ascii dash (-), so there are options like
"-interactive" and "-stat" in the Info documents. I wouldn't advertise
these documents very loudly to the public.
(My real real real opinion is that the GNU people should drop the Info
system and start using html instead. Html probably isn't a simple
drop-in replacement but at least it's a relevant format in 2008-2009.)
Teemu Likonen (2):
Fix the building of user-manual.texi and gitman.texi documents
Fix the building of gitman.info document
Documentation/Makefile | 9 +++++----
Documentation/cat-texi.perl | 8 ++++++--
2 files changed, 11 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH] http-push: support full URI in handle_remote_ls_ctx()
From: Junio C Hamano @ 2008-12-29 8:36 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <1230517935-11299-1-git-send-email-catap@catap.ru>
Thanks; already applied ;-)
^ permalink raw reply
* Re: [PATCH 1/2] Fix the building of user-manual.texi and gitman.texi documents
From: Junio C Hamano @ 2008-12-29 8:39 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <1230537789-5376-2-git-send-email-tlikonen@iki.fi>
I do not build nor use info myself these days, so I'll apply the patches
but when somebody else screams I'll let you and that somebody else work on
improvements.
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation/diff-options.txt: unify options
From: Junio C Hamano @ 2008-12-29 8:47 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763l331l6.fsf@jidanni.org>
Thanks.
jidanni@jidanni.org writes:
> (You were right about my previous patch being bad.
> At least git-am gives an error message when fed
> http://article.gmane.org/gmane.comp.version-control.git/104017/raw
> git-apply however does nothing and returns 0! Must be a bug.)
> OK, here's a better patch:
>
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
That commentary above your S-o-b is not a proper commit log message, but
I'll come up with something and apply.
$ wget http://article.gmane.org/gmane.comp.version-control.git/104017/raw
$ git apply raw
error: diff-options.txt: No such file or directory
$ echo $?
1
Even if you hand munge the "raw" file to have proper prefix, it will
refuse to apply a context-free diff.
$ git apply raw-edited
error: patch failed: Documentation/diff-options.txt:26
error: Documentation/diff-options.txt: patch does not apply
$ echo $?
1
This is to avoid applying the patch only by line number without context;
see the last paragraph of <7vvdt4aj0e.fsf@gitster.siamese.dyndns.org> for
the explanation.
Upon a very rare case where you are absolutely sure that your copy is what the
patch is based on and that it is safe to applying a context-free patch
only by line number, you can give --unidiff-zero option to git-apply to
countermand this safety measure, but a patch posted on the public mailing
list for open source development rarely falls into that category.
^ permalink raw reply
* Re: [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: Nanako Shiraishi @ 2008-12-29 8:52 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: jidanni, git
In-Reply-To: <bd6139dc0812280900t12189c6anb583033e52a5b027@mail.gmail.com>
Quoting "Sverre Rabbelier" <srabbelier@gmail.com>:
> On Fri, Dec 26, 2008 at 16:02, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Quoting jidanni@jidanni.org:
>>
>>> Signed-off-by: jidanni <jidanni@jidanni.org>
>>
>> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
>
> Be nice, they are obviously a bit peculiar about their name/sign-off name :).
If you are telling me that I said something un-nice, I apologize. I did not mean to offend anybody. But I do not understand. Who do you mean by they in your sentence?
> --
> Cheers,
>
> Sverre Rabbelier
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-add --verbose should say when something is already indexed
From: Nanako Shiraishi @ 2008-12-29 8:52 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87eizr32db.fsf@jidanni.org>
Quoting jidanni@jidanni.org:
> git-add or at least git-add --verbose should say upon
> $ git-add bla.txt
> $ git-add bla.txt
> bla.txt is already in the index.
I do not think it should.
I suspect that you misunderstand what "git add" is. It is not about adding a new path to be tracked. Rather, it is to add the current contents of the file (unless --interactive is used).
You told git to add the contents of "bla.txt" to the index as path "bla.txt". I do not think there is anything more to report after it did exactly what it was told to do.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: some git-commands --help don't act like git commands --help
From: Nanako Shiraishi @ 2008-12-29 8:53 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87iqp333bk.fsf@jidanni.org>
Quoting jidanni@jidanni.org:
> Hmmm, some git-commands --help act just like git commands --help,
> $ git commit --help 2>&1|wc -l
> 336
> $ git-commit --help 2>&1|wc -l
> 336
>
> But others don't
> $ git am --help 2>&1|wc -l
> 152
> $ git-am --help 2>&1|wc -l
> 19
Thank you for your observation; what do you want to do about it?
Are you complaining that some commands do not have customized description that is not as long as the full manual page but not as terse as the short help "-h" output? Or are you complaining some other commands do not give you full manual pages for "--help"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-add --verbose should say when something is already indexed
From: Junio C Hamano @ 2008-12-29 9:02 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: jidanni, git
In-Reply-To: <20081229175258.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting jidanni@jidanni.org:
>
>> git-add or at least git-add --verbose should say upon
>> $ git-add bla.txt
>> $ git-add bla.txt
>> bla.txt is already in the index.
>
> I do not think it should.
>
> I suspect that you misunderstand what "git add" is. It is not about adding a new path to be tracked. Rather, it is to add the current contents of the file (unless --interactive is used).
>
> You told git to add the contents of "bla.txt" to the index as path "bla.txt". I do not think there is anything more to report after it did exactly what it was told to do.
That is almost (say, 98%) true, but it is not absolutely outlandishly
unreasonable if somebody wants:
$ git add bla.txt
$ edit bla.txt
$ git add bla.txt
and
$ git add bla.txt
$ git add bla.txt
to behave differently. The latter is a pure no-op.
Having said that, I do not think it is worth it. For one thing, if you
did:
$ git add .
after making changes to a few files and created one new file in a project
with 20,000 files, command would say "Yo, bozo, you told me to add the
same contents for path X" for 19,998 times.
If the report were not negative as Jidanni suggests, but instead were
positive, i.e.
$ git add -v frotz.txt nitfol.txt
added new contents for frotz.txt
added new contents for nitfol.txt
$ edit frotz.txt
$ git add -v frotz.txt nitfol.txt
added new contents for frotz.txt
it might be slightly more useful, but I doubt it is that useful in
practice.
I won't reject a patch if it is cleanly done, though.
^ permalink raw reply
* Re: [PATCH v2] diff: add option to show context between close hunks
From: Junio C Hamano @ 2008-12-29 9:05 UTC (permalink / raw)
To: René Scharfe
Cc: Git Mailing List, Jeff King, Davide Libenzi, Johannes Sixt
In-Reply-To: <1230489932.8791.25.camel@ubuntu.ubuntu-domain>
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH] Documentation/diff-options.txt: unify options
From: Junio C Hamano @ 2008-12-29 9:10 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <7vabafe5ai.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> That commentary above your S-o-b is not a proper commit log message, but
> I'll come up with something and apply.
Here is what I came up with and applied.
Documentation/diff-options.txt: unify options
Instead of listing short option (e.g. "-U<n>") as a shorthand for its
longer counterpart (e.g. "--unified=<n>"), list the synonyms together. It
saves one indirection to find what the reader wants.
Signed-off-by: jidanni <jidanni@jidanni.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks.
^ permalink raw reply
* [PATCH] t7500-commit.sh: do not call test_set_editor unnecessarily, it's confusing
From: Adeodato Simó @ 2008-12-29 9:24 UTC (permalink / raw)
To: git, gitster; +Cc: Adeodato Simó
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
I was reading this test case, and it took a small bit to figure out the
editor was not being used at all. I hope there was no hidden reason for
it to be there, and it can go away.
Cheers,
t/t7500-commit.sh | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index 6e18a96..5998baf 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -149,10 +149,7 @@ EOF
test_expect_success '--signoff' '
echo "yet another content *narf*" >> foo &&
- echo "zort" | (
- test_set_editor "$TEST_DIRECTORY"/t7500/add-content &&
- git commit -s -F - foo
- ) &&
+ echo "zort" | git commit -s -F - foo &&
git cat-file commit HEAD | sed "1,/^$/d" > output &&
test_cmp expect output
'
--
1.6.1.307.g07803
^ permalink raw reply related
* Re: [PATCH] t7500-commit.sh: do not call test_set_editor unnecessarily, it's confusing
From: Junio C Hamano @ 2008-12-29 9:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Adeodato Simó
In-Reply-To: <1230542658-9758-1-git-send-email-dato@net.com.org.es>
Adeodato Simó <dato@net.com.org.es> writes:
> I was reading this test case, and it took a small bit to figure out the
> editor was not being used at all. I hope there was no hidden reason for
> it to be there, and it can go away.
That 'zort' came from 1320857 (builtin-commit: fix --signoff, 2007-11-11),
and I _think_ it is trying to make sure that presense of "-F -" makes the
editor not to trigger.
Dscho?
^ permalink raw reply
* Re: some git-commands --help don't act like git commands --help
From: Michael Gaber @ 2008-12-29 9:48 UTC (permalink / raw)
To: git
In-Reply-To: <20081229175305.6117@nanako3.lavabit.com>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
Nanako Shiraishi schrieb:
> Quoting jidanni@jidanni.org:
>
>> Hmmm, some git-commands --help act just like git commands --help,
>> $ git commit --help 2>&1|wc -l
>> 336
>> $ git-commit --help 2>&1|wc -l
>> 336
>>
>> But others don't
>> $ git am --help 2>&1|wc -l
>> 152
>> $ git-am --help 2>&1|wc -l
>> 19
>
> Thank you for your observation; what do you want to do about it?
>
> Are you complaining that some commands do not have customized description that is not as long as the full manual page but not as terse as the short help "-h" output? Or are you complaining some other commands do not give you full manual pages for "--help"?
>
I think he just wantet to state that the output of git-command --help
and git command --help should be identical as the both do the same
thing, don't they?
Regards Michael
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3656 bytes --]
^ permalink raw reply
* Re: [PATCH] t7500-commit.sh: do not call test_set_editor unnecessarily, it's confusing
From: Adeodato Simó @ 2008-12-29 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vmyefco11.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [Mon, 29 Dec 2008 01:46:02 -0800]:
> Adeodato Simó <dato@net.com.org.es> writes:
> > I was reading this test case, and it took a small bit to figure out the
> > editor was not being used at all. I hope there was no hidden reason for
> > it to be there, and it can go away.
> That 'zort' came from 1320857 (builtin-commit: fix --signoff, 2007-11-11),
> and I _think_ it is trying to make sure that presense of "-F -" makes the
> editor not to trigger.
Hm. Well, if that is true, then IMHO it should be in a /separate/ test
case, for clarity. Probably in "message from stdin" test from t7501.
That's of course just my opinion, and I'll accept if you prefer to
maintain it the way it is now. I also volunteer to move it to t7501 if
that's what you prefer, just let me know.
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Justin Nozuka - I'm In Peace
^ permalink raw reply
* Re: some git-commands --help don't act like git commands --help
From: Junio C Hamano @ 2008-12-29 9:54 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: jidanni, git
In-Reply-To: <20081229175305.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting jidanni@jidanni.org:
>
>> Hmmm, some git-commands --help act just like git commands --help,
>> $ git commit --help 2>&1|wc -l
>> 336
>> $ git-commit --help 2>&1|wc -l
>> 336
>>
>> But others don't
>> $ git am --help 2>&1|wc -l
>> 152
>> $ git-am --help 2>&1|wc -l
>> 19
>
> Thank you for your observation; what do you want to do about it?
>
> Are you complaining that some commands do not have customized description that is not as long as the full manual page but not as terse as the short help "-h" output? Or are you complaining some other commands do not give you full manual pages for "--help"?
I think he is comparing "git am" and "git-am" the latter of which is now
deprecated and largely removed from the end user.
IOW, the seeming inconsistency is not an issue anymore in practice in the
post 1.6.0 era.
^ permalink raw reply
* Re: [PATCH] t7500-commit.sh: do not call test_set_editor unnecessarily, it's confusing
From: Junio C Hamano @ 2008-12-29 9:57 UTC (permalink / raw)
To: Adeodato Simó; +Cc: Johannes Schindelin, git
In-Reply-To: <20081229095220.GA26942@chistera.yi.org>
Adeodato Simó <dato@net.com.org.es> writes:
> * Junio C Hamano [Mon, 29 Dec 2008 01:46:02 -0800]:
> ...
>> That 'zort' came from 1320857 (builtin-commit: fix --signoff, 2007-11-11),
>> and I _think_ it is trying to make sure that presense of "-F -" makes the
>> editor not to trigger.
>
> Hm. Well, if that is true, then IMHO it should be in a /separate/ test
> case, for clarity. Probably in "message from stdin" test from t7501.
>
> That's of course just my opinion, and I'll accept if you prefer to
> maintain it the way it is now. I also volunteer to move it to t7501 if
> that's what you prefer, just let me know.
I underscored _think_ and CC'ed Dscho for a reason.
If "-F -" has a bug, and if you do not define GIT_EDITOR, your test may
not work unattended (i.e. neither succeed nor finish but gets stuck).
Perhaps that is the issue? I dunno.
^ permalink raw reply
* Re: some git-commands --help don't act like git commands --help
From: Nanako Shiraishi @ 2008-12-29 10:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jidanni, git
Quoting Junio C Hamano <gitster@pobox.com>:
> I think he is comparing "git am" and "git-am" the latter of which is now
> deprecated and largely removed from the end user.
>
> IOW, the seeming inconsistency is not an issue anymore in practice in the
> post 1.6.0 era.
Ah, I misread that distinction in the OP's message.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH v3] Add a commit.signoff configuration option to always use --signoff in commit
From: Adeodato Simó @ 2008-12-29 11:16 UTC (permalink / raw)
To: git, gitster; +Cc: Adeodato Simó
In-Reply-To: <20081227120128.GA11322@chistera.yi.org>
The intent is that it only applies when the user runs `git commit`
themselves, hence a number of commands (rebase and revert/cherry-pick)
have started passing --no-signoff when invoking commit.
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
Hello, I've worked a bit more on this patch, and I'd like to know if
it's going in a good direction or not. Changes since v2:
t/t7500-commit.sh | 22 ++++++++++++++++++++++
* add tests to check that commit.signoff works correctly, and that
is overriden by --no-signoff
git-rebase.sh | 2 +-
t/t3402-rebase-merge.sh | 6 +++++-
* make git-rebase pass --no-signoff when invoking `git commit`, and
add a test for it
builtin-revert.c | 2 ++
* make revert/cherry-pick pass --no-signoff unless -s was given by
the user (missing test)
Documentation/config.txt | 4 ++--
* improve config.txt wording as per <20081227120128.GA11322@chistera.yi.org>
(I don't know if it's customary to send a diff from v2 to v3, if it is
please let me know.)
Thanks,
Documentation/config.txt | 9 +++++++++
Documentation/git-commit.txt | 3 ++-
builtin-commit.c | 5 +++++
builtin-revert.c | 2 ++
git-rebase.sh | 2 +-
t/t3402-rebase-merge.sh | 6 +++++-
t/t7500-commit.sh | 22 ++++++++++++++++++++++
7 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 52786c7..13f2200 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -591,6 +591,15 @@ color.ui::
commit.template::
Specify a file to use as the template for new commit messages.
+commit.signoff::
+ If set, 'git commit' will behave as if '-s' option was given.
+ Please use this option with care: by enabling it globally, you'd
+ be stating that all your commits will invariably meet the S-o-b
+ requirements for any project you send patches to. It's probably
+ best to only use it from your private repositories' .git/config
+ file, and only for projects who require a S-o-b as proof of
+ provenance of the patch, and not of its correctness or quality.
+
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);
}
diff --git a/builtin-revert.c b/builtin-revert.c
index d48313c..395c7a5 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -429,6 +429,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
args[i++] = "-n";
if (signoff)
args[i++] = "-s";
+ else
+ args[i++] = "--no-signoff";
if (!edit) {
args[i++] = "-F";
args[i++] = defmsg;
diff --git a/git-rebase.sh b/git-rebase.sh
index ebd4df3..bf520d0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -63,7 +63,7 @@ continue_merge () {
cmt=`cat "$dotest/current"`
if ! git diff-index --quiet --ignore-submodules HEAD --
then
- if ! git commit --no-verify -C "$cmt"
+ if ! git commit --no-verify --no-signoff -C "$cmt"
then
echo "Commit failed, please do not call \"git commit\""
echo "directly, but instead do one of the following: "
diff --git a/t/t3402-rebase-merge.sh b/t/t3402-rebase-merge.sh
index 7b7d072..bd2d08c 100755
--- a/t/t3402-rebase-merge.sh
+++ b/t/t3402-rebase-merge.sh
@@ -41,7 +41,8 @@ test_expect_success setup '
git branch test-rebase side &&
git branch test-rebase-pick side &&
git branch test-reference-pick side &&
- git checkout -b test-merge side
+ git checkout -b test-merge side &&
+ git config commit.signoff true
'
test_expect_success 'reference merge' '
@@ -54,6 +55,9 @@ test_expect_success rebase '
GIT_TRACE=1 git rebase --merge master
'
+test_expect_success 'rebase uses --no-signoff' '
+ !(git log | grep -q Signed-off-by)'
+
test_expect_success 'test-rebase@{1} is pre rebase' '
test $PRE_REBASE = $(git rev-parse test-rebase@{1})
'
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index 6e18a96..c7deb3e 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -147,6 +147,10 @@ zort
Signed-off-by: C O Mitter <committer@example.com>
EOF
+cat > expect_no_signoff << EOF
+zort
+EOF
+
test_expect_success '--signoff' '
echo "yet another content *narf*" >> foo &&
echo "zort" | (
@@ -157,6 +161,24 @@ test_expect_success '--signoff' '
test_cmp expect output
'
+test_expect_success 'commit.signoff' '
+ echo "and more content" >> foo &&
+ git config commit.signoff true &&
+ echo "zort" | git commit -F - foo &&
+ git config --unset commit.signoff &&
+ git cat-file commit HEAD | sed "1,/^$/d" > output &&
+ test_cmp expect output
+'
+
+test_expect_success '--no-signoff trumps commit.signoff' '
+ echo "and even more" >> foo &&
+ git config commit.signoff true &&
+ echo "zort" | git commit --no-signoff -F - foo &&
+ git config --unset commit.signoff &&
+ git cat-file commit HEAD | sed "1,/^$/d" > output &&
+ test_cmp expect_no_signoff output
+'
+
test_expect_success 'commit message from file (1)' '
mkdir subdir &&
echo "Log in top directory" >log &&
--
1.6.1.307.g07803
^ permalink raw reply related
* Re: [PATCH v3] Add a commit.signoff configuration option to always use --signoff in commit
From: Adeodato Simó @ 2008-12-29 11:18 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <1230549405-10000-1-git-send-email-dato@net.com.org.es>
> Changes since v2:
(Updating git-rebase--interactive.sh is still missing, I know.)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
He who has not a good memory should never take upon himself the trade of lying.
-- Michel de Montaigne
^ permalink raw reply
* Re: [PATCH] gitweb: Fix export check in git_get_projects_list
From: Jakub Narebski @ 2008-12-29 12:29 UTC (permalink / raw)
To: Devin Doucette; +Cc: git, Petr Baudis
In-Reply-To: <200812280312.02615.jnareb@gmail.com>
On Sun, 28 Dec 2008, Jakub Narebski wrote:
> On Sat, 27 Dec 2008, Devin Doucette wrote:
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 8f574c7..99f71b4 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -2147,8 +2147,9 @@ sub git_get_projects_list {
> >
> > my $subdir = substr($File::Find::name, $pfxlen + 1);
> > # we check related file in $projectroot
> > - if (check_export_ok("$projectroot/$filter/$subdir")) {
> > - push @list, { path => ($filter ? "$filter/" : '') . $subdir };
> > + my $path = ($filter ? "$filter/" : '') . $subdir;
>
> Nice and clear, but wouldn't be better to use slightly more effective
>
> + my $path = $filter ? "$filter/$subdir" : $subdir;
>
> Or even, taking care of the case when $filter eq '0'
>
> + my $path = defined $filter && $filter ne '' ? "$filter/$subdir" : $subdir;
Err, actually with "$filter ||= '';" earlier in git_get_projects_list
this is not necessary, and is not an improvement.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] doc/git-send-email: mention sendemail.cc config variable
From: Thomas Rast @ 2008-12-29 13:00 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git, gitster
In-Reply-To: <200812290037.25890.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
Markus Heidelberg wrote:
> Specify a starting "Cc:" value for each email.
> + Default is the value of 'sendemail.cc'.
> +
> The --cc option must be repeated for each user you want on the cc list.
Judging from the source, this is not a default value that you can
override: any recipients listed in sendemail.cc configuration(s) are
always added to the Cc list. The same goes for --bcc and
sendemail.bcc however, which uses the exact same formulation.
Maybe something like
You can also add Cc recipients via 'sendemail.cc' configuration
settings.
would clarify?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] doc/git-send-email: mention sendemail.cc config variable
From: Markus Heidelberg @ 2008-12-29 13:29 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <200812291400.08924.trast@student.ethz.ch>
Thomas Rast, 29.12.2008:
> Markus Heidelberg wrote:
> > Specify a starting "Cc:" value for each email.
> > + Default is the value of 'sendemail.cc'.
> > +
> > The --cc option must be repeated for each user you want on the cc list.
>
> Judging from the source, this is not a default value that you can
> override: any recipients listed in sendemail.cc configuration(s) are
> always added to the Cc list. The same goes for --bcc and
> sendemail.bcc however, which uses the exact same formulation.
OK, and --to and sendemail.to is also affected.
> Maybe something like
>
> You can also add Cc recipients via 'sendemail.cc' configuration
> settings.
>
> would clarify?
It is already in next, I think a following patch should be against next
now, shouldn't it?
Markus
^ permalink raw reply
* gitk "reset branch to here" bug in Cygwin
From: Hannu Koivisto @ 2008-12-29 13:41 UTC (permalink / raw)
To: git
Greetings,
First create a test repository with two commits:
mkdir gittest3
cd gittest3
git init
echo foo > foo
git add foo
git commit -m "Foo"
echo foo >> foo
git add foo
git commit -m "2nd. foo"
Now start gitk, point at the first commit and from the context menu
select "Reset master branch to here" and then "Hard:...".
The result is 'can not find channel named "1"'.
git reset --hard HEAD\^1 in the same repository works fine.
Tested with 159c88e5ae95c5b02298193c1658fac5919c8012 (1.6.1 plus a
few commits) on Windows XP.
--
Hannu
^ permalink raw reply
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Joe Casadonte @ 2008-12-29 14:54 UTC (permalink / raw)
To: git
In-Reply-To: <ud4fdxn08.fsf@terrapin.northbound-train.com>
Joe Casadonte <jcasadonte <at> northbound-train.com> writes:
> The same test machine has cloned from a different linux server via the
> git protocol just fine.
>
> Any ideas? Thanks for the help!
Does anyone know of more logging I can try to help diagnose the issue? Despite
the SSH work-around, this is really hampering me....
^ permalink raw reply
* [PATCH] bash: add '--merge' to 'git reset'
From: SZEDER Gábor @ 2008-12-29 15:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3491fd0..f6c3755 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1408,7 +1408,7 @@ _git_reset ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
- __gitcomp "--mixed --hard --soft"
+ __gitcomp "--merge --mixed --hard --soft"
return
;;
esac
--
1.6.1.57.gdceb8
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox