* Re: [ANNOUNCE] ugit: the pythonic git gui
From: Guilhem Bonnefille @ 2008-01-02 10:42 UTC (permalink / raw)
To: David; +Cc: git
In-Reply-To: <402731c90712281449g3d0c4f53w48c65dc8883bbbb3@mail.gmail.com>
Hi,
Good to learn a new GUI is available for Git.
But, for people like me, not enougth curious to install the software,
do you have any screenshots somewhere?
2007/12/28, David <davvid@gmail.com>:
> ugit, the pyqt-based git gui, has been taking shape as of late.
>
> First off, I'd like to thank everyone that replied with suggestions
> and criticism. This list is extremely helpful with regards to
> providing honest software critiques.
>
> New features since the last announcement (almost all of which were
> mentioned in one way or another on this list):
>
> * inotify support (we've removed the "Rescan" button)
> * Patch hunk un/staging
> * Allows un/staging selected patch hunk lines (without --unidiff-zero)
> * Prepped for i18n ("env LANG=ja_JP ugit" looks pretty cool now)
> * I'm a westerner, so the unstaged list is now on the left and the
> staged list is on the right (thanks Jason)
> * Optimizations to improve the interactivity of the patch browser
> * Misc. fixes for MacOS and Windows (thanks Steffan and Sebastian)
> * Uses default system colors whenever possible [no more darkness] (thanks Alex)
> * No longer requires PYTHONPATH
>
> Source code (requires pyqt4-dev-tools to build):
> http://repo.or.cz/w/ugit.git
>
> Tarballs (require a stock pyqt-4.3 installation):
> http://ugit.justroots.com/
>
> I'll try and get some .deb, .rpm, etc. action happening soon.
>
> p.s.
> If you read ugit as "(f)uh-git" or "ugly-git", then that's good since
> I think that falls in line with the git style ;-)
> -
> 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
>
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* About the .gitmodules file
From: Imran M Yousuf @ 2008-01-02 10:39 UTC (permalink / raw)
To: git
Hi All,
I need a help in order to parse the .gitmodules file generated on
"git-submodule add". An entry for a submodule in that file looks like:
[submodule "a"]
path = a
url = /home/imyousuf/projects/git-projs/smart-sip/submodules/a/.git
I want to parse this file to know the location of my module so that
when I got git-commit on the parent project my script will also
traverse the submodule hierarchy. I wanted to know whether path = a
noted the relative path from the current directory or not.
Thanks in advance,
--
Imran M Yousuf
^ permalink raw reply
* Re: [PATCH] Remove duplication in t9119-git-svn-info.sh
From: Junio C Hamano @ 2008-01-02 10:27 UTC (permalink / raw)
To: Eric Wong; +Cc: David D. Kilzer, git
In-Reply-To: <20080102034317.GB11711@untitled>
Eric Wong <normalperson@yhbt.net> writes:
> Nevertheless, does your change make things work with older
> versions of SVN? I'm running 1.4.x everywhere these days, but
> I seem to recall the version of SVN on kernel.org was giving
> Junio trouble with the tests.
Ahh, you are right. Here is what I am getting.
$ sh t9119-git-svn-info.sh -i -v
* expecting success:
mkdir info &&
cd info &&
echo FIRST > A &&
echo one > file &&
ln -s file symlink-file &&
mkdir directory &&
touch directory/.placeholder &&
ln -s directory symlink-directory &&
svn import -m 'initial' . file:///home/junio/git/t/trash/svnrepo &&
cd .. &&
mkdir gitwc &&
cd gitwc &&
git-svn init file:///home/junio/git/t/trash/svnrepo &&
git-svn fetch &&
cd .. &&
svn co file:///home/junio/git/t/trash/svnrepo svnwc &&
ptouch file &&
ptouch directory &&
ptouch symlink-file &&
ptouch symlink-directory
Adding file
Adding A
Adding symlink-file
Adding directory
Adding directory/.placeholder
Adding symlink-directory
Committed revision 1.
Initialized empty Git repository in .git/
A file
A A
A symlink-file
A directory/.placeholder
A symlink-directory
r1 = 153bc4aeb5ed1375deb17b3611c1d2177ff2e5a4 (git-svn)
Checked out HEAD:
file:///home/junio/git/t/trash/svnrepo r1
A svnwc/file
A svnwc/A
A svnwc/symlink-file
A svnwc/directory
A svnwc/directory/.placeholder
A svnwc/symlink-directory
Checked out revision 1.
* ok 1: setup repository and import
* expecting success:
(cd svnwc; svn info) > expected.info &&
(cd gitwc; git-svn info) > actual.info &&
git-diff expected.info actual.info
* ok 2: info
* expecting success:
test $(cd gitwc; git-svn info --url) = $svnrepo
* ok 3: info --url
* expecting success:
(cd svnwc; svn info .) > expected.info-dot &&
(cd gitwc; git-svn info .) > actual.info-dot &&
git-diff expected.info-dot actual.info-dot
* ok 4: info .
* expecting success:
test $(cd gitwc; git-svn info --url .) = $svnrepo
* ok 5: info --url .
* expecting success:
(cd svnwc; svn info file) > expected.info-file &&
(cd gitwc; git-svn info file) > actual.info-file &&
git-diff expected.info-file actual.info-file
diff --git a/expected.info-file b/actual.info-file
index 23b45e2..e7f3924 100644
--- a/expected.info-file
+++ b/actual.info-file
@@ -10,6 +10,5 @@ Last Changed Author: junio
Last Changed Rev: 1
Last Changed Date: 2008-01-02 10:25:19 +0000 (Wed, 02 Jan 2008)
Text Last Updated: 2008-01-02 10:25:20 +0000 (Wed, 02 Jan 2008)
-Properties Last Updated: 2008-01-02 10:25:20 +0000 (Wed, 02 Jan 2008)
Checksum: 5bbf5a52328e7439ae6e719dfe712200
* FAIL 6: info file
(cd svnwc; svn info file) > expected.info-file &&
(cd gitwc; git-svn info file) > actual.info-file &&
git-diff expected.info-file actual.info-file
^ permalink raw reply related
* [PATCH 3/2] attribute "coding": specify blob encoding
From: Junio C Hamano @ 2008-01-02 9:50 UTC (permalink / raw)
To: Tsugikazu Shibata; +Cc: git
In-Reply-To: <7v1w904x29.fsf@gitster.siamese.dyndns.org>
This teaches "diff hunk header" function about custom character
encoding per path via gitattributes(5) so that it can sensibly
chomp a line without truncating a character in the middle.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is not intended for serious inclusion, but was done more
as a demonstration of the concept, hence [3/2].
Makefile | 5 ++-
coding.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
coding.h | 10 +++++++++
diff.c | 48 ++++++++++++++++++++++++++++++++++++++++-----
diffcore.h | 1 +
5 files changed, 118 insertions(+), 8 deletions(-)
create mode 100644 coding.c
create mode 100644 coding.h
diff --git a/Makefile b/Makefile
index 21c80e6..de205e6 100644
--- a/Makefile
+++ b/Makefile
@@ -293,7 +293,8 @@ LIB_H = \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
- mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h
+ mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h \
+ coding.h
DIFF_OBJS = \
diff.o diff-lib.o diffcore-break.o diffcore-order.o \
@@ -316,7 +317,7 @@ LIB_OBJS = \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o \
- transport.o bundle.o walker.o parse-options.o ws.o
+ transport.o bundle.o walker.o parse-options.o ws.o coding.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/coding.c b/coding.c
new file mode 100644
index 0000000..63c5dc7
--- /dev/null
+++ b/coding.c
@@ -0,0 +1,62 @@
+#include "coding.h"
+
+unsigned long truncate_euc_jp(char *line, unsigned long len)
+{
+ /*
+ * line contains len bytes but the end of the string could
+ * be incomplete (chomped in the middle of a character).
+ * grab complete lines and count the display width, and
+ * return the number of bytes to chomp at (which could
+ * be smaller than 'len' given, to discard the corrupt
+ * characters at the end
+ */
+ char *ep = line + len;
+ unsigned long sofar = 0;
+
+ while (line < ep) {
+ int ch = (*line++ & 0xFF);
+ int width;
+
+ if (ch < 0x80) {
+ /* JIS X 0201 lower half */
+ sofar++;
+ width = 1;
+ } else if (0xA1 <= ch && ch <= 0xFE) {
+ /* JIS X 0208 */
+ if (ep <= line)
+ goto invalid;
+ ch = (*line++ & 0xFF);
+ if (ch < 0xA1 || 0xFE < ch)
+ goto invalid;
+ width = 2;
+ sofar += 2;
+ } else if (ch == 0x8E) {
+ /* JIS X 0201 upper half */
+ if (ep <= line)
+ goto invalid;
+ ch = (*line++ & 0xFF);
+ if (ch <= 0xA1 || 0xDF < ch)
+ goto invalid;
+ width = 1;
+ sofar += 2;
+ } else if (ch == 0x8F) {
+ /* JIS X 0212 */
+ if (ep <= line)
+ goto invalid;
+ ch = (*line++ & 0xFF);
+ if (ch < 0xA1 || 0xFE < ch)
+ goto invalid;
+ if (ep <= line)
+ goto invalid;
+ ch = (*line++ & 0xFF);
+ if (ch < 0xA1 || 0xFE < ch)
+ goto invalid;
+ width = 2;
+ sofar += 3;
+ } else {
+ invalid:
+ return sofar;
+ }
+ }
+ return sofar;
+}
diff --git a/coding.h b/coding.h
new file mode 100644
index 0000000..0e02701
--- /dev/null
+++ b/coding.h
@@ -0,0 +1,10 @@
+#ifndef CODING_H
+#define CODING_H
+
+#include "cache.h"
+
+typedef unsigned long (*sane_truncate_fn)(char *line, unsigned long len);
+
+unsigned long truncate_euc_jp(char *, unsigned long);
+
+#endif
diff --git a/diff.c b/diff.c
index b9159bc..40c8d2b 100644
--- a/diff.c
+++ b/diff.c
@@ -11,6 +11,7 @@
#include "attr.h"
#include "run-command.h"
#include "utf8.h"
+#include "coding.h"
#ifdef NO_FAST_WORKING_DIRECTORY
#define FAST_WORKING_DIRECTORY 0
@@ -466,8 +467,6 @@ static void diff_words_show(struct diff_words_data *diff_words)
}
}
-typedef unsigned long (*sane_truncate_fn)(char *line, unsigned long len);
-
struct emit_callback {
struct xdiff_emit_state xm;
int nparents, color_diff;
@@ -1125,30 +1124,34 @@ static void emit_binary_diff(mmfile_t *one, mmfile_t *two)
static void setup_diff_attr_check(struct git_attr_check *check)
{
static struct git_attr *attr_diff;
+ static struct git_attr *attr_coding;
if (!attr_diff) {
attr_diff = git_attr("diff", 4);
+ attr_coding = git_attr("coding", 6);
}
check[0].attr = attr_diff;
+ check[1].attr = attr_coding;
}
static void diff_filespec_check_attr(struct diff_filespec *one)
{
- struct git_attr_check attr_diff_check;
+ struct git_attr_check attr_diff_check[2];
int check_from_data = 0;
if (one->checked_attr)
return;
- setup_diff_attr_check(&attr_diff_check);
+ setup_diff_attr_check(attr_diff_check);
one->is_binary = 0;
one->funcname_pattern_ident = NULL;
+ one->coding = NULL;
- if (!git_checkattr(one->path, 1, &attr_diff_check)) {
+ if (!git_checkattr(one->path, 2, attr_diff_check)) {
const char *value;
/* binaryness */
- value = attr_diff_check.value;
+ value = attr_diff_check[0].value;
if (ATTR_TRUE(value))
;
else if (ATTR_FALSE(value))
@@ -1161,6 +1164,15 @@ static void diff_filespec_check_attr(struct diff_filespec *one)
;
else
one->funcname_pattern_ident = value;
+
+ /* coding */
+ value = attr_diff_check[1].value;
+ if (ATTR_TRUE(value) ||
+ ATTR_FALSE(value) ||
+ ATTR_UNSET(value))
+ ;
+ else
+ one->coding = value;
}
if (check_from_data) {
@@ -1233,6 +1245,27 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)
return NULL;
}
+static struct {
+ const char *coding;
+ sane_truncate_fn fn;
+} builtin_truncate_fn[] = {
+ { "euc-jp", truncate_euc_jp },
+ { "utf-8", NULL },
+};
+
+static sane_truncate_fn diff_truncate_line_fn(struct diff_filespec *one)
+{
+ int i;
+
+ diff_filespec_check_attr(one);
+ if (!one->coding)
+ return NULL;
+ for (i = 0; i < ARRAY_SIZE(builtin_truncate_fn); i++)
+ if (!strcmp(one->coding, builtin_truncate_fn[i].coding))
+ return builtin_truncate_fn[i].fn;
+ return NULL;
+}
+
static void builtin_diff(const char *name_a,
const char *name_b,
struct diff_filespec *one,
@@ -1318,6 +1351,9 @@ static void builtin_diff(const char *name_a,
ecbdata.color_diff = DIFF_OPT_TST(o, COLOR_DIFF);
ecbdata.found_changesp = &o->found_changes;
ecbdata.ws_rule = whitespace_rule(name_b ? name_b : name_a);
+ ecbdata.truncate = diff_truncate_line_fn(one);
+ if (!ecbdata.truncate)
+ ecbdata.truncate = diff_truncate_line_fn(two);
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
xecfg.ctxlen = o->context;
xecfg.flags = XDL_EMIT_FUNCNAMES;
diff --git a/diffcore.h b/diffcore.h
index cc96c20..711a4df 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -28,6 +28,7 @@ struct diff_filespec {
void *data;
void *cnt_data;
const char *funcname_pattern_ident;
+ const char *coding; /* blob text coding */
unsigned long size;
int count; /* Reference count */
int xfrm_flags; /* for use by the xfrm */
--
1.5.4.rc2.13.g690bd
^ permalink raw reply related
* [PATCH 2/2] diff: do not chomp hunk-header in the middle of a character
From: Junio C Hamano @ 2008-01-02 9:50 UTC (permalink / raw)
To: Tsugikazu Shibata; +Cc: git
In-Reply-To: <7v1w904x29.fsf@gitster.siamese.dyndns.org>
We truncate hunk-header line at 80 bytes, but that 80th byte
could be in the middle of a character, which is bad. This uses
utf8_width() function to make sure we do not cut a character in
the middle.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* And this implements the sane_truncate_line() that
unconditionally assumes UTF-8.
The 80-byte cutoff is meant to chomp at 80 display columns,
and in many encodings including UTF-8 80 cols are usually
more than 80 bytes. To implement 80 column chomping, we
would need to tweak the low level xdl_find_func() interface
further so that it gives us back more than 80-bytes. Ideally
that layer should not be doing any chomping.
Another thing I noticed but did not bother to fix was that
the emit_line() interface is doing bad things with color.
It emits:
start-color text (= line, len) reset-color
and the text often ends with LF. We should emit reset-color
before the terminating LF instead.
diff.c | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 5bdc111..b9159bc 100644
--- a/diff.c
+++ b/diff.c
@@ -10,6 +10,7 @@
#include "color.h"
#include "attr.h"
#include "run-command.h"
+#include "utf8.h"
#ifdef NO_FAST_WORKING_DIRECTORY
#define FAST_WORKING_DIRECTORY 0
@@ -465,10 +466,13 @@ static void diff_words_show(struct diff_words_data *diff_words)
}
}
+typedef unsigned long (*sane_truncate_fn)(char *line, unsigned long len);
+
struct emit_callback {
struct xdiff_emit_state xm;
int nparents, color_diff;
unsigned ws_rule;
+ sane_truncate_fn truncate;
const char **label_path;
struct diff_words_data *diff_words;
int *found_changesp;
@@ -521,6 +525,27 @@ static void emit_add_line(const char *reset, struct emit_callback *ecbdata, cons
}
}
+static unsigned long sane_truncate_line(struct emit_callback *ecb, char *line, unsigned long len)
+{
+ const char *cp;
+ unsigned long width, allot;
+
+ if (ecb->truncate)
+ return ecb->truncate(line, len);
+ cp = line;
+ width = 0;
+ allot = len;
+ while (0 < len) {
+ int w = utf8_width(&cp, &len);
+ if (!cp)
+ break; /* truncated in the middle? */
+ width += w;
+ if (allot <= width)
+ break;
+ }
+ return allot - len;
+}
+
static void fn_out_consume(void *priv, char *line, unsigned long len)
{
int i;
@@ -551,8 +576,11 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
;
if (2 <= i && i < len && line[i] == ' ') {
ecbdata->nparents = i - 1;
+ len = sane_truncate_line(ecbdata, line, len);
emit_line(diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO),
reset, line, len);
+ if (line[len-1] != '\n')
+ putchar('\n');
return;
}
--
1.5.4.rc2.13.g690bd
^ permalink raw reply related
* [PATCH 1/2] utf8_width(): allow non NUL-terminated input
From: Junio C Hamano @ 2008-01-02 9:49 UTC (permalink / raw)
To: Tsugikazu Shibata; +Cc: git
In-Reply-To: <7v1w904x29.fsf@gitster.siamese.dyndns.org>
The original interface assumed that the input string to be
always terminated with NUL, but that wasn't too useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is a preparatory step for the next one that follows what
I outlined in my response. As we are in pre-1.5.4 freeze, I
won't be applying this to 'master' but this and the one that
implements the sane truncation might be 'next' material.
utf8.c | 68 ++++++++++++++++++++++++++++++++++++++-------------------------
utf8.h | 2 +-
2 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/utf8.c b/utf8.c
index 9efcdb9..5d641fa 100644
--- a/utf8.c
+++ b/utf8.c
@@ -157,57 +157,71 @@ static int git_wcwidth(ucs_char_t ch)
* pointed to by the variable start. The pointer is updated to point at
* the next character. If it was not valid UTF-8, the pointer is set to NULL.
*/
-int utf8_width(const char **start)
+int utf8_width(const char **start, size_t *remainder_p)
{
unsigned char *s = (unsigned char *)*start;
ucs_char_t ch;
+ size_t remainder, incr;
- if (*s < 0x80) {
+ /*
+ * A caller that assumes NUL terminated text can choose
+ * not to bother with the remainder length.
+ */
+ remainder = (remainder_p ? *remainder_p : 999);
+
+ if (remainder < 1) {
+ goto invalid;
+ } else if (*s < 0x80) {
/* 0xxxxxxx */
ch = *s;
- *start += 1;
+ incr = 1;
} else if ((s[0] & 0xe0) == 0xc0) {
/* 110XXXXx 10xxxxxx */
- if ((s[1] & 0xc0) != 0x80 ||
- /* overlong? */
- (s[0] & 0xfe) == 0xc0)
+ if (remainder < 2 ||
+ (s[1] & 0xc0) != 0x80 ||
+ (s[0] & 0xfe) == 0xc0)
goto invalid;
ch = ((s[0] & 0x1f) << 6) | (s[1] & 0x3f);
- *start += 2;
+ incr = 2;
} else if ((s[0] & 0xf0) == 0xe0) {
/* 1110XXXX 10Xxxxxx 10xxxxxx */
- if ((s[1] & 0xc0) != 0x80 ||
- (s[2] & 0xc0) != 0x80 ||
- /* overlong? */
- (s[0] == 0xe0 && (s[1] & 0xe0) == 0x80) ||
- /* surrogate? */
- (s[0] == 0xed && (s[1] & 0xe0) == 0xa0) ||
- /* U+FFFE or U+FFFF? */
- (s[0] == 0xef && s[1] == 0xbf &&
- (s[2] & 0xfe) == 0xbe))
+ if (remainder < 3 ||
+ (s[1] & 0xc0) != 0x80 ||
+ (s[2] & 0xc0) != 0x80 ||
+ /* overlong? */
+ (s[0] == 0xe0 && (s[1] & 0xe0) == 0x80) ||
+ /* surrogate? */
+ (s[0] == 0xed && (s[1] & 0xe0) == 0xa0) ||
+ /* U+FFFE or U+FFFF? */
+ (s[0] == 0xef && s[1] == 0xbf &&
+ (s[2] & 0xfe) == 0xbe))
goto invalid;
ch = ((s[0] & 0x0f) << 12) |
((s[1] & 0x3f) << 6) | (s[2] & 0x3f);
- *start += 3;
+ incr = 3;
} else if ((s[0] & 0xf8) == 0xf0) {
/* 11110XXX 10XXxxxx 10xxxxxx 10xxxxxx */
- if ((s[1] & 0xc0) != 0x80 ||
- (s[2] & 0xc0) != 0x80 ||
- (s[3] & 0xc0) != 0x80 ||
- /* overlong? */
- (s[0] == 0xf0 && (s[1] & 0xf0) == 0x80) ||
- /* > U+10FFFF? */
- (s[0] == 0xf4 && s[1] > 0x8f) || s[0] > 0xf4)
+ if (remainder < 4 ||
+ (s[1] & 0xc0) != 0x80 ||
+ (s[2] & 0xc0) != 0x80 ||
+ (s[3] & 0xc0) != 0x80 ||
+ /* overlong? */
+ (s[0] == 0xf0 && (s[1] & 0xf0) == 0x80) ||
+ /* > U+10FFFF? */
+ (s[0] == 0xf4 && s[1] > 0x8f) || s[0] > 0xf4)
goto invalid;
ch = ((s[0] & 0x07) << 18) | ((s[1] & 0x3f) << 12) |
((s[2] & 0x3f) << 6) | (s[3] & 0x3f);
- *start += 4;
+ incr = 4;
} else {
invalid:
*start = NULL;
return 0;
}
+ *start += incr;
+ if (remainder_p)
+ *remainder_p = remainder - incr;
return git_wcwidth(ch);
}
@@ -218,7 +232,7 @@ int is_utf8(const char *text)
text++;
continue;
}
- utf8_width(&text);
+ utf8_width(&text, NULL);
if (!text)
return 0;
}
@@ -278,7 +292,7 @@ int print_wrapped_text(const char *text, int indent, int indent2, int width)
continue;
}
if (assume_utf8)
- w += utf8_width(&text);
+ w += utf8_width(&text, NULL);
else {
w++;
text++;
diff --git a/utf8.h b/utf8.h
index 15db6f1..4295a19 100644
--- a/utf8.h
+++ b/utf8.h
@@ -1,7 +1,7 @@
#ifndef GIT_UTF8_H
#define GIT_UTF8_H
-int utf8_width(const char **start);
+int utf8_width(const char **start, size_t *remain);
int is_utf8(const char *text);
int is_encoding_utf8(const char *name);
--
1.5.4.rc2.13.g690bd
^ permalink raw reply related
* Re: Git and securing a repository
From: Gonzalo Garramuño @ 2008-01-02 10:39 UTC (permalink / raw)
To: David Symonds, git
In-Reply-To: <ee77f5c20801020126n1776d625ya6928c2e4bfdf497@mail.gmail.com>
David Symonds wrote:
>
> You can do arbitrarily-fine-grained authentication via the pre-receive hook.
>
Can you provide some more info? Looking at the kernel.org git docs, the
pre-receive hook seems very limited as no parameters are allowed. So
I'm not sure how an authentication system could be created.
It also seems to be a push hook only (not invoked on pulls).
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
^ permalink raw reply
* Re: Git and securing a repository
From: David Symonds @ 2008-01-02 9:26 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: Felipe Balbi, git
In-Reply-To: <477B6199.6070601@advancedsl.com.ar>
On Jan 2, 2008 9:04 PM, Gonzalo Garramuño <ggarra@advancedsl.com.ar> wrote:
> Felipe Balbi wrote:
> >
> > it's easy on the full repository case, create different groups and
> > share git repositories by groups, after that chmod o-rwx -R
> > /path/to/repository.git.
> >
>
> Thanks. I'll admit what you describe is somewhat discouraging, as what
> you are just describing is just managing user accounts or groups on the
> underlying OS. That does not extend well to placing code on the net and
> has a bunch of administrative headaches.
>
> I was really looking for a permission based system that was part of git
> itself (and thus more portable and easier to admin), and not the OS.
> Something akin to what perforce or even CVS can do.
You can do arbitrarily-fine-grained authentication via the pre-receive hook.
Dave.
^ permalink raw reply
* Re: Git and securing a repository
From: Gonzalo Garramuño @ 2008-01-02 10:04 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Gonzalo Garramuño, git
In-Reply-To: <31e679430801012234x20bbebe7vb496a338bf2699d5@mail.gmail.com>
Felipe Balbi wrote:
>
> it's easy on the full repository case, create different groups and
> share git repositories by groups, after that chmod o-rwx -R
> /path/to/repository.git.
>
Thanks. I'll admit what you describe is somewhat discouraging, as what
you are just describing is just managing user accounts or groups on the
underlying OS. That does not extend well to placing code on the net and
has a bunch of administrative headaches.
I was really looking for a permission based system that was part of git
itself (and thus more portable and easier to admin), and not the OS.
Something akin to what perforce or even CVS can do.
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
^ permalink raw reply
* Re: input validation in receive-pack
From: Junio C Hamano @ 2008-01-02 8:01 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <20080102075152.GA24401@auto.tuwien.ac.at>
mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
> Are there more refs outside "refs/", which somebody would want to push to?
As anything outside refs/ and not HEAD are subject to gc, I do
not think it should even be allowed.
But this is, as everybody should be aware, very late in 1.5.4
cycle, so I'd rather avoid bahviour change to tighten things
before post-1.5.4 opens.
^ permalink raw reply
* Re: input validation in receive-pack
From: Martin Koegler @ 2008-01-02 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlvp3oya.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 01, 2008 at 07:07:25PM -0800, Junio C Hamano wrote:
> mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
> > Some lines above:
> > | if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
> > | error("refusing to create funny ref '%s' remotely", name);
> > | return "funny refname";
> > | }
> >
> > Is this code really correct?
>
> Interesting. Things have been this way forever, I think. I do
> not offhand see any reason not to refuse refs outside refs/, so
> you can try
>
> if (prefixcmp(name, "refs/") || check_ref_format(name + 5))
>
> and see what happens.
I tried this and it passed the test suite.
> Some people may however want to push to
> HEAD (that is ".git/HEAD" which is outside ".git/refs"), though.
If pushing to HEAD is allowed, it bypasses the fast-forward check.
As minimum,
if (check_ref_format(name))
should be safer, as it rejects totally invalid refnames (especially ../[...]).
Are there more refs outside "refs/", which somebody would want to push to?
If not, the following patch could work:
if (!strcmp(name, "HEAD") &&
(prefixcmp(name, "refs/") || check_ref_format(name+5))) {
[..error..]
}
if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
!is_null_sha1(old_sha1) &&
(!prefixcmp(name, "refs/heads/")||!strcmp(name, "HEAD")) {
[...]
}
mfg Martin Kögler
^ permalink raw reply
* [PATCH] receive-pack: check object type of sha1 before using them as commits
From: Martin Koegler @ 2008-01-02 7:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
receive-pack.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/receive-pack.c b/receive-pack.c
index fba4cf8..d0a563d 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -178,11 +178,21 @@ static const char *update(struct command *cmd)
if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
!is_null_sha1(old_sha1) &&
!prefixcmp(name, "refs/heads/")) {
+ struct object *old_object, *new_object;
struct commit *old_commit, *new_commit;
struct commit_list *bases, *ent;
- old_commit = (struct commit *)parse_object(old_sha1);
- new_commit = (struct commit *)parse_object(new_sha1);
+ old_object = parse_object(old_sha1);
+ new_object = parse_object(new_sha1);
+
+ if (!old_object || !new_object ||
+ old_object->type != OBJ_COMMIT ||
+ new_object->type != OBJ_COMMIT) {
+ error("bad sha1 objects for %s", name);
+ return "bad ref";
+ }
+ old_commit = (struct commit *)old_object;
+ new_commit = (struct commit *)new_object;
bases = get_merge_bases(old_commit, new_commit, 1);
for (ent = bases; ent; ent = ent->next)
if (!hashcmp(old_sha1, ent->item->object.sha1))
--
1.4.4.4
^ permalink raw reply related
* Re: Git and securing a repository
From: Felipe Balbi @ 2008-01-02 6:34 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <477B39B5.5010107@advancedsl.com.ar>
On Jan 2, 2008 2:13 AM, Gonzalo Garramuño <ggarra@advancedsl.com.ar> wrote:
>
> I've been using git for some time and love it. For open source projects
> there's clearly nothing currently better.
>
> However, I am now using git for proprietary elements, which in the
> future I may need or want to partially restrict access to. The idea
> being that at my company some (junior) developers should not be given
> access to some elements. That means either that some full git
> repository should be password protected or even portions of the same
> repository.
>
> Another desirable way to protect elements might be only giving
> clone/pull access to a repository (or portion of it) but not permissions
> to push in changes.
push access is only available through ssh, so if your developer
doesn't have a ssh account on the server, he can't push code to it
>
> I have not seen or read much about how git deals with accesses and
> permissions. Can anyone point me to some documentation if some or all
> of this is possible?
it's easy on the full repository case, create different groups and
share git repositories by groups, after that chmod o-rwx -R
/path/to/repository.git.
If a user is not the owner nor is part of that group in particular, it
wouldn't be able to push any code to the repository.
btw, if you don't start git-daemon you could use ssh to pull code as well.
thinking on the partial repository access, maybe git submodule would
help, but i've never used it.
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Git and securing a repository
From: Gonzalo Garramuño @ 2008-01-02 7:13 UTC (permalink / raw)
To: git
I've been using git for some time and love it. For open source projects
there's clearly nothing currently better.
However, I am now using git for proprietary elements, which in the
future I may need or want to partially restrict access to. The idea
being that at my company some (junior) developers should not be given
access to some elements. That means either that some full git
repository should be password protected or even portions of the same
repository.
Another desirable way to protect elements might be only giving
clone/pull access to a repository (or portion of it) but not permissions
to push in changes.
I have not seen or read much about how git deals with accesses and
permissions. Can anyone point me to some documentation if some or all
of this is possible?
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
^ permalink raw reply
* Re: [PATCH] Remove duplication in t9119-git-svn-info.sh
From: Junio C Hamano @ 2008-01-02 5:57 UTC (permalink / raw)
To: Eric Wong; +Cc: David D. Kilzer, git
In-Reply-To: <20080102034317.GB11711@untitled>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "David D. Kilzer" <ddkilzer@kilzer.net> writes:
>>
>> > @@ -350,8 +355,8 @@ test_expect_success 'info unknown-symlink-directory' "
>> > cd svnwc &&
>> > ln -s unknown-directory unknown-symlink-directory &&
>> > cd .. &&
>> > - ptouch gitwc/unknown-symlink-directory \
>> > - svnwc/unknown-symlink-directory &&
>> > + ptouch svnwc/unknown-symlink-directory \
>> > + gitwc/unknown-symlink-directory &&
>>
>> Hmph. Am I the only one who finds this repetition somewhat
>> disturbing?
>
> "David D. Kilzer" <ddkilzer@kilzer.net> wrote:
>> Simplify arguments to ptouch bash function.
>
> Not reading Junio's mind, I think he meant that you were swapping the
> "gitwc/" and "svnwc/" args everywhere in your changeset.
Yeah, that was what I meant. ptouch routine's implementation
could have swapped the order of arguments internally.
The follow-up patch by David makes ptouch routine unusable if
the test suite becomes more elaborate and starts using more than
one git and svn work trees, but I do not think that is something
we have to worry about too much.
^ permalink raw reply
* Re: input validation in receive-pack
From: Junio C Hamano @ 2008-01-02 5:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Martin Koegler, git, Johannes Schindelin
In-Reply-To: <alpine.LNX.1.00.0801012353580.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 1 Jan 2008, Junio C Hamano wrote:
>
>> mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
>>
>> > In the update code path, the check is done in refs.c:
>> > | struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
>> > | {
>> > | if (check_ref_format(ref) == -1)
>> > | return NULL;
>> > | return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
>> > | }
>> >
>> > check_ref_format may also return -2 (less than two name levels) and -3
>> > (* at the end), which are ignored. Is it really intended, that
>> > receive-pack can create such refs.
>>
>> Misconversion in 8558fd9ece4c8250a037a6d5482a8040d600ef47 that
>> changed check_ref_format() without looking at what its callers
>> are checking, I think.
>
> When I got to it, it was already accepting -2. It clearly shouldn't accept
> -3 (and I don't know why I missed it; I was probably misinterpreting the
> original logic there.
You are right.
builtin-commit.c uses it to lock "HEAD", and update_ref() calls
it to update any ref so we cannot reject -2. However, I do not
think allowing wildcard is useful for any caller.
-- >8 --
lock_any_ref_for_update(): reject wildcard return from check_ref_format
Recent check_ref_format() returns -3 as well as -1 (general
error) and -2 (less than two levels). The caller was explicitly
checking for -1, to allow "HEAD" but still disallow bogus refs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
refs.c | 27 ++++++++++++++++++---------
refs.h | 5 ++++-
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index 759924d..7484a46 100644
--- a/refs.c
+++ b/refs.c
@@ -613,32 +613,37 @@ int check_ref_format(const char *ref)
while ((ch = *cp++) == '/')
; /* tolerate duplicated slashes */
if (!ch)
- return -1; /* should not end with slashes */
+ /* should not end with slashes */
+ return CHECK_REF_FORMAT_ERROR;
/* we are at the beginning of the path component */
if (ch == '.')
- return -1;
+ return CHECK_REF_FORMAT_ERROR;
bad_type = bad_ref_char(ch);
if (bad_type) {
- return (bad_type == 2 && !*cp) ? -3 : -1;
+ return (bad_type == 2 && !*cp)
+ ? CHECK_REF_FORMAT_WILDCARD
+ : CHECK_REF_FORMAT_ERROR;
}
/* scan the rest of the path component */
while ((ch = *cp++) != 0) {
bad_type = bad_ref_char(ch);
if (bad_type) {
- return (bad_type == 2 && !*cp) ? -3 : -1;
+ return (bad_type == 2 && !*cp)
+ ? CHECK_REF_FORMAT_WILDCARD
+ : CHECK_REF_FORMAT_ERROR;
}
if (ch == '/')
break;
if (ch == '.' && *cp == '.')
- return -1;
+ return CHECK_REF_FORMAT_ERROR;
}
level++;
if (!ch) {
if (level < 2)
- return -2; /* at least of form "heads/blah" */
- return 0;
+ return CHECK_REF_FORMAT_ONELEVEL;
+ return CHECK_REF_FORMAT_OK;
}
}
}
@@ -816,9 +821,13 @@ struct ref_lock *lock_ref_sha1(const char *ref, const unsigned char *old_sha1)
struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
{
- if (check_ref_format(ref) == -1)
+ switch (check_ref_format(ref)) {
+ case CHECK_REF_FORMAT_ERROR:
+ case CHECK_REF_FORMAT_WILDCARD:
return NULL;
- return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
+ default:
+ return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
+ }
}
static struct lock_file packlock;
diff --git a/refs.h b/refs.h
index 9dc8aa0..9cd16f8 100644
--- a/refs.h
+++ b/refs.h
@@ -52,7 +52,10 @@ int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data);
*/
extern int for_each_reflog(each_ref_fn, void *);
-/** Returns 0 if target has the right format for a ref. **/
+#define CHECK_REF_FORMAT_OK 0
+#define CHECK_REF_FORMAT_ERROR (-1)
+#define CHECK_REF_FORMAT_ONELEVEL (-2)
+#define CHECK_REF_FORMAT_WILDCARD (-3)
extern int check_ref_format(const char *target);
/** rename ref, return 0 on success **/
^ permalink raw reply related
* Re: [RFC/PATCH] fix "git diff" to create wrong UTF-8 text
From: Junio C Hamano @ 2008-01-02 5:26 UTC (permalink / raw)
To: Tsugikazu Shibata; +Cc: git
In-Reply-To: <20080102.082014.02281301.tshibata@ab.jp.nec.com>
Tsugikazu Shibata <tshibata@ab.jp.nec.com> writes:
> I believe this should be work for another language using UTF-8 and
> solve this issue.
> ...
> @@ -368,6 +394,7 @@ int xdl_emit_hunk_hdr(long s1, long c1,
> buf[nb++] = ' ';
> if (funclen > sizeof(buf) - nb - 1)
> funclen = sizeof(buf) - nb - 1;
> + funclen = utf8width(func, funclen);
> memcpy(buf + nb, func, funclen);
> nb += funclen;
> }
I'd rather not do this in xdiff/ level for two reasons.
We consider the functions there strictly "borrowed code", and
ideally I'd rather even not to have that "chop down to funclen"
logic at that level.
The code at that level does not know what paths it is dealing
with and cannot consult git specific data (i.e. attributes); it
would make it harder to enhance it later by introducing per-path
encoding information.
How about...
* (optional) lift the funclen limit from xdl_emit_hunk_hdr()
and xdl_emit_diff() and have them preserve the full line;
* Around ll.554 in diff.c::fn_out_consume(), look at
line[i..eol] and apply the "chomp between character" logic
there. I think it is very sensible to use the UTF-8 logic by
default as you did above (but I suspect you may be able to
reuse helper functions in utf8.c such as git_wcwidth(),
instead of rolling your own). Chomp the funcname line given
from xdiff layer in this function.
* (future) make the length of the funcname line configurable
either from the command line or configuration.
* (future) add per-path blob encoding information (default to
UTF-8) to struct emit_callback, and initialize it from the
gitattributes(5) mechanism, just like we have added ws_rule
recently there. Use that to decide how inter-character chomp
works to customize the logic in diff.c::fn_out_consume() you
would introduce above.
I think the two future enhancements I listed above as examples
would be cleaner to implement if the line chomping is done in
fn_out_consume().
^ permalink raw reply
* Re: input validation in receive-pack
From: Daniel Barkalow @ 2008-01-02 5:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Koegler, git, Johannes Schindelin
In-Reply-To: <7vzlvp3oya.fsf@gitster.siamese.dyndns.org>
On Tue, 1 Jan 2008, Junio C Hamano wrote:
> mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
>
> > In the update code path, the check is done in refs.c:
> > | struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
> > | {
> > | if (check_ref_format(ref) == -1)
> > | return NULL;
> > | return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
> > | }
> >
> > check_ref_format may also return -2 (less than two name levels) and -3
> > (* at the end), which are ignored. Is it really intended, that
> > receive-pack can create such refs.
>
> Misconversion in 8558fd9ece4c8250a037a6d5482a8040d600ef47 that
> changed check_ref_format() without looking at what its callers
> are checking, I think.
When I got to it, it was already accepting -2. It clearly shouldn't accept
-3 (and I don't know why I missed it; I was probably misinterpreting the
original logic there.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Remove duplication in t9119-git-svn-info.sh
From: David D. Kilzer @ 2008-01-02 3:54 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20080102034317.GB11711@untitled>
Eric Wong <normalperson@yhbt.net> wrote:
> Not reading Junio's mind, I think he meant that you were swapping the
> "gitwc/" and "svnwc/" args everywhere in your changeset.
I did not switch them everywhere. The original patch to fix the race condition
required switching the arguments because I had to treat the svnwc path
differently than the gitwc path.
> Nevertheless, does your change make things work with older
> versions of SVN? I'm running 1.4.x everywhere these days, but
> I seem to recall the version of SVN on kernel.org was giving
> Junio trouble with the tests.
Was it the "race condition" he was seeing, where the tests were failing because
of a difference in one second between the svn output and the git output? If
so, that was fixed with the first patch. I was able to reproduce the race
condition locally with svn-1.4.5 on my PowerBook G4.
I don't have an easy way to test with svn-1.3.
Dave
^ permalink raw reply
* Re: [PATCH] Remove duplication in t9119-git-svn-info.sh
From: Eric Wong @ 2008-01-02 3:43 UTC (permalink / raw)
To: David D. Kilzer; +Cc: Junio C Hamano, git
In-Reply-To: <1199143999-6859-1-git-send-email-ddkilzer@kilzer.net>
Junio C Hamano <gitster@pobox.com> wrote:
> "David D. Kilzer" <ddkilzer@kilzer.net> writes:
>
> > @@ -350,8 +355,8 @@ test_expect_success 'info unknown-symlink-directory' "
> > cd svnwc &&
> > ln -s unknown-directory unknown-symlink-directory &&
> > cd .. &&
> > - ptouch gitwc/unknown-symlink-directory \
> > - svnwc/unknown-symlink-directory &&
> > + ptouch svnwc/unknown-symlink-directory \
> > + gitwc/unknown-symlink-directory &&
>
> Hmph. Am I the only one who finds this repetition somewhat
> disturbing?
"David D. Kilzer" <ddkilzer@kilzer.net> wrote:
> Simplify arguments to ptouch bash function.
Not reading Junio's mind, I think he meant that you were swapping the
"gitwc/" and "svnwc/" args everywhere in your changeset.
Nevertheless, does your change make things work with older
versions of SVN? I'm running 1.4.x everywhere these days, but
I seem to recall the version of SVN on kernel.org was giving
Junio trouble with the tests.
--
Eric Wong
^ permalink raw reply
* Re: Commit a series of patches to SVN without rebase
From: Eric Wong @ 2008-01-02 3:11 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git
In-Reply-To: <slrnfmttoo.28m.joerg@alea.gnuu.de>
Jörg Sommer <joerg@alea.gnuu.de> wrote:
> Hi Eric,
>
> Eric Wong <normalperson@yhbt.net> wrote:
> > Jörg Sommer <joerg@alea.gnuu.de> wrote:
> >> I've a number of patches in git I want to send to a SVN repository. git
> >> svn dcommit does a rebase after each commit which makes the whole commit
> >> takes very long. Is it possible to skip the rebase? All patches are in
> >> one branch without merges, a simple chain. Is it save to use --no-rebase
> >> in this case?
> >
> > Right now, only if the changes don't depend on each other (they all
> > modify different files).
>
> May I ask you what the rational behind doing a rebase every time is? Is
> it needed? Why is it not possible to send all commits and do one rebase
> after the last one?
Rebase is done to alert the user of potential conflicts before
attempting to commit them to a remote repository. Formerly it was
done to prevent potential clobbering of upstream changes if
there were conflicts, but I think that's been rectified in recent
months.
--
Eric Wong
^ permalink raw reply
* Re: input validation in receive-pack
From: Junio C Hamano @ 2008-01-02 3:07 UTC (permalink / raw)
To: Martin Koegler; +Cc: git, Johannes Schindelin, Daniel Barkalow
In-Reply-To: <20080101213451.GA26772@auto.tuwien.ac.at>
mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
> In the function "static const char *update(struct command *cmd)" in
> receive-pack.c:
>
> | if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
> | !is_null_sha1(old_sha1) &&
> | !prefixcmp(name, "refs/heads/")) {
> | struct commit *old_commit, *new_commit;
> | struct commit_list *bases, *ent;
> |
> | old_commit = (struct commit *)parse_object(old_sha1);
> | new_commit = (struct commit *)parse_object(new_sha1);
> | bases = get_merge_bases(old_commit, new_commit, 1);
> | for (ent = bases; ent; ent = ent->next)
> | if (!hashcmp(old_sha1, ent->item->object.sha1))
> | break;
> | free_commit_list(bases);
> | if (!ent) {
> | error("denying non-fast forward %s"
> | " (you should pull first)", name);
> | return "non-fast forward";
> | }
> | }
>
> As far as I understand the code, it assumes, that sha1 values provided
> by the client really point to a commit. Shouldn't there be a check for
> the object type?
Yes, 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57 seems to have been
a bit sloppy. The codepath to delete a ref may need to be lax
(see 28391a80a94d2b59d1d21f8264fe5dab91d77249) but there is no
excuse not to be strict when updating.
> Some lines above:
> | if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
> | error("refusing to create funny ref '%s' remotely", name);
> | return "funny refname";
> | }
>
> Is this code really correct?
Interesting. Things have been this way forever, I think. I do
not offhand see any reason not to refuse refs outside refs/, so
you can try
if (prefixcmp(name, "refs/") || check_ref_format(name + 5))
and see what happens. Some people may however want to push to
HEAD (that is ".git/HEAD" which is outside ".git/refs"), though.
> In the update code path, the check is done in refs.c:
> | struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
> | {
> | if (check_ref_format(ref) == -1)
> | return NULL;
> | return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
> | }
>
> check_ref_format may also return -2 (less than two name levels) and -3
> (* at the end), which are ignored. Is it really intended, that
> receive-pack can create such refs.
Misconversion in 8558fd9ece4c8250a037a6d5482a8040d600ef47 that
changed check_ref_format() without looking at what its callers
are checking, I think.
^ permalink raw reply
* Re: [PATCH] Let transport.c use git without a dash
From: Junio C Hamano @ 2008-01-02 2:31 UTC (permalink / raw)
To: Pieter de Bie; +Cc: git
In-Reply-To: <1199216375-22161-1-git-send-email-pdebie@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> This fixes transport.c by using "git upload-pack" and "git receive pack".
> Using the old dashed form, git fetch would fail on a remote installation where
> the git binaries are installed in a separate dir
> ---
>
> I think this might have been on the list before, but then it was never applied
> to master. git fetch fails when you have used make gitexecdir=/somewhereelse
> on the remote side, as it can't find git-upload-pack.
Two questions.
(1) There has long been a support for specifying where your
out-of-PATH receive-pack and upload-pack are to be found.
Is it inadequate, and if so why?
(2) data->receivepack is copied to args.receivepack in
git_transport_push() and then eventually given as prog
parameter to git_connect(), which is sent to the shell on
the other end. If the git restricted shell is in use, that
is compared to the list of commands shell.c::cmd_list[];
and separating "git-receive-pack" into two words like your
patch would break it, I suspect. Have you tested this
codepath?
In the longer term (definitely before 1.6.0), we should rethink
the way --receive-pack (given to "git push") and --upload-pack
(given to "git fetch") options are handled. We are heading
towards "a single git binary to rule them all", so it might make
sense to deprecate these two options and instead have the caller
specify the path to "git" itself (which in turn knows how to
invoke receive-pack and upload-pack subcommands).
^ permalink raw reply
* [RFC/PATCH] fix "git diff" to create wrong UTF-8 text
From: Tsugikazu Shibata @ 2008-01-01 23:20 UTC (permalink / raw)
To: git; +Cc: tshibata
Hello,
I met a problem in patch text from "git diff" for UTF-8 text.
Patch text following to "@@" sometimes cut the string with max
80bytes. In case of UTF-8 text written in Japanese and English, most
of Japanese character are consist of 3 bytes for a character and also
ASCII character is single byte.
So, cut the string with 80bytes may cause cut off 1 or 2 byte for a
character at the bottom. This will cause the broken code of result of
"git diff".
It seems no problem to read such patch text for the patch command but
the problem is not readable for me. ie. Emacs cannot handle the
encoding for such file and show me octal numbers.
The patch below is my quick and dirty solution (but It works fine !)
I tested this patch with using Linux kernel document
(Documentation/ja_JP/HOWTO)
I believe this should be work for another language using UTF-8 and
solve this issue.
Please note that this is focused only for UTF-8 but we may need to
support another encoding.
So, How can we turn on this UTF-8 processing?
Any suggestions are welcome.
Thanks,
Sigined-off-by: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
---
diff -upr git-1.5.3.7/xdiff/xutils.c git-1.5.3.7-dev/xdiff/xutils.c
--- git-1.5.3.7/xdiff/xutils.c 2007-12-02 06:21:12.000000000 +0900
+++ git-1.5.3.7-dev/xdiff/xutils.c 2007-12-31 01:30:51.000000000 +0900
@@ -332,6 +332,32 @@ long xdl_atol(char const *str, char cons
}
+/* return utf character size of bytes */
+int utf8charsize(const unsigned char c) {
+ int l;
+ if ( c < 0x7f ) l = 1;
+ else if (( c > 0xc0) && ( c < 0xdf)) l=2;
+ else if (( c > 0xe0) && ( c < 0xef)) l=3;
+ else if (( c > 0xf0) && ( c < 0xf7)) l=4;
+ else if (( c > 0xf8) && ( c < 0xfb)) l=5;
+ else if (( c > 0xfc) && ( c < 0xfd)) l=6;
+ else l=1; /* fale safe */
+ return l;
+}
+
+int utf8width(const char *up, int len) {
+ int cs;
+ int l=len;
+ const char *p = up;
+ while ((l > 0) && (p[0] != '\0')) {
+ cs = utf8charsize(p[0]);
+ if (l >= cs) {
+ l -= cs; p += cs;
+ } else l=0; /* do not split multi byte char. */
+ }
+ return p-up;
+}
+
int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2,
const char *func, long funclen, xdemitcb_t *ecb) {
int nb = 0;
@@ -368,6 +394,7 @@ int xdl_emit_hunk_hdr(long s1, long c1,
buf[nb++] = ' ';
if (funclen > sizeof(buf) - nb - 1)
funclen = sizeof(buf) - nb - 1;
+ funclen = utf8width(func, funclen);
memcpy(buf + nb, func, funclen);
nb += funclen;
}
^ permalink raw reply
* etckeeper, metastore and mr
From: Martin Langhoff @ 2008-01-01 22:56 UTC (permalink / raw)
To: Git Mailing List
reading planet debian, I found that Joey Hess has written a couple of
git-based tools, and one of them seems to address the "how to keep my
etc with git" fairly well. The readme is educational too. Thought it'd
be worth mentioning them
etckeeper
http://kitenet.net/~joey/code/etckeeper/
etckeeper uses metastore, which sounds useful too
as a pre-commit-hook
http://david.hardeman.nu/software.php
mr - for your cross-SCM projects
http://kitenet.net/~joey/code/mr/
adding them to the git wiki too ;-) -- with a bit of luck, this will
kill the next "how do I store etc with git" flamefest...
happy new year!
m
^ 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