* [PATCH 3/3] git.el: Make status refresh faster.
From: Alexandre Julliard @ 2008-01-08 13:49 UTC (permalink / raw)
To: git
Don't set the needs-refresh flag when inserting a new file info, since
ewoc refreshes it upon insert already; this makes a full refresh twice
as fast.
Also make git-fileinfo-prettyprint a little faster by not retrieving
permission values twice.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 825b1e9..8f39ebe 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -538,10 +538,10 @@ and returns the process output as a string."
('ignored (propertize "Ignored " 'face 'git-ignored-face))
(t "? ")))
-(defun git-file-type-as-string (info)
- "Return a string describing the file type of INFO."
- (let* ((old-type (lsh (or (git-fileinfo->old-perm info) 0) -9))
- (new-type (lsh (or (git-fileinfo->new-perm info) 0) -9))
+(defun git-file-type-as-string (old-perm new-perm)
+ "Return a string describing the file type based on its permissions."
+ (let* ((old-type (lsh (or old-perm 0) -9))
+ (new-type (lsh (or new-perm 0) -9))
(str (case new-type
(?\100 ;; file
(case old-type
@@ -590,12 +590,14 @@ and returns the process output as a string."
(defun git-fileinfo-prettyprint (info)
"Pretty-printer for the git-fileinfo structure."
- (insert (concat " " (if (git-fileinfo->marked info) (propertize "*" 'face 'git-mark-face) " ")
- " " (git-status-code-as-string (git-fileinfo->state info))
- " " (git-permissions-as-string (git-fileinfo->old-perm info) (git-fileinfo->new-perm info))
- " " (git-escape-file-name (git-fileinfo->name info))
- (git-file-type-as-string info)
- (git-rename-as-string info))))
+ (let ((old-perm (git-fileinfo->old-perm info))
+ (new-perm (git-fileinfo->new-perm info)))
+ (insert (concat " " (if (git-fileinfo->marked info) (propertize "*" 'face 'git-mark-face) " ")
+ " " (git-status-code-as-string (git-fileinfo->state info))
+ " " (git-permissions-as-string old-perm new-perm)
+ " " (git-escape-file-name (git-fileinfo->name info))
+ (git-file-type-as-string old-perm new-perm)
+ (git-rename-as-string info)))))
(defun git-insert-info-list (status infolist)
"Insert a list of file infos in the status buffer, replacing existing ones if any."
@@ -606,7 +608,6 @@ and returns the process output as a string."
(let ((info (pop infolist))
(node (ewoc-nth status 0)))
(while info
- (setf (git-fileinfo->needs-refresh info) t)
(cond ((not node)
(setq node (ewoc-enter-last status info))
(setq info (pop infolist)))
@@ -617,6 +618,7 @@ and returns the process output as a string."
(git-fileinfo->name info))
;; preserve the marked flag
(setf (git-fileinfo->marked info) (git-fileinfo->marked (ewoc-data node)))
+ (setf (git-fileinfo->needs-refresh info) t)
(setf (ewoc-data node) info)
(setq info (pop infolist)))
(t
--
1.5.4.rc2.71.ge10a9
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 2/3] git.el: Refresh files from their real state upon commit.
From: Alexandre Julliard @ 2008-01-08 13:46 UTC (permalink / raw)
To: git
Instead of just setting the state to up-to-date, retrieve the full
state again, so that the file type can be displayed properly.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 885ad20..825b1e9 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -626,7 +626,8 @@ and returns the process output as a string."
(defun git-run-diff-index (status files)
"Run git-diff-index on FILES and parse the results into STATUS.
Return the list of files that haven't been handled."
- (let (infolist)
+ (let ((remaining (copy-sequence files))
+ infolist)
(with-temp-buffer
(apply #'git-call-process-env t nil "diff-index" "-z" "-M" "HEAD" "--" files)
(goto-char (point-min))
@@ -644,10 +645,10 @@ Return the list of files that haven't been handled."
(push (git-create-fileinfo 'deleted name 0 0 'rename new-name) infolist)
(push (git-create-fileinfo 'added new-name old-perm new-perm 'rename name) infolist))
(push (git-create-fileinfo (git-state-code state) name old-perm new-perm) infolist))
- (setq files (delete name files))
- (when new-name (setq files (delete new-name files))))))
+ (setq remaining (delete name remaining))
+ (when new-name (setq remaining (delete new-name remaining))))))
(git-insert-info-list status infolist)
- files))
+ remaining))
(defun git-find-status-file (status file)
"Find a given file in the status ewoc and return its node."
@@ -673,7 +674,8 @@ Return the list of files that haven't been handled."
(defun git-run-ls-files-cached (status files default-state)
"Run git-ls-files -c on FILES and parse the results into STATUS.
Return the list of files that haven't been handled."
- (let (infolist)
+ (let ((remaining (copy-sequence files))
+ infolist)
(with-temp-buffer
(apply #'git-call-process-env t nil "ls-files" "-z" "-s" "-c" "--" files)
(goto-char (point-min))
@@ -682,9 +684,9 @@ Return the list of files that haven't been handled."
(old-perm (if (eq default-state 'added) 0 new-perm))
(name (match-string 2)))
(push (git-create-fileinfo default-state name old-perm new-perm) infolist)
- (setq files (delete name files)))))
+ (setq remaining (delete name remaining)))))
(git-insert-info-list status infolist)
- files))
+ remaining))
(defun git-run-ls-unmerged (status files)
"Run git-ls-files -u on FILES and parse the results into STATUS."
@@ -716,8 +718,8 @@ Return the list of files that haven't been handled."
(defun git-update-status-files (files &optional default-state)
"Update the status of FILES from the index."
(unless git-status (error "Not in git-status buffer."))
- (unless files
- (when git-show-uptodate (git-run-ls-files-cached git-status nil 'uptodate)))
+ (when (or git-show-uptodate files)
+ (git-run-ls-files-cached git-status files 'uptodate))
(let* ((remaining-files
(if (git-empty-db-p) ; we need some special handling for an empty db
(git-run-ls-files-cached git-status files 'added)
@@ -839,7 +841,7 @@ Return the list of files that haven't been handled."
(condition-case nil (delete-file ".git/MERGE_HEAD") (error nil))
(condition-case nil (delete-file ".git/MERGE_MSG") (error nil))
(with-current-buffer buffer (erase-buffer))
- (dolist (info files) (git-set-fileinfo-state info 'uptodate))
+ (git-update-status-files (git-get-filenames files) 'uptodate)
(git-call-process-env nil nil "rerere")
(git-call-process-env nil nil "gc" "--auto")
(git-refresh-files)
--
1.5.4.rc2.71.ge10a9
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 1/3] git.el: Make sure we never insert the same file twice.
From: Alexandre Julliard @ 2008-01-08 13:45 UTC (permalink / raw)
To: git
Skip non-zero stage files during git-ls-files -c, they are handled
later. Also fix git-insert-info-list to merge duplicate file names.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 9a0f03f..885ad20 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -608,7 +608,7 @@ and returns the process output as a string."
(while info
(setf (git-fileinfo->needs-refresh info) t)
(cond ((not node)
- (ewoc-enter-last status info)
+ (setq node (ewoc-enter-last status info))
(setq info (pop infolist)))
((string-lessp (git-fileinfo->name (ewoc-data node))
(git-fileinfo->name info))
@@ -620,7 +620,7 @@ and returns the process output as a string."
(setf (ewoc-data node) info)
(setq info (pop infolist)))
(t
- (ewoc-enter-before status node info)
+ (setq node (ewoc-enter-before status node info))
(setq info (pop infolist)))))))
(defun git-run-diff-index (status files)
@@ -677,7 +677,7 @@ Return the list of files that haven't been handled."
(with-temp-buffer
(apply #'git-call-process-env t nil "ls-files" "-z" "-s" "-c" "--" files)
(goto-char (point-min))
- (while (re-search-forward "\\([0-7]\\{6\\}\\) [0-9a-f]\\{40\\} [0-3]\t\\([^\0]+\\)\0" nil t)
+ (while (re-search-forward "\\([0-7]\\{6\\}\\) [0-9a-f]\\{40\\} 0\t\\([^\0]+\\)\0" nil t)
(let* ((new-perm (string-to-number (match-string 1) 8))
(old-perm (if (eq default-state 'added) 0 new-perm))
(name (match-string 2)))
--
1.5.4.rc2.71.ge10a9
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: Cover letter
From: Paolo Ciarrocchi @ 2008-01-08 13:13 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Git Mailing List
In-Reply-To: <478375FB.405@isy.liu.se>
On Jan 8, 2008 2:09 PM, Gustaf Hendeby <hendeby@isy.liu.se> wrote:
> > This is working fine but since I'm going to push out a queue of patches
> > it would be nicer to script everything with git-send-email.
> >
> > I know I have to configure git in order to use the gmail's smtp server,
> > I know how to tell git-send-email where to pick up the patches but I fail
> > to understand how I can write a cover letter and let it be part of the patch
> > queue.
>
> Use the switch --compose to git send-email, that should open up an
> editor and let you write a cover letter to go with the patches.
Not enough coffe :-)
The option is there and well documented.
Thanks Gustaf.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Cover letter
From: Gustaf Hendeby @ 2008-01-08 13:09 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30801080452g71c3d3dx39f2ec805239ef01@mail.gmail.com>
> This is working fine but since I'm going to push out a queue of patches
> it would be nicer to script everything with git-send-email.
>
> I know I have to configure git in order to use the gmail's smtp server,
> I know how to tell git-send-email where to pick up the patches but I fail
> to understand how I can write a cover letter and let it be part of the patch
> queue.
Use the switch --compose to git send-email, that should open up an
editor and let you write a cover letter to go with the patches.
/Gustaf
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Harris @ 2008-01-08 13:07 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se>
On Jan 8, 2008 5:56 AM, Peter Karlsson <peter@softwolves.pp.se> wrote:
> Thomas Neumann:
>
> > as a user, I expect a SCM to only modify a file when I have
> > explicitly asked it to do so.
>
> As a user, I exepect things to just work. With RCS/CVS/Subversion, it
> does, because it differentiates between text files (internally encoding
> NLs with "LF", but I couldn't care less what it uses there) and binary
> files (which it doesn't change). With git it currently doesn't since it
> treats everything as binary files.
Actually, Subversion does the Right Thing, and treats everything as a
binary file until and unless you explicitly set the svn:eol-style
property on each file that you want it to mangle.
Maybe you set up Subversion auto-props and forgot about it? That would
be almost (but not really) like setting autocrlf=true in your global
git config.
Peter Harris
^ permalink raw reply
* Re: [PATCH 2/4] git branch: Use color configuration infrastructure
From: Matthias Kestenholz @ 2008-01-08 12:52 UTC (permalink / raw)
To: Jeff King, gitster, git
In-Reply-To: <20080108112328.GA19941@coredump.intra.peff.net>
On Tue, 2008-01-08 at 06:23 -0500, Jeff King wrote:
> On Sat, Jan 05, 2008 at 03:11:37PM +0100, Matthias Kestenholz wrote:
>
> > --- a/builtin-branch.c
> > +++ b/builtin-branch.c
> > [...]
> > -static int branch_use_color;
> > [...]
> > if (!strcmp(var, "color.branch")) {
> > - branch_use_color = git_config_colorbool(var, value, -1);
> > + git_use_color = git_config_colorbool(var, value, -1);
> > return 0;
> > }
>
> If I read this right, you are getting rid of the individual "use color"
> variables with a single static git_use_color. This will break if two
> different color "zones" get used in the same program (e.g.,
> color.branch and color.diff, but only one is supposed to be set). I
> don't think this is a problem currently, but it seems like a step
> backwards in terms of libification.
Yes that's right. I am still not convinced that its worth having
multiple color switches, but since they are there now we should probably
preserve them.
I finally made the application of the default config (color.ui)
explicit. It's a little bit more code and I have to export the
colorbools, but appart from that it's not too bad (I hope). I am
initializing all colorbools to -1 to differentiate between `unset` and
`false`/`never`.
I have doubts about the change in diff.c. That git_diff_basic_config()
calls git_color_default_config() seems not too nice, because color.diff
is evaluated one layer higher, in git_diff_ui_config. It does not do no
harm however, because git_color_default_config() has no side effects.
This is the last complete rewrite of the patch without requests from
outside, I promise :-) I am rather happy with the current state of
affairs. Many thanks for the reviews and comments.
-- 8< --
>From 1ee26ac15628979b480b087f4dba3375ce1efd13 Mon Sep 17 00:00:00 2001
From: Matthias Kestenholz <matthias@spinlock.ch>
Date: Tue, 8 Jan 2008 13:45:32 +0100
Subject: [PATCH] Add color.ui variable which globally enables colorization if set
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/config.txt | 7 +++++++
builtin-branch.c | 10 +++++++---
builtin-commit.c | 4 ++++
builtin-diff.c | 5 +++++
builtin-log.c | 17 +++++++++++++++++
color.c | 12 ++++++++++++
color.h | 11 +++++++++++
diff.c | 6 +++---
diff.h | 1 +
wt-status.c | 6 +++---
10 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1b6d6d6..b55f3b4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -439,6 +439,13 @@ color.status.<slot>::
commit.template::
Specify a file to use as the template for new commit messages.
+color.ui::
+ When set to `always`, always use colors in all git commands which
+ are capable of colored output. When false (or `never`), never. When
+ set to `true` or `auto`, use colors only when the output is to the
+ terminal. When more specific variables of color.* are set, they always
+ take precedence over this setting. Defaults to false.
+
diff.autorefreshindex::
When using `git diff` to compare with work tree
files, do not consider stat-only change as changed.
diff --git a/builtin-branch.c b/builtin-branch.c
index 089cae5..9a1eb21 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -31,7 +31,7 @@ static unsigned char head_sha1[20];
static int branch_track = 1;
-static int branch_use_color;
+static int branch_use_color = -1;
static char branch_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
"", /* PLAIN (normal) */
@@ -76,12 +76,12 @@ static int git_branch_config(const char *var, const char *value)
if (!strcmp(var, "branch.autosetupmerge"))
branch_track = git_config_bool(var, value);
- return git_default_config(var, value);
+ return git_color_default_config(var, value);
}
static const char *branch_get_color(enum color_branch ix)
{
- if (branch_use_color)
+ if (branch_use_color > 0)
return branch_colors[ix];
return "";
}
@@ -585,6 +585,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
};
git_config(git_branch_config);
+
+ if (branch_use_color == -1)
+ branch_use_color = git_use_color_default;
+
track = branch_track;
argc = parse_options(argc, argv, options, builtin_branch_usage, 0);
if (!!delete + !!rename + !!force_create > 1)
diff --git a/builtin-commit.c b/builtin-commit.c
index 73f1e35..ba60cfa 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -7,6 +7,7 @@
#include "cache.h"
#include "cache-tree.h"
+#include "color.h"
#include "dir.h"
#include "builtin.h"
#include "diff.h"
@@ -640,6 +641,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
git_config(git_status_config);
+ if (wt_status_use_color == -1)
+ wt_status_use_color = git_use_color_default;
+
argc = parse_and_validate_options(argc, argv, builtin_status_usage);
index_file = prepare_index(argc, argv, prefix);
diff --git a/builtin-diff.c b/builtin-diff.c
index 29365a0..77a9c9a 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -4,6 +4,7 @@
* Copyright (c) 2006 Junio C Hamano
*/
#include "cache.h"
+#include "color.h"
#include "commit.h"
#include "blob.h"
#include "tag.h"
@@ -229,6 +230,10 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
prefix = setup_git_directory_gently(&nongit);
git_config(git_diff_ui_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
diff --git a/builtin-log.c b/builtin-log.c
index dcc9f81..880da94 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -5,6 +5,7 @@
* 2006 Junio Hamano
*/
#include "cache.h"
+#include "color.h"
#include "commit.h"
#include "diff.h"
#include "revision.h"
@@ -235,6 +236,10 @@ int cmd_whatchanged(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.diff = 1;
rev.simplify_history = 0;
@@ -307,6 +312,10 @@ int cmd_show(int argc, const char **argv, const char *prefix)
int i, count, ret = 0;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.diff = 1;
rev.combine_merges = 1;
@@ -367,6 +376,10 @@ int cmd_log_reflog(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
init_reflog_walk(&rev.reflog_info);
rev.abbrev_commit = 1;
@@ -395,6 +408,10 @@ int cmd_log(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.always_show_header = 1;
cmd_log_init(argc, argv, prefix, &rev);
diff --git a/color.c b/color.c
index 7f66c29..09b81fe 100644
--- a/color.c
+++ b/color.c
@@ -3,6 +3,8 @@
#define COLOR_RESET "\033[m"
+int git_use_color_default = 0;
+
static int parse_color(const char *name, int len)
{
static const char * const color_names[] = {
@@ -143,6 +145,16 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty)
return 0;
}
+int git_color_default_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "color.ui")) {
+ git_use_color_default = git_config_colorbool(var, value, -1);
+ return 0;
+ }
+
+ return git_default_config(var, value);
+}
+
static int color_vfprintf(FILE *fp, const char *color, const char *fmt,
va_list args, const char *trail)
{
diff --git a/color.h b/color.h
index ff63513..ecda556 100644
--- a/color.h
+++ b/color.h
@@ -4,6 +4,17 @@
/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
#define COLOR_MAXLEN 24
+/*
+ * This variable stores the value of color.ui
+ */
+extern int git_use_color_default;
+
+
+/*
+ * Use this instead of git_default_config if you need the value of color.ui.
+ */
+int git_color_default_config(const char *var, const char *value);
+
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
diff --git a/diff.c b/diff.c
index b18c140..d6f23c7 100644
--- a/diff.c
+++ b/diff.c
@@ -20,7 +20,7 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = 100;
-static int diff_use_color_default;
+int diff_use_color_default = -1;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
@@ -189,7 +189,7 @@ int git_diff_basic_config(const char *var, const char *value)
}
}
- return git_default_config(var, value);
+ return git_color_default_config(var, value);
}
static char *quote_two(const char *one, const char *two)
@@ -2048,7 +2048,7 @@ void diff_setup(struct diff_options *options)
options->change = diff_change;
options->add_remove = diff_addremove;
- if (diff_use_color_default)
+ if (diff_use_color_default > 0)
DIFF_OPT_SET(options, COLOR_DIFF);
else
DIFF_OPT_CLR(options, COLOR_DIFF);
diff --git a/diff.h b/diff.h
index 073d5cb..8e73f07 100644
--- a/diff.h
+++ b/diff.h
@@ -174,6 +174,7 @@ extern void diff_unmerge(struct diff_options *,
extern int git_diff_basic_config(const char *var, const char *value);
extern int git_diff_ui_config(const char *var, const char *value);
+extern int diff_use_color_default;
extern void diff_setup(struct diff_options *);
extern int diff_opt_parse(struct diff_options *, const char **, int);
extern int diff_setup_done(struct diff_options *);
diff --git a/wt-status.c b/wt-status.c
index c0c2472..0dfc909 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -9,7 +9,7 @@
#include "diffcore.h"
int wt_status_relative_paths = 1;
-int wt_status_use_color = 0;
+int wt_status_use_color = -1;
static char wt_status_colors[][COLOR_MAXLEN] = {
"", /* WT_STATUS_HEADER: normal */
"\033[32m", /* WT_STATUS_UPDATED: green */
@@ -40,7 +40,7 @@ static int parse_status_slot(const char *var, int offset)
static const char* color(int slot)
{
- return wt_status_use_color ? wt_status_colors[slot] : "";
+ return wt_status_use_color > 0 ? wt_status_colors[slot] : "";
}
void wt_status_prepare(struct wt_status *s)
@@ -409,5 +409,5 @@ int git_status_config(const char *k, const char *v)
wt_status_relative_paths = git_config_bool(k, v);
return 0;
}
- return git_default_config(k, v);
+ return git_color_default_config(k, v);
}
--
1.5.4.rc2.68.ge708a-dirty
^ permalink raw reply related
* Cover letter
From: Paolo Ciarrocchi @ 2008-01-08 12:52 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I'm going to experiment the git-send-email command quite soon and I
have a doubt
that I would like to clarify.
I'm used to the following work flow:
- git branch trivial
- git checkout trivial
- work work work
- git gui to commit all the changes
- git-format-patch -n -o /home/paolo/patches
- open the MUA
- write the cover letter
- import the N patches
- send all the patches
- collect feedback
- work work work
- git rebase -i
- back to the git gui to commit all the changes line
This is working fine but since I'm going to push out a queue of patches
it would be nicer to script everything with git-send-email.
I know I have to configure git in order to use the gmail's smtp server,
I know how to tell git-send-email where to pick up the patches but I fail
to understand how I can write a cover letter and let it be part of the patch
queue.
Any hint?
Thanks in advance.
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-08 12:20 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git
In-Reply-To: <20080108100818.GA17205@coredump.intra.peff.net>
On 8/1/08 10:08, "Jeff King" <peff@peff.net> wrote:
>> If you are introducing crlf = warn, that means you are declaring
>> that CRLF should be treated as a disease, and that should apply
>> everywhere, not just on Windows (which some people may consider
>> a disease itself, but that is a separate topic).
>
> It's unclear to me: is such a warning only supposed to happen when we
> see CRLF _after_ we have determined that a file is not actually binary?
> Otherwise, it seems like we are punishing people on sane platforms who
> use binary files (although even with that check, I am slightly
> uncomfortable given reports of incorrect guessing).
In the context of EOL style, a warning or error should only be given if we
think the file is text. Very occasionally we will be wrong about this, but
if the default behaviour is warn then that will just be a minor annoyance.
This annoyance can be overcome for a file or file type (with attributes),
per project or globally. If the default behaviour were munge (e.g.
autocrlf=true) then we could very occasionally damage something, so I think
we can all agree that is a bad idea.
Greg.
^ permalink raw reply
* Re: [PATCH] git-submodule: New subcommand 'summary'
From: Ping Yin @ 2008-01-08 12:20 UTC (permalink / raw)
To: git
In-Reply-To: <1199122505-27478-1-git-send-email-pkufranky@gmail.com>
Any comment to my patch?
Following this i will give patches to introduce submodule summary
function into git-commit
On Jan 1, 2008 1:35 AM, Ping Yin <pkufranky@gmail.com> wrote:
> The patch series ( 3 in total) teach git-submodule a new subcommand 'summary'.
>
> PATCH 1 introduces the code framework.
>
> PATCH 2 does the real work for summary.
>
> PATCH 3 teaches a new option '--summary-limit|-n'.
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ping Yin
^ permalink raw reply
* An interaction with ce_match_stat_basic() and autocrlf
From: Junio C Hamano @ 2008-01-08 12:12 UTC (permalink / raw)
To: torvalds; +Cc: git
There is an interesting interaction with the stat matching and
autocrlf.
$ git init
$ git config core.autocrlf true
$ echo a >a.txt
$ git add a.txt
$ unix2dos a.txt
$ git diff
diff --git a/a.txt b/a.txt
At this point, the index records a blob with LF line ending,
while the work tree file has the same content with CRLF line
ending. And the funny thing is that once you get into this
situation it is unfixable short of "git add a.txt". Most
notably, "git update-index --refresh" (and the equilvalent
auto-refresh that is implicitly run by "git diff" Porcelain)
will not update the cached stat information.
This is caused partly by the breakage in size_only codepath of
diff.c::diff_populate_filespec(). When taking the file contents
from the work tree, it just gets stat data and thinks it got the
final size, but it should actually convert the blob data into
canonical format. diff.c::diffcore_skip_stat_unmatch() is
fooled by this and declares that the path is modified.
This can be fixed by not returning early even when size_only is
asked in the codepath. It will make everything quite a lot more
expensive, as there currently is not a cheap way to ask "is this
path going to be munged by autocrlf or clean filter", but
getting the correct result is more important than getting a
quick but wrong result.
But that is just a half of the story.
(1) It won't make the entry stat clean, as refresh_index()
later called from builtin-diff.c to clean up the stat
dirtiness works without paying attention to the autocrlf
conversion.
(2) It won't help lower-level diff-files and internal callers
to ce_match_stat() that checks if the path were touched.
The "read-tree -m -u" codepath uses it to avoid touching
the path with local modifications. The standard way to
clear the stat-dirtiness with "git update-index --refresh"
still needs to be fixed anyway.
I was going to conclude this message by saying "I need to sleep
on this to see if I can come up with a clean solution", but it
appears I do not have much time left for actually sleeping X-<.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-08 11:54 UTC (permalink / raw)
To: Jeff King; +Cc: Peter Karlsson, git
In-Reply-To: <20080108110757.GB18087@coredump.intra.peff.net>
Hi,
On Tue, 8 Jan 2008, Jeff King wrote:
> On Tue, Jan 08, 2008 at 11:56:00AM +0100, Peter Karlsson wrote:
>
> > If I occasionally need to do a
> >
> > git add -kb binary.txt
> >
> > to flag a file explicitely, that's a small price to pay for everything
> > else to work out of the box.
>
> For you, perhaps, since you apparently infrequently commit binary files
> and derive some benefit from CRLF conversion. But please bear in mind
> that there are people on the other end of the spectrum who want the
> opposite (i.e., who could care less about CRLF, but _do_ have binary
> files).
Do not forget the people who say that git is a content tracker (as opposed
to a content munger). Git was really intended as a tracker of octet
strings which are organised in tree structures, and where you can have
revisions over those tree structures.
That is the beauty of git: it keeps simple things simple. Now, for some,
this is a curse ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-08 11:52 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se>
Hi,
On Tue, 8 Jan 2008, Peter Karlsson wrote:
> Thomas Neumann:
>
> > as a user, I expect a SCM to only modify a file when I have
> > explicitly asked it to do so.
>
> As a user, I exepect things to just work. With RCS/CVS/Subversion, it
> does, because it differentiates between text files (internally encoding
> NLs with "LF", but I couldn't care less what it uses there) and binary
> files (which it doesn't change). With git it currently doesn't since it
> treats everything as binary files.
<tongue-in-cheek>Hey, if Subversion does what you want, why not just use
it?</tongue-in-cheek>
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Josh Triplett @ 2008-01-08 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Joe Perches, J. Bruce Fields, git
In-Reply-To: <7vy7bt57wn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>> Ah. The problem is that git-send-email unconditionally adds a
>> message-id. Usually git-format-patch doesn't add one, but for obvious
>> reasons, it must when doing --thread. Here is a fix.
>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 1d6f466..083466a 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -580,7 +580,7 @@ sub send_message
>> $ccline = "\nCc: $cc";
>> }
>> my $sanitized_sender = sanitize_address($sender);
>> - make_message_id();
>> + make_message_id() unless defined($message_id);
>
> Isn't this called inside a loop? If the outgoing message does not
> originally have "Message-Id:", does the loop correctly reinitialize
> $message_id to undef, or does this change make everybody reuse the same
> $message_id over and over again?
>
> I have a feeling that --thread to format-patch is a misfeature. Why is
> it needed if you are feeding the output to send-email?
I added that option; see (d1566f7883f727f38bf442af3fdb69d36e6fcea2,
cc35de8470541e389b7d2bdda4c901574720fa81, and
da56645dd7c1175fc2ed1628ac35fdd35e705641). I use git-imap-send, not
git-send-email, and I wanted to thread my patches.
- Josh Triplett
^ permalink raw reply
* Re: [PATCH 2/4] git branch: Use color configuration infrastructure
From: Jeff King @ 2008-01-08 11:23 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: gitster, git, Matthias Kestenholz
In-Reply-To: <1199542299-12082-2-git-send-email-mk@spinlock.ch>
On Sat, Jan 05, 2008 at 03:11:37PM +0100, Matthias Kestenholz wrote:
> --- a/builtin-branch.c
> +++ b/builtin-branch.c
> [...]
> -static int branch_use_color;
> [...]
> if (!strcmp(var, "color.branch")) {
> - branch_use_color = git_config_colorbool(var, value, -1);
> + git_use_color = git_config_colorbool(var, value, -1);
> return 0;
> }
If I read this right, you are getting rid of the individual "use color"
variables with a single static git_use_color. This will break if two
different color "zones" get used in the same program (e.g.,
color.branch and color.diff, but only one is supposed to be set). I
don't think this is a problem currently, but it seems like a step
backwards in terms of libification.
-Peff
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Josh Triplett @ 2008-01-08 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Joe Perches, J. Bruce Fields, git
In-Reply-To: <7vy7bt57wn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>> Ah. The problem is that git-send-email unconditionally adds a
>> message-id. Usually git-format-patch doesn't add one, but for obvious
>> reasons, it must when doing --thread. Here is a fix.
>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 1d6f466..083466a 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -580,7 +580,7 @@ sub send_message
>> $ccline = "\nCc: $cc";
>> }
>> my $sanitized_sender = sanitize_address($sender);
>> - make_message_id();
>> + make_message_id() unless defined($message_id);
>
> Isn't this called inside a loop? If the outgoing message does not
> originally have "Message-Id:", does the loop correctly reinitialize
> $message_id to undef, or does this change make everybody reuse the same
> $message_id over and over again?
>
> I have a feeling that --thread to format-patch is a misfeature. Why is
> it needed if you are feeding the output to send-email?
I added that option; see (d1566f7883f727f38bf442af3fdb69d36e6fcea2,
cc35de8470541e389b7d2bdda4c901574720fa81, and
da56645dd7c1175fc2ed1628ac35fdd35e705641). I use git-imap-send, not
git-send-email, and I wanted to thread my patches.
- Josh Triplett
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Jeff King @ 2008-01-08 11:07 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se>
On Tue, Jan 08, 2008 at 11:56:00AM +0100, Peter Karlsson wrote:
> If I occasionally need to do a
>
> git add -kb binary.txt
>
> to flag a file explicitely, that's a small price to pay for everything
> else to work out of the box.
For you, perhaps, since you apparently infrequently commit binary files
and derive some benefit from CRLF conversion. But please bear in mind
that there are people on the other end of the spectrum who want the
opposite (i.e., who could care less about CRLF, but _do_ have binary
files).
-Peff
^ permalink raw reply
* git and unicode
From: Gonzalo Garramuño @ 2008-01-08 11:09 UTC (permalink / raw)
To: git
In-Reply-To: <C3A86A49.10AEF%jefferis@gmail.com>
Forking a little from the recent CR/LF thread, I was wondering how does
git deal with unicode files?
Most scripting languages (ruby, python, etc) are now allowing their
source code to be written in unicode (UTF-8, usually). Will git
incorrectly categorize those source files as "binary"?
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-08 10:56 UTC (permalink / raw)
To: git
In-Reply-To: <20080107224204.55539c31@jaiman>
Thomas Neumann:
> as a user, I expect a SCM to only modify a file when I have
> explicitly asked it to do so.
As a user, I exepect things to just work. With RCS/CVS/Subversion, it
does, because it differentiates between text files (internally encoding
NLs with "LF", but I couldn't care less what it uses there) and binary
files (which it doesn't change). With git it currently doesn't since it
treats everything as binary files.
Yes, it's the whole text vs. binary file issue. We do live in a world
where different systems store text differently. We have to deal with
it. Preferrably, the computer should deal with it without me having to
do anything about it. After all, that's what computers are good at.
If I occasionally need to do a
git add -kb binary.txt
to flag a file explicitely, that's a small price to pay for everything
else to work out of the box.
FWIW, I wouldn't care if git internally stored all texts as SCSU/BOCU
(or UTF-32, for that matter, if Git's compression engine is better than
SCSU or BOCU) using PARAGRAPH SEPARATOR to separate lines, just as
long as I could get back the text I checked in. Come to think about it,
locale autoconversion of text files would be a nice way to work between
systems that want different encodings, like how Windows prefers
UTF-16LE, Mac OS X prefers UTF-8 and Linux systems prefers whatever I
have set my locale to (I still use iso-8859-1, so shoot me).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-08 10:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080108100818.GA17205@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 07, 2008 at 11:29:30PM -0800, Junio C Hamano wrote:
>
>> Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
>
> I'm not sure what's causing it, but all of the addresses in your message
> (including cc headers) got munged.
I think Steffen's original got munged (I just replied to it) by
gmane's mail relaying interface.
>> > I'm asking the last question because every Unix developer should
>> > think about the option, too. Neither Unix or Windows are causing
>> > the problem alone.
>>
>> That's the logical conclusion.
>>
>> If you are introducing crlf = warn, that means you are declaring
>> that CRLF should be treated as a disease, and that should apply
>> everywhere, not just on Windows (which some people may consider
>> a disease itself, but that is a separate topic).
>
> It's unclear to me: is such a warning only supposed to happen when we
> see CRLF _after_ we have determined that a file is not actually binary?
Oh, I agree. I thought that was what Steffen was proposing.
^ permalink raw reply
* Re: [PATCH] Documentation: config: add 'help.*' and 'instaweb.*' variables.
From: Johannes Schindelin @ 2008-01-08 10:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7vabngwyra.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 7 Jan 2008, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > By the way I had no comment on my RFC/Patch to run the test scripts
> > under valgrind. Maybe it's useless because it doesn't find any bug
> > right now.
>
> I found it interesting myself. I did not know how well it fits into the
> rest of the testing infrastructure, though. Perhaps you would want to
> reopen the issue after 1.5.4?
I meant to rewrite it as a patch to test-lib.sh, because I found the use
of perl not necessary. Besides, I would like to integrate it better, i.e.
"make USE_VALGRIND=yes" or "make USE_VALGRIND=t1501:2".
Ciao,
Dscho
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Jeff King @ 2008-01-08 10:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejcswzad.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 07, 2008 at 11:29:30PM -0800, Junio C Hamano wrote:
> Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
I'm not sure what's causing it, but all of the addresses in your message
(including cc headers) got munged.
> > I'm asking the last question because every Unix developer should
> > think about the option, too. Neither Unix or Windows are causing
> > the problem alone.
>
> That's the logical conclusion.
>
> If you are introducing crlf = warn, that means you are declaring
> that CRLF should be treated as a disease, and that should apply
> everywhere, not just on Windows (which some people may consider
> a disease itself, but that is a separate topic).
It's unclear to me: is such a warning only supposed to happen when we
see CRLF _after_ we have determined that a file is not actually binary?
Otherwise, it seems like we are punishing people on sane platforms who
use binary files (although even with that check, I am slightly
uncomfortable given reports of incorrect guessing).
-Peff
^ permalink raw reply
* Re: A note from the maintainer
From: Junio C Hamano @ 2008-01-08 10:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m31w8socts.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * IRC and Mailing list
>
>> When you point at a message in a mailing list archive, using
>> gmane is often the easiest to follow by readers, like this:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
>>
>> as it also allows people who subscribe to the mailing list as
>> gmane newsgroup to "jump to" the article.
>
> Isn't it better to give Message-ID (perhaps with addition to
> some archive URLs)?
Then please do so. I have no problem with that.
But I am talking about practices of people who give pointer to
list archives as URL in this section, and I am just sick and
tired of seeing references to marc.info that does not give you
useful threaded interface.
> What about "offcuts" branch?
What about it? It is not that relevant to people new to the
community.
^ permalink raw reply
* Re: [PATCH] gitk: use user-configured background in view definition dialog
From: Gerrit Pape @ 2008-01-08 9:55 UTC (permalink / raw)
To: Paul Mackerras, git
In-Reply-To: <20071228145156.8106.qmail@6afea2d2003e0e.315fe32.mid.smarden.org>
Hi, I suggest to apply this change to gitk. Thanks, Gerrit.
On Fri, Dec 28, 2007 at 02:51:56PM +0000, Gerrit Pape wrote:
> Have the text fields in the view definition dialog (View->New view...)
> use the background color as configured through the preferences, instead
> of hard-coded 'white'.
>
> This was suggested by Paul Wise through
> http://bugs.debian.org/457124
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> gitk | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gitk b/gitk
> index 684e614..7d70c64 100755
> --- a/gitk
> +++ b/gitk
> @@ -1881,7 +1881,7 @@ proc editview {} {
>
> proc vieweditor {top n title} {
> global newviewname newviewperm viewfiles
> - global uifont
> + global uifont bgcolor
>
> toplevel $top
> wm title $top $title
> @@ -1895,12 +1895,12 @@ proc vieweditor {top n title} {
> -text [mc "Commits to include (arguments to git rev-list):"]
> grid $top.al - -sticky w -pady 5
> entry $top.args -width 50 -textvariable newviewargs($n) \
> - -background white -font uifont
> + -background $bgcolor -font uifont
> grid $top.args - -sticky ew -padx 5
> message $top.l -aspect 1000 -font uifont \
> -text [mc "Enter files and directories to include, one per line:"]
> grid $top.l - -sticky w
> - text $top.t -width 40 -height 10 -background white -font uifont
> + text $top.t -width 40 -height 10 -background $bgcolor -font uifont
> if {[info exists viewfiles($n)]} {
> foreach f $viewfiles($n) {
> $top.t insert end $f
> --
> 1.5.3.7
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git-diff across branches?
From: Jakub Narebski @ 2008-01-08 10:01 UTC (permalink / raw)
To: Jeff King; +Cc: Gonzalo Garramuño, git
In-Reply-To: <20080108085705.GA4222@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 08, 2008 at 05:44:14AM -0300, Gonzalo Garramuño wrote:
>
> > I was wondering if there was a way to make a git-diff across (local)
> > branches.
> >
> > Something like:
> >
> > $ git-diff --branch test1 HEAD --branch test2 HEAD file.cpp
> > (would show a diff for file.cpp between test1 HEAD and test2 HEAD)
>
> I think you are mistaken about how HEAD works; it is a pointer to a
> particular branch. So there is no "HEAD" for test1; there is simply
> test1, and from time to time your repository's HEAD points to test1.
>
> However, that makes things easier. You can simply do this:
>
> git-diff test1 test2 file.cpp
Canonically it is
# git diff test1 test2 -- file.cpp
but you can also use (for example if file was renamed)
# git diff test1:file.cpp test2:file.cpp
> Unless you mean that you have two separate repositories, test1 and
> test2. In which case each _does_ have its own HEAD, and you will have to
> fetch from one repo into the other to get your answer:
[cut]
Not necessary. If those two repositories are on the same local
filesystem, you can use trick from GitTips:
http://git.or.cz/gitwiki/GitTips#head-9f79516c05f0c1b51945b848adb3dd1c5a2bf016
(assuming we are in test1, and ../test2 is relative path to test2)
# GIT_ALTERNATE_OBJECT_DIRECTORIES=../test2/.git/objects git diff-tree \
$(GIT_DIR=../test2/.git git rev-parse --verify HEAD) HEAD
--
Jakub Narebski
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