* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Timo Hirvonen @ 2006-07-10 9:45 UTC (permalink / raw)
To: Ryan Anderson; +Cc: pasky, martin.langhoff, git
In-Reply-To: <44B19D42.6030701@michonline.com>
Ryan Anderson <ryan@michonline.com> wrote:
> By "don't split the Makefile", do mean, "Don't use recursive make"?
>
> I'm fine with that (and if you look at my patch, I "include
> scm/Makefile" to do just that), but if you mean "keep only a top-level
> Makefile", well, I think that continues the problem of "there is too
> much stuff going on here", but I can be persuaded otherwise.
Recursive make is a horrible hack. Splitting Makefile to smaller chunks
which would be included in the top level Makefile is almost as bad. You
can't cd to subdirectory and run make there and you have to prefix all
files with "subdir/".
If you really want to make Makefile shorter just move all the platform
specific stuff to a configure script.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vzmfhdhrf.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:
> It is sad that some people stay behind and we need to
> cater to them, though.
Do you, really?
OG.
^ permalink raw reply
* problems GIT_TRACE
From: Matthias Lederhofer @ 2006-07-10 11:05 UTC (permalink / raw)
To: git
I just discovered a problem with GIT_TRACE. Some scripts redirect
stderr to stdout and the trace messages go with it. For example from
git-repack:
> name=$(git-rev-list --objects --all $rev_list 2>&1 |
> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
> exit 1
Then for example git-pack-objects complains:
> fatal: expected sha1, got garbage:
> trace: built-in: git 'rev-list' '--objects' '--all'
git-grep '2>&' shows a few other places that do this too, I'll take a
closer look at this later. Is there any reason to redirect stderr to
stdout? I think this will always fail with such a strange error
message when something is written to stderr.
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Johannes Schindelin @ 2006-07-10 11:06 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Junio C Hamano, git
In-Reply-To: <20060710094653.GA52962@dspnet.fr.eu.org>
Hi,
On Mon, 10 Jul 2006, Olivier Galibert wrote:
> On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:
> > It is sad that some people stay behind and we need to
> > cater to them, though.
>
> Do you, really?
Well, I guess as long as things do not break for _you_, we do not need to.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix linking for not-so-clever linkers.
From: Johannes Schindelin @ 2006-07-10 11:40 UTC (permalink / raw)
To: git, junkio
On one of my systems, the linker is not intelligent enough to link with
pager.o (in libgit.a) when only the variable pager_in_use is needed. The
consequence is that the linker complains about an undefined variable. So,
put the variable into environment.o, where it is linked always.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
environment.c | 1 +
| 2 --
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/environment.c b/environment.c
index 43823ff..97d42b1 100644
--- a/environment.c
+++ b/environment.c
@@ -21,6 +21,7 @@ char git_commit_encoding[MAX_ENCODING_LE
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace = NULL;
int zlib_compression_level = Z_DEFAULT_COMPRESSION;
+int pager_in_use;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
--git a/pager.c b/pager.c
index bb14e99..280f57f 100644
--- a/pager.c
+++ b/pager.c
@@ -5,8 +5,6 @@ #include "cache.h"
* something different on Windows, for example.
*/
-int pager_in_use;
-
static void run_pager(const char *pager)
{
execlp(pager, pager, NULL);
--
1.4.1.g6e33b-dirty
^ permalink raw reply related
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 11:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607101306030.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Jul 10, 2006 at 01:06:44PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 10 Jul 2006, Olivier Galibert wrote:
>
> > On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:
> > > It is sad that some people stay behind and we need to
> > > cater to them, though.
> >
> > Do you, really?
>
> Well, I guess as long as things do not break for _you_, we do not need to.
Supporting old, not-standard-anymore compilers has a cost in
maintainability, by precluding the use of better constructs (//
comments, declarations near initialisation, struct initializers...).
Additionally, it gets harder and harder to have people test for them.
Given than you can find gcc on pretty much everything that has a
filesystem cache decent enough to handle git correctly, is this cost
worth it? _That_ was the question.
OG.
^ permalink raw reply
* Perl gurus: why do we need Scalar::Util?
From: Johannes Schindelin @ 2006-07-10 11:44 UTC (permalink / raw)
To: git
Hi,
please do not let my die dumb: what is this "blessed" thing all about? And
why do we need it in the private-Error.pm??
Thanks,
Dscho
^ permalink raw reply
* newbie'ish FAQ/question about merging different trees
From: Peter Gervai @ 2006-07-10 11:56 UTC (permalink / raw)
To: git
Hello,
I ask with specifics to make it easier to get, but the question
probably general.
In one sentence: I would like to use
linux/kernel/git/jejb/aic94xx-sas-2.6.git with the current released
kernel, which is 2.6.17.4 at the moment.
In more sentences:
There are two trees on kernel.org's git:
linux/kernel/git/jejb/aic94xx-sas-2.6.git (it seems to be at 2.6.16-rc5)
linux/kernel/git/torvalds/linux-2.6.git (it probably does have a tag
at v2.6.17.4)
Is there a way to merge these to produce 2.6.17.4 (latest released), patched?
Thanks,
Peter
ps: ...apart from asking the subtree's maintainer to update his tree...
^ permalink raw reply
* [PATCH] read-tree --rename (WIP)
From: Junio C Hamano @ 2006-07-10 12:18 UTC (permalink / raw)
To: git
This adds '--rename' flag to 3-way merge done by "read-tree -m".
Currently it detects the case where one branch renamed but the
other branch didn't. It should be taught to notice that both
branches renamed the same old path to the same new path.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* To use this, you would copy git-merge-resolve.sh to create
git-merge-rename.sh, replace "git-read-tree --aggressive"
call with "git-read-tree --rename", or something like that.
I wanted to avoid the changes to threeway_merge(). They were
to force the code to leave "only one side added" cases
unmerged.
builtin-read-tree.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 6df5d7c..e7aba0e 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -11,6 +11,8 @@ #include "object.h"
#include "tree.h"
#include "tree-walk.h"
#include "cache-tree.h"
+#include "diff.h"
+#include "diffcore.h"
#include <sys/time.h>
#include <signal.h>
#include "builtin.h"
@@ -22,6 +24,7 @@ static int index_only = 0;
static int nontrivial_merge = 0;
static int trivial_merges_only = 0;
static int aggressive = 0;
+static int do_renames = 0;
static int verbose_update = 0;
static volatile int progress_update = 0;
static const char *prefix = NULL;
@@ -389,6 +392,130 @@ static void check_updates(struct cache_e
}
}
+static struct cache_entry *renamed_entry(const char *new_name, int namelen, struct cache_entry *old)
+{
+ struct cache_entry *renamed;
+
+ renamed = xcalloc(1, cache_entry_size(namelen));
+ renamed->ce_mode = old->ce_mode;
+ renamed->ce_flags = create_ce_flags(namelen, ce_stage(old));
+ strcpy(renamed->name, new_name);
+ memcpy(renamed->sha1, old->sha1, 20);
+ return renamed;
+}
+
+static void handle_renames(void)
+{
+ /* Find entries that have stages #1 and #2 (but not #3)
+ * and then entries that have stage #3 only.
+ * If #1 of the former and #3 of the latter are similar,
+ * that means we did not rename it but they did.
+ * Similarly, entries that have stages #1 and #3 can be
+ * matched up with entries that have only stage #2, in
+ * which case they did not rename but we did.
+ * In either case, move the #1 and unmoved stage to the
+ * path of the moved stage.
+ */
+ struct diff_options opt;
+ int i;
+
+ diff_setup(&opt);
+ opt.detect_rename = DIFF_DETECT_RENAME;
+ opt.output_format = DIFF_FORMAT_NO_OUTPUT;
+ opt.recursive = 1;
+ diff_setup_done(&opt);
+
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ int j;
+ if (!ce_stage(ce))
+ continue; /* fully merged */
+
+ for (j = i + 1; j < active_nr; j++) {
+ if (strcmp(ce->name, active_cache[j]->name))
+ break;
+ }
+
+ if (ce_stage(ce) == 1 && (j - i) == 2)
+ /* This entry has stage #1 and another one
+ * i.e. either #2 or #3 but not both.
+ */
+ diff_addremove(&opt, '-', ntohl(ce->ce_mode), ce->sha1,
+ ce->name, NULL);
+
+ if (1 < ce_stage(ce) && (j - i) == 1)
+ /* This entry has only stage #2 or #3 */
+ diff_addremove(&opt, '+', ntohl(ce->ce_mode), ce->sha1,
+ ce->name, NULL);
+
+ i = j - 1;
+ }
+ diffcore_std(&opt);
+
+ if (diff_queued_diff.nr) {
+ /* We have found the renames and stuff */
+ for (i = 0; i < diff_queued_diff.nr; i++) {
+ struct diff_filepair *p = diff_queued_diff.queue[i];
+ const char *old_name, *new_name;
+ int namelen;
+ struct cache_entry *e, *e_one, *e_kept, *e_moved;
+ int pos, kept;
+
+ if (p->status != DIFF_STATUS_RENAMED)
+ continue;
+
+ /* one->path has stage #1 and either stage #2
+ * or #3 that was kept on one branch, and
+ * two->path is where it was moved on the other
+ * branch, either stage #2 or stage #3.
+ */
+ old_name = p->one->path;
+ new_name = p->two->path;
+ namelen = strlen(new_name);
+ pos = cache_name_pos(old_name, strlen(old_name));
+ if (0 <= pos)
+ die("oops %s:%d", __FILE__, __LINE__);
+ pos = -pos - 1;
+ e = active_cache[pos++];
+ if (strcmp(e->name, old_name))
+ die("oops %s:%d", __FILE__, __LINE__);
+ if (ce_stage(e) != 1)
+ die("oops %s:%d", __FILE__, __LINE__);
+ e_one = renamed_entry(new_name, namelen, e);
+ if (active_nr <= pos)
+ die("oops %s:%d", __FILE__, __LINE__);
+ e = active_cache[pos];
+ if (strcmp(e->name, old_name))
+ die("oops %s:%d", __FILE__, __LINE__);
+ kept = ce_stage(e);
+ if (kept < 2)
+ die("oops %s:%d", __FILE__, __LINE__);
+ e_kept = renamed_entry(new_name, namelen, e);
+
+ pos = cache_name_pos(new_name, namelen);
+ if (0 <= pos)
+ die("oops %s:%d", __FILE__, __LINE__);
+ pos = -pos - 1;
+ e = active_cache[pos];
+ if (strcmp(e->name, new_name))
+ die("oops %s:%d", __FILE__, __LINE__);
+ if (ce_stage(e) + kept != 5)
+ /* If kept was #2 this must be #3 and
+ * vice versa.
+ */
+ die("oops %s:%d", __FILE__, __LINE__);
+ e_moved = renamed_entry(new_name, namelen, e);
+
+ remove_file_from_cache(old_name);
+ remove_file_from_cache(new_name);
+ add_cache_entry(e_one, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(e_kept, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(e_moved, ADD_CACHE_OK_TO_ADD);
+ }
+ }
+ diff_flush(&opt);
+}
+
static int unpack_trees(merge_fn_t fn)
{
int indpos = 0;
@@ -412,6 +539,9 @@ static int unpack_trees(merge_fn_t fn)
if (trivial_merges_only && nontrivial_merge)
die("Merge requires file-level merging");
+ if (merge_size == 3 && do_renames)
+ handle_renames();
+
check_updates(active_cache, active_nr);
return 0;
}
@@ -606,6 +736,10 @@ static int threeway_merge(struct cache_e
}
}
+ if (do_renames && remote && !head && !index && any_anc_missing)
+ /* they created, we didn't -- maybe they renamed */
+ return keep_entry(remote);
+
/* We start with cases where the index is allowed to match
* something other than the head: #14(ALT) and #2ALT, where it
* is permitted to match the result instead.
@@ -625,6 +759,10 @@ static int threeway_merge(struct cache_e
}
if (head) {
+ if (do_renames && !remote && any_anc_missing)
+ /* we created, they didn't -- maybe we renamed */
+ return keep_entry(head);
+
/* #5ALT, #15 */
if (same(head, remote))
return merged_entry(head, index);
@@ -868,6 +1006,9 @@ static void prime_cache_tree(void)
static const char read_tree_usage[] = "git-read-tree (<sha> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <sha1> [<sha2> [<sha3>]])";
+static const char err_aggressive_rename[] =
+"--aggressive and --rename are mutually exclusive";
+
static struct lock_file lock_file;
int cmd_read_tree(int argc, const char **argv, char **envp)
@@ -952,10 +1093,19 @@ int cmd_read_tree(int argc, const char *
}
if (!strcmp(arg, "--aggressive")) {
+ if (do_renames)
+ die(err_aggressive_rename);
aggressive = 1;
continue;
}
+ if (!strcmp(arg, "--rename")) {
+ if (aggressive)
+ die(err_aggressive_rename);
+ do_renames = 1;
+ continue;
+ }
+
/* "-m" stands for "merge", meaning we start in stage 1 */
if (!strcmp(arg, "-m")) {
if (stage || merge || prefix)
--
1.4.1.gf157
^ permalink raw reply related
* Re: problems GIT_TRACE
From: Junio C Hamano @ 2006-07-10 12:22 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1Fzta3-00066Z-8B@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> I just discovered a problem with GIT_TRACE. Some scripts redirect
> stderr to stdout and the trace messages go with it. For example from
> git-repack:
>> name=$(git-rev-list --objects --all $rev_list 2>&1 |
>> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
>> exit 1
> Then for example git-pack-objects complains:
>> fatal: expected sha1, got garbage:
>> trace: built-in: git 'rev-list' '--objects' '--all'
> git-grep '2>&' shows a few other places that do this too, I'll take a
> closer look at this later. Is there any reason to redirect stderr to
> stdout? I think this will always fail with such a strange error
> message when something is written to stderr.
This particular one is trying to catch an error condition from
rev-list. Shell reports the exit status from the last command
in the pipeline, and when rev-list notices a corrupt repository,
it wants to tell pack-objects to stop producing incorrect pack,
but there is no way other than sending a garbage string (as an
error message) to cause pack-object to notice there is garbage
coming in.
^ permalink raw reply
* Re: newbie'ish FAQ/question about merging different trees
From: Alex Riesen @ 2006-07-10 12:31 UTC (permalink / raw)
To: Peter Gervai; +Cc: git
In-Reply-To: <d55656c10607100456o761bb342p3db229b499579dd9@mail.gmail.com>
On 7/10/06, Peter Gervai <grin@grin.hu> wrote:
> There are two trees on kernel.org's git:
>
> linux/kernel/git/jejb/aic94xx-sas-2.6.git (it seems to be at 2.6.16-rc5)
> linux/kernel/git/torvalds/linux-2.6.git (it probably does have a tag
> at v2.6.17.4)
It doesn't. The stable tags are in stable per-release repo
(linux-2.6.17.y.git currently)
> Is there a way to merge these to produce 2.6.17.4 (latest released), patched?
>
Why, doesn't "git pull aic94xx-sas-2.6.git master" work anymore?
^ permalink raw reply
* Re: Perl gurus: why do we need Scalar::Util?
From: Petr Baudis @ 2006-07-10 13:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607101343060.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Mon, Jul 10, 2006 at 01:44:39PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> please do not let my die dumb: what is this "blessed" thing all about? And
> why do we need it in the private-Error.pm??
I'm working on it. I'll try to get a patch together by the evening.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Randal L. Schwartz @ 2006-07-10 13:09 UTC (permalink / raw)
To: Michal Rokos; +Cc: Junio C Hamano, git
In-Reply-To: <200607100741.26377.michal.rokos@nextsoft.cz>
>>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
Michal> I don't se the point. If you ask me, I'd say it should be either:
Michal> - controlled fully via env: which means 'perl' in scripts and /usr/bin/env in
Michal> *.perl; or
which *pointlessly* doesn't work if *I* have installed a private Perl and a
private git on a large shared systems, and *you* on the same system want to
use my git installation, but not necessarily have my Perl in your path.
There's *no* point to the env hack. You're *installing* the file, which means
you can *rewrite* it as needed. The env hack is a quick hack in case you have
a no-install file (something you're rsync'ing from one machine to another) for
strictly personal use. Don't introduce that to something like the formal
git installation.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: newbie'ish FAQ/question about merging different trees
From: Peter Gervai @ 2006-07-10 13:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0607100531k6fc6921do1990850aef259dba@mail.gmail.com>
On 7/10/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/10/06, Peter Gervai <grin@grin.hu> wrote:
> > There are two trees on kernel.org's git:
> >
> > linux/kernel/git/jejb/aic94xx-sas-2.6.git (it seems to be at 2.6.16-rc5)
> > linux/kernel/git/torvalds/linux-2.6.git (it probably does have a tag
> > at v2.6.17.4)
>
> It doesn't. The stable tags are in stable per-release repo
> (linux-2.6.17.y.git currently)
Well, even that would do.
> > Is there a way to merge these to produce 2.6.17.4 (latest released), patched?
>
> Why, doesn't "git pull aic94xx-sas-2.6.git master" work anymore?
s/Why,/The answer /;
s/ anymore/s for you, right?/;
:)
Thanks, it merged. It does not compile, but that's what I get using
git trees. :)
^ permalink raw reply
* [PATCH] fix git-repack for use with GIT_TRACE
From: Matthias Lederhofer @ 2006-07-10 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtalbqeo.fsf@assigned-by-dhcp.cox.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> This particular one is trying to catch an error condition from
> rev-list. Shell reports the exit status from the last command
> in the pipeline, and when rev-list notices a corrupt repository,
> it wants to tell pack-objects to stop producing incorrect pack,
> but there is no way other than sending a garbage string (as an
> error message) to cause pack-object to notice there is garbage
> coming in.
Ok, this patch should fix this. Instead of "echo abort" another more
meaningful message could be used. I checked the other scripts which
redirect stderr and they should be fine. In the tests I found
t/t1200-tutorial.sh:38
t/t1300-repo-config.sh:276
t/t5500-fetch-pack.sh:66
redirecting stderr, which probably fail which GIT_TRACE.
git-cvsserver.perl:2138 has 2>&1 but uses an regexp to match for the
content, so the trace message should not make a problem. Can someone
using git-cvsserver confirm this? Perhaps this should be changed to
2>/dev/null anyway.
---
git-repack.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 640ad8d..4dd7dad 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -43,7 +43,7 @@ case ",$all_into_one," in
;;
esac
pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
-name=$(git-rev-list --objects --all $rev_list 2>&1 |
+name=$( (git-rev-list --objects --all $rev_list || echo abort) |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
exit 1
if [ -z "$name" ]; then
--
1.4.1.gf157-dirty
^ permalink raw reply related
* Re: [Patch] Using 'perl' in *.sh
From: Johannes Schindelin @ 2006-07-10 13:16 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Michal Rokos, git
In-Reply-To: <86veq5sj22.fsf@blue.stonehenge.com>
Hi,
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
> >>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
>
> Michal> I don't se the point. If you ask me, I'd say it should be either:
> Michal> - controlled fully via env: which means 'perl' in scripts and /usr/bin/env in
> Michal> *.perl; or
>
> which *pointlessly* doesn't work if *I* have installed a private Perl and a
> private git on a large shared systems, and *you* on the same system want to
> use my git installation, but not necessarily have my Perl in your path.
... so, git depends on perl. You know what that means...
Ciao,
Dscho
^ permalink raw reply
* Re: Perl gurus: why do we need Scalar::Util?
From: Randal L. Schwartz @ 2006-07-10 13:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607101343060.29667@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> please do not let my die dumb: what is this "blessed" thing all about? And
Johannes> why do we need it in the private-Error.pm??
Ugh. Just took a peek for the first time at the "next" branch, and I see the
dangerous syntactic-sugar try { } catch { }. Sorry for not noticing that
earlier.
While that syntax looks like it would make things easier in theory, in
practice it is a source of leak-after-leak because it creates a closure for
the two blocks, and that can easily lead to a circular reference for
long-running tools. This would be of some concern if someone writes
a mod_perl module or a standalone webserver that doesn't exec itself
to clean up (which it shouldn't need).
So, if there's going to be rewrite, the first part would be to eliminate
the try { } catch { } sugar, and replace it with more traditional
exception catchers.
eval { };
if ($@) { ... }
Note that I'm *not* suggesting not to use Error.pm - that's a great
means by which to create hierarchical error classes that stringify nicely
and carry context on the error. I'm just saying to throw out the
try/catch syntax helper.
Sorry about that. If it's any consequence, we got it right in Perl 6. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Randal L. Schwartz @ 2006-07-10 13:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michal Rokos, git
In-Reply-To: <Pine.LNX.4.63.0607101514410.29667@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> ... so, git depends on perl. You know what that means...
Fine. perl has to be installed for git to work, and not necessarily in my
path. You know what *that* means. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Perl gurus: why do we need Scalar::Util?
From: Petr Baudis @ 2006-07-10 14:29 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Johannes Schindelin, git
In-Reply-To: <86k66lsi5q.fsf@blue.stonehenge.com>
Dear diary, on Mon, Jul 10, 2006 at 03:28:49PM CEST, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> While that syntax looks like it would make things easier in theory, in
> practice it is a source of leak-after-leak because it creates a closure for
> the two blocks, and that can easily lead to a circular reference for
> long-running tools.
Care to elaborate, please? All I've found are several mentions that the
problem is there, but not what the problem actually is and it doesn't
occur to me why is it a problem.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Josh Triplett @ 2006-07-10 15:44 UTC (permalink / raw)
To: git
Add message_id and ref_message_id fields to struct rev_info, used in show_log
with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively.
Use these in git-format-patch to make the second and subsequent patch mails
replies to the first patch mail.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
---
git-send-email already does this, but this change helps people who use
things like git-imap-send or similar to send the patch emails by other
means.
builtin-log.c | 23 +++++++++++++++++++++++
log-tree.c | 5 +++++
revision.h | 2 ++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 864c6cd..9d0cae1 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -220,6 +220,17 @@ static void get_patch_ids(struct rev_inf
o2->flags = flags2;
}
+static void gen_message_id(char *dest, unsigned int length, char *base)
+{
+ const char *committer = git_committer_info(1);
+ const char *email_start = strrchr(committer, '<');
+ const char *email_end = strrchr(committer, '>');
+ if(!email_start || !email_end || email_start > email_end - 1)
+ die("Could not extract email from committer identity.");
+ snprintf(dest, length, "%s.%u.git.%.*s", base, time(NULL),
+ email_end - email_start - 1, email_start + 1);
+}
+
int cmd_format_patch(int argc, const char **argv, char **envp)
{
struct commit *commit;
@@ -233,6 +244,8 @@ int cmd_format_patch(int argc, const cha
int ignore_if_in_upstream = 0;
struct diff_options patch_id_opts;
char *add_signoff = NULL;
+ char message_id[1024];
+ char ref_message_id[1024];
init_revisions(&rev);
rev.commit_format = CMIT_FMT_EMAIL;
@@ -359,6 +372,16 @@ int cmd_format_patch(int argc, const cha
int shown;
commit = list[nr];
rev.nr = total - nr + (start_number - 1);
+ /* Make the second and subsequent mails replies to the first */
+ if (nr == (total - 2)) {
+ strncpy(ref_message_id, message_id,
+ sizeof(ref_message_id));
+ ref_message_id[sizeof(ref_message_id)-1] = '\0';
+ rev.ref_message_id = ref_message_id;
+ }
+ gen_message_id(message_id, sizeof(message_id),
+ sha1_to_hex(commit->object.sha1));
+ rev.message_id = message_id;
if (!use_stdout)
reopen_stdout(commit, rev.nr, keep_subject);
shown = log_tree_commit(&rev, commit);
diff --git a/log-tree.c b/log-tree.c
index 9d8d46f..4971988 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -97,6 +97,11 @@ void show_log(struct rev_info *opt, cons
subject = "Subject: ";
printf("From %s Mon Sep 17 00:00:00 2001\n", sha1);
+ if (opt->message_id)
+ printf("Message-Id: <%s>\n", opt->message_id);
+ if (opt->ref_message_id)
+ printf("In-Reply-To: <%s>\nReferences: <%s>\n",
+ opt->ref_message_id, opt->ref_message_id);
if (opt->mime_boundary) {
static char subject_buffer[1024];
static char buffer[1024];
diff --git a/revision.h b/revision.h
index c010a08..e23ec8f 100644
--- a/revision.h
+++ b/revision.h
@@ -61,6 +61,8 @@ struct rev_info {
struct log_info *loginfo;
int nr, total;
const char *mime_boundary;
+ const char *message_id;
+ const char *ref_message_id;
const char *add_signoff;
const char *extra_headers;
--
1.4.1.gbe4c7-dirty
^ permalink raw reply related
* Re: [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Johannes Schindelin @ 2006-07-10 16:01 UTC (permalink / raw)
To: git, josht
In-Reply-To: <1152546266.8890.19.camel@josh-work.beaverton.ibm.com>
Hi,
please make that behaviour optional.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Erik Mouw @ 2006-07-10 16:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, josht
In-Reply-To: <Pine.LNX.4.63.0607101801360.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Jul 10, 2006 at 06:01:48PM +0200, Johannes Schindelin wrote:
> please make that behaviour optional.
Rather make it consistent with git-send-email. Principle of least
surprise.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Josh Triplett @ 2006-07-10 16:43 UTC (permalink / raw)
To: Erik Mouw; +Cc: Johannes Schindelin, git, josht
In-Reply-To: <20060710162920.GR20191@harddisk-recovery.com>
On Mon, 2006-07-10 at 18:29 +0200, Erik Mouw wrote:
> On Mon, Jul 10, 2006 at 06:01:48PM +0200, Johannes Schindelin wrote:
> > please make that behaviour optional.
>
> Rather make it consistent with git-send-email. Principle of least
> surprise.
Well, git-send-email does not include an option to disable the threading
headers, so consistency with git-send-email would imply not including
any such option. I can, however, implement a --no-thread option to omit
the headers, as well as git-send-email's --in-reply-to option to set an
initial In-Reply-To/References. New patch series shortly.
- Josh Triplett
^ permalink raw reply
* can I get only the list of merges?
From: Diego Calleja @ 2006-07-10 17:26 UTC (permalink / raw)
To: git
Hi, git-log and git-rev-list and friends have a --no-merges option. However,
I need the contrary functionality: a sort of "--only-merges" way of getting
the log? (that is, without parsing manually the git-log output)
^ permalink raw reply
* Re: can I get only the list of merges?
From: Matthias Lederhofer @ 2006-07-10 17:41 UTC (permalink / raw)
To: Diego Calleja; +Cc: git
In-Reply-To: <20060710192622.70c51a81.diegocg@gmail.com>
Diego Calleja <diegocg@gmail.com> wrote:
> Hi, git-log and git-rev-list and friends have a --no-merges option. However,
> I need the contrary functionality: a sort of "--only-merges" way of getting
> the log? (that is, without parsing manually the git-log output)
Perhaps something like this? It finds all commits with more than one
parent (I dunno if there are any other commits that have more than one
parent)
git-rev-list --parents HEAD | \
grep -E '^([a-z0-9]{40} ){2}[a-z0-9]{40}' | \
cut -d ' ' -f 1
^ 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