* [PATCH] send-email: allow sendmail binary to be used instead of SMTP
From: Eric Wong @ 2006-05-15 2:32 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
This should make local mailing possible for machines without
a connection to an SMTP server.
It'll default to using /usr/sbin/sendmail or /usr/lib/sendmail
if no SMTP server is specified (the default). If it can't find
either of those paths, it'll fall back to connecting to an SMTP
server on localhost.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 55 +++++++++++++++++++++++++++++++++++++++------------
1 files changed, 42 insertions(+), 13 deletions(-)
1c9bacc5a2bfe382f68046aeba62302d28e4c976
diff --git a/git-send-email.perl b/git-send-email.perl
index d8c4b1f..d27a7a5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -40,7 +40,8 @@ # Variables we fill in automatically, or
my (@to,@cc,@initial_cc,$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
# Behavior modification variables
-my ($chain_reply_to, $smtp_server, $quiet, $suppress_from, $no_signed_off_cc) = (1, "localhost", 0, 0, 0);
+my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc) = (1, 0, 0, 0);
+my $smtp_server;
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
@@ -179,8 +180,14 @@ if (!defined $initial_reply_to && $promp
$initial_reply_to =~ s/(^\s+|\s+$)//g;
}
-if (!defined $smtp_server) {
- $smtp_server = "localhost";
+if (!$smtp_server) {
+ foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
+ if (-x $_) {
+ $smtp_server = $_;
+ last;
+ }
+ }
+ $smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
}
if ($compose) {
@@ -358,18 +365,39 @@ X-Mailer: git-send-email $gitversion
";
$header .= "In-Reply-To: $reply_to\n" if $reply_to;
- $smtp ||= Net::SMTP->new( $smtp_server );
- $smtp->mail( $from ) or die $smtp->message;
- $smtp->to( @recipients ) or die $smtp->message;
- $smtp->data or die $smtp->message;
- $smtp->datasend("$header\n$message") or die $smtp->message;
- $smtp->dataend() or die $smtp->message;
- $smtp->ok or die "Failed to send $subject\n".$smtp->message;
+ if ($smtp_server =~ m#^/#) {
+ my $pid = open my $sm, '|-';
+ defined $pid or die $!;
+ if (!$pid) {
+ exec($smtp_server,'-i',@recipients) or die $!;
+ }
+ print $sm "$header\n$message";
+ close $sm or die $?;
+ if ($quiet) {
+ printf "Sent %s\n", $subject;
+ } else {
+ print "OK. Log says:
+Date: $date
+Sendmail: $smtp_server
+From: $from
+Subject: $subject
+Cc: $cc
+To: $to
- if ($quiet) {
- printf "Sent %s\n", $subject;
+Result: OK\n";
+ }
} else {
- print "OK. Log says:
+ $smtp ||= Net::SMTP->new( $smtp_server );
+ $smtp->mail( $from ) or die $smtp->message;
+ $smtp->to( @recipients ) or die $smtp->message;
+ $smtp->data or die $smtp->message;
+ $smtp->datasend("$header\n$message") or die $smtp->message;
+ $smtp->dataend() or die $smtp->message;
+ $smtp->ok or die "Failed to send $subject\n".$smtp->message;
+ if ($quiet) {
+ printf "Sent %s\n", $subject;
+ } else {
+ print "OK. Log says:
Date: $date
Server: $smtp_server Port: 25
From: $from
@@ -378,6 +406,7 @@ Cc: $cc
To: $to
Result: ", $smtp->code, ' ', ($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
+ }
}
}
--
1.3.2.g1c9b
^ permalink raw reply related
* [PATCH] Install git-send-email by default
From: Eric Wong @ 2006-05-15 2:26 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
After 567ffeb7722eefab3991cb894c96548b92b57cc2 and
4bc87a28be020a6bf7387161c65ea3d8e4a0228b, git-send-email no
longer requires any non-standard Perl modules, so there's no
reason to special-case it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Makefile | 7 ++-----
git.spec.in | 4 ++--
2 files changed, 4 insertions(+), 7 deletions(-)
df2d76fcee34efcf265b3a8a45940138e11a97c4
diff --git a/Makefile b/Makefile
index 8fd3e13..95d25f0 100644
--- a/Makefile
+++ b/Makefile
@@ -131,7 +131,8 @@ SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-shortlog.perl git-fmt-merge-msg.perl git-rerere.perl \
git-annotate.perl git-cvsserver.perl \
- git-svnimport.perl git-mv.perl git-cvsexportcommit.perl
+ git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
+ git-send-email.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
@@ -320,10 +321,6 @@ else
endif
endif
-ifdef WITH_SEND_EMAIL
- SCRIPT_PERL += git-send-email.perl
-endif
-
ifndef NO_CURL
ifdef CURLDIR
# This is still problematic -- gcc does not always want -R.
diff --git a/git.spec.in b/git.spec.in
index 96dfc1d..8ccd256 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -74,12 +74,12 @@ Git revision tree visualiser ('gitk')
%setup -q
%build
-make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease WITH_SEND_EMAIL=1 \
+make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
-make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease WITH_SEND_EMAIL=1 \
+make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
--
1.3.2.g1c9b
^ permalink raw reply related
* [PATCH (resend)] send-email: address expansion for common mailers
From: Eric Wong @ 2006-05-15 2:13 UTC (permalink / raw)
To: Junio C Hamano, git, Ryan Anderson; +Cc: Eric Wong
In-Reply-To: <20060326024416.GA14234@localdomain>
mutt, gnus, pine, mailrc formats should be supported.
Testing and feedback for correctness and completeness of all formats
and support for additional formats would be good.
Nested expansions are also supported.
More than one alias file to be used.
All alias file formats must still of be the same type, though.
Two git repo-config keys are required for this
(as suggested by Ryan Anderson):
sendemail.aliasesfile = <filename of aliases file>
sendemail.aliasfiletype = (mutt|gnus|pine|mailrc)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Looks like this patch got forgotten a while ago, and I never noticed
because I forgot to set WITH_SEND_EMAIL when doing make install.
Of course, WITH_SEND_EMAIL should no longer be needed...
git-send-email.perl | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
ff6593287dc500853c1cf05bdb0f32f970f10c9d
diff --git a/git-send-email.perl b/git-send-email.perl
index 703dd1f..d8c4b1f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -89,6 +89,41 @@ sub gitvar_ident {
my ($author) = gitvar_ident('GIT_AUTHOR_IDENT');
my ($committer) = gitvar_ident('GIT_COMMITTER_IDENT');
+my %aliases;
+chomp(my @alias_files = `git-repo-config --get-all sendemail.aliasesfile`);
+chomp(my $aliasfiletype = `git-repo-config sendemail.aliasfiletype`);
+my %parse_alias = (
+ # multiline formats can be supported in the future
+ mutt => sub { my $fh = shift; while (<$fh>) {
+ if (/^alias\s+(\S+)\s+(.*)$/) {
+ my ($alias, $addr) = ($1, $2);
+ $addr =~ s/#.*$//; # mutt allows # comments
+ # commas delimit multiple addresses
+ $aliases{$alias} = [ split(/\s*,\s*/, $addr) ];
+ }}},
+ mailrc => sub { my $fh = shift; while (<$fh>) {
+ if (/^alias\s+(\S+)\s+(.*)$/) {
+ # spaces delimit multiple addresses
+ $aliases{$1} = [ split(/\s+/, $2) ];
+ }}},
+ pine => sub { my $fh = shift; while (<$fh>) {
+ if (/^(\S+)\s+(.*)$/) {
+ $aliases{$1} = [ split(/\s*,\s*/, $2) ];
+ }}},
+ gnus => sub { my $fh = shift; while (<$fh>) {
+ if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
+ $aliases{$1} = [ $2 ];
+ }}}
+);
+
+if (@alias_files && defined $parse_alias{$aliasfiletype}) {
+ foreach my $file (@alias_files) {
+ open my $fh, '<', $file or die "opening $file: $!\n";
+ $parse_alias{$aliasfiletype}->($fh);
+ close $fh;
+ }
+}
+
my $prompting = 0;
if (!defined $from) {
$from = $author || $committer;
@@ -112,6 +147,19 @@ if (!@to) {
$prompting++;
}
+sub expand_aliases {
+ my @cur = @_;
+ my @last;
+ do {
+ @last = @cur;
+ @cur = map { $aliases{$_} ? @{$aliases{$_}} : $_ } @last;
+ } while (join(',',@cur) ne join(',',@last));
+ return @cur;
+}
+
+@to = expand_aliases(@to);
+@initial_cc = expand_aliases(@initial_cc);
+
if (!defined $initial_subject && $compose) {
do {
$_ = $term->readline("What subject should the emails start with? ",
--
1.3.2.g1c9b
^ permalink raw reply related
* Re: Branch relationships
From: Junio C Hamano @ 2006-05-15 2:11 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200605150348.53879.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> But not supporting this in a first step should be no problem, as
> you always can do "git pull somewhere that-head" directly.
That defeats the point of .git/remotes/ setup, and I suspect is
unacceptable to people who pull from a given branch of a given
repository repeatedly without ever tracking it. Think of the
maintainer pulling from subsystem maintainers.
^ permalink raw reply
* Re: [PATCH] Add "--summary" option to git diff.
From: Linus Torvalds @ 2006-05-15 1:51 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git, Johannes.Schindelin
In-Reply-To: <BAYC1-PASMTP02640E2C9813E4DA1E778BAEA30@CEZ.ICE>
On Sun, 14 May 2006, Sean wrote:
>
> What's a bit more worrying is that:
>
> $ PAGER= ./git whatchanged -B -C --stat --no-merges --diff-filter=RC
>
> Causes the same problem on the current (1.3.2) release branch without any
> other patches applied at all.
If you have electric fence installed, just do
PAGER= ef ./git whatchanged -B -C --stat --no-merges --diff-filter=RC
to run it with the efence preload, which should cause a core-dump and/or
be more debuggable.
Sadly, last I tried, you can't run gdb under ef, because electric fence
(incorrectly) thinks that zero-size allocations are bad.
Linus
^ permalink raw reply
* Re: git diff: support "-U" and "--unified" options properly
From: Junio C Hamano @ 2006-05-15 1:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605141745410.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 14 May 2006, Junio C Hamano wrote:
>>
>> I am not either after seeing your numbers and trying them
>> myself. I was going to look at it myself over the weekend, but
>> I ended up spending most of the time migrating my environment,
>> so no progress on that front yet. Sorry.
>
> I was looking at it, and I just suspect that "grep" is very optimized.
>
> At the same time, the built-in one had many good features, notably that
> you could grep the cached copy and from a specific version. So I think it
> makes sense.
>
> ... Except for testing, and fixing my stupid bugs, which
> I'm too lazy to do.
The command line flags needs to be
unparsed before feeding the external grep.
> The whole "exec_grep()" should basically be the same as "spawn_prog()".
> You get the idea.
>
> Anybody?
I think somebody wanted to have his own funky grep spawned off
from his PATH, so I'd leave that to him (or her I do not
remember which) ;-).
^ permalink raw reply
* Re: Branch relationships
From: Josef Weidendorfer @ 2006-05-15 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslncyxez.fsf@assigned-by-dhcp.cox.net>
On Monday 15 May 2006 01:55, you wrote:
> > After a "git clone", we would have
> >
> > [remote "origin"]
> > url = ...
> > fetch = master:origin
> >
> > [branch "master"]
> > origin = "origin" ; upstream of master is local branch "origin"
>
> Doesn't that arrangement force people to use tracking branches?
I think we already had the same discussion some time ago ;-)
This asks for support of a way to specify a remote origin branch
without any local tracking, like
origin = "<remotebranch> of <remote>"
But not supporting this in a first step should be no problem, as
you always can do "git pull somewhere that-head" directly.
A side-effect of the origin-arrangement would be that branching
off a tracking branch would automatically update it on pull from
the new branch. I would see this as improvement of usability as
"generating a local development branch from a remote one" does
not need any special command.
^ permalink raw reply
* Re: [PATCH] Add "--summary" option to git diff.
From: Sean @ 2006-05-15 0:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin
In-Reply-To: <7v3bfcno2b.fsf@assigned-by-dhcp.cox.net>
On Sun, 14 May 2006 17:12:28 -0700
Junio C Hamano <junkio@cox.net> wrote:
> The next branch with this and other patches applied seems to
> misbehave.
>
> It makes glibc unhappy with
>
> PAGER= ./git whatchanged -B -C --stat --summary --no-merges --diff-filter=RC
What's a bit more worrying is that:
$ PAGER= ./git whatchanged -B -C --stat --no-merges --diff-filter=RC
Causes the same problem on the current (1.3.2) release branch without any
other patches applied at all.
Sean
^ permalink raw reply
* Re: git diff: support "-U" and "--unified" options properly
From: Linus Torvalds @ 2006-05-15 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqu0yvda.fsf@assigned-by-dhcp.cox.net>
On Sun, 14 May 2006, Junio C Hamano wrote:
>
> I am not either after seeing your numbers and trying them
> myself. I was going to look at it myself over the weekend, but
> I ended up spending most of the time migrating my environment,
> so no progress on that front yet. Sorry.
I was looking at it, and I just suspect that "grep" is very optimized.
At the same time, the built-in one had many good features, notably that
you could grep the cached copy and from a specific version. So I think it
makes sense.
I have this suspicion that the best solution is to just handle the "grep
against current tree" separately, and even make that something that only
gets enabled on UNIX - I assume that trying to execve() grep externally
would suck on windows again.
So I would actually assume that the solution is to simply make
grep_cache() have a simple
#ifdef __unix__
if (!cached) {
hit = external_grep(opt, paths, cached);
if (hit >= 0)
return hit;
}
#endif
at the top, so that we'd have the best of both worlds.
The "external_grep()" should look something like this:
#define MAXARGS 1000
static int external_grep(struct grep_opt *opt, const char **paths, int cached)
{
int nr;
char *argv[MAXARGS];
read_cache();
argv[0] = "grep";
argv[1] = "-e";
argv[2] = opt->pattern; /* whatever */
argv[3] = "--";
argc = 4;
for (nr = 0; nr < active_nr; nr++) {
struct cache_entry *ce = active_cache[nr];
if (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))
continue;
if (!pathspec_matches(paths, ce->name))
continue;
argv[argc++] = ce->name;
if (argc < MAXARGS)
continue;
hit += exec_grep(argv, argc);
argc = 4;
}
if (argc > 4)
hit += exec_grep(argv, argc);
return hit;
}
and you're all done. Except for testing, and fixing my stupid bugs, which
I'm too lazy to do.
The whole "exec_grep()" should basically be the same as "spawn_prog()".
You get the idea.
Anybody?
Linus
^ permalink raw reply
* Re: git diff: support "-U" and "--unified" options properly
From: Junio C Hamano @ 2006-05-15 0:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605131518390.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 13 May 2006, Junio C Hamano wrote:
>>
>> * built-in grep (jc/grep)
>>
>> Ready.
>
> I'm not entirely convinced.
I am not either after seeing your numbers and trying them
myself. I was going to look at it myself over the weekend, but
I ended up spending most of the time migrating my environment,
so no progress on that front yet. Sorry.
^ permalink raw reply
* [PATCH] commit: allow --pretty= args to be abbreviated
From: Eric Wong @ 2006-05-15 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtcoyxs2.fsf@assigned-by-dhcp.cox.net>
Unlike the original one, this one only does prefix matches, so
you can't do --pretty=er anymore :)
This one really works with and without the gitopt changes.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > commit.c | 42 +++++++++++++++++++++++++++++-------------
> > 1 files changed, 29 insertions(+), 13 deletions(-)
>
> This is applicable without the gitopt changes, but I have a
> feeling that when we think about abbreviations the users would
> expect the leading substring abbreviation, not strstr().
>
> While "git log --pretty=lle" or "git log --pretty=or" might be
> unambiguous, I think that is trying to be too cute and
> confusing, especially if somebody picks up that habit by
> watching others type such a cute abbreviations.
>
> That comment probably incidentally applies to your bigger
> patches.
Ok. The current gitopt patch only uses leading substring abbreviations
by default. GIT_ABBREV_HARDER needs to be set if you want all the
crazyness :)
commit.c | 50 ++++++++++++++++++++++++++++++++++++--------------
1 files changed, 36 insertions(+), 14 deletions(-)
d4473559924b1a5ba655cd5d5b18d39f53e25184
diff --git a/commit.c b/commit.c
index 2717dd8..2753677 100644
--- a/commit.c
+++ b/commit.c
@@ -22,23 +22,45 @@ struct sort_node
const char *commit_type = "commit";
+struct cmt_fmt_map {
+ const char *n;
+ enum cmit_fmt v;
+} cmt_fmts[] = {
+ { "raw", CMIT_FMT_RAW },
+ { "medium", CMIT_FMT_MEDIUM },
+ { "short", CMIT_FMT_SHORT },
+ { "full", CMIT_FMT_FULL },
+ { "fuller", CMIT_FMT_FULLER },
+ { "oneline", CMIT_FMT_ONELINE },
+};
+
enum cmit_fmt get_commit_format(const char *arg)
{
- if (!*arg)
+ int i, found;
+ size_t len;
+
+ if (!arg || !*arg)
return CMIT_FMT_DEFAULT;
- if (!strcmp(arg, "=raw"))
- return CMIT_FMT_RAW;
- if (!strcmp(arg, "=medium"))
- return CMIT_FMT_MEDIUM;
- if (!strcmp(arg, "=short"))
- return CMIT_FMT_SHORT;
- if (!strcmp(arg, "=full"))
- return CMIT_FMT_FULL;
- if (!strcmp(arg, "=fuller"))
- return CMIT_FMT_FULLER;
- if (!strcmp(arg, "=oneline"))
- return CMIT_FMT_ONELINE;
- die("invalid --pretty format");
+ if (*arg == '=')
+ arg++;
+ for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
+ if (!strcmp(arg, cmt_fmts[i].n))
+ return cmt_fmts[i].v;
+ }
+
+ /* look for abbreviations */
+ len = strlen(arg);
+ found = -1;
+ for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
+ if (!strncmp(cmt_fmts[i].n, arg, len)) {
+ if (found >= 0)
+ die("invalid --pretty format: %s", arg);
+ found = i;
+ }
+ }
+ if (found >= 0)
+ return cmt_fmts[found].v;
+ die("invalid --pretty format: %s", arg);
}
static struct commit *check_commit(struct object *obj,
--
1.3.2.g58c0
^ permalink raw reply related
* Re: [PATCH] Add "--branches", "--tags" and "--remotes" options to git-rev-parse.
From: Sean @ 2006-05-15 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xp4196e.fsf@assigned-by-dhcp.cox.net>
On Sun, 14 May 2006 16:24:57 -0700
Junio C Hamano <junkio@cox.net> wrote:
> I do not have problem with that, but somebody else's script
> might; Cogito seems not to mind.
>
> Something like this perhaps?
That looks good. If you accept the rev-parse patch, then i'd suggest the
patch below instead.
Sean
diff --git a/git-tag.sh b/git-tag.sh
index dc6aa95..a0afa25 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -25,14 +25,12 @@ do
force=1
;;
-l)
- cd "$GIT_DIR/refs" &&
case "$#" in
1)
- find tags -type f -print ;;
- *)
- shift
- find tags -type f -print | grep "$@" ;;
+ set x . ;;
esac
+ shift
+ git rev-parse --symbolic --tags | sort | grep "$@"
exit $?
;;
-m)
^ permalink raw reply related
* Re: [PATCH] Add "--summary" option to git diff.
From: Junio C Hamano @ 2006-05-15 0:12 UTC (permalink / raw)
To: Sean; +Cc: git, Johannes Schindelin
In-Reply-To: <BAYC1-PASMTP0770FC4238970CB812C192AEA20@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> Remove the need to pipe git diff through git apply to
> get the extended headers summary.
>
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Hmph...
The next branch with this and other patches applied seems to
misbehave.
It makes glibc unhappy with
PAGER= ./git whatchanged -B -C --stat --summary --no-merges --diff-filter=RC
and "*** glibc detected *** malloc(): memory corruption: xxx ***"
but not with this:
PAGER= ./git whatchanged -B -C --no-merges --diff-filter=RC
nor with this:
PAGER= ./git whatchanged -B -C --summary --no-merges --diff-filter=RC
works just fine, so this is _not_ your fault, and I know who to
harrass ;-).
^ permalink raw reply
* Re: Branch relationships
From: Junio C Hamano @ 2006-05-14 23:55 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200605150104.46762.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Monday 15 May 2006 00:19, you wrote:
>> > I suppose "branch.<branch name>.origin" is still the way to go for
>> > specifying the upstream?
>>
>> Probably "origin" is a better name for it; I was assuming
>> "branch.<branch name>.remote = foo" refers to a [remote "foo"]
>> section and means "when on this branch, pull from foo and merge
>> from it".
>
> Maybe.
>
> But there is a misunderstanding. I wanted the branch attribute "origin"
> to specify the upstream _branch_, not a remote.
>
> After a "git clone", we would have
>
> [remote "origin"]
> url = ...
> fetch = master:origin
>
> [branch "master"]
> origin = "origin" ; upstream of master is local branch "origin"
Doesn't that arrangement force people to use tracking branches?
IOW, "git pull somewhere that-head" fetches that-head, without
storing it anywhere in the local repository as a tracking
branch, and immediately merges it to the current branch.
^ permalink raw reply
* Re: [PATCH 4/5] commit: allow --pretty= args to be abbreviated
From: Junio C Hamano @ 2006-05-14 23:47 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1147619963765-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> commit.c | 42 +++++++++++++++++++++++++++++-------------
> 1 files changed, 29 insertions(+), 13 deletions(-)
This is applicable without the gitopt changes, but I have a
feeling that when we think about abbreviations the users would
expect the leading substring abbreviation, not strstr().
While "git log --pretty=lle" or "git log --pretty=or" might be
unambiguous, I think that is trying to be too cute and
confusing, especially if somebody picks up that habit by
watching others type such a cute abbreviations.
That comment probably incidentally applies to your bigger
patches.
^ permalink raw reply
* Re: [PATCH 5/5] diff: parse U/u/unified options with an optional integer arg
From: Eric Wong @ 2006-05-14 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605140931410.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sun, 14 May 2006, Eric Wong wrote:
> >
> > -u (lowercase) now accepts an optional arg, like -U (GNU diff
> > -u also has this behavior).
>
> Actually, modern GNU "diff -u5" will say
>
> diff: `-5' option is obsolete; use `-U 5'
> diff: Try `diff --help' for more information.
>
> and exit.
>
> I'm not entirely sure why, but I think it's because "u" can be mixed (ie
> with something like "-urN"), while "U" cannot. The GNU diff rule seems to
> be that simple arguments can be mixed together, but arguments with
> parameters cannot. Which sounds sane.
Interesting. With _POSIX2_VERSION < 200112, diff is happy to accept
-u5. Setting _POSIX2_VERSION >= 200112 causes it to burp, however.
It turns out -u5 is actually short for -u -5, but I (and apparently some
other people) have always assumed -u5 worked like -U5. POSIX doesn't
like -<num> switches, however, but we support it regardless in rev-list.
I prefer that it works the -u5 way, of course :)
Also, I find integer arguments being bundled with other parameters to be
pretty nice feature, but it's easy to disable if users don't like it:
diff --git a/gitopt.c b/gitopt.c
index 9e85247..139cd2d 100644
--- a/gitopt.c
+++ b/gitopt.c
@@ -270,17 +270,9 @@ static const char * parse_bundled(struct
} else if (s->arg_fl) {
if (*cur) {
/* no space between the arg and opt switch: */
- if (s->arg_fl & ARG_IS_INT) {
- /* we know to handle stuff like:
- * -h24w80 => -h=24 -w=80 */
- char *endptr = (char *)cur;
- strtol(cur, &endptr, 10);
-
- while (cur < endptr)
- *c++ = *cur++;
- } else if (s->arg_fl & ARG_ONE) {
- /* unfortunately, other args are less
- * clear-cut */
+ if (s->arg_fl & ARG_ONE) {
+ /* don't attempt further unbundling, extra
+ * chars are arguments */
while (*cur)
*c++ = *cur++;
}
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] gitk: Display commit messages with word wrap
From: Paul Mackerras @ 2006-05-14 23:34 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20060514151456.GA18012@procyon.home>
Sergey Vlasov writes:
> Some people put very long strings into commit messages, which then
> become invisible in gitk (word wrapping in the commit details window is
> turned off, and there is no horizontal scroll bar). Enabling word wrap
> for just the commit message looks much better.
Well... you can scroll in any direction with mouse button 2, but ok...
> + $ctext insert end "\n" {}
Why are you adding the superfluous {} ?
> - set comment {}
> + set headers {}
Why are you changing the name here? Your commit description doesn't
address either of these points.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Display commit messages with word wrap
From: Junio C Hamano @ 2006-05-14 23:30 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20060514151456.GA18012@procyon.home>
Sergey Vlasov <vsu@altlinux.ru> writes:
> Some people put very long strings into commit messages, which then
> become invisible in gitk (word wrapping in the commit details window is
> turned off, and there is no horizontal scroll bar). Enabling word wrap
> for just the commit message looks much better.
I do not mind it myself but IIRC gitk's "no wrapping" was made
because people found wrapping annoying; maybe a runtime
configuration option?
^ permalink raw reply
* Re: [PATCH] Add "--branches", "--tags" and "--remotes" options to git-rev-parse.
From: Junio C Hamano @ 2006-05-14 23:24 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP043948149786B7EE06DED3AEA20@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On a related note, would it be okay to change "git tag -l" to
> produce a list of tags without the "tags/" prefix in front of
> every tag as it does now? Wanted to use the new "git
> rev-parse --tags" instead of "find" to produce the list but am
> not sure how important backward compatibility is in that case.
I do not have problem with that, but somebody else's script
might; Cogito seems not to mind.
Something like this perhaps?
-- >8 --
diff --git a/git-tag.sh b/git-tag.sh
index dc6aa95..2286ad5 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -28,11 +28,10 @@ do
cd "$GIT_DIR/refs" &&
case "$#" in
1)
- find tags -type f -print ;;
- *)
- shift
- find tags -type f -print | grep "$@" ;;
+ set x . ;;
esac
+ shift
+ find tags -type f -print | sed -e 's|^tags/||' | grep "$@"
exit $?
;;
-m)
^ permalink raw reply related
* Re: Tracking branch history
From: Junio C Hamano @ 2006-05-14 23:16 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20060513T140528-554@post.gmane.org>
Elrond <elrond+kernel.org@samba-tng.org> writes:
> Daniel Barkalow <barkalow <at> iabervon.org> writes:
>
>>
>> One feature that might make git more intuitive to people is if we were to
>> additionally track the history of what commit was the head of each branch
>> over time. This is only vaguely related to the history of the content, but
>> it's well-defined and sometimes significant.
>>
>> E.g., if you know that two weeks ago, what you had worked, but it doesn't
>> work now, you can use git-bisect to figure out what happened, but first
>> you have to figure out what commit it was that you were using two weeks
>> ago. Two weeks ago, we had that information, but we didn't keep it.
>
> On a related issue:
>
> Looking at a commit:
> commit id-commit
> parent id-1
> parent id-2
> parent id-3
>
> Merge branch 'branch-2', 'branch-3'
>
> One can tell the name of the branches for id-2 and id-3 (branch-2, 3),
> but one can't tell the name of id-1.
That's deliberate. If you are merging into a branch other than
"master", the message would say:
commit ea892b27b15fbc46a3bb3ad2ddce737dc6590ae5
Merge: 7278a29... 8d48ad6...
Author: Junio C Hamano <junkio@cox.net>
Date: Sat May 13 18:49:54 2006 -0700
Merge branch 'lt/config' into next
* lt/config:
git config syntax updates
Another config file parsing fix.
checkout: use --aggressive when running a 3-way merge (-m).
Fix git-pack-objects for 64-bit platforms
fix diff-delta bad memory access
The point is to keep the punch line as short and meaningful for
the most common case.
^ permalink raw reply
* Re: Tracking branch history
From: Junio C Hamano @ 2006-05-14 23:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060513181816.GA12475@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Log ref updates to logs/refs/<ref>
>
> If config parameter core.logRefUpdates is true then append a line
> to .git/logs/refs/<ref> whenever git-update-ref <ref> is executed.
I cannot decide if a parameter makes more sense, or just making
the existence of such a file a cue is better. For example, I do
not much care about when I updated each of my topic branch head,
while I do care about master, next, and pu branches. A global
parameter would make this black-or-white choice, while opening
the log without O_CREAT and write things out only when the log
file exists might make things as easy and controllable.
I could "touch" the ones I care about to prime the process.
Hmm?
^ permalink raw reply
* Re: Branch relationships
From: Josef Weidendorfer @ 2006-05-14 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xp4ntbf.fsf@assigned-by-dhcp.cox.net>
On Monday 15 May 2006 00:19, you wrote:
> > I suppose "branch.<branch name>.origin" is still the way to go for
> > specifying the upstream?
>
> Probably "origin" is a better name for it; I was assuming
> "branch.<branch name>.remote = foo" refers to a [remote "foo"]
> section and means "when on this branch, pull from foo and merge
> from it".
Maybe.
But there is a misunderstanding. I wanted the branch attribute "origin"
to specify the upstream _branch_, not a remote.
After a "git clone", we would have
[remote "origin"]
url = ...
fetch = master:origin
[branch "master"]
origin = "origin" ; upstream of master is local branch "origin"
[branch "origin"]
tracksremote ; bool
Now adding a further development branch for remote branch "topic", we would add
[remote "origin"]
...
fetch = topic:tracking-topic
[branch "local-topic"]
origin = "tracking-topic"
[branch "tracking-topic"]
tracksremote
Now, a "git pull" on branch "local-topic" does the right thing: it fetches
from remote "origin", as "tracking-topic" is given in a refspec there, and merges
"tracking-topic" to the current branch "local-topic", as given by the origin
attribute.
This also extends to local upstreams: a "git checkout -b topic2 master" would
append
[branch "topic2"]
origin = "master"
and a "git pull" on topic2 would merge the upstream "master".
Josef
^ permalink raw reply
* Re: Branch relationships
From: Junio C Hamano @ 2006-05-14 22:19 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200605150001.48548.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> Exactly. I would _want_ to push to both with single action when
>> I say "git push ko-private". Actually I have _never_ felt need
>> to, but Linus wanted it first and I think it makes sense.
>
> Hmmm. Isn't this a solution for a very special use-case?
> You even can not specify different push lines for the 2 URLs.
> I think you want an alias name for a group of remotes here?
Perhaps.
The "push to multiple places" is mostly for Linus backing things
up, and I tend to agree that your "alias" notation makes things
appear to be more general. However, I do not think you would
want to push to two different places with different branch
mappings, so I suspect that generality is not buying you much
while making things more easily misconfigured.
> I suppose "branch.<branch name>.origin" is still the way to go for
> specifying the upstream?
Probably "origin" is a better name for it; I was assuming
"branch.<branch name>.remote = foo" refers to a [remote "foo"]
section and means "when on this branch, pull from foo and merge
from it".
^ permalink raw reply
* Re: The git newbie experience
From: Junio C Hamano @ 2006-05-14 22:09 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: git
In-Reply-To: <446778B8.7080201@inoi.fi>
Tommi Virtanen <tv@inoi.fi> writes:
> My best idea so far is to add a "git commit -A" option, that
> essentially does the "update-index --refresh". Whenever index
> has a file state != HEAD, update-index it. The modified unrelated
> files will have index state == HEAD. Or altering "git commit -a"
> to do that.
I am not sure what you are trying to achieve by --refresh. It
does not update the object names in the index. Maybe you are
thinking about --again, but that is when you did something to
the index yourself, so it would not buy you much in the "novice
faced with merge" case.
Anyway, I think the time to commit is too late to save somebody
who does not understand the index. How would you explain why
you sometimes need to use -A and sometimes -a? That is why I
suggested to make "git pull" and "git merge" refuse to work if
there are local changes for novice users, where the definition
of novice is "git commit -a" is the only way to make a commit.
We can have [core] novice = yes in .git/config for that.
If somebody does not understand the index, if the merge is
prevented because the local change does conflict with it, how
would you explain why sometimes you can merge and sometimes you
cannot?
But if you insist going that route, I would say we could make
"git commit -a" on a merge commit to do a bit more magic.
For example, we could make -a do something special for a merge
by looking at the presense of .git/MERGE_HEAD.
- if "commit -a", and without .git/MERGE_HEAD, just grab
all the local modifications that are not in index yet,
and commit it.
- upon "commit -a", and when .git/MERGE_HEAD exists,
grab the paths that ls-files -u reports, update-index
them. Other automerged paths are already registered
in the index.
> Except, trying to solve usability problems by _adding_ options
> is just insane.
I am not sure if it is "usability" but additional option to
simplify things does not sound right, I'd agree.
> For example, we had a case where we absolutely _had_ to keep
> an ugly workaround in the tree, in a file not otherwise
> edited, but we definitely did not want to commit the kludge,
> at least not to the branch that was really being worked on. So
> such restricted mode would just have meant either people could
> not merge, or they had to use index anyway.
Your example is a very ill-thought out one.
If you are leaving the uncommitable kludge around, you cannot be
using "commit -a" with the normal non-merge workflow. Why
would you worry about not being able to do "commit -a" on a
merge then?
For the beginning user without index, I would rewrite your
scenario like this.
- Jack is a beginning user of git and does not (want to) understand
the index (right now).
- Jack works on branch X, say his HEAD points to X1. He has an edited,
uncommitted files with the names A, B and C.
- Jack wants to pull new changes made by others to his branch.
But "git merge" invoked from "git pull" says he needs to stash
away the local changes to do the merge.
- Jack stashes away what he has been working on and cleans up
his mess.
git diff >P.diff
git checkout HEAD A B C
- Jack then pulls. There are merge conflicts in files D, E, ..., Z.
- Jack resolves the merge conflicts and is ready to commit the resulting
merge. Note files A, B and C do not have his unfinished work.
There is no "if Jack does this or that" problem; he says "git
commit -a" because that is the only "commit" command he knows
about.
- Jack then reapplies what he stashed away with "git apply P.diff"
and keeps working.
Maybe "git stash" command that does "git diff --full-index" with
some frills, and "git unstash" command which does an equivalent
of "git am -3" would help this workflow (bare "git apply" does
not do the three-way merge like am does).
^ permalink raw reply
* Re: Branch relationships
From: Josef Weidendorfer @ 2006-05-14 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr72w2thu.fsf@assigned-by-dhcp.cox.net>
On Sunday 14 May 2006 23:20, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> >> ; my private build areas on the kernel.org machines
> >> [remote "ko-private"]
> >> url = "x86-64-build.kernel.org:git"
> >> url = "i386-build.kernel.org:git"
> >> push = master:origin
> >> ...
> >
> > specifies that "git push" should push to both URLs?
>
> Exactly. I would _want_ to push to both with single action when
> I say "git push ko-private". Actually I have _never_ felt need
> to, but Linus wanted it first and I think it makes sense.
Hmmm. Isn't this a solution for a very special use-case?
You even can not specify different push lines for the 2 URLs.
I think you want an alias name for a group of remotes here?
Why not
[remotealias "ko-private"]
remote = "ko-private-x86-64"
remote = "ko-private-i386"
Neverless, this wasn't the thing I was after.
> That is what "branch.foo.remote = this-remote" is about.
OK. Sorry, I somehow missed this.
> When
> working on foo branch, use what is described in
> remote."this-remote" section for "git pull".
> remote."this-remote" would have url and one or more fetch lines,
> and as usual the first fetch line would say "merge this thing".
> This gives the continuity in semantics while migrating from
> .git/remotes/foo to [remote "foo"] section of the config file.
The only thing I wanted to discuss in this thread is exactly the
limitation of "as usual the first fetch line..." by the branch
attribute "origin", which lead me to the alternative "tracksremote"
attribute. Sorry about any confusion.
I suppose "branch.<branch name>.origin" is still the way to go for
specifying the upstream?
Josef
^ 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