* [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 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 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 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
* 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
* 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: [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 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: 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: 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: Israel Garcia @ 2009-10-13 18:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091013174913.GV9261@spearce.org>
BTW, is there any git-dump or git-backup command to do some kind of
backup I'm looking for?
regards,
Israel.
On 10/13/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
>> Sorry to ask again, but I'm a little confuse about how git work in my
>> case.
>> I use gitosis on a server where I have all repos
>> (/usr/local/git/repositories/), so different people clone their repos
>> on their computers. What I want is to backup, on gitosis server, all
>> repos in /backups/git/repositories/ after every commit. So, my
>> questions are:
>>
>> Do I have to run these two comands on tha gitosis server?
>
> Yes.
>
>> The post-commit are execute on gitosis server or on the remote pc?
>
> Actually, you need the post-update hook. post-commit doesn't run
> on the gitosis server.
>
> I suggested post-commit because I thought you were talking about
> backing up your local working directory each time you called
> "git commit". But since you are actually backing up every
> "git push" you need to use the hooks invoked by that instead.
>
> --
> Shawn.
>
--
Regards;
Israel Garcia
^ permalink raw reply
* Efficient cloning from svn (with multiple branches/tags subdirs)
From: Bruno Harbulot @ 2009-10-13 18:13 UTC (permalink / raw)
To: git
Hello,
I'm trying to clone an existing subversion repository (Restlet:
http://restlet.tigris.org/source/browse/). I'm using Git 1.6.5. The
layout of the project is like this:
trunk/
branches/1.0
branches/1.1
tags/1.0/1.0b1
tags/1.0/1.0b2
...
tags/1.0/1.0.1
...
tags/1.1/1.1.0
tags/1.1/1.1.1
...
Therefore, I've tried to use this (with and without '-T trunk', but
that's a separate problem):
git init
git svn init --prefix=svn/ -t tags/1.0 -t tags/1.1 -t tags/1.2 -t
tags/2.0 -b branches/1.0 -b branches/1.1
http://restlet.tigris.org/svn/restlet
git svn fetch
This takes a while (I've had to interrupt this) and this creates a
number of branches such as:
remotes/svn/tags/1.0b1
remotes/svn/tags/1.0b2
remotes/svn/tags/1.0b3
remotes/svn/tags/1.0b3@1883
remotes/svn/tags/1.0b3@323
What surprises me is that it looks like it's looping over and over,
since sometimes it starts back from SVN revision 1 when it's trying to
import a new tag.
Tt starts like this:
>
> Checked through r101
> Checked through r201
> Checked through r301
> A www/index.html
> r1 = 2ec77afc2e491e2b7c825cb685101e3bcbe7a8f7 (refs/remotes/svn/tags/1.0b1@312)
> A source/impl/License.txt
> A source/impl/Copyright.txt
> A source/impl/org/restlet/UniformInterface.java
> A source/impl/org/restlet/RestletException.java
> ...
Then, when it reaches r312, it starts again at r1:
> r312 = 5b40558b5bb2b4b04f9520f89b699ff6b0f50cdb (refs/remotes/svn/tags/1.0b1@312)
> r313 = 7ebcbd9da535cfdc23aacb612271e625445a7516 (refs/remotes/svn/tags/1.0b1@1881)
> r1882 = aed1582d4868a1be8ae8fcc0f15546822099f339 (refs/remotes/svn/tags/1.0b1)
> Checked through r101
> Checked through r201
> Checked through r301
> A www/index.html
> r1 = 2ec77afc2e491e2b7c825cb685101e3bcbe7a8f7 (refs/remotes/svn/tags/1.0b2@321)
> A source/impl/License.txt
> A source/impl/Copyright.txt
> A source/impl/org/restlet/UniformInterface.java
> A source/impl/org/restlet/RestletException.java
> A source/impl/org/restlet/AbstractRestlet.java
> A source/impl/org/restlet/connector/Resolver.java
(And so on for each tag).
This seems particularly inefficient and unfriendly for the resource
provider (I stopped as soon as I noticed). Is there a better way to do this?
Best wishes,
Bruno.
^ permalink raw reply
* Re: [RFC PATCH v2 01/16] pkt-line: Add strbuf based functions
From: Shawn O. Pearce @ 2009-10-13 18:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AD42C52.80205@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> > -int packet_read_line(int fd, char *buffer, unsigned size)
> > +static int packet_length(unsigned *ret_len, const char *linelen)
...
> > + *ret_len = len;
> > + return 0;
> > +}
>
> len can be signed: Valid lengths fit into a signed int. Then you can
> 'return len;' on success and 'return -1;' on failure and don't need return
> the result by reference. packet_read_line() ultimately converts it to int
> anyway:
Great catch, thanks. This is actually from a prior version of code
where I was exposing this function to callers... but even then the
method could have just returned int with the value because as you
point out, all valid lengths fit in int and must be >= 0.
--
Shawn.
^ permalink raw reply
* Re: backup git repo on every commit
From: Israel Garcia @ 2009-10-13 18:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091013174913.GV9261@spearce.org>
On 10/13/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
>> Sorry to ask again, but I'm a little confuse about how git work in my
>> case.
>> I use gitosis on a server where I have all repos
>> (/usr/local/git/repositories/), so different people clone their repos
>> on their computers. What I want is to backup, on gitosis server, all
>> repos in /backups/git/repositories/ after every commit. So, my
>> questions are:
>>
>> Do I have to run these two comands on tha gitosis server?
>
> Yes.
>
>> The post-commit are execute on gitosis server or on the remote pc?
>
> Actually, you need the post-update hook. post-commit doesn't run
> on the gitosis server.
>
> I suggested post-commit because I thought you were talking about
> backing up your local working directory each time you called
> "git commit". But since you are actually backing up every
> "git push" you need to use the hooks invoked by that instead.
Hi Shawn,
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.
Thanks in advance.
regrads
Israel.
>
> --
> Shawn.
>
--
Regards;
Israel Garcia
^ permalink raw reply
* Re: [RFC PATCH v2 07/16] remote-helpers: Fetch more than one ref in a batch
From: Shawn O. Pearce @ 2009-10-13 18:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910122326130.32515@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Mon, 12 Oct 2009, Shawn O. Pearce wrote:
> > Some network protocols (e.g. native git://) are able to fetch more
> > than one ref at a time and reduce the overall transfer cost by
> > combining the requests into a single exchange. Instead of feeding
> > each fetch request one at a time to the helper, feed all of them
> > at once so the helper can decide whether or not it should batch them.
> >
> > Because 'fetch' was already released in 1.6.5 we introduce the new
> > fetch-multiple capability/command to signal that the helper wants
> > to use batch oriented approach to fetching refs.
>
> In 1.6.5, there's no way to call a helper other than git-remote-curl, and
> no way to call git-remote-curl unless 1.6.5 was built with it. So I think
> the protocol is not set in stone quite yet. It's documentated for being an
> API, and it's supposed to be that, but it's not quite there in this
> version.
I originally had this change as just redefining "fetch" to be batch
oriented and requiring a blank line to terminate the batch group,
but reconsidered when 1.6.5 shipped and I realized this code was
in 1.6.5.
But, yea, you are right, with no way to invoke anything except
remote-curl there really isn't that much of a problem if we change
the protocol.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 09/16] Move WebDAV HTTP push under remote-curl
From: Johannes Schindelin @ 2009-10-13 18:04 UTC (permalink / raw)
To: Mike Hommey; +Cc: Shawn O. Pearce, git, Daniel Barkalow, Tay Ray Chuan
In-Reply-To: <20091013044141.GA18961@glandium.org>
Hi,
On Tue, 13 Oct 2009, Mike Hommey wrote:
> On Mon, Oct 12, 2009 at 07:25:08PM -0700, Shawn O. Pearce wrote:
> > The remote helper interface now supports the push capability, which
> > can be used to ask the implementation to push one or more specs to the
> > remote repository. For remote-curl we implement this by calling the
> > existing WebDAV based git-http-push executable.
> >
> > Internally the helper interface uses the push_refs transport hook so
> > that the complexity of the refspec parsing and matching can be reused
> > between remote implementations. When possible however the helper
> > protocol uses source ref name rather than the source SHA-1, thereby
> > allowing the helper to access this name if it is useful.
>
> It's been a while I haven't followed changes in the remote code but this
> looks nice, though I haven't checked thoroughly. I guess the next step
> would be to kill http-push as an external program.
Ilari made signs on IRC that he got something working. After, ahem,
saying a few things about the design of the remote helpers.
Ciao,
Dscho
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-13 17:49 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910130943j40c12902o760e463e7a8ce8fa@mail.gmail.com>
Israel Garcia <igalvarez@gmail.com> wrote:
> Sorry to ask again, but I'm a little confuse about how git work in my case.
> I use gitosis on a server where I have all repos
> (/usr/local/git/repositories/), so different people clone their repos
> on their computers. What I want is to backup, on gitosis server, all
> repos in /backups/git/repositories/ after every commit. So, my
> questions are:
>
> Do I have to run these two comands on tha gitosis server?
Yes.
> The post-commit are execute on gitosis server or on the remote pc?
Actually, you need the post-update hook. post-commit doesn't run
on the gitosis server.
I suggested post-commit because I thought you were talking about
backing up your local working directory each time you called
"git commit". But since you are actually backing up every
"git push" you need to use the hooks invoked by that instead.
--
Shawn.
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Tony Finch @ 2009-10-13 17:46 UTC (permalink / raw)
To: Jeff King; +Cc: sylvain, Alex Riesen, Steven Noonan, git
In-Reply-To: <20091012183519.GA10686@coredump.intra.peff.net>
On Mon, 12 Oct 2009, Jeff King wrote:
>
> $ cd /
> $ git init
> $ cd /etc/whatever
> $ git add .
One reason that you don't want to do this (even if it does work) is that
careless use of git (e.g. by a user who is not the sysadmin playing with
git in their home directory) is going to find the root repository when you
expect it not to find any repository.
Also, I suggest this little wrapper script:
http://dotat.at/cgi/git?p=git-deploy.git;a=blob;f=git-root.sh
Tony.
--
f.anthony.n.finch <dot@dotat.at> http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
^ permalink raw reply
* Re: backup git repo on every commit
From: Israel Garcia @ 2009-10-13 16:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091012143043.GJ9261@spearce.org>
Hi Shawn,
Sorry to ask again, but I'm a little confuse about how git work in my case.
I use gitosis on a server where I have all repos
(/usr/local/git/repositories/), so different people clone their repos
on their computers. What I want is to backup, on gitosis server, all
repos in /backups/git/repositories/ after every commit. So, my
questions are:
Do I have to run these two comands on tha gitosis server? Or on a
remote computer?
git --git-dir=/backup/project.git init
git remote add --mirror backup /backup/project.git
The post-commit are execute on gitosis server or on the remote pc?
I'm completely new using git so I'm a little confuse.. sorry for asking again.
thanks a lot.
regards
Israel.
On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
>> That's OK, but I want to backup my git repo locally
>
> Just change the path of the backup remote (that final argument to
> git remote add) to point to the local directory.
>
> Though I guess you would also need to run git init there, e.g.:
>
> git --git-dir=/backup/project.git init
> git remote add --mirror backup /backup/project.git
>
> # and create the hook as below
>
> Of course, backup to another folder on the same disk isn't a backup
> at all, the disk can still fail and lose both repositories.
>
>> On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > Israel Garcia <igalvarez@gmail.com> wrote:
>> >> Which is the simplest way to backup a git repository after every
>> >> commit?
>> >
>> > Add a commit hook to push to another location, e.g.:
>> >
>> > git remote add --mirror backup you@another.host:path/to/backup.git
>> >
>> > cat >.git/hooks/post-commit
>> > #!/bin/sh
>> > git push backup
>> > ^D
>> >
>> > chmod a+x .git/hooks/post-commit
>
> --
> Shawn.
>
--
Regards;
Israel Garcia
^ permalink raw reply
* Re: [JGit-io-RFC-PATCH v2 2/4] Add JGit IO SPI and default implementation
From: Imran M Yousuf @ 2009-10-13 15:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, egit-dev, Imran M Yousuf
In-Reply-To: <20091013151522.GR9261@spearce.org>
Hi Shawn,
Firstly thanks for the reply, my comments are inline.
On Tue, Oct 13, 2009 at 10:15 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Imran M Yousuf <imyousuf@gmail.com> wrote:
>> Firstly, I am sorry but I am not intelligent enough to perceive, how
>> do the user decide which instance of Config to use? I personally think
>> that there is no API to achieve what you just mentioned :(; i.e. the
>> user will have know CassandraConfig directly.
>
> Yes. Well, almost.
>
> The user will have to know that s/he wants a CassandraRepository or
> a JdbcRepository in order to obtain the abstract Repository handle.
> Each of these will need different configuration, possibly data which
> is too complex to simply cram into a URL string, so I was expecting
> the application would construct the concrete Repository class and
> configure it with the proper arguments required for contact with
> the underlying storage.
>
> Since the Repository wants several things associated with it, each
> concrete Repository class knows what concrete Config, ObjectDatabase
> and RefDatabase it should create. Those concrete classes know how
> to read a repository stored on that medium.
>
Hmm, when trying to come up with an API, where I essentially wanted a
to abstract all records, I noticed that everything uses java.io.File
and I never actually thought in this line.
Well, I was thinking of in terms of URI as I think Git and in turn
JGit (some how feels so) follows REST and from my understanding of git
storage (which very well could be incorrect) URI could be a perfect
match. Question of how a implementation requiring configuration be fed
to the SPI manager is simple before JGit is used the instance it self
is registered to the manager. So e.g. for JDBC the URI could very well
look like - jdbc://etc/X11/ for a repo path and the JDBC implementor
will already know the connection config specs etc. so there is no need
to cramp in all info in the URL.
>> Secondly, I instead was
>> thinking of porting JGit for that matter to any system supporting
>> streams (not any specific sub-class of them), such HBase/BigTable or
>> HDFS anything.... Thirdly, I think we actually have several task in
>> hand and I would state them as -
>>
>> 1. First introduce the I/O API such that it completely replaces java.io.File
>> 2. Secondly segregate persistence of for config (or config like
>> objects) and introduce a SPI for them for smarter storage.
>
> Supporting streams on an arbitrary backend is difficult. DHTs like
> BigTable/Cassandra aren't very good at providing streams, they tend
> to have a limit on how big a row can be. They tend to have very
> slow read latencies, but can return a small block of consecutive
> rows in one reply.
>
> I want to talk about the DHT backend more with Scott Chacon at the
> GitTogether, but I have this feeling that just laying a pack file
> into a stream in a DHT is going to perform very poorly.
>
> Likewise JDBC has similar performance problems, you can only store
> so much in a row before performance of the RDBMS drops off sharply.
> You can get a handful of rows in a single reply pretty efficiently,
> but each query takes longer than you'd like. Yes, there is often
> a BLOB type that allows large file storage, but different RDBMS
> support these differently and have different performance when it
> comes to accessing the BLOB types. Some don't support random access,
> some do. Even if they do support random access read, writing a large
> 2 GiB repository's pack file after repacking it would take ages.
>
> Once you get outside of the pack file, *everything* else git stores
> is either a loose object, or very tiny text files (aka refs, their
> logs, config). The loose object case should be handled by the same
> thing that handles the bulk of the object store, loose objects are
> a trivial thing compared to packed objects.
>
> The refs, the ref logs, and the config are all structured text.
> If you lay a Git repository down into a database of some sort,
> I think its reasonable to expect that the schema for these items
> in that database permits query and update using relatively native
> primitives in that database. E.g. if you put this in SQL I would
> expect a schema like:
>
> CREATE TABLE refs (
> repository_id INT NOT NULL
> ,name VARCHAR(255) NOT NULL
> ,id CHAR(40)
> ,target VARCHAR(255)
> ,PRIMARY KEY (repository_id, name)
> ,CHECK (id IS NOT NULL OR target IS NOT NULL));
>
> CREATE TABLE reflogs (
> repository_id INT NOT NULL
> ,name VARCHAR(255) NOT NULL
> ,old_id CHAR(40) NOT NULL
> ,new_id CHAR(40) NOT NULL
> ,committer_name VARCHAR(255)
> ,committer_email VARCHAR(255)
> ,committer_date TIMESTAMP NOT NULL
> ,message VARCHAR(255)
> ,PRIMARY KEY (repository_id, name, committer_date));
>
> CREATE TABLE config (
> repository_id INT NOT NULL
> ,section VARCHAR(255) NOT NULL
> ,group VARCHAR(255)
> ,name VARCHAR(255) NOT NULL
> ,value VARCHAR(255)
> ,PRIMARY KEY(repository_id, section, group, name, value))
>
> This makes it easier to manipulate settings, you can use direct
> SQL UPDATE to modify the configuration, or SELECT to scan through
> reflogs. Etc.
>
> If we just threw everything as streams into the database this
> would be a lot more difficult to work with through the database's
> own native query and update interface. You'd lose alot of the
> benefits of using a database, but still be paying the massive price
> in performance.
>
To be honest I understood your point the last time you mentioned it
:). I agree with performance part fully and I too have doubts, that is
why while you were mentioning HBase, I was HDFS :) and I was actually
thinking of in terms of FS. But after your elaboration, it just makes
more sense for the changes -
* Firstly we decouple from a particular FS and have our own I/O, for
packed and loose objects, so that we can easily retain the current
behavior.
* Then we first rework the key objects, e.g. Refs, Configs etc. to
segregate their persistence, that is introduce their persistence layer
which should friendly enough for native operations for platforms such
as RDBMS or HBase or BigTable. Using packs will depend of setup and
repositories, but certain implementations
* We implement this SPI to support different persistence platforms then :).
The thing is I first want to make JGit independent of java.io.File :),
thats was my motto to start with, but you showed me a path beyond that
:) and that is free from java.io.File and optimized persistence API
:). I want to have them both and let the implementor choose how to
implement it :).
>> I am not thinking of storing "only" the bare content of a git
>> repository, but I intent to be able to also store the versioned
>> contents it self as well.
>
> When I say "bare repository" I only mean a repository without a
> working directory. It still holds the complete revision history.
> If you wanted a git repository on Cassandra but wanted to actually
> have a working directory checkout, you'd need the local filesystem
> for the checkout and .git/index, but could otherwise keep the objects
> and refs in Cassandra. Its nuts... but in theory one could do it.
>
My requirement also involves needing to check it out on HDFS :), that
is why I was mentioning it, but it could be a different topic other
than that of JGit.
Eagerly waiting for a reply.
Thank you,
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
^ permalink raw reply
* Re: quote in help code example
From: Miklos Vajna @ 2009-10-13 15:30 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091013140622.GA3927@debian.b2j>
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
On Tue, Oct 13, 2009 at 10:06:23PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> I run these commands
>
> make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr all doc info
> sudo make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr install install-doc install-html install-info
>
> 1. did I need to set ASCIIDOC_NO_ROFF in both lines?
In general, it's always a good idea, though I don't think it's necessary
for the second time.
> 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.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 15:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaazw6uyi.fsf@alter.siamese.dyndns.org>
‘git bisect reset’ accepts an optional argument specifying a branch to
check out after cleaning up the bisection state. This lets you
specify an arbitrary commit.
In particular, this provides a way to clean the bisection state
without moving HEAD: ‘git bisect reset HEAD’. This may be useful if
you are not interested in the state before you began a bisect,
especially if checking out the old commit would be expensive and
invalidate most of your compiled tree.
Clarify the ‘git bisect reset’ documentation to explain this optional
argument, which was previously mentioned only in the usage message.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
Documentation/git-bisect.txt | 23 +++++++++++++++++------
git-bisect.sh | 7 +++----
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 63e7a42..d2ffae0 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -20,7 +20,7 @@ on the subcommand:
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [(<rev>|<range>)...]
- git bisect reset [<branch>]
+ git bisect reset [<commit>]
git bisect visualize
git bisect replay <logfile>
git bisect log
@@ -81,16 +81,27 @@ will have been left with the first bad kernel revision in "refs/bisect/bad".
Bisect reset
~~~~~~~~~~~~
-To return to the original head after a bisect session, issue the
-following command:
+After a bisect session, to clean up the bisection state and return to
+the original HEAD, issue the following command:
------------------------------------------------
$ git bisect reset
------------------------------------------------
-This resets the tree to the original branch instead of being on the
-bisection commit ("git bisect start" will also do that, as it resets
-the bisection state).
+By default, this will return your tree to the commit that was checked
+out before `git bisect start`. (A new `git bisect start` will also do
+that, as it cleans up the old bisection state.)
+
+With an optional argument, you can return to a different commit
+instead:
+
+------------------------------------------------
+$ git bisect reset <commit>
+------------------------------------------------
+
+For example, `git bisect reset HEAD` will leave you on the current
+bisection commit and avoid switching commits at all, while `git bisect
+reset bisect/bad` will check out the first bad revision.
Bisect visualize
~~~~~~~~~~~~~~~~
diff --git a/git-bisect.sh b/git-bisect.sh
index 6f6f039..0c56c26 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -13,8 +13,8 @@ git bisect skip [(<rev>|<range>)...]
mark <rev>... untestable revisions.
git bisect next
find next bisection to test and check it out.
-git bisect reset [<branch>]
- finish bisection search and go back to branch.
+git bisect reset [<commit>]
+ finish bisection search and go back to commit.
git bisect visualize
show bisect status in gitk.
git bisect replay <logfile>
@@ -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 ;;
--
1.6.5
^ permalink raw reply related
* Re: [JGit-io-RFC-PATCH v2 2/4] Add JGit IO SPI and default implementation
From: Shawn O. Pearce @ 2009-10-13 15:15 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git, egit-dev, Imran M Yousuf
In-Reply-To: <7bfdc29a0910121830y4dc9b3efpe17860e04457988d@mail.gmail.com>
Imran M Yousuf <imyousuf@gmail.com> wrote:
> Firstly, I am sorry but I am not intelligent enough to perceive, how
> do the user decide which instance of Config to use? I personally think
> that there is no API to achieve what you just mentioned :(; i.e. the
> user will have know CassandraConfig directly.
Yes. Well, almost.
The user will have to know that s/he wants a CassandraRepository or
a JdbcRepository in order to obtain the abstract Repository handle.
Each of these will need different configuration, possibly data which
is too complex to simply cram into a URL string, so I was expecting
the application would construct the concrete Repository class and
configure it with the proper arguments required for contact with
the underlying storage.
Since the Repository wants several things associated with it, each
concrete Repository class knows what concrete Config, ObjectDatabase
and RefDatabase it should create. Those concrete classes know how
to read a repository stored on that medium.
> Secondly, I instead was
> thinking of porting JGit for that matter to any system supporting
> streams (not any specific sub-class of them), such HBase/BigTable or
> HDFS anything.... Thirdly, I think we actually have several task in
> hand and I would state them as -
>
> 1. First introduce the I/O API such that it completely replaces java.io.File
> 2. Secondly segregate persistence of for config (or config like
> objects) and introduce a SPI for them for smarter storage.
Supporting streams on an arbitrary backend is difficult. DHTs like
BigTable/Cassandra aren't very good at providing streams, they tend
to have a limit on how big a row can be. They tend to have very
slow read latencies, but can return a small block of consecutive
rows in one reply.
I want to talk about the DHT backend more with Scott Chacon at the
GitTogether, but I have this feeling that just laying a pack file
into a stream in a DHT is going to perform very poorly.
Likewise JDBC has similar performance problems, you can only store
so much in a row before performance of the RDBMS drops off sharply.
You can get a handful of rows in a single reply pretty efficiently,
but each query takes longer than you'd like. Yes, there is often
a BLOB type that allows large file storage, but different RDBMS
support these differently and have different performance when it
comes to accessing the BLOB types. Some don't support random access,
some do. Even if they do support random access read, writing a large
2 GiB repository's pack file after repacking it would take ages.
Once you get outside of the pack file, *everything* else git stores
is either a loose object, or very tiny text files (aka refs, their
logs, config). The loose object case should be handled by the same
thing that handles the bulk of the object store, loose objects are
a trivial thing compared to packed objects.
The refs, the ref logs, and the config are all structured text.
If you lay a Git repository down into a database of some sort,
I think its reasonable to expect that the schema for these items
in that database permits query and update using relatively native
primitives in that database. E.g. if you put this in SQL I would
expect a schema like:
CREATE TABLE refs (
repository_id INT NOT NULL
,name VARCHAR(255) NOT NULL
,id CHAR(40)
,target VARCHAR(255)
,PRIMARY KEY (repository_id, name)
,CHECK (id IS NOT NULL OR target IS NOT NULL));
CREATE TABLE reflogs (
repository_id INT NOT NULL
,name VARCHAR(255) NOT NULL
,old_id CHAR(40) NOT NULL
,new_id CHAR(40) NOT NULL
,committer_name VARCHAR(255)
,committer_email VARCHAR(255)
,committer_date TIMESTAMP NOT NULL
,message VARCHAR(255)
,PRIMARY KEY (repository_id, name, committer_date));
CREATE TABLE config (
repository_id INT NOT NULL
,section VARCHAR(255) NOT NULL
,group VARCHAR(255)
,name VARCHAR(255) NOT NULL
,value VARCHAR(255)
,PRIMARY KEY(repository_id, section, group, name, value))
This makes it easier to manipulate settings, you can use direct
SQL UPDATE to modify the configuration, or SELECT to scan through
reflogs. Etc.
If we just threw everything as streams into the database this
would be a lot more difficult to work with through the database's
own native query and update interface. You'd lose alot of the
benefits of using a database, but still be paying the massive price
in performance.
> I am not thinking of storing "only" the bare content of a git
> repository, but I intent to be able to also store the versioned
> contents it self as well.
When I say "bare repository" I only mean a repository without a
working directory. It still holds the complete revision history.
If you wanted a git repository on Cassandra but wanted to actually
have a working directory checkout, you'd need the local filesystem
for the checkout and .git/index, but could otherwise keep the objects
and refs in Cassandra. Its nuts... but in theory one could do it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 14:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vtyy3zo9m.fsf@alter.siamese.dyndns.org>
On Tue, 13 Oct 2009, Junio C Hamano wrote:
> I agree that "git bisect reset-and-detach-at-the-first-bad-one" would make
> a lot of sense.
Under my patch, that’s ‘git bisect reset bisect/bad’. Similar arguments
may be made as to whether that should or shouldn’t be a separate command
(although it’s less clear what to call it, in this case).
Anders
^ permalink raw reply
* Re: quote in help code example
From: bill lam @ 2009-10-13 14:06 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091013101916.GV23777@genesis.frugalware.org>
On Tue, 13 Oct 2009, Miklos Vajna wrote:
> On Tue, Oct 13, 2009 at 10:16:17AM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > > Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
> > > ASCIIDOC_NO_ROFF?
> > >
> > > Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
> >
> > I'm not familiar with how to twist git makefile. By adding a line to ./Makefile
> >
> > # Platform specific tweaks
> > #
> >
> > # We choose to avoid "if .. else if .. else .. endif endif"
> > # because maintaining the nesting to match is a pain. If
> > # we had "elif" things would have been much nicer...
> >
> > ASCIIDOC_NO_ROFF = YesPlease # <--- this line added
> > ifeq ($(uname_S),Linux)
> >
> > However, the man page still display the same
>
> Don't edit the Makefile, just use the command 'make
> ASCIIDOC_NO_ROFF=YesPlease'. Also make sure to do a 'make clean' in the
> Documentation dir to get the manpages rebuilt.
I run these commands
make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr all doc info
sudo make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr install install-doc install-html install-info
1. did I need to set ASCIIDOC_NO_ROFF in both lines?
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´
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ 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