* What's cooking in gitweb (20 Sep 2008)
From: Jakub Narebski @ 2008-09-20 23:38 UTC (permalink / raw)
To: git; +Cc: Giuseppe Bilotta, Lea Wiemann, J.H., Gustavo Sverzut Barbieri
This is short summary of not-applied (and not ready to be applied)
gitweb patches, in reverse chronological order, with most recent
entries on top (first). Patches which probably should be resend, now
that we are after 1.6.0 release
Junio, what about "[PATCH] avoid gitweb uninitialized value warning"
(http://thread.gmane.org/gmane.comp.version-control.git/95028)? This
is pure bugfix (well, warning fix, and failrly rare one, but warning
which goes to web server logs).
$gmane=thread.gmane.org/gmane.comp.version-control.git
1. "gitweb pathinfo improvements" by Giuseppe Bilotta
Message-ID: <1220435839-29360-1-git-send-email-giuseppe.bilotta@gmail.com>
http://$gmane/94779
Table of contents:
==================
* [PATCH 1/5] gitweb: action in path with use_pathinfo
* [PATCH 2/5] gitweb: use_pathinfo filenames start with /
* [PATCH 3/5] gitweb: parse parent..current syntax from pathinfo
* [PATCH 4/5] gitweb: use_pathinfo creates parent..current paths
* [PATCH 5/5] gitweb: remove PATH_INFO from $my_url and $my_uri
Need some refinement, especially with respect to _generating_
path_info URLs inside gitweb. Some patches (2 and 5) does not
need correction, and probably should be sent as separate series.
Author promised to resend series, if I remember correctly.
2. "[PATCH] gitweb: shortlog now also obeys $hash_parent" by Giuseppe Bilotta
Message-ID: <1218204731-9931-1-git-send-email-giuseppe.bilotta@gmail.com>
http://$gmane/91666
Very good idea, but for the following two caveats. The name
'$commit_hash' is a bit strange to mean also revision range; passing
"a..b" to parse_commits()... well, it is a good solution, but for me it
feels a bit hacky. But this is not something serious.
More importnat fact is that I'd very much like for _all_ log-like views
(perhaps with exception of feeds: Atom and RSS) to implement this
feature. This could be done by either doing it all in the same commit,
doing commit series changing 'shortlog', 'log' and 'history' separately,
or what I would prefer actually, to refactor generation of log-like views
to use single worker/engine subroutine.
3. "[PATCH 1/1] Add "git" link to the end of project line on the
project_list page." by John 'Warthog9' Hawley
Message-ID: <1217815217-11329-2-git-send-email-warthog19@eaglescrag.net>
http://$gmane/91305
See also: http://$gmane/90778
As it was said in the commit message (which should be line-wrapped by
the way) it makes the assumption that each repository is available from
unique location. Both per-repo cloneurl and gitweb.url, and per
instllation @git_base_url_list allow for multiple repository URLs.
The problem of course is _which_ of those to choose for the targer of
'git' links on projects list page. And I don't think adding yet another
prefix to generate $project URL is a good dolution; better to simply
use first of URLs, and mention it both in comments in gitweb, and in
gitweb/README. Perhaps simply use first entry in @git_base_url_list.
Commit message could be improved too.
3. "Re: [PATCH 0/3] Git::Repo API and gitweb caching" by Lea Wiemann
Message-ID: <48A9CEC0.2020100@gmail.com>
http://$gmane/92726
Demo: http://odin3.kernel.org/git-lewiemann/
Result of "gitweb caching" Google Summer of Code 2008 project.
This is second resend of gitweb patch; the patches adding Mechanize
test of gitweb output, and Git::Repo api had more revisions (reviews)
on git mailing list.
Quote (perhaps it is simply not possible...):
> I unfortunately didn't end up being able to split up the third patch
> (use Perl API in Gitweb, and add caching layer), since the two changes
> are too intricately linked to be properly separated (I actually tried
> splitting it two times, two different ways, and it just didn't work).
Those patches, in particular the gitweb one, needs some review I think,
as they affect quite a bit of code.
4. "[PATCH 0/2] gitweb use sections" by Gustavo Sverzut Barbieri
Message-ID: <1217298868-16513-1-git-send-email-barbieri@profusion.mobi>
http://$gmane/90553
Demo: http://staff.get-e.org/
Patches overview:
==================
* [PATCH 1/2] gitweb: sort projects by path.
* [PATCH 2/2] gitweb: add section support to gitweb project listing.
What I'd like to have for first patch is at least estimating
performance hit (if there is any), and an example where original old
code sorts paths wrongly.
Nevetheless I think it is a good idea to have. I didn't reviewed the
code though...
--
Jakub Narebski
Poland
^ permalink raw reply
* [JGIT PATCH] Add test for OpenSshConfig separator parsing
From: Jonas Fonseca @ 2008-09-20 22:33 UTC (permalink / raw)
To: Gilion Goudsmit; +Cc: git, spearce
In-Reply-To: <20080920214808.GA7426@diku.dk>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../spearce/jgit/transport/OpenSshConfigTest.java | 24 ++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
I sent the previous patch a bit too early. This one has the assertions.
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
index 959b6b7..8c1133d 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
@@ -81,6 +81,30 @@ public void testNoConfig() {
assertNull(h.getIdentityFile());
}
+ public void testSeparatorParsing() throws Exception {
+ config("Host\tfirst\n" +
+ "\tHostName\tfirst.tld\n" +
+ "\n" +
+ "Host second\n" +
+ " HostName\tsecond.tld\n" +
+ "Host=third\n" +
+ "HostName=third.tld\n\n\n" +
+ "\t Host = fourth\n\n\n" +
+ " \t HostName\t=fourth.tld\n" +
+ "Host\t = last\n" +
+ "HostName \t last.tld");
+ assertNotNull(osc.lookup("first"));
+ assertEquals("first.tld", osc.lookup("first").getHostName());
+ assertNotNull(osc.lookup("second"));
+ assertEquals("second.tld", osc.lookup("second").getHostName());
+ assertNotNull(osc.lookup("third"));
+ assertEquals("third.tld", osc.lookup("third").getHostName());
+ assertNotNull(osc.lookup("fourth"));
+ assertEquals("fourth.tld", osc.lookup("fourth").getHostName());
+ assertNotNull(osc.lookup("last"));
+ assertEquals("last.tld", osc.lookup("last").getHostName());
+ }
+
public void testAlias_DoesNotMatch() throws Exception {
config("Host orcz\n" + "\tHostName repo.or.cz\n");
final Host h = osc.lookup("repo.or.cz");
--
1.6.0.2.444.gf2494
--
Jonas Fonseca
^ permalink raw reply related
* Re: [JGIT PATCH] Fixed a bug that caused tabs in ~/.ssh/config to break parsing
From: Jonas Fonseca @ 2008-09-20 22:29 UTC (permalink / raw)
To: Gilion Goudsmit; +Cc: git, spearce
In-Reply-To: <12219428213749-git-send-email-ggoudsmit@shebang.nl>
Gilion Goudsmit <ggoudsmit@shebang.nl> wrote Sat, Sep 20, 2008:
> Having only tab-characters separating a key and value in the
> users ~/.ssh/config would cause the config-parser to fail with
> a "String index out of range: -1" exception. Also simplified
> the line parsing code my using a two argument split.
>
> Signed-off-by: Gilion Goudsmit <ggoudsmit@shebang.nl>
> ---
With the following on top, the code will also pass the updated test for:
Host = somewhere
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
index 5bfcf5f..a9c6c12 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
@@ -167,7 +167,7 @@ public Host lookup(final String hostName) {
if (line.length() == 0 || line.startsWith("#"))
continue;
- final String[] parts = line.split("[ \t=]", 2);
+ final String[] parts = line.split("[ \t]*[= \t]", 2);
final String keyword = parts[0].trim();
final String argValue = parts[1].trim();
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Junio C Hamano @ 2008-09-20 22:29 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <loom.20080920T200157-713@post.gmane.org>
Brandon Casey <drafnel@gmail.com> writes:
> Junio C Hamano <gitster <at> pobox.com> writes:
>
>> Here is [1/2] to be applied on top of 45d9414 (diff.*.xfuncname which uses
>> "extended" regex's for hunk header selection, 2008-09-18).
>>
>> Testing appreciated.
>
>> + { "bibtex", "(@[a-zA-Z]{1,}[ \t]*\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
>> + REG_EXTENDED },
>> + { "tex",
>> + "^(\\\\((sub)*section|chapter|part)\\*{0,1}\{.*)$",
>
> I think you need double backslash '\\' before '{' in the two places in these
> patterns where you only have a single backslash.
Thanks. Any other nits?
^ permalink raw reply
* Re: Problems with git over http
From: Sean Davis @ 2008-09-20 22:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3wsh6lck1.fsf@localhost.localdomain>
On Sat, Sep 20, 2008 at 5:42 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Sean Davis" <sdavis2@mail.nih.gov> writes:
>
>> I am new to git and trying to set up a remote repository over http. I
>> have configured apache2 and the bare, empty repository. Using curl, I
>> can get the file HEAD without a password (seems .netrc is correct?).
>> However, when I try to push to the repository, I get the following:
>>
>> sdavis@lestrade:/tmp/testing> git push
>> http://sdavis@watson.nci.nih.gov/git/sean_git.git/ master
>> fatal: exec http-push failed.
>> error: failed to push some refs to
>> 'http://sdavis@watson.nci.nih.gov/git/sean_git.git/'
>
> Errr... to _push_ via https you have to enable WebDAV.
> See Documentation/howto/setup-git-server-over-http.txt
WebDAV is enabled and authentication is working.
Sean
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Junio C Hamano @ 2008-09-20 22:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vvdwq1moh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> By the way: what was index version 1?
>
> It was the format used before ccc4feb (Convert the index file
> reading/writing to use network byte order., 2005-04-15)
Sorry, I dug that wrong. The right one is:
ca9be05 (Make the sha1 of the index file go at the very end of the file., 2005-04-20)
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Junio C Hamano @ 2008-09-20 22:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <m3skrulbrd.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way: what was index version 1?
It was the format used before ccc4feb (Convert the index file
reading/writing to use network byte order., 2005-04-15)
^ permalink raw reply
* Re: [JGIT PATCH] Fixed a bug that caused tabs in ~/.ssh/config to break parsing
From: Robin Rosenberg @ 2008-09-20 22:18 UTC (permalink / raw)
To: Gilion Goudsmit; +Cc: git, spearce
In-Reply-To: <12219428213749-git-send-email-ggoudsmit@shebang.nl>
lördagen den 20 september 2008 22.33.41 skrev Gilion Goudsmit:
> Having only tab-characters separating a key and value in the
> users ~/.ssh/config would cause the config-parser to fail with
> a "String index out of range: -1" exception. Also simplified
> the line parsing code my using a two argument split.
Thank you and welcome to the club!
-- robin
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Junio C Hamano @ 2008-09-20 22:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0809201248w2850a243n50596dda3121f2c@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
> ...
>> >> BTW I think that the same rules are used in gitattributes, aren't
>> >> they?
>> >
>> > They have different implementations. Though the rules may be the same.
>>
>> Were you able to reuse either one?
>
> No. .gitignore is tied to read_directory() while .gitattributes has
> attributes attached. So I rolled out another one for index.
I am sorry, but that sounds like a rather lame excuse. It certainly is
possible to introduce an "ignored" attribute and have .gitattributes file
specify that, instead of having an entry in .gitignore file, if you teach
read_directory() to pay attention to the attributes mechanism. If we had
from day one that a more generic gitattributes mechanism, I would imagine
we wouldn't even had a separate .gitignore codepath but used the attribute
mechanism throughout the system.
Now I do not think we are ever going to deprecate gitignore and move
everybody to "ignored" attributes, because such a transition would not buy
the end users anything, but it technically is possible and would have been
the right thing to do, if we were building the system from scratch. We
still could add it as an optional feature (i.e. if a path has the
attribute that says "ignored" or "not ignored", then that determines the
fate of the path, otherwise we look at gitignore).
I wouldn't be surprised if an alternative implementation of your code to
assign "sparseness" to each path internally used "to-be-checked-out"
attribute, and used that attribute to control how ls-files filters its
output.
A better excuse might have been that "I am not reading these patterns from
anywhere but command line", but that got me thinking further.
How would that --narrow-match that is not stored anywhere on the
filesystem but used only for filtering the output be any more useful than
a grep that filters ls-files output in practice?
I would imagine it would be much more useful if .git/info/attributes can
specify "checkout" attribute that is defined like this:
`checkout`
^^^^^^^^^^
This attribute controls if the path can be left not checked-out to the
working tree.
Unset::
Unsetting the `checkout` marks the path not to be checked out.
Unspecified::
A path which does not have any `checkout` attribute specified is
handled in no special way.
Any value set to `checkout` is ignored, and git acts as if the
attribute is left unspecified.
Then whenever a new path enters the index, you _could_ check with the
attribute mechanism to set the CE_NOCHECKOUT flag. Just like an already
tracked path is not ignored even if it matches .gitignore pattern, a path
without CE_NOCHECKOUT that is in the index is checked out even if it has
checkout attribute Unset.
Hmm?
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Jakub Narebski @ 2008-09-20 21:59 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221904913-25887-2-git-send-email-pclouds@gmail.com>
Comments below are just nitpicking. Feel free to diregard them...
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> The on-disk format of index only saves 16 bit flags, nearly all have
> been used. The last bit (CE_EXTENDED) is used to for future extension.
>
> This patch extends index entry format to save more flags in future.
> The new entry format will be used when CE_EXTENDED bit is 1.
>
> Because older implementation may not understand CE_EXTENDED bit and
> misread the new format, if there is any extended entry in index, index
> header version will turn 3, which makes it incompatible for older git.
> If there is none, header version will return to 2 again.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
It would be nice if at least this part of series got accepted...
> ---
> cache.h | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
> read-cache.c | 51 +++++++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 95 insertions(+), 14 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index f4b8ddf..77b6eb3 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -109,6 +109,26 @@ struct ondisk_cache_entry {
> char name[FLEX_ARRAY]; /* more */
> };
>
> +/*
> + * This struct is used when CE_EXTENDED bit is 1
> + * The struct must match ondisk_cache_entry exactly from
> + * ctime till flags
> + */
Errr... "must match"? Wouldn't "does match" be better?
This type is defined below, not is to be defined...
> +struct ondisk_cache_entry_extended {
> + struct cache_time ctime;
> + struct cache_time mtime;
> + unsigned int dev;
> + unsigned int ino;
> + unsigned int mode;
> + unsigned int uid;
> + unsigned int gid;
> + unsigned int size;
> + unsigned char sha1[20];
> + unsigned short flags;
> + unsigned short flags2;
flags and flags2? Why not flags1 and flags2, or flags[2], or flags and
flags_ext/flags_extended?
Just nitpicking.
> + char name[FLEX_ARRAY]; /* more */
> +};
> +
> struct cache_entry {
> unsigned int ce_ctime;
> unsigned int ce_mtime;
> @@ -130,7 +150,15 @@ struct cache_entry {
> #define CE_VALID (0x8000)
> #define CE_STAGESHIFT 12
>
> -/* In-memory only */
> +/*
> + * Range 0xFFFF0000 in ce_flags is divided into
> + * two parts: in-memory flags and on-disk ones.
> + * Flags in CE_EXTENDED_FLAGS will get saved on-disk
Semicolon at the end of below text to separate, I think. Or at least
comma.
> + * if you want to save a new flag, add it in
> + * CE_EXTENDED_FLAGS
Nice comment.
> + *
> + * In-memory only flags
> + */
> #define CE_UPDATE (0x10000)
> #define CE_REMOVE (0x20000)
> #define CE_UPTODATE (0x40000)
> @@ -140,6 +168,24 @@ struct cache_entry {
> #define CE_UNHASHED (0x200000)
>
> /*
> + * Extended on-disk flags
> + */
> +/* CE_EXTENDED2 is for future extension */
> +#define CE_EXTENDED2 0x80000000
Perhaps CE_RESERVED then?
> +
> +#define CE_EXTENDED_FLAGS (0)
> +
> +/*
> + * Safeguard to avoid saving wrong flags:
> + * - CE_EXTENDED2 won't get saved until its semantic is known
> + * - Bits in 0x0000FFFF have been saved in ce_flags already
> + * - Bits in 0x003F0000 are currently in-memory flags
> + */
> +#if CE_EXTENDED_FLAGS & 0x80CFFFFF
> +#error "CE_EXTENDED_FLAGS out of range"
> +#endif
I don't quite understand the above fragment (especially with the fact
that CE_EXTENDED_FLAGS is defined as (0))...
> diff --git a/read-cache.c b/read-cache.c
> index c5a8659..667c36b 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1096,7 +1096,7 @@ static int verify_hdr(struct cache_header *hdr, unsigned long size)
>
> if (hdr->hdr_signature != htonl(CACHE_SIGNATURE))
> return error("bad signature");
> - if (hdr->hdr_version != htonl(2))
> + if (hdr->hdr_version != htonl(2) && hdr->hdr_version != htonl(3))
> return error("bad index version");
By the way: what was index version 1?
[...]
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [JGIT PATCH] Add test for OpenSshConfig separator parsing
From: Jonas Fonseca @ 2008-09-20 21:48 UTC (permalink / raw)
To: Gilion Goudsmit; +Cc: git, spearce
In-Reply-To: <12219428213749-git-send-email-ggoudsmit@shebang.nl>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../spearce/jgit/transport/OpenSshConfigTest.java | 22 ++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
Gilion Goudsmit <ggoudsmit@shebang.nl> wrote Sat, Sep 20, 2008:
> Having only tab-characters separating a key and value in the
> users ~/.ssh/config would cause the config-parser to fail with
> a "String index out of range: -1" exception. Also simplified
> the line parsing code my using a two argument split.
>
> Signed-off-by: Gilion Goudsmit <ggoudsmit@shebang.nl>
A small test for this bug and FWIW:
Tested-by: Jonas Fonseca <fonseca@diku.dk>
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
index 959b6b7..927c350 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
@@ -81,6 +81,28 @@ public void testNoConfig() {
assertNull(h.getIdentityFile());
}
+ public void testSeparatorParsing() throws Exception {
+ config("Host\tfirst\n" +
+ "\tHostName\tfirst.tld\n" +
+ "\n" +
+ "Host second\n" +
+ " HostName\tsecond.tld\n" +
+ "Host=third\n" +
+ "HostName=third.tld\n\n\n" +
+ "\t Host = fourth\n\n\n" +
+ " \t HostName\t=fourth.tld\n" +
+ "Host\t = last\n" +
+ "HostName \t last.tld");
+ assertNotNull(osc.lookup("first"));
+ assertEquals("first.tld", osc.lookup("first").getHostName());
+ assertNotNull(osc.lookup("second"));
+ assertEquals("second.tld", osc.lookup("second").getHostName());
+ assertNotNull(osc.lookup("third"));
+ assertEquals("third.tld", osc.lookup("third").getHostName());
+ assertNotNull(osc.lookup("last"));
+ assertEquals("last.tld", osc.lookup("last").getHostName());
+ }
+
public void testAlias_DoesNotMatch() throws Exception {
config("Host orcz\n" + "\tHostName repo.or.cz\n");
final Host h = osc.lookup("repo.or.cz");
--
1.6.0.1.451.gc8d31
--
Jonas Fonseca
^ permalink raw reply related
* Re: Problems with git over http
From: Jakub Narebski @ 2008-09-20 21:42 UTC (permalink / raw)
To: Sean Davis; +Cc: git
In-Reply-To: <264855a00809201013h6003abbfr9bbdd20c92e9201d@mail.gmail.com>
"Sean Davis" <sdavis2@mail.nih.gov> writes:
> I am new to git and trying to set up a remote repository over http. I
> have configured apache2 and the bare, empty repository. Using curl, I
> can get the file HEAD without a password (seems .netrc is correct?).
> However, when I try to push to the repository, I get the following:
>
> sdavis@lestrade:/tmp/testing> git push
> http://sdavis@watson.nci.nih.gov/git/sean_git.git/ master
> fatal: exec http-push failed.
> error: failed to push some refs to
> 'http://sdavis@watson.nci.nih.gov/git/sean_git.git/'
Errr... to _push_ via https you have to enable WebDAV.
See Documentation/howto/setup-git-server-over-http.txt
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Brandon Casey @ 2008-09-20 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vy71n482x.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> Here is [1/2] to be applied on top of 45d9414 (diff.*.xfuncname which uses
> "extended" regex's for hunk header selection, 2008-09-18).
>
> Testing appreciated.
> + { "bibtex", "(@[a-zA-Z]{1,}[ \t]*\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
> + REG_EXTENDED },
> + { "tex",
> + "^(\\\\((sub)*section|chapter|part)\\*{0,1}\{.*)$",
I think you need double backslash '\\' before '{' in the two places in these
patterns where you only have a single backslash.
-brandon
^ permalink raw reply
* [JGIT PATCH] Fixed a bug that caused tabs in ~/.ssh/config to break parsing
From: Gilion Goudsmit @ 2008-09-20 20:33 UTC (permalink / raw)
To: git; +Cc: spearce, Gilion Goudsmit
Having only tab-characters separating a key and value in the
users ~/.ssh/config would cause the config-parser to fail with
a "String index out of range: -1" exception. Also simplified
the line parsing code my using a two argument split.
Signed-off-by: Gilion Goudsmit <ggoudsmit@shebang.nl>
---
.../org/spearce/jgit/transport/OpenSshConfig.java | 14 +++-----------
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
index df38e18..5bfcf5f 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
@@ -167,17 +167,9 @@ while ((line = br.readLine()) != null) {
if (line.length() == 0 || line.startsWith("#"))
continue;
- final int sp = line.indexOf(' ');
- final int eq = line.indexOf('=');
- final int splitAt;
- if (sp >= 0 && eq >= 0)
- splitAt = Math.min(sp, eq);
- else if (sp < 0)
- splitAt = eq;
- else
- splitAt = sp;
- final String keyword = line.substring(0, splitAt).trim();
- final String argValue = line.substring(splitAt + 1).trim();
+ final String[] parts = line.split("[ \t=]", 2);
+ final String keyword = parts[0].trim();
+ final String argValue = parts[1].trim();
if ("Host".equalsIgnoreCase(keyword)) {
current.clear();
--
1.5.3.8
^ permalink raw reply related
* Re: Problems with git over http
From: Sean Davis @ 2008-09-20 20:40 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20080920184257.GD18932@strlen.de>
On Sat, Sep 20, 2008 at 2:42 PM, Uwe Kleine-König <ukleinek@strlen.de> wrote:
> Hello Sean,
>
> On Sat, Sep 20, 2008 at 01:13:53PM -0400, Sean Davis wrote:
>> I am new to git and trying to set up a remote repository over http. I
>> have configured apache2 and the bare, empty repository. Using curl, I
>> can get the file HEAD without a password (seems .netrc is correct?).
>> However, when I try to push to the repository, I get the following:
>>
>> sdavis@lestrade:/tmp/testing> git push
>> http://sdavis@watson.nci.nih.gov/git/sean_git.git/ master
>> fatal: exec http-push failed.
>> error: failed to push some refs to
>> 'http://sdavis@watson.nci.nih.gov/git/sean_git.git/'
>>
>> What can I do to try to debug this, as the error message isn't helping
>> me to sort out what is wrong. The client and server are both running
>> git-1.5.x (although the minor versions are a bit different). Any
>> suggestions?
> Try cloning first. And check the error log of apache. I don't know how
> pushing over http works, but maybe you installed git into /usr/local and
> /usr/local/bin is not in the PATH for the apache user?
Thanks, Uwe. Good idea. On the client:
orf-01569049:/tmp sdavis$ git clone
http://sdavis@watson.nci.nih.gov/git/sean_git.git/
Initialized empty Git repository in /tmp/sean_git/.git/
cat: /tmp/sean_git/.git/refs/remotes/origin/master: No such file or directory
/usr/local/bin/git-clone: line 4: cd:
/tmp/sean_git/.git/refs/remotes/origin: No such file or directory
fatal: Not a valid object name HEAD
Nothing in the error_log on apache. Why would git be looking for a
remotes origin since I am cloning from a remote source?
Sean
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-20 19:48 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <200809202001.28383.jnareb@gmail.com>
On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
> > "--reset-path", I think, is a better name though. It would express the
> > relation compared to --add-path and --remove-path.
>
>
> I don't like very much '--reset-path' option name, because it is not
> about 'reset' or 'resetting', but about limiting checkout to specified
> paths. Unfortunately --include / --exclude looks like are for ignoring
> files, not marking files with "no-checkout" bit etc.
>
> But I am not native English speaker.
>
> Further proposals: --only ("git checkout --only <pattern>") with
> --checkout-only as counterpart in git-clone; --limit-to, --sparse.
>
>
> GNU tar uses --exclude and --exclude-file (with --no-recurse,
> --no-wildcards, --no-wildcards-match-slash). wget uses --accept
> and --reject for filename patterns, and --include / --exclude for
> directories. Neither looks right for sparse checkout in Git.
I think --exclude and --include are quite good. With Junio's
suggestion "foo-X", how about this?
git clone --sparse-checkout=<patterns> [1]
git checkout --set-sparse=<patterns>
git checkout --include-sparse=<patterns>
git checkout --exclude-sparse=<patterns> [2]
[1] "checkout" is there to avoid being interpreted as "sparse clone"
[2] --narrow-sparse IMO does not tell how the following patterns are
used (is it the set that will be excluded or the target set?),
"exclude" does better.
> >> BTW I think that the same rules are used in gitattributes, aren't
> >> they?
> >
> > They have different implementations. Though the rules may be the same.
>
>
> Were you able to reuse either one?
No. .gitignore is tied to read_directory() while .gitattributes has
attributes attached. So I rolled out another one for index.
--
Duy
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Junio C Hamano @ 2008-09-20 18:52 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, git
In-Reply-To: <fcaeb9bf0809201033o1e9298a8ob135c68228b77218@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 9/20/08, Jakub Narebski <jnareb@gmail.com> wrote:
>> > - "git clone --path" => "git clone --narrow-path"
>> > - "git checkout --path" => "git checkout --reset-path"
>>
>> I am not sure about that change, especially the fact that git-clone
>> and git-checkout use differently named options, because those options
>> affect clone only as they affect the checkout part of the clone. One
>> would think that git-clone = git-init + git-remote add + git-fetch +
>> git-checkout, and that git-clone would simply pass sparse checkout
>> flags to git-checkout.
>>
>
> Johannes sixt said --path was too generic so I changed the name. Hmm..
> I did not think the same option name for git-checkout and git-clone
> was important, rather worry about people may misunderstand that it is
> "narrow clone" (do not fetch objects outside given paths for all
> history). Maybe "git clone --narrow-checkout" would be better.
Be it narrow or sparse, I would agree this round is better than too
generic sounding --path. Whatever that "limited set of paths that are to
appear in the working tree" is called, it is a good idea to name options
to clarify what effect each option causes on that concept X. So perhaps:
--reset-X resets the checkout set
--widen-X widens the checkout set
--narrow-X narrows the checkout set
is a good set of options to give "checkout".
You could argue that using "--reset-X" would be more consistent for clone,
but I think the "--reset-" part is redundant, because clone cannot
possibly say "add these" or "subtract those". I.e. it can only establish
the initial set (which is "--reset-X"). Which leads me to suggest that it
would not be such a good idea to use the same option name for clone and
checkout
With s/X/sparse/, above would give a set of options that does not sound
too bad, I think. It certainly is better than s/X/narrow/ which would
have a strong "Huh?" factor in "--narrow-narrow" one ;-)
^ permalink raw reply
* Re: Problems with git over http
From: Uwe Kleine-König @ 2008-09-20 18:42 UTC (permalink / raw)
To: Sean Davis; +Cc: git
In-Reply-To: <264855a00809201013h6003abbfr9bbdd20c92e9201d@mail.gmail.com>
Hello Sean,
On Sat, Sep 20, 2008 at 01:13:53PM -0400, Sean Davis wrote:
> I am new to git and trying to set up a remote repository over http. I
> have configured apache2 and the bare, empty repository. Using curl, I
> can get the file HEAD without a password (seems .netrc is correct?).
> However, when I try to push to the repository, I get the following:
>
> sdavis@lestrade:/tmp/testing> git push
> http://sdavis@watson.nci.nih.gov/git/sean_git.git/ master
> fatal: exec http-push failed.
> error: failed to push some refs to
> 'http://sdavis@watson.nci.nih.gov/git/sean_git.git/'
>
> What can I do to try to debug this, as the error message isn't helping
> me to sort out what is wrong. The client and server are both running
> git-1.5.x (although the minor versions are a bit different). Any
> suggestions?
Try cloning first. And check the error log of apache. I don't know how
pushing over http works, but maybe you installed git into /usr/local and
/usr/local/bin is not in the PATH for the apache user?
Best regards
Uwe
^ permalink raw reply
* Re: Encoding problems with format-patch [Was: [PATCH v2 00/14] Sparse checkout]
From: Uwe Kleine-König @ 2008-09-20 18:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <200809202001.28383.jnareb@gmail.com>
Hello,
On Sat, Sep 20, 2008 at 08:01:27PM +0200, Jakub Narebski wrote:
> On Sat, 20 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> >>> Nguyễn Thái NgỠc Duy (14):
> >>
> >> Errr... what happened here? For me it doesn't look like correct UTF-8
> >> encoding, but perhaps that it is just my news client (Gnus)...
> >
> > The cover letter lacks MIME-Version and Content-Type, hmm..
>
> Bug in git-format-patch? IIRC --cover-letter was added quite late, and
> is quite a new option; some bugs might have been not ironed out yet.
I hit this kind of problem already, too.
My problem was that format-patch only adds MIME-Version and
Content-Type headers if the commit has non-ascii characters. If I add a
S-o-b only after the format-patch step I easily forget to add the needed
headers. IMHO the right fix is to let send-email stop if there is no
encoding related header in the mail but non-ascii characters.
Best regards
Uwe
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Jakub Narebski @ 2008-09-20 18:01 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0809201033o1e9298a8ob135c68228b77218@mail.gmail.com>
On Sat, 20 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/20/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> - "git clone --path" => "git clone --narrow-path"
>>> - "git checkout --path" => "git checkout --reset-path"
>>
>>
>> I am not sure about that change, especially the fact that git-clone
>> and git-checkout use differently named options, because those options
>> affect clone only as they affect the checkout part of the clone. One
>> would think that git-clone = git-init + git-remote add + git-fetch +
>> git-checkout, and that git-clone would simply pass sparse checkout
>> flags to git-checkout.
>>
>
> Johannes sixt said --path was too generic so I changed the name. Hmm..
> I did not think the same option name for git-checkout and git-clone
> was important, rather worry about people may misunderstand that it is
> "narrow clone" (do not fetch objects outside given paths for all
> history). Maybe "git clone --narrow-checkout" would be better.
True, I didn't thought that git-clone can have option with explicit
'checkout' in a name, for example --checkout-paths, or --checkout-only,
or --narrow-checkout (although for me this one doesn't look as it
accepts arguments, at least on first glance), or --sparse-checkout
(the same).
> "--reset-path", I think, is a better name though. It would express the
> relation compared to --add-path and --remove-path.
I don't like very much '--reset-path' option name, because it is not
about 'reset' or 'resetting', but about limiting checkout to specified
paths. Unfortunately --include / --exclude looks like are for ignoring
files, not marking files with "no-checkout" bit etc.
But I am not native English speaker.
Further proposals: --only ("git checkout --only <pattern>") with
--checkout-only as counterpart in git-clone; --limit-to, --sparse.
GNU tar uses --exclude and --exclude-file (with --no-recurse,
--no-wildcards, --no-wildcards-match-slash). wget uses --accept
and --reject for filename patterns, and --include / --exclude for
directories. Neither looks right for sparse checkout in Git.
>>> - New narrow spec (or "sparse patterns" from now) resembles
>>> .gitignore patterns
>>
>>
>> You mean here that rules for patterns to select which parts of tree
>> mark as "no-checkout" and/or checkout/leave in checkout are the same
>> (or nearly the same) as rules for ignoring files, isn't it?
>
> Yes, almost the same, exceptions include "./" support (this may have
> worked already for .gitignore, I dunno) and backslash escape for
> colons.
'./', or rather '/' support works for gitignore: this is the only way
to have pattern which matches only files in given directory,
nonrecursively. For example last line in last example on gitignore(5)
man page.
>> BTW I think that the same rules are used in gitattributes, aren't
>> they?
>
> They have different implementations. Though the rules may be the same.
Were you able to reuse either one?
>>> Nguyễn Thái NgỠc Duy (14):
>>
>> Errr... what happened here? For me it doesn't look like correct UTF-8
>> encoding, but perhaps that it is just my news client (Gnus)...
>
> The cover letter lacks MIME-Version and Content-Type, hmm..
Bug in git-format-patch? IIRC --cover-letter was added quite late, and
is quite a new option; some bugs might have been not ironed out yet.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-20 17:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m31vzen4v5.fsf@localhost.localdomain>
On 9/20/08, Jakub Narebski <jnareb@gmail.com> wrote:
> > - "git clone --path" => "git clone --narrow-path"
> > - "git checkout --path" => "git checkout --reset-path"
>
>
> I am not sure about that change, especially the fact that git-clone
> and git-checkout use differently named options, because those options
> affect clone only as they affect the checkout part of the clone. One
> would think that git-clone = git-init + git-remote add + git-fetch +
> git-checkout, and that git-clone would simply pass sparse checkout
> flags to git-checkout.
>
Johannes sixt said --path was too generic so I changed the name. Hmm..
I did not think the same option name for git-checkout and git-clone
was important, rather worry about people may misunderstand that it is
"narrow clone" (do not fetch objects outside given paths for all
history). Maybe "git clone --narrow-checkout" would be better.
"--reset-path", I think, is a better name though. It would express the
relation compared to --add-path and --remove-path.
> > - New narrow spec (or "sparse patterns" from now) resembles
> > .gitignore patterns
>
>
> You mean here that rules for patterns to select which parts of tree
> mark as "no-checkout" and/or checkout/leave in checkout are the same
> (or nearly the same) as rules for ignoring files, isn't it?
Yes, almost the same, exceptions include "./" support (this may have
worked already for .gitignore, I dunno) and backslash escape for
colons.
> BTW I think that the same rules are used in gitattributes, aren't
> they?
They have different implementations. Though the rules may be the same.
> > Nguyễn Thái NgỠc Duy (14):
>
> Errr... what happened here? For me it doesn't look like correct UTF-8
> encoding, but perhaps that it is just my news client (Gnus)...
The cover letter lacks MIME-Version and Content-Type, hmm..
--
Duy
^ permalink raw reply
* Problems with git over http
From: Sean Davis @ 2008-09-20 17:13 UTC (permalink / raw)
To: git
I am new to git and trying to set up a remote repository over http. I
have configured apache2 and the bare, empty repository. Using curl, I
can get the file HEAD without a password (seems .netrc is correct?).
However, when I try to push to the repository, I get the following:
sdavis@lestrade:/tmp/testing> git push
http://sdavis@watson.nci.nih.gov/git/sean_git.git/ master
fatal: exec http-push failed.
error: failed to push some refs to
'http://sdavis@watson.nci.nih.gov/git/sean_git.git/'
What can I do to try to debug this, as the error message isn't helping
me to sort out what is wrong. The client and server are both running
git-1.5.x (although the minor versions are a bit different). Any
suggestions?
Thanks,
Sean
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Jakub Narebski @ 2008-09-20 16:45 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221904913-25887-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Main changes from the last round are:
> - The name is now "sparse checkout"
I guess that 'sparse checkout' would be more recognizable than 'narrow
checkout'.
> - "git clone --path" => "git clone --narrow-path"
> - "git checkout --path" => "git checkout --reset-path"
I am not sure about that change, especially the fact that git-clone
and git-checkout use differently named options, because those options
affect clone only as they affect the checkout part of the clone. One
would think that git-clone = git-init + git-remote add + git-fetch +
git-checkout, and that git-clone would simply pass sparse checkout
flags to git-checkout.
> - New narrow spec (or "sparse patterns" from now) resembles
> .gitignore patterns
You mean here that rules for patterns to select which parts of tree
mark as "no-checkout" and/or checkout/leave in checkout are the same
(or nearly the same) as rules for ignoring files, isn't it?
BTW I think that the same rules are used in gitattributes, aren't
they?
> - "git ls-files" now supports more fine-grained listing. It can now
> list checkout files, no-checkout files or orphaned (previously
> "overlay") files. --overlay is gone
Good. I hope (I haven't read the post yet) that you extended '-t' and
'-v' output (or added similar option for no-checkout bit specially)
for git-ls-files.
> - "git status" shows orphaned entries and remedies
Good. I guess (I haven't read the post yet) that git-status displays,
or can be asked to display "orphaned"/"unwanted" files (files which
exists in working repository, but are marked with "no-checkout" bit),
and perhaps simply the fact that we commit/are in narrow checkout
(there is at least one file with "no-checkout" bit set in the index).
> For code changes, significant changes are:
> [10/14] ls-files: support "sparse patterns", used to form sparse
> checkout areas
Hmmm...
> I hope I have addressed all the issues. If I miss anything, please
> speak up.
By the way, pleas do not worry if there would be new round of
comments. Sparse checkout is a new feature, and I think it is quite
important to get UI (interface) part, like names of configuration
variables and options first, or at least correct them before sparse
checkout hits released version. It is harder IMVHO to change user
interface (this applies also to non-local repository data) due to
concerns for backwards compatibility; it is I think easier to correct
code.
> Nguyá»…n Thái Ngá»c Duy (14):
Errr... what happened here? For me it doesn't look like correct UTF-8
encoding, but perhaps that it is just my news client (Gnus)...
P.S. Thanks for numbering this series.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-20 12:07 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0809200348h1170e8cm302e92043da8995d@mail.gmail.com>
On 9/20/08, Santi Béjar <santi@agolina.net> wrote:
> On Sat, Sep 20, 2008 at 12:01 PM, Nguyễn Thái Ngọc Duy
> <pclouds@gmail.com> wrote:
> >
> > Nguyễn Thái Ngọc Duy (14):
> > Extend index to save more flags
> > Introduce CE_NO_CHECKOUT bit
> > ls-files: add options to support sparse checkout
> > update-index: refactor mark_valid() in preparation for new options
> > update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
> > ls-files: Add tests for --sparse and friends
> > Prevent diff machinery from examining worktree outside sparse checkout
> > checkout_entry(): CE_NO_CHECKOUT on checked out entries.
> > grep: skip files outside sparse checkout area
> > ls-files: support "sparse patterns", used to form sparse checkout areas
> > unpack_trees(): add support for sparse checkout
> > clone: support sparse checkout with --narrow-path option
> > checkout: add new options to support sparse checkout
> > wt-status: Show orphaned entries in "git status" output
> >
>
>
> I would like to test it, do you have a public repo to fetch it?
git://repo.or.cz/git/pclouds.git branch sparse-checkout.
--
Duy
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Santi Béjar @ 2008-09-20 10:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221904913-25887-1-git-send-email-pclouds@gmail.com>
On Sat, Sep 20, 2008 at 12:01 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
>
> Nguyễn Thái Ngọc Duy (14):
> Extend index to save more flags
> Introduce CE_NO_CHECKOUT bit
> ls-files: add options to support sparse checkout
> update-index: refactor mark_valid() in preparation for new options
> update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
> ls-files: Add tests for --sparse and friends
> Prevent diff machinery from examining worktree outside sparse checkout
> checkout_entry(): CE_NO_CHECKOUT on checked out entries.
> grep: skip files outside sparse checkout area
> ls-files: support "sparse patterns", used to form sparse checkout areas
> unpack_trees(): add support for sparse checkout
> clone: support sparse checkout with --narrow-path option
> checkout: add new options to support sparse checkout
> wt-status: Show orphaned entries in "git status" output
>
I would like to test it, do you have a public repo to fetch it?
Santi
^ 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