* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Ramkumar Ramachandra @ 2011-09-08 9:28 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Georgi Chorbadzhiyski, git
In-Reply-To: <vpq7h5jtngj.fsf@bauges.imag.fr>
Hi Matthieu and Georgi,
Matthieu Moy writes:
> There have been discussion (and IIRC a patch) proposing this already in
> the past. One advantage of sleeping a bit between each email is that it
> increase the chances for the receiver to receive the emails in the right
> order.
Ah, it looks like I missed the earlier discussion/ patch- sorry. Yes,
I've also wondered what to do about the order in which patches appear
in reply to the cover letter- I was of the opinion that it was a minor
inconvenience that we have to put up with that until SMTP servers
learn to fix these things. Slowing things down a little bit for now
until they catch up is probably a good idea.
Georgi Chorbadzhiyski writes:
> See for example this: http://mailman.videolan.org/pipermail/dvblast-devel/2011-August/thread.html
> The thread named: [dvblast-devel] [PATCH 0/4] Post git migration changes
> See how 1,3,4/4 are not detected to be part of the thread even when
> all headers are set correctly by git-send-email.
This is a far more serious problem. For this, I was toying with the
idea of special cover-letter handling in git-send-email. My idea was
that it should essentially send the cover letter, wait for a second
and then send all the other emails concurrently. Sure, slowing the
entire process down would work too, but it's not so elegant.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCHv2 4/5] branch: introduce --list option
From: Michael J Gruber @ 2011-09-08 9:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20110907195611.GD13364@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 07.09.2011 21:56:
> On Sun, Aug 28, 2011 at 04:37:04PM +0200, Michael J Gruber wrote:
>
>> Currently, "-m -d" is forbidden", but "-m -v" is "-m", same for "-d -v".
>> Do we want to keep it like that? Probably. I'll add the tests to 4/5.
>
> Yes, I think so. "-v" just means "be more verbose"; the fact that
> there is currently nothing to be more verbose about with "-m" and "-d"
> is irrelevant.
>
> It does make me a little nervous about the "'git branch -v'
> automatically means 'git branch --list -v'" patch, though. It closes the
> door in the future to us being more or less verbose about branch
> creation details (and while helpful, it creates a slight inconsistency
> in the interface).
>
> If we are adding "-l" anyway, is it really necessary? It's not much
> harder to do "git branch -lv" once that is in place.
Well, it will take a while to (re-)take "-l". For the sake of
consistency I wouldn't mind making "--verbose" strictly a "modifier" for
whatever mode/subcommand of the command is going on, even though it
would mean having to type "-v --list" for a long time. In general,
-v/--verbose should always be like that, but is not (e.g. tag -v).
This is in next now but no harm would be done changing it now.
Michael
^ permalink raw reply
* Re: [PATCH 0/5] RFC: patterns for branch list
From: Michael J Gruber @ 2011-09-08 9:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Michael Schubert
In-Reply-To: <20110907195319.GC13364@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 07.09.2011 21:53:
> On Fri, Aug 26, 2011 at 09:55:37AM -0700, Junio C Hamano wrote:
>
>> As we use fnmatch() and not match_pathspec() for this pattern matching,
>> "git branch peff/" will not list all the topics under the peff/ hierarchy
>> (your example "git branch peff/\*" would be the way), but I would imagine
>> that we may someday want to update it to allow the leading path match
>> here. And at that point, distinction between
>>
>> git branch peff ;# to create a "peff" branch
>> git branch peff/ ;# to list "peff/" branches, as "peff/" itself is
>> ;# an invalid branch name and your auto listing
>> ;# heuristic kicks in
>>
>> while it might be very useful for experts, becomes too subtle and would
>> confuse new people. We should instead require an explicit -l/--list, and
>> not use the auto listing heuristics (it is fine for -v to imply -l).
>
> Sorry, I'm atrociously behind on reviewing this topic. But FWIW, I
> completely agree with this. Detecting invalid branch formats is much too
> subtle and error prone, and we are better off making a short and
> easy-to-type version of "--list".
We all agreed on that, you didn't miss anything ;)
Michael
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Georgi Chorbadzhiyski @ 2011-09-08 9:11 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <CALkWK0kH+pD6ymtt9oWLhT0Bftp4EvtrwTtNVw6mjX0aObb-BQ@mail.gmail.com>
Around 09/08/2011 11:43 AM, Ramkumar Ramachandra scribbled:
> Hi Georgi,
>
> Georgi Chorbadzhiyski writes:
>> Sometimes when sending lots of changes it is not nice
>> to send emails as fast as possible. Of course you can
>> confirm each email after waiting couple of seconds but
>> this is not optimal. This patch adds --sleep option
>> to git-send-mail and corresponding sendmail.sleep config
>> variable to control how much seconds to wait between
>> sending each email. The default is 0 (not wait at all).
>
> I use git-send-email a lot, and I ask it to print out the list of all
> emails once before confirming. After confirming, I just switch back
> to Emacs and continue work- in the many instances, I've never actually
> needed to slow the process down. If anything, I wished it could
> concurrently send many emails and do things /faster/ *. I'm a little
> curious about why you want to slow it down- is your SMTP server
> configured to block you because it suspects that you're trying to
> spam?
>
> Thanks.
>
> * I first need to see if SMTP servers today can take in emails at this
> speed without suspecting spam.
It is not the mail server, it is workaround mainly for web archives and
MUAs that look at received dates when sorting threads.
When they receive a lot of email in one thread very quickly (and out of
order) they do not thread correctly.
See for example this: http://mailman.videolan.org/pipermail/dvblast-devel/2011-August/thread.html
The thread named: [dvblast-devel] [PATCH 0/4] Post git migration changes
See how 1,3,4/4 are not detected to be part of the thread even when
all headers are set correctly by git-send-email.
Probably my mail server send them out of order and that is why I have
the idea to introduce some small delay between sending each email. Easier
on the MTA, works around the possibility to send emails out of order
the flip side is that it takes more time.
--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
^ permalink raw reply
* Re: [PATCHv2 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Martin von Zweigbergk @ 2011-09-08 9:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, git, Jeff King
In-Reply-To: <7vzkifzol6.fsf@alter.siamese.dyndns.org>
On Wed, 7 Sep 2011, Junio C Hamano wrote:
> Later in the same mv() function, the other one renames refs/remotes/$OLD/
> to refs/remotes/$NEW/, even when you did not find any fetch refspec that
> stores under "refs/remotes/$OLD/<anything>" in the earlier logic.
Ah, of course. Sorry for being slow and thanks for the explanation. So
if there are two configured refspecs with RHSs "refs/remotes/$OLD/foo"
and "refs/remotes/$OLD/bar/*", we should remember that we updated
those and only update refs that match the same patterns. I will see
what I can do and will hopefully soon get back with a "patch 4/2".
Martin
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Matthieu Moy @ 2011-09-08 9:03 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Georgi Chorbadzhiyski, git
In-Reply-To: <CALkWK0kH+pD6ymtt9oWLhT0Bftp4EvtrwTtNVw6mjX0aObb-BQ@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> I'm a little curious about why you want to slow it down- is your SMTP
> server configured to block you because it suspects that you're trying
> to spam?
There have been discussion (and IIRC a patch) proposing this already in
the past. One advantage of sleeping a bit between each email is that it
increase the chances for the receiver to receive the emails in the right
order.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Ramkumar Ramachandra @ 2011-09-08 8:43 UTC (permalink / raw)
To: Georgi Chorbadzhiyski; +Cc: git
In-Reply-To: <1315428191-9769-1-git-send-email-gf@unixsol.org>
Hi Georgi,
Georgi Chorbadzhiyski writes:
> Sometimes when sending lots of changes it is not nice
> to send emails as fast as possible. Of course you can
> confirm each email after waiting couple of seconds but
> this is not optimal. This patch adds --sleep option
> to git-send-mail and corresponding sendmail.sleep config
> variable to control how much seconds to wait between
> sending each email. The default is 0 (not wait at all).
I use git-send-email a lot, and I ask it to print out the list of all
emails once before confirming. After confirming, I just switch back
to Emacs and continue work- in the many instances, I've never actually
needed to slow the process down. If anything, I wished it could
concurrently send many emails and do things /faster/ *. I'm a little
curious about why you want to slow it down- is your SMTP server
configured to block you because it suspects that you're trying to
spam?
Thanks.
* I first need to see if SMTP servers today can take in emails at this
speed without suspecting spam.
-- Ram
^ permalink raw reply
* Re: git push output goes into stderr
From: Sitaram Chamarty @ 2011-09-08 8:24 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, Junio C Hamano, Lynn Lin, git
In-Reply-To: <20110908070706.GA1454@sigill.intra.peff.net>
On Thu, Sep 8, 2011 at 12:37 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Sep 08, 2011 at 11:12:48AM +0530, Sitaram Chamarty wrote:
>
>> > But with a program whose main function is to perform an action, like
>> > "git push", I think there are really two ways to look at it:
>> >
>> > 1. There is no main output; any progress or status update is just
>> > diagnostic chat, and should go to stderr.
>> >
>> > 2. The main output is the status report; it goes to stdout, and
>> > progress updates go to stderr.
>>
>> I always thought if you write stuff to stdout the remote client gets
>> confused because it is executing to a defined protocol and suddenly
>> sees unexpected input in the middle.
>>
>> Bit if *you* are saying this (output random stuff to STDOUT) can
>> happen if we want it to, clearly I was wrong...
>
> For the remote side, yes, we have to be sure not to pollute stdout,
> because that's where the protocol is going.. But the status table is
> generated on the client side, so stdout is just connected to the user's
> terminal there.
aah ok, that makes sense; thanks.
^ permalink raw reply
* How to specify a default <start-point> for git branch
From: Lay, Stefan @ 2011-09-08 8:00 UTC (permalink / raw)
To: git@vger.kernel.org, jgit-dev@eclipse.org; +Cc: manuel.doniger@googlemail.com
Is it possible in git to configure a default <start-point> for the git-branch command?
For some workflows it could be useful to define e.g. a remote-tracking branch as the default <start-point> for new branches. Then there would be a tracking configuration for each created branch and tools like ALM tools could easily determine the remote repository.
For EGit-/JGit-development there is a proposal in Gerrit to add a new config parameter workflow.defaultsourceref (http://egit.eclipse.org/r/#change,4168). I suggested to use workflow.branchstartpoint instead.
What do you think about such a property?
^ permalink raw reply
* [PATCH] Add a note to the README for new contributors
From: Andrew Ardill @ 2011-09-08 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <1315464479-6876-1-git-send-email-andrew.ardill@gmail.com>
Signed-off-by: Andrew Ardill <andrew.ardill@gmail.com>
---
README | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 67cfeb2..b67a881 100644
--- a/README
+++ b/README
@@ -52,3 +52,7 @@ git.git (stable)" and "What's cooking in git.git (topics)" and
the discussion following them on the mailing list give a good
reference for project status, development direction and
remaining tasks.
+
+If you are looking to contribute to the project, a good place to start
+is http://git-blame.blogspot.com/p/note-from-maintainer.html and in
+Documentation/howto/maintain-git.txt
--
1.7.6.msysgit.0
^ permalink raw reply related
* Re: [PATCH 1/3] remove prefix argument from pathspec_prefix
From: Clemens Buchacher @ 2011-09-08 7:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaaah8muf.fsf@alter.siamese.dyndns.org>
On Tue, Sep 06, 2011 at 12:58:16PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Is it because we no longer ever return "prefix" we pass in which is a
> > pointer to a constant memory region to begin with?
> >
> > We also didn't free() in the earlier code (because we do not know if it
> > can be freed) and leaking xmemdupz() if the function didn't return the
> > "prefix", but now you plugged the small leak. Isn't it something you
> > should advertise?
>
> Nah, the leak is not necessarily plugged in all callers anyway, so scratch
> that part. I've rewritten it like this:
Ok.
The only other caller, though, is cmd_ls_files(). And it would be
trivial to plug that leak as well.
But is it considered a leak, if the program is going to terminate
right after the function returns? I recall that being used as an
argument against free'ing such memory on this list.
On the other hand, that practice makes it harder to analyze leaks
using memory leak detectors like for example valgrind.
Clemens
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Francis Moreau @ 2011-09-08 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vk49k48q4.fsf@alter.siamese.dyndns.org>
On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Francis Moreau <francis.moro@gmail.com> writes:
>
>> If I start the rebase process with : "git rebase -i -p master foo"
>> then the filtering is happening. Here 'foo' has been created with
>> v2.6.39 tag as start point and contains some patches cherry-picked
>> from the upstream.
>>
>> However if I call git-rebase this way: "git rebase -i -p --onto master
>> v2.6.39 foo", then it seems that no filtering is done.
>>
>> Is that expected ?
>
> Because "rebase --onto A B C" has to be usable when commit A does not have
> any ancestry relationship with the history between B and C,
But is it the common case ? That would mean that A and B are part of
totaly independant branches which is not that common I think.
I'm using "git rebase --onto A B C" because I want to simplify git's
work. I know that any commits between A..B are already in A history
and I'm not interested in rebasing them anyways.
> I wouldn't be
> surprised if the command does not look at commits on the history that lead
> to A that _might_ be related to the ones between B and C. It does not know
> how far to dig from A and stop, and obviously you do not want to dig down
> to the beginning of the history. "rebase A B" on the other hand can safely
> stop digging the history back from A down to where the history leading to
> B forked (i.e. merge base between A and B).
Hmm I dont understand why "rebase --onto A B C" wouldn't try to find
the merge base between A and B. If it doesn't (which is quite uncommon
I guess) then don't do the filtering as we're currently doing but if
there's a merge base (common case) then do the filtering.
No ?
--
Francis
^ permalink raw reply
* Re: git push output goes into stderr
From: Jeff King @ 2011-09-08 7:07 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Clemens Buchacher, Junio C Hamano, Lynn Lin, git
In-Reply-To: <CAMK1S_gro=THLkc_wrHSLwUVaJp9k-zRDuFDQpOGaiyBTHiDnQ@mail.gmail.com>
On Thu, Sep 08, 2011 at 11:12:48AM +0530, Sitaram Chamarty wrote:
> > But with a program whose main function is to perform an action, like
> > "git push", I think there are really two ways to look at it:
> >
> > 1. There is no main output; any progress or status update is just
> > diagnostic chat, and should go to stderr.
> >
> > 2. The main output is the status report; it goes to stdout, and
> > progress updates go to stderr.
>
> I always thought if you write stuff to stdout the remote client gets
> confused because it is executing to a defined protocol and suddenly
> sees unexpected input in the middle.
>
> Bit if *you* are saying this (output random stuff to STDOUT) can
> happen if we want it to, clearly I was wrong...
For the remote side, yes, we have to be sure not to pollute stdout,
because that's where the protocol is going.. But the status table is
generated on the client side, so stdout is just connected to the user's
terminal there.
We already generate --porcelain status output from push on stdout (and
again, that makes sense to me philosophically, because the user is
asking push to generate the output). So it's clearly not a big deal.
It's just a matter of taste.
-Peff
^ permalink raw reply
* Make it easier for new contributors to come to grips with the project
From: Andrew Ardill @ 2011-09-08 6:47 UTC (permalink / raw)
To: git
Something that has been difficult as a developer looking to contribute
to this project is trying to understand how everything is organised.
In particular, working out what 'pu' stood for took quite a long time.
Following is a (very) simple patch to the README that will at least
send potential contributors off in a useful direction. I know I would
have saved much time if this note was there when I started looking.
Potentially, the wiki and public website could be updated to provide
similar links and start-up hints.
^ permalink raw reply
* Re: git.kernel.org problems?
From: J.H. @ 2011-09-08 6:30 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git
In-Reply-To: <CAH5451mouz=7Bvsk18iuB04aFwp0VS2mNYSJdmCH82iw6xU7Qw@mail.gmail.com>
There are currently known dns issues that are being worked on.
- John 'Warthog9' Hawley
On 09/07/2011 09:39 PM, Andrew Ardill wrote:
> Anyone else getting issues connecting to git.kernel.org sites?
> http://www.isup.me/git.kernel.org is reporting that it is up sometimes
> and down sometimes, and I have resolved some resources fine earlier
> (for example git.kernel.org/?p=git/git.git;a=tree;h=todo;hb=todo)
> however everything fails for me now.
>
> Any ideas?
>
> Regards,
>
> Andrew Ardill
> --
> 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 push output goes into stderr
From: Sitaram Chamarty @ 2011-09-08 5:42 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, Junio C Hamano, Lynn Lin, git
In-Reply-To: <20110907215716.GJ13364@sigill.intra.peff.net>
On Thu, Sep 8, 2011 at 3:27 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Sep 06, 2011 at 09:49:16AM +0200, Clemens Buchacher wrote:
>
>> On Sun, Sep 04, 2011 at 05:57:53PM -0700, Junio C Hamano wrote:
>> > Lynn Lin <lynn.xin.lin@gmail.com> writes:
>> >
>> > > When I create a local branch and then push it to remote. I find that
>> > > the output without error goes into stderr, is this expected?
>> >
>> > Progress output are sent to the stderr stream.
>>
>> But it's not only progress output that goes to stderr in case of
>> git push. Even the summary written in tranport_print_push_status
>> goes to stderr, unless we specify git push --porcelain. Can't we
>> let that part of the output go to stdout unconditionally?
>
> We could, though it makes more sense on stderr to me.
>
> Stdout has always been about "the main program output" and stderr about
> diagnostic messages. With a program whose main function is to generate
> output (e.g., "git tag -l", it's very easy to know that the list of tags
> is the main program output (which you don't want to pollute with
> anything else), and any problems or even general chattiness goes to
> stderr.
>
> But with a program whose main function is to perform an action, like
> "git push", I think there are really two ways to look at it:
>
> 1. There is no main output; any progress or status update is just
> diagnostic chat, and should go to stderr.
>
> 2. The main output is the status report; it goes to stdout, and
> progress updates go to stderr.
I always thought if you write stuff to stdout the remote client gets
confused because it is executing to a defined protocol and suddenly
sees unexpected input in the middle.
Bit if *you* are saying this (output random stuff to STDOUT) can
happen if we want it to, clearly I was wrong...
> I think both are equally valid mental models, and both are consistent
> with the philosophy above. If we switch, I wouldn't be surprised to see
> somebody say "why is this going to stdout, it should be on stderr". In
> fact, I seem to recall that we've had this discussion before on the
> list.
^ permalink raw reply
* [PATCH 5/2] push -s: receiving end
From: Junio C Hamano @ 2011-09-08 5:38 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Johan Herland
In-Reply-To: <7vehzrzm0e.fsf@alter.siamese.dyndns.org>
This stores the GPG signed push certificate in the receiving repository
using the notes mechanism. The certificate is appended to a note in the
refs/notes/signed-push tree for each object that appears on the right
hand side of the push certificate, i.e. the object that was pushed to
update the tip of a ref.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is largely untested, so take it with a large grain of salt.
This concludes tonight's hacking session for me.
builtin/receive-pack.c | 74 +++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 307fc3b..257f2a5 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -11,6 +11,11 @@
#include "transport.h"
#include "string-list.h"
#include "sha1-array.h"
+#include "gpg-interface.h"
+#include "notes.h"
+#include "notes-merge.h"
+#include "blob.h"
+#include "tag.h"
static const char receive_pack_usage[] = "git receive-pack <git-dir>";
@@ -156,6 +161,7 @@ struct command {
};
static const char pre_receive_hook[] = "hooks/pre-receive";
+static const char pre_receive_signature_hook[] = "hooks/pre-receive-signature";
static const char post_receive_hook[] = "hooks/post-receive";
static void rp_error(const char *err, ...) __attribute__((format (printf, 1, 2)));
@@ -581,6 +587,22 @@ static void check_aliased_updates(struct command *commands)
string_list_clear(&ref_list, 0);
}
+static void get_note_text(struct strbuf *buf, struct notes_tree *t,
+ const unsigned char *object)
+{
+ const unsigned char *sha1 = get_note(t, object);
+ char *text;
+ unsigned long len;
+ enum object_type type;
+
+ if (!sha1)
+ return;
+ text = read_sha1_file(sha1, &type, &len);
+ if (text && len && type == OBJ_BLOB)
+ strbuf_add(buf, text, len);
+ free(text);
+}
+
static int record_signed_push(char *cert)
{
/*
@@ -591,19 +613,57 @@ static int record_signed_push(char *cert)
*
* You could also feed the signed push certificate to GPG,
* verify the signer identity, and all the other fun stuff,
- * including feeding it to "pre-push-verify-signature" hook.
- *
- * Here we just throw it to stderr to demonstrate that the
- * codepath is being exercised.
+ * including feeding it to "pre-receive-signature" hook.
*/
+ size_t total, payload;
char *cp, *ep;
- for (cp = cert; *cp; cp = ep) {
+ int ret = 0;
+ struct notes_tree *t;
+ struct strbuf nbuf = STRBUF_INIT;
+
+ init_notes(NULL, "refs/notes/signed-push", NULL, 0);
+ t = &default_notes_tree;
+
+ total = strlen(cert);
+ payload = parse_signature(cert, total);
+ for (cp = cert; cp < cert + payload; cp = ep) {
+ unsigned char sha1[20], nsha1[20];
+
ep = strchrnul(cp, '\n');
if (*ep == '\n')
ep++;
- fprintf(stderr, "RSP: %.*s", (int)(ep - cp), cp);
+ if (prefixcmp(cp, "Update: "))
+ continue;
+ cp += strlen("Update: ");
+ if (get_sha1_hex(cp, sha1) || cp[40] != ' ')
+ continue;
+ cp += 41;
+ if (get_sha1_hex(cp, sha1) || cp[40] != ' ')
+ continue;
+
+ get_note_text(&nbuf, t, sha1);
+ if (nbuf.len)
+ strbuf_addch(&nbuf, '\n');
+ strbuf_add(&nbuf, cert, total);
+ if (write_sha1_file(nbuf.buf, nbuf.len, blob_type, nsha1) ||
+ add_note(t, sha1, nsha1, NULL))
+ ret = error(_("unable to write note object"));
+ strbuf_reset(&nbuf);
}
- return 0;
+
+ if (!ret) {
+ unsigned char commit[20];
+ unsigned char parent[20];
+ struct ref_lock *lock;
+
+ resolve_ref(t->ref, parent, 0, NULL);
+ lock = lock_any_ref_for_update(t->ref, parent, 0);
+ create_notes_commit(t, NULL, "push", commit);
+ ret = write_ref_sha1(lock, commit, "push");
+ }
+ free_notes(t);
+
+ return ret;
}
static void execute_commands(struct command *commands, const char *unpacker_error)
--
1.7.7.rc0.188.g3793ac
^ permalink raw reply related
* git.kernel.org problems?
From: Andrew Ardill @ 2011-09-08 4:39 UTC (permalink / raw)
To: git
Anyone else getting issues connecting to git.kernel.org sites?
http://www.isup.me/git.kernel.org is reporting that it is up sometimes
and down sometimes, and I have resolved some resources fine earlier
(for example git.kernel.org/?p=git/git.git;a=tree;h=todo;hb=todo)
however everything fails for me now.
Any ideas?
Regards,
Andrew Ardill
^ permalink raw reply
* [PATCH 4/2] push -s: send signed push certificate
From: Junio C Hamano @ 2011-09-08 4:38 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <7vbouw2hqg.fsf@alter.siamese.dyndns.org>
And this uses the GPG interface to sign the push certificate. The format
of the signed certificate is very similar to a signed tag, in that the
result is a concatenation of the payload, immediately followed by a
detached signature.
This places the same constraint as an annotated tag on the push
certificate payload; it has to be a text file and the final line
must not be an incomplete line.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/send-pack.c | 29 ++++++++++++-----------------
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 3193f34..298e181 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -8,6 +8,7 @@
#include "send-pack.h"
#include "quote.h"
#include "transport.h"
+#include "gpg-interface.h"
static const char send_pack_usage[] =
"git send-pack [--all | --mirror] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
@@ -237,25 +238,18 @@ static int sideband_demux(int in, int out, void *data)
return ret;
}
-static void sign_push_certificate(struct strbuf *cert)
+/*
+ * Take the contents of cert->buf, and have the user GPG sign it, and
+ * read it back in the strbuf.
+ */
+static int sign_push_certificate(struct strbuf *cert)
{
/*
- * Here, take the contents of cert->buf, and have the user GPG
- * sign it, and read it back in the strbuf.
- *
- * You may want to append some extra info to cert before giving
- * it to GPG, possibly via a hook.
- *
- * Here we upcase them just to demonstrate that the codepath
- * is being exercised.
+ * You may want to append some extra info to cert before
+ * giving it to GPG, possibly via a hook, here.
*/
- char *cp;
- for (cp = cert->buf; *cp; cp++) {
- int ch = *cp;
- if ('a' <= ch && ch <= 'z')
- *cp = toupper(ch);
- }
- return;
+
+ return sign_buffer(cert, git_committer_info(IDENT_NO_DATE));
}
int send_pack(struct send_pack_args *args,
@@ -370,7 +364,8 @@ int send_pack(struct send_pack_args *args,
if (signed_push) {
char *cp, *ep;
- sign_push_certificate(&push_cert);
+ if (sign_push_certificate(&push_cert))
+ return error(_("failed to sign push certificate"));
strbuf_reset(&req_buf);
for (cp = push_cert.buf; *cp; cp = ep) {
ep = strchrnul(cp, '\n');
--
1.7.7.rc0.188.g3793ac
^ permalink raw reply related
* [PATCH 3/2] Split GPG interface into its own helper library
From: Junio C Hamano @ 2011-09-08 4:37 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <7vbouw2hqg.fsf@alter.siamese.dyndns.org>
This moves existing code from builtin/tag.c (for signing) and
builtin/verify-tag.c (for verifying) to a new gpg-interface.c file to
provide a more generic library interface.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 2 +
builtin/tag.c | 60 ++++----------------------------
builtin/verify-tag.c | 35 ++-----------------
gpg-interface.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++
gpg-interface.h | 11 ++++++
5 files changed, 117 insertions(+), 85 deletions(-)
create mode 100644 gpg-interface.c
create mode 100644 gpg-interface.h
diff --git a/Makefile b/Makefile
index 8d6d451..2183223 100644
--- a/Makefile
+++ b/Makefile
@@ -530,6 +530,7 @@ LIB_H += exec_cmd.h
LIB_H += fsck.h
LIB_H += gettext.h
LIB_H += git-compat-util.h
+LIB_H += gpg-interface.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
@@ -620,6 +621,7 @@ LIB_OBJS += entry.o
LIB_OBJS += environment.o
LIB_OBJS += exec_cmd.o
LIB_OBJS += fsck.o
+LIB_OBJS += gpg-interface.o
LIB_OBJS += graph.o
LIB_OBJS += grep.o
LIB_OBJS += hash.o
diff --git a/builtin/tag.c b/builtin/tag.c
index 667515e..e9d36fa 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -14,6 +14,7 @@
#include "parse-options.h"
#include "diff.h"
#include "revision.h"
+#include "gpg-interface.h"
static const char * const git_tag_usage[] = {
"git tag [-a|-s|-u <key-id>] [-f] [-m <msg>|-F <file>] <tagname> [<head>]",
@@ -208,60 +209,13 @@ static int verify_tag(const char *name, const char *ref,
static int do_sign(struct strbuf *buffer)
{
- struct child_process gpg;
- const char *args[4];
- char *bracket;
- int len;
- int i, j;
+ const char *key;
- if (!*signingkey) {
- if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
- sizeof(signingkey)) > sizeof(signingkey) - 1)
- return error(_("committer info too long."));
- bracket = strchr(signingkey, '>');
- if (bracket)
- bracket[1] = '\0';
- }
-
- /* When the username signingkey is bad, program could be terminated
- * because gpg exits without reading and then write gets SIGPIPE. */
- signal(SIGPIPE, SIG_IGN);
-
- memset(&gpg, 0, sizeof(gpg));
- gpg.argv = args;
- gpg.in = -1;
- gpg.out = -1;
- args[0] = "gpg";
- args[1] = "-bsau";
- args[2] = signingkey;
- args[3] = NULL;
-
- if (start_command(&gpg))
- return error(_("could not run gpg."));
-
- if (write_in_full(gpg.in, buffer->buf, buffer->len) != buffer->len) {
- close(gpg.in);
- close(gpg.out);
- finish_command(&gpg);
- return error(_("gpg did not accept the tag data"));
- }
- close(gpg.in);
- len = strbuf_read(buffer, gpg.out, 1024);
- close(gpg.out);
-
- if (finish_command(&gpg) || !len || len < 0)
- return error(_("gpg failed to sign the tag"));
-
- /* Strip CR from the line endings, in case we are on Windows. */
- for (i = j = 0; i < buffer->len; i++)
- if (buffer->buf[i] != '\r') {
- if (i != j)
- buffer->buf[j] = buffer->buf[i];
- j++;
- }
- strbuf_setlen(buffer, j);
-
- return 0;
+ if (*signingkey)
+ key = signingkey;
+ else
+ key = git_committer_info(IDENT_ERROR_ON_NO_NAME|IDENT_NO_DATE);
+ return sign_buffer(buffer, key);
}
static const char tag_template[] =
diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
index 3134766..8b4f742 100644
--- a/builtin/verify-tag.c
+++ b/builtin/verify-tag.c
@@ -11,6 +11,7 @@
#include "run-command.h"
#include <signal.h>
#include "parse-options.h"
+#include "gpg-interface.h"
static const char * const verify_tag_usage[] = {
"git verify-tag [-v|--verbose] <tag>...",
@@ -19,42 +20,12 @@ static const char * const verify_tag_usage[] = {
static int run_gpg_verify(const char *buf, unsigned long size, int verbose)
{
- struct child_process gpg;
- const char *args_gpg[] = {"gpg", "--verify", "FILE", "-", NULL};
- char path[PATH_MAX];
- size_t len;
- int fd, ret;
+ int len;
- fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
- if (fd < 0)
- return error("could not create temporary file '%s': %s",
- path, strerror(errno));
- if (write_in_full(fd, buf, size) < 0)
- return error("failed writing temporary file '%s': %s",
- path, strerror(errno));
- close(fd);
-
- /* find the length without signature */
len = parse_signature(buf, size);
if (verbose)
write_in_full(1, buf, len);
-
- memset(&gpg, 0, sizeof(gpg));
- gpg.argv = args_gpg;
- gpg.in = -1;
- args_gpg[2] = path;
- if (start_command(&gpg)) {
- unlink(path);
- return error("could not run gpg.");
- }
-
- write_in_full(gpg.in, buf, len);
- close(gpg.in);
- ret = finish_command(&gpg);
-
- unlink_or_warn(path);
-
- return ret;
+ return verify_signed_buffer(buf, size, len);
}
static int verify_tag(const char *name, int verbose)
diff --git a/gpg-interface.c b/gpg-interface.c
new file mode 100644
index 0000000..b83cca1
--- /dev/null
+++ b/gpg-interface.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2011, Google Inc.
+ */
+#include "cache.h"
+#include "run-command.h"
+#include "strbuf.h"
+#include "gpg-interface.h"
+#include "sigchain.h"
+
+int sign_buffer(struct strbuf *buffer, const char *signing_key)
+{
+ struct child_process gpg;
+ const char *args[4];
+ ssize_t len;
+ int i, j;
+
+ memset(&gpg, 0, sizeof(gpg));
+ gpg.argv = args;
+ gpg.in = -1;
+ gpg.out = -1;
+ args[0] = "gpg";
+ args[1] = "-bsau";
+ args[2] = signing_key;
+ args[3] = NULL;
+
+ if (start_command(&gpg))
+ return error(_("could not run gpg."));
+
+ /*
+ * When the username signingkey is bad, program could be terminated
+ * because gpg exits without reading and then write gets SIGPIPE.
+ */
+ sigchain_push(SIGPIPE, SIG_IGN);
+
+ if (write_in_full(gpg.in, buffer->buf, buffer->len) != buffer->len) {
+ close(gpg.in);
+ close(gpg.out);
+ finish_command(&gpg);
+ return error(_("gpg did not accept the data"));
+ }
+ close(gpg.in);
+ len = strbuf_read(buffer, gpg.out, 1024);
+ close(gpg.out);
+
+ sigchain_pop(SIGPIPE);
+
+ if (finish_command(&gpg) || !len || len < 0)
+ return error(_("gpg failed to sign the data"));
+
+ /* Strip CR from the line endings, in case we are on Windows. */
+ for (i = j = 0; i < buffer->len; i++)
+ if (buffer->buf[i] != '\r') {
+ if (i != j)
+ buffer->buf[j] = buffer->buf[i];
+ j++;
+ }
+ strbuf_setlen(buffer, j);
+
+ return 0;
+}
+
+int verify_signed_buffer(const char *buf, size_t total, size_t payload)
+{
+ struct child_process gpg;
+ const char *args_gpg[] = {"gpg", "--verify", "FILE", "-", NULL};
+ char path[PATH_MAX];
+ int fd, ret;
+
+ fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
+ if (fd < 0)
+ return error("could not create temporary file '%s': %s",
+ path, strerror(errno));
+ if (write_in_full(fd, buf, total) < 0)
+ return error("failed writing temporary file '%s': %s",
+ path, strerror(errno));
+ close(fd);
+
+ memset(&gpg, 0, sizeof(gpg));
+ gpg.argv = args_gpg;
+ gpg.in = -1;
+ args_gpg[2] = path;
+ if (start_command(&gpg)) {
+ unlink(path);
+ return error("could not run gpg.");
+ }
+
+ write_in_full(gpg.in, buf, payload);
+ close(gpg.in);
+ ret = finish_command(&gpg);
+
+ unlink_or_warn(path);
+
+ return ret;
+}
diff --git a/gpg-interface.h b/gpg-interface.h
new file mode 100644
index 0000000..7689357
--- /dev/null
+++ b/gpg-interface.h
@@ -0,0 +1,11 @@
+#ifndef GPG_INTERFACE_H
+#define GPG_INTERFACE_H
+
+/*
+ * Copyright (c) 2011, Google Inc.
+ */
+
+extern int sign_buffer(struct strbuf *buffer, const char *signing_key);
+extern int verify_signed_buffer(const char *buffer, size_t total, size_t payload);
+
+#endif
--
1.7.7.rc0.188.g3793ac
^ permalink raw reply related
* Re: [PATCHv2 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Junio C Hamano @ 2011-09-08 3:43 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Jeff King
In-Reply-To: <alpine.DEB.2.00.1109062136350.12564@debian>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> same pattern both when updating refspecs and when renaming refs. Of
> course, we can never be certain that a ref "refs/remotes/origin/foo"
> is really related to the remote called "origin". The user could have
> simply created the ref manually. Is that what you are getting at?
You have two separate and independent code that are not linked together
but should logically be.
One updates fetch refspec whose RHS is "refs/remotes/$OLD/<anything>" to
"refs/remotes/$NEW/<the same thing>". If you do not find any such fetch
refspec, then you do not update these configuration variables, which is
good.
Later in the same mv() function, the other one renames refs/remotes/$OLD/
to refs/remotes/$NEW/, even when you did not find any fetch refspec that
stores under "refs/remotes/$OLD/<anything>" in the earlier logic.
Now, these actual refs may have been placed manually by the user. They may
have been placed by an old config that the user may have edited. You
simply do not know.
But you know one thing. You _do_ know is that these refs did _not_ come
from any "[remote "$OLD"] fetch = ..." configuration, and by inference, it
will not come from any "[remote "$NEW"] fetch = ...", in other words, they
do not have any relation with the "$NEW" remote. So I do not see a good
reason to move them from refs/remotes/$OLD/ to refs/remotes/$NEW/. That
was what I was pointing out.
^ permalink raw reply
* Re: Pushing with --mirror over HTTP?
From: Eli Barzilay @ 2011-09-08 2:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110907213950.GI13364@sigill.intra.peff.net>
5 hours ago, Jeff King wrote:
> On Mon, Sep 05, 2011 at 12:05:37AM -0400, Eli Barzilay wrote:
>
> > Is there anything broken with pushing with mirror over HTTP? I'm
> > trying that with a github url, and I get a broken-looking error
> > message:
> >
> > remote part of refspec is not a valid name in :.have
>
> It's probably nothing to do with http, but rather with alternate
> object databases on the server (which GitHub uses heavily). The
> server hands out fake ".have" refs telling you it has some other
> branch tips to base packs off of. So I suspect the "push --mirror"
> code is simply wrong for trying to update those refs (it may be
> exacerbated by using http, though, as the remote helper code seems
> to have some extra checks).
Ah -- I thought that this was some result of parsing some text message
or something like that, maybe if the error was
remote part of refspec is not a valid name in ":.have"
or even
remote part of refspec is not a valid name in: :.have
it would have been clearer? Seems like it's a good place for this
since some `:foo' is likely to appear there, and the colon can be
confused as part of the text.
Also, maybe the man page should say something about `--mirror' not
working well with such servers? It looks to me like mirroring to
github and to google code would be pretty popular.
> > and with the google code, I get:
> >
> > error: unable to push to unqualified destination: HEAD
> >
> > Pushing to both of these work fine without `--mirror'.
>
> This one, I'm not sure. It may be related.
>
> > (BTW, as a workaround, I'm using
> > push --force --tags <url> :
> > is this achieving the same effect for a repo without weird refs?)
>
> Not quite. I think:
>
> git push --force <url> refs/*:refs/*
>
> would be closer.
Thanks -- I'll use that instead.
> But even that's not quite right. I believe that "--mirror" will
> also delete any remote refs that don't exist locally (which is why
> you are seeing the ":.have" refspec above, which attempts to delete
> it).
Is there some way of doing that? (We do use a branch during releases
that is deleted after the release, so I need to propagate these
deletions.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
^ permalink raw reply
* Re: [PATCH v2] date.c: Support iso8601 timezone formats
From: Haitao Li @ 2011-09-08 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vaaag4794.fsf@alter.siamese.dyndns.org>
>> + } else {
>> + /* Only hours specified */
>
> That comment belongs to inside the following if() {...}.
>
>> + if (n == 1 || n == 2) {
>
> ... i.e. here.
>
Good catch!
>> - if (min < 60 && n > 2) {
>> + if (n > 0 && min < 60 && hour < 25) {
>
> What is this "hour < 25" about? Aren't we talking about the UTC offset
> value that come after the [-+] sign?
>
> I do not mind adding a new check, but I do mind if it adds a check with
> not much value. Even at Pacific/Kiritimati, the offset is 14; the new
> check seems a bit too lenient.
>
I think it's not "too" lenient. UTC+14 was "invented" in 1995 [1].
Maybe UTC+15 would be added someday for some reason? How about
changing to "hour < 24", this is how ICU checks offset validity [2].
1. http://en.wikipedia.org/wiki/UTC%2B14#History
2. http://bugs.icu-project.org/trac/browser/icu/tags/release-4-8-1/source/i18n/timezone.cpp#L1482
^ permalink raw reply
* Re: [PATCH v3 1/1] sha1_file: normalize alt_odb path before comparing and storing
From: wanghui @ 2011-09-08 2:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tali
In-Reply-To: <7vk49k2nsz.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Wang Hui <Hui.Wang@windriver.com> writes:
>
>
>> From: Hui Wang <Hui.Wang@windriver.com>
>>
>> When it needs to compare and add an alt object path to the
>> alt_odb_list, we normalize this path first since comparing normalized
>> path is easy to get correct result.
>>
>> Use strbuf to replace some string operations, since it is cleaner and
>> safer.
>>
>
> Thanks, will queue.
>
>
>> diff --git a/sha1_file.c b/sha1_file.c
>> index f7c3408..fa2484b 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -248,27 +248,27 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
>> ...
>> + /* Drop the last '/' from path can make memcmp more accurate */
>> + if (pathbuf.buf[pfxlen-1] == '/')
>> + pfxlen -= 1;
>>
>
> By the way, I do not necessarily agree with the above comment. As long as
> you consistently strip the trailing slashes from all directory paths, or
> you consistently leave a single trailing slash after all directory paths,
> you can get accurate comparison either way.
>
> Side note: I tend to prefer keeping a single trailing slash when I
> know what we are talking about is a directory in general, because
> you do not have to worry about the corner case near the root.
> Compare ('/' and '/bin/') vs ('/' and '/bin').
>
> In this particular case, the real reason you want to remove the trailing
> slash is that the invariants of ent->base[] demands it (after all, it
> places another slash immediately after it), and making pathbuf.buf[] an
> empty string (i.e. pfxlen == 0) would still be OK to represent an
> alternate object store at the root level (this function assigns '/' at
> ent->base[pfxlen] immediately before returning, and that '/' names the
> root directory).
>
>
Yes, your concern is right, I didn't even think about root directory
situation. If the pathbuf.buf is really '/', stripping last slash will
make pathbuf.buf a empty string, this will make is_directory() return
false, this is a bug, how about replace those three line codes to:
/* Except root dir, all paths are stripped the last slash if they have */
if (pathbuf.buf[pfxlen-1] == '/' && pxflen != 1)
pxflen -= 1;
>> + entlen = pfxlen + 43; /* '/' + 2 hex + '/' + 38 hex + NUL */
>> + ent = xmalloc(sizeof(*ent) + entlen);
>> + memcpy(ent->base, pathbuf.buf, pfxlen);
>> + strbuf_release(&pathbuf);
>>
>> ent->name = ent->base + pfxlen + 1;
>> ent->base[pfxlen + 3] = '/';
>>
>
>
^ permalink raw reply
* Re: [PATCHv2 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Martin von Zweigbergk @ 2011-09-08 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, git, Jeff King
In-Reply-To: <7vaaah6zx0.fsf@alter.siamese.dyndns.org>
On Tue, 6 Sep 2011, Junio C Hamano wrote:
> It is somewhat bothering that we do not say "we didn't do any magic" here
> when we did not move the tracking branch specifications, but that is not a
> new problem, so I am OK with this change.
If I understand you correctly, this is the same concern that Jeff had
and that I tried to address in patch 3/2.
> I however suspect that you would want to keep the record of what you
> changed here, so that the renaming of actual refs done in [PATCH 2/2] is
> limited to those that you updated the specifications for, no?
Sorry, I don't think I really understand. Are you worried that we
might rename too many refs, i.e. unrelated ones? We match exactly the
same pattern both when updating refspecs and when renaming refs. Of
course, we can never be certain that a ref "refs/remotes/origin/foo"
is really related to the remote called "origin". The user could have
simply created the ref manually. Is that what you are getting at?
Martin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox