* [PATCH 0/1] Add new test to demonstrate git archive core.autocrlf inconsistency
From: Charles Bailey @ 2008-09-18 20:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
t/t0024-crlf-archive.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100644 t/t0024-crlf-archive.sh
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
new file mode 100644
index 0000000..3511439
--- /dev/null
+++ b/t/t0024-crlf-archive.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='respect crlf in git archive'
+
+. ./test-lib.sh
+UNZIP=${UNZIP:-unzip}
+
+test_expect_success setup '
+
+ git config core.autocrlf true
+
+ printf "CRLF line ending\r\nAnd another\r\n" > sample &&
+ git add sample &&
+
+ test_tick &&
+ git commit -m Initial
+
+'
+
+test_expect_success 'tar archive' '
+
+ git archive --format=tar HEAD |
+ ( mkdir untarred && cd untarred && "$TAR" -xf - )
+
+ test_cmp sample untarred/sample
+
+'
+
+"$UNZIP" -v >/dev/null 2>&1
+if [ $? -eq 127 ]; then
+ echo "Skipping ZIP test, because unzip was not found"
+ test_done
+ exit
+fi
+
+test_expect_failure 'zip archive' '
+
+ git archive --format=zip HEAD >test.zip &&
+
+ ( mkdir unzipped && cd unzipped && unzip ../test.zip ) &&
+
+ test_cmp sample unzipped/sample
+
+'
+
+test_done
--
1.6.0.1.309.g4f56
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply related
* [PATCH 1/1] Make git archive respect core.autocrlf when creating zip format archives
From: Charles Bailey @ 2008-09-18 20:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1a7cc4db062b7df0dae0f27b29dba66c9d917e59.1221767629.git.charles@hashpling.org>
There is currently no call to git_config at the start of cmd_archive.
When creating tar archives the core config is read as a side-effect of
reading the tar specific config, but this doesn't happen for zip
archives.
The consequence is that in a configuration with core.autocrlf set,
although files in a tar archive are created with crlf line endings,
files in a zip archive retain unix line endings.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
It took me a while to find the cause of the difference in behaviour
between tar and zip format archives when all the crlf fixing code
seemed to be in code shared by both archiving processes. I'm 99% sure
that creating zip archives from repositories with core.autocrlf set to
true should create zip entries with crlf line endings but it would be
good to have that confirmed.
builtin-archive.c | 2 ++
t/t0024-crlf-archive.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-archive.c b/builtin-archive.c
index 5ceec43..432ce2a 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -111,6 +111,8 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
{
const char *remote = NULL;
+ git_config(git_default_config, NULL);
+
remote = extract_remote_arg(&argc, argv);
if (remote)
return run_remote_archiver(remote, argc, argv);
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
index 3511439..e533039 100644
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -33,7 +33,7 @@ if [ $? -eq 127 ]; then
exit
fi
-test_expect_failure 'zip archive' '
+test_expect_success 'zip archive' '
git archive --format=zip HEAD >test.zip &&
--
1.6.0.1.309.g4f56
^ permalink raw reply related
* GitTogether topics status
From: Christian Couder @ 2008-09-18 20:07 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
Hi,
As can be seen on the GitTogether page on the wiki:
http://git.or.cz/gitwiki/GitTogether
we may have the following speakers/topics:
* Shawn O. Pearce:
- bundle related secret project,
- JGit,
- PackV4,
* Sam Vilain:
- GitTorrent (current state, security considerations, future direction),
- Git as a DB backend,
* Junio C Hamano:
- TBD,
Some people are not yet decided and others have not yet be contacted. So the
list of possible speakers may grow. By the way if you want to talk or
introduce a discussion/workshop/haxession please contact us (Shawn and
myself).
The topics suggested on the wiki are:
- GitTorrent: current state, security considerations, future direction
- Submodules: how to make a UI for this important feature that is intuitive
and complete
- PackV4
- JGit, quo vadis1?
- Using Git for everything but source (Git as a backup tool, how to handle
large blobs, using as a DB back-end, etc)
- How to make Git more attractive to the Google Code folks?
- Success/War stories (big wanking session for Gits)
- Linkable library for basic object access (libification or new library)
- Git GUI that even a designer could use (GitCheetah, AKA TortoiseGit?)
- Shawn's current bundle related secret project
- TopGit introduction/design/integration(?)
- Pasky's current pickaxe related "secret project" (if tangible by then)
- New Git Homepage hammering-out
- Extending Git with volatile metadata database (see
20080910164045.GL10360@machine.or.cz)
- Git Survey 2008 results and discussion
- Free form "We tried to use git in our project this way, didn't work very
well" session, where participants are not allowed to say "Your workflow is
broken".
More topics/ideas are welcome.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 1/1] Make git archive respect core.autocrlf when creating zip format archives
From: Charles Bailey @ 2008-09-18 20:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20080918200120.GB8631@hashpling.org>
Apologies for the bad threading headers and the weird characters in
the subject.
While I though I'd remembered how git format-patch and my mail client
worked together, it's obvious that I hadn't.
I'll make sure that I get it right in the final patch, but in the mean
time are there any comments on this?
Charles.
^ permalink raw reply
* Re: [PATCH 1/1] Make git archive respect core.autocrlf when creating zip format archives
From: Andreas Ericsson @ 2008-09-18 20:21 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, Junio C Hamano
In-Reply-To: <20080918200120.GB8631@hashpling.org>
Charles Bailey wrote:
> There is currently no call to git_config at the start of cmd_archive.
> When creating tar archives the core config is read as a side-effect of
> reading the tar specific config, but this doesn't happen for zip
> archives.
>
> The consequence is that in a configuration with core.autocrlf set,
> although files in a tar archive are created with crlf line endings,
> files in a zip archive retain unix line endings.
>
> Signed-off-by: Charles Bailey <charles@hashpling.org>
> ---
>
> It took me a while to find the cause of the difference in behaviour
> between tar and zip format archives when all the crlf fixing code
> seemed to be in code shared by both archiving processes. I'm 99% sure
> that creating zip archives from repositories with core.autocrlf set to
> true should create zip entries with crlf line endings but it would be
> good to have that confirmed.
>
If it fixes the broken test while all the other tests still
pass, I can only assume it's doing something right.
The topic is a bit long though. Could you change it to
"git archive: respect core.autocrlf when creating zip archives"
so that it fits comfortably in one line when running "git log"
on 80 char wide terminals?
As a side-note, you needn't put "1/1" in the [PATCH] section.
That's usually done to make sure patches are applied in the
right order when sending a series, but since a series of 1
is kinda hard to jumble.. ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/1] Make git archive respect core.autocrlf when creating ...
From: Charles Bailey @ 2008-09-18 20:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Junio C Hamano
In-Reply-To: <48D2B831.8080206@op5.se>
On Thu, Sep 18, 2008 at 10:21:05PM +0200, Andreas Ericsson wrote:
> If it fixes the broken test while all the other tests still
> pass, I can only assume it's doing something right.
Only if you believe that I added a sensible test in the first place :-)
> The topic is a bit long though. Could you change it to
> "git archive: respect core.autocrlf when creating zip archives"
> so that it fits comfortably in one line when running "git log"
> on 80 char wide terminals?
Sorry, I made it <= 72 chars in my commit message and then forgot that
git format-patch adds the [PATCH] tag.
> As a side-note, you needn't put "1/1" in the [PATCH] section.
> That's usually done to make sure patches are applied in the
> right order when sending a series, but since a series of 1
> is kinda hard to jumble.. ;-)
I thought that the patch (a single commit) didn't really warrant a patch
series - being a one liner - but I made the test 0 of 1 so that people
could see the test failure first before deciding whether my proposed
patch was good or not. Sorry for the confusion.
Charles.
^ permalink raw reply
* Re: [PATCH 1/1] Make git archive respect core.autocrlf when creating zip format archives
From: René Scharfe @ 2008-09-18 20:41 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, Junio C Hamano
In-Reply-To: <20080918200120.GB8631@hashpling.org>
Charles Bailey schrieb:
> There is currently no call to git_config at the start of cmd_archive.
> When creating tar archives the core config is read as a side-effect of
> reading the tar specific config, but this doesn't happen for zip
> archives.
>
> The consequence is that in a configuration with core.autocrlf set,
> although files in a tar archive are created with crlf line endings,
> files in a zip archive retain unix line endings.
The patches look good, but it took me a while to realize that there are
two of them (0/1 and 1/1). :)
Thanks,
René
^ permalink raw reply
* Re: GitTogether topics status
From: Jakub Narebski @ 2008-09-18 20:48 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Shawn O. Pearce
In-Reply-To: <200809182207.21448.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> The topics suggested on the wiki are:
[...]
> More topics/ideas are welcome.
Perhaps a good idea would be to take advantage of whiteboards and
meeting face to face, and talk for example about ideas for perfect GUI
for git, or for editor/IDE/RAD integration interface, designing
mockups of UI. This could aldo help with improving git homepage (the
original one, I guess).
What also might be interesting to talk about scriptability, having
defined API, libification (I see that there is planned), interfaces to
other programming languages versus calling git plumbing versus
reimplementing git in other languages (e.g. JGit vs JavaGit, Grit vs
Ruby/Git, GitPython vs PyGit, Git.pm vs Git::Repo), but I guess this
discussion could be had on git mailing list.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/1] Make git archive respect core.autocrlf when creating ...
From: Sverre Rabbelier @ 2008-09-18 20:53 UTC (permalink / raw)
To: Charles Bailey; +Cc: Andreas Ericsson, git, Junio C Hamano
In-Reply-To: <20080918202929.GA9948@hashpling.org>
On Thu, Sep 18, 2008 at 22:29, Charles Bailey <charles@hashpling.org> wrote:
> I thought that the patch (a single commit) didn't really warrant a patch
> series - being a one liner - but I made the test 0 of 1 so that people
> could see the test failure first before deciding whether my proposed
> patch was good or not. Sorry for the confusion.
Shouldn't the tests be part of the patch? ;) To prevent it from being
broken again that is.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] sha1_file: link() returns -1 on failure, not errno
From: Thomas Rast @ 2008-09-18 22:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
5723fe7 changed the call to use link() directly instead of through a
custom wrapper, but forgot that it returns 0 or -1, not 0 or errno.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
sha1_file.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 9ee1ed1..aec81bb 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2136,7 +2136,9 @@ static void write_sha1_file_prepare(const void *buf, unsigned long len,
*/
int move_temp_to_file(const char *tmpfile, const char *filename)
{
- int ret = link(tmpfile, filename);
+ int ret = 0;
+ if (link(tmpfile, filename))
+ ret = errno;
/*
* Coda hack - coda doesn't like cross-directory links,
--
tg: (97d7fee..) t/link-returns-minus1 (depends on: origin/master)
^ permalink raw reply related
* [PATCH v2 1/4] diff.c: return pattern entry pointer rather than just the hunk header pattern
From: Brandon Casey @ 2008-09-18 22:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <7vskry1485.fsf@gitster.siamese.dyndns.org>
This is in preparation for associating a flag with each pattern which will
control how the pattern is interpreted. For example, as a basic or extended
regular expression.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> diff --git a/diff.c b/diff.c
>> index 998dcaa..e040088 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -94,6 +94,8 @@ static int parse_lldiff_command(const char *var, const char *ep, const char *val
>> * 'diff.<what>.funcname' attribute can be specified in the configuration
>> * to define a customized regexp to find the beginning of a function to
>> * be used for hunk header lines of "diff -p" style output.
>> + * Note: If this structure is modified, it must retain the ability to be cast
>> + * to a struct funcname_pattern_entry, defined elsewhere.
>> */
>
> Yuck. Why not do:
>
> struct funcname_pattern_entry {
> /* whatever fields one entry needs */
> };
> static struct funcname_pattern_list {
> struct funcname_pattern_list *next;
> struct funcname_pattern_entry e;
> } *funcname_pattern_list;
<...>
> Then you do not have to worry about casting things up and down, right?
diff.c | 55 ++++++++++++++++++++++++++++---------------------------
1 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/diff.c b/diff.c
index 998dcaa..3928124 100644
--- a/diff.c
+++ b/diff.c
@@ -95,32 +95,35 @@ static int parse_lldiff_command(const char *var, const char *ep, const char *val
* to define a customized regexp to find the beginning of a function to
* be used for hunk header lines of "diff -p" style output.
*/
-static struct funcname_pattern {
+struct funcname_pattern_entry {
char *name;
char *pattern;
- struct funcname_pattern *next;
+};
+static struct funcname_pattern_list {
+ struct funcname_pattern_list *next;
+ struct funcname_pattern_entry e;
} *funcname_pattern_list;
static int parse_funcname_pattern(const char *var, const char *ep, const char *value)
{
const char *name;
int namelen;
- struct funcname_pattern *pp;
+ struct funcname_pattern_list *pp;
name = var + 5; /* "diff." */
namelen = ep - name;
for (pp = funcname_pattern_list; pp; pp = pp->next)
- if (!strncmp(pp->name, name, namelen) && !pp->name[namelen])
+ if (!strncmp(pp->e.name, name, namelen) && !pp->e.name[namelen])
break;
if (!pp) {
pp = xcalloc(1, sizeof(*pp));
- pp->name = xmemdupz(name, namelen);
+ pp->e.name = xmemdupz(name, namelen);
pp->next = funcname_pattern_list;
funcname_pattern_list = pp;
}
- free(pp->pattern);
- pp->pattern = xstrdup(value);
+ free(pp->e.pattern);
+ pp->e.pattern = xstrdup(value);
return 0;
}
@@ -1382,20 +1385,17 @@ int diff_filespec_is_binary(struct diff_filespec *one)
return one->is_binary;
}
-static const char *funcname_pattern(const char *ident)
+static const struct funcname_pattern_entry *funcname_pattern(const char *ident)
{
- struct funcname_pattern *pp;
+ struct funcname_pattern_list *pp;
for (pp = funcname_pattern_list; pp; pp = pp->next)
- if (!strcmp(ident, pp->name))
- return pp->pattern;
+ if (!strcmp(ident, pp->e.name))
+ return &pp->e;
return NULL;
}
-static struct builtin_funcname_pattern {
- const char *name;
- const char *pattern;
-} builtin_funcname_pattern[] = {
+static const struct funcname_pattern_entry builtin_funcname_pattern[] = {
{ "bibtex", "\\(@[a-zA-Z]\\{1,\\}[ \t]*{\\{0,1\\}[ \t]*[^ \t\"@',\\#}{~%]*\\).*$" },
{ "html", "^\\s*\\(<[Hh][1-6]\\s.*>.*\\)$" },
{ "java", "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
@@ -1415,9 +1415,10 @@ static struct builtin_funcname_pattern {
{ "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$" },
};
-static const char *diff_funcname_pattern(struct diff_filespec *one)
+static const struct funcname_pattern_entry *diff_funcname_pattern(struct diff_filespec *one)
{
- const char *ident, *pattern;
+ const char *ident;
+ const struct funcname_pattern_entry *pe;
int i;
diff_filespec_check_attr(one);
@@ -1432,9 +1433,9 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)
return funcname_pattern("default");
/* Look up custom "funcname.$ident" regexp from config. */
- pattern = funcname_pattern(ident);
- if (pattern)
- return pattern;
+ pe = funcname_pattern(ident);
+ if (pe)
+ return pe;
/*
* And define built-in fallback patterns here. Note that
@@ -1442,7 +1443,7 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)
*/
for (i = 0; i < ARRAY_SIZE(builtin_funcname_pattern); i++)
if (!strcmp(ident, builtin_funcname_pattern[i].name))
- return builtin_funcname_pattern[i].pattern;
+ return &builtin_funcname_pattern[i];
return NULL;
}
@@ -1520,11 +1521,11 @@ static void builtin_diff(const char *name_a,
xdemitconf_t xecfg;
xdemitcb_t ecb;
struct emit_callback ecbdata;
- const char *funcname_pattern;
+ const struct funcname_pattern_entry *pe;
- funcname_pattern = diff_funcname_pattern(one);
- if (!funcname_pattern)
- funcname_pattern = diff_funcname_pattern(two);
+ pe = diff_funcname_pattern(one);
+ if (!pe)
+ pe = diff_funcname_pattern(two);
memset(&xecfg, 0, sizeof(xecfg));
memset(&ecbdata, 0, sizeof(ecbdata));
@@ -1536,8 +1537,8 @@ static void builtin_diff(const char *name_a,
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
xecfg.ctxlen = o->context;
xecfg.flags = XDL_EMIT_FUNCNAMES;
- if (funcname_pattern)
- xdiff_set_find_func(&xecfg, funcname_pattern);
+ if (pe)
+ xdiff_set_find_func(&xecfg, pe->pattern);
if (!diffopts)
;
else if (!prefixcmp(diffopts, "--unified="))
--
1.6.0.1.244.gdc19
^ permalink raw reply related
* [PATCH v2 2/4] diff.c: associate a flag with each pattern and use it for compiling regex
From: Brandon Casey @ 2008-09-18 22:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <7vskry1485.fsf@gitster.siamese.dyndns.org>
This is in preparation for allowing extended regular expression patterns.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
diff.c | 27 +++++++++++++++------------
xdiff-interface.c | 4 ++--
xdiff-interface.h | 2 +-
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/diff.c b/diff.c
index 3928124..08cdd8f 100644
--- a/diff.c
+++ b/diff.c
@@ -98,13 +98,14 @@ static int parse_lldiff_command(const char *var, const char *ep, const char *val
struct funcname_pattern_entry {
char *name;
char *pattern;
+ int cflags;
};
static struct funcname_pattern_list {
struct funcname_pattern_list *next;
struct funcname_pattern_entry e;
} *funcname_pattern_list;
-static int parse_funcname_pattern(const char *var, const char *ep, const char *value)
+static int parse_funcname_pattern(const char *var, const char *ep, const char *value, int cflags)
{
const char *name;
int namelen;
@@ -124,6 +125,7 @@ static int parse_funcname_pattern(const char *var, const char *ep, const char *v
}
free(pp->e.pattern);
pp->e.pattern = xstrdup(value);
+ pp->e.cflags = cflags;
return 0;
}
@@ -192,7 +194,8 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
if (!strcmp(ep, ".funcname")) {
if (!value)
return config_error_nonbool(var);
- return parse_funcname_pattern(var, ep, value);
+ return parse_funcname_pattern(var, ep, value,
+ 0);
}
}
}
@@ -1396,23 +1399,23 @@ static const struct funcname_pattern_entry *funcname_pattern(const char *ident)
}
static const struct funcname_pattern_entry builtin_funcname_pattern[] = {
- { "bibtex", "\\(@[a-zA-Z]\\{1,\\}[ \t]*{\\{0,1\\}[ \t]*[^ \t\"@',\\#}{~%]*\\).*$" },
- { "html", "^\\s*\\(<[Hh][1-6]\\s.*>.*\\)$" },
+ { "bibtex", "\\(@[a-zA-Z]\\{1,\\}[ \t]*{\\{0,1\\}[ \t]*[^ \t\"@',\\#}{~%]*\\).*$", 0 },
+ { "html", "^\\s*\\(<[Hh][1-6]\\s.*>.*\\)$", 0 },
{ "java", "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
"new\\|return\\|switch\\|throw\\|while\\)\n"
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
- "[ ]*([^;]*\\)$" },
+ "[ ]*([^;]*\\)$", 0 },
{ "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
"destructor\\|interface\\|implementation\\|"
"initialization\\|finalization\\)[ \t]*.*\\)$"
"\\|"
- "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"
- },
- { "php", "^[\t ]*\\(\\(function\\|class\\).*\\)" },
- { "python", "^\\s*\\(\\(class\\|def\\)\\s.*\\)$" },
- { "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
- { "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$" },
+ "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$",
+ 0 },
+ { "php", "^[\t ]*\\(\\(function\\|class\\).*\\)", 0 },
+ { "python", "^\\s*\\(\\(class\\|def\\)\\s.*\\)$", 0 },
+ { "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$", 0 },
+ { "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$", 0 },
};
static const struct funcname_pattern_entry *diff_funcname_pattern(struct diff_filespec *one)
@@ -1538,7 +1541,7 @@ static void builtin_diff(const char *name_a,
xecfg.ctxlen = o->context;
xecfg.flags = XDL_EMIT_FUNCNAMES;
if (pe)
- xdiff_set_find_func(&xecfg, pe->pattern);
+ xdiff_set_find_func(&xecfg, pe->pattern, pe->cflags);
if (!diffopts)
;
else if (!prefixcmp(diffopts, "--unified="))
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 944ad98..7f1a7d3 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -218,7 +218,7 @@ static long ff_regexp(const char *line, long len,
return result;
}
-void xdiff_set_find_func(xdemitconf_t *xecfg, const char *value)
+void xdiff_set_find_func(xdemitconf_t *xecfg, const char *value, int cflags)
{
int i;
struct ff_regs *regs;
@@ -243,7 +243,7 @@ void xdiff_set_find_func(xdemitconf_t *xecfg, const char *value)
expression = buffer = xstrndup(value, ep - value);
else
expression = value;
- if (regcomp(®->re, expression, 0))
+ if (regcomp(®->re, expression, cflags))
die("Invalid regexp to look for hunk header: %s", expression);
free(buffer);
value = ep + 1;
diff --git a/xdiff-interface.h b/xdiff-interface.h
index 558492b..23c49b9 100644
--- a/xdiff-interface.h
+++ b/xdiff-interface.h
@@ -16,6 +16,6 @@ int parse_hunk_header(char *line, int len,
int read_mmfile(mmfile_t *ptr, const char *filename);
int buffer_is_binary(const char *ptr, unsigned long size);
-extern void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line);
+extern void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line, int cflags);
#endif
--
1.6.0.1.244.gdc19
^ permalink raw reply related
* [PATCH v2 3/4] diff.*.xfuncname which uses "extended" regex's for hunk header selection
From: Brandon Casey @ 2008-09-18 22:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <7vskry1485.fsf@gitster.siamese.dyndns.org>
Currently, the hunk headers produced by 'diff -p' are customizable by
setting the diff.*.funcname option in the config file. The 'funcname' option
takes a basic regular expression. This functionality was designed using the
GNU regex library which, by default, allows using backslashed versions of
some extended regular expression operators, even in Basic Regular Expression
mode. For example, the following characters, when backslashed, are
interpreted according to the extended regular expression rules: ?, +, and |.
As such, the builtin funcname patterns were created using some extended
regular expression operators.
Other platforms which adhere more strictly to the POSIX spec do not
interpret the backslashed extended RE operators in Basic Regular Expression
mode. This causes the pattern matching for the builtin funcname patterns to
fail on those platforms.
Introduce a new option 'xfuncname' which uses extended regular expressions,
and advertise it _instead_ of funcname. Since most users are on GNU
platforms, the majority of funcname patterns are created and tested there.
Advertising only xfuncname should help to avoid the creation of non-portable
patterns which work with GNU regex but not elsewhere.
Additionally, the extended regular expressions may be less ugly and
complicated compared to the basic RE since many common special operators do
not need to be backslashed.
For example, the GNU Basic RE:
^[ ]*\\(\\(public\\|static\\).*\\)$
becomes the following Extended RE:
^[ ]*((public|static).*)$
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Documentation/gitattributes.txt | 4 ++--
diff.c | 5 +++++
t/t4018-diff-funcname.sh | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 6f3551d..9a75257 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -288,13 +288,13 @@ for paths.
*.tex diff=tex
------------------------
-Then, you would define "diff.tex.funcname" configuration to
+Then, you would define "diff.tex.xfuncname" configuration to
specify a regular expression that matches a line that you would
want to appear as the hunk header, like this:
------------------------
[diff "tex"]
- funcname = "^\\(\\\\\\(sub\\)*section{.*\\)$"
+ xfuncname = "^(\\\\(sub)*section\\{.*)$"
------------------------
Note. A single level of backslashes are eaten by the
diff --git a/diff.c b/diff.c
index 08cdd8f..9d8fd2b 100644
--- a/diff.c
+++ b/diff.c
@@ -196,6 +196,11 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
return config_error_nonbool(var);
return parse_funcname_pattern(var, ep, value,
0);
+ } else if (!strcmp(ep, ".xfuncname")) {
+ if (!value)
+ return config_error_nonbool(var);
+ return parse_funcname_pattern(var, ep, value,
+ REG_EXTENDED);
}
}
}
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 18bcd97..602d68f 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -58,7 +58,7 @@ test_expect_success 'last regexp must not be negated' '
'
test_expect_success 'alternation in pattern' '
- git config diff.java.funcname "^[ ]*\\(\\(public\\|static\\).*\\)$"
+ git config diff.java.xfuncname "^[ ]*((public|static).*)$" &&
git diff --no-index Beer.java Beer-correct.java |
grep "^@@.*@@ public static void main("
'
--
1.6.0.1.244.gdc19
^ permalink raw reply related
* [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Brandon Casey @ 2008-09-18 22:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <7vskry1485.fsf@gitster.siamese.dyndns.org>
The 'non-GNU' part of this basic RE to extended RE conversion means '\\s' was
converted to ' '.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
diff.c | 35 ++++++++++++++++++-----------------
1 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/diff.c b/diff.c
index 9d8fd2b..c74f1a3 100644
--- a/diff.c
+++ b/diff.c
@@ -1404,23 +1404,24 @@ static const struct funcname_pattern_entry *funcname_pattern(const char *ident)
}
static const struct funcname_pattern_entry builtin_funcname_pattern[] = {
- { "bibtex", "\\(@[a-zA-Z]\\{1,\\}[ \t]*{\\{0,1\\}[ \t]*[^ \t\"@',\\#}{~%]*\\).*$", 0 },
- { "html", "^\\s*\\(<[Hh][1-6]\\s.*>.*\\)$", 0 },
- { "java", "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
- "new\\|return\\|switch\\|throw\\|while\\)\n"
- "^[ ]*\\(\\([ ]*"
- "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
- "[ ]*([^;]*\\)$", 0 },
- { "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
- "destructor\\|interface\\|implementation\\|"
- "initialization\\|finalization\\)[ \t]*.*\\)$"
- "\\|"
- "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$",
- 0 },
- { "php", "^[\t ]*\\(\\(function\\|class\\).*\\)", 0 },
- { "python", "^\\s*\\(\\(class\\|def\\)\\s.*\\)$", 0 },
- { "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$", 0 },
- { "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$", 0 },
+ { "bibtex", "(@[a-zA-Z]{1,}[ \t]*\\{{0,1}[ \t]*[^ \t\"@',\\#\\}\\{~%]*).*$", REG_EXTENDED },
+ { "html", "^ *(<[Hh][1-6] .*>.*)$", REG_EXTENDED },
+ { "java", "!^[ ]*(catch|do|for|if|instanceof|"
+ "new|return|switch|throw|while)\n"
+ "^[ ]*(([ ]*"
+ "[A-Za-z_][A-Za-z_0-9]*){2,}"
+ "[ ]*\\([^;]*)$", REG_EXTENDED },
+ { "pascal", "^((procedure|function|constructor|"
+ "destructor|interface|implementation|"
+ "initialization|finalization)[ \t]*.*)$"
+ "|"
+ "^(.*=[ \t]*(class|record).*)$",
+ REG_EXTENDED },
+ { "php", "^[\t ]*((function|class).*)", REG_EXTENDED },
+ { "python", "^ *((class|def)\\s.*)$", REG_EXTENDED },
+ { "ruby", "^ *((class|module|def) .*)$", REG_EXTENDED },
+ { "tex", "^(\\\\((sub)*section|chapter|part)\\*{0,1}\\{.*)$",
+ REG_EXTENDED },
};
static const struct funcname_pattern_entry *diff_funcname_pattern(struct diff_filespec *one)
--
1.6.0.1.244.gdc19
^ permalink raw reply related
* Re: How to supply "raw" bytes to git grep?
From: Kalle Olavi Niemitalo @ 2008-09-18 22:07 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060809180846j25e4eb44h291b017aa01bbe36@mail.gmail.com>
"Jacob Helwig" <jacob.helwig@gmail.com> writes:
> Inserting a literal carriage return seems to do the trick for me, in bash.
>
> git grep --cached -I -l -e <Ctrl-V><Ctrl-M>
In bash, $'\r' works too, and may be nicer to edit.
Better not use that with #! /bin/sh though.
^ 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-18 22:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <4i0Mu795rKpv37JoHytmE6kODBjwgwITn0-DuKdZiFs3ZnUlyJC-Fw@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> + { "java", "!^[ ]*(catch|do|for|if|instanceof|"
> + "new|return|switch|throw|while)\n"
> + "^[ ]*(([ ]*"
> + "[A-Za-z_][A-Za-z_0-9]*){2,}"
I don't understand the last two lines above.
Is it possible for the second bracketed space and tab to match
anything? Wouldn't the first one consume all space and tab?
Assuming it is possible for the second brackets to match
successfully, why would we want to capture this leading
space?
It looks like both of the following lines would match:
' a'
'ab'
but not this
'a'
Would it be better written like:
"^[ ]*(([A-Za-z_][A-Za-z_0-9]*)"
> + "[ ]*\\([^;]*)$", REG_EXTENDED },
<snip>
-brandon
^ permalink raw reply
* [PATCH] Documentation: clarify the details of overriding LESS via core.pager
From: Chris Frey @ 2008-09-18 23:22 UTC (permalink / raw)
To: git
The process of overriding the default LESS options using only
git-specific methods is rather obscure. Show the end user how
to do it in a step-by-step manner.
Signed-off-by: Chris Frey <cdfrey@foursquare.net>
---
I recently upgraded to 1.6.0.2, and ran into the LESS problem again.
I usually just hacked the code, but figured this was sub-par, expecially
with the documentation recently upgraded to show me how to do it
with core.pager.
Unfortunately, it took me much longer than I would have expected.
I'm assuming others will have run into this as well, so here's
an update to the docs.
The most interesting feature I discovered while looking into this,
was that setting command line options in core.pager ends up using
the shell, which allows for additional trickery to make this
override truly git-specific.
Now I can have different less behaviour when using it myself vs.
using it through git. In the same shell. Regardless of how I
setup LESS.
- Chris
Documentation/config.txt | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 922ac7b..9493621 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -363,8 +363,17 @@ core.pager::
variable. Note that git sets the `LESS` environment
variable to `FRSX` if it is unset when it runs the
pager. One can change these settings by setting the
- `LESS` variable to some other value or by giving the
- `core.pager` option a value such as "`less -+FRSX`".
+ `LESS` variable to some other value. Alternately,
+ these settings can be overridden on a project or
+ global basis by setting the `core.pager` option.
+ Setting `core.pager` has no affect on the `LESS`
+ environment variable behaviour above, so if you want
+ to override git's default settings this way, you need
+ to be explicit. For example, to disable the S option
+ in a backward compatible manner, set `core.pager`
+ to "`less -+$LESS -FRX`". This will be passed to the
+ shell by git, which will translate the final command to
+ "`LESS=FRSX less -+FRSX -FRX`".
core.whitespace::
A comma separated list of common whitespace problems to
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Johan Herland @ 2008-09-18 23:40 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <4i0Mu795rKpv37JoHytmE6kODBjwgwITn0-DuKdZiFs3ZnUlyJC-Fw@cipher.nrlssc.navy.mil>
On Friday 19 September 2008, Brandon Casey wrote:
> The 'non-GNU' part of this basic RE to extended RE conversion means '\\s'
> was converted to ' '.
Shouldn't that be '[ \t]' instead? At least I would like that for the HTML
pattern.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* How to remove a commit object?
From: Steven Grimm @ 2008-09-18 23:41 UTC (permalink / raw)
To: Git Users List
I maintain a shared repository a bunch of my coworkers push to for
code reviews. It has accumulated a lot of packfiles, so I want to
shrink it down a bit, but there's a problem:
% git repack -A -d
Counting objects: ...
error: Could not read 125bf191b65189aaec7a6aa24ff26460d141d587
fatal: bad tree object 125bf191b65189aaec7a6aa24ff26460d141d587
"git fsck" confirms that the tree object is missing:
% git fsck
broken link from commit 1b2f0595bb4a6c2e17ca43a9cc41feec88c72a47
to tree 125bf191b65189aaec7a6aa24ff26460d141d587
...
missing tree 125bf191b65189aaec7a6aa24ff26460d141d587
This is a dangling commit, but that's fine; for this particular
repository we actually *want* lots of dangling commits since they
represent the history of people's code review requests. (Hence me
running git-repack with -A instead of -a.)
Given that it's dangling, it seems like it'd be safe to just remove
entirely (we lose that little bit of code-review history but we've
lost it already anyway with the tree object missing). But I'm not sure
how to do it. Is it possible to delete a commit object, and if so, how?
I don't know how the corruption happened in the first place. There was
a short time at one point where the permissions on the object
directories were inconsistent, so it's possible someone pushed during
that period and managed to create the commit object file in .git/
objects but didn't have permission to create the tree object. That's
just speculation on my part, though. This is the only corrupt object
in the repository according to git-fsck, so at this point I just want
to know how to get rid of it so I can do the repack.
Thanks!
-Steve
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-19 2:56 UTC (permalink / raw)
To: dhruva, Jing Xue, David Brown
Cc: Daniel Barkalow, Junio C Hamano, GIT SCM, Simon Hausmann
Hello,
----- Original Message ----
> From: dhruva <dhruva@ymail.com>
> To: Jing Xue <jingxue@digizenstudio.com>; David Brown <git@davidb.org>
> >
> > How about collapsing the keywords in the _p4_ version after "p4 edit"
> > but before applying the patch, and just "p4 submit" the collapsed
> > version if patching succeeds? As pointed out earlier in this thread, p4
> > submit doesn't care about whether keywords are expanded or not anyway.
>
> That is feasible but would require more changes. I still feel having an option
> to disable the keyword from collapsing is a move forward followed by your
> suggestion as a bug fix to fix the issue with 'p4 submit' when rcs keywords are
> collapsed. Would that be an acceptable approach?
>
If there are no more suggestions or objections, could we go ahead with patch? Personally, I would love to start seeing my small contributions getting into mainline and hence the shameless eagerness :)
-dhruva
Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/
^ permalink raw reply
* Re: GitTogether topics status
From: Christian Couder @ 2008-09-19 5:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce
In-Reply-To: <m363otmb8p.fsf@localhost.localdomain>
Le jeudi 18 septembre 2008, Jakub Narebski a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > The topics suggested on the wiki are:
>
> [...]
>
> > More topics/ideas are welcome.
>
> Perhaps a good idea would be to take advantage of whiteboards and
> meeting face to face, and talk for example about ideas for perfect GUI
> for git, or for editor/IDE/RAD integration interface, designing
> mockups of UI. This could aldo help with improving git homepage (the
> original one, I guess).
Ok. There are now the following topics together on the wiki:
* Git GUI that even a designer could use (Git``Cheetah, AKA Tortoise``Git?)
(UI session?)
* Git integration with IDE, RAD, and editors (UI session?)
* New Git Homepage hammering-out (UI session?)
The second one is new. And "(UI session?)" was added at the end of each of
them.
> What also might be interesting to talk about scriptability, having
> defined API, libification (I see that there is planned), interfaces to
> other programming languages versus calling git plumbing versus
> reimplementing git in other languages (e.g. JGit vs JavaGit, Grit vs
> Ruby/Git, GitPython vs PyGit, Git.pm vs Git::Repo), but I guess this
> discussion could be had on git mailing list.
The following topics are now together on the wiki:
* Linkable library for basic object access (libification or new library)
* Scriptability, using git in other languages (using interfaces vs calling
plumbing vs reimplementting)
The second one is new.
If we want these topics to be discussed during the GitTogether, we need
someone who wants to talk about or at least introduce these subjects
though. (Hint, hint.)
Thanks,
Christian.
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Kirill Smelkov @ 2008-09-19 5:06 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Bert Wesarg, Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <alpine.LNX.1.00.0809181526190.19665@iabervon.org>
On Thu, Sep 18, 2008 at 03:30:35PM -0400, Daniel Barkalow wrote:
> On Thu, 18 Sep 2008, Bert Wesarg wrote:
>
> > On Thu, Sep 18, 2008 at 18:29, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> > > Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> > > ---
> > > .gitignore | 2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/.gitignore b/.gitignore
> > > index 8868f2d..aa39db4 100644
> > > --- a/.gitignore
> > > +++ b/.gitignore
> > > @@ -18,3 +18,5 @@ tg-import.txt
> > > tg-remote
> > > tg-remote.txt
> > > tg
> > > +
> > > +*.swp
> > can't you do this in your .git/info/excludes?
>
> It's generally better to put a core.excludesfile entry in your
> ~/.gitconfig pointing to a ignore file with editor temporaries for the
> editor(s) you personally use. This will then apply to all git projects you
> work on.
Yes, this makes sense, thanks.
I've had to add the following to my ~/.gitconfig
[core]
excludesfile= /home/kirr/.gitignore-kirr
because it does not work when '~' is used for $HOME
[core]
excludesfile= ~/.gitignore-kirr # does not work
Is it intended?
Still I think since a lot of people have to do the same operation, maybe
it makes sense to put ignores for popular tools right into project's
.gitignore.
--
Всего хорошего, Кирилл.
^ permalink raw reply
* Re: GitTogether topics status
From: Scott Chacon @ 2008-09-19 6:03 UTC (permalink / raw)
To: Christian Couder; +Cc: Jakub Narebski, git, Shawn O. Pearce
In-Reply-To: <200809190703.11969.chriscool@tuxfamily.org>
Hi,
On Thu, Sep 18, 2008 at 10:03 PM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> Le jeudi 18 septembre 2008, Jakub Narebski a écrit :
>> Christian Couder <chriscool@tuxfamily.org> writes:
>> > The topics suggested on the wiki are:
>>
>> [...]
>>
>> > More topics/ideas are welcome.
>>
>> Perhaps a good idea would be to take advantage of whiteboards and
>> meeting face to face, and talk for example about ideas for perfect GUI
>> for git, or for editor/IDE/RAD integration interface, designing
>> mockups of UI. This could aldo help with improving git homepage (the
>> original one, I guess).
>
> Ok. There are now the following topics together on the wiki:
>
> * Git GUI that even a designer could use (Git``Cheetah, AKA Tortoise``Git?)
> (UI session?)
> * Git integration with IDE, RAD, and editors (UI session?)
> * New Git Homepage hammering-out (UI session?)
>
> The second one is new. And "(UI session?)" was added at the end of each of
> them.
>
>> What also might be interesting to talk about scriptability, having
>> defined API, libification (I see that there is planned), interfaces to
>> other programming languages versus calling git plumbing versus
>> reimplementing git in other languages (e.g. JGit vs JavaGit, Grit vs
>> Ruby/Git, GitPython vs PyGit, Git.pm vs Git::Repo), but I guess this
>> discussion could be had on git mailing list.
>
> The following topics are now together on the wiki:
>
> * Linkable library for basic object access (libification or new library)
> * Scriptability, using git in other languages (using interfaces vs calling
> plumbing vs reimplementting)
>
> The second one is new.
>
> If we want these topics to be discussed during the GitTogether, we need
> someone who wants to talk about or at least introduce these subjects
> though. (Hint, hint.)
I would be happy to talk about / introduce at least the second one,
since I've done most of the work on the pure-ruby implementation of
git in the Grit project, which is one of the more popular of the
re-implementations out there (and runs the GitHub site). I would also
be happy to help with a discussion on the first one, since I added it
to the wiki in the first place and it is heavily connected to the
second topic. I very much want to see a library that provides basic
Git object access that we can use to write proper bindings in
Ruby/Python/Perl. If the current Git code is too difficult to libify
properly, then perhaps an alternate C implementation that is built
only for that purpose is preferable to having a re-implementation in
_every_ language. Looking forward to the discussion.
Scott
>
> Thanks,
> Christian.
>
>
> --
> 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
* Re: GitTogether topics status
From: Christian Couder @ 2008-09-19 6:35 UTC (permalink / raw)
To: Scott Chacon; +Cc: Jakub Narebski, git, Shawn O. Pearce
In-Reply-To: <d411cc4a0809182303x365e2280r3fc8a9a3534d8890@mail.gmail.com>
Le vendredi 19 septembre 2008, Scott Chacon a écrit :
> Hi,
>
> On Thu, Sep 18, 2008 at 10:03 PM, Christian Couder
>
> <chriscool@tuxfamily.org> wrote:
> > Le jeudi 18 septembre 2008, Jakub Narebski a écrit :
> >
> >> What also might be interesting to talk about scriptability, having
> >> defined API, libification (I see that there is planned), interfaces to
> >> other programming languages versus calling git plumbing versus
> >> reimplementing git in other languages (e.g. JGit vs JavaGit, Grit vs
> >> Ruby/Git, GitPython vs PyGit, Git.pm vs Git::Repo), but I guess this
> >> discussion could be had on git mailing list.
> >
> > The following topics are now together on the wiki:
> >
> > * Linkable library for basic object access (libification or new
> > library) * Scriptability, using git in other languages (using
> > interfaces vs calling plumbing vs reimplementting)
> >
> > The second one is new.
> >
> > If we want these topics to be discussed during the GitTogether, we need
> > someone who wants to talk about or at least introduce these subjects
> > though. (Hint, hint.)
>
> I would be happy to talk about / introduce at least the second one,
> since I've done most of the work on the pure-ruby implementation of
> git in the Grit project, which is one of the more popular of the
> re-implementations out there (and runs the GitHub site). I would also
> be happy to help with a discussion on the first one, since I added it
> to the wiki in the first place and it is heavily connected to the
> second topic. I very much want to see a library that provides basic
> Git object access that we can use to write proper bindings in
> Ruby/Python/Perl. If the current Git code is too difficult to libify
> properly, then perhaps an alternate C implementation that is built
> only for that purpose is preferable to having a re-implementation in
> _every_ language. Looking forward to the discussion.
Great! You are now in the "Possible speakers" list on the wiki.
Thanks,
Christian.
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Bert Wesarg @ 2008-09-19 7:10 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Daniel Barkalow, Petr Baudis, Git Mailing List
In-Reply-To: <20080919050612.GA4423@roro3>
On Fri, Sep 19, 2008 at 07:06, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> On Thu, Sep 18, 2008 at 03:30:35PM -0400, Daniel Barkalow wrote:
>> On Thu, 18 Sep 2008, Bert Wesarg wrote:
>>
>> > On Thu, Sep 18, 2008 at 18:29, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
>> > > Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
>> > > ---
>> > > .gitignore | 2 ++
>> > > 1 files changed, 2 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/.gitignore b/.gitignore
>> > > index 8868f2d..aa39db4 100644
>> > > --- a/.gitignore
>> > > +++ b/.gitignore
>> > > @@ -18,3 +18,5 @@ tg-import.txt
>> > > tg-remote
>> > > tg-remote.txt
>> > > tg
>> > > +
>> > > +*.swp
>> > can't you do this in your .git/info/excludes?
>>
>> It's generally better to put a core.excludesfile entry in your
>> ~/.gitconfig pointing to a ignore file with editor temporaries for the
>> editor(s) you personally use. This will then apply to all git projects you
>> work on.
>
> Yes, this makes sense, thanks.
>
> I've had to add the following to my ~/.gitconfig
>
> [core]
> excludesfile= /home/kirr/.gitignore-kirr
>
>
> because it does not work when '~' is used for $HOME
>
> [core]
> excludesfile= ~/.gitignore-kirr # does not work
Have you tried:
[core]
excludesfile = .gitignore-kirr
There was a discussion about relative files in config. but I didn't tried this.
Anyway, I think this is the best solution. Don't globber the repos with this.
Bert
^ 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