* Re: can I get only the list of merges?
From: Linus Torvalds @ 2006-07-10 18:51 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Diego Calleja, git
In-Reply-To: <Pine.LNX.4.64.0607101103160.5623@g5.osdl.org>
On Mon, 10 Jul 2006, Linus Torvalds wrote:
>
> However, if you want a _sneaky_ way of doing it, and want a graphical
> result, and have a recent version of git, you can also just do something
> like
>
> gitk --full-history -- %%nonexistant-file%%
>
> which will give you each commit that changes that nonexistant file (there
> should be none ;), and the full commit history for those (ie all the
> merges).
Btw, a better way to do the same is probably
gitk --full-history -- a//b
which is guaranteed to not match any files and doesn't depend on just an
_unlikely_ filename. Instead, it depends on the fact that a name with a
double slash should not exist in a git archive.
(There are other possibilities too - instead of "a//a", you can just use
the filename ".git", for the same reasons - it definitely won't be tracked
by git).
Linus
^ permalink raw reply
* git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 18:42 UTC (permalink / raw)
To: git
Am I missing an option to have git-log go forward in time rather than
backward? I'd really like "git-log --pretty=short ORIG_HEAD..HEAD" to show me
a story I can read. :)
--
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
* [PATCH 3/3] Add option to set initial In-Reply-To/References
From: Josh Triplett @ 2006-07-10 18:42 UTC (permalink / raw)
To: git
In-Reply-To: <5b476cb7f1440875f348842a2ef581ab882e7d0d.1152550451.git.josh@freedesktop.org>
Add the --in-reply-to option to provide a Message-Id for an initial
In-Reply-To/References header, useful for including a new patch series as part
of an existing thread.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
---
Same behavior as git-send-email.
Documentation/git-format-patch.txt | 6 ++++++
builtin-log.c | 10 ++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 81e3a9a..6a805c3 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--no-thread]
[-s | --signoff] [--diff-options] [--start-number <n>]
+ [--in-reply-to=Message-Id]
<since>[..<until>]
DESCRIPTION
@@ -70,6 +71,11 @@ OPTIONS
Do not add In-Reply-To and References headers to make the
second and subsequent mails appear as replies to the first.
+--in-reply-to=Message-Id::
+ Make the first mail (or all the mails with --no-thread) appear as a
+ reply to the given Message-Id, which avoids breaking threads to
+ provide a new patch series.
+
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each
diff --git a/builtin-log.c b/builtin-log.c
index 97df715..d0d70c4 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -243,6 +243,7 @@ int cmd_format_patch(int argc, const cha
int keep_subject = 0;
int ignore_if_in_upstream = 0;
int thread = 1;
+ char *in_reply_to = NULL;
struct diff_options patch_id_opts;
char *add_signoff = NULL;
char message_id[1024];
@@ -314,6 +315,14 @@ int cmd_format_patch(int argc, const cha
ignore_if_in_upstream = 1;
else if (!strcmp(argv[i], "--no-thread"))
thread = 0;
+ else if (!strncmp(argv[i], "--in-reply-to=", 14))
+ in_reply_to = argv[i] + 14;
+ else if (!strcmp(argv[i], "--in-reply-to")) {
+ i++;
+ if (i == argc)
+ die("Need a Message-Id for --in-reply-to");
+ in_reply_to = argv[i];
+ }
else
argv[j++] = argv[i];
}
@@ -371,6 +380,7 @@ int cmd_format_patch(int argc, const cha
if (numbered)
rev.total = total + start_number - 1;
rev.add_signoff = add_signoff;
+ rev.ref_message_id = in_reply_to;
while (0 <= --nr) {
int shown;
commit = list[nr];
--
1.4.1.gf029
^ permalink raw reply related
* [PATCH 2/3] Add option to disable threading headers
From: Josh Triplett @ 2006-07-10 18:41 UTC (permalink / raw)
To: git
In-Reply-To: <5b476cb7f1440875f348842a2ef581ab882e7d0d.1152550451.git.josh@freedesktop.org>
Add a --no-thread option to disable generation of In-Reply-To and References
headers, normally used to make the second and subsequent mails appear as
replies to the first.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
---
As requested by Johannes Schindelin <johannes.schindelin@gmx.de>.
Documentation/git-format-patch.txt | 8 +++++++-
builtin-log.c | 5 ++++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 4ca0014..81e3a9a 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--no-thread]
[-s | --signoff] [--diff-options] [--start-number <n>]
<since>[..<until>]
@@ -35,6 +35,9 @@ they are created in the current working
If -n is specified, instead of "[PATCH] Subject", the first line
is formatted as "[PATCH n/m] Subject".
+The generated mails include In-Reply-To and References headers to make
+the second and subsequent patch mails appear as replies to the first
+mail; --no-thread disables this behavior.
OPTIONS
-------
@@ -63,6 +66,9 @@ OPTIONS
--attach::
Create attachments instead of inlining patches.
+--no-thread::
+ Do not add In-Reply-To and References headers to make the
+ second and subsequent mails appear as replies to the first.
CONFIGURATION
-------------
diff --git a/builtin-log.c b/builtin-log.c
index 9d0cae1..97df715 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -242,6 +242,7 @@ int cmd_format_patch(int argc, const cha
int start_number = -1;
int keep_subject = 0;
int ignore_if_in_upstream = 0;
+ int thread = 1;
struct diff_options patch_id_opts;
char *add_signoff = NULL;
char message_id[1024];
@@ -311,6 +312,8 @@ int cmd_format_patch(int argc, const cha
rev.mime_boundary = argv[i] + 9;
else if (!strcmp(argv[i], "--ignore-if-in-upstream"))
ignore_if_in_upstream = 1;
+ else if (!strcmp(argv[i], "--no-thread"))
+ thread = 0;
else
argv[j++] = argv[i];
}
@@ -373,7 +376,7 @@ int cmd_format_patch(int argc, const cha
commit = list[nr];
rev.nr = total - nr + (start_number - 1);
/* Make the second and subsequent mails replies to the first */
- if (nr == (total - 2)) {
+ if (thread && nr == (total - 2)) {
strncpy(ref_message_id, message_id,
sizeof(ref_message_id));
ref_message_id[sizeof(ref_message_id)-1] = '\0';
--
1.4.1.gf029
^ permalink raw reply related
* [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Josh Triplett @ 2006-07-10 18:41 UTC (permalink / raw)
To: git
In-Reply-To: <20060710162920.GR20191@harddisk-recovery.com>
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>
---
Resend of previous patch as part of new patch series.
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.gf029
^ permalink raw reply related
* Re: can I get only the list of merges?
From: Linus Torvalds @ 2006-07-10 18:09 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Diego Calleja, git
In-Reply-To: <E1FzzlS-0003JE-9C@moooo.ath.cx>
On Mon, 10 Jul 2006, Matthias Lederhofer wrote:
> 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
Well, the above is the "proper" way of doing things, and is efficient and
gives the right answer. However, if you want a _sneaky_ way of doing it,
and want a graphical result, and have a recent version of git, you can
also just do something like
gitk --full-history -- %%nonexistant-file%%
which will give you each commit that changes that nonexistant file (there
should be none ;), and the full commit history for those (ie all the
merges).
(If you use "git log", you also need to add "--parents" while gitk will do
it for you).
Linus
^ permalink raw reply
* [PATCH] git-rev-list: add documentation for --parents, --no-merges
From: Matthias Lederhofer @ 2006-07-10 17:57 UTC (permalink / raw)
To: git
In-Reply-To: <20060710192622.70c51a81.diegocg@gmail.com>
---
Btw: grep -E ' .* ' should work too.
Documentation/git-rev-list.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index e220842..f60eacd 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -56,6 +56,9 @@ OPTIONS
Print the contents of the commit in raw-format; each
record is separated with a NUL character.
+--parents::
+ Print the parents of the commit.
+
--objects::
Print the object IDs of any object referenced by the listed commits.
'git-rev-list --objects foo ^bar' thus means "send me all object IDs
@@ -102,6 +105,9 @@ OPTIONS
--remove-empty::
Stop when a given path disappears from the tree.
+--no-merges::
+ Do not print commits with more than one parent.
+
--not::
Reverses the meaning of the '{caret}' prefix (or lack
thereof) for all following revision specifiers, up to
--
1.4.1.gf157-dirty
^ permalink raw reply related
* 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
* 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: [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
* 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: 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
* [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: 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
* 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: 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: 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
* [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: 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
* 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: 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: 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: 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
* [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
* 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
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