* Which dates 'git log --since= --after=' compare?
From: Daniel @ 2009-10-19 10:01 UTC (permalink / raw)
To: git
Hi,
I can see that 'git log --since= --after=' compares commit's dates,
not author's dates.How can I limit commits by Author's date?
$ git log --format="%aD %cD"
Mon, 5 Oct 2009 14:54:57 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Mon, 21 Sep 2009 11:11:35 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Mon, 21 Sep 2009 10:14:41 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Wed, 16 Sep 2009 14:23:30 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Wed, 16 Sep 2009 10:27:39 +0200 Thu, 8 Oct 2009 10:31:38 +0200
Wed, 16 Sep 2009 09:15:32 +0200 Thu, 8 Oct 2009 10:30:31 +0200
Wed, 16 Sep 2009 08:02:23 +0200 Wed, 16 Sep 2009 09:02:29 +0200
$ git log --format="%aD %cD" --since=2009-09-01 --until=2009-10-01
Wed, 16 Sep 2009 08:02:23 +0200 Wed, 16 Sep 2009 09:02:29 +0200
--
Daniel
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 10:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <alpine.DEB.1.00.0910191155310.4985@pacific.mpi-cbg.de>
Hi,
I'm quite interested in this too but I can't see what that patch does
at all. I'm unsure what the 'mob' account is but a search suggests
it's something to do with anonymous access, which doesn't seem to make
any sense.
Can you explain?
Thanks!
2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 19 Oct 2009, Mohit Aron wrote:
>
>> I'm setting up a shared repository and I'd like to prevent users from
>> creating branches in it (they can of course create local branches in
>> their own clone of this repository). How can I accomplish this ? I
>> looked at 'git help config' and it seems I need something similar to the
>> parameter receive.denyDeletes - this prevents deletion of branches.
>
> The easiest way to accomplish things is to look who had the same problem
> and solved it:
>
> http://repo.or.cz/w/repo.git?a=blob;f=update-hook;h=98b419ecad61f6c80f;hb=6f92e96db0d605bed50db99029172607af301792#l16
>
> Hth,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Sergio Callegari @ 2009-10-19 10:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4ADC2D45.3020803@viscovery.net>
Johannes Sixt wrote:
> Sergio Callegari schrieb:
>
>> Is there a means to have fsck to a truly full check on the sanity of a repo?
>>
>
> git fsck --full
>
> RTFM, please.
>
>
Right... sorry for the noise, I mismatched --strict for --full in a script.
BTW, the short help for fsck at --full only says "consider objects in
alternate repositories".
My apologize.
Sergio
^ permalink raw reply
* Re: Potentially dangerous behavior of git gc
From: Miklos Vajna @ 2009-10-19 11:21 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091019T095725-840@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari <sergio.callegari@gmail.com> wrote:
> With this when the alternate info of A is finally updated, A is broken, missing
> many references and not having a head anymore.
>
> Would it be better to have git gc not to take dangerous actions on potentially
> problematic repos?
Such repos are usually created using git clone -s. See the NOTE of the
manpage under the -s option, probably you want to use git repack -a
after git clone.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Unapplied patches reminder
From: Rolf Bjarne Kvinge @ 2009-10-19 11:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vzl7ogtxs.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]
On Mon, 19 Oct 2009 01:31:59 +0200, Junio C Hamano <gitster@pobox.com> wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, I saw these patches and thought what they try to do were
>> sensible, but I don't them in your tree. I didn't see much discussion
>> on most of them, either.
>>
>> Because I don't read C very well, I may have listed some patches
>> here that you may have discarded because the code was no good, and
>> if so I apologize for wasting your time, but I thought at least
>> some of them should be salvaged.
>> ...
>> From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
>> Subject: git rev-list --pretty=raw strips empty lines
>> Date: Tue, 06 Oct 2009 14:33:37 +0200
>> Message-ID: <op.u1do6bq5k71drc@linux.lacasa>
>>
>> It seems like the --pretty=raw format strips off empty newlines from
>> the beginning of log messages, while I'd expect the raw format to
>> not do any transformations (just as the documentation says: "The
>> 'raw' format shows the entire commit exactly as stored in the commit
>> object").
>>
>> The below changes works for me, not sure if I'm right about this
>> though (my first time here ;-)
>
> I do not recall seeing this one; most likely it was lost in the noise,
> especially because it did not look like a patch submission, without having
> anything resembling a commit log message.
>
> I think the change itself is an uncontroversial one, even though this
> really changes the behaviour.
My specific need is to be able to get out the exact same log message as I committed, another way of getting the same result would be to implement --pretty=xml (along the lines of subversions 'svn log --xml'). This would prevent behavioural changes. And yes, I'm willing to implement it if you agree it's a good idea.
Regarding the previous patch I just found that it's not complete - git would still print lines with only whitespace as empty lines (i.e. stripping off the whitespace). I'm attaching a revised patch that fixes this issue, but since I found the resulting code slightly ugly, I also found an easier approach: in pretty_print_commit (pretty.c) just print the commit message buffer and return.
Rolf
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[-- Attachment #2: 0001-pretty.c-Don-t-do-any-transformations-when-using-the.patch --]
[-- Type: application/octet-stream, Size: 0 bytes --]
[-- Attachment #3: 0001-pretty.c-special-case-raw-format.patch --]
[-- Type: application/octet-stream, Size: 874 bytes --]
From 4fa9e4c1c133fbe3423c979efd5722dd7bd5d530 Mon Sep 17 00:00:00 2001
From: Rolf Bjarne Kvinge <RKvinge@novell.com>
Date: Mon, 19 Oct 2009 13:31:17 +0200
Subject: [PATCH] pretty.c: Don't do any transformations when using the 'raw' format.
When formatting commits with the 'raw' format, print the commit exactly as
stored.
Signed-off-by: Rolf Bjarne Kvinge <RKvinge@novell.com>
---
pretty.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index f5983f8..96dac9a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -915,6 +915,11 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
return;
}
+ if (fmt == CMIT_FMT_RAW) {
+ strbuf_add(sb, msg, strlen (msg));
+ return;
+ }
+
reencoded = reencode_commit_message(commit, &encoding);
if (reencoded) {
msg = reencoded;
--
1.6.5.rc2.17.gdbc1b.dirty
^ permalink raw reply related
* Re: denying branch creation in a shared repository
From: Johannes Schindelin @ 2009-10-19 12:00 UTC (permalink / raw)
To: Howard Miller; +Cc: Mohit Aron, git
In-Reply-To: <26ae428a0910190308t3233debdjfc0c8beedb9c0ac6@mail.gmail.com>
Hi,
first, if you want to be taken seriously, you might want to avoid to
top-post.
Second, do diligent research (e.g. on the 'mob' user).
On Mon, 19 Oct 2009, Howard Miller wrote:
> I'm quite interested in this too but I can't see what that patch does at
> all. I'm unsure what the 'mob' account is but a search suggests it's
> something to do with anonymous access, which doesn't seem to make any
> sense.
If this trivial script (_not_ a patch! This should be obvious at first
sight) does not make any sense to you, I fear you will not be able to use
hooks to do what you want to do.
> Can you explain?
Yes.
The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
that exists. IOW a user of repo.or.cz can decide to let random people to
push commits by creating the 'mob' branch and adding the 'mob' user to the
pushers.
The first part of the hook (as you can see from the pretty helpful error
messages it outputs) is about denying to push to anything but the mob
branch.
The second part is much more interesting in the context of this thread
(and I would expect anyone capable of reading shell scripts to see that
readily), because it denies the 'mob' user to _create_ the 'mob' branch.
See line 16ff.
So the point is: the update hook gets a "$2" = 0000... in case a branch is
about to be created, and the hook can prevent that by exiting with a
non-zero exit code.
Hth,
Dscho
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 12:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <alpine.DEB.1.00.0910191353080.4985@pacific.mpi-cbg.de>
Mmm....
Thanks for the helpful reply Johannes. Perhaps you should do diligent
research into mail software that folds quoted text for you. There's a
company called Google you might have heard of. Just a thought.
On the other hand if you can't be bothered making a helpful reply
rather than a rude one perhaps simply not writing anything at all
would, at the very least, leave us absolutely no worse off. Just the
opinion of someone not to be taken seriously.... of course!
Howard
2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> first, if you want to be taken seriously, you might want to avoid to
> top-post.
>
> Second, do diligent research (e.g. on the 'mob' user).
>
> On Mon, 19 Oct 2009, Howard Miller wrote:
>
>> I'm quite interested in this too but I can't see what that patch does at
>> all. I'm unsure what the 'mob' account is but a search suggests it's
>> something to do with anonymous access, which doesn't seem to make any
>> sense.
>
> If this trivial script (_not_ a patch! This should be obvious at first
> sight) does not make any sense to you, I fear you will not be able to use
> hooks to do what you want to do.
>
>> Can you explain?
>
> Yes.
>
> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
> that exists. IOW a user of repo.or.cz can decide to let random people to
> push commits by creating the 'mob' branch and adding the 'mob' user to the
> pushers.
>
> The first part of the hook (as you can see from the pretty helpful error
> messages it outputs) is about denying to push to anything but the mob
> branch.
>
> The second part is much more interesting in the context of this thread
> (and I would expect anyone capable of reading shell scripts to see that
> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
> See line 16ff.
>
> So the point is: the update hook gets a "$2" = 0000... in case a branch is
> about to be created, and the hook can prevent that by exiting with a
> non-zero exit code.
>
> Hth,
> Dscho
>
>
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 12:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <26ae428a0910190519mbe9ddaava3c15de94a0cd14f@mail.gmail.com>
And... I instantly have to apologise.. With wonderful irony,
Googlemail folded the helpful bit of your reply leaving just the
(apparently) unhelpful bit.
(Crawls under nearest rock).
2009/10/19 Howard Miller <howard@e-learndesign.co.uk>:
> Mmm....
>
> Thanks for the helpful reply Johannes. Perhaps you should do diligent
> research into mail software that folds quoted text for you. There's a
> company called Google you might have heard of. Just a thought.
>
> On the other hand if you can't be bothered making a helpful reply
> rather than a rude one perhaps simply not writing anything at all
> would, at the very least, leave us absolutely no worse off. Just the
> opinion of someone not to be taken seriously.... of course!
>
> Howard
>
> 2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> first, if you want to be taken seriously, you might want to avoid to
>> top-post.
>>
>> Second, do diligent research (e.g. on the 'mob' user).
>>
>> On Mon, 19 Oct 2009, Howard Miller wrote:
>>
>>> I'm quite interested in this too but I can't see what that patch does at
>>> all. I'm unsure what the 'mob' account is but a search suggests it's
>>> something to do with anonymous access, which doesn't seem to make any
>>> sense.
>>
>> If this trivial script (_not_ a patch! This should be obvious at first
>> sight) does not make any sense to you, I fear you will not be able to use
>> hooks to do what you want to do.
>>
>>> Can you explain?
>>
>> Yes.
>>
>> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
>> that exists. IOW a user of repo.or.cz can decide to let random people to
>> push commits by creating the 'mob' branch and adding the 'mob' user to the
>> pushers.
>>
>> The first part of the hook (as you can see from the pretty helpful error
>> messages it outputs) is about denying to push to anything but the mob
>> branch.
>>
>> The second part is much more interesting in the context of this thread
>> (and I would expect anyone capable of reading shell scripts to see that
>> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
>> See line 16ff.
>>
>> So the point is: the update hook gets a "$2" = 0000... in case a branch is
>> about to be created, and the hook can prevent that by exiting with a
>> non-zero exit code.
>>
>> Hth,
>> Dscho
>>
>>
>
^ permalink raw reply
* Re: [PATCH] Add the --submodule option to the diff option family
From: Jens Lehmann @ 2009-10-19 12:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3a5gdr1c.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> I have four patches queued on js/diff-verbose-submodule topic and I think
> this corresponds to the first three, correct?
Yes.
>> +--submodule[=<format>]::
>> + Chose the output format for submodule differences. <format> can be one of
>> + 'short' and 'left-right-log'. 'short' is the default value for this
>> + option and and shows pairs of commit names. 'left-right-log' lists the
>> + commits in that commit range like the 'summary' option of
>> + linkgit:git-submodule[1] does.
>> +
>
> Well, while left-right-log may be logically the most correct name for this
> option, I think it is too long to be practical. Because it is not like we
> would want to have an option to have full log there when we are showing
> "diff", I think it would make sense to making left-right-log the default
> when "--submodule" (without format specification) is given, and possibly
> give "--submodule=log" as the synonym for this format.
O.k., "--submodule=log" it is.
> After all, if you do not give --submodule, we will give the traditional
> short format, no?
Yes. Will make the documentation clearer on this.
>> diff --git a/diff.c b/diff.c
>> index c719ce2..8af1ae2 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -2771,6 +2783,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
>> DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
>> else if (!strcmp(arg, "--ignore-submodules"))
>> DIFF_OPT_SET(options, IGNORE_SUBMODULES);
>> + else if (!prefixcmp(arg, "--submodule=")) {
>> + if (!strcmp(arg + 12, "left-right-log"))
>> + DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
>> + }
>
> I do not see --submodule (without "=<format>") supported here as the
> documentation claims, but this is the logical place to do so.
Will change that.
>> diff --git a/submodule.c b/submodule.c
>> new file mode 100644
>> index 0000000..206386f
>> --- /dev/null
>> +++ b/submodule.c
>> @@ -0,0 +1,112 @@
>> +...
>> +void show_submodule_summary(FILE *f, const char *path,
>> + unsigned char one[20], unsigned char two[20],
>> + const char *del, const char *add, const char *reset)
>> +{
>> ...
>> + fwrite(sb.buf, sb.len, 1, f);
>> +
>> + if (!message) {
>> + while ((commit = get_revision(&rev))) {
>> + ...
>> + }
>> + clear_commit_marks(left, ~0);
>> + clear_commit_marks(right, ~0);
>> + }
>> +}
>
> I thought we had strbuf_release(&sb) here... Where did it go?
*blush* ... thanks for catching this, will put it back where it belongs.
^ permalink raw reply
* [PATCH v2] Add the --submodule option to the diff option family
From: Jens Lehmann @ 2009-10-19 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <4ADC5BB7.5090207@web.de>
When you use the option --submodule=log you can see the submodule
summaries inlined in the diff, instead of not-quite-helpful SHA-1 pairs.
The format imitates what "git submodule summary" shows.
To do that, <path>/.git/objects/ is added to the alternate object
databases (if that directory exists).
This option was requested by Jens Lehmann at the GitTogether in Berlin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Changes since v1:
- Changed the option name from "left-right-log" to "log"
- Handling "--submodule"-option without extra arguments now
- Re-added a "strbuf_release(&sb);" being accidentally dropped
- Changed the wording in the Documentation
Documentation/diff-options.txt | 7 +++
Makefile | 2 +
diff.c | 18 ++++++
diff.h | 1 +
submodule.c | 113 ++++++++++++++++++++++++++++++++++++++++
submodule.h | 8 +++
6 files changed, 149 insertions(+), 0 deletions(-)
create mode 100644 submodule.c
create mode 100644 submodule.h
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9276fae..e26b847 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -87,6 +87,13 @@ endif::git-format-patch[]
Show only names and status of changed files. See the description
of the `--diff-filter` option on what the status letters mean.
+--submodule[=<format>]::
+ Chose the output format for submodule differences. <format> can be one of
+ 'short' and 'log'. 'short' just shows pairs of commit names, this format
+ is used when this option is not given. 'log' is the default value for this
+ option and lists the commits in that commit range like the 'summary'
+ option of linkgit:git-submodule[1] does.
+
--color::
Show colored diff.
diff --git a/Makefile b/Makefile
index c0eff64..2f61e17 100644
--- a/Makefile
+++ b/Makefile
@@ -453,6 +453,7 @@ LIB_H += sideband.h
LIB_H += sigchain.h
LIB_H += strbuf.h
LIB_H += string-list.h
+LIB_H += submodule.h
LIB_H += tag.h
LIB_H += transport.h
LIB_H += tree.h
@@ -551,6 +552,7 @@ LIB_OBJS += sideband.o
LIB_OBJS += sigchain.o
LIB_OBJS += strbuf.o
LIB_OBJS += string-list.o
+LIB_OBJS += submodule.o
LIB_OBJS += symlinks.o
LIB_OBJS += tag.o
LIB_OBJS += trace.o
diff --git a/diff.c b/diff.c
index c719ce2..5fc9f37 100644
--- a/diff.c
+++ b/diff.c
@@ -13,6 +13,7 @@
#include "utf8.h"
#include "userdiff.h"
#include "sigchain.h"
+#include "submodule.h"
#ifdef NO_FAST_WORKING_DIRECTORY
#define FAST_WORKING_DIRECTORY 0
@@ -1557,6 +1558,17 @@ static void builtin_diff(const char *name_a,
const char *a_prefix, *b_prefix;
const char *textconv_one = NULL, *textconv_two = NULL;
+ if (DIFF_OPT_TST(o, SUBMODULE_LEFT_RIGHT_LOG) &&
+ (!one->mode || S_ISGITLINK(one->mode)) &&
+ (!two->mode || S_ISGITLINK(two->mode))) {
+ const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
+ const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
+ show_submodule_summary(o->file, one ? one->path : two->path,
+ one->sha1, two->sha1,
+ del, add, reset);
+ return;
+ }
+
if (DIFF_OPT_TST(o, ALLOW_TEXTCONV)) {
textconv_one = get_textconv(one);
textconv_two = get_textconv(two);
@@ -2771,6 +2783,12 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
+ else if (!strcmp(arg, "--submodule"))
+ DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
+ else if (!prefixcmp(arg, "--submodule=")) {
+ if (!strcmp(arg + 12, "log"))
+ DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
+ }
/* misc options */
else if (!strcmp(arg, "-z"))
diff --git a/diff.h b/diff.h
index a7e7ccb..8079f5b 100644
--- a/diff.h
+++ b/diff.h
@@ -67,6 +67,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
#define DIFF_OPT_ALLOW_TEXTCONV (1 << 21)
#define DIFF_OPT_DIFF_FROM_CONTENTS (1 << 22)
+#define DIFF_OPT_SUBMODULE_LEFT_RIGHT_LOG (1 << 23)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
diff --git a/submodule.c b/submodule.c
new file mode 100644
index 0000000..d5fce7a
--- /dev/null
+++ b/submodule.c
@@ -0,0 +1,113 @@
+#include "cache.h"
+#include "submodule.h"
+#include "dir.h"
+#include "diff.h"
+#include "commit.h"
+#include "revision.h"
+
+int add_submodule_odb(const char *path)
+{
+ struct strbuf objects_directory = STRBUF_INIT;
+ struct alternate_object_database *alt_odb;
+
+ strbuf_addf(&objects_directory, "%s/.git/objects/", path);
+ if (!is_directory(objects_directory.buf))
+ return -1;
+
+ /* avoid adding it twice */
+ for (alt_odb = alt_odb_list; alt_odb; alt_odb = alt_odb->next)
+ if (alt_odb->name - alt_odb->base == objects_directory.len &&
+ !strncmp(alt_odb->base, objects_directory.buf,
+ objects_directory.len))
+ return 0;
+
+ alt_odb = xmalloc(objects_directory.len + 42 + sizeof(*alt_odb));
+ alt_odb->next = alt_odb_list;
+ strcpy(alt_odb->base, objects_directory.buf);
+ alt_odb->name = alt_odb->base + objects_directory.len;
+ alt_odb->name[2] = '/';
+ alt_odb->name[40] = '\0';
+ alt_odb->name[41] = '\0';
+ alt_odb_list = alt_odb;
+ prepare_alt_odb();
+ return 0;
+}
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset)
+{
+ struct rev_info rev;
+ struct commit *commit, *left = left, *right;
+ struct commit_list *merge_bases, *list;
+ const char *message = NULL;
+ struct strbuf sb = STRBUF_INIT;
+ static const char *format = " %m %s";
+ int fast_forward = 0, fast_backward = 0;
+
+ if (is_null_sha1(two))
+ message = "(submodule deleted)";
+ else if (add_submodule_odb(path))
+ message = "(not checked out)";
+ else if (is_null_sha1(one))
+ message = "(new submodule)";
+ else if (!(left = lookup_commit_reference(one)) ||
+ !(right = lookup_commit_reference(two)))
+ message = "(commits not present)";
+
+ if (!message) {
+ init_revisions(&rev, NULL);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.left_right = 1;
+ rev.first_parent_only = 1;
+ left->object.flags |= SYMMETRIC_LEFT;
+ add_pending_object(&rev, &left->object, path);
+ add_pending_object(&rev, &right->object, path);
+ merge_bases = get_merge_bases(left, right, 1);
+ if (merge_bases) {
+ if (merge_bases->item == left)
+ fast_forward = 1;
+ else if (merge_bases->item == right)
+ fast_backward = 1;
+ }
+ for (list = merge_bases; list; list = list->next) {
+ list->item->object.flags |= UNINTERESTING;
+ add_pending_object(&rev, &list->item->object,
+ sha1_to_hex(list->item->object.sha1));
+ }
+ if (prepare_revision_walk(&rev))
+ message = "(revision walker failed)";
+ }
+
+ strbuf_addf(&sb, "Submodule %s %s..", path,
+ find_unique_abbrev(one, DEFAULT_ABBREV));
+ if (!fast_backward && !fast_forward)
+ strbuf_addch(&sb, '.');
+ strbuf_addf(&sb, "%s", find_unique_abbrev(two, DEFAULT_ABBREV));
+ if (message)
+ strbuf_addf(&sb, " %s\n", message);
+ else
+ strbuf_addf(&sb, "%s:\n", fast_backward ? " (rewind)" : "");
+ fwrite(sb.buf, sb.len, 1, f);
+
+ if (!message) {
+ while ((commit = get_revision(&rev))) {
+ strbuf_setlen(&sb, 0);
+ if (commit->object.flags & SYMMETRIC_LEFT) {
+ if (del)
+ strbuf_addstr(&sb, del);
+ }
+ else if (add)
+ strbuf_addstr(&sb, add);
+ format_commit_message(commit, format, &sb,
+ rev.date_mode);
+ if (reset)
+ strbuf_addstr(&sb, reset);
+ strbuf_addch(&sb, '\n');
+ fprintf(f, "%s", sb.buf);
+ }
+ clear_commit_marks(left, ~0);
+ clear_commit_marks(right, ~0);
+ }
+ strbuf_release(&sb);
+}
diff --git a/submodule.h b/submodule.h
new file mode 100644
index 0000000..4c0269d
--- /dev/null
+++ b/submodule.h
@@ -0,0 +1,8 @@
+#ifndef SUBMODULE_H
+#define SUBMODULE_H
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset);
+
+#endif
--
1.6.5.104.gd732a
^ permalink raw reply related
* Re: denying branch creation in a shared repository
From: Thomas Rast @ 2009-10-19 12:59 UTC (permalink / raw)
To: Howard Miller; +Cc: Johannes Schindelin, Mohit Aron, git
In-Reply-To: <26ae428a0910190519mbe9ddaava3c15de94a0cd14f@mail.gmail.com>
Howard Miller wrote:
> 2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >
> > first, if you want to be taken seriously, you might want to avoid to
^^^^^^^^^
> > top-post.
>
> Thanks for the helpful reply Johannes. Perhaps you should do diligent
> research into mail software that folds quoted text for you. There's a
> company called Google you might have heard of. Just a thought.
It really is about the "seriously". If you don't, you'll get your
mail outright ignored.
Many of us get lots[1] of mail per day, and have no time nor will to
scroll around in the message reading long (untrimmed) quoted parts
that are out of order, let alone click around in the corresponding
thread to remember the context. If you want your mail to be read, you
should take some time to make it *easy* to read on its own.
[1] I'm luckily not one of them, but I hear high-profile project
maintainers get hundreds.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 13:12 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Schindelin, Mohit Aron, git
In-Reply-To: <200910191459.40332.trast@student.ethz.ch>
>
> Many of us get lots[1] of mail per day, and have no time nor will to
> scroll around in the message reading long (untrimmed) quoted parts
> that are out of order, let alone click around in the corresponding
> thread to remember the context. If you want your mail to be read, you
> should take some time to make it *easy* to read on its own.
>
I forgot and I apologise unreservedly. I am in a similar position on
other projects although we use web forums which makes it easier. I
certainly don't want to get into that argument though. I struggle a
great deal to be nice to people who haven't made any kind of effort to
even ask a sensible question so I do understand. The challenge is to
think someone is stupid yet to manage a polite, constructive and
non-arrogant reply (or just say nothing if you can't). At least web
forums have emoticons - a smiley fixes everything!!
Gentlemen... keep up the good work. Even an idiot like me thinks that
git is a fantastic project. It has saved me hours of pain and effort.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Per Strandh @ 2009-10-19 13:08 UTC (permalink / raw)
To: git
In-Reply-To: <7vzl7ogtxs.fsf@alter.siamese.dyndns.org>
"Junio C Hamano" <gitster@pobox.com> skrev i meddelandet
news:7vzl7ogtxs.fsf@alter.siamese.dyndns.org...
>> From: Per Strandh <Per.Strandh@q-matic.se>
>> Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
>> Date: Tue, 13 Oct 2009 22:09:12 +0200
>> Message-ID:
>> <65D9329CA2AF94438F542D48F2A42E830F95F51514@GOT-SRV-005.QMATIC.local>
>>
>> git-p4 clone (and sync) did not work if the specified depot path
>> contained spaces.
>> Fixed by quoting the argument to the "p4 changes" and "p4 files"
>> commands.
>
> I do recall ignoring this one because (1) I never use git-p4 myself and
> always rely on Acks from people who have been involved in it, and (2) the
> message was mangled (perhaps it had two or three copies of patches as
> attachments).
Sorry for posting a mangled patch.
Please let someone involved in the git-p4 code review/approve/apply the
patch.
Regards
/Per/
>From c70682a9c4051f2dc92e2dd92f1710c755df6cfe Mon Sep 17 00:00:00 2001
From: Per Strandh <per.strandh@q-matic.se>
Date: Fri, 9 Oct 2009 12:11:14 +0200
Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
path
git-p4 clone (and sync) did not work if the specified depot path contained
spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p,
changeRange)
- for p in
depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p,
changeRange)
+ for p in
depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) +
"\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
^ permalink raw reply related
* Re: How to revert one of multiple merges
From: Michael J Gruber @ 2009-10-19 15:19 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <19162.32265.738503.382638@lisa.zopyra.com>
Bill Lear venit, vidit, dixit 18.10.2009 04:31:
> Branch A, B, C each have 20 commits, 0-19.
>
> Branch v1.0.0 created, then merge of A, B, C performed.
>
> After testing, we realize that the branch B is not ready for
> production release and we'd like to remove it from branch
> v1.0.0.
>
> If I do
>
> % git merge A B C
>
> I get a single commit:
>
> % git log -p
>
> commit 1644a0b98c01869aa83e59aa41374c22098c47b6
> [...]
> Date: Fri Oct 16 09:52:32 2009 -0500
>
> Merge branches 'A', 'B' and 'C' into v1.0.0
>
> [20 x 3 commits]
>
> If I do
>
> % git merge A
> % git merge B
> % git merge C
>
> Then:
>
> % git log -p
>
> commit 8946edd381384d0882221c87b5b3b7bf47127d70
> [...]
> Date: Sat Oct 17 21:28:36 2009 -0500
>
> Merge branch 'B' into v1.0.0
>
> commit 076ed422443e3684e564f7cae2b92e4538088ae6
> [...]
> Date: Sat Oct 17 21:28:35 2009 -0500
>
> Merge branch 'A' into v1.0.0
>
> but no "Merge branch 'C' into v1.0.0".
Do you get any commits after the merge of B? If yes, then v1.0.0 got
fast-forwarded (you can avoid that using --no-ff). If no, C was
contained in v1.0.0 already.
In both cases, it's not clear how C could have been "ready" when B was not.
> And so, I'm faced with git rebase -i posing some unanswerable questions
> to our release manager. She cannot easily remove B from the merge after
> doint either merge A B C, or merge A, merge B, merge C.
The way you described the situation there are no commits after the
merges. So, why not reset to before the merge and do a "git merge A C"?
Michael
^ permalink raw reply
* [PATCH v4 1/8] imap-send: remove useless uid code
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Jeff King, Erik Faye-Lund
In-Reply-To: <1255966929-1280-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.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 2/8] imap-send: use separate read and write fds
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255966929-1280-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.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 4/8] imap-send: fix compilation-error on Windows
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255966929-1280-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.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255966929-1280-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.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255966929-1280-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.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 7/8] mingw: enable OpenSSL
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255966929-1280-7-git-send-email-kusmabite@gmail.com>
Since we have OpenSSL in msysgit now, enable it to support SSL
encryption for imap-send.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0d13af3..dbeaf2f 100644
--- a/Makefile
+++ b/Makefile
@@ -952,7 +952,6 @@ else
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
--
1.6.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 6/8] mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255966929-1280-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.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 8/8] MSVC: Enable OpenSSL, and translate -lcrypto
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Marius Storm-Olsen, Erik Faye-Lund
In-Reply-To: <1255966929-1280-8-git-send-email-kusmabite@gmail.com>
From: Marius Storm-Olsen <mstormo@gmail.com>
We don't use crypto, but rather require libeay32 and
ssleay32. handle it in both the Makefile msvc linker
script, and the buildsystem generator.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 1 -
compat/vcbuild/scripts/clink.pl | 3 +++
contrib/buildsystems/engine.pl | 3 +++
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index dbeaf2f..9db6c08 100644
--- a/Makefile
+++ b/Makefile
@@ -900,7 +900,6 @@ ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index f9528c0..8a2112f 100644
--- a/compat/vcbuild/scripts/clink.pl
+++ b/compat/vcbuild/scripts/clink.pl
@@ -29,6 +29,9 @@ while (@ARGV) {
push(@args, "zlib.lib");
} elsif ("$arg" eq "-liconv") {
push(@args, "iconv.lib");
+ } elsif ("$arg" eq "-lcrypto") {
+ push(@args, "libeay32.lib");
+ push(@args, "ssleay32.lib");
} elsif ("$arg" =~ /^-L/ && "$arg" ne "-LTCG") {
$arg =~ s/^-L/-LIBPATH:/;
push(@args, $arg);
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 20bd061..d506717 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -315,6 +315,9 @@ sub handleLinkLine
$appout = shift @parts;
} elsif ("$part" eq "-lz") {
push(@libs, "zlib.lib");
+ } elsif ("$part" eq "-lcrypto") {
+ push(@libs, "libeay32.lib");
+ push(@libs, "ssleay32.lib");
} elsif ($part =~ /^-/) {
push(@lflags, $part);
} elsif ($part =~ /\.(a|lib)$/) {
--
1.6.5.15.g5f078
^ permalink raw reply related
* [PATCH v4 0/8] imap-send: Windows support
From: Erik Faye-Lund @ 2009-10-19 15:42 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
Here's the 4th iteration of my patches for
Windows-compatibility in imap-send.
- Patch 1-3 is about getting rid of or rewriting
code with portability issues.
- Patch 4 fixes a compilation error on Windows
- Patch 5 enables compilation of imap-send
- Patch 6-7 enables SSL-suport for mingw
- Patch 8 enables imap-send and SSL for msvc
Changes in this iteration compared to the previous
are as follows:
- Patch 3/8 calls "sh -c" instead of "/bin/sh -c"
- Patch 5/8 keeps the list sorted
Thanks to Johannes Sixt for reviewing v4
Erik Faye-Lund (6):
imap-send: use separate read and write fds
imap-send: use run-command API for tunneling
imap-send: fix compilation-error on Windows
imap-send: build imap-send on Windows
mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
mingw: enable OpenSSL
Jeff King (1):
imap-send: remove useless uid code
Marius Storm-Olsen (1):
MSVC: Enable OpenSSL, and translate -lcrypto
Makefile | 4 +-
compat/mingw.h | 21 ++++
compat/vcbuild/scripts/clink.pl | 3 +
contrib/buildsystems/engine.pl | 3 +
imap-send.c | 226 +++++++++------------------------------
5 files changed, 77 insertions(+), 180 deletions(-)
^ permalink raw reply
* [PATCH v4 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-19 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <7vaazonwtr.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> One solution to help the compiler catch this kind of semantic crash upon
> merging or applying code based on the old format_commit_message() would
> have been to change its function signature (or even the name), so that it
> would not go unnoticed that DATE_NORMAL that happens to be "0" is silently
> interpreted as (void *)0 == NULL.
Indeed, that would have been a good idea. (I still don't fully see
the use of allowing an enum value as a pointer, but apparently the
standard's that way.)
I fixed the calls to format_commit_message(), but without changing the
function signature compared to the last patch. I also decided not to
put in the test case; the easiest I could come up with was the
following:
-- 8< --
diff --git i/t/t5001-archive-attr.sh w/t/t5001-archive-attr.sh
index 426b319..0950527 100755
--- i/t/t5001-archive-attr.sh
+++ w/t/t5001-archive-attr.sh
@@ -4,7 +4,7 @@ test_description='git archive attribute tests'
. ./test-lib.sh
-SUBSTFORMAT=%H%n
+SUBSTFORMAT=%H%ad%n
test_expect_exists() {
test_expect_success " $1 exists" "test -e $1"
-- >8 --
which immediately fails most tests in the file because of segfaults
with the buggy series. However, it still wouldn't catch other broken
callers, if there were any, so I left it out.
Compared to v3, I also rebased the series on current master, which
conflicted with 7f98ebc (format_commit_message(): fix function
signature, 2009-10-15) so you now need that commit to apply it.
Finally, I squashed a revert of 0a0c342 (git-stash documentation:
mention default options for 'list', 2009-10-12) into 5/5 since there
are no more default options after my patch.
Thomas Rast (5):
Refactor pretty_print_commit arguments into a struct
reflog-walk: refactor the branch@{num} formatting
Introduce new pretty formats %g[sdD] for reflog information
stash list: use new %g formats instead of sed
stash list: drop the default limit of 10 stashes
Documentation/git-stash.txt | 3 +-
Documentation/pretty-formats.txt | 9 ++++
archive.c | 4 +-
builtin-branch.c | 3 +-
builtin-checkout.c | 3 +-
builtin-commit.c | 8 +++-
builtin-log.c | 3 +-
builtin-merge.c | 7 ++-
builtin-rev-list.c | 7 ++-
builtin-shortlog.c | 9 +++-
builtin-show-branch.c | 4 +-
commit.h | 20 ++++++---
git-stash.sh | 8 +---
log-tree.c | 25 ++++++-----
pretty.c | 44 ++++++++++++++------
reflog-walk.c | 83 ++++++++++++++++++++++++++++----------
reflog-walk.h | 8 ++++
t/t6006-rev-list-format.sh | 18 ++++++++
18 files changed, 189 insertions(+), 77 deletions(-)
^ permalink raw reply related
* [PATCH v4 2/5] reflog-walk: refactor the branch@{num} formatting
From: Thomas Rast @ 2009-10-19 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255966426.git.trast@student.ethz.ch>
We'll use the same output in an upcoming commit, so refactor its
formatting (which was duplicated anyway) into a separate function.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
reflog-walk.c | 54 ++++++++++++++++++++++++++++++++----------------------
1 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 5623ea6..596bafe 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -241,36 +241,46 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
commit->object.flags &= ~(ADDED | SEEN | SHOWN);
}
-void show_reflog_message(struct reflog_walk_info *info, int oneline,
+void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return;
+
+ strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (commit_reflog->flag || dmode) {
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ strbuf_addstr(sb, show_date(info->timestamp, info->tz, dmode));
+ } else {
+ strbuf_addf(sb, "%d", commit_reflog->reflogs->nr
+ - 2 - commit_reflog->recno);
+ }
+
+ strbuf_addch(sb, '}');
+}
+
+void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
- if (info && info->last_commit_reflog) {
- struct commit_reflog *commit_reflog = info->last_commit_reflog;
+ if (reflog_info && reflog_info->last_commit_reflog) {
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ get_reflog_selector(&selector, reflog_info, dmode);
if (oneline) {
- printf("%s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("}: %s", info->message);
+ printf("%s: %s", selector.buf, info->message);
}
else {
- printf("Reflog: %s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("} (%s)\nReflog message: %s",
- info->email, info->message);
+ printf("Reflog: %s (%s)\nReflog message: %s",
+ selector.buf, info->email, info->message);
}
+
+ strbuf_release(&selector);
}
}
--
1.6.5.1.137.gefbc6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox