* 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
* [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: 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 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
* [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 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
* 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
* 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
* 2 questions on git-send-email usage
From: moreau francis @ 2006-07-10 19:00 UTC (permalink / raw)
To: git
Hi
I'm wondering what am I supposed to answer when git-send-email
is asking me :
Message-ID to be used as In-Reply-To for the first email?
I'm running this command:
$ git-send-email --no-signed-off-by-cc --no-chain-reply-to --to foo@bar.com --compose /tmp/patch/
to write an introductory message, and all patches are sent as replies to
this introductory email sent.
I also noticed that git-send-email removes the commit message of each
patches I sent, I don't think this is the normal behaviour though. What
am I missing ?
Thanks
Francis
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 19:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86bqrxpai1.fsf@blue.stonehenge.com>
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
> 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. :)
Well, as long as you realize that that automatically means that you have
to walk the whole commit list, and you won't be able to get the
incremental output that git-log and friends normally are able to give?
But this patch should do it. With it,
git log --reverse --pretty=short ORIG_HEAD..
should do what you want.
It is _not_ possible to reverse the "gitk" view with this patch, though,
as this does _not_ reverse parenthood information.
The "--reverse" flag could possibly be renamed.
Linus
---
diff --git a/revision.c b/revision.c
index 7df9089..13a3e40 100644
--- a/revision.c
+++ b/revision.c
@@ -698,6 +698,10 @@ int setup_revisions(int argc, const char
revs->topo_order = 1;
continue;
}
+ if (!strcmp(arg, "--reverse")) {
+ revs->reverse ^= 1;
+ continue;
+ }
if (!strcmp(arg, "--parents")) {
revs->parents = 1;
continue;
@@ -921,7 +925,7 @@ int setup_revisions(int argc, const char
add_pending_object(revs, object, def);
}
- if (revs->topo_order || revs->unpacked)
+ if (revs->topo_order || revs->unpacked || revs->reverse)
revs->limited = 1;
if (revs->prune_data) {
@@ -941,6 +945,19 @@ int setup_revisions(int argc, const char
return left;
}
+static struct commit_list *reverse_commit_list(struct commit_list *p)
+{
+ struct commit_list *result = NULL;
+
+ while (p) {
+ struct commit_list *next = p->next;
+ p->next = result;
+ result = p;
+ p = next;
+ }
+ return result;
+}
+
void prepare_revision_walk(struct rev_info *revs)
{
int nr = revs->pending.nr;
@@ -968,6 +985,8 @@ void prepare_revision_walk(struct rev_in
sort_in_topological_order_fn(&revs->commits, revs->lifo,
revs->topo_setter,
revs->topo_getter);
+ if (revs->reverse)
+ revs->commits = reverse_commit_list(revs->commits);
}
static int rewrite_one(struct rev_info *revs, struct commit **pp)
diff --git a/revision.h b/revision.h
index c010a08..ff6ce44 100644
--- a/revision.h
+++ b/revision.h
@@ -32,6 +32,7 @@ struct rev_info {
remove_empty_trees:1,
simplify_history:1,
lifo:1,
+ reverse:1,
topo_order:1,
tag_objects:1,
tree_objects:1,
^ permalink raw reply related
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 19:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101151470.5623@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> Well, as long as you realize that that automatically means that you
Linus> have to walk the whole commit list, and you won't be able to get the
Linus> incremental output that git-log and friends normally are able to give?
Wow. Yes, I think I can live with that for the application.
Linus> But this patch should do it.
Thanks!
--
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] Avoid C++ comments, use C comments instead
From: Paul Serice @ 2006-07-10 19:14 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20060710114117.GA62514@dspnet.fr.eu.org>
> 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.
I've seen this argument before. Unfortunately it seems reasonable
enough on the surface, and I actually bought into it much to may later
regret.
My experience is that gcc often produces buggy code, and if gcc is not
_the_ compiler for that platform, those bugs do not get fixed.
Specifically, I have had lots of problems with gcc and IRIX.
If you want to write portable code, you have to take into account
different operating systems _and_ different compilers. Writing your
code for just a single compiler is almost as bad as writing your code
for just a single operating system.
Paul Serice
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 19:20 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863bd9p9en.fsf@blue.stonehenge.com>
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
> Linus> Well, as long as you realize that that automatically means that you
> Linus> have to walk the whole commit list, and you won't be able to get the
> Linus> incremental output that git-log and friends normally are able to give?
>
> Wow. Yes, I think I can live with that for the application.
It's a big deal for me, I often end up doing things like
git log -p some-random-file
to see what has happened, and getting the most recent changes basically
instantaneously (rather than waiting for the thing to traverse all of the
history) is a big deal.
If you have a fairly small archive, or you don't use pathname limiting,
the history generation is so fast that you'll never even notice. But with
the kernel, doing something like
git log drivers/serial
takes just over two seconds for me, and if I had to wait for two seconds
before the first data starts arriving, I'd go nuts.
To see this in cold hard numbers:
// Full log
[torvalds@g5 linux]$ time git log drivers/serial > /dev/null
real 0m2.267s
user 0m2.204s
sys 0m0.020s
// Simulate "get the first screenful"
[torvalds@g5 linux]$ time git log drivers/serial | head -25 > /dev/null
real 0m0.054s
user 0m0.048s
sys 0m0.008s
// Simulate "get the first screenful of reverse output"
[torvalds@g5 linux]$ time git log --reverse drivers/serial | head > /dev/null
real 0m2.218s
user 0m2.176s
sys 0m0.044s
and it's the difference between the second and the third case I wanted to
point out.
The difference between getting the first screenful in 0.054 seconds versus
it taking 2.218 seconds is quite noticeable, and one of the things I've
actually spent a fair amount of time on is to make sure that the
incremental output case is the _common_ one for all the normal operations
like "git log -p".
Linus
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 19:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101212410.5623@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>> Wow. Yes, I think I can live with that for the application.
Linus> It's a big deal for me, I often end up doing things like
Linus> git log -p some-random-file
Linus> to see what has happened, and getting the most recent changes basically
Linus> instantaneously (rather than waiting for the thing to traverse all of the
Linus> history) is a big deal.
Well, this is for a "I'm connected to the net right now: please
refresh all of my git mirrors" script:
## (code here to cd to the right dir omitted)
git-fetch
if git-status | grep -v 'nothing to commit'
then echo UPDATE SKIPPED
else
if git-pull . origin | egrep -v 'up-to-date'
then git-log --pretty=short ORIG_HEAD..HEAD | cat
fi
fi
The log is just so I can quickly eyeball the interesting changes. The "cat"
is to keep git-log from starting a pager. (If there's a switch that does
*that* that I've overlooked, that'd be good too.)
--
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: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 19:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101212410.5623@g5.osdl.org>
On Mon, 10 Jul 2006, Linus Torvalds wrote:
>
> The difference between getting the first screenful in 0.054 seconds versus
> it taking 2.218 seconds is quite noticeable, and one of the things I've
> actually spent a fair amount of time on is to make sure that the
> incremental output case is the _common_ one for all the normal operations
> like "git log -p".
Side note: the good news is that even with the reverse generation, if you
also generate _diffs_, the diffs will be generated incrementally, so:
// Full "git log" with diffs
[torvalds@g5 linux]$ time git log -p drivers/serial > /dev/null
real 0m3.409s
user 0m3.360s
sys 0m0.052s
// First screenful of reverse git log with diffs
[torvalds@g5 linux]$ time git log -p --reverse drivers/serial | head -25 > /dev/null
real 0m2.228s
user 0m2.216s
sys 0m0.012s
// First screenful of regular git log with diffs
[torvalds@g5 linux]$ time git log -p drivers/serial | head -25 > /dev/null
real 0m0.038s
user 0m0.036s
sys 0m0.004s
here you can see how the full "git log -p" is obviously more expensive
than the full "git log" was (the diff generation adds about a second to
the full time), but because the diffs are generated incrementally as they
are shown even with "--reverse", the first screenful of the "--reverse"
case didn't get any more expensive, because we didn't generate all the
diffs up-front, just the ones we needed.
And the first screenfull of the normal case obviously stays really fast,
because both history generation _and_ diff generation is all on-the-fly.
Linus
^ permalink raw reply
* [PATCH] Allow usage of git-svnimport's -d/-D options with https
From: Diego 'Flameeyes' Pettenò @ 2006-07-10 19:34 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 384 bytes --]
While importing an SVN https repository (from SourceForge), I noticed that the
svnimport script just accepts http as url scheme to use -d/-D options, while
it seems to work fine with https too. The attached patch fixes that for me.
HTH,
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
[-- Attachment #1.2: git-svnimport-https.patch --]
[-- Type: text/x-diff, Size: 426 bytes --]
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 26dc454..9a69369 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -209,7 +209,7 @@ if($opt_d or $opt_D) {
} else {
$svn_dir = "";
}
- if ($svn_url->scheme eq "http") {
+ if ($svn_url->scheme eq "http" or $svn_url->scheme eq "https") {
use LWP::UserAgent;
$lwp_ua = LWP::UserAgent->new(keep_alive => 1, requests_redirectable => []);
} else {
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 20:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzbhntxu.fsf@blue.stonehenge.com>
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
> then git-log --pretty=short ORIG_HEAD..HEAD | cat
> The log is just so I can quickly eyeball the interesting changes. The "cat"
> is to keep git-log from starting a pager. (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)
Just do
PAGER= git log --pretty=short ORIG_HEAD..HEAD
instead.
And if you didn't know about "git shortlog" already, I personally actually
find it easier to read
git log --no-merges ORIG_HEAD.. | git shortlog
which orders things by author instead. It also reverses the log messages
as it does so, so each author will have the one-liners sorted oldest to
newest the way you wanted to (so you do _not_ want to pass --reverse to
that git-shortlog invocation).
Linus
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 20:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101304210.5623@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> And if you didn't know about "git shortlog" already, I personally actually
Linus> find it easier to read
Linus> git log --no-merges ORIG_HEAD.. | git shortlog
Linus> which orders things by author instead. It also reverses the log
Linus> messages as it does so, so each author will have the one-liners sorted
Linus> oldest to newest the way you wanted to (so you do _not_ want to pass
Linus> --reverse to that git-shortlog invocation).
See -- I *knew* there was a shorter way.
Looks like I owe you lunch. (Again? :)
--
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] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 20:24 UTC (permalink / raw)
To: Paul Serice; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <44B2A709.8020500@serice.net>
On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:
> If you want to write portable code, you have to take into account
> different operating systems _and_ different compilers. Writing your
> code for just a single compiler is almost as bad as writing your code
> for just a single operating system.
Hmmm, that was not so much about gcc-specific code than which kind of
C you want to code to, the one from 1973, the one from 1989 or the one
from 1999? I personally don't have much sympathy for the OS vendors
giving you an older standard C compiler and selling you the up-to-date
one.
OG.
^ permalink raw reply
* Re: [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Jakub Narebski @ 2006-07-10 20:25 UTC (permalink / raw)
To: git
In-Reply-To: <1152549787.8890.36.camel@josh-work.beaverton.ibm.com>
Josh Triplett wrote:
> 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.
git-send-email has three ways of sending files:
1. Chain Reply-To:, where every patch refers to earlier in series.
Ugly in threaded mail/news readers, harder to comment, but there is
no way to loose the order (e.g. if patches are not numbered *blush*)
2. No chain reply-to, with cover letter introducing patch series.
IMHO nicest format... provided there are no errors nor mistakes.
3. No chain reply-to, without cover letter. I presonally don't like
this format, YMMV.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Junio C Hamano @ 2006-07-10 20:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzbhntxu.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Well, this is for a "I'm connected to the net right now: please
> refresh all of my git mirrors" script:
>
> ## (code here to cd to the right dir omitted)
> git-fetch
> if git-status | grep -v 'nothing to commit'
git-status exits non-zero for "nothing to commit" case, so do
not grep its output, but check the status of the command, to see
if your tree is in a good shape to do a pull.
> then echo UPDATE SKIPPED
> else
> if git-pull . origin | egrep -v 'up-to-date'
> then git-log --pretty=short ORIG_HEAD..HEAD | cat
> fi
> fi
>
> The log is just so I can quickly eyeball the interesting changes.
Do we not leave ORIG_HEAD when we are already up-to-date? If so
that would be confusing... No, we do leave ORIG_HEAD no matter
what, so you do not have to have this inner if to grep
up-to-date (on the other hand, you might want to do intelligent
things when git-pull fails). So just drop the if and say
something like:
else
PAGER= ; export PAGER
git pull . origin &&
git log --pretty ORIG_HEAD..HEAD |
git shortlog
fi
> The "cat"
> is to keep git-log from starting a pager. (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)
BTW,
PAGER=cat
export PAGER
This should work as more efficiently -- see pager.c ;-)
^ permalink raw reply
* Re: 2 questions on git-send-email usage
From: Jakub Narebski @ 2006-07-10 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <20060710190010.94648.qmail@web25808.mail.ukl.yahoo.com>
moreau francis wrote:
> I'm wondering what am I supposed to answer when git-send-email
> is asking me :
>
> Message-ID to be used as In-Reply-To for the first email?
>
> I'm running this command:
>
> $ git-send-email --no-signed-off-by-cc --no-chain-reply-to --to \
> foo@bar.com --compose /tmp/patch/
>
> to write an introductory message, and all patches are sent as replies to
> this introductory email sent.
Empty string (i.e. RET) should do if you don't want to attach your series of
patches somewhere in existing thread.
> I also noticed that git-send-email removes the commit message of each
> patches I sent, I don't think this is the normal behaviour though. What
> am I missing ?
Are patches formatted using git-format-patch?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsgdb40s.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> ## (code here to cd to the right dir omitted)
>> git-fetch
>> if git-status | grep -v 'nothing to commit'
Junio> git-status exits non-zero for "nothing to commit" case, so do
Junio> not grep its output, but check the status of the command, to see
Junio> if your tree is in a good shape to do a pull.
No, this is deliberate. I want to see nothing if we're up to date, but if
not, I want to see *everything else* that git-status said. This nice "grep
-v" does precisely the right thing.
Junio> Do we not leave ORIG_HEAD when we are already up-to-date? If so
Junio> that would be confusing... No, we do leave ORIG_HEAD no matter
Junio> what, so you do not have to have this inner if to grep
Junio> up-to-date (on the other hand, you might want to do intelligent
Junio> things when git-pull fails). So just drop the if and say
Junio> something like:
Junio> else
Junio> PAGER= ; export PAGER
Junio> git pull . origin &&
Junio> git log --pretty ORIG_HEAD..HEAD |
Junio> git shortlog
Junio> fi
However, this is good to know.
--
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
* Items not covered by repository-layout.txt
From: Jakub Narebski @ 2006-07-10 20:46 UTC (permalink / raw)
To: git
I have noticed few files in .git/ directory which currently are not covered
(and neither is their format) by Documentation/repository-layout.txt
* COMMIT_EDITMSG (temporary file, when I decided during writing commit
message that I should change something before commit)
* FETCH_HEAD (format?)
* HEAD, ORIG_HEAD and probably some other *_HEAD
* .tmp-vtag (I'm not sure what have left that, probably git-verify-tag
broken due to lack of signing PGP keys)
* description file
I know they are fairly obvious, but having everything that one could fing in
his/her git-core managed .git repository would be nice...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* git-update-ref (reflog) uses bogus author ident information
From: Jakub Narebski @ 2006-07-10 20:52 UTC (permalink / raw)
To: git
git-log reports
commit 059111c9381ce1444d17c8fc35606b0aa417ca42
Author: Jakub Narebski <jnareb@gmail.com>
Date: Sat Jul 8 18:52:35 2006 +0200
configure.ac vertical whitespace usage cleanup
git-var -l shows:
GIT_COMMITTER_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
GIT_AUTHOR_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
BUT in git/.git/logs/refs/heads/autoconf I have (broken into lines):
fe7b45a419ae62ed96148d98f6aba8710a6f6245
059111c9381ce1444d17c8fc35606b0aa417ca42
Jakub Narebski <jnareb@roke.D-201> 1152377555 +0200
commit: configure.ac vertical whitespace usage cleanu
where "roke.D-201" are results of "hostname -f" on my computer, and are
suitable _only_ for my small private local network.
Bug or a feature?
I use git 1.4.0.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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