* 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: 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
* [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] 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
* 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: 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: 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: 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: [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: [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 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] 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
* [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
* [PATCH 1/2] Fix the building of user-manual.texi and gitman.texi documents
From: Teemu Likonen @ 2008-12-29 8:03 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1230537789-5376-1-git-send-email-tlikonen@iki.fi>
Previously "docbook2x-texi" failed to generate user-manual.texi and
gitman.texi files from .xml input files because "iconv" stopped at
"illegal input sequence" error. This was due to some UTF-8 octets in the
input .xml files. This patch adds option --encoding=UTF-8 for
"docbook2x-texi" to allow the building of .texi files complete.
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
---
Documentation/Makefile | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index c34c1ca..c41a7b4 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -187,13 +187,14 @@ git.info: user-manual.texi
user-manual.texi: user-manual.xml
$(RM) $@+ $@
- $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+
+ $(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout | \
+ $(PERL_PATH) fix-texi.perl >$@+
mv $@+ $@
gitman.texi: $(MAN_XML) cat-texi.perl
$(RM) $@+ $@
- ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \
- $(PERL_PATH) cat-texi.perl $@ >$@+
+ ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --encoding=UTF-8 \
+ --to-stdout $(xml);)) | $(PERL_PATH) cat-texi.perl $@ >$@+
mv $@+ $@
gitman.info: gitman.texi
--
1.6.1.16.gd45c5
^ permalink raw reply related
* [PATCH 2/2] Fix the building of gitman.info document
From: Teemu Likonen @ 2008-12-29 8:03 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1230537789-5376-2-git-send-email-tlikonen@iki.fi>
"makeinfo" failed to generate gitman.info from gitman.texi input file
because the combined manual page file contains several nodes with the
same name (DESCRIPTION, OPTIONS, SEE ALSO etc.). An Info document should
contain unique node names.
This patch creates a simple (read: ugly) work-around by suppressing the
validation of the final Info file. Jumping to nodes in the Info document
still works but they are not very useful. Common man-page headings like
DESCRIPTION and OPTIONS appear in the Info node list and they point to
the man page where they appear first (that is git-add currently).
Also, this patch adds directory-entry information for Info document to
make the document appear in the top-level Info directory.
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
---
Documentation/Makefile | 2 +-
Documentation/cat-texi.perl | 8 ++++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index c41a7b4..5cd8b63 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -198,7 +198,7 @@ gitman.texi: $(MAN_XML) cat-texi.perl
mv $@+ $@
gitman.info: gitman.texi
- $(MAKEINFO) --no-split $*.texi
+ $(MAKEINFO) --no-split --no-validate $*.texi
$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
$(RM) $@+ $@
diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl
index dbc133c..828ec62 100755
--- a/Documentation/cat-texi.perl
+++ b/Documentation/cat-texi.perl
@@ -18,8 +18,12 @@ close TMP;
printf '\input texinfo
@setfilename gitman.info
-@documentencoding us-ascii
-@node Top,,%s
+@documentencoding UTF-8
+@dircategory Development
+@direntry
+* Git Man Pages: (gitman). Manual pages for Git revision control system
+@end direntry
+@node Top,,, (dir)
@top Git Manual Pages
@documentlanguage en
@menu
--
1.6.1.16.gd45c5
^ permalink raw reply related
* Re: [PATCH] http-push: support full URI in handle_remote_ls_ctx()
From: Mike Hommey @ 2008-12-29 7:17 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: Junio C Hamano, git
In-Reply-To: <1230517935-11299-1-git-send-email-catap@catap.ru>
On Mon, Dec 29, 2008 at 05:32:15AM +0300, Kirill A. Korinskiy wrote:
> The program calls remote_ls() to get list of files from the server
> over HTTP; handle_remote_ls_ctx() is used to parse its response to
> populate "struct remote_ls_ctx" that is returned from remote_ls().
>
> The handle_remote_ls_ctx() function assumed that the server returns a
> local path in href field, but RFC 4918 (14.7) demand of support full
> URI (e.g. "http://localhost:8080/repo.git").
>
> This resulted in push failure (e.g. git-http-push issues a PROPFIND
> request to "/repo.git/alhost:8080/repo.git/refs/" to the server).
>
> Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
> ---
> http-push.c | 25 +++++++++++++++++++------
> 1 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/http-push.c b/http-push.c
> index 7c6460919bf3eba10c46cede11ffdd9c53fd2dd2..a4b7d08663504a57008f66a39fffe293f62c1d08 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -87,6 +87,7 @@ static struct object_list *objects;
> struct repo
> {
> char *url;
> + char *path;
> int path_len;
> int has_info_refs;
> int can_update_info_refs;
> @@ -1424,9 +1425,19 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
> ls->userFunc(ls);
> }
> } else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
> - ls->dentry_name = xmalloc(strlen(ctx->cdata) -
> + char *path = ctx->cdata;
> + if (*ctx->cdata == 'h') {
> + path = strstr(path, "//");
I would make that a "://"
> + if (path) {
> + path = strchr(path+2, '/');
and s/2/3/, accordingly.
But I realize the existing code already does something like what your
are doing...
Mike
^ permalink raw reply
* Re: [PATCH] Documentation/diff-options.txt: unify options
From: jidanni @ 2008-12-29 7:03 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vvdt4aj0e.fsf@gitster.siamese.dyndns.org>
(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>
---
Documentation/diff-options.txt | 18 ++++--------------
1 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index c62b45c..b432d25 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -19,16 +19,12 @@ endif::git-format-patch[]
ifndef::git-format-patch[]
-p::
+-u::
Generate patch (see section on generating patches).
{git-diff? This is the default.}
endif::git-format-patch[]
--u::
- Synonym for "-p".
-
-U<n>::
- Shorthand for "--unified=<n>".
-
--unified=<n>::
Generate diffs with <n> lines of context instead of
the usual three. Implies "-p".
@@ -190,31 +186,25 @@ endif::git-format-patch[]
can name which subdirectory to make the output relative
to by giving a <path> as an argument.
+-a::
--text::
Treat all files as text.
--a::
- Shorthand for "--text".
-
--ignore-space-at-eol::
Ignore changes in whitespace at EOL.
+-b::
--ignore-space-change::
Ignore changes in amount of whitespace. This ignores whitespace
at line end, and considers all other sequences of one or
more whitespace characters to be equivalent.
--b::
- Shorthand for "--ignore-space-change".
-
+-w::
--ignore-all-space::
Ignore whitespace when comparing lines. This ignores
differences even if one line has whitespace where the other
line has none.
--w::
- Shorthand for "--ignore-all-space".
-
--exit-code::
Make the program exit with codes similar to diff(1).
That is, it exits with 1 if there were differences and
--
1.5.6.5
^ permalink raw reply related
* git-add --verbose should say when something is already indexed
From: jidanni @ 2008-12-29 6:46 UTC (permalink / raw)
To: git
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.
The git-add man page should mention how one can see all the files
added, perhaps by git-ls-files. If so mention in SEE ALSO too.
^ permalink raw reply
* Re: user manual question
From: Dilip M @ 2008-12-29 6:33 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrnglg90m.olt.sitaramc@sitaramc.homelinux.net>
On Mon, Dec 29, 2008 at 6:42 AM, <sitaramc@gmail.com> wrote:
> On 2008-12-29, Zorba <cr@altmore.co.uk> wrote:
>> Hi Sitaram!
>>
>> Thanks for clearing that one up.
>
> you're welcome; we've all done a bit of struggling I guess!
>
>> Also, I did wonder about HEAD and head. One can move, the other
>> doesn't! (well, acually it does - head moves "forward", as the tip
>> of the branch grows)
>
> Here's an extract from my notes/internal talks on this:
>
> === basic concepts * a branch is "an active line of
> development" * //master//: default branch in a project, by
> convention * //head//: tip of a branch * a repo can track
> many branches, but the working tree is associated with only one
> branch at a time * //HEAD//: tip of the branch associated with
> the working tree; this is where commits go ** except
> when it's "detached"
That's a nice,compact and effective note. Thanks for sharing :-)
Consider pushing the full notes to GITHUB...would be _useful_ for all of
us..(like me)...
-- dm
^ permalink raw reply
* some git-commands --help don't act like git commands --help
From: jidanni @ 2008-12-29 6:25 UTC (permalink / raw)
To: git
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
$ git --version
git version 1.5.6.5
on Debian sid.
^ permalink raw reply
* [PATCH] Documentation/git-config.txt: clarify order of option reading
From: jidanni @ 2008-12-29 6:13 UTC (permalink / raw)
To: git
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-config.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 19a8917..34041b1 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -176,6 +176,8 @@ $GIT_DIR/config::
$(prefix)/etc/gitconfig::
System-wide configuration file.
+Options found earlier in this sequence override those found later.
+
If no further options are given, all reading options will read all of these
files that are available. If the global or the system-wide configuration
file are not available they will be ignored. If the repository configuration
--
1.5.6.5
^ permalink raw reply related
* Re: many git sites homepages megabytes big
From: J.H. @ 2008-12-29 5:17 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87r63r374j.fsf@jidanni.org>
There are lots of reasons fore and against what your proposing, and
there is no good answer. Yes it sends a lot of data, but one could
argue - more data is better than less data.
- John 'Warthog9' Hawley
On Mon, 2008-12-29 at 13:03 +0800, jidanni@jidanni.org wrote:
> I notice the web interfaces to many git sites are very risky to just
> click on. E.g., just clicking http://repo.or.cz/ sends megabytes to
> the users browser. At least the homepage of such sites should be
> something lighter in weight.
> --
> 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
^ permalink raw reply
* many git sites homepages megabytes big
From: jidanni @ 2008-12-29 5:03 UTC (permalink / raw)
To: git
I notice the web interfaces to many git sites are very risky to just
click on. E.g., just clicking http://repo.or.cz/ sends megabytes to
the users browser. At least the homepage of such sites should be
something lighter in weight.
^ permalink raw reply
* [PATCH] http-push: support full URI in handle_remote_ls_ctx()
From: Kirill A. Korinskiy @ 2008-12-29 2:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kirill A. Korinskiy
In-Reply-To: <7vmyekag6p.fsf@gitster.siamese.dyndns.org>
The program calls remote_ls() to get list of files from the server
over HTTP; handle_remote_ls_ctx() is used to parse its response to
populate "struct remote_ls_ctx" that is returned from remote_ls().
The handle_remote_ls_ctx() function assumed that the server returns a
local path in href field, but RFC 4918 (14.7) demand of support full
URI (e.g. "http://localhost:8080/repo.git").
This resulted in push failure (e.g. git-http-push issues a PROPFIND
request to "/repo.git/alhost:8080/repo.git/refs/" to the server).
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
---
http-push.c | 25 +++++++++++++++++++------
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/http-push.c b/http-push.c
index 7c6460919bf3eba10c46cede11ffdd9c53fd2dd2..a4b7d08663504a57008f66a39fffe293f62c1d08 100644
--- a/http-push.c
+++ b/http-push.c
@@ -87,6 +87,7 @@ static struct object_list *objects;
struct repo
{
char *url;
+ char *path;
int path_len;
int has_info_refs;
int can_update_info_refs;
@@ -1424,9 +1425,19 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
ls->userFunc(ls);
}
} else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
- ls->dentry_name = xmalloc(strlen(ctx->cdata) -
+ char *path = ctx->cdata;
+ if (*ctx->cdata == 'h') {
+ path = strstr(path, "//");
+ if (path) {
+ path = strchr(path+2, '/');
+ }
+ }
+ if (path) {
+ path += remote->path_len;
+ }
+ ls->dentry_name = xmalloc(strlen(path) -
remote->path_len + 1);
- strcpy(ls->dentry_name, ctx->cdata + remote->path_len);
+ strcpy(ls->dentry_name, path + remote->path_len);
} else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
ls->dentry_flags |= IS_DIR;
}
@@ -2206,10 +2217,11 @@ int main(int argc, char **argv)
if (!remote->url) {
char *path = strstr(arg, "//");
remote->url = arg;
+ remote->path_len = strlen(arg);
if (path) {
- path = strchr(path+2, '/');
- if (path)
- remote->path_len = strlen(path);
+ remote->path = strchr(path+2, '/');
+ if (remote->path)
+ remote->path_len = strlen(remote->path);
}
continue;
}
@@ -2238,8 +2250,9 @@ int main(int argc, char **argv)
rewritten_url = xmalloc(strlen(remote->url)+2);
strcpy(rewritten_url, remote->url);
strcat(rewritten_url, "/");
+ remote->path = rewritten_url + (remote->path - remote->url);
+ remote->path_len++;
remote->url = rewritten_url;
- ++remote->path_len;
}
/* Verify DAV compliance/lock support */
--
1.5.6.5
^ permalink raw reply related
* Re: user manual question
From: Sitaram Chamarty @ 2008-12-29 1:12 UTC (permalink / raw)
To: git
In-Reply-To: <gj96pl$885$4@ger.gmane.org>
On 2008-12-29, Zorba <cr@altmore.co.uk> wrote:
> Hi Sitaram!
>
> Thanks for clearing that one up.
you're welcome; we've all done a bit of struggling I guess!
> Also, I did wonder about HEAD and head. One can move, the other doesn't!
> (well, acually it does - head moves "forward", as the tip of the branch
> grows)
Here's an extract from my notes/internal talks on this:
=== basic concepts
* a branch is "an active line of development"
* //master//: default branch in a project, by convention
* //head//: tip of a branch
* a repo can track many branches, but the working tree is associated with
only one branch at a time
* //HEAD//: tip of the branch associated with the working tree; this is
where commits go
** except when it's "detached"
> Thanks for your other post/reply too - I will be getting back to you on that
> one
Glad to be of help. I don't consider myself a guru, and am
constantly waiting for one of the real gurus to strike me
down with a thunderbolt for saying something stupid :-)
^ 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