* [PATCH] New strbuf APIs: splice and attach.
From: Pierre Habouzit @ 2007-09-15 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070916172134.GA26457@artemis.corp>
* strbuf_splice replace a portion of the buffer with another.
* strbuf_attach replace a strbuf buffer with the given one, that should be
malloc'ed. Then it enforces strbuf's invariants. If alloc > len, then this
function has negligible cost, else it will perform a realloc, possibly
with a cost.
Also some style issues are fixed now.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
strbuf.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++-------------
strbuf.h | 5 ++++
2 files changed, 57 insertions(+), 15 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index d919047..ff551ac 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -1,30 +1,45 @@
#include "cache.h"
#include "strbuf.h"
-void strbuf_init(struct strbuf *sb, size_t hint) {
+void strbuf_init(struct strbuf *sb, size_t hint)
+{
memset(sb, 0, sizeof(*sb));
if (hint)
strbuf_grow(sb, hint);
}
-void strbuf_release(struct strbuf *sb) {
+void strbuf_release(struct strbuf *sb)
+{
free(sb->buf);
memset(sb, 0, sizeof(*sb));
}
-void strbuf_reset(struct strbuf *sb) {
+void strbuf_reset(struct strbuf *sb)
+{
if (sb->len)
strbuf_setlen(sb, 0);
sb->eof = 0;
}
-char *strbuf_detach(struct strbuf *sb) {
+char *strbuf_detach(struct strbuf *sb)
+{
char *res = sb->buf;
strbuf_init(sb, 0);
return res;
}
-void strbuf_grow(struct strbuf *sb, size_t extra) {
+void strbuf_attach(struct strbuf *sb, void *buf, size_t len, size_t alloc)
+{
+ strbuf_release(sb);
+ sb->buf = buf;
+ sb->len = len;
+ sb->alloc = alloc;
+ strbuf_grow(sb, 0);
+ sb->buf[sb->len] = '\0';
+}
+
+void strbuf_grow(struct strbuf *sb, size_t extra)
+{
if (sb->len + extra + 1 <= sb->len)
die("you want to use way too much memory");
ALLOC_GROW(sb->buf, sb->len + extra + 1, sb->alloc);
@@ -37,24 +52,44 @@ void strbuf_rtrim(struct strbuf *sb)
sb->buf[sb->len] = '\0';
}
-void strbuf_insert(struct strbuf *sb, size_t pos, const void *data, size_t len) {
+void strbuf_insert(struct strbuf *sb, size_t pos, const void *data, size_t len)
+{
strbuf_grow(sb, len);
- if (pos >= sb->len) {
- pos = sb->len;
- } else {
- memmove(sb->buf + pos + len, sb->buf + pos, sb->len - pos);
- }
+ if (pos > sb->len)
+ die("`pos' is too far after the end of the buffer");
+ memmove(sb->buf + pos + len, sb->buf + pos, sb->len - pos);
memcpy(sb->buf + pos, data, len);
strbuf_setlen(sb, sb->len + len);
}
-void strbuf_add(struct strbuf *sb, const void *data, size_t len) {
+void strbuf_splice(struct strbuf *sb, size_t pos, size_t len,
+ const void *data, size_t dlen)
+{
+ if (pos + len < pos)
+ die("you want to use way too much memory");
+ if (pos > sb->len)
+ die("`pos' is too far after the end of the buffer");
+ if (pos + len > sb->len)
+ die("`pos + len' is too far after the end of the buffer");
+
+ if (dlen >= len)
+ strbuf_grow(sb, dlen - len);
+ memmove(sb->buf + pos + dlen,
+ sb->buf + pos + len,
+ sb->len - pos - len);
+ memcpy(sb->buf + pos, data, dlen);
+ strbuf_setlen(sb, sb->len + dlen - len);
+}
+
+void strbuf_add(struct strbuf *sb, const void *data, size_t len)
+{
strbuf_grow(sb, len);
memcpy(sb->buf + sb->len, data, len);
strbuf_setlen(sb, sb->len + len);
}
-void strbuf_addf(struct strbuf *sb, const char *fmt, ...) {
+void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
+{
int len;
va_list ap;
@@ -76,7 +111,8 @@ void strbuf_addf(struct strbuf *sb, const char *fmt, ...) {
strbuf_setlen(sb, sb->len + len);
}
-size_t strbuf_fread(struct strbuf *sb, size_t size, FILE *f) {
+size_t strbuf_fread(struct strbuf *sb, size_t size, FILE *f)
+{
size_t res;
strbuf_grow(sb, size);
@@ -110,7 +146,8 @@ ssize_t strbuf_read(struct strbuf *sb, int fd, size_t hint)
return sb->len - oldlen;
}
-void read_line(struct strbuf *sb, FILE *fp, int term) {
+void read_line(struct strbuf *sb, FILE *fp, int term)
+{
int ch;
if (feof(fp)) {
strbuf_release(sb);
diff --git a/strbuf.h b/strbuf.h
index 21fc111..f163c63 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -55,6 +55,7 @@ extern void strbuf_init(struct strbuf *, size_t);
extern void strbuf_release(struct strbuf *);
extern void strbuf_reset(struct strbuf *);
extern char *strbuf_detach(struct strbuf *);
+extern void strbuf_attach(struct strbuf *, void *, size_t, size_t);
/*----- strbuf size related -----*/
static inline size_t strbuf_avail(struct strbuf *sb) {
@@ -81,6 +82,10 @@ static inline void strbuf_addch(struct strbuf *sb, int c) {
/* inserts after pos, or appends if pos >= sb->len */
extern void strbuf_insert(struct strbuf *, size_t pos, const void *, size_t);
+/* splice pos..pos+len with given data */
+extern void strbuf_splice(struct strbuf *, size_t pos, size_t len,
+ const void *, size_t);
+
extern void strbuf_add(struct strbuf *, const void *, size_t);
static inline void strbuf_addstr(struct strbuf *sb, const char *s) {
strbuf_add(sb, s, strlen(s));
--
1.5.3.1
^ permalink raw reply related
* [PATCH] Refactor replace_encoding_header.
From: Pierre Habouzit @ 2007-09-15 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070916172134.GA26457@artemis.corp>
* Be more clever in how we search for "encoding ...\n": parse for real
instead of the sloppy strstr's.
* use strbuf_splice to do the substring replacements.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
commit.c | 59 +++++++++++++++++++++++------------------------------------
1 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/commit.c b/commit.c
index 6602e2c..13af933 100644
--- a/commit.c
+++ b/commit.c
@@ -648,47 +648,34 @@ static char *get_header(const struct commit *commit, const char *key)
static char *replace_encoding_header(char *buf, const char *encoding)
{
- char *encoding_header = strstr(buf, "\nencoding ");
- char *header_end = strstr(buf, "\n\n");
- char *end_of_encoding_header;
- int encoding_header_pos;
- int encoding_header_len;
- int new_len;
- int need_len;
- int buflen = strlen(buf) + 1;
-
- if (!header_end)
- header_end = buf + buflen;
- if (!encoding_header || encoding_header >= header_end)
- return buf;
- encoding_header++;
- end_of_encoding_header = strchr(encoding_header, '\n');
- if (!end_of_encoding_header)
+ struct strbuf tmp;
+ size_t start, len;
+ char *cp = buf;
+
+ /* guess if there is an encoding header before a \n\n */
+ while (strncmp(cp, "encoding ", strlen("encoding "))) {
+ cp = strchr(cp, '\n');
+ if (!cp || *++cp == '\n')
+ return buf;
+ }
+ start = cp - buf;
+ cp = strchr(cp, '\n');
+ if (!cp)
return buf; /* should not happen but be defensive */
- end_of_encoding_header++;
-
- encoding_header_len = end_of_encoding_header - encoding_header;
- encoding_header_pos = encoding_header - buf;
+ len = cp + 1 - (buf + start);
+ strbuf_init(&tmp, 0);
+ strbuf_attach(&tmp, buf, strlen(buf), strlen(buf) + 1);
if (is_encoding_utf8(encoding)) {
/* we have re-coded to UTF-8; drop the header */
- memmove(encoding_header, end_of_encoding_header,
- buflen - (encoding_header_pos + encoding_header_len));
- return buf;
- }
- new_len = strlen(encoding);
- need_len = new_len + strlen("encoding \n");
- if (encoding_header_len < need_len) {
- buf = xrealloc(buf, buflen + (need_len - encoding_header_len));
- encoding_header = buf + encoding_header_pos;
- end_of_encoding_header = encoding_header + encoding_header_len;
+ strbuf_splice(&tmp, start, len, NULL, 0);
+ } else {
+ /* just replaces XXXX in 'encoding XXXX\n' */
+ strbuf_splice(&tmp, start + strlen("encoding "),
+ len - strlen("encoding \n"),
+ encoding, strlen(encoding));
}
- memmove(end_of_encoding_header + (need_len - encoding_header_len),
- end_of_encoding_header,
- buflen - (encoding_header_pos + encoding_header_len));
- memcpy(encoding_header + 9, encoding, strlen(encoding));
- encoding_header[9 + new_len] = '\n';
- return buf;
+ return tmp.buf;
}
static char *logmsg_reencode(const struct commit *commit,
--
1.5.3.1
^ permalink raw reply related
* Re: [RFC] strbuf's in builtin-apply
From: Pierre Habouzit @ 2007-09-16 17:21 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20070915141210.GA27494@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
Following this mail will happen a new janitoring series. This is a
rewrite of the former, using Junio's advice to use strbufs in
convert_to_* functions. The patch hence becomes more intrusive than
before (in convert.c mostly). Note that this imply that now strbuf.h is
included from cache.h so all git sources see strbuf's.
The convert_to_git patches gain some marginal efficiency as the new API
makes the reuse of the buffers possible when in-place editing works
(e.g. the \r\n -> \n can be done in place, we save a malloc here). Else
nothing should have changed significantly.
The last 2 patches are new. The first one is a simplification of the
code splicing the "encoding" header in commit.c, reusing the logic
already in strbuf.c for that matter, and also making the parsing code
easier to read (IMHO).
The latter further simplify some code that was trying to guess if
rfc2047 encoding of some header was needed. Thanks to strbuf_grow, and
the fact that now at each point we can grow buffers (which was harder
before), I tried to wait until we are sure if rfc2047 encoding will be
needed or not to extend the buffer. I've benchmarked many tools (on real
repositories, with commiters having non ascii chars in their name) using
the pretty printer without noticeable changes in the numbers (and rather
again, a trend to be faster, but with less than a percent gain, so I
won't call it a real gain).
The series is based on next, as many patches are definitely not suitable
for master :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Blaming diffs
From: Mike Hommey @ 2007-09-16 17:16 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20070916170534.GU22865@planck.djpig.de>
On Sun, Sep 16, 2007 at 07:05:35PM +0200, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Sun, Sep 16, 2007 at 06:38:29PM +0200, Mike Hommey wrote:
> > It seems to me there is no tool to "blame diffs", i.e. something to know
> > what commit(s) is(are) responsible for a set of changes.
> >
> > For example, the following script tries to get the set of commits
> > involved in the changes between $A and $B. Note it only works for text
> > additions.
> >
> > git diff --unified=0 $A $B | awk 'BEGIN { FS="(^(--- a/|+++ b/)|^@@ -[0-9,]+ \\+| @@)" } /^---/ || ( /^+++ b\/(.*)/ && file=="" ) { file = $2 } /^@@/ {split($2, a, /,/); a[2] = a[2] ? a[2] + a[1] - 1 : a[1]; print "git blame -l -L " a[1] "," a[2], "'$A..$B'", file }' | sh | cut -f 1 -d " " | sort -u
> >
> > Has anyone tried to work on something similar yet ?
> >
> > If not, as git users, what kind of output would you expect from such a
> > tool, and where do you think this should lie (extension to git diff, or
> > separate tool) ?
>
> What do you use for $A and $B? commits? What is the difference between
> your script and "git log --pretty=format:%H $A..$B"
> then?
In my typical usecase, $A is upstream and $B is HEAD. What happens is
that my work branch includes some changes that have been merged upstream
and some others that are not yet, or won't because it's not appropriate.
I obviously occasionally merge the upstream branch back, in which case
my changes that were committed upstream don't appear in a git diff $A $B
anymore.
git log --pretty=format:%H $A..$B would give me the list of all commits
that occurred on my branch, while my script only gives the commits
containing changes that are still not applied upstream.
Mike
^ permalink raw reply
* [PATCH] preserve executable bits in zip archives
From: Dmitry Potapov @ 2007-09-16 17:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
Correct `git-archive --format=zip' command to preserve executable bits in
zip archives.
---
archive-zip.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 444e162..5f9b7e6 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -191,7 +191,8 @@ static int write_zip_entry(const unsigned char *sha1,
compressed_size = 0;
} else if (S_ISREG(mode) || S_ISLNK(mode)) {
method = 0;
- attr2 = S_ISLNK(mode) ? ((mode | 0777) << 16) : 0;
+ attr2 = S_ISLNK(mode) ? ((mode | 0777) << 16) :
+ (mode & 0111) ? ((mode) << 16) : 0;
if (S_ISREG(mode) && zlib_compression_level != 0)
method = 8;
result = 0;
@@ -229,7 +230,8 @@ static int write_zip_entry(const unsigned char *sha1,
}
copy_le32(dirent.magic, 0x02014b50);
- copy_le16(dirent.creator_version, S_ISLNK(mode) ? 0x0317 : 0);
+ copy_le16(dirent.creator_version,
+ S_ISLNK(mode) || (S_ISREG(mode) && (mode & 0111)) ? 0x0317 : 0);
copy_le16(dirent.version, 10);
copy_le16(dirent.flags, 0);
copy_le16(dirent.compression_method, method);
--
1.5.3.1
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Blaming diffs
From: Mike Hommey @ 2007-09-16 16:38 UTC (permalink / raw)
To: git
Hi,
It seems to me there is no tool to "blame diffs", i.e. something to know
what commit(s) is(are) responsible for a set of changes.
For example, the following script tries to get the set of commits
involved in the changes between $A and $B. Note it only works for text
additions.
git diff --unified=0 $A $B | awk 'BEGIN { FS="(^(--- a/|+++ b/)|^@@ -[0-9,]+ \\+| @@)" } /^---/ || ( /^+++ b\/(.*)/ && file=="" ) { file = $2 } /^@@/ {split($2, a, /,/); a[2] = a[2] ? a[2] + a[1] - 1 : a[1]; print "git blame -l -L " a[1] "," a[2], "'$A..$B'", file }' | sh | cut -f 1 -d " " | sort -u
Has anyone tried to work on something similar yet ?
If not, as git users, what kind of output would you expect from such a
tool, and where do you think this should lie (extension to git diff, or
separate tool) ?
Cheers,
Mike
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Jan Hudec @ 2007-09-16 15:59 UTC (permalink / raw)
To: david
Cc: Johannes Schindelin, Daniel Barkalow, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709151737400.24221@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
On Sat, Sep 15, 2007 at 18:30:53 -0700, david@lang.hm wrote:
> 1. whatever is trying to write the files with the correct permissions
> needs to be able to query the permission store before files are
> written. This needs to either be an API call into git to retreive the
> information for any file when it's written, or the ability to define a
> specific file to be checked out first so that it can be used for
> everything else.
You seem to be forgetting about the index. Git never writes trees directly to
filesystem, but always with intermediate step in the index. So the API
actually exists -- simply read from the index.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Jan Hudec @ 2007-09-16 15:51 UTC (permalink / raw)
To: martin f krafft
Cc: git, Johannes Schindelin, Daniel Barkalow, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz, David Härdeman
In-Reply-To: <20070916061411.GC24124@piper.oerlikon.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
On Sun, Sep 16, 2007 at 08:14:11 +0200, martin f krafft wrote:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.16.0014 +0200]:
> > While at it, you should invent a fallback what to do when the
> > owner is not present on the system you check out on. And
> > a fallback when checking out on a filesystem that does not support
> > owners.
>
> Like rsync, git would use numerical UIDs (which are always present)
> by default, but could be told to try to map account names.
>
> If the filesystem does not support owners, chown() would not exist.
> I actually tend to think of things the other way around: instead of
> a fallback when chown() does not work (what would such a fallback be
> other than not chown()ing?), it would only try chown() if such
> functionality existed.
There's a problem. You need to know that the functionality is missing and not
try to read attributes back, but instead consider them unchanged. Nothing
that can't be taken care of, but it needs to be handled carefuly.
> > And a fallback when a non-root user uses it.
>
> That's easy, Unix already provides you with that "fallback": pack up
> /etc in a tar and unpack it as a normal user...
But if you tar that up again, the owners will be different. But you don't
want the change.
> > Oh, and while you're at it (you said that it would be nice not to
> > restrict git in any way: "it is a content tracker") support the
> > Windows style "Group-or-User-or-something:[FRW]" ACLs.
>
> Provided we find a way to implement this in an extensible manner,
> this should not be hard to do. I can't do it since I don't have
> access to a Windows machine.
>
> Your statement does catch me off-guard though. Does git now
> officially target Windows?
Official git works in cygwin. There is also a port to msys, which is
not official in a sense it is not merged into mainline.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: Daniel Barkalow @ 2007-09-16 15:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: david, Johannes Schindelin, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <7vwsur590q.fsf@gitster.siamese.dyndns.org>
On Sun, 16 Sep 2007, Junio C Hamano wrote:
> I however think your idea to have extra "permission information
> file" is very interesting. What would be more palatable, than
> mucking with the core level git, would be to have an external
> command that takes two tree object names that tells it what the
> old and new trees our work tree is switching between, and have
> that command to:
>
> - inspect the diff-tree output to find out what were checked
> out and might need their permission information tweaked;
>
> - inspect the differences between the "permission information
> file" in these trees to find out what were _not_ checked out,
> but still need their permission information tweaked.
>
> - tweak whatever external information you are interested in
> expressing in your "permission information file" in the work
> tree for the paths it discovered in the above two steps.
> This step may involve actions specific to projects and call
> hook scripts with <path, info from "permission information
> file" for that path> tuples to carry out the actual tweaking.
Why not have the command also responsible for creating the files that need
to be created (calling back into git to read their contents)? That way,
there's no window where they've been created without their metadata, and
there's more that the core git doesn't have to worry about.
I could see the program getting the index, the target tree, and the
directory to put files in, and being told to do the whole 2-way merge
(except, perhaps, updating the index to match the tree, which git could do
afterwards). As far as git would be concerned, it would mostly be like a
bare repository.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Soria @ 2007-09-16 15:12 UTC (permalink / raw)
To: git
In-Reply-To: <857imq4pi0.fsf@lola.goethe.zz>
> Oder "Zusammenfassung"?
>
probably the best translation yet
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Kastrup @ 2007-09-16 15:08 UTC (permalink / raw)
To: David Soria; +Cc: git
In-Reply-To: <85bqc24pjg.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> David Soria <sn_@gmx.net> writes:
>
>> Am Sun, 16 Sep 2007 14:38:37 +0200 schrieb Christian Stimming:
>>
>> Hi Christian,
>>
>> thank you for bringing up the topic, it's really worth discussing it.
>>
>>> [commit] message - Meldung (Nachricht?; Source Safe: Kommentar)
>> I prefer "Kommentar" here. It describes better what the commit message is
>> about. "Meldung" has some co-notations that don't fit (like e.g.
>> "Meldung" often involes other people, like you "meldest" something to
>> somebody).
>
> "Beschreibung"?
Oder "Zusammenfassung"?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Kastrup @ 2007-09-16 15:07 UTC (permalink / raw)
To: David Soria; +Cc: git
In-Reply-To: <fcjgfg$56m$1@sea.gmane.org>
David Soria <sn_@gmx.net> writes:
> Am Sun, 16 Sep 2007 14:38:37 +0200 schrieb Christian Stimming:
>
> Hi Christian,
>
> thank you for bringing up the topic, it's really worth discussing it.
>
>> [commit] message - Meldung (Nachricht?; Source Safe: Kommentar)
> I prefer "Kommentar" here. It describes better what the commit message is
> about. "Meldung" has some co-notations that don't fit (like e.g.
> "Meldung" often involes other people, like you "meldest" something to
> somebody).
"Beschreibung"?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Soria @ 2007-09-16 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <200709161438.37733.stimming@tuhh.de>
Am Sun, 16 Sep 2007 14:38:37 +0200 schrieb Christian Stimming:
Hi Christian,
thank you for bringing up the topic, it's really worth discussing it.
> [commit] message - Meldung (Nachricht?; Source Safe: Kommentar)
I prefer "Kommentar" here. It describes better what the commit message is
about. "Meldung" has some co-notations that don't fit (like e.g.
"Meldung" often involes other people, like you "meldest" something to
somebody).
> I'm still rather unsure what to do about them. One problem here is that
> both words are used in several different meanings all at once. For
> example, the "commit [noun]" is used interchangeably with "revision".
> I'm actually inclined to translate it with "Version" for exactly that
> reason. And then "checkout": The noun is probably used interchangeably
> with "working copy". Hence, it could be translated as such. OTOH the
> verb means "to update the working copy", and it could be translated as
> such instead of one single word. This would leave only "commit [verb]"
> as the last tricky issue for which a single-word translation must be
> found. "übertragen" is my current favorite but I'm absolutely open for
> further proposals here.
>
> As you can see in the glossary file, I'm still unhappy with the
> translations for those, but anyway here's the current status (not taking
> into account the discussion of the previous paragraph so far):
>
Really hard. I would prefer some larger explanations if they fit into the
application and make sense on every label in the gui.
> msgid "commit [noun]"
> msgstr "Übertragung (Sendung?, Übergabe?, Einspielung?, Ablagevorgang?)"
Übertragung fits well, but for me it has a co-notation that something is
transfered from one point to another (e.g. using an internet connection)
So this translation would fit perfectly for centralized versioning
systems, where the changeset is really "transfered" to somewhere. I would
prefer the term "Einspielung" as I think it reflects better, that the
commit is locally.
David
^ permalink raw reply
* RFC: German translation vocabulary
From: Christian Stimming @ 2007-09-16 12:38 UTC (permalink / raw)
To: git
Dear all,
as git-gui has now picked up the i18n features and the initial German
translation has been included as well, it is about time to discuss and
finalize the actual translation wordings of git terminology in German.
In particular, for all keywords of git and git-gui one needs to find
corresponding keywords in German, which will then be used consistently
throughout all of git-gui translations. Those keywords and (for some of them)
their english definition are contained in the "glossary" file, see [1]. I
would like to invite all German-speaking readers here to review the German
keyword translations that have been chosen in the glossary, and I'll denote
the most important ones below for immediate feedback.
(I'll mostly stick to an english discussion so that other languages can use
this as a model on how to discuss this, if they want to.)
One word on the intended audience for the translated git-gui: The translated
form of git-gui is *not for you* :-). In other words, it is not intended for
those who are reading this list and, by doing so, are completely familiar
with all the English terminology of git. Instead, the translation is intended
for German developers who know *some* English, but feel much more comfortable
with a fully German development environment and probably wouldn't touch an
english-language git-gui anyway. Hence, the translation should try really
hard to find German words wherever possible.
Also, other version control systems have worked on their German translation as
well. If you want to check the wordings that have been chosen there, I'd
recommend looking into their translations [2].
I'll list the most important glossary terms here, starting with the easier
ones:
repository - Projektarchiv
revision - Version
staging area - Bereitstellung
branch [noun] - Zweig
branch [verb] - verzweigen
working copy, working tree - Arbeitskopie
[commit] message - Meldung (Nachricht?; Source Safe: Kommentar)
For some of them you can see alternatives considered in the glossary [1], but
overall the above ones were rather easy. Now for the difficult ones:
commit [noun]
commit [verb]
checkout [noun]
checkout [verb]
I'm still rather unsure what to do about them. One problem here is that both
words are used in several different meanings all at once. For example,
the "commit [noun]" is used interchangeably with "revision". I'm actually
inclined to translate it with "Version" for exactly that reason. And
then "checkout": The noun is probably used interchangeably with "working
copy". Hence, it could be translated as such. OTOH the verb means "to update
the working copy", and it could be translated as such instead of one single
word. This would leave only "commit [verb]" as the last tricky issue for
which a single-word translation must be found. "übertragen" is my current
favorite but I'm absolutely open for further proposals here.
As you can see in the glossary file, I'm still unhappy with the translations
for those, but anyway here's the current status (not taking into account the
discussion of the previous paragraph so far):
msgid "checkout [noun]"
msgstr "Auscheck? Ausspielung? Abruf? (Source Safe: Auscheckvorgang)"
msgid "checkout [verb]"
msgstr "auschecken? ausspielen? abrufen? (Source Safe: auschecken)"
msgid "commit [noun]"
msgstr "Übertragung (Sendung?, Übergabe?, Einspielung?, Ablagevorgang?)"
msgid "commit [verb]"
msgstr "übertragen (TortoiseSVN: übertragen; Source Safe: einchecken; senden?,
übergeben?, einspielen?, einpflegen?, ablegen?)"
Regards,
Christian Stimming
[1] http://repo.or.cz/w/git-gui.git?a=blob_plain;f=po/glossary/de.po;hb=HEAD
(note: the file is in UTF-8, but repo.or.cz's webserver claims it is latin1,
hence the messed-up Umlauts)
[2]
* http://tortoisesvn.net/docs/release/TortoiseSVN_de/index.html (very good)
* http://msdn.microsoft.com/de-de/library/ms181038(vs.80).aspx (MS Visual
Source Safe, commercial)
* http://cvsbook.red-bean.com/translations/german/Kap_06.html (not so good)
*
http://tortoisecvs.cvs.sourceforge.net/tortoisecvs/po/TortoiseCVS/de_DE.po?view=markup
(not so good)
* http://rapidsvn.tigris.org/svn/rapidsvn/trunk/src/locale/de/rapidsvn.po
(username=guest, password empty, quite bad)
^ permalink raw reply
* Re: git-gui i18n status?
From: Christian Stimming @ 2007-09-16 12:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709021320230.28586@racer.site>
Hi Shawn et al.,
Am Sonntag, 2. September 2007 14:20 schrieb Johannes Schindelin:
> > > > Hmm. I am not enough involved in i18n stuff to form a proper opinion
> > > > here... Do you suggest to move the initialisation earlier?
> > >
> > > Yea, I think that's what we are going to have to do here. If we don't
> > > setup the directory for the .msg files early enough than we cannot do
> > > translations through [mc]. Unfortunately that means we have to also
> > > break up the library initialization.
> > >
> > > I'll try to work up a patch that does this.
> >
> > This two patch series is based on my current master (gitgui-0.8.2).
> > Its also now in my pu branch.
>
> Sound both good to me. Christian?
Thanks for including the i18n framework and existing translations into the
master of git-gui. I loosely watched the progress here, but due to other
commitments I cannot spend as much time on git-gui i18n as I initially
thought. I'd happily update and polish the German translation, though (will
send other email for that), but I probably can't follow any of the ongoing
i18n cleanup work.
One question came up when seeing the i18n code really in git-gui.git: How are
translators supposed to submit new or updated translations? Is
git-gui-i18n.git of any use anymore? This doesn't seem so. Should updated
translations just be submitted by email to git@vger? In any case, the
instructions in po/README should probably be updated to explain the
recommended way of submitting translation updates.
Oh, and po/git-gui.pot should probably be updated to reflect the latest string
additions and changes.
Thanks a lot.
Christian
^ permalink raw reply
* Re: git-svn error when cloning apache repo
From: Sam Vilain @ 2007-09-16 11:46 UTC (permalink / raw)
To: jingxue; +Cc: git
In-Reply-To: <20070915230833.GA8525@falcon.digizenstudio.com>
Jing Xue wrote:
> $ git svn clone https://svn.apache.org/repos/asf/incubator/ivy/core/ ivy-core -T trunk -b branches -t tags
> Initialized empty Git repository in .git/
> Using higher level of URL: https://svn.apache.org/repos/asf/incubator/ivy/core => https://svn.apache.org/repos/asf
>
I'm fairly sure this is where it went wrong. Try editing .git/config and
putting your original URL in the source URL, and re-try the fetch.
Sam.
^ permalink raw reply
* Re: Conflicting "-n" short options for git-pull?
From: Frans Pop @ 2007-09-16 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy1f8pmm.fsf@gitster.siamese.dyndns.org>
On Sunday 16 September 2007, Junio C Hamano wrote:
> Frans Pop <elendil@planet.nl> writes:
> > According to the man page for git-pull from git-core 1.5.3.1 (Debian
> > package), two options are defined as having the short option "-n":
> >
> > -n, --no-summary
> > Do not show diffstat at the end of the merge.
> > [...]
> > -n, --no-tags
> > By default, git-fetch fetches tags that point at objects that
> > are downloaded from the remote repository and stores them locally. This
> > option disables this automatic tag following.
>
> The manpage option descriptions are shared between the
> commands. Maybe we should drop mention of the shorthand form.
Not sure if that last is the correct solution. Wouldn't it mean that short
options would not be documented at all anymore?
> When git-fetch is used -n means --no-tags because there is no
> other -n; when git-pull indirectly invokes git-fetch, you need
> to spell it --no-tags because --no-summary takes precedence.
That does explain, but it is not at all obvious from the documentation.
Guess this is a general "problem" in git then.
Another question.
Is it possible to set default options for commands somehow?
I'd like to run git-pull with '--no-summary' by default. I could of course
define an alias, but that only covers 'git-pull' and not 'git pull'.
Does git itself have some mechanism for this?
Thanks,
Frans Pop
^ permalink raw reply
* Re: [StGit PATCH 00/13] Eliminate 'top' and 'bottom' files
From: David Kågedal @ 2007-09-16 10:28 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström , git
In-Reply-To: <b0943d9e0709160028h41a67474g6b379a45c4c88432@mail.gmail.com>
16 sep 2007 kl. 09.28 skrev Catalin Marinas:
> On 16/09/2007, Karl Hasselström <kha@treskal.com> wrote:
>> On 2007-09-15 00:31:09 +0200, David Kågedal wrote:
>>
>>> The following series removes the 'bottom' and 'top' files for each
>>> patch, and instead uses the commit objects to keep track of the
>>> patches.
>>
>> Wonderful! Does this ensure that there's a bijection between patches
>> and commits at _all_ times, or am I missing something?
>
> We should get rid of top.old and bottom.old as well.
>
> My question - does this conflict with the DAG patches in any way? I
> intend to include the them at some point, once I get a chance to test
> the performance penalty with a big tree like the Linux kernel.
My refactoring of the push_patch function will conflict because of
refactoring, but it doesn't change how the appliedness is used, so it
should be pretty simple to resolve.
Or I could try to redo the patches so it only has the minimal changes
to actually remove the top and bottom files.
>> Hmm, wait, no. Right. We also have to create commits for those
>> patches
>> that don't have exactly one commit object. Not that there'll be many
>> of them, but better not make assumptions ...
>
> Is there any patch which consists of more than one commit? Maybe only
> uncommit could generate one but I think we put some tests in place.
I haven't seen any such case. Can uncommit create one? Or did it use
to do that before? I added checks to detect it, and no test case
caught it at least.
--
David Kågedal
davidk@lysator.liu.se
^ permalink raw reply
* Re: [StGit PATCH 00/13] Eliminate 'top' and 'bottom' files
From: David Kågedal @ 2007-09-16 10:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, catalin.marinas
In-Reply-To: <20070915234244.GD25507@diana.vm.bytemark.co.uk>
16 sep 2007 kl. 01.42 skrev Karl Hasselström:
> On 2007-09-15 00:31:09 +0200, David Kågedal wrote:
>
>> The following series removes the 'bottom' and 'top' files for each
>> patch, and instead uses the commit objects to keep track of the
>> patches.
>
> Wonderful! Does this ensure that there's a bijection between patches
> and commits at _all_ times, or am I missing something?
That's the intention, at least. As far as I could tell, the biject
already held, except temporarily in the middle of executing some
commands. So I had to refactor them to never create that intermedate
state.
>> The last two patches do the final cleansing. Obviously, this changes
>> the format, and the format version should be increased and and
>> update function be written. So it's not really ready to go in yet.
>
> It's a trivial format update, though: just delete those two files and
> increase the number from 2 to 3.
>
> Hmm, wait, no. Right. We also have to create commits for those patches
> that don't have exactly one commit object. Not that there'll be many
> of them, but better not make assumptions ...
I haven't seen any such patches, but I haven't tried everything.
Neither do the test suite test everything.
--
David Kågedal
davidk@lysator.liu.se
^ permalink raw reply
* Re: [StGit PATCH 13/13] Remove the 'top' field
From: David Kågedal @ 2007-09-16 10:22 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, catalin.marinas
In-Reply-To: <20070915233632.GC25507@diana.vm.bytemark.co.uk>
16 sep 2007 kl. 01.36 skrev Karl Hasselström:
> On 2007-09-15 00:32:15 +0200, David Kågedal wrote:
>
>> @@ -436,7 +422,13 @@ class Series(PatchSet):
>> patch = patch.strip()
>> os.rename(os.path.join(branch_dir, patch),
>> os.path.join(patch_dir, patch))
>> - Patch(patch, patch_dir, refs_base).update_top_ref()
>> + topfield = os.path.join(patch_dir, patch, 'top')
>> + if os.path.isfile(topfield):
>> + top = read_string(topfield, False)
>> + else:
>> + top = None
>> + if top:
>> + git.set_ref(refs_base + '/' + patch, top)
>> set_format_version(1)
>>
>> # Update 1 -> 2.
>
> And remove the top file, maybe? (Or I may be mistaken; I don't have a
> copy of the surrounding code handy.)
No, this is the code that updates from version 0 to version 1. The
problem was that the update functionality used the update_top_ref()
function in the Patch class which I changed. So I had to inline the
code instead.
--
David Kågedal
davidk@lysator.liu.se
^ permalink raw reply
* Re: [PATCH 3/3] rev-list --bisect: Bisection "distance" clean up.
From: Junio C Hamano @ 2007-09-16 8:54 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20070915130016.eac885f4.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> diff --git a/builtin-rev-list.c b/builtin-rev-list.c
> index c2ce1fc..6ade3b7 100644
> --- a/builtin-rev-list.c
> +++ b/builtin-rev-list.c
> @@ -189,7 +189,7 @@ static int count_interesting_parents(struct commit *commit)
> return count;
> }
>
> -static inline int halfway(struct commit_list *p, int distance, int nr)
> +static inline int halfway(struct commit_list *p, int nr)
> {
This makes sense as we always call with "distance = weight(p)".
But is this three-patch series really needed? We see this kind
of clean-ups often as a prelude to a larger set of enhancements,
building up anticipation for smarter and more beautiful things
to come, and seeing the series end here leaves me wondering
"Huh? Is that it?".
Not that clean-up itself does not have any value, but still...
^ permalink raw reply
* Re: [PATCH 1/3] rev-list --bisect: Move finding bisection into do_find_bisection.
From: Junio C Hamano @ 2007-09-16 8:47 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20070915125957.0899841b.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> This factorises some code and make a big function smaller.
I think the refactoring itself makes sense, especially where it
simplifies the clean-up of weight array in early-return
codepath. But I have a couple of comments, though.
> +static struct commit_list *do_find_bisection(struct commit_list *list,
> + int nr, int *weights);
> +
> /*
> * zero or positive weight is the number of interesting commits it can
> * reach, including itself. Especially, weight = 0 means it does not
The comment whose top part we can see here talks about the magic
values -1 and -2 used while do_find_bisection() after the
refactoring does its work, and these magic values are never
visible to the calling function. You should move the comment to
the top of do_find_bisection() as well.
Also this forward declaration is unwarranted. A bottom-up
sequence to define do_find_bisection() first, then to define its
sole caller find_bisection() next is easier to read at least for
me.
The latter comment also applies to your other patch.
^ permalink raw reply
* Re: metastore
From: David Kastrup @ 2007-09-16 8:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: david, Johannes Schindelin, Daniel Barkalow, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <7vwsur590q.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Yes, I am very well aware that somebody already mentioned "there
> is a window between the true checkout and permission tweaking".
> If you need to touch the core level in order to close that
> window, I am not interested.
Doing this atomically involves creating the file in question by
specifying the permissions on the creat system call already, and
possibly wrap seteuid calls and similar around it for getting the
right file/ownership.
However, it is not really necessary to do this atomically: instead one
can rather create the file using safe permissions (600) at first, then
do fchown and fchmod (or chown/chmod) at some point in time afterwards
as required.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] builtin-apply: use strbuf's instead of buffer_desc's.
From: Pierre Habouzit @ 2007-09-16 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4phv8m26.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On Sun, Sep 16, 2007 at 12:56:49AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > 1 files changed, 73 insertions(+), 130 deletions(-)
>
> Nice reduction.
>
> > - }
> > - return got != size;
> > +
> > + nsize = buf->len;
> > + nbuf = convert_to_git(path, buf->buf, &nsize);
> > + if (nbuf)
> > + strbuf_embed(buf, nbuf, nsize, nsize);
> > + return 0;
>
>
> I suspect that changing the convert_to_git() interface to work
> on strbuf instead of (char*, size_t *) pair might make things
> simpler and easier.
Well, yes, maybe it could use:
(const char *, char *, size_t, struct strbuf *out);
But this function is used elsewhere where there isn't strbuf's (yet ?)
so I wasn't willing to do such a big change. But as you seem to think it
would help, I'll evaluate where it's going.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] Remove unnecessary 'fetch' argument from transport_get API
From: Shawn O. Pearce @ 2007-09-16 8:11 UTC (permalink / raw)
To: Junio C Hamano, Daniel Barkalow; +Cc: git
In-Reply-To: <20070915072314.GE20346@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> We don't actually need to know at the time of transport_get if the
> caller wants to fetch, push, or do both on the returned object.
> It is easier to just delay the initialization of the HTTP walker
> until we know we will need it by providing a CURL specific fetch
> function in the curl_transport that makes sure the walker instance
> is initialized before use.
Daniel privately emailed me his rationale for why this fetch argument
was here in the first place and I mostly agree with him, but will
be working up a more clear API replacement in the near future.
The "1/0","fetch/push" thing is not the clearest way that we could
define the API.
Right now this patch is required to go along with my 1/5 bug fix,
as without this patch we get the sequence:
http_init()
http_init()
... use http ...
http_cleanup()
... try to use http again and barf ...
This 5/5 makes the sequence be in proper order by delaying creation
of the HTTP walker object (and thus one of the http_init() calls)
to after the first http_cleanup(), so we get the nice neat order of:
http_init()
... use http ...
http_cleanup()
http_init()
... use http just fine ...
http_cleanup()
I'll be honest here; I did not test 1/5 or 5/5 on their own.
I only tested the combined result of them, and that creates a
working HTTP fetch. But I'm pretty sure that one of these patches
alone will still cause SIGSEGV/SIGBUS errors during HTTP fetch due
to either the bad cleanup (1/5 fixes) or the bad init ordering I'm
talking about above (5/5 fixes).
Reinstating a replacement for the fetch parameter that I removed
in this patch isn't critical for functionality, but will be
necessary to do performance optimization in the form of reusing
the connection between ref discovery and pack transfer in the
native protocol. Right now I'm focusing on making builtin-fetch
stable and implementing prior behavior. Once its solid enough to
graduate to `next` we can start doing some of the optimization work.
--
Shawn.
^ 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