* [PATCH v5 8/8] MSVC: Enable OpenSSL, and translate -lcrypto
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Marius Storm-Olsen, Erik Faye-Lund
In-Reply-To: <1256144691-2908-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 | 2 +-
compat/vcbuild/scripts/clink.pl | 3 +++
contrib/buildsystems/engine.pl | 3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 986483b..1e1a2f2 100644
--- a/Makefile
+++ b/Makefile
@@ -900,7 +900,7 @@ ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = 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.msysgit.0
^ permalink raw reply related
* [PATCH v5 6/8] mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-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.msysgit.0
^ permalink raw reply related
* [PATCH v5 4/8] imap-send: fix compilation-error on Windows
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-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 72ed640..69e6142 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.msysgit.0
^ permalink raw reply related
* [PATCH v5 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-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..0d13af3 100644
--- a/Makefile
+++ b/Makefile
@@ -354,6 +354,7 @@ EXTRA_PROGRAMS =
PROGRAMS += $(EXTRA_PROGRAMS)
PROGRAMS += git-fast-import$X
PROGRAMS += git-hash-object$X
+PROGRAMS += git-imap-send$X
PROGRAMS += git-index-pack$X
PROGRAMS += git-merge-index$X
PROGRAMS += git-merge-tree$X
@@ -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.msysgit.0
^ permalink raw reply related
* [PATCH v5 1/8] imap-send: remove useless uid code
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Jeff King, Erik Faye-Lund
In-Reply-To: <1256144691-2908-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.msysgit.0
^ permalink raw reply related
* [PATCH v5 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-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..72ed640 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] = "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.msysgit.0
^ permalink raw reply related
* [PATCH v5 0/8] imap-send: Windows support
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
Here's the 5th 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
The only change compared to the previous iteration
is that patch 7 and 8 enables NEEDS_CRYPTO_WITH_SSL.
Please note that I haven't tested Patch 8 with
NEEDS_CRYPTO_WITH_SSL under MSVC, as I don't have a
working setup with both msysgit and MSVC installed.
I'd love it if someone with such a working setup
could verify that it works, preferrably also with
BLK_SHA1 enabled.
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 | 6 +-
compat/mingw.h | 21 ++++
compat/vcbuild/scripts/clink.pl | 3 +
contrib/buildsystems/engine.pl | 3 +
imap-send.c | 226 +++++++++------------------------------
5 files changed, 79 insertions(+), 180 deletions(-)
^ permalink raw reply
* Re: drawbacks to svn server + git-svn vs git server?
From: Dmitry Potapov @ 2009-10-21 16:05 UTC (permalink / raw)
To: Pascal Obry; +Cc: Dexter Riley, git
In-Reply-To: <4ADF2666.1070908@obry.net>
On Wed, Oct 21, 2009 at 05:19:02PM +0200, Pascal Obry wrote:
> Le 21/10/2009 17:05, Dexter Riley a écrit :
>> Hello. My group is currently using subversion on our version control server,
>> but would like to move to git as a client. We are considering using
>> git-svn, to avoid revalidating the server software. My question is, are
>> there any major disadvantages to using git-svn versus git? I know that the
>> git repository would be smaller. I'm more concerned about possible svn
>> repository corruption, performance when pushing large merges back to svn,
>> and any gotchas you might have encountered.
>
> Something that come to mind immediately is that you'll loose merge
> information as Subversion has linear history. I understand that recent
> Subversion versions have added some information about merges but I don't
> think git-svn handles this (I don't even know if it makes sense or not:).
AFAIK, SVN remembers what changesets have been merged and what are not
(on per file basis). So, it is more like cherry-pick with some automatic
tracking than git merge, and stored separately for each file in the repo.
So, I do not think it is easy to map svn merge concept to git one...
Inability to do merges mean that you have to track what changes what
branch by hands, which is very inconvenient if you have a few long
living branches.
Another long standing issue with git-svn was automatic end-of-line
conversion. It did not work with git-svn and the last time I heard about
it, it was disabled for repository created by git-svn. Probably, it may
not difficult to correct, but no one has looked at that closely....
> If you have a single integrator you'll also loose the author name.
Right... And if everyone has the right to commit then git-svn will
automatically rebase your changes during 'dcommit' on top of changes
made by other people, which means that you put into the repository a
different state than one you have actually tested.
Dmitry
^ permalink raw reply
* [RFC] What to you think about a loose status for submodules?
From: Heiko Voigt @ 2009-10-21 16:01 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann, Lars Hjemli
Hi,
for some time now I have been thinking about submodules which are
not checked out by default. So for example if you have a project which
consist of the submodules:
project/core
/help
/app
...
Consider the situation that 'help' is really big because it is a user
friendly application ;)
So you usually do not need the help folder to develop the application
but it still is tied to a certain revision.
For such a workflow I would like to implement what I call 'loose'
submodules. Where a
git clone project.git
cd project
git submodule init && git submodule update
would omit the 'help' folder. But in case I specify it directly like
git submodule init help
it would update to the recorded revision.
Of course the relation would be configurable. E.g.:
git config submodule."name".relation loose
and the opposite as
git config submodule."name".relation tight
Initially the implementation would only deal with the initialization
case. As a second step I would like to deal with the situation whether a
submodule should be shown as changed or not. What do you think about such
an extension?
cheers Heiko
^ permalink raw reply
* Re: drawbacks to svn server + git-svn vs git server?
From: Pascal Obry @ 2009-10-21 15:19 UTC (permalink / raw)
To: Dexter Riley; +Cc: git
In-Reply-To: <25994334.post@talk.nabble.com>
Le 21/10/2009 17:05, Dexter Riley a écrit :
> Hello. My group is currently using subversion on our version control server,
> but would like to move to git as a client. We are considering using
> git-svn, to avoid revalidating the server software. My question is, are
> there any major disadvantages to using git-svn versus git? I know that the
> git repository would be smaller. I'm more concerned about possible svn
> repository corruption, performance when pushing large merges back to svn,
> and any gotchas you might have encountered.
Something that come to mind immediately is that you'll loose merge
information as Subversion has linear history. I understand that recent
Subversion versions have added some information about merges but I don't
think git-svn handles this (I don't even know if it makes sense or not:).
If you have a single integrator you'll also loose the author name. Keep
in mind also that git-svn is slower to get new commits from the upstream
repository.
I've used git-svn for a while now without any trouble. And I can say
that I won't move back to using an svn client.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: Bill Lear @ 2009-10-21 15:05 UTC (permalink / raw)
To: Patrick Schoenfeld; +Cc: git
In-Reply-To: <20091021133702.GA470@lisa>
On Wednesday, October 21, 2009 at 15:37:03 (+0200) Patrick Schoenfeld writes:
>Hi,
>
>I regulary work with various branches, that I call by the number
>of an associated bug tracking / support tracking number. That
>makes it clear to which ticket a given branch belongs.
>In this case I would find it very useful, if I could associate
>short comments with a branch, which would be shown when
>doing a 'git branch'. This way I could see what this branch
>about, without looking up the ticket information.
>
>Obvious the workaround is to name the branches different,
>but this is sometimes not convenient and may result in quiet
>long branch names.
For now, we do just this. We use Jira for bug reporting. When we
create a new Jira bug, we use the Jira Id as the base and then tack on
a short suffix:
% git checkout -b ADM-417_service_deploy_race_condition
We are also working on tools that would, among other things, obviate
this. For example:
% git branch
* ADM-417
ADM-312
master
% jira describe
ADM-417: Service deployments have logging race condition on first start
% jira describe -l ADM-312
ADM-312: Portal permissions set incorrectly for WEP users
Description: The portal permissions get whacked whenever ...
Assigned To: John Smith <jsmith@ourhouse.com>
Status: In Progress
[...]
The 'jira' command just connects to our Jira server and performs
actions directly on the Jira server for current or whichever branch,
etc.
Bill
^ permalink raw reply
* drawbacks to svn server + git-svn vs git server?
From: Dexter Riley @ 2009-10-21 15:05 UTC (permalink / raw)
To: git
Hello. My group is currently using subversion on our version control server,
but would like to move to git as a client. We are considering using
git-svn, to avoid revalidating the server software. My question is, are
there any major disadvantages to using git-svn versus git? I know that the
git repository would be smaller. I'm more concerned about possible svn
repository corruption, performance when pushing large merges back to svn,
and any gotchas you might have encountered.
Any advice would be greatly appreciated.
Thanks,
Ed
--
View this message in context: http://www.nabble.com/drawbacks-to-svn-server-%2B-git-svn-vs-git-server--tp25994334p25994334.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* keeping track of where a patch begins
From: E R @ 2009-10-21 14:45 UTC (permalink / raw)
To: git
Hi,
We've started to use git at work. Developers create branches for their
patches (which we call "tickets" because they are related to our
ticketing system), and those branches are picked up by an integration
team and merged together to form a release. Hopefully this is not too
unconventional.
Ideally a developer will start their ticket branch from a previous
release. However, occasionally a developer working on multiple tickets
will forget to switch back to a release node when creating a new
ticket branch. Then code from the first ticket inadvertently gets
added to the second ticket, and this is a problem if integration
decides to include the second ticket in the release but not the first.
What solutions have you come up with to either to catch or prevent
this from happening? It is possible to determine what node a branch
started from?
It seems that somehow the node that the patch begins at has to be
either identified, marked or remembered, and it might have to done
outside of git. Then the integration team or other tools can validate
the starting node to ensure that it complies with the build process.
Thanks,
ER
^ permalink raw reply
* Re: [PATCH] git push: say that --tag can't be used with --all or --mirror in help text
From: Jeff King @ 2009-10-21 14:42 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Miklos Vajna, Sebastian Pipping, git,
Bjorn Gustavsson
In-Reply-To: <20091019125701.6117@nanako3.lavabit.com>
On Mon, Oct 19, 2009 at 12:57:01PM +0900, Nanako Shiraishi wrote:
> - OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
> + OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all nor --mirror"),
Hmm. We apparently all managed to miss this typo. It's visually hard to
notice because of the ")" closing the macro.
-- >8 --
Subject: [PATCH] push: fix typo in usage
Missing ")".
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 7d78711..019c986 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -181,7 +181,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
- OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror"),
+ OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror)"),
OPT_BIT( 0 , "purge", &flags,
"remove locally deleted refs from remote",
TRANSPORT_PUSH_PURGE),
--
1.6.5.1.139.g6f544.dirty
^ permalink raw reply related
* [bug][bisected] git-svn with root branches
From: Daniel Cordero @ 2009-10-21 14:41 UTC (permalink / raw)
To: Adam Brewster, Eric Wong; +Cc: git
Hello,
when trying to clone a svn repo with the command-line:
$ git svn clone -b / http://svn.collab.net/repos/svn/
(that is, each folder in the root of the repo should be considered it's
own branch)
the clone sometimes[1] fails saying:
ref: 'refs/remotes/' ends with a trailing slash, this is not permitted by git nor Subversion
The offending config is:
[svn-remote "svn"]
url = http://svn.collab.net/repos/svn
branches = /*:refs/remotes/*
This used to work in the past; I bisected the bad commit to
commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
Author: Adam Brewster <adambrewster@gmail.com>
Date: Tue Aug 11 23:14:03 2009 -0400
svn: allow branches outside of refs/remotes
Thanks in advance.
[1] It does work when the URL has at least 1 folder of depth
(e.g. suffix "trunk" to the above URL).
Its config section is:
[svn-remote "svn"]
url = http://svn.collab.net/repos/svn
branches = trunk//*:refs/remotes/*
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: Jeff King @ 2009-10-21 14:13 UTC (permalink / raw)
To: B Smith-Mannschott; +Cc: Thomas Adam, Patrick Schoenfeld, git
In-Reply-To: <28c656e20910210656m5ad597b9h7668e33eeb86b096@mail.gmail.com>
On Wed, Oct 21, 2009 at 03:56:51PM +0200, B Smith-Mannschott wrote:
> >> What do others think about this? Would this be useful
> >> for others, too?
> >
> > This feature is already being worked on as "git notes" -- see the "pu"
> > branch, I think it's still in there, unless it has graduated to next;
> > I forget now.
>
> Really? I was under the impression that the nodes were meant to
> annotate commits, or more generally things with SHA-1 IDs. (commits,
> tress, blobs). The SHA-1 ID a branch uses to refer to its HEAD commit
> changes with every commit, and the branch itself doesn't have an ID,
> just a name.
Yes, I think you are right. If I understand the OP, he really just wants
to annotate the refs themselves, not the commits they point to. So you
could probably get away with setting a "branch.$name.description" config
variable and then showing it during "git branch". The downside of such a
scheme is that it is purely local -- there's no way of pushing or
pulling your descriptions (which is maybe a feature, if you are thinking
of the descriptions as something only for you yourself to see).
A related technique is to maintain a separate meta repository which has
a list of branches, their status, etc. This is what Junio does with the
'todo' branch of git.git. The advantage is that it is fully version
controlled, and you can do much more than just set descriptions (e.g.,
'todo' also has scripts for maintaining the list of topic branches,
calculating branch dependencies, building the pu branch, etc). The
disadvantage is that it's a lot more work to set up and maintain.
-Peff
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: B Smith-Mannschott @ 2009-10-21 13:56 UTC (permalink / raw)
To: Thomas Adam; +Cc: Patrick Schoenfeld, git
In-Reply-To: <18071eea0910210646l41f18deam8c75f1218df7e25a@mail.gmail.com>
On Wed, Oct 21, 2009 at 15:46, Thomas Adam <thomas.adam22@gmail.com> wrote:
> 2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:
>> What do others think about this? Would this be useful
>> for others, too?
>
> This feature is already being worked on as "git notes" -- see the "pu"
> branch, I think it's still in there, unless it has graduated to next;
> I forget now.
Really? I was under the impression that the nodes were meant to
annotate commits, or more generally things with SHA-1 IDs. (commits,
tress, blobs). The SHA-1 ID a branch uses to refer to its HEAD commit
changes with every commit, and the branch itself doesn't have an ID,
just a name.
// Ben
^ permalink raw reply
* Re: Finding a commit
From: Daniele Segato @ 2009-10-21 13:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: Soham Mehta, git
In-Reply-To: <200910211437.39166.trast@student.ethz.ch>
On Wed, Oct 21, 2009 at 2:37 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> Commit -> Tree ---> Blob1, Blob2, Blob3
>>
>> Commit, Trees and Blobs are all identified by sha1
>> the commit should keep information on the author, the "parent"
>> commit(s) and so on..
>> the tree should just keep the "snapshot" of the data..
>>
>> so I think that if you search for the SHA-1 of the tree you should be fine..
>
> Not if you really want to find out if X was cherry-picked into this
> repository, because the tree is the *final state* at that commit,
> which of course includes all preceding changes.
>
> So suppose you have two patches A.diff and B.diff introducing files of
> the same name; then if you combine them into history as
>
> A -- B
>
> the tree state at B has both files, and hence is different from the
> tree state of B' in
>
> B' -- A'
>
> because there it only has the file B.
Yes... obviously...
the tree is the snapshot of a complete data set: so if you apply the
same patch to different data set you get different trees...
thanks for pointing it out.. :)
Regards,
Daniele
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: Howard Miller @ 2009-10-21 13:48 UTC (permalink / raw)
To: Patrick Schoenfeld; +Cc: git
In-Reply-To: <20091021133702.GA470@lisa>
2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:
> Hi,
>
> I regulary work with various branches, that I call by the number
> of an associated bug tracking / support tracking number. That
> makes it clear to which ticket a given branch belongs.
> In this case I would find it very useful, if I could associate
> short comments with a branch, which would be shown when
> doing a 'git branch'. This way I could see what this branch
> about, without looking up the ticket information.
>
> Obvious the workaround is to name the branches different,
> but this is sometimes not convenient and may result in quiet
> long branch names.
>
> What do others think about this? Would this be useful
> for others, too?
Definitely +1.
Even on a much more simplistic level (and speaking as a relative
newbie) I feel it's an important feature missing. It's terribly easy
in the fog of working on several different projects to remember what
all the branches really are. It is just human nature that you think it
makes perfect sense at the time but in a couple of weeks time you
can't find the branch you want from three or four similar ones. A
comments field for branches would be very helpful.
Howard
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: Thomas Adam @ 2009-10-21 13:46 UTC (permalink / raw)
To: Patrick Schoenfeld; +Cc: git
In-Reply-To: <20091021133702.GA470@lisa>
2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:
> What do others think about this? Would this be useful
> for others, too?
This feature is already being worked on as "git notes" -- see the "pu"
branch, I think it's still in there, unless it has graduated to next;
I forget now.
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH 7/6 (v4)] support for commit grafts, slight change to general mechanism
From: Thomas Rast @ 2009-10-21 13:44 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, Sam Vilain,
Michael J Gruber, Jeff King, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <200910211115.25017.trast@student.ethz.ch>
Thomas Rast wrote:
> Nick Edelen wrote:
> > Adds support for graft commits in rev-cache (w/ test), and slightly alters
> > graft mechanism. Before, parse_commit() checked the graft list on every
> > commit. Now register_commit_graft() preemptively loads graft commits into
> > memory, and sets a new 'graft' flag in the object. This allows awareness of
> > the commits' medical history without searching a (normally private) array upon
> > each commit.
>
> I felt adventurous and merged the topic into my local build, but I get
> "error: duplicate graft data ..." in repositories with only a single
> line in .git/info/grafts, which bisects to this commit (1c0a666 in
> today's pu).
Here's the complaint in squashable form if you want to keep it as a
testcase:
diff --git i/t/t6001-rev-list-graft.sh w/t/t6001-rev-list-graft.sh
index b2131cd..49ba37b 100755
--- i/t/t6001-rev-list-graft.sh
+++ w/t/t6001-rev-list-graft.sh
@@ -110,4 +110,18 @@ do
"
done
+
+duplicate_error="error: duplicate graft"
+
+test_expect_success 'duplicates: no false positives' '
+ echo $B0 $A2 > .git/info/grafts &&
+ ! git rev-list -1 HEAD 2>&1 | grep -q "$duplicate_error"
+'
+
+test_expect_success 'duplicates: no false negatives' '
+ echo $B0 $A2 > .git/info/grafts &&
+ echo $B0 $A1 >> .git/info/grafts &&
+ git rev-list -1 HEAD 2>&1 | grep "$duplicate_error"
+'
+
test_done
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Feature request: Store comments on branches
From: Patrick Schoenfeld @ 2009-10-21 13:37 UTC (permalink / raw)
To: git
Hi,
I regulary work with various branches, that I call by the number
of an associated bug tracking / support tracking number. That
makes it clear to which ticket a given branch belongs.
In this case I would find it very useful, if I could associate
short comments with a branch, which would be shown when
doing a 'git branch'. This way I could see what this branch
about, without looking up the ticket information.
Obvious the workaround is to name the branches different,
but this is sometimes not convenient and may result in quiet
long branch names.
What do others think about this? Would this be useful
for others, too?
Best Regards,
Patrick
^ permalink raw reply
* [PATCH v3] new --dirty option for git describe
From: Jean Privat @ 2009-10-21 13:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
With the --dirty option, git describe works on HEAD but append "-dirty"
if the working tree is dirty. If the working tree is clean, nothing
is appended.
$ git describe --dirty
v1.6.5-15-gc274db7
$ echo >> Makefile
$ git describe --dirty
v1.6.5-15-gc274db7-dirty
--dirty can also be used to specify what is append if the working
tree is dirty.
$ git describe --dirty=.mod
v1.6.5-15-gc274db7.mod
Many build scripts use `git describe` to produce a version number based
on the description of HEAD (on which is based the working tree) + saying
that if the working tree is dirty or no.
This patch helps the writing of such scripts since `git describe --dirty`
do directly the intended thing.
Alternatives specifications:
1 Describe the working tree by default and describe HEAD only if "HEAD"
is explicitly specified
Pro: does the right thing by default (both for users and for scripts)
Pro: is coherent with other git commands that works on the working tree
by default
Con: breaks existing scripts (since the world is not ideal)
2 Use --worktree instead of --dirty
Pro: does what it says: "git describe --worktree" will describe the
working three
Con: is incoherent with other commands that do not require a --worktree
option to work on the working tree
Con: unusable with an optional value: "git describe --worktree=.mod"
is quite unintuitive.
3 Use --dirty as in this patch
Pro: make sense to specify an optional value (what the dirty mark is)
Pro: do not have any of the big cons of previous alternatives
* does not break scripts
* is not inconsistent with other git commands
Pro: has an easy fallback to alternative 1 if the world become suddenly
ideal, or at least allows some kind of future transition plan if
people *really* bother:
1- ask that scripts use either "git describe HEAD" or
"git describe --dirty" (no more "git describe")
2- change default
Once the transition is done, the role of the --dirty option will
just be the way to specify an alternative mark (and a noop if alone)
Signed-off-by: Jean Privat <jean@pryen.org>
---
Changes since v2.5:
Use test_must_fail
Changes since v2:
No more line breaks (I hope)
Changes since v1:
use --dirty (alternative 3) instead of defaulting on workdir (alternative 1)
---
Documentation/git-describe.txt | 6 ++++++
builtin-describe.c | 25 ++++++++++++++++++++++++-
t/t6120-describe.sh | 14 ++++++++++++++
3 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index b231dbb..5253d86 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -9,6 +9,7 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
DESCRIPTION
-----------
@@ -27,6 +28,11 @@ OPTIONS
<committish>...::
Committish object names to describe.
+--dirty[=<mark>]::
+ Describe the working tree.
+ It means describe HEAD and appends <mark> (`-dirty` by
+ default) if the working tree is dirty.
+
--all::
Instead of using only the annotated tags, use any ref
found in `.git/refs/`. This option enables matching
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..84af981 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -5,12 +5,14 @@
#include "builtin.h"
#include "exec_cmd.h"
#include "parse-options.h"
+#include "diff.h"
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
static const char * const describe_usage[] = {
"git describe [options] <committish>*",
+ "git describe [options] --dirty",
NULL
};
@@ -23,6 +25,13 @@ static int max_candidates = 10;
static int found_names;
static const char *pattern;
static int always;
+static const char *dirty;
+
+/* diff-index command arguments to check if working tree is dirty. */
+static const char *diff_index_args[] = {
+ "diff-index", "--quiet", "HEAD", "--", NULL
+};
+
struct commit_name {
struct tag *tag;
@@ -208,6 +217,8 @@ static void describe(const char *arg, int last_one)
display_name(n);
if (longformat)
show_suffix(0, n->tag ? n->tag->tagged->sha1 : sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
return;
}
@@ -265,7 +276,10 @@ static void describe(const char *arg, int last_one)
if (!match_cnt) {
const unsigned char *sha1 = cmit->object.sha1;
if (always) {
- printf("%s\n", find_unique_abbrev(sha1, abbrev));
+ printf("%s", find_unique_abbrev(sha1, abbrev));
+ if (dirty)
+ printf("%s", dirty);
+ printf("\n");
return;
}
die("cannot describe '%s'", sha1_to_hex(sha1));
@@ -300,6 +314,8 @@ static void describe(const char *arg, int last_one)
display_name(all_matches[0].name);
if (abbrev)
show_suffix(all_matches[0].depth, cmit->object.sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
if (!last_one)
@@ -324,6 +340,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
"only consider tags matching <pattern>"),
OPT_BOOLEAN(0, "always", &always,
"show abbreviated commit object as fallback"),
+ {OPTION_STRING, 0, "dirty", &dirty, "mark",
+ "append <mark> on dirty working tree (default: \"-dirty\")",
+ PARSE_OPT_OPTARG, NULL, "-dirty"},
OPT_END(),
};
@@ -360,7 +379,11 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
}
if (argc == 0) {
+ if (dirty && !cmd_diff_index(ARRAY_SIZE(diff_index_args) - 1, diff_index_args, prefix))
+ dirty = NULL;
describe("HEAD", 1);
+ } else if (dirty) {
+ die("--dirty is incompatible with committishes");
} else {
while (argc-- > 0) {
describe(*argv++, argc == 0);
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 8c7e081..e061177 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -123,6 +123,20 @@ test_expect_success 'rename tag Q back to A' '
test_expect_success 'pack tag refs' 'git pack-refs'
check_describe A-* HEAD
+check_describe "A-*[0-9a-f]" --dirty
+
+test_expect_success 'set-up dirty working tree' '
+ echo >>file
+'
+
+check_describe "A-*[0-9a-f]-dirty" --dirty
+
+check_describe "A-*[0-9a-f].mod" --dirty=.mod
+
+test_expect_success 'describe --dirty HEAD' '
+ test_must_fail git describe --dirty HEAD
+'
+
test_expect_success 'set-up matching pattern tests' '
git tag -a -m test-annotated test-annotated &&
echo >>file &&
--
1.6.5
^ permalink raw reply related
* Re: Finding a commit
From: Douglas Campos @ 2009-10-21 13:26 UTC (permalink / raw)
To: Soham Mehta; +Cc: git
In-Reply-To: <4ADEF095.3020406@box.net>
On Wed, Oct 21, 2009 at 9:29 AM, Soham Mehta <soham@box.net> wrote:
> Given a SHA1 of a commit from one repository (say x), wondering what is a
> proper way to find out if that commit (change) also exists in a different
> repository (say y).
>
> Because SHA1 can change if a commit is cherry-picked around, I cannot just
> grep for that SHA1 from git-rev-list or git-log on 'y'. I need a way to know
> if a commit with identical changes (as in 'x') is also present in 'y'.
>
> I realize that Author and Timestamp do not change when the commit is moved
> (fetched, pushed, pulled, rebased, cherry-picked etc). So my current
> solution relies on grepping for the pair of Author-Timestamp from git-log on
> 'y'.
>
Have you tried git cherry?
--
Douglas Campos (qmx)
+55 11 7626 5959
^ permalink raw reply
* Re: [msysGit] [PATCH v4 7/8] mingw: enable OpenSSL
From: Johannes Sixt @ 2009-10-21 12:55 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, Marius Storm-Olsen
In-Reply-To: <40aa078e0910210543t2dcc2af6ie16eb0e49895788f@mail.gmail.com>
Erik Faye-Lund schrieb:
> On Wed, Oct 21, 2009 at 2:15 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> I seem to have ack'ed this one too early. After testing in my environment,
>> I get:
>>
>> imap-send.o: In function `ssl_socket_perror':
>> D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_get_error'
>> D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_error_string'
>>
>> I need this patch in addition, and perhaps something similar is also
>> needed with MSVC:
>
> Ah, yes - thanks for that one. I traced it a bit, and I found that it
> works for me without your patch because I'm using OpenSSL's sha1, so
> $(LIB_4_CRYPTO) is already included. Your fix is of course correct.
> I'll squash it in and resend.
Indeed, I observed the failure after I set BLK_SHA1=YesPlease. I did this
exactly because it removes the dependency on libcrypto.dll from git.exe.
-- Hannes
^ 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