* [PATCH v2 5/7] push -s: receiving end
From: Junio C Hamano @ 2011-09-08 20:01 UTC (permalink / raw)
To: git
In-Reply-To: <1315512102-19022-1-git-send-email-gitster@pobox.com>
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>
---
builtin/receive-pack.c | 72 +++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 65 insertions(+), 7 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 20b6799..344660e 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>";
@@ -581,6 +586,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)
{
/*
@@ -592,18 +613,55 @@ 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-receive-signature" hook.
- *
- * Here we just throw it to stderr to demonstrate that the
- * codepath is being exercised.
*/
+ 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;
+
+ if (!cert)
+ return 0;
+
+ 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;
+
+ 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)
@@ -623,7 +681,7 @@ static void execute_commands(struct command *commands, const char *unpacker_erro
return;
}
- if (push_certificate && record_signed_push(push_certificate)) {
+ if (record_signed_push(push_certificate)) {
for (cmd = commands; cmd; cmd = cmd->next)
cmd->error_string = "n/a (push signature error)";
return;
--
1.7.7.rc0.188.g3793ac
^ permalink raw reply related
* Re: git rebase fails with: Patch does not have a valid e-mail address.
From: Junio C Hamano @ 2011-09-08 21:21 UTC (permalink / raw)
To: James Blackburn; +Cc: git
In-Reply-To: <CACyv8dc28sRWsObYi3vbFNakj=R-2Q9eAoJdFfqNxsqq2+_aPg@mail.gmail.com>
James Blackburn <jamesblackburn@gmail.com> writes:
>> Perhaps you used "filter-branch" for conversion and your "doesn't
>> ordinarily complain about this" refers to it? If so, I have to say that it
>> is filter-branch that needs to be fixed to error out.
>
> I use cvs2git for the conversion (which produces a fast-import
> stream). That tool doesn't enforce an email address, and it's only
> when I try to rebase that I run into this problem... AFAICS there's
> nothing fundamentally wrong with what I'm trying to do, so forcing me
> to re-write the author seems to be the wrong answer, no?
Sorry, I do not follow. Nobody is forcing you to rewrite the author, but
earlier didn't you say _you_ rewrote the author into that invalid empty
string yourself, no?
^ permalink raw reply
* Re: [PATCH 2/2] push -s: skeleton
From: Junio C Hamano @ 2011-09-08 22:19 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20110908210217.GA32522@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yeah, it is a potential problem, but it just seems wrong to put too much
> policy work onto the server.
My take on it is somewhat different. The only thing in the end result we
want to see is that the pushed commits are annotated with GPG signatures
in the notes tree, and there is no reason for us to cast in stone that
there has to be any significance in the commit history of the notes tree.
In a busy hosting site that has many branches being pushed simultaneously,
it is entirely plausible that the server side may just want to store each
received push certificate in a new flat file in a filesystem, and have
asynchronous process sweep the new certificates to update the notes tree,
possibly creating a single notes tree commit that records updates by
multiple pushes, for performance purposes, in its implementation of
record_signed_push() in receive-pack.
If you forced the clients to also prepare notes and push the notes tree to
the server, you are forcing the ordering in the history of the notes, and
closing the door for such a server implementation. I would consider it an
unnecessary and/or premature policy decision.
^ permalink raw reply
* [PATCH v2 1/7] send-pack: typofix error message
From: Junio C Hamano @ 2011-09-08 20:01 UTC (permalink / raw)
To: git
In-Reply-To: <1315512102-19022-1-git-send-email-gitster@pobox.com>
The message identifies the process as receive-pack when it cannot fork the
sideband demultiplexer. We are actually a send-pack.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/send-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index c1f6ddd..87833f4 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -334,7 +334,7 @@ int send_pack(struct send_pack_args *args,
demux.data = fd;
demux.out = -1;
if (start_async(&demux))
- die("receive-pack: unable to fork off sideband demultiplexer");
+ die("send-pack: unable to fork off sideband demultiplexer");
in = demux.out;
}
--
1.7.7.rc0.188.g3793ac
^ permalink raw reply related
* Re: [PATCH v4] gitk: Allow commit editing
From: Paul Mackerras @ 2011-09-08 20:59 UTC (permalink / raw)
To: Michal Sojka; +Cc: Jeff King, git
In-Reply-To: <87fwknaveh.fsf@steelpick.2x.cz>
On Sat, Aug 27, 2011 at 02:31:02PM +0200, Michal Sojka wrote:
> Here is a new version with the micro-optimization.
>
> Another minor change is that this patch now applies to gitk repo
> (http://git.kernel.org/pub/scm/gitk/gitk.git) instead of the main git
> repo.
>
> -Michal
>
> --8<---------------cut here---------------start------------->8---
> I often use gitk to review patches before pushing them out and I would
> like to have an easy way to edit commits. The current approach with
> copying the commitid, switching to terminal, invoking git rebase -i,
> editing the commit and switching back to gitk is a way too complicated
> just for changing a single letter in the commit message or removing a
> debug printf().
>
> This patch adds "Edit this commit" item to gitk's context menu which
> invokes interactive rebase in a non-interactive way :-). git gui is
> used to actually edit the commit.
>
> Besides editing the commit message, splitting of commits, as described
> in git-rebase(1), is also supported.
>
> The user is warned if the commit to be edited is contained in another
> ref besides the current branch and the stash (e.g. in a remote
> branch). Additionally, error box is displayed if the user attempts to
> edit a commit not contained in the current branch.
I have to say that this patch makes me pretty nervous. I can see the
attractiveness of the feature, but I don't like making gitk
unresponsive for a potentially long time, i.e. until git gui exits.
It may not be clear to users that the reason gitk isn't responding is
because some other git gui window is still running.
Also, if some subsequent commit no longer applies because of the
changes you make to a commit, it's going to abort the rebase
completely and thus lose the changes you made. That could be
annoying.
I usually do this by starting a new branch just before the commit I
want to change and then use a combination of the cherry-pick menu item
and git commit --amend. Maybe something to make that simpler for
users would be good, i.e. automate it a bit but still have it be a
step-by-step process if necessary. Part of the problem of course is
that neither gitk nor git gui are really designed to be an editing
environment. In fact you really want an edit/compile/test environment
so you don't introduce new bugs.
Paul.
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: John Szakmeister @ 2011-09-08 15:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Kyle Neath, git, Jeff King
In-Reply-To: <4E68C04F.9060804@drmicha.warpmail.net>
On Thu, Sep 8, 2011 at 9:17 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
[snip]
> It would be interesting to know what we can rely on in the user group
> you're thinking about (which I called ssh-challenged). Setting up ssh
> keys is too complicated. Can we require a working gpg setup? They do
> want to check sigs, don't they?
I don't think you can require a working gpg setup (at least for not
addressing the ssh-challenged group).
[snip]
> Or that in C, probably using Junio's gpg-lib. That would be secure and
> useful *if* we can rely on people having a convenient gpg setup
> (gpg-agent or such).
>
> So: What credential store/password wallet/etc. can we rely on for this
> group? Is gpg fair game?
I think there probably need to be providers for using Keychain under
the Mac, gnome-keyring and kwallet under Linux, and probably something
using the wincrypt API under Windows. I don't think there's a
one-store-fits-all solution here, unfortunately. :-(
I'm actually tempted try and work on a couple of those myself.
-John
^ permalink raw reply
* Git Bug - diff in commit message.
From: anikey @ 2011-09-08 14:49 UTC (permalink / raw)
To: git
Hi, peops. I'm pretty much sure that's a bug.
What I did was putting git diff (i needed to tell people that for my changes
to start working they needed to aplly message-inline patch to some code
which was not under git) in commit message. Like adding:
diff --git a/app/controllers/settings_controller.rb
b/app/controllers/settings_controller.rb
index 937da74..0e8440d 100644
--- a/app/controllers/settings_controller.rb
+++ b/app/controllers/settings_controller.rb
@@ -42,7 +42,7 @@ class SettingsController < ApplicationController
end
def snmp_mibs
- render layout: 'ext3'
+ render layout: 'ext3_2'
end
def cfg_auth_keys(auth_type=:all)
though the commit itself didn't contain that change. So while `git rebase
some_branch_name` I started getting:
First, rewinding head to replay your work on top of it...
Applying: My cool patch.
fatal: sha1 information is lacking or useless
(app/controllers/settings_controller.rb).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 My cool patch.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
I wasn't able to figure out what was wrong for a very long time, when things
came to my mind.
Thanks.
--
View this message in context: http://git.661346.n2.nabble.com/Git-Bug-diff-in-commit-message-tp6772145p6772145.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply related
* Re: Add interactive patch menu help scrolled away if hunk is long
From: Sverre Rabbelier @ 2011-09-08 14:43 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20110907T143944-529@post.gmane.org>
Heya,
On Wed, Sep 7, 2011 at 14:43, Sergio Callegari
<sergio.callegari@gmail.com> wrote:
> Probably it would be better not to reprint the hunk when '?' is selected.
Seconded! I was trying to explain git add -i to someone and typed '?'
three times in a row wondering why it wasn't working.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCHv4 5/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-09-08 14:25 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <cover.1315491900.git.git@drmicha.warpmail.net>
Allow pattern arguments for the list mode just like for git tag -l.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 8 ++++++--
builtin/branch.c | 24 +++++++++++++++++++++---
t/t3203-branch-output.sh | 23 +++++++++++++++++++++++
3 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 26024b6..2e27ee4 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
[--list] [-v [--abbrev=<length> | --no-abbrev]]
- [(--merged | --no-merged | --contains) [<commit>]]
+ [(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
@@ -22,6 +22,9 @@ With no arguments, existing branches are listed and the current branch will
be highlighted with an asterisk. Option `-r` causes the remote-tracking
branches to be listed, and option `-a` shows both. This list mode is also
activated by the `--list` option (see below).
+<pattern> restricts the output to matching branches, the pattern is a shell
+wildcard (i.e., matched using fnmatch(3)).
+Multiple patterns may be given; if any of them matches, the tag is shown.
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
@@ -112,7 +115,8 @@ OPTIONS
List both remote-tracking branches and local branches.
--list::
- Activate the list mode.
+ Activate the list mode. `git branch <pattern>` would try to create a branch,
+ use `git branch --list <pattern>` to list matching branches.
-v::
--verbose::
diff --git a/builtin/branch.c b/builtin/branch.c
index b17ad26..099c75c 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -260,9 +260,22 @@ static char *resolve_symref(const char *src, const char *prefix)
struct append_ref_cb {
struct ref_list *ref_list;
+ const char **pattern;
int ret;
};
+static int match_patterns(const char **pattern, const char *refname)
+{
+ if (!*pattern)
+ return 1; /* no pattern always matches */
+ while (*pattern) {
+ if (!fnmatch(*pattern, refname, 0))
+ return 1;
+ pattern++;
+ }
+ return 0;
+}
+
static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
struct append_ref_cb *cb = (struct append_ref_cb *)(cb_data);
@@ -297,6 +310,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
+ if (!match_patterns(cb->pattern, refname))
+ return 0;
+
commit = NULL;
if (ref_list->verbose || ref_list->with_commit || merge_filter != NO_FILTER) {
commit = lookup_commit_reference_gently(sha1, 1);
@@ -492,7 +508,7 @@ static void show_detached(struct ref_list *ref_list)
}
}
-static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
+static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit, const char **pattern)
{
int i;
struct append_ref_cb cb;
@@ -506,6 +522,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
if (merge_filter != NO_FILTER)
init_revisions(&ref_list.revs, NULL);
cb.ref_list = &ref_list;
+ cb.pattern = pattern;
cb.ret = 0;
for_each_rawref(append_ref, &cb);
if (merge_filter != NO_FILTER) {
@@ -523,7 +540,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
detached = (detached && (kinds & REF_LOCAL_BRANCH));
- if (detached)
+ if (detached && match_patterns(pattern, "HEAD"))
show_detached(&ref_list);
for (i = 0; i < ref_list.index; i++) {
@@ -707,7 +724,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
else if (list)
- return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
+ return print_ref_list(kinds, detached, verbose, abbrev,
+ with_commit, argv);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
else if (rename && (argc == 2))
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 97d10b1..76fe7e0 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -38,6 +38,15 @@ test_expect_success 'git branch --list shows local branches' '
'
cat >expect <<'EOF'
+ branch-one
+ branch-two
+EOF
+test_expect_success 'git branch --list pattern shows matching local branches' '
+ git branch --list branch* >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
origin/HEAD -> origin/branch-one
origin/branch-one
origin/branch-two
@@ -72,6 +81,20 @@ test_expect_success 'git branch -v shows branch summaries' '
'
cat >expect <<'EOF'
+two
+one
+EOF
+test_expect_success 'git branch --list -v pattern shows branch summaries' '
+ git branch --list -v branch* >tmp &&
+ awk "{print \$NF}" <tmp >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'git branch -v pattern does not show branch summaries' '
+ test_must_fail git branch -v branch*
+'
+
+cat >expect <<'EOF'
* (no branch)
branch-one
branch-two
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply related
* [PATCHv4 4/5] branch: introduce --list option
From: Michael J Gruber @ 2011-09-08 14:25 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <cover.1315491900.git.git@drmicha.warpmail.net>
Currently, there is no way to invoke the list mode explicitly.
Introduce a --list option which invokes the list mode. This will be
beneficial for invoking list mode with pattern matching, which otherwise
would be interpreted as branch creation.
Along with --list, test also combinations of existing options.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 11 ++++++++---
builtin/branch.c | 11 ++++++++---
t/t3200-branch.sh | 32 ++++++++++++++++++++++++++++++++
t/t3203-branch-output.sh | 5 +++++
4 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4c64ac9..26024b6 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
- [-v [--abbrev=<length> | --no-abbrev]]
+ [--list] [-v [--abbrev=<length> | --no-abbrev]]
[(--merged | --no-merged | --contains) [<commit>]]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
@@ -20,7 +20,8 @@ DESCRIPTION
With no arguments, existing branches are listed and the current branch will
be highlighted with an asterisk. Option `-r` causes the remote-tracking
-branches to be listed, and option `-a` shows both.
+branches to be listed, and option `-a` shows both. This list mode is also
+activated by the `--list` option (see below).
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
@@ -110,9 +111,13 @@ OPTIONS
--all::
List both remote-tracking branches and local branches.
+--list::
+ Activate the list mode.
+
-v::
--verbose::
- Show sha1 and commit subject line for each head, along with
+ When in list mode,
+ show sha1 and commit subject line for each head, along with
relationship to upstream branch (if any). If given twice, print
the name of the upstream branch, as well.
diff --git a/builtin/branch.c b/builtin/branch.c
index bd3a315..b17ad26 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -612,7 +612,7 @@ static int opt_parse_merge_filter(const struct option *opt, const char *arg, int
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, rename = 0, force_create = 0;
+ int delete = 0, rename = 0, force_create = 0, list = 0;
int verbose = 0, abbrev = -1, detached = 0;
int reflog = 0;
enum branch_track track;
@@ -651,6 +651,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('D', NULL, &delete, "delete branch (even if not merged)", 2),
OPT_BIT('m', "move", &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
+ OPT_BOOLEAN(0, "list", &list, "list branch names"),
OPT_BOOLEAN('l', "create-reflog", &reflog, "create the branch's reflog"),
OPT__FORCE(&force_create, "force creation (when already exists)"),
{
@@ -693,7 +694,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, builtin_branch_usage,
0);
- if (!!delete + !!rename + !!force_create > 1)
+
+ if (!delete && !rename && !force_create && argc == 0)
+ list = 1;
+
+ if (!!delete + !!rename + !!force_create + !!list > 1)
usage_with_options(builtin_branch_usage, options);
if (abbrev == -1)
@@ -701,7 +706,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
- else if (argc == 0)
+ else if (list)
return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 9e69c8c..c466b20 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -98,6 +98,38 @@ test_expect_success 'git branch -m q r/q should fail when r exists' '
test_must_fail git branch -m q r/q
'
+test_expect_success 'git branch -v -d t should work' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ git branch -v -d t &&
+ test ! -f .git/refs/heads/t
+'
+
+test_expect_success 'git branch -v -m t s should work' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ git branch -v -m t s &&
+ test ! -f .git/refs/heads/t &&
+ test -f .git/refs/heads/s &&
+ git branch -d s
+'
+
+test_expect_success 'git branch -m -d t s should fail' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ test_must_fail git branch -m -d t s &&
+ git branch -d t &&
+ test ! -f .git/refs/heads/t
+'
+
+test_expect_success 'git branch --list -d t should fail' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ test_must_fail git branch --list -d t &&
+ git branch -d t &&
+ test ! -f .git/refs/heads/t
+'
+
mv .git/config .git/config-saved
test_expect_success 'git branch -m q q2 without config should succeed' '
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 6b7c118..97d10b1 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -32,6 +32,11 @@ test_expect_success 'git branch shows local branches' '
test_cmp expect actual
'
+test_expect_success 'git branch --list shows local branches' '
+ git branch --list >actual &&
+ test_cmp expect actual
+'
+
cat >expect <<'EOF'
origin/HEAD -> origin/branch-one
origin/branch-one
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply related
* [PATCHv4 0/5] mg/branch-list amendment
From: Michael J Gruber @ 2011-09-08 14:25 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <4E6889DF.7030404@drmicha.warpmail.net>
So, this is what the top 2 commits in mg/branch-list should be replaced
with if we don't let "-v" activate list mode, so that we can have a verbose
option for branch creation later on, i.e.:
git branch -v foo is the verbose version of git branch
Michael J Gruber (2):
branch: introduce --list option
branch: allow pattern arguments
Documentation/git-branch.txt | 17 +++++++++++++----
builtin/branch.c | 35 +++++++++++++++++++++++++++++------
t/t3200-branch.sh | 32 ++++++++++++++++++++++++++++++++
t/t3203-branch-output.sh | 28 ++++++++++++++++++++++++++++
4 files changed, 102 insertions(+), 10 deletions(-)
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Georgi Chorbadzhiyski @ 2011-09-08 14:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Ramkumar Ramachandra, git
In-Reply-To: <4E68CA0C.5080702@unixsol.org>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
Around 09/08/2011 04:58 PM, Georgi Chorbadzhiyski scribbled:
> Around 09/08/2011 02:15 PM, Matthieu Moy scribbled:
>> [1] Actually, I think there's a problem with Georgi's patch. If I read
>> correctly, the sleep is inserted within the confirmation loop, which
>> means the user will have
>>
>> send this email? yes
>> sending email
>> sleeping 10 seconds
>> send this email? yes
>> sending email
>> sleeping 10 seconds
>> ...
>>
>> while it should be
>>
>> send this email? yes
>> ok, I'll send it later
>> send this email? yes
>> ok, I'll send it later
>> sending first email ...
>> sleeping 10 seconds
>> sending second email
>> done.
>>
>> (i.e. don't force the user to wait between confirmations, and don't wait
>> after the last email)
>
> In order for this to work, confirmation should be split from send_message()
> and from a quick look this not seem very easy. Might be easier to just
> disable the sleep if user was asked for confirmation. It'll be good to
> not sleep after last email, but main "foreach my $t (@files) {" loop should
> pass some hint to send_message().
The attached patch (apply on on top of the original) should implement the
idea.
--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
[-- Attachment #2: send-email-sleep-fix1.diff --]
[-- Type: text/plain, Size: 399 bytes --]
diff --git a/git-send-email.perl b/git-send-email.perl
index 7239fd4..d4559c9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1149,7 +1149,7 @@ X-Mailer: git-send-email $gitversion
}
}
- if (!$dry_run && $sleep) {
+ if (!$dry_run && $sleep && $message_num < scalar $#files && $confirm eq 'never') {
print "Sleeping: $sleep second(s).\n" if (!$quiet);
sleep($sleep);
};
^ permalink raw reply related
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Georgi Chorbadzhiyski @ 2011-09-08 13:58 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Ramkumar Ramachandra, git
In-Reply-To: <vpq39g7gua3.fsf@bauges.imag.fr>
Around 09/08/2011 02:15 PM, Matthieu Moy scribbled:
> [1] Actually, I think there's a problem with Georgi's patch. If I read
> correctly, the sleep is inserted within the confirmation loop, which
> means the user will have
>
> send this email? yes
> sending email
> sleeping 10 seconds
> send this email? yes
> sending email
> sleeping 10 seconds
> ...
>
> while it should be
>
> send this email? yes
> ok, I'll send it later
> send this email? yes
> ok, I'll send it later
> sending first email ...
> sleeping 10 seconds
> sending second email
> done.
>
> (i.e. don't force the user to wait between confirmations, and don't wait
> after the last email)
In order for this to work, confirmation should be split from send_message()
and from a quick look this not seem very easy. Might be easier to just
disable the sleep if user was asked for confirmation. It'll be good to
not sleep after last email, but main "foreach my $t (@files) {" loop should
pass some hint to send_message().
--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Michael J Gruber @ 2011-09-08 13:17 UTC (permalink / raw)
To: Kyle Neath; +Cc: git, Jeff King
In-Reply-To: <CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com>
Kyle Neath venit, vidit, dixit 07.09.2011 22:14:
> Junio C Hamano <gitster@pobox.com> wrote:
>> If this were a new, insignificant, and obscure feature in a piece of
>> software with mere 20k users, it may be OK to release a new version with
>> the feature in an uncooked shape.
>
> For the sake of my paycheck, I should certainly hope not! I'm not at all
> suggesting we merge what we have in. However, I do think this feature is
> important enough to delay the release. I trust in the judgement of the core
> members to know when something is ready for inclusion in master.
>
> Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> So, it's been a year or more that you've been aware of the importance of
>> this issue (from your/github's perspective), and we hear about it now,
>> at the end of the rc phase.
>
> I apologize if it sounds like that. I've been discussing this situation with
> many people (including Jeff King) for a very long time now, and it was my
> understanding that the credential caching was done and simply waiting for a
> new release. This is the first I've heard that it will not be included in
> 1.7.7, so I'm voicing my opinion now. Admittedly, late in the game - and I
> apologize for that.
OK, I've calmed down :)
> I'd be happy to help in any capacity I can. Unfortunately I'm no C hacker, and
> I've accepted that as a character flaw (it's something I'm working on). I'm
> afraid I can't be of much help with the actual code. What I can provide is an
> alternate viewpoint to the core team. A viewpoint of someone who's spent 3
> years trying to make git easier for newcomers.
It would be interesting to know what we can rely on in the user group
you're thinking about (which I called ssh-challenged). Setting up ssh
keys is too complicated. Can we require a working gpg setup? They do
want to check sigs, don't they?
What I have in mind is a very simple, but secure version of Jeff's
credential-store, respectively his example, somewhat like:
---%<---
STORAGE=$HOME/.credentials
for i in "$@"; do
case "$i" in
--unique=*)
unique=${i#--unique=} ;;
esac
done
key=$(git config get credential.gpgkey) # or error out
if ! test -e "$STORAGE/$unique"; then
mkdir -m 0700 "$STORAGE"
git credential-getpass "$@" | gpg -ear $key >"$STORAGE/$unique"
fi
gpg <"$STORAGE/$unique"
---%<---
Or that in C, probably using Junio's gpg-lib. That would be secure and
useful *if* we can rely on people having a convenient gpg setup
(gpg-agent or such).
So: What credential store/password wallet/etc. can we rely on for this
group? Is gpg fair game?
Michael
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Martin von Zweigbergk @ 2011-09-08 13:14 UTC (permalink / raw)
To: Francis Moreau; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <CAC9WiBjMUg3SUOP9AJw6qCKrGVLs6Qy_O2fQa_SHX30NkjAEdw@mail.gmail.com>
On Thu, 8 Sep 2011, Francis Moreau wrote:
> 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.
Patches that are in both sides of v2.6.39...foo will be filtered, but
as Junio said, what is in master is not considered. In your case,
since foo was created from the tag, there should of course be no
commits in foo..v2.6.39.
> I'm using "git rebase --onto A B C" because I want to simplify git's
> work.
What work? Calculating mege-base and patch-ids? But that's exactly
what you said you don't want to avoid, no?
> I know that any commits between A..B are already in A history
Did you mean "B..A" here?
> and I'm not interested in rebasing them anyways.
They wouldn't be rebased by running "git rebase A C" either... Maybe
I'm misunderstanding something.
> 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.
It could do that. I think that's what Junio meant by "justifiable--- I
dunno". In your case, though, it seems like "git rebase master foo"
would do exactly what you want.
Somewhat related, I think "git rebase --onto A B C" should NOT filter
out patches that also appear both sides of "B...C", because when
"--onto" is used, "B" is only used as a way to calculate the
merge-base. I think it would make more sense to filter out from
appears in both "B..C" what also appears in "C..A". This has been on
my todo list for way too long. Some day I'll send out a patch for it
and we'll see what others think.
Martin
^ permalink raw reply
* Re: Tracking database changes.
From: Victor Engmark @ 2011-09-08 12:12 UTC (permalink / raw)
To: Rodrigo Cortés; +Cc: git
In-Reply-To: <30328581.178675.1315346163453.JavaMail.trustmail@mail1.terreactive.ch>
On Tue, Sep 06, 2011 at 06:55:56PM -0300, Rodrigo Cortés wrote:
> Is there a way to use git to track database changes?
1. Export the data and/or data model with a tool like mysqldump.
2. Remove output which would clutter up your diffs without adding any
useful information. This could include things like date and time of the
export and user name of the exporter.
3. Commit and enjoy!
Optionally create a cron job to export and commit automatically during
off-peak hours.
Cheers,
Victor
--
terreActive AG
Kasinostrasse 30
CH-5001 Aarau
Tel: +41 62 834 00 55
Fax: +41 62 823 93 56
www.terreactive.ch
Wir sichern Ihren Erfolg - seit 15 Jahren
^ permalink raw reply
* Re: Tracking database changes.
From: Rodrigo Cortés @ 2011-09-08 12:16 UTC (permalink / raw)
To: Rodrigo Cortés, git
In-Reply-To: <20110908121225.GC32087@victor.terreactive.ch>
So... there is no "plugin" for git to do that work.
On Thu, Sep 8, 2011 at 9:12 AM, Victor Engmark
<victor.engmark@terreactive.ch> wrote:
> On Tue, Sep 06, 2011 at 06:55:56PM -0300, Rodrigo Cortés wrote:
>> Is there a way to use git to track database changes?
>
> 1. Export the data and/or data model with a tool like mysqldump.
> 2. Remove output which would clutter up your diffs without adding any
> useful information. This could include things like date and time of the
> export and user name of the exporter.
> 3. Commit and enjoy!
>
> Optionally create a cron job to export and commit automatically during
> off-peak hours.
>
> Cheers,
> Victor
>
> --
> terreActive AG
> Kasinostrasse 30
> CH-5001 Aarau
> Tel: +41 62 834 00 55
> Fax: +41 62 823 93 56
> www.terreactive.ch
>
> Wir sichern Ihren Erfolg - seit 15 Jahren
>
--
Rodrigo Cortés Carvajal
Ingeniería Eléctrica
Universidad Tecnológica de Chile
^ permalink raw reply
* git rebase fails with: Patch does not have a valid e-mail address.
From: James Blackburn @ 2011-09-08 11:47 UTC (permalink / raw)
To: git
Hi,
I'm trying to rewrite some history and git's telling me:
-bash:jamesb:lc-cam-025:33079> git rebase
7f58969b933745d4cb9bb128bbd3fa8d441cdb92
First, rewinding head to replay your work on top of it...
Patch does not have a valid e-mail address.
Now it's true there isn't an email address for the author - the author
no longer works for the company, and the email address was removed
during the conversion. Therefore the repo contains "Author <>".
Given git doesn't ordinarily complain about this, should this prevent
rebase from working?
Cheers,
James
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Matthieu Moy @ 2011-09-08 11:15 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Georgi Chorbadzhiyski, git
In-Reply-To: <CALkWK0mNBG8EwysjO8uoR+fU5ZM=Pz9es3t_+s6cFgR6NSodGQ@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Hi,
>
> I mocked up a small patch to demonstrate the "special cover letter
> handling" idea. Let me know if you think it's worth pursuing.
If it was really a problem to have to wait a few seconds/minutes more,
I'd consider it as an interesting compromise (allow [PATCH 1/2] to come
after [PATCH 2/2] but make sure they both come after the coverletter to
make sure the recipient notice they're part of the same thread).
But quite frankly, I don't think it's worth the trouble.
As you said, the normal workflow is to use "git send-email", and go back
to work after, so you can do something else while the emails are being
sent (see below [1]). I don't think bothering users with --sleep and
--initial-wait is worth the benefit of having both possibilities. People
worried about email order should be fine with --sleep.
[1] Actually, I think there's a problem with Georgi's patch. If I read
correctly, the sleep is inserted within the confirmation loop, which
means the user will have
send this email? yes
sending email
sleeping 10 seconds
send this email? yes
sending email
sleeping 10 seconds
...
while it should be
send this email? yes
ok, I'll send it later
send this email? yes
ok, I'll send it later
sending first email ...
sleeping 10 seconds
sending second email
done.
(i.e. don't force the user to wait between confirmations, and don't wait
after the last email)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Georgi Chorbadzhiyski @ 2011-09-08 10:57 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Matthieu Moy, git
In-Reply-To: <CALkWK0mNBG8EwysjO8uoR+fU5ZM=Pz9es3t_+s6cFgR6NSodGQ@mail.gmail.com>
Around 09/08/2011 01:44 PM, Ramkumar Ramachandra scribbled:
> I mocked up a small patch to demonstrate the "special cover letter
> handling" idea. Let me know if you think it's worth pursuing.
> Warning: Untested.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
>
> -- 8< --
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 98ab33a..30b8651 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -80,6 +80,7 @@ git send-email [options] <file | directory |
> rev-list options >
> --[no-]suppress-from * Send to self. Default off.
> --[no-]chain-reply-to * Chain In-Reply-To: fields. Default off.
> --[no-]thread * Use In-Reply-To: field. Default on.
> + --[no-]initial-wait <int> * Wait <int> seconds after sending
> first email.
>
> Administering:
> --confirm <str> * Confirm recipients before sending;
> @@ -190,7 +191,7 @@ sub do_edit {
> }
>
> # Variables with corresponding config settings
> -my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
> +my ($thread, $initial_wait, $chain_reply_to, $suppress_from,
> $signed_off_by_cc);
> my ($to_cmd, $cc_cmd);
> my ($smtp_server, $smtp_server_port, @smtp_server_options);
> my ($smtp_authuser, $smtp_encryption);
> @@ -205,6 +206,7 @@ my $not_set_by_user = "true but not set by the user";
>
> my %config_bool_settings = (
> "thread" => [\$thread, 1],
> + "initialwait" => [\$initial_wait, 0],
> "chainreplyto" => [\$chain_reply_to, $not_set_by_user],
> "suppressfrom" => [\$suppress_from, undef],
> "signedoffbycc" => [\$signed_off_by_cc, undef],
> @@ -1141,6 +1143,11 @@ X-Mailer: git-send-email $gitversion
> } else {
> print "Result: OK\n";
> }
> + if ($initial_wait) {
> + print "Sleeping: $initial_wait seconds.\n" if (!$quiet);
> + sleep($initial_wait);
> + $initial_wait = 0;
> + }
> }
>
> return 1;
I don't see how this would solve the problem that MTA can send
emails after the first one out of order.
--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Ramkumar Ramachandra @ 2011-09-08 10:44 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Georgi Chorbadzhiyski, git
In-Reply-To: <CALkWK0nt4PXfBxGcAnavUkKM6AhKpZnw1NtZsNznzmGZiguFqA@mail.gmail.com>
Hi,
I mocked up a small patch to demonstrate the "special cover letter
handling" idea. Let me know if you think it's worth pursuing.
Warning: Untested.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
-- 8< --
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..30b8651 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -80,6 +80,7 @@ git send-email [options] <file | directory |
rev-list options >
--[no-]suppress-from * Send to self. Default off.
--[no-]chain-reply-to * Chain In-Reply-To: fields. Default off.
--[no-]thread * Use In-Reply-To: field. Default on.
+ --[no-]initial-wait <int> * Wait <int> seconds after sending
first email.
Administering:
--confirm <str> * Confirm recipients before sending;
@@ -190,7 +191,7 @@ sub do_edit {
}
# Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
+my ($thread, $initial_wait, $chain_reply_to, $suppress_from,
$signed_off_by_cc);
my ($to_cmd, $cc_cmd);
my ($smtp_server, $smtp_server_port, @smtp_server_options);
my ($smtp_authuser, $smtp_encryption);
@@ -205,6 +206,7 @@ my $not_set_by_user = "true but not set by the user";
my %config_bool_settings = (
"thread" => [\$thread, 1],
+ "initialwait" => [\$initial_wait, 0],
"chainreplyto" => [\$chain_reply_to, $not_set_by_user],
"suppressfrom" => [\$suppress_from, undef],
"signedoffbycc" => [\$signed_off_by_cc, undef],
@@ -1141,6 +1143,11 @@ X-Mailer: git-send-email $gitversion
} else {
print "Result: OK\n";
}
+ if ($initial_wait) {
+ print "Sleeping: $initial_wait seconds.\n" if (!$quiet);
+ sleep($initial_wait);
+ $initial_wait = 0;
+ }
}
return 1;
^ permalink raw reply related
* Re: How to specify a default <start-point> for git branch
From: Thomas Rast @ 2011-09-08 10:11 UTC (permalink / raw)
To: Lay, Stefan
Cc: git@vger.kernel.org, jgit-dev@eclipse.org,
manuel.doniger@googlemail.com
In-Reply-To: <D3AA6127B29A3048B2939A08CC561AF55EDD6CDD0E@DEWDFECCR01.wdf.sap.corp>
Lay, Stefan wrote:
> Is it possible in git to configure a default <start-point> for the git-branch command?
Literally as you propose it's probably not going to happen. It would
break every script ever written that uses "git branch <foo>" to start
a new branch at the current commit.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] send-mail: Add option to sleep between sending each email.
From: Ramkumar Ramachandra @ 2011-09-08 9:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Georgi Chorbadzhiyski, git
In-Reply-To: <CALkWK0nuLHpG9xqAAVL4T21N-31m7=A3_amp7Mf0Sw9jobYDRg@mail.gmail.com>
Hi again,
Ramkumar Ramachandra writes:
> [...]
> 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.
Another small thought- it'll probably be a good idea to teach
interfaces like Gmane and your email client some special rules: If the
X-Mailer is git-send-email or if the subject field matches [.*PATCH
(\d+)/\d+], sort the email thread by \1. Thoughts?
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 5/2] push -s: receiving end
From: Johan Herland @ 2011-09-08 9:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7v7h5jzj8o.fsf_-_@alter.siamese.dyndns.org>
On Thursday 8. September 2011, Junio C Hamano wrote:
> 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>
> ---
(...)
> 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
> @@ -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);
> +}
> +
What about adding this function to notes.h as a convenience to other
users of the notes API?
Otherwise the code looks good to me.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* 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
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