* Re: [PATCH 2/5] daemon: if one of the standard fds is missing open it to /dev/null
From: Uwe Zeisberger @ 2006-07-13 14:36 UTC (permalink / raw)
To: Edgar Toernig, git, Matthias Lederhofer
In-Reply-To: <E1G11nq-00076g-Aa@moooo.ath.cx>
Hello Matthias,
(Do you know you set the Mail-Followup-To Header? That is annoying.)
> devnull = open("/dev/null", O_RDWR, 0);
> while (devnull != -1 && devnull < 2)
> dup(devnull);
You mean
devnull = dup(devnull);
, don't you?
> if (devnull == -1)
> die("..");
> close(devnull);
Best regards
Uwe
--
Uwe Zeisberger
primes where sieve (p:xs) = [ x | x<-xs, x `rem` p /= 0 ]; \
primes = map head (iterate sieve [2..])
^ permalink raw reply
* Re: [PATCH 2/5] daemon: if one of the standard fds is missing open it to /dev/null
From: Morten Welinder @ 2006-07-13 15:37 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G0znB-0002IO-61@moooo.ath.cx>
> + if (devnull == -1 &&
> + (devnull = open("/dev/null", O_RDWR, 0)) == -1)
> + die("open /dev/null failed: %s", strerror(errno));
> + if (dup2(devnull, i) != i)
> + die("dup2 failed: %s", strerror(errno));
"die" probably won't work well at this point.
Should git (and most other programs) do something like this in general?
fprintf will happily write to fd=2 regardless of whether that is some critical
file you opened.
Morten
^ permalink raw reply
* Re: [PATCH 2/5] daemon: if one of the standard fds is missing open it to /dev/null
From: Matthias Lederhofer @ 2006-07-13 16:03 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0607130837u30c58d53lc785f56d45ef970c@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> wrote:
> >+ if (devnull == -1 &&
> >+ (devnull = open("/dev/null", O_RDWR, 0)) == -1)
> >+ die("open /dev/null failed: %s", strerror(errno));
> >+ if (dup2(devnull, i) != i)
> >+ die("dup2 failed: %s", strerror(errno));
>
> "die" probably won't work well at this point.
At least with --syslog there will be an error message in the logs.
If the user does not use --syslog and closes fd 2 it is just his own
fault imho.
> Should git (and most other programs) do something like this in general?
> fprintf will happily write to fd=2 regardless of whether that is some critical
> file you opened.
I thought of that too. It might be not that important because I
cannot think of anyway that this could happen accidentally or could be
exploited.
^ permalink raw reply
* [PATCH] diff: Support 256 colors
From: Timo Hirvonen @ 2006-07-13 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Add support for more than 8 colors. Colors can be specified as numbers
-1..255. -1 is same as "normal".
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
diff.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index a9118a9..351cd07 100644
--- a/diff.c
+++ b/diff.c
@@ -26,8 +26,8 @@ enum color_diff {
DIFF_FILE_NEW = 5,
};
-/* "\033[1;30;47m\0" is 11 bytes */
-static char diff_colors[][16] = {
+/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
+static char diff_colors[][24] = {
"\033[m", /* reset */
"", /* normal */
"\033[1m", /* bold */
@@ -57,12 +57,16 @@ static int parse_color(const char *name,
"normal", "black", "red", "green", "yellow",
"blue", "magenta", "cyan", "white"
};
+ char *end;
int i;
for (i = 0; i < ARRAY_SIZE(color_names); i++) {
const char *str = color_names[i];
if (!strncasecmp(name, str, len) && !str[len])
return i - 1;
}
+ i = strtol(name, &end, 10);
+ if (*name && !*end && i >= -1 && i <= 255)
+ return i;
return -2;
}
@@ -135,14 +139,22 @@ static void parse_diff_color_value(const
if (fg >= 0) {
if (sep++)
*dst++ = ';';
- *dst++ = '3';
- *dst++ = '0' + fg;
+ if (fg < 8) {
+ *dst++ = '3';
+ *dst++ = '0' + fg;
+ } else {
+ dst += sprintf(dst, "38;5;%d", fg);
+ }
}
if (bg >= 0) {
if (sep++)
*dst++ = ';';
- *dst++ = '4';
- *dst++ = '0' + bg;
+ if (bg < 8) {
+ *dst++ = '4';
+ *dst++ = '0' + bg;
+ } else {
+ dst += sprintf(dst, "48;5;%d", bg);
+ }
}
*dst++ = 'm';
}
--
1.4.1.gd0c9d-dirty
^ permalink raw reply related
* [PATCH] diff: Support both attributes and colors
From: Timo Hirvonen @ 2006-07-13 16:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Make it possible to set both colors and a attribute for diff colors.
Background colors are supported too.
Syntax is now:
[attr] [fg [bg]]
[fg [bg]] [attr]
Empty value is same as "normal normal", ie use default colors. The new
syntax is backwards compatible.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
diff.c | 164 ++++++++++++++++++++++++++++++++++++++++++----------------------
1 files changed, 107 insertions(+), 57 deletions(-)
diff --git a/diff.c b/diff.c
index a007019..a9118a9 100644
--- a/diff.c
+++ b/diff.c
@@ -26,30 +26,14 @@ enum color_diff {
DIFF_FILE_NEW = 5,
};
-#define COLOR_NORMAL ""
-#define COLOR_BOLD "\033[1m"
-#define COLOR_DIM "\033[2m"
-#define COLOR_UL "\033[4m"
-#define COLOR_BLINK "\033[5m"
-#define COLOR_REVERSE "\033[7m"
-#define COLOR_RESET "\033[m"
-
-#define COLOR_BLACK "\033[30m"
-#define COLOR_RED "\033[31m"
-#define COLOR_GREEN "\033[32m"
-#define COLOR_YELLOW "\033[33m"
-#define COLOR_BLUE "\033[34m"
-#define COLOR_MAGENTA "\033[35m"
-#define COLOR_CYAN "\033[36m"
-#define COLOR_WHITE "\033[37m"
-
-static const char *diff_colors[] = {
- COLOR_RESET,
- COLOR_NORMAL,
- COLOR_BOLD,
- COLOR_CYAN,
- COLOR_RED,
- COLOR_GREEN
+/* "\033[1;30;47m\0" is 11 bytes */
+static char diff_colors[][16] = {
+ "\033[m", /* reset */
+ "", /* normal */
+ "\033[1m", /* bold */
+ "\033[36m", /* cyan */
+ "\033[31m", /* red */
+ "\033[32m" /* green */
};
static int parse_diff_color_slot(const char *var, int ofs)
@@ -67,38 +51,104 @@ static int parse_diff_color_slot(const c
die("bad config variable '%s'", var);
}
-static const char *parse_diff_color_value(const char *value, const char *var)
-{
- if (!strcasecmp(value, "normal"))
- return COLOR_NORMAL;
- if (!strcasecmp(value, "bold"))
- return COLOR_BOLD;
- if (!strcasecmp(value, "dim"))
- return COLOR_DIM;
- if (!strcasecmp(value, "ul"))
- return COLOR_UL;
- if (!strcasecmp(value, "blink"))
- return COLOR_BLINK;
- if (!strcasecmp(value, "reverse"))
- return COLOR_REVERSE;
- if (!strcasecmp(value, "reset"))
- return COLOR_RESET;
- if (!strcasecmp(value, "black"))
- return COLOR_BLACK;
- if (!strcasecmp(value, "red"))
- return COLOR_RED;
- if (!strcasecmp(value, "green"))
- return COLOR_GREEN;
- if (!strcasecmp(value, "yellow"))
- return COLOR_YELLOW;
- if (!strcasecmp(value, "blue"))
- return COLOR_BLUE;
- if (!strcasecmp(value, "magenta"))
- return COLOR_MAGENTA;
- if (!strcasecmp(value, "cyan"))
- return COLOR_CYAN;
- if (!strcasecmp(value, "white"))
- return COLOR_WHITE;
+static int parse_color(const char *name, int len)
+{
+ static const char * const color_names[] = {
+ "normal", "black", "red", "green", "yellow",
+ "blue", "magenta", "cyan", "white"
+ };
+ int i;
+ for (i = 0; i < ARRAY_SIZE(color_names); i++) {
+ const char *str = color_names[i];
+ if (!strncasecmp(name, str, len) && !str[len])
+ return i - 1;
+ }
+ return -2;
+}
+
+static int parse_attr(const char *name, int len)
+{
+ static const int attr_values[] = { 1, 2, 4, 5, 7 };
+ static const char * const attr_names[] = {
+ "bold", "dim", "ul", "blink", "reverse"
+ };
+ int i;
+ for (i = 0; i < ARRAY_SIZE(attr_names); i++) {
+ const char *str = attr_names[i];
+ if (!strncasecmp(name, str, len) && !str[len])
+ return attr_values[i];
+ }
+ return -1;
+}
+
+static void parse_diff_color_value(const char *value, const char *var, char *dst)
+{
+ const char *ptr = value;
+ int attr = -1;
+ int fg = -2;
+ int bg = -2;
+
+ if (!strcasecmp(value, "reset")) {
+ strcpy(dst, "\033[m");
+ return;
+ }
+
+ /* [fg [bg]] [attr] */
+ while (*ptr) {
+ const char *word = ptr;
+ int val, len = 0;
+
+ while (word[len] && !isspace(word[len]))
+ len++;
+
+ ptr = word + len;
+ while (*ptr && isspace(*ptr))
+ ptr++;
+
+ val = parse_color(word, len);
+ if (val >= -1) {
+ if (fg == -2) {
+ fg = val;
+ continue;
+ }
+ if (bg == -2) {
+ bg = val;
+ continue;
+ }
+ goto bad;
+ }
+ val = parse_attr(word, len);
+ if (val < 0 || attr != -1)
+ goto bad;
+ attr = val;
+ }
+
+ if (attr >= 0 || fg >= 0 || bg >= 0) {
+ int sep = 0;
+
+ *dst++ = '\033';
+ *dst++ = '[';
+ if (attr >= 0) {
+ *dst++ = '0' + attr;
+ sep++;
+ }
+ if (fg >= 0) {
+ if (sep++)
+ *dst++ = ';';
+ *dst++ = '3';
+ *dst++ = '0' + fg;
+ }
+ if (bg >= 0) {
+ if (sep++)
+ *dst++ = ';';
+ *dst++ = '4';
+ *dst++ = '0' + bg;
+ }
+ *dst++ = 'm';
+ }
+ *dst = 0;
+ return;
+bad:
die("bad config value '%s' for variable '%s'", value, var);
}
@@ -145,7 +195,7 @@ int git_diff_ui_config(const char *var,
}
if (!strncmp(var, "diff.color.", 11)) {
int slot = parse_diff_color_slot(var, 11);
- diff_colors[slot] = parse_diff_color_value(value, var);
+ parse_diff_color_value(value, var, diff_colors[slot]);
return 0;
}
return git_default_config(var, value);
--
1.4.1.gd0c9d-dirty
^ permalink raw reply related
* [PATCH 2.1/5] daemon: if one of the standard fds is missing open it to /dev/null
From: Matthias Lederhofer @ 2006-07-13 16:32 UTC (permalink / raw)
To: git
In-Reply-To: <E1G0znB-0002IO-61@moooo.ath.cx>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
fixed sanitize_stdfds
---
daemon.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/daemon.c b/daemon.c
index a7636bc..01ccda3 100644
--- a/daemon.c
+++ b/daemon.c
@@ -662,6 +662,18 @@ static int service_loop(int socknum, int
}
}
+/* if any standard file descriptor is missing open it to /dev/null */
+static void sanitize_stdfds(void)
+{
+ int fd = open("/dev/null", O_RDWR, 0);
+ while (fd != -1 && fd < 2)
+ fd = dup(fd);
+ if (fd == -1)
+ die("open /dev/null or dup failed: %s", strerror(errno));
+ if (fd > 2)
+ close(fd);
+}
+
static int serve(int port)
{
int socknum, *socklist;
@@ -773,5 +785,7 @@ int main(int argc, char **argv)
return execute(peer);
}
+ sanitize_stdfds();
+
return serve(port);
}
--
1.4.1.g8b4b
^ permalink raw reply related
* Re: [PATCH 5.1/5] daemon: new option --detach to run git-daemon in background
From: Matthias Lederhofer @ 2006-07-13 16:47 UTC (permalink / raw)
To: Edgar Toernig; +Cc: git
In-Reply-To: <20060713153703.05f862ee.froese@gmx.de>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Edgar Toernig <froese@gmx.de> wrote:
> Hmm... leaks devnull. Why not simply close(0/1/2) and
> let sanitize_stdfds take care of the rest?
---
daemon.c | 29 ++++++++++++++++++++++++++++-
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/daemon.c b/daemon.c
index cdc4266..e4ec676 100644
--- a/daemon.c
+++ b/daemon.c
@@ -674,6 +674,24 @@ static void sanitize_stdfds(void)
close(fd);
}
+static void daemonize(void)
+{
+ switch (fork()) {
+ case 0:
+ break;
+ case -1:
+ die("fork failed: %s", strerror(errno));
+ default:
+ exit(0);
+ }
+ if (setsid() == -1)
+ die("setsid failed: %s", strerror(errno));
+ close(0);
+ close(1);
+ close(2);
+ sanitize_stdfds();
+}
+
static void store_pid(const char *path)
{
FILE *f = fopen(path, "w");
@@ -699,6 +717,7 @@ int main(int argc, char **argv)
int port = DEFAULT_GIT_PORT;
int inetd_mode = 0;
const char *pid_file = NULL;
+ int detach = 0;
int i;
/* Without this we cannot rely on waitpid() to tell
@@ -767,6 +786,11 @@ int main(int argc, char **argv)
pid_file = arg + 11;
continue;
}
+ if (!strcmp(arg, "--detach")) {
+ detach = 1;
+ log_syslog = 1;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
@@ -799,7 +823,10 @@ int main(int argc, char **argv)
return execute(peer);
}
- sanitize_stdfds();
+ if (detach)
+ daemonize();
+ else
+ sanitize_stdfds();
if (pid_file)
store_pid(pid_file);
--
1.4.1.g8b4b
^ permalink raw reply related
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Jakub Narebski @ 2006-07-13 19:38 UTC (permalink / raw)
To: git
In-Reply-To: <44B6369D.6070602@codeweavers.com>
Robert Shearman wrote:
>
> format-patch previously didn't generate a newline after a subject. This
> caused the diffstat to not be displayed in messages without a blank line
> and the first blank line to be eaten in messages with a blank line.
Does this _enforce_ separating commit message into subject+empty
line+description? What about commit messages without this structire (e.g.
legacy commit messages from import from other SCM, e.g. GNU ChangeLog
style)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Robert Shearman @ 2006-07-13 20:03 UTC (permalink / raw)
To: git
In-Reply-To: <e967en$bi6$1@sea.gmane.org>
Jakub Narebski wrote:
>Robert Shearman wrote:
>
>
>>format-patch previously didn't generate a newline after a subject. This
>>caused the diffstat to not be displayed in messages without a blank line
>>and the first blank line to be eaten in messages with a blank line.
>>
>>
>
>Does this _enforce_ separating commit message into subject+empty
>line+description? What about commit messages without this structire (e.g.
>legacy commit messages from import from other SCM, e.g. GNU ChangeLog
>style)?
>
It only affects commits exported into email style. It has nothing to do
with the structure of GIT commit messages or those of any other SCM.
--
Rob Shearman
^ permalink raw reply
* As long as you're hacking on git-daemon...
From: linux @ 2006-07-13 20:12 UTC (permalink / raw)
To: matled; +Cc: git
Is it possible to make it capable of running from /etc/inetd.conf?
That's nicer for little-used personal servers, and also nicer if you
want to use tcp wrappers or one of the inetd replacements that
offers sophisticated load control. (Refuse connections if
load average is too high, different nice level for internal vs.
external clients, etc. etc.)
Thanks.
^ permalink raw reply
* [PATCH 0] A few improvements to Emacs interface to Git
From: Jakub Narebski @ 2006-07-13 20:15 UTC (permalink / raw)
To: git
This series of patches introduces a few minor improvements to
Emacs interface to Git.
--
Jakub Narebski
^ permalink raw reply
* Re: As long as you're hacking on git-daemon...
From: Matthias Lederhofer @ 2006-07-13 20:19 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060713201248.25353.qmail@science.horizon.com>
linux@horizon.com <linux@horizon.com> wrote:
> Is it possible to make it capable of running from /etc/inetd.conf?
It is, see man git-daemon, --inetd :)
^ permalink raw reply
* [PATCH 2] Display help for Git mode after pressing `h' or `?' in *git-status*
From: Jakub Narebski @ 2006-07-13 20:22 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11528217463561-git-send-email-jnareb@gmail.com>
Add bindings for "h" and "?" in git-status-mode to display help about the mode,
including keymap via (describe-function 'git-status-mode), like in PCL-CVS.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
contrib/emacs/git.el | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 83a845d..34c9950 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -943,6 +943,8 @@ (unless git-status-mode-map
(let ((map (make-keymap))
(diff-map (make-sparse-keymap)))
(suppress-keymap map)
+ (define-key map "?" 'git-help)
+ (define-key map "h" 'git-help)
(define-key map " " 'git-next-file)
(define-key map "a" 'git-add-file)
(define-key map "c" 'git-commit-file)
@@ -1012,5 +1014,10 @@ (defun git-status (dir)
(goto-char (point-min)))
(message "%s is not a git working tree." dir)))
+(defun git-help ()
+ "Display help for Git mode."
+ (interactive)
+ (describe-function 'git-status-mode))
+
(provide 'git)
;;; git.el ends here
--
1.4.0
^ permalink raw reply related
* [PATCH 1] Wrap long lines in docstrings in contrib/emacs/git.el
From: Jakub Narebski @ 2006-07-13 20:22 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11528217463561-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
contrib/emacs/git.el | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index ebd00ef..83a845d 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -59,14 +59,16 @@ (defgroup git nil
(defcustom git-committer-name nil
"User name to use for commits.
-The default is to fall back to the repository config, then to `add-log-full-name' and then to `user-full-name'."
+The default is to fall back to the repository config,
+then to `add-log-full-name' and then to `user-full-name'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Name")))
(defcustom git-committer-email nil
"Email address to use for commits.
-The default is to fall back to the git repository config, then to `add-log-mailing-address' and then to `user-mail-address'."
+The default is to fall back to the git repository config,
+then to `add-log-mailing-address' and then to `user-mail-address'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Email")))
@@ -86,6 +88,7 @@ (defcustom git-per-dir-ignore-file ".git
:group 'git
:type 'string)
+
(defface git-status-face
'((((class color) (background light)) (:foreground "purple")))
"Git mode face used to highlight added and modified files."
@@ -149,7 +152,8 @@ (defun git-call-process-env (buffer env
(apply #'call-process "git" nil buffer nil args)))
(defun git-call-process-env-string (env &rest args)
- "Wrapper for call-process that sets environment strings, and returns the process output as a string."
+ "Wrapper for call-process that sets environment strings,
+and returns the process output as a string."
(with-temp-buffer
(and (eq 0 (apply #' git-call-process-env t env args))
(buffer-string))))
--
1.4.0
^ permalink raw reply related
* when is "git diff" output suitable for patch?
From: J. Bruce Fields @ 2006-07-13 21:21 UTC (permalink / raw)
To: git
I assume the -C and -M, -c, and -cc options all result in diff output
that can't be correctly applied by "patch" any more? (Would a patch to
the git-diff-files documentation warning about this be helpful?)
Someone I'm working with is having trouble applying patches that they
created with a simple "git diff". The patches in question have some
"copy from/copy to" headers. Should that every happen with just a plain
"git diff"? Is this a bug in their version of git? (They're on 1.2.4).
--b.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: Junio C Hamano @ 2006-07-13 21:27 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060713212127.GA30770@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> I assume the -C and -M, -c, and -cc options all result in diff output
> that can't be correctly applied by "patch" any more? (Would a patch to
> the git-diff-files documentation warning about this be helpful?)
May not be bad to have, except that I do not know if
"git-diff-files" documentation is the right place to talk about
it.
> Someone I'm working with is having trouble applying patches that they
> created with a simple "git diff". The patches in question have some
> "copy from/copy to" headers. Should that every happen with just a plain
> "git diff"? Is this a bug in their version of git? (They're on 1.2.4).
As far as I recall "git diff" never defaulted to -M. These days
you can have diff.renames = true in the configuration to make it
so, but and I do not think there was any way to do that back in
1.2.4.
If _they_ created the diff with git, and if that is the same
_they_ who are having trouble applying, maybe you can suggest to
use "git apply" instead of "patch -p1"?
^ permalink raw reply
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Junio C Hamano @ 2006-07-13 21:31 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <44B6369D.6070602@codeweavers.com>
Robert Shearman <rob@codeweavers.com> writes:
> This patch inserts a newline in two places - once in the loop to
> separate the subject part of the commit message from the body part of
> the commit message and another after the loop to counteract the eating
> of whitespace at the end of the message.
Thanks.
* Please sign your patch.
* This breaks a handful t4013 tests, but all in a good way (in
other words, the expected output files were wrong).
I'll fix up the t/t4013/diff.* files myself.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: J. Bruce Fields @ 2006-07-13 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd1lurei.fsf@assigned-by-dhcp.cox.net>
On Thu, Jul 13, 2006 at 02:27:33PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > I assume the -C and -M, -c, and -cc options all result in diff output
> > that can't be correctly applied by "patch" any more? (Would a patch to
> > the git-diff-files documentation warning about this be helpful?)
>
> May not be bad to have, except that I do not know if
> "git-diff-files" documentation is the right place to talk about
> it.
OK.
> > Someone I'm working with is having trouble applying patches that they
> > created with a simple "git diff". The patches in question have some
> > "copy from/copy to" headers. Should that every happen with just a plain
> > "git diff"? Is this a bug in their version of git? (They're on 1.2.4).
>
> As far as I recall "git diff" never defaulted to -M.
Hm. Is this related?:
commit 42efbf6d8a5b4902c55a2f6e96034625c056ba1f
Author: Junio C Hamano <junkio@cox.net>
Date: Sat Mar 11 17:44:10 2006 -0800
git-diff: -p disables rename detection.
--b.
^ permalink raw reply
* Re: As long as you're hacking on git-daemon...
From: linux @ 2006-07-13 21:38 UTC (permalink / raw)
To: linux, matled; +Cc: git
In-Reply-To: <E1G17eZ-0006qh-PV@moooo.ath.cx>
> It is, see man git-daemon, --inetd :)
*Blush*. I remember looking for that a while ago and not finding it,
but it appears that it's been there for a year
(since e64e1b79d7c50a234e97d59aadc7a4911de91efe)
I don't think it was that long ago that I looked, so I must have somehow
been utterly blind.
Sorry.
^ permalink raw reply
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Junio C Hamano @ 2006-07-13 21:48 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <7vbqrtur8q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Robert Shearman <rob@codeweavers.com> writes:
>
>> This patch inserts a newline in two places - once in the loop to
>> separate the subject part of the commit message from the body part of
>> the commit message and another after the loop to counteract the eating
>> of whitespace at the end of the message.
>
> Thanks.
>
> * Please sign your patch.
>
> * This breaks a handful t4013 tests, but all in a good way (in
> other words, the expected output files were wrong).
>
> I'll fix up the t/t4013/diff.* files myself.
Actually, I take that back. This breaks normal commit log
messages by adding extra blank lines. The extra LF is needed
when the commit log does not have any message (just title).
I'll be tweaking a few tests in t4013 to catch future breakage
of this kind.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: Junio C Hamano @ 2006-07-13 21:51 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060713213116.GK19366@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> As far as I recall "git diff" never defaulted to -M.
>
> Hm. Is this related?:
>
> commit 42efbf6d8a5b4902c55a2f6e96034625c056ba1f
> Author: Junio C Hamano <junkio@cox.net>
> Date: Sat Mar 11 17:44:10 2006 -0800
>
> git-diff: -p disables rename detection.
Ah, sorry, it _did_ default to -M; it was in such an ancient
past and the shell wrapper wasn't initially done by me, so I
misremembered.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: J. Bruce Fields @ 2006-07-13 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bd5uqav.fsf@assigned-by-dhcp.cox.net>
On Thu, Jul 13, 2006 at 02:51:20PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> >> As far as I recall "git diff" never defaulted to -M.
> >
> > Hm. Is this related?:
> >
> > commit 42efbf6d8a5b4902c55a2f6e96034625c056ba1f
> > Author: Junio C Hamano <junkio@cox.net>
> > Date: Sat Mar 11 17:44:10 2006 -0800
> >
> > git-diff: -p disables rename detection.
>
> Ah, sorry, it _did_ default to -M; it was in such an ancient
> past and the shell wrapper wasn't initially done by me, so I
> misremembered.
Perfectly understandable; thanks for the help.--b.
^ permalink raw reply
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Robert Shearman @ 2006-07-13 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2huqfj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>Junio C Hamano <junkio@cox.net> writes:
>
>
>
>>Robert Shearman <rob@codeweavers.com> writes:
>>
>>
>>
>>>This patch inserts a newline in two places - once in the loop to
>>>separate the subject part of the commit message from the body part of
>>>the commit message and another after the loop to counteract the eating
>>>of whitespace at the end of the message.
>>>
>>>
>>Thanks.
>>
>> * Please sign your patch.
>>
>> * This breaks a handful t4013 tests, but all in a good way (in
>> other words, the expected output files were wrong).
>>
>>I'll fix up the t/t4013/diff.* files myself.
>>
>>
>
>Actually, I take that back. This breaks normal commit log
>messages by adding extra blank lines. The extra LF is needed
>when the commit log does not have any message (just title).
>
>
Ok, I'll resend with that fixed.
>I'll be tweaking a few tests in t4013 to catch future breakage
>of this kind.
>
Thanks.
--
Rob Shearman
^ permalink raw reply
* [PATCH] format-patch: Generate a newline between the subject header and the message body
From: Robert Shearman @ 2006-07-13 22:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
format-patch previously didn't generate a newline after a subject. This
caused the diffstat to not be displayed in messages with only one line
for the commit message.
This patch fixes this by adding a newline after the headers if a body
hasn't been added.
Signed-off-by: Robert Shearman <rob@codeweavers.com>
---
commit.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
[-- Attachment #2: e4ec67def0af32e4a1704ce5ad941c81136b34e8.diff --]
[-- Type: text/x-patch, Size: 884 bytes --]
diff --git a/commit.c b/commit.c
index 522a6f3..6ac3bf7 100644
--- a/commit.c
+++ b/commit.c
@@ -655,6 +655,9 @@ unsigned long pretty_print_commit(enum c
continue;
}
+ if (!subject)
+ body = 1;
+
if (is_empty_line(line, &linelen)) {
if (!body)
continue;
@@ -662,8 +665,6 @@ unsigned long pretty_print_commit(enum c
continue;
if (fmt == CMIT_FMT_SHORT)
break;
- } else {
- body = 1;
}
if (subject) {
@@ -702,6 +703,12 @@ unsigned long pretty_print_commit(enum c
/* Make sure there is an EOLN for the non-oneline case */
if (fmt != CMIT_FMT_ONELINE)
buf[offset++] = '\n';
+ /*
+ * make sure there is another EOLN to separate the headers from whatever
+ * body the caller appends if we haven't already written a body
+ */
+ if (fmt == CMIT_FMT_EMAIL && !body)
+ buf[offset++] = '\n';
buf[offset] = '\0';
return offset;
}
^ permalink raw reply related
* Kernel headers git tree
From: David Woodhouse @ 2006-07-13 23:59 UTC (permalink / raw)
To: linux-kernel; +Cc: git
At http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git
there's a git tree which contains the sanitised exported headers for all
architectures -- basically the result of 'make headers_install'.
It tracks Linus' kernel tree, by means of some evil scripts.¹
Only commits in Linus' tree which actually affect the exported result
should have an equivalent commit in the above tree, which means that any
changes which affect userspace should be clearly visible for review.
--
dwmw2
¹ http://david.woodhou.se/extract-khdrs-git.sh and
http://david.woodhou.se/extract-khdrs-stage2.sh for the stout of stomach
^ 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