* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-13 18:18 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910131114q19b6c822t5806d20005341cb4@mail.gmail.com>
Israel Garcia <igalvarez@gmail.com> wrote:
> BTW, is there any git-dump or git-backup command to do some kind of
> backup I'm looking for?
No, you backup git by making a clone. E.g. `git clone --bare`.
Since this leaves you with a directory, you need to then perhaps
use some sort of file combiner tool like tar or zip to produce a
single file for backup to tape.
You can incrementally update that backup clone using git push to
write into it, or you can just blow it away and recreate it each
time you make a backup.
One could also use `git bundle` to create backup file that had
everything packaged in one neat file, but this can be slightly
harder to work with since a bundle is not a git repository.
--
Shawn.
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-13 18:18 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910131108h10acbacdy68306c9c3389517@mail.gmail.com>
Israel Garcia <igalvarez@gmail.com> wrote:
> Thanks for your answer, could you please put here how you think
> post-update file should be setup? Remember in my case I want to backup
> every repo to /backups/git folder for example.
Exactly the same as that post-commit I mentioned, just call the
file .git/hooks/post-update instead.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 12/16] Smart fetch and push over HTTP: server side
From: Shawn O. Pearce @ 2009-10-13 18:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AD42C87.6000205@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> > diff --git a/http-backend.c b/http-backend.c
>
> #include "run-command.h" is missing here because you added it already in
> patch 10/16 unnecessarily.
>
> > + if (start_command(&cld))
> > + die_errno("Cannot start %s", argv[0]);
> > ...
> > + if (finish_command(&cld))
> > + die("%s terminated with error", argv[0]);
>
> start_command and finish_command already write an error message for you
> that includes argv[0] and errno. You can just exit(1) here.
Whoops on both; thanks for the catch.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Daniel Barkalow @ 2009-10-13 18:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Johannes Schindelin, Euguess, Mikael Magnusson,
Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>
On Tue, 13 Oct 2009, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> >> Or can't you go the other way, say
> >>
> >> git checkout -t $remote_tracking
> >>
> >> to create a local branch forking from the named remote tracking branch?
> >
> > Sure, but we already have that and we still failed to fix the users,
> > so FWIW, I think Dscho's right and we should try fixing the UI next.
>
> What it means is that -t was a broken attempt to help the users at the UI
> level, and I can surely see that.
>
> So we need the set of new rules, say, for 1.7.0 release. A strawman?
>
> Assume that these are the only refs that exist:
>
> refs/remotes/origin/{master,next,nitfol}
> refs/remotes/xyzzy/{frotz,nitfol}
> refs/heads/master
> refs/tags/v1.0.0
>
> #0. These will stay as is:
>
> $ git checkout mine ;# switches to the branch
> $ git checkout $any_committish^0 ;# detaches
>
> #1. These used to detach, but will create a local branch
>
> $ git checkout origin/next ;# as if with -t
> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
>
> #2. These are allowed only when unambiguous and there is no local branch yet.
>
> $ git checkout next ;# ok
> $ git checkout frotz ;# ok (origin is not special)
> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
>
> #3. These used to detach, but what should we do?
>
> $ git checkout v1.0.0 ;# detach, or refuse???
> $ git checkout origin/master ;# detach, or refuse???
>
> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we
> started refusing to detach in case #3, as people who want to detach can
> always suffix ^0 or ~0 to make it a general committish.
I suspect that a very common pattern for people who follow trees for
testing and such or who only develop in topic branches is:
$ git clone ...
$ git checkout origin/next
$ git fetch origin
$ git checkout origin/next
For people who use topic branches extensively:
$ git fetch origin
$ git checkout origin/next
(test, find issues, maybe make changes)
$ git checkout -b topic
$ git commit
(send changes)
Some people (IIRC, including Linus):
$ git checkout origin/next
(work)
$ git commit
$ git checkout -b topic
In all of these cases, the user will get a misleading "next" local branch;
in Linus's case, this branch ends up with commits from a topic branch.
For that matter, even the intended user would have problems with your
suggestion:
$ git clone ...
$ git checkout origin/next
(do some next stuff)
$ git checkout origin/master
(do some master stuff)
$ git checkout origin/next
On the second cycle, either git refuses or does something actively
confusing to this user, and the user has to learn the difference between
local branches and remote branches on the *second* cycle. IMHO, it's much
better to make users learn things at the point when they don't think they
know how to use the system, rather than when they think they understand it
and are just trying to get things done.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-13 18:39 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <1255429615-4402-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> On Monday 12 October 2009 08:19, Stephen Boyd wrote:
>> The problem is I can't get it to work with UTF-8 characters. I'm not sure
>> if it's my system or not, so I'm just posting here to see if others
>> experience the same problem and if there's interest.
>
> Does it work if you use CGI::escape() on the author names when filling
> the searchtext?
This doesn't seem to work. Now I get %25 in front of the escaped
characters. For example, a space is now %25%20.
Can you reproduce my problem locally?
^ permalink raw reply
* Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Shawn O. Pearce @ 2009-10-13 18:45 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910122357230.32515@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> > diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> > +'option' <name>::
> > + This helper supports the option <name> under fetch-multiple.
> > +
>
> I'm a bit surprised that the options only apply in a fetch-multiple
> section, rather than getting set at the beginning and applying to
> everything for that run. At least, I think an "option" command should be
> useable outside of a fetch-multiple (or possible future grouping
> construct) and have global scope.
In hindsight, I agree with you.
I'll respin the series so the set_option method in the transport
forwards the options immediately to the helper and lets the helper
decide whether it accepts or rejects the option string. This will
clean up the capabilities interface since we no longer need to dump
the list of options we support in the helper, and as you point out,
it will make a lot more sense to just set the options for this
transport instance.
> > REF LIST ATTRIBUTES
> > -------------------
> >
> > @@ -76,10 +80,26 @@ None are defined yet, but the caller must accept any which are supplied.
> >
> > FETCH OPTIONS
> > -------------
> > +To enable an option the helper must list it in 'capabilities'.
> >
> > 'option verbose'::
> > Print more verbose activity messages to stderr.
>
> I think you mis-split the above part; your previoud patch declared this
> option without declaring any way to use it. Might be worth allowing
> multiple "verboses" and "quiet" or "option verbosity quiet"/"option
> verbosity verbose verbose".
Hmmph. "option verbosity verbose verbose" is a bit verbose, don't
you think? :-)
I think we should just forward the verbosity setting from the
frontend: "option verbosity [0-n]" where n is the number of
times -v appeared on the command line/how verbose the user wants.
> > +'option uploadpack' <command>::
> > + The program to use on the remote side to generate a pack.
>
> I sort of feel like the helper ought to read this one out of the config
> file itself if it wants it.
Eh, true, but you can also set this on the command line. An open
question I still have for myself is how to set this in HTTP
transports.
The reason why I care is Gerrit Code Review has overloaded the
'git-receive-pack' executable and taught it more command line flags:
$ ssh r git receive-pack -h
git receive-pack PROJECT.git [--cc EMAIL ...] [--help (-h)] [--reviewer (--re) EMAIL ...]
PROJECT.git : project name
--cc EMAIL : CC user on change(s)
--help (-h) : display this help text
--reviewer (--re) EMAIL : request reviewer for change(s)
Which is typically invoked as:
git push --receive-pack "git-receive-pack --reviewer spearce@spearce.org" URL REFSPEC
Folks actually have scripts which make this invocation for them, so
they can insert in the proper reviewer and/or cc arguments. Since
the arguments vary its hard to set this up in the configuration file.
Over SSH this is fine, we obtain the arguments off the SSH command
line string and its no big deal. Over git:// this would fail as
git-daemon can't parse the line anymore. Over HTTP this also is not
going to work since the service can't receive arbitrary arguements.
My primary motivator for doing smart HTTP now is folks who are
stuck behind firewalls that permit only HTTP through their local
proxy servers are unable to communicate with a Gerrit Code Review
instance over SSH on port 29418. That --reviewer flag above is a
very useful feature of Gerrit that I somehow have to support for
the HTTP transport too.
I started down the road of currying this data into the backend by
at least exposing the option to the helper. How the helper reads
and uses it is up to the helper.
But given that the value can come in from the command line or from
the configuration file, I think this should be handled by fetch
or push porcelain and fed through the helper protocol, and not be
something that the helper reads from the config directly.
> In general, it would be good to have
> transport.c and remote.c out of the business of knowing this sort of
> protocol-specific (albiet specific now to two protocols) information. (Of
> course, the native protocol's transport methods are in transport.c, so
> that's there, but I'd like to move that to a transport-native.c someday.)
Agreed, but I have no solution for you due to the --receive-pack
and --upload-pack arguments supported by the command line git push
and git fetch/pull porcelain.
But I have been trying to extend the helper interface in a way
that would allow us to eject the native transport code entirely
into a helper. We may never bother, there are some advantages to
being in the push/fetch client process, but I also didn't want to
get stuck in a corner.
I think with my series we do almost everything we need to support
native git:// in an external helper process rather than builtin.
We honor the pack lock file system used by fetch to maintain safe
concurrent mutations. We use push_refs API and signal back the
complete information from the remote side. We permit arbitrary
message strings per ref to be returned by the helper. Etc.
> > +'option followtags'::
> > + Aggressively fetch annotated tags if possible.
>
> I assume this means to fetch tags which annotate objects we have or are
> fetching? (As opposed to fetching any annotated tag we could possibly
> fetch, even if we don't otherwise care about the tag or the thing it
> tags.) It's obvious in the context of git's config options, but I'd like
> this document to avoid assuming that context, and the option could apply
> more generally.
Yes. I'll extend the documentation further in the next iteration.
> > +'option thin'::
> > + Transfer the data as a thin pack if possible.
>
> Does anyone still use non-default thinness?
Its a command line option on the porcelain. Until we remove
the command line flag I think we should still try to honor it
in implementations that understand that notion.
--
Shawn.
^ permalink raw reply
* [PATCH v3 2/8] imap-send: use separate read and write fds
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-2-git-send-email-kusmabite@gmail.com>
This is a patch that enables us to use the run-command
API, which is supported on Windows.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 8da7a94..7216453 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -151,7 +151,7 @@ struct imap_list {
};
struct imap_socket {
- int fd;
+ int fd[2];
SSL *ssl;
};
@@ -301,8 +301,12 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
ssl_socket_perror("SSL_new");
return -1;
}
- if (!SSL_set_fd(sock->ssl, sock->fd)) {
- ssl_socket_perror("SSL_set_fd");
+ if (!SSL_set_rfd(sock->ssl, sock->fd[0])) {
+ ssl_socket_perror("SSL_set_rfd");
+ return -1;
+ }
+ if (!SSL_set_wfd(sock->ssl, sock->fd[1])) {
+ ssl_socket_perror("SSL_set_wfd");
return -1;
}
@@ -324,11 +328,12 @@ static int socket_read(struct imap_socket *sock, char *buf, int len)
n = SSL_read(sock->ssl, buf, len);
else
#endif
- n = xread(sock->fd, buf, len);
+ n = xread(sock->fd[0], buf, len);
if (n <= 0) {
socket_perror("read", sock, n);
- close(sock->fd);
- sock->fd = -1;
+ close(sock->fd[0]);
+ close(sock->fd[1]);
+ sock->fd[0] = sock->fd[1] = -1;
}
return n;
}
@@ -341,11 +346,12 @@ static int socket_write(struct imap_socket *sock, const char *buf, int len)
n = SSL_write(sock->ssl, buf, len);
else
#endif
- n = write_in_full(sock->fd, buf, len);
+ n = write_in_full(sock->fd[1], buf, len);
if (n != len) {
socket_perror("write", sock, n);
- close(sock->fd);
- sock->fd = -1;
+ close(sock->fd[0]);
+ close(sock->fd[1]);
+ sock->fd[0] = sock->fd[1] = -1;
}
return n;
}
@@ -358,7 +364,8 @@ static void socket_shutdown(struct imap_socket *sock)
SSL_free(sock->ssl);
}
#endif
- close(sock->fd);
+ close(sock->fd[0]);
+ close(sock->fd[1]);
}
/* simple line buffering */
@@ -911,7 +918,7 @@ static void imap_close_server(struct imap_store *ictx)
{
struct imap *imap = ictx->imap;
- if (imap->buf.sock.fd != -1) {
+ if (imap->buf.sock.fd[0] != -1) {
imap_exec(ictx, NULL, "LOGOUT");
socket_shutdown(&imap->buf.sock);
}
@@ -939,7 +946,7 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
ctx = xcalloc(sizeof(*ctx), 1);
ctx->imap = imap = xcalloc(sizeof(*imap), 1);
- imap->buf.sock.fd = -1;
+ imap->buf.sock.fd[0] = imap->buf.sock.fd[1] = -1;
imap->in_progress_append = &imap->in_progress;
/* open connection to IMAP server */
@@ -966,7 +973,8 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
close(a[0]);
- imap->buf.sock.fd = a[1];
+ imap->buf.sock.fd[0] = a[1];
+ imap->buf.sock.fd[1] = dup(a[1]);
imap_info("ok\n");
} else {
@@ -1043,7 +1051,8 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
goto bail;
}
- imap->buf.sock.fd = s;
+ imap->buf.sock.fd[0] = s;
+ imap->buf.sock.fd[1] = dup(s);
if (srvc->use_ssl &&
ssl_socket_connect(&imap->buf.sock, 0, srvc->ssl_verify)) {
--
1.6.4
^ permalink raw reply related
* [PATCH v3 1/8] imap-send: remove useless uid code
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Jeff King, Erik Faye-Lund
In-Reply-To: <1255461925-2244-1-git-send-email-kusmabite@gmail.com>
From: Jeff King <peff@peff.net>
The imap-send code is based on code from isync, a program
for syncing imap mailboxes. Because of this, it has
inherited some code that makes sense for isync, but not for
imap-send.
In particular, when storing a message, it does one of:
- if the server supports it, note the server-assigned
unique identifier (UID) given to each message
- otherwise, assigned a random UID and store it in the
message header as X-TUID
Presumably this is used in isync to be able to synchronize
mailstores multiple times without duplication. But for
imap-send, the values are useless; we never do anything
with them and simply forget them at the end of the program.
This patch removes the useless code. Not only is it nice for
maintainability to get rid of dead code, but the removed
code relied on the existence of /dev/urandom, which made it
a portability problem for non-Unix platforms.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 155 ++++------------------------------------------------------
1 files changed, 11 insertions(+), 144 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 3847fd1..8da7a94 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -123,9 +123,6 @@ static int nfvasprintf(char **strp, const char *fmt, va_list ap)
return len;
}
-static void arc4_init(void);
-static unsigned char arc4_getbyte(void);
-
struct imap_server_conf {
char *name;
char *tunnel;
@@ -489,52 +486,6 @@ static int nfsnprintf(char *buf, int blen, const char *fmt, ...)
return ret;
}
-static struct {
- unsigned char i, j, s[256];
-} rs;
-
-static void arc4_init(void)
-{
- int i, fd;
- unsigned char j, si, dat[128];
-
- if ((fd = open("/dev/urandom", O_RDONLY)) < 0 && (fd = open("/dev/random", O_RDONLY)) < 0) {
- fprintf(stderr, "Fatal: no random number source available.\n");
- exit(3);
- }
- if (read_in_full(fd, dat, 128) != 128) {
- fprintf(stderr, "Fatal: cannot read random number source.\n");
- exit(3);
- }
- close(fd);
-
- for (i = 0; i < 256; i++)
- rs.s[i] = i;
- for (i = j = 0; i < 256; i++) {
- si = rs.s[i];
- j += si + dat[i & 127];
- rs.s[i] = rs.s[j];
- rs.s[j] = si;
- }
- rs.i = rs.j = 0;
-
- for (i = 0; i < 256; i++)
- arc4_getbyte();
-}
-
-static unsigned char arc4_getbyte(void)
-{
- unsigned char si, sj;
-
- rs.i++;
- si = rs.s[rs.i];
- rs.j += si;
- sj = rs.s[rs.j];
- rs.s[rs.i] = sj;
- rs.s[rs.j] = si;
- return rs.s[(si + sj) & 0xff];
-}
-
static struct imap_cmd *v_issue_imap_cmd(struct imap_store *ctx,
struct imap_cmd_cb *cb,
const char *fmt, va_list ap)
@@ -1198,88 +1149,20 @@ static int imap_make_flags(int flags, char *buf)
return d;
}
-#define TUIDL 8
-
-static int imap_store_msg(struct store *gctx, struct msg_data *data, int *uid)
+static int imap_store_msg(struct store *gctx, struct msg_data *data)
{
struct imap_store *ctx = (struct imap_store *)gctx;
struct imap *imap = ctx->imap;
struct imap_cmd_cb cb;
- char *fmap, *buf;
const char *prefix, *box;
- int ret, i, j, d, len, extra, nocr;
- int start, sbreak = 0, ebreak = 0;
- char flagstr[128], tuid[TUIDL * 2 + 1];
+ int ret, d;
+ char flagstr[128];
memset(&cb, 0, sizeof(cb));
- fmap = data->data;
- len = data->len;
- nocr = !data->crlf;
- extra = 0, i = 0;
- if (!CAP(UIDPLUS) && uid) {
- nloop:
- start = i;
- while (i < len)
- if (fmap[i++] == '\n') {
- extra += nocr;
- if (i - 2 + nocr == start) {
- sbreak = ebreak = i - 2 + nocr;
- goto mktid;
- }
- if (!memcmp(fmap + start, "X-TUID: ", 8)) {
- extra -= (ebreak = i) - (sbreak = start) + nocr;
- goto mktid;
- }
- goto nloop;
- }
- /* invalid message */
- free(fmap);
- return DRV_MSG_BAD;
- mktid:
- for (j = 0; j < TUIDL; j++)
- sprintf(tuid + j * 2, "%02x", arc4_getbyte());
- extra += 8 + TUIDL * 2 + 2;
- }
- if (nocr)
- for (; i < len; i++)
- if (fmap[i] == '\n')
- extra++;
-
- cb.dlen = len + extra;
- buf = cb.data = xmalloc(cb.dlen);
- i = 0;
- if (!CAP(UIDPLUS) && uid) {
- if (nocr) {
- for (; i < sbreak; i++)
- if (fmap[i] == '\n') {
- *buf++ = '\r';
- *buf++ = '\n';
- } else
- *buf++ = fmap[i];
- } else {
- memcpy(buf, fmap, sbreak);
- buf += sbreak;
- }
- memcpy(buf, "X-TUID: ", 8);
- buf += 8;
- memcpy(buf, tuid, TUIDL * 2);
- buf += TUIDL * 2;
- *buf++ = '\r';
- *buf++ = '\n';
- i = ebreak;
- }
- if (nocr) {
- for (; i < len; i++)
- if (fmap[i] == '\n') {
- *buf++ = '\r';
- *buf++ = '\n';
- } else
- *buf++ = fmap[i];
- } else
- memcpy(buf, fmap + i, len - i);
-
- free(fmap);
+ cb.dlen = data->len;
+ cb.data = xmalloc(cb.dlen);
+ memcpy(cb.data, data->data, data->len);
d = 0;
if (data->flags) {
@@ -1288,26 +1171,14 @@ static int imap_store_msg(struct store *gctx, struct msg_data *data, int *uid)
}
flagstr[d] = 0;
- if (!uid) {
- box = gctx->conf->trash;
- prefix = ctx->prefix;
- cb.create = 1;
- if (ctx->trashnc)
- imap->caps = imap->rcaps & ~(1 << LITERALPLUS);
- } else {
- box = gctx->name;
- prefix = !strcmp(box, "INBOX") ? "" : ctx->prefix;
- cb.create = 0;
- }
- cb.ctx = uid;
+ box = gctx->name;
+ prefix = !strcmp(box, "INBOX") ? "" : ctx->prefix;
+ cb.create = 0;
ret = imap_exec_m(ctx, &cb, "APPEND \"%s%s\" %s", prefix, box, flagstr);
imap->caps = imap->rcaps;
if (ret != DRV_OK)
return ret;
- if (!uid)
- ctx->trashnc = 0;
- else
- gctx->count++;
+ gctx->count++;
return DRV_OK;
}
@@ -1483,7 +1354,6 @@ int main(int argc, char **argv)
{
struct msg_data all_msgs, msg;
struct store *ctx = NULL;
- int uid = 0;
int ofs = 0;
int r;
int total, n = 0;
@@ -1491,9 +1361,6 @@ int main(int argc, char **argv)
git_extract_argv0_path(argv[0]);
- /* init the random number generator */
- arc4_init();
-
setup_git_directory_gently(&nongit_ok);
git_config(git_imap_config, NULL);
@@ -1540,7 +1407,7 @@ int main(int argc, char **argv)
break;
if (server.use_html)
wrap_in_html(&msg);
- r = imap_store_msg(ctx, &msg, &uid);
+ r = imap_store_msg(ctx, &msg);
if (r != DRV_OK)
break;
n++;
--
1.6.4
^ permalink raw reply related
* [PATCH v3 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-3-git-send-email-kusmabite@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 37 ++++++++++++++++---------------------
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 7216453..dc3da98 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -24,6 +24,7 @@
#include "cache.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
@@ -940,8 +941,7 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
struct imap_store *ctx;
struct imap *imap;
char *arg, *rsp;
- int s = -1, a[2], preauth;
- pid_t pid;
+ int s = -1, preauth;
ctx = xcalloc(sizeof(*ctx), 1);
@@ -952,29 +952,24 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
/* open connection to IMAP server */
if (srvc->tunnel) {
- imap_info("Starting tunnel '%s'... ", srvc->tunnel);
+ const char *argv[4];
+ struct child_process tunnel = {0};
- if (socketpair(PF_UNIX, SOCK_STREAM, 0, a)) {
- perror("socketpair");
- exit(1);
- }
+ imap_info("Starting tunnel '%s'... ", srvc->tunnel);
- pid = fork();
- if (pid < 0)
- _exit(127);
- if (!pid) {
- if (dup2(a[0], 0) == -1 || dup2(a[0], 1) == -1)
- _exit(127);
- close(a[0]);
- close(a[1]);
- execl("/bin/sh", "sh", "-c", srvc->tunnel, NULL);
- _exit(127);
- }
+ argv[0] = "/bin/sh";
+ argv[1] = "-c";
+ argv[2] = srvc->tunnel;
+ argv[3] = NULL;
- close(a[0]);
+ tunnel.argv = argv;
+ tunnel.in = -1;
+ tunnel.out = -1;
+ if (start_command(&tunnel))
+ die("cannot start proxy %s", argv[0]);
- imap->buf.sock.fd[0] = a[1];
- imap->buf.sock.fd[1] = dup(a[1]);
+ imap->buf.sock.fd[0] = tunnel.out;
+ imap->buf.sock.fd[1] = tunnel.in;
imap_info("ok\n");
} else {
--
1.6.4
^ permalink raw reply related
* [PATCH v3 4/8] imap-send: fix compilation-error on Windows
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-4-git-send-email-kusmabite@gmail.com>
mmsystem.h (included from windows.h) defines DRV_OK to 1. To avoid
an error due to DRV_OK redefenition, this patch undefines the old
definition (i.e the one from mmsystem.h) before defining DRV_OK.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index dc3da98..07f86ce 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -94,6 +94,7 @@ struct msg_data {
unsigned int crlf:1;
};
+#undef DRV_OK
#define DRV_OK 0
#define DRV_MSG_BAD -1
#define DRV_BOX_BAD -2
--
1.6.4
^ permalink raw reply related
* [PATCH v3 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-5-git-send-email-kusmabite@gmail.com>
Since the POSIX-specific tunneling code has been replaced
by the run-command API (and a compile-error has been
cleaned away), we can now enable imap-send on Windows
builds.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index fea237b..3ddb3b3 100644
--- a/Makefile
+++ b/Makefile
@@ -365,6 +365,7 @@ PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
PROGRAMS += git-upload-pack$X
PROGRAMS += git-var$X
+PROGRAMS += git-imap-send$X
# List built-in command $C whose implementation cmd_$C() is not in
# builtin-$C.o but is linked in as part of some other command.
@@ -1075,7 +1076,6 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
- PROGRAMS += git-imap-send$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
--
1.6.4
^ permalink raw reply related
* [PATCH v3 7/8] mingw: enable OpenSSL
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-7-git-send-email-kusmabite@gmail.com>
Since we have OpenSSL in msysgit now, enable it to support SSL
encryption for imap-send.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 3ddb3b3..e416fdb 100644
--- a/Makefile
+++ b/Makefile
@@ -952,7 +952,6 @@ else
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
--
1.6.4
^ permalink raw reply related
* [PATCH v3 6/8] mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-6-git-send-email-kusmabite@gmail.com>
SSL_set_fd (and friends) expects a OS file handle on Windows, not
a file descriptor as on UNIX(-ish).
This patch makes the Windows version of SSL_set_fd behave like the
UNIX versions, by calling _get_osfhandle on it's input.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.h | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..6907345 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -124,6 +124,27 @@ static inline int waitpid(pid_t pid, int *status, unsigned options)
return -1;
}
+#ifndef NO_OPENSSL
+#include <openssl/ssl.h>
+static inline int mingw_SSL_set_fd(SSL *ssl, int fd)
+{
+ return SSL_set_fd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_fd mingw_SSL_set_fd
+
+static inline int mingw_SSL_set_rfd(SSL *ssl, int fd)
+{
+ return SSL_set_rfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_rfd mingw_SSL_set_rfd
+
+static inline int mingw_SSL_set_wfd(SSL *ssl, int fd)
+{
+ return SSL_set_wfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_wfd mingw_SSL_set_wfd
+#endif
+
/*
* implementations of missing functions
*/
--
1.6.4
^ permalink raw reply related
* [PATCH v3 8/8] MSVC: Enable OpenSSL, and translate -lcrypto
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Marius Storm-Olsen, Erik Faye-Lund
In-Reply-To: <1255461925-2244-8-git-send-email-kusmabite@gmail.com>
From: Marius Storm-Olsen <mstormo@gmail.com>
We don't use crypto, but rather require libeay32 and
ssleay32. handle it in both the Makefile msvc linker
script, and the buildsystem generator.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 1 -
compat/vcbuild/scripts/clink.pl | 3 +++
contrib/buildsystems/engine.pl | 3 +++
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index e416fdb..b39bed4 100644
--- a/Makefile
+++ b/Makefile
@@ -900,7 +900,6 @@ ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index f9528c0..8a2112f 100644
--- a/compat/vcbuild/scripts/clink.pl
+++ b/compat/vcbuild/scripts/clink.pl
@@ -29,6 +29,9 @@ while (@ARGV) {
push(@args, "zlib.lib");
} elsif ("$arg" eq "-liconv") {
push(@args, "iconv.lib");
+ } elsif ("$arg" eq "-lcrypto") {
+ push(@args, "libeay32.lib");
+ push(@args, "ssleay32.lib");
} elsif ("$arg" =~ /^-L/ && "$arg" ne "-LTCG") {
$arg =~ s/^-L/-LIBPATH:/;
push(@args, $arg);
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 20bd061..d506717 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -315,6 +315,9 @@ sub handleLinkLine
$appout = shift @parts;
} elsif ("$part" eq "-lz") {
push(@libs, "zlib.lib");
+ } elsif ("$part" eq "-lcrypto") {
+ push(@libs, "libeay32.lib");
+ push(@libs, "ssleay32.lib");
} elsif ($part =~ /^-/) {
push(@lflags, $part);
} elsif ($part =~ /\.(a|lib)$/) {
--
1.6.4
^ permalink raw reply related
* [PATCH v3 0/8] imap-send: Windows support
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
Here's the 3rd iteration of my patches for
Windows-compatibility in imap-send.
- Patch 1-3 is about getting rid of or rewriting
code with portability issues.
- Patch 4 fixes a compilation error on Windows
- Patch 5 enables compilation of imap-send
- Patch 6-7 enables SSL-suport for mingw
- Patch 8 enables imap-send and SSL for msvc
Changes in this iteration compared to v2 are as
follows:
- A typo has been corrected in the commit message
for 1/8
- some unneeded preprocessor directives has been
deleted from patch 4/8
Thanks to Matt Kraai for reviewing v2
P.S:
Perhaps some people are only on the msysgit mailing
list and wonders where v2 went -- I forgot to CC
you guys last round, sorry about that! If you're
interrested, you can read the discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/129471
Erik Faye-Lund (6):
imap-send: use separate read and write fds
imap-send: use run-command API for tunneling
imap-send: fix compilation-error on Windows
imap-send: build imap-send on Windows
mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
mingw: enable OpenSSL
Jeff King (1):
imap-send: remove useless uid code
Marius Storm-Olsen (1):
MSVC: Enable OpenSSL, and translate -lcrypto
Makefile | 4 +-
compat/mingw.h | 21 ++++
compat/vcbuild/scripts/clink.pl | 3 +
contrib/buildsystems/engine.pl | 3 +
imap-send.c | 226 +++++++++------------------------------
5 files changed, 77 insertions(+), 180 deletions(-)
^ permalink raw reply
* How do I see all of my changes on a branch?
From: jonhud @ 2009-10-13 19:40 UTC (permalink / raw)
To: git
Hi,
We are using github (but that's more or less irrelevant, since I'm just
running git 1.6 locally on Ubuntu). Some time ago, I created a new branch
(release.2.2) and pushed it out to the remote repository. All the digging
through log, gitk, etc. has not made it possible for me to figure out the
commit (or point in time) at which I cut the branch.
What I want to do is to get a list of files (and/or diffs for those files)
from that point in time to HEAD on the branch. I understand that git-diff
--name-only is part of the solution. What I can't figure out is how to
pinpoint the first commit. So that's my first question... how do I do that?
To complicate things, I was also working on a side branch which I merged to
master before cutting the release.2.2 branch. In the best of all worlds, I
would trace my changes back to the point at which I cut *that* branch and
follow through the HEAD of release.2.2. How do I do that? I know I might
have to take 2 passes, one for release 2.2 and one for the side branch and
that's OK.
Thanks!
Jon
--
View this message in context: http://www.nabble.com/How-do-I-see-all-of-my-changes-on-a-branch--tp25879435p25879435.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Giuseppe Bilotta @ 2009-10-13 19:41 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Jakub Narebski
In-Reply-To: <4AD4C94A.9010909@gmail.com>
On Tue, Oct 13, 2009 at 8:39 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> On Monday 12 October 2009 08:19, Stephen Boyd wrote:
>>> The problem is I can't get it to work with UTF-8 characters. I'm not sure
>>> if it's my system or not, so I'm just posting here to see if others
>>> experience the same problem and if there's interest.
>>
>> Does it work if you use CGI::escape() on the author names when filling
>> the searchtext?
>
> This doesn't seem to work. Now I get %25 in front of the escaped
> characters. For example, a space is now %25%20.
>
> Can you reproduce my problem locally?
Reproduced, debugged, patch incoming (the problem is not in your patch
but in esc_param).
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH v3 5/8] imap-send: build imap-send on Windows
From: Johannes Sixt @ 2009-10-13 19:57 UTC (permalink / raw)
To: msysgit; +Cc: Erik Faye-Lund, git, Erik Faye-Lund
In-Reply-To: <1255461925-2244-6-git-send-email-kusmabite@gmail.com>
On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
> PROGRAMS += git-unpack-file$X
> PROGRAMS += git-upload-pack$X
> PROGRAMS += git-var$X
> +PROGRAMS += git-imap-send$X
This list is sorted. Please keep it so.
-- Hannes
^ permalink raw reply
* [PATCH] gitweb: fix esc_param
From: Giuseppe Bilotta @ 2009-10-13 19:51 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Stephen Boyd, Junio C Hamano, Giuseppe Bilotta
The custom CGI escaping done in esc_param failed to escape UTF-8
properly. Fix by using CGI::escape on each sequence of matched
characters instead of sprintf()ing a custom escaping for each byte.
Additionally, the space -> + escape was being escaped due to greedy
matching on the first substitution. Fix by adding space to the
list of characters not handled on the first substitution.
Finally, remove an unnecessary escaping of the + sign.
---
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
The issues with this routine were exposed by Stephen's
"author as search link" patch. This should fix them.
Since the idea of esc_param is to replicate CGI::escape except for the /
character (if I read the comment correclty), a possible alternative
would be to just use CGI::escape on the whole string and then undo the
escaping for the / character.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6237865..6593e5c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1115,8 +1115,7 @@ sub to_utf8 {
# correct, but quoted slashes look too horrible in bookmarks
sub esc_param {
my $str = shift;
- $str =~ s/([^A-Za-z0-9\-_.~()\/:@])/sprintf("%%%02X", ord($1))/eg;
- $str =~ s/\+/%2B/g;
+ $str =~ s/([^A-Za-z0-9\-_.~()\/:@ ]+)/CGI::escape($1)/eg;
$str =~ s/ /\+/g;
return $str;
}
--
1.6.3.rc1.192.gdbfcb
^ permalink raw reply related
* Re: [PATCH v3 3/8] imap-send: use run-command API for tunneling
From: Johannes Sixt @ 2009-10-13 19:59 UTC (permalink / raw)
To: msysgit; +Cc: Erik Faye-Lund, git, Erik Faye-Lund
In-Reply-To: <1255461925-2244-4-git-send-email-kusmabite@gmail.com>
On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
> + argv[0] = "/bin/sh";
> + argv[1] = "-c";
> + argv[2] = srvc->tunnel;
> + argv[3] = NULL;
Is there a particular reason that you run "/bin/sh" with a path? I doubt that
this works on Windows.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Christian Couder @ 2009-10-13 20:06 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.2.00.0910131116300.5105@dr-wily.mit.edu>
On Tuesday 13 October 2009, Anders Kaseorg wrote:
> @@ -311,8 +311,7 @@ bisect_reset() {
> }
> case "$#" in
> 0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
> - 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
> - die "$1 does not seem to be a valid branch"
> + 1) git rev-parse --verify "$1^{commit}" || exit
> branch="$1" ;;
> *)
> usage ;;
I agree with the purpose of the patch but I think something like the
following would be better:
@@ -311,8 +311,8 @@ bisect_reset() {
}
case "$#" in
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
- die "$1 does not seem to be a valid branch"
+ 1) git rev-parse --quiet --verify "$1^{commit}" > /dev/null ||
+ die "'$1' does not seem to point to a valid commit"
branch="$1" ;;
*)
usage ;;
It would give a better error message when "git rev-parse" fails instead of:
fatal: Needed a single revision
and it would not print the SHA1 from "$1^{commit}" when "git rev-parse"
succeeds.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH v3 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-13 20:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <200910132157.41279.j6t@kdbg.org>
On Tue, Oct 13, 2009 at 9:57 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
>> PROGRAMS += git-unpack-file$X
>> PROGRAMS += git-upload-pack$X
>> PROGRAMS += git-var$X
>> +PROGRAMS += git-imap-send$X
>
> This list is sorted. Please keep it so.
>
> -- Hannes
>
Aha, I didn't notice! Thanks, I'll fix :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 20:09 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git
In-Reply-To: <200910132206.18460.chriscool@tuxfamily.org>
On Tue, 13 Oct 2009, Christian Couder wrote:
> + 1) git rev-parse --quiet --verify "$1^{commit}" > /dev/null ||
> + die "'$1' does not seem to point to a valid commit"
>
> It would give a better error message when "git rev-parse" fails instead of:
>
> fatal: Needed a single revision
>
> and it would not print the SHA1 from "$1^{commit}" when "git rev-parse"
> succeeds.
Oh, oops, I somehow lost the > /dev/null in my version.
But as for the ‘git rev-parse’ error being confusing, why don’t we fix
‘git rev-parse’ instead?
Anders
^ permalink raw reply
* [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path
From: Per Strandh @ 2009-10-13 20:09 UTC (permalink / raw)
To: git@vger.kernel.org
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
^ permalink raw reply related
* Re: quote in help code example
From: Thomas Rast @ 2009-10-13 20:15 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bill lam, git
In-Reply-To: <20091013153031.GX23777@genesis.frugalware.org>
[-- Attachment #1: Type: Text/Plain, Size: 2721 bytes --]
Miklos Vajna wrote:
> On Tue, Oct 13, 2009 at 10:06:23PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > 2. now the .ft pair fixed but it still displayed incorrect quote.
> >
> > git filter-branch --tree-filter ´rm filename´ HEAD
> >
> > it should be 'rm filename' not ´rm filename´
>
> I can reproduce that here as well, that's how it is in the official
> manpages as well (see the man branch), so that's not specific to your
> system.
Same here. The patch below is a band-aid fix that works for me, but
I'd rather have it tested on various docbook/asciidoc combinations if
anyone still runs them.
My findings so far were that asciidoc correctly turns the apostrophe
into an ' entity in the .xml output, and xmlto then turns it into
\' instead of just ' in the troff output. Then, if the terminal
appears to support Unicode (this can be disabled with LC_ALL=C or
such) the formatter turns it into a "real" apostrophe that, of course,
is not understood by any ASCII-based tool.
So far so good, and sounded like an easy debugging job, right? Not
so. The buzzword-compliance people apparently felt it would be nice
to wrap a bad joke of a language in the bad joke of a language that
XML already is, and thus was XSL invented. Deep in the horrors of
these XSL files, in my case in
/usr/share/xml/docbook/stylesheet/nwalsh/1.75.2/manpages/other.xsl
there's a template that, according to the comment near it, maltreats
our apostrophes:
* The backslash, dot, dash, and apostrophe (\, ., -, ') characters
* have special meaning for roff, so before we do any other
* processing, we must escape those characters where they appear in
* the source content.
The patch below just replaces said template with a no-op for git's
manpage creation. I have not been able to substantiate the claim that
apostrophes are special, and in fact with the patch my manpages look
fine. Then again I don't know anything about roff syntax either, and
manuals seem a bit hard to come by.
Grrr.
diff --git i/Documentation/manpage-base.xsl w/Documentation/manpage-base.xsl
index a264fa6..7c14469 100644
--- i/Documentation/manpage-base.xsl
+++ w/Documentation/manpage-base.xsl
@@ -7,6 +7,11 @@
<xsl:param name="man.output.quietly" select="1"/>
<xsl:param name="refentry.meta.get.quietly" select="1"/>
+<xsl:template name="escape.apostrophe">
+ <xsl:param name="content"/>
+ <xsl:value-of select="$content"/>
+</xsl:template>
+
<!-- convert asciidoc callouts to man page format;
git.docbook.backslash and git.docbook.dot params
must be supplied by another XSL file or other means -->
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
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