* Re: [PATCH] urls.txt: Use substitution to escape square brackets
From: Alp Toker @ 2006-07-15 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonas Fonseca
In-Reply-To: <7v3bd3ois4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Alp is right -- the comments in [attributes] section after the
> definition do appear in the output, even with asciidoc 7.1.2, so
> here is a replacement proposal from me.
>
> The one by Alp is an easy work-around, but I do not want to
> worry about potential, unintended, breakages that might be
> caused by changing delimited blocks to literal paragraphs (and
> it changes the resulting rendering from the original).
>
> -- >8 --
> From: Jonas Fonseca <fonseca@diku.dk>
>
> This changes "[user@]" to use {startsb} and {endsb} to insert [ and ],
> similar to how {caret} is used in git-rev-parse.txt.
>
> [jc: Removed a well-intentioned comment that broke the final
> formatting from the original patch. While we are at it,
> updated the paragraph that claims to be equivalent to the
> section that was updated earlier without making matching
> changes.]
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Alp Toker <alp@atoker.com>
^ permalink raw reply
* [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Josh Triplett @ 2006-07-15 0:48 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>
---
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.gd2cb0
^ permalink raw reply related
* [PATCH] Add option to set initial In-Reply-To/References
From: Josh Triplett @ 2006-07-15 0:49 UTC (permalink / raw)
To: git
In-Reply-To: <5b476cb7f1440875f348842a2ef581ab882e7d0d.1152924479.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>
---
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 305bd79..67425dc 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] [--thread]
[-s | --signoff] [--diff-options] [--start-number <n>]
+ [--in-reply-to=Message-Id]
<since>[..<until>]
DESCRIPTION
@@ -72,6 +73,11 @@ OPTIONS
subsequent mails appear as replies to the first. Also generates
the Message-Id header to reference.
+--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 4572295..3ef7b8e 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 = 0;
+ 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], "--thread"))
thread = 1;
+ 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.gd2cb0
^ permalink raw reply related
* [PATCH] Add option to enable threading headers
From: Josh Triplett @ 2006-07-15 0:49 UTC (permalink / raw)
To: git
In-Reply-To: <5b476cb7f1440875f348842a2ef581ab882e7d0d.1152924479.git.josh@freedesktop.org>
Add a --thread option to enable generation of In-Reply-To and References
headers, used to make the second and subsequent mails appear as replies to the
first.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
---
Documentation/git-format-patch.txt | 10 +++++++++-
builtin-log.c | 21 +++++++++++++--------
2 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 4ca0014..305bd79 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] [--thread]
[-s | --signoff] [--diff-options] [--start-number <n>]
<since>[..<until>]
@@ -35,6 +35,10 @@ 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".
+If given --thread, git-format-patch will generate In-Reply-To and
+References headers to make the second and subsequent patch mails appear
+as replies to the first mail; this also generates a Message-Id header to
+reference.
OPTIONS
-------
@@ -63,6 +67,10 @@ OPTIONS
--attach::
Create attachments instead of inlining patches.
+--thread::
+ Add In-Reply-To and References headers to make the second and
+ subsequent mails appear as replies to the first. Also generates
+ the Message-Id header to reference.
CONFIGURATION
-------------
diff --git a/builtin-log.c b/builtin-log.c
index 9d0cae1..4572295 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 = 0;
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], "--thread"))
+ thread = 1;
else
argv[j++] = argv[i];
}
@@ -373,15 +376,17 @@ 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)) {
- 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;
+ if (thread) {
+ 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;
}
- 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);
--
1.4.1.gd2cb0
^ permalink raw reply related
* [PATCH 1/2] Quote all calls to GIT_CONF_APPEND_LINE
From: Pavel Roskin @ 2006-07-15 5:29 UTC (permalink / raw)
To: git
From: Pavel Roskin <proski@gnu.org>
Not quoting macro arguments that contain other macros is a big no-no in
Autoconf. It can break at any time.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
configure.ac | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2932d0e..c1f7751 100644
--- a/configure.ac
+++ b/configure.ac
@@ -39,30 +39,30 @@ # Define NO_OPENSSL environment variable
# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
AC_CHECK_LIB([ssl], [SHA1_Init],[],
[AC_CHECK_LIB([crypto], [SHA1_INIT],
- GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease),
- GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease))])
+ [GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease)],
+ [GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease)])])
#
# Define NO_CURL if you do not have curl installed. git-http-pull and
# git-http-push are not built, and you cannot use http:// and https://
# transports.
AC_CHECK_LIB([curl], [curl_global_init],[],
-GIT_CONF_APPEND_LINE(NO_CURL=YesPlease))
+[GIT_CONF_APPEND_LINE(NO_CURL=YesPlease)])
#
# Define NO_EXPAT if you do not have expat installed. git-http-push is
# not built, and you cannot push using http:// and https:// transports.
AC_CHECK_LIB([expat], [XML_ParserCreate],[],
-GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease))
+[GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease)])
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
AC_CHECK_LIB([c], [iconv],[],
[AC_CHECK_LIB([iconv],[iconv],
- GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease),[])])
+ [GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease)],[])])
#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
AC_CHECK_LIB([c], [socket],[],
[AC_CHECK_LIB([socket],[socket],
- GIT_CONF_APPEND_LINE(NEEDS_SOCKET=YesPlease),[])])
+ [GIT_CONF_APPEND_LINE(NEEDS_SOCKET=YesPlease)],[])])
## Checks for header files.
@@ -73,19 +73,19 @@ AC_MSG_NOTICE([CHECKS for typedefs, stru
#
# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
AC_CHECK_MEMBER(struct dirent.d_ino,[],
-GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease),
+[GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease)],
[#include <dirent.h>])
#
# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks
# d_type in struct dirent (latest Cygwin -- will be fixed soonish).
AC_CHECK_MEMBER(struct dirent.d_type,[],
-GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease),
+[GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease)],
[#include <dirent.h>])
#
# Define NO_SOCKADDR_STORAGE if your platform does not have struct
# sockaddr_storage.
AC_CHECK_TYPE(struct sockaddr_storage,[],
-GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE=YesPlease),
+[GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE=YesPlease)],
[#include <netinet/in.h>])
@@ -95,15 +95,15 @@ AC_MSG_NOTICE([CHECKS for library functi
#
# Define NO_STRCASESTR if you don't have strcasestr.
AC_CHECK_FUNC(strcasestr,[],
-GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease))
+[GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease)])
#
# Define NO_STRLCPY if you don't have strlcpy.
AC_CHECK_FUNC(strlcpy,[],
-GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease))
+[GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease)])
#
# Define NO_SETENV if you don't have setenv in the C library.
AC_CHECK_FUNC(setenv,[],
-GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease))
+[GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease)])
#
# Define NO_MMAP if you want to avoid mmap.
#
^ permalink raw reply related
* [PATCH 2/2] Set datarootdir in config.mak.in
From: Pavel Roskin @ 2006-07-15 5:29 UTC (permalink / raw)
To: git
In-Reply-To: <20060715052919.19165.19665.stgit@dv.roinet.com>
From: Pavel Roskin <proski@gnu.org>
Autoconf 2.60 expresses datadir in terms of datarootdir. If datarootdir
is not substituted, configure issues a warning and uses a compatibility
substitution for datadir.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
config.mak.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 89520eb..04f508a 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -10,6 +10,7 @@ prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
#gitexecdir = @libexecdir@/git-core/
+datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates/
GIT_PYTHON_DIR = @datadir@/git-core/python
^ permalink raw reply related
* [ANNOUNCE qgit-1.4]
From: Marco Costalba @ 2006-07-15 7:31 UTC (permalink / raw)
To: GIT list, linux-kernel
This is qgit-1.4
With qgit you will be able to browse revision histories, view patch content
and changed files, graphically following different development branches.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- Associate commands sequences, scripts and anything else executable
to a custom action. Actions can be run from menu and corresponding
output is grabbed by a terminal window.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry
picking single modified files.
NEW IN THIS RELEASE
To let user to quickly invoke native git commands from the menu bar a
'custom action' build dialog has been added.
It is possible to associate commands sequences, scripts and anything
else executable to a custom action, give it a name and then call from
menu when needed. The corresponding output is grabbed by a terminal
window.
An action can also ask for command line arguments before to run so
to allow for maximum flexibility.
Just to name a few, I have created some stuff like 'git pull', make,
'make install', git pull with input argument and so on, and I've found
them quite useful.
There is also some work on near tag information and better tag markers,
see changelog for details.
Please note that you will need git 1.4.0 or newer.
DOWNLOAD
Tarball is
http://prdownloads.sourceforge.net/qgit/qgit-1.4.tar.bz2?download
Git archive is
git://git.kernel.org/pub/scm/qgit/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
INSTALLATION
git 1.4.0 is required.
To install from tarball:
./configure
make
make install-strip
To install from git archive:
autoreconf -i
./configure
make
make install-strip
Or check the shipped README for detailed information.
CHANGELOG from 1.3
- added custom action support
- use markers for refs instead of background color in short log line
- added "Copy link sha1" context menu entry in revision description
- CTRL+right click on a revision to toggle 'diff to selected sha' mode
- added support for applying patches to working directory only
- better diagnostic when a command fails to start
- show branches that revision belongs to
- show near tags information in revision description
- show children list in revision description
- added a tool button to highlight filter matches instead of filtering
For a complete changelog see shipped ChangeLog file or git repository
revision's history
Marco
^ permalink raw reply
* [PATCH] Make asciidoc related rules depend on asciidoc.conf
From: Jonas Fonseca @ 2006-07-15 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alp Toker
In-Reply-To: <7v3bd3ois4.fsf@assigned-by-dhcp.cox.net>
Any rule running asciidoc, whether using -f asciidoc.conf or not,
will read asciidoc.conf. Make such rules depend on asciidoc.conf.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Junio C Hamano <junkio@cox.net> wrote Fri, Jul 14, 2006:
> Alp is right -- the comments in [attributes] section after the
> definition do appear in the output, even with asciidoc 7.1.2, so
> here is a replacement proposal from me.
Am using the same setup as Alp (AsciiDoc 7.0.2 on Ubuntu Dapper), so I
was a bit curious that I could not see that. So I guess I compiled the
docs first and later decided to add the comments which then didn't cause
a recompilation.
I don't know if there should be a dependency on asciidoc.conf in every
rule calling asciidoc. Could be annoying if you are only making a minor
change.
---
diff --git a/Documentation/Makefile b/Documentation/Makefile
index cc83610..ce6c6cf 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -76,18 +76,18 @@ README: ../README
clean:
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
-%.html : %.txt
+%.html : %.txt asciidoc.conf
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
%.1 %.7 : %.xml
xmlto -m callouts.xsl man $<
-%.xml : %.txt
+%.xml : %.txt asciidoc.conf
asciidoc -b docbook -d manpage -f asciidoc.conf $<
git.html: git.txt README
-glossary.html : glossary.txt sort_glossary.pl
+glossary.html : glossary.txt sort_glossary.pl asciidoc.conf
cat $< | \
perl sort_glossary.pl | \
asciidoc -b xhtml11 - > glossary.html
@@ -97,12 +97,12 @@ howto-index.txt: howto-index.sh $(wildca
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
mv $@+ $@
-$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
+$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt asciidoc.conf
asciidoc -b xhtml11 $*.txt
WEBDOC_DEST = /pub/software/scm/git/docs
-$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
+$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt asciidoc.conf
rm -f $@+ $@
sed -e '1,/^$$/d' $? | asciidoc -b xhtml11 - >$@+
mv $@+ $@
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Petr Baudis @ 2006-07-15 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh Triplett, git
In-Reply-To: <7vwtagnfsk.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 14, 2006 at 09:32:27PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Josh Triplett <josht@us.ibm.com> writes:
>
> > ..., but you
> > suggested that you didn't mind having threading as the default.
>
> Did I? ... then that was either a mistake or miscommunication.
>
> I do mind changing the default output. I do not mind threading
> as the default ONLY IF user asks for output with these extra
> headers.
What's the big deal? It's not like we didn't change those things in the
past if it doesn't horribly break everything and the new behaviour is
clearly more sensible.
It would be good to know what the general policy on this is nowadays.
--
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 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Junio C Hamano @ 2006-07-15 8:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060715074532.GF13776@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Fri, Jul 14, 2006 at 09:32:27PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Josh Triplett <josht@us.ibm.com> writes:
>>
>> > ..., but you
>> > suggested that you didn't mind having threading as the default.
>>
>> Did I? ... then that was either a mistake or miscommunication.
>>
>> I do mind changing the default output. I do not mind threading
>> as the default ONLY IF user asks for output with these extra
>> headers.
>
> What's the big deal? It's not like we didn't change those things in the
> past if it doesn't horribly break everything and the new behaviour is
> clearly more sensible.
While I agree to the whole three lines, I do not think adding the
Message-Id and In-Reply-To header lines by default is more
sensible at all.
Adding phoney Message-Id to format-patch output makes some sense
only when you are sending messages, and if I recall original
"motive" message correctly only with git-imap-send. We do not
need this for git-send-email, since it can do its own threading.
Although I've already accepted the series to "next", now after
you brought up the issue, I started to suspect that it might
even make sense not to do this in format-patch but make it a
responsibility for MUA-looking commands instead.
More importantly, format-patch is used to extract patches into
separate files (I do that myself often, and I think Andrew
Morten uses it to extract stuff from git-maintained trees). In
such a case having phoney Message-Id is simply a waste. Running
"head -n X 0*.txt" now needs one or two larger X to view the
same information, and fewer patches fit on the screen than
before. So the new behaviour, if it were not optional, is
clearly less useful for such purpose.
It could even be confusing and inviting mistakes. When quoting
a change from somebody that was sent in an e-mail to the list,
giving its Message-Id is often helpful to others who want to go
to the source themselves, but if a file that was generated by
format-patch by default carries a phoney Message-Id, it can be
mistakenly used in such a quote.
^ permalink raw reply
* My interview for "FLOSS weekly"
From: Randal L. Schwartz @ 2006-07-15 8:16 UTC (permalink / raw)
To: git
Git was mentioned right at the end of http://www.twit.tv/floss9
Linus was mentioned at least a few times in the middle. :)
--
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: [ANNOUNCE qgit-1.4]
From: Jakub Narebski @ 2006-07-15 9:20 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <e5bfff550607150031g5cca3d02h61aa6e6565aad132@mail.gmail.com>
Marco Costalba wrote:
> - use markers for refs instead of background color in short log line
Thanks a lot. That was what I was lacking in qgit. I have not yet downloaded
qgit-1.4,... but perhaps having both background color for branch tips and
markers for both branches (heads) and tags would be best of both options.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Strange output of 'git diff <revision1>:<file> <revision2>:<file>'
From: Jakub Narebski @ 2006-07-15 10:20 UTC (permalink / raw)
To: git
git diff output for files specified by revision is somewhat unexpected.
$ git diff <revision_1>:<file> <revision_2>:<file>
outputs the following diff metainfo
diff --git a/<revision_2>:<file> b/<revision_2>:<file>
index 5eabe06..2e87de4 100644
--- a/<revision_2>:<file>
+++ b/<revision_2>:<file>
Is it intended, or is it a bug? Looks like a bug to me...
git 1.4.0 (git-core-1.4.0-1.fc4 by Fedora Project).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] use the path as name from the revision:path syntax in setup_revisions
From: Matthias Lederhofer @ 2006-07-15 12:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e9aff7$nk1$1@sea.gmane.org>
---
Jakub Narebski <jnareb@gmail.com> wrote:
> git diff output for files specified by revision is somewhat unexpected.
>
> $ git diff <revision_1>:<file> <revision_2>:<file>
>
> outputs the following diff metainfo
>
> diff --git a/<revision_2>:<file> b/<revision_2>:<file>
> index 5eabe06..2e87de4 100644
> --- a/<revision_2>:<file>
> +++ b/<revision_2>:<file>
>
> Is it intended, or is it a bug? Looks like a bug to me...
I guess the revision should not be there. Here is a patch to remove
it.
<matled> is there a name for 'revision:path' to specify a file at a
certain revision?
<jdl> "That weird syntax, you know."
<matled> get_path_out_of_the_weird_syntax(const char *s)
<matled> you know :)
<jdl> That should do it!
Could someone please come up with a nice name for the function?
Without knowing a name for the '<revision>:<path>' syntax I can only
think of get_path or similar names and this is much too generic imo.
---
cache.h | 1 +
revision.c | 2 ++
sha1_name.c | 12 ++++++++++++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index d433d46..7da1c5c 100644
--- a/cache.h
+++ b/cache.h
@@ -249,6 +249,7 @@ #define DEFAULT_ABBREV 7
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
+extern char *get_path_out_of_the_weird_syntax(const char *str);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
extern int read_ref(const char *filename, unsigned char *sha1);
extern const char *resolve_ref(const char *path, unsigned char *sha1, int);
diff --git a/revision.c b/revision.c
index 874e349..fbd1458 100644
--- a/revision.c
+++ b/revision.c
@@ -908,6 +908,8 @@ int setup_revisions(int argc, const char
if (!seen_dashdash)
verify_non_filename(revs->prefix, arg);
object = get_reference(revs, arg, sha1, flags ^ local_flags);
+ if (object->type == OBJ_BLOB || object->type == OBJ_TREE)
+ arg = get_path_out_of_the_weird_syntax(arg);
add_pending_object(revs, object, arg);
}
if (show_merge)
diff --git a/sha1_name.c b/sha1_name.c
index 5fe8e5d..718ce1b 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -543,3 +543,15 @@ int get_sha1(const char *name, unsigned
}
return ret;
}
+
+/* get the path from sha1:path, :path and :[0-3]:path */
+char *get_path_out_of_the_weird_syntax(const char *str)
+{
+ if (strlen(str) >= 3 &&
+ str[0] == ':' && str[2] == ':' &&
+ str[1] >= '0' && str[2] <= '3')
+ return((char*)(str+3));
+ if (index(str, ':'))
+ return index(str, ':')+1;
+ return str;
+}
--
1.4.1.ga3e6
^ permalink raw reply related
* [PATCH] array index mixup
From: Matthias Lederhofer @ 2006-07-15 12:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <e9aff7$nk1$1@sea.gmane.org>
---
Jakub Narebski <jnareb@gmail.com> wrote:
> git diff output for files specified by revision is somewhat unexpected.
>
> $ git diff <revision_1>:<file> <revision_2>:<file>
>
> outputs the following diff metainfo
>
> diff --git a/<revision_2>:<file> b/<revision_2>:<file>
> index 5eabe06..2e87de4 100644
> --- a/<revision_2>:<file>
> +++ b/<revision_2>:<file>
>
> Is it intended, or is it a bug? Looks like a bug to me...
I dunno if this is really an index mixup or was intended. If this is
intended please add a comment what it's for. (Without this you get
rename information, perhaps this is the reason.)
---
builtin-diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index cb38f44..4d43a5c 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -136,7 +136,7 @@ static int builtin_diff_blobs(struct rev
stuff_change(&revs->diffopt,
mode, mode,
blob[1].sha1, blob[0].sha1,
- blob[0].name, blob[0].name);
+ blob[1].name, blob[0].name);
diffcore_std(&revs->diffopt);
diff_flush(&revs->diffopt);
return 0;
--
1.4.1.ga3e6
^ permalink raw reply related
* :), Pan-slavonism
From: Elliott Gagnon @ 2006-07-15 18:26 UTC (permalink / raw)
To: git-commits-head-owner
Even if you have no erectin problems SOFT CIAGLIS
would help you to make BETTER SE6X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER3ECTION during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISCPOUNT OFER!
http://1XUV88ehdhvqwlejr881dq81v88q.snowkdj.com/
==========
the fishing boats were specks in the flat blue water, Breakfast Flock was
"Well, I don't either. That's true. But now for the First time we know
science fiction called swords-and-sorcery. And among its highest virtues is
five hours to a stalker? A snap. How about twelve? Or how about two days? If
When they could see again, Chiang was gone.
He didn't answer. The water was making a lot of noise.
He spoke of very simple things - that it is right for a guil to fly,
windows weren't broken. Only they were so dirty that they looked blind. At
^ permalink raw reply
* [PATCH] git-svn: don't check for migrations/upgrades on commit-diff
From: Eric Wong @ 2006-07-15 14:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
Unlike other git-svn commands, commit-diff is intended to
operate without needing any additional metadata inside .git
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 4530ffe..89ad840 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -147,7 +147,7 @@ init_vars();
load_authors() if $_authors;
load_all_refs() if $_branch_all_refs;
svn_compat_check() unless $_use_lib;
-migration_check() unless $cmd =~ /^(?:init|rebuild|multi-init)$/;
+migration_check() unless $cmd =~ /^(?:init|rebuild|multi-init|commit-diff)$/;
$cmd{$cmd}->[0]->(@ARGV);
exit 0;
--
1.4.1.gb805
^ permalink raw reply related
* The newest Every man wishes it. Revel in
From: Kurt @ 2006-07-15 18:24 UTC (permalink / raw)
To: gord
Yo!
Have you ever wanted to impress your girl?
But some of us think it’s impossible
Take this and your woman will be speechless
Come in: http://lingvert.com/gall/
The prices are really low and the quality it truly very high!
^ permalink raw reply
* Re: disable the compile-flags-changed check
From: Matthias Lederhofer @ 2006-07-15 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2gsotv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>
> > Is there any way to disable the "the compile flags have changed,
> > recompile everything" check? I want to built with another prefix than
> > installing to create a tarball I copy to other machines. Is there any
> > way to do this?
>
> Perhaps
>
> DESTDIR=/var/tmp/ make prefix=/usr install
>
> is what you are looking for?
Thanks, this works.
^ permalink raw reply
* Re: disable the compile-flags-changed check
From: Junio C Hamano @ 2006-07-15 21:48 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G1qAS-0005gv-P7@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Matthias Lederhofer <matled@gmx.net> writes:
>>
>> > Is there any way to disable the "the compile flags have changed,
>> > recompile everything" check? I want to built with another prefix than
>> > installing to create a tarball I copy to other machines. Is there any
>> > way to do this?
>>
>> Perhaps
>>
>> DESTDIR=/var/tmp/ make prefix=/usr install
>>
>> is what you are looking for?
>
> Thanks, this works.
By the way, in older days before binary distributions have
become _the_ way for the end users to get programs, "install
into a saparate place for tarring up" needed to be custom job
per package, because Makefiles of many packages were not set up
to easily allow it (like DESTDIR= stuff). These days, allowing
it is almost a requirement in order to make binary distros'
lives easier, so if a program is packaged for some binary
distros (say, RPM or deb), often the easiest way to figure out
the answer to your question is to see how they build their
packages out of the source.
^ permalink raw reply
* git merge performance problem..
From: Linus Torvalds @ 2006-07-15 21:48 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Junio, I think there is something wrong with git-merge. It sometimes takes
up to ten seconds, and it's stuck at the
git-show-branch --independent "$head" "$@"
call.
I don't know quite what that thing is even meant to do (we do already know
the parents, why do we do something special here?) but even apart from
that, the whole thing must be doing something seriously wrong, since it
takes so long. Does it check the whole commit history?
Linus
^ permalink raw reply
* * LIVE DEALERS & Fast Downloads
From: Basil @ 2006-07-16 2:35 UTC (permalink / raw)
To: git
Halo!
Hi Rolelr is the best in the industry because we offer:
* 24-hour support
* LIVE DEALERS & Fast Downloads
* Hi Roller Cassino is one of the oldest and most established online cassino.
* Several options that allow you to control the playing environment
Give us a try! Remember, Free $88.800 is ON THE HOUSE!
How can you possibly turn that down?
Start Winning Now!
http://uveltord.com/d1/check/
It nah good to shove yuh foot in every stocking. Moon ah run till daylight ketch am. A celebrity is someone who works hard all his life to become known and then wears dark glasses to avoid being recognized. Half a loaf is better than no bread Lookers on see most of the game
^ permalink raw reply
* Re: git merge performance problem..
From: Junio C Hamano @ 2006-07-16 3:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607151445270.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, I think there is something wrong with git-merge. It sometimes takes
> up to ten seconds, and it's stuck at the
>
> git-show-branch --independent "$head" "$@"
>
> call.
>
> I don't know quite what that thing is even meant to do (we do already know
> the parents, why do we do something special here?) but even apart from
> that, the whole thing must be doing something seriously wrong, since it
> takes so long. Does it check the whole commit history?
The code is to cull redundant parents primarily in octopus and
is not strictly necessary. Can I have the $head and $@ (the
other merge parents, but in your case you never do an octopus so
that would be the other branch head) to see what is going on
please? It should not descend down the history all the way but
with the recent changes to the object marking/unmarking code it
is possible we might have broken something.
^ permalink raw reply
* Enjoy the newest Onlline Casino. Go and Play It
From: Erica @ 2006-07-16 3:19 UTC (permalink / raw)
To: git
Hi
Online Casino wwith 85+ games. Play It Now! http://wegast.com/d1/ace/
Wisdom crieth without; she uttereth her voice in the streets. Empty sacks will never stand upright
^ permalink raw reply
* Re: git merge performance problem..
From: Junio C Hamano @ 2006-07-16 4:24 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j2eme3u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Junio, I think there is something wrong with git-merge. It sometimes takes
>> up to ten seconds, and it's stuck at the
>>
>> git-show-branch --independent "$head" "$@"
>>
>> call.
>>
>> I don't know quite what that thing is even meant to do (we do already know
>> the parents, why do we do something special here?) but even apart from
>> that, the whole thing must be doing something seriously wrong, since it
>> takes so long. Does it check the whole commit history?
>
> The code is to cull redundant parents primarily in octopus and
> is not strictly necessary.
Wrong. The commit log says it was to remove redundant parents;
I think this as a reaction after seeing a few incorrectly made
merge commits in the kernel archive.
> ..., but in your case you never do an octopus so
> that would be the other branch head) to see what is going on
> please?
Disregard this request please. I see a few commits that this
step takes a long time to process in the kernel archive. The
last merge before you left to Ottawa was one of them.
b5032a5 48ce8b0
I do not think we need to do the --independent check there
especially for two-head cases because we have already done
fast-forward and up-to-date tests when we get there, so let's
revert that part from commit 6ea2334.
-- >8 --
diff --git a/git-merge.sh b/git-merge.sh
index 24e3b50..ee41077 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -314,7 +314,11 @@ # If we have a resulting tree, that mean
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ parents="-p $head"
+ for remote
+ do
+ parents="$parents -p $remote"
+ done
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge $result_commit, made by $wt_strategy."
dropsave
^ permalink raw reply related
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