* Is it possible to "graft" a series of commits into/onto an existing repository?
From: Patrick Doyle @ 2007-06-27 13:25 UTC (permalink / raw)
To: git
I have an empty directory, managed by git and I want to graft another
(git) repository onto it, such that that history is maintained. Is
this possible?
--wpd
^ permalink raw reply
* Re: [PATCH] git-log: detect dup and fdopen failure
From: Alex Riesen @ 2007-06-27 13:18 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87r6nxo8iq.fsf_-_@rho.meyering.net>
On 6/27/07, Jim Meyering <jim@meyering.net> wrote:
> I didn't see that fdopen could fail with ENOMEM.
> That'll teach me to trust the man page. I see POSIX does mention it.
I wouldn't trust Linux man pages nor POSIX, if I were you.
Check if this works in some exotic but common
environments (like MacOSX, Cygwin or HP-UX).
(And yes, they probably are broken, and no, you can't fix them,
and no, people are not going to stop using them).
> + if (!use_stdout) {
> + int fd = dup(1);
> + if (fd < 0 || (realstdout = fdopen(fd, "w")) == NULL)
> + die("failed to duplicate standard output: %s",
> + strerror(errno));
> + }
Kinda stuffed in here. What's wrong with plain
realstdout = fdopen(dup(1), "w");
if (!realstdout)
die("%s", strerror(errno));
(Yes, I do think that "duplicate standard output" is useless,
except for debugging. Exactly as strerror is, but that is shorter).
^ permalink raw reply
* Re: t9400-git-cvsserver-server failures
From: Brian Gernhardt @ 2007-06-27 13:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <3E98C380-541B-479F-9E8F-6BBE82EE2930@silverinsanity.com>
On Jun 26, 2007, at 11:07 PM, Brian Gernhardt wrote:
> I'm getting several failures in the git-cvsserver tests. I don't
> even know where to start with that code, so here's as detailed an
> error report as I can give.
>
> The first category appears to be that several of the tests use
> test_expect_failure, which expects the error codes to be less than
> 127 and the error it gets is 255 (-1).
>
> * FAIL 9: req_Root failure (strict-paths)
> cat request-anonymous | git-cvsserver --strict-paths
> pserver $WORKDIR >log 2>&1
> * FAIL 11: req_Root failure (w/o strict-paths)
> cat request-anonymous | git-cvsserver pserver $WORKDIR/
> gitcvs >log 2>&1
> * FAIL 13: req_Root failure (base-path)
> cat request-anonymous | git-cvsserver --strict-paths --base-
> path $WORKDIR pserver $SERVERDIR >log 2>&1
Running the tests again this morning after a fresh pull results in
only the above failures occurring. I looked through git-
cvsserver.perl and couldn't find any exit(-1) or similar. Anyone
have any idea where to start to fix these?
~~ Brian
^ permalink raw reply
* [PATCH] git-log: detect dup and fdopen failure
From: Jim Meyering @ 2007-06-27 13:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0706270548p6f694fd6x5f47cbefa16c08ac@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> wrote:
> On 6/27/07, Jim Meyering <jim@meyering.net> wrote:
>> Without this, if you ever run out of file descriptors, dup will
>> fail (silently), fdopen will return NULL, and fprintf will
>> try to dereference NULL (i.e., usually segfault).
>
> But if you check the result of fdopen for NULL instead
> you'll cover the dup failure _and_ out-of-memory in one
> go. You'll loose the errno (probably), but you don't seem
> to use it here anyway.
Good catch. Thanks!
I didn't see that fdopen could fail with ENOMEM.
That'll teach me to trust the man page. I see POSIX does mention it.
Here's a better patch:
Signed-off-by: Jim Meyering <jim@meyering.net>
---
builtin-log.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 073a2a1..7b0d6f4 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -588,8 +588,12 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (ignore_if_in_upstream)
get_patch_ids(&rev, &ids, prefix);
- if (!use_stdout)
- realstdout = fdopen(dup(1), "w");
+ if (!use_stdout) {
+ int fd = dup(1);
+ if (fd < 0 || (realstdout = fdopen(fd, "w")) == NULL)
+ die("failed to duplicate standard output: %s",
+ strerror(errno));
+ }
prepare_revision_walk(&rev);
while ((commit = get_revision(&rev)) != NULL) {
^ permalink raw reply related
* Re: [PATCH] detect dup failure
From: Alex Riesen @ 2007-06-27 12:48 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87wsxpobf0.fsf@rho.meyering.net>
On 6/27/07, Jim Meyering <jim@meyering.net> wrote:
> Without this, if you ever run out of file descriptors, dup will
> fail (silently), fdopen will return NULL, and fprintf will
> try to dereference NULL (i.e., usually segfault).
But if you check the result of fdopen for NULL instead
you'll cover the dup failure _and_ out-of-memory in one
go. You'll loose the errno (probably), but you don't seem
to use it here anyway.
^ permalink raw reply
* [PATCH] Avoid perl in t1300-repo-config
From: Alex Riesen @ 2007-06-27 12:45 UTC (permalink / raw)
To: Git Mailing List; +Cc: Frank Lichtenheld, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 227 bytes --]
It fixes the test on system where ActiveState Perl is used.
It is also shorter.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t1300-repo-config.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
[-- Attachment #2: 0001-Avoid-perl-in-t1300-repo-config.txt --]
[-- Type: text/plain, Size: 1472 bytes --]
From e844edbdc63150386dc4eb2c2080ece4f371cd04 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 27 Jun 2007 14:40:41 +0200
Subject: [PATCH] Avoid perl in t1300-repo-config
It fixes the test on system where ActiveState Perl is used.
It is shorter as a bonus.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t1300-repo-config.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 7a77bef..60b0dc5 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -530,24 +530,24 @@ EOF
cat > expect <<\EOF
Key: section.sub=section.val1
-Value: foo=bar
+foo=bar
Key: section.sub=section.val2
-Value: foo
+foo
bar
Key: section.sub=section.val3
-Value:
+
Key: section.sub=section.val4
-Value:
+
Key: section.sub=section.val5
EOF
-git config --null --list | perl -0ne 'chop;($key,$value)=split(/\n/,$_,2);print "Key: $key\n";print "Value: $value\n" if defined($value)' > result
+git config --null --list | xargs -n1 -0 echo 'Key:' > result
test_expect_success '--null --list' 'cmp result expect'
-git config --null --get-regexp 'val[0-9]' | perl -0ne 'chop;($key,$value)=split(/\n/,$_,2);print "Key: $key\n";print "Value: $value\n" if defined($value)' > result
+git config --null --get-regexp 'val[0-9]' | xargs -n1 -0 echo 'Key:' > result
test_expect_success '--null --get-regexp' 'cmp result expect'
--
1.5.2.2.1308.g540b6
^ permalink raw reply related
* Re: post-update script to update wc - version 2
From: Alex Riesen @ 2007-06-27 12:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, Sam Vilain, git
In-Reply-To: <7vved9pv2h.fsf@assigned-by-dhcp.pobox.com>
On 6/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
> > On 6/27/07, Sam Vilain <sam@vilain.net> wrote:
> >> Sam Vilain wrote:
> >> > this_tree=`git-cat-file commit $commit | awk '/^tree/ { print $2; exit }'`
> >>
> >> Of course on newer git, `git-rev-parse $commit:` will do that.
> >
> > Are you sure? Maybe you mean git-rev-parse "$commit"^{tree}?
>
> I had the same "Huh?" moment as you had, but what Sam said is
> correct. He is being too clever to confuse us ;-).
>
> When "$commit" is a tree-ish,
>
> $commit:$path
>
> is the name of the tree or blob object at that $path, and as
> very strange special case, an empty $path is the whole tree.
I didn't even see the colon. That's GMail, they obviously have
no idea what font should be used for the mail of a technical user.
^ permalink raw reply
* RE: [PATCH] git-submodule: Instead of using only annotated tags, use any tag found in .git/refs/tags
From: Medve Emilian-EMMEDVE1 @ 2007-06-27 12:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vabulrki3.fsf@assigned-by-dhcp.pobox.com>
Hello Junio,
You're right and there might be no tag at all, thus --contains might
return an undefined. In the spirit of best effort maybe we should try
--all (which I don't think that can fail and it will return something
more relevant then undefined, i.e. the branch of the commit) if
--contains returns undefined. I'll submit a patch to reflect this.
Opinions?
While playing with git-describe I noticed that the --all option is maybe
not trying first to find a tag as the man page suggests but it goes
directly for .git/refs. Here is some output from my git repo clone with
yesterday's head on the master branch:
$ git-describe aeb59328453cd4f438345ea79ff04c96bccbbbb8
v1.5.2.2-549-gaeb5932
$ git-describe --all aeb59328453cd4f438345ea79ff04c96bccbbbb8
heads/master
Do you think we want to fix that? If yes, I could look into it and
submit a patch.
Cheers,
Emil.
This e-mail, and any associated attachments have been classified as:
--------------------------------------------------------------------
[x] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Wednesday, June 27, 2007 1:15 AM
To: Medve Emilian-EMMEDVE1
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-submodule: Instead of using only annotated
tags, use any tag found in .git/refs/tags
Emil Medve <Emilian.Medve@Freescale.com> writes:
> Some repositories might not use/have annotated tags (for
> example repositories created with git-cvsimport) and
> git-submodule status might fail because git-describe might
> fail to find a tag. This change allows the status of a
> submodule to be described/displayed relative to lightweight
> tags as well.
Certainly that is an improvement, as $revname is purely for
commenting and not being able to describe it is not an excuse to
fail the command.
But there may not be any tag at all. How about something like
this on top?
diff --git a/git-submodule.sh b/git-submodule.sh
index 56ea935..7b6195b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -133,6 +133,18 @@ modules_update()
done
}
+set_name_rev () {
+ revname=$( (
+ unset GIT_DIR &&
+ cd "$1" && {
+ git-describe "$2" 2>/dev/null ||
+ git-describe --tags "$2" 2>/dev/null ||
+ git-describe --contains --tags "$2"
+ }
+ ) )
+ test -z "$revname" || revname=" ($revname)"
+}
+
#
# List all submodules, prefixed with:
# - submodule not initialized
@@ -156,16 +168,17 @@ modules_list()
continue;
fi
revname=$(unset GIT_DIR && cd "$path" && git-describe
--tags $sha1)
+ set_name_rev "$path" $"sha1"
if git diff-files --quiet -- "$path"
then
- say " $sha1 $path ($revname)"
+ say " $sha1 $path$revname"
else
if test -z "$cached"
then
sha1=$(unset GIT_DIR && cd "$path" &&
git-rev-parse --verify HEAD)
- revname=$(unset GIT_DIR && cd "$path" &&
git-describe --tags $sha1)
+ set_name_rev "$path" $"sha1"
fi
- say "+$sha1 $path ($revname)"
+ say "+$sha1 $path$revname"
fi
done
}
^ permalink raw reply related
* [PATCH] detect dup failure
From: Jim Meyering @ 2007-06-27 11:59 UTC (permalink / raw)
To: git
Without this, if you ever run out of file descriptors, dup will
fail (silently), fdopen will return NULL, and fprintf will
try to dereference NULL (i.e., usually segfault).
Signed-off-by: Jim Meyering <jim@meyering.net>
---
builtin-log.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 073a2a1..ca54387 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -588,8 +588,12 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (ignore_if_in_upstream)
get_patch_ids(&rev, &ids, prefix);
- if (!use_stdout)
- realstdout = fdopen(dup(1), "w");
+ if (!use_stdout) {
+ int fd = dup(1);
+ if (fd < 0)
+ die("failed to duplicate standard output");
+ realstdout = fdopen(fd, "w");
+ }
prepare_revision_walk(&rev);
while ((commit = get_revision(&rev)) != NULL) {
^ permalink raw reply related
* Re: post-update script to update wc - version 2
From: Johannes Schindelin @ 2007-06-27 10:36 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <E1I3MuE-0005eO-00@www.watts.utsl.gen.nz>
Hi,
On Wed, 27 Jun 2007, Sam Vilain wrote:
> # An example hook script to prepare a packed repository for use over
> # dumb transports.
???
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] rebase -i: several cleanups
From: Johannes Schindelin @ 2007-06-27 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodj2tazk.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Tue, 26 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > +die_abort () {
> >> > + rm -rf "$DOTEST" 2> /dev/null
> >> > + die "$1"
> >> > +}
> >>
> >> Why "2>/dev/null" here?
> >
> > Just to be sure. If it does not exist, it's no error. No sense alarming
> > the user.
>
> Yeah, but isn't that exactly why you have "-f" there? On the
> other hand, if $DOTEST exists but for some reason couldn't be
> removed, we probably would want to know about it.
>
> $ rm -fr no-such
> $ mkdir no-such
> $ echo >no-such/file
> $ rm -fr no-such
> $ mkdir no-such
> $ echo >no-such/file
> $ chmod a-w no-such
> $ rm -fr no-such
> rm: cannot remove `no-such/file': Permission denied
Good point.
Okay, let's leave the 2> /dev/null out.
Ciao,
Dscho
^ permalink raw reply
* Re: post-update script to update wc - version 2
From: Junio C Hamano @ 2007-06-27 10:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Sam Vilain, Sam Vilain, git
In-Reply-To: <81b0412b0706270221y40bac0a7gf6b73eda9f1e4bb0@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 6/27/07, Sam Vilain <sam@vilain.net> wrote:
>> Sam Vilain wrote:
>> > this_tree=`git-cat-file commit $commit | awk '/^tree/ { print $2; exit }'`
>>
>> Of course on newer git, `git-rev-parse $commit:` will do that.
>
> Are you sure? Maybe you mean git-rev-parse "$commit"^{tree}?
I had the same "Huh?" moment as you had, but what Sam said is
correct. He is being too clever to confuse us ;-).
When "$commit" is a tree-ish,
$commit:$path
is the name of the tree or blob object at that $path, and as
very strange special case, an empty $path is the whole tree.
It's been this way since early this year (before v1.5.0-rc1),
thanks to Jeff King.
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: しらいしななこ @ 2007-06-27 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT
In-Reply-To: <7vsl8euryx.fsf@assigned-by-dhcp.pobox.com>
Quoting Junio C Hamano <gitster@pobox.com>:
> I think it would make much more sense to represent a stash like
> this:
>
> .------o commit to represent index state
> / \
> ---o---o----------o
> HEAD commit to represent worktree state
>
> That is, "index" and "worktree" state are represented as one
> commit each, both are direct child of the HEAD, with an added
> twist of the latter being also a child of the former.
I do not know if I understand you correctly.
Do you mean that I should create a stash this way?
i_tree=$(git-write-tree)
i_commit=$(echo index | git-commit-tree $i_tree -p HEAD)
w_tree=$( what I did to create w_tree in my previous patch )
w_commit=$(echo $msg | git-commit-tree $w_tree -p HEAD -p $i_commit)
and when unstashing the stash, I should:
git-merge-recursive $stash^^{tree} -- $stash^^{tree} $stash^{tree}
I think I can make it work, but if that is not what you meant, please let me know.
> I am not absolutely sure if "git reset --hard" belongs here.
> > You can certainly type one less command in your example sequence
> > ("stash; pull; restore"). But I suspect there may be a case
> > that would be more useful if "git save" did not do the reset
> > itself. I dunno....
>
> I now think "git reset --hard" here is fine.
I see.
I will try to update and resend my patch this weekend.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com
^ permalink raw reply
* Re: post-update script to update wc - version 2
From: Alex Riesen @ 2007-06-27 9:21 UTC (permalink / raw)
To: Sam Vilain; +Cc: Sam Vilain, git
In-Reply-To: <4681C640.6060408@vilain.net>
On 6/27/07, Sam Vilain <sam@vilain.net> wrote:
> Sam Vilain wrote:
> > this_tree=`git-cat-file commit $commit | awk '/^tree/ { print $2; exit }'`
>
> Of course on newer git, `git-rev-parse $commit:` will do that.
>
Are you sure? Maybe you mean git-rev-parse "$commit"^{tree}?
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jim Meyering @ 2007-06-27 8:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706251505570.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, 25 Jun 2007, Jim Meyering wrote:
>> Remember: I'm trying to improve existing code here.
>> You should save some of your ire for the person who wrote that code.
>
> Ehh. Remind me who I should be pissed at when the old code was _better_
> before your change?
If someone pointed out a bug in coreutils whereby a tool failed
to give an accurate diagnostic, I would thank them (and honestly,
I'd be grateful), even if their attempt at fixing it introduced
a horrible bug. Of course, if the original bug were mine, I might
be annoyed with myself, but certainly would not shoot the messenger.
> With the current git.c, we report write errors quite well.
Yes, I'm glad (in spite of the tone of much of your feedback)
that my little improvements are making it into git.
> We don't give
> the exact output you want, but on a scale of 1-10, how important is that?
> Pretty damn low on the list.
If you get a report of a git write error, you might well
appreciate knowing right away whether it was due to EIO or to ENOSPC.
> And the reason I'm really really irritated at you is that you ignore me
> when I tell you what your bugs are.
Be careful when throwing stones...
I mentioned (without making a fuss) a regression you introduced,
http://thread.gmane.org/gmane.comp.version-control.git/50742/focus=50917
and you included similar code in a snippet in the very message to which
I'm replying now. I do see that you omitted the troublesome ferror call
from your eventual patch.
> - I *told* you that EPIPE is special. What did you do? Ignore my advice,
> and made a broken patch that did exactly the opposite of what I told
> you.
I did not ignore your advice. I considered it carefully and explained
why I hold the opposing view. We've already beaten this to death, but
for the record, I'd summarize it like this:
You and I have a difference of opinion. I firmly believe that it is
unnecessary and counterproductive (it is prohibited by POSIX for many
of the tools I maintain) to suppress an EPIPE diagnostic and to exit
successfully in spite of a write error. Since EPIPE doesn't even arise
in most normal situations, the only reason to do that is if you want
to pander to the needs of some theoretical, broken-by-design (i.e.,
SIGPIPE-ignoring) git Porcelain program. You want to add such code to
git, at every point where writing to stdout may fail.
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jim Meyering @ 2007-06-27 8:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706251557090.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
...
> So I didn't mean to imply that the new git.c code in 'next' is wrong, I
> just meant to imply that the "ferror()"+"fflush()" sequence that it uses
> and that I copied for my example is a very unreliable sequence, and it
> basically fails exactly because you can never know what caused the
> ferror() to trigger - if it *ever* triggers, you're basically screwed.
>
> I wonder how many applications actually ever use ferror() and friends.
At least among GNU programs, many do.
Here are a few:
gcc, make, diff, grep, tar, find, xargs, gawk
And add to that 89 or 90 of the coreutils programs:
$ git-grep -l close_stdout|grep 'src/.*\.c'|wc -l
89
But none of those suppress EPIPE errors, so ferror works fine for them.
That's partly because the ferror-only situation is far less common
than the one in which we have a valid errno value.
^ permalink raw reply
* Re: post-update script to update wc - version 2
From: Steven Grimm @ 2007-06-27 7:54 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <E1I3MuE-0005eO-00@www.watts.utsl.gen.nz>
Sam Vilain wrote:
> # An example hook script to prepare a packed repository for use over
> # dumb transports.
>
Maybe this comment isn't quite accurate any more?
-Steve
^ permalink raw reply
* [PATCH 2/2] git-send-email: Add --thread option
From: Adam Roben @ 2007-06-27 6:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Adam Roben
In-Reply-To: <1182927238504-git-send-email-aroben@apple.com>
The --thread option controls whether the In-Reply-To header will be set on
any emails sent. The current behavior is to always set this header, so this
option is most useful in its negated form, --no-thread. This behavior can
also be controlled through the 'sendemail.threaded' config setting.
Signed-off-by: Adam Roben <aroben@apple.com>
---
Apologies to Junio, Matthias, and Julian, who had to endure a spamming from me
in the development of this patch.
Documentation/git-send-email.txt | 7 +++++++
git-send-email.perl | 11 ++++++++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 01bbd18..293686c 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -90,6 +90,13 @@ The --cc option must be repeated for each user you want on the cc list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-supress-from.
+--thread, --no-thread::
+ If this is set, the In-Reply-To header will be set on each email sent.
+ If disabled with "--no-thread", no emails will have the In-Reply-To
+ header set.
+ Default is the value of the 'sendemail.thread' configuration value;
+ if that is unspecified, default to --thread.
+
--dry-run::
Do everything except actually send the emails.
diff --git a/git-send-email.perl b/git-send-email.perl
index 584eda9..28659f8 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -73,6 +73,9 @@ Options:
--suppress-from Suppress sending emails to yourself if your address
appears in a From: line. Defaults to off.
+ --thread Specify that the "In-Reply-To:" header should be set on all
+ emails. Defaults to on.
+
--quiet Make git-send-email less verbose. One line per email
should be all that is output.
@@ -154,9 +157,10 @@ if ($@) {
my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
-my ($chain_reply_to, $suppress_from, $signed_off_cc);
+my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc);
my %config_settings = (
+ "thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, 0],
"signedoffcc" => [\$signed_off_cc, 1],
@@ -189,6 +193,7 @@ my $rc = GetOptions("from=s" => \$from,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
+ "thread!" => \$thread,
);
unless ($rc) {
@@ -295,7 +300,7 @@ if (!defined $initial_subject && $compose) {
$prompting++;
}
-if (!defined $initial_reply_to && $prompting) {
+if ($thread && !defined $initial_reply_to && $prompting) {
do {
$_= $term->readline("Message-ID to be used as In-Reply-To for the first email? ",
$initial_reply_to);
@@ -492,7 +497,7 @@ Date: $date
Message-Id: $message_id
X-Mailer: git-send-email $gitversion
";
- if ($reply_to) {
+ if ($thread && $reply_to) {
$header .= "In-Reply-To: $reply_to\n";
$header .= "References: $references\n";
--
1.5.2.2.551.ga811
^ permalink raw reply related
* [PATCH 1/2] git-send-email: Add negations and config equivalents for --suppress-from and --no-signed-off-cc
From: Adam Roben @ 2007-06-27 6:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Adam Roben
This change makes git-send-email's behavior easier to modify by adding config
equivalents for two more of git-send-email's flags.
The mapping of flag to config setting is:
--[no-]supress-from => sendemail.suppressfrom
--[no-]signed-off-cc => sendemail.signedoffcc
Signed-off-by: Adam Roben <aroben@apple.com>
---
Thanks to Junio for the suggestion for how to clean up the default values.
Documentation/git-send-email.txt | 16 ++++++++++------
git-send-email.perl | 34 +++++++++++++++++++++-------------
2 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 946bd76..01bbd18 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -59,9 +59,11 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---no-signed-off-by-cc::
- Do not add emails found in Signed-off-by: or Cc: lines to the
- cc list.
+--signed-off-by-cc, --no-signed-off-by-cc::
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list.
+ Default is the value of 'sendemail.signedoffbycc' configuration value;
+ if that is unspecified, default to --signed-off-by-cc.
--quiet::
Make git-send-email less verbose. One line per email should be
@@ -82,9 +84,11 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---suppress-from::
- Do not add the From: address to the cc: list, if it shows up in a From:
- line.
+--suppress-from, --no-suppress-from::
+ If this is set, do not add the From: address to the cc: list, if it
+ shows up in a From: line.
+ Default is the value of 'sendemail.suppressfrom' configuration value;
+ if that is unspecified, default to --no-supress-from.
--dry-run::
Do everything except actually send the emails.
diff --git a/git-send-email.perl b/git-send-email.perl
index 9f75551..584eda9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -64,15 +64,14 @@ Options:
email sent, rather than to the first email sent.
Defaults to on.
- --no-signed-off-cc Suppress the automatic addition of email addresses
- that appear in Signed-off-by: or Cc: lines to the cc:
- list. Note: Using this option is not recommended.
+ --signed-off-cc Automatically add email addresses that appear in
+ Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
--suppress-from Suppress sending emails to yourself if your address
- appears in a From: line.
+ appears in a From: line. Defaults to off.
--quiet Make git-send-email less verbose. One line per email
should be all that is output.
@@ -137,9 +136,6 @@ my $compose_filename = ".msg.$$";
my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
-# Behavior modification variables
-my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
- $dry_run) = (1, 0, 0, 0, 0);
my $smtp_server;
my $envelope_sender;
@@ -154,9 +150,21 @@ if ($@) {
$term = new FakeTerm "$@: going non-interactive";
}
-my $def_chain = $repo->config_bool('sendemail.chainreplyto');
-if (defined $def_chain and not $def_chain) {
- $chain_reply_to = 0;
+# Behavior modification variables
+my ($quiet, $dry_run) = (0, 0);
+
+# Variables with corresponding config settings
+my ($chain_reply_to, $suppress_from, $signed_off_cc);
+
+my %config_settings = (
+ "chainreplyto" => [\$chain_reply_to, 1],
+ "suppressfrom" => [\$suppress_from, 0],
+ "signedoffcc" => [\$signed_off_cc, 1],
+);
+
+foreach my $setting (keys %config_settings) {
+ my $config = $repo->config_bool("sendemail.$setting");
+ ${$config_settings{$setting}->[0]} = (defined $config) ? $config : $config_settings{$setting}->[1];
}
@bcclist = $repo->config('sendemail.bcc');
@@ -177,8 +185,8 @@ my $rc = GetOptions("from=s" => \$from,
"smtp-server=s" => \$smtp_server,
"compose" => \$compose,
"quiet" => \$quiet,
- "suppress-from" => \$suppress_from,
- "no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
+ "suppress-from!" => \$suppress_from,
+ "signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
);
@@ -609,7 +617,7 @@ foreach my $t (@files) {
}
} else {
$message .= $_;
- if (/^(Signed-off-by|Cc): (.*)$/i && !$no_signed_off_cc) {
+ if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
my $c = $2;
chomp $c;
push @cc, $c;
--
1.5.2.2.551.ga811
^ permalink raw reply related
* git-svn problems with branches containing spaces
From: Ewald, Robert @ 2007-06-27 6:53 UTC (permalink / raw)
To: git
Hello,
As I have reported yesterday on IRC, git-svn has problems with branches
containing spaces.
I get the following message, when I want to clone from the repository
containing a branch with a space.
Cloning until the revision the branch is created everything works fine.
fatal: refs/remotes/Modbus Error Limit Fix: cannot lock the ref
update-ref -m r1897 refs/remotes/Modbus Error Limit Fix
ff0819c8e9c97c24e9865bc868c503fd9b64f980: command returned error: 128
Thanks for your help.
Best regards
Robert Ewald
PS. Please CC me, I am not subscribed.
^ permalink raw reply
* Re: [PATCH] git-submodule: Instead of using only annotated tags, use any tag found in .git/refs/tags
From: Junio C Hamano @ 2007-06-27 6:15 UTC (permalink / raw)
To: Emil Medve; +Cc: git
In-Reply-To: <11829012583562-git-send-email-Emilian.Medve@Freescale.com>
Emil Medve <Emilian.Medve@Freescale.com> writes:
> Some repositories might not use/have annotated tags (for
> example repositories created with git-cvsimport) and
> git-submodule status might fail because git-describe might
> fail to find a tag. This change allows the status of a
> submodule to be described/displayed relative to lightweight
> tags as well.
Certainly that is an improvement, as $revname is purely for
commenting and not being able to describe it is not an excuse to
fail the command.
But there may not be any tag at all. How about something like
this on top?
diff --git a/git-submodule.sh b/git-submodule.sh
index 56ea935..7b6195b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -133,6 +133,18 @@ modules_update()
done
}
+set_name_rev () {
+ revname=$( (
+ unset GIT_DIR &&
+ cd "$1" && {
+ git-describe "$2" 2>/dev/null ||
+ git-describe --tags "$2" 2>/dev/null ||
+ git-describe --contains --tags "$2"
+ }
+ ) )
+ test -z "$revname" || revname=" ($revname)"
+}
+
#
# List all submodules, prefixed with:
# - submodule not initialized
@@ -156,16 +168,17 @@ modules_list()
continue;
fi
revname=$(unset GIT_DIR && cd "$path" && git-describe --tags $sha1)
+ set_name_rev "$path" $"sha1"
if git diff-files --quiet -- "$path"
then
- say " $sha1 $path ($revname)"
+ say " $sha1 $path$revname"
else
if test -z "$cached"
then
sha1=$(unset GIT_DIR && cd "$path" && git-rev-parse --verify HEAD)
- revname=$(unset GIT_DIR && cd "$path" && git-describe --tags $sha1)
+ set_name_rev "$path" $"sha1"
fi
- say "+$sha1 $path ($revname)"
+ say "+$sha1 $path$revname"
fi
done
}
^ permalink raw reply related
* Re: [PATCH] git-send-email: Add --threaded option
From: Junio C Hamano @ 2007-06-27 6:03 UTC (permalink / raw)
To: Adam Roben; +Cc: git
In-Reply-To: <70B55529-9309-46D4-89A0-3FFD4D4E0660@apple.com>
Adam Roben <aroben@apple.com> writes:
> On Jun 26, 2007, at 10:21 PM, Junio C Hamano wrote:
> ...
>>> +my ($threaded, $chain_reply_to, $quiet, $suppress_from,
>>> $no_signed_off_cc,
>>> + $dry_run) = (1, 1, 0, 0, 0, 0);
>>
>> While we are at it, you might want to make everything other than
>> quiet and dry_run overridable the same way.
>
> --[no-]chain-reply-to, --suppress-from and --no-signed-off-cc
> already exist, so do you mean that we should support --no-suppress-
> from and --signed-off-cc (i.e., the negations) as well? Or that we
> should have equivalent config settings for these? Or both?
Sorry for being unclear; I was talking about the config.
Also "my ($a, $b, $c, ...) = ($defA, $defB, $defC, ...)" gets
extremely hard to read when the list grows longer. I was hoping
that when adding entries to %config_settings array, you would do
something like:
my %config_settings = (
threaded => [\threaded, 1],
chainreplyto => [\chain_reply_to, 1],
...
);
while (my ($var, $data) = each %config_settings) {
my $config = $repo_config_bool("sendemail.$var);
${$data->[0]} = (defined $config) ? $config : $data->[1];
}
^ permalink raw reply
* Re: [PATCH 1/2] Add test script for git-stripspace.
From: Carlos Rica @ 2007-06-27 5:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin, krh
In-Reply-To: <7v8xa6ruu4.fsf@assigned-by-dhcp.pobox.com>
2007/6/27, Junio C Hamano <gitster@pobox.com>:
> Thanks. That's extensive set of tests for a little utility.
I hope not being overtesting the program. In order to reuse the
function that does this job from the builtins, perhaps we need another
implementation doing the same in a memory buffer instead a file
stream. The tests save the need to feed manually the program in this
development, and clarify the expected behaviour for the utility.
> > new file mode 100644
> 100755?
> > + cat expect | git-stripspace >actual &&
> Please don't cat a single file into a pipeline.
> git-stripspace <actual >expect
Thank you for your corrections. I Will resend it with those fixed.
^ permalink raw reply
* Re: [PATCH] git-send-email: Add --threaded option
From: Adam Roben @ 2007-06-27 5:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvedaq8eg.fsf@assigned-by-dhcp.pobox.com>
On Jun 26, 2007, at 10:21 PM, Junio C Hamano wrote:
> Adam Roben <aroben@apple.com> writes:
>
>> @@ -138,8 +141,8 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
>> $initial_reply_to,$initial_subject,@files,$from,$compose,$time);
>>
>> # Behavior modification variables
>> -my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
>> - $dry_run) = (1, 0, 0, 0, 0);
>> +my ($threaded, $chain_reply_to, $quiet, $suppress_from,
>> $no_signed_off_cc,
>> + $dry_run) = (1, 1, 0, 0, 0, 0);
>
> While we are at it, you might want to make everything other than
> quiet and dry_run overridable the same way.
--[no-]chain-reply-to, --suppress-from and --no-signed-off-cc
already exist, so do you mean that we should support --no-suppress-
from and --signed-off-cc (i.e., the negations) as well? Or that we
should have equivalent config settings for these? Or both?
I also realized after sending this that git-format-patch has a --
[no-]thread option, so I think I'll change the name of this option to
match.
-Adam
^ permalink raw reply
* Re: [PATCH] git-send-email: Add --threaded option
From: Junio C Hamano @ 2007-06-27 5:21 UTC (permalink / raw)
To: Adam Roben; +Cc: git
In-Reply-To: <11828981103069-git-send-email-aroben@apple.com>
Adam Roben <aroben@apple.com> writes:
> The --threaded option controls whether the In-Reply-To header will be set on
> any emails sent. The current behavior is to always set this header, so this
> option is most useful in its negated form, --no-threaded. This behavior can
> also be controlled through the 'sendemail.threaded' config setting.
>
> Signed-off-by: Adam Roben <aroben@apple.com>
Thanks. I've always felt that send-email has too much built-in
policy; I think this is a sensible change.
> @@ -138,8 +141,8 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
> $initial_reply_to,$initial_subject,@files,$from,$compose,$time);
>
> # Behavior modification variables
> -my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
> - $dry_run) = (1, 0, 0, 0, 0);
> +my ($threaded, $chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
> + $dry_run) = (1, 1, 0, 0, 0, 0);
While we are at it, you might want to make everything other than
quiet and dry_run overridable the same way.
^ 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