* Re: git fsck not identifying corrupted packs
From: Johannes Sixt @ 2009-10-19 9:11 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091019T094924-194@post.gmane.org>
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.
-- Hannes
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Johan Herland @ 2009-10-19 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin
In-Reply-To: <7vhbtv6c76.fsf@alter.siamese.dyndns.org>
On Monday 19 October 2009, Junio C Hamano wrote:
> * jh/notes (2009-10-09) 22 commits.
> - fast-import: Proper notes tree manipulation using the notes API
> - Refactor notes concatenation into a flexible interface for combining notes
> - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
> - Notes API: for_each_note(): Traverse the entire notes tree with a callback
> - Notes API: get_note(): Return the note annotating the given object
> - Notes API: add_note(): Add note objects to the internal notes tree structure
> - Notes API: init_notes(): Initialize the notes tree from the given notes ref
> - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
> - Add selftests verifying concatenation of multiple notes for the same commit
> - Refactor notes code to concatenate multiple notes annotating the same object
> - Add selftests verifying that we can parse notes trees with various fanouts
> - Teach the notes lookup code to parse notes trees with various fanout schemes
> - Teach notes code to free its internal data structures on request
> - Add '%N'-format for pretty-printing commit notes
> - Add flags to get_commit_notes() to control the format of the note string
> - t3302-notes-index-expensive: Speed up create_repo()
> - fast-import: Add support for importing commit notes
> - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
> (this branch uses sr/gfi-options.)
Nope. This branch does not use sr/gfi-options. The jh/cvs-helper branch
does, though.
> Is this good for 'next' now?
Not all of it.
I suspect the first 14 patches are stable and 'next'-worthy, although
it would be nice if Dscho had the time to ACK them.
The last patch (#22) needs some major rework based on Shawn's comments
(I'm working on that, although I currently have less time than I hoped
for), and that rework might ripple into patches #15 through #21.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Moving git
From: rhlee @ 2009-10-19 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <20091016184251.GG19511@inocybe.localdomain>
Thanks, I've been looking for something like EPEL for a long time.
--
View this message in context: http://n2.nabble.com/Moving-git-tp3836198p3848039.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Johannes Schindelin @ 2009-10-19 9:57 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
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
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Johannes Schindelin @ 2009-10-19 10:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sergio Callegari, git
In-Reply-To: <4ADC2D45.3020803@viscovery.net>
Hi,
On Mon, 19 Oct 2009, 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.
Now, now.
If you were to test a new filesystem, say, wonderfulfs, and wanted to
check its integrity, would you not just run "fsck-wonderfulfs" if that
exists, rather than reading the fantamagastic manual? Would you not
expect that it Does The Right Thing? Would you not expect that it
follows the Law Of Minimal Surprise?
So FWIW I can see where Sergio is coming from.
Ciao,
Dscho
^ permalink raw reply
* 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
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