* Re: how to edit commit message in history
From: Jike Song @ 2009-01-16 4:09 UTC (permalink / raw)
To: git
In-Reply-To: <20090116035714.GA6984@b2j>
On Fri, Jan 16, 2009 at 11:57 AM, bill lam <cbill.lam@gmail.com> wrote:
> I made some typos in commit messages, how to edit them without
> affecting everything else?
>
> Thanks in advance.
say, it's commit HEAD~2 to be revised.
git rebase -i HEAD~3
In your editor, you all see something like this:
pick db79377 2nd
pick fa9ced8 3rd
pick b842e49 4nd
# Rebase 1423d77..b842e49 onto 1423d77
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Now change "pick" to "edit" with your typo commit, save it and exit.
You will see something like this:
$ git-rebase -i HEAD~3
Stopped at db79377... 2nd
You can amend the commit now, with
git commit --amend
Once you are satisfied with your changes, run
git rebase --continue
Just follow the instructions.
--
Thanks,
Jike
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: George Spelvin @ 2009-01-16 4:24 UTC (permalink / raw)
To: Johannes.Schindelin, gitster; +Cc: linux, git
In-Reply-To: <20090116032708.21156.qmail@science.horizon.com>
> I don't mind doing the coding, but can someone who groks the
> code more fully tell me if I'm missing something major?
Here's a first draft, that Works For Me(tm). Does anyone see anything
broken about it?
(This code released into the public domain, copyright abandoned. You may
do anything you like with it, including evil things, as long as you
don't bother me asking for additional permissions.)
diff --git a/builtin-grep.c b/builtin-grep.c
index bebf15c..5727a8b 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -90,12 +90,74 @@ static int pathspec_matches(const char **paths, const char *name)
return 0;
}
+/*
+ * Write a filename like "/usr/src/linux/include/linux/zlib.h" as
+ * a path relative to some prefix like "/usr/src/linux/kernel/"
+ * (The prefix always includes a trailing slash.)
+ * label_len, if non-zero, describes a leading portion on the name
+ * (typically of the form "HEAD^^:") which should not be stripped off.
+ *
+ * The result is in one of three places:
+ * - It may be a pointer into the supplied name in the simplest case,
+ * - It may be returned in a static buffer if it is of reaonable size, or
+ * - It may be in a malloced buffer if it is large.
+ * A pointer to be passed to free() is returned in *to_free, which
+ * is set to NULL if the return value is not to be freed, or is equal
+ * to the return value if it is. (It could be simply a boolean, but doing
+ * it this way eliminates a test in the caller.)
+ */
+static const char *make_relative(unsigned label_len, const char *prefix, unsigned prefix_len, const char *name, void **to_free)
+{
+ static char name_buf[PATH_MAX];
+ char *cp;
+ unsigned n, match_len = 0, slashes = 0;
+ unsigned name_len;
+
+ for (n = 0; n < prefix_len; n++) {
+ if (prefix[n] != name[label_len+n]) {
+ for (; n < prefix_len; n++)
+ slashes += (prefix[n] == '/');
+ break;
+ }
+ if (prefix[n] == '/')
+ match_len = n+1;
+ }
+
+ /* Can we return a substring of the input string? */
+ if (!slashes && (!label_len || !match_len)) {
+ *to_free = NULL;
+ return name + match_len;
+ }
+
+ /* Nope, assemble the full response */
+
+ /* Output buffer will be tag + "../"*slashes + name + '\0' */
+ name_len = strlen(name + label_len + match_len) + 1;
+ n = label_len + 3*slashes + name_len + 1;
+ if (n <= ARRAY_SIZE(name_buf)) {
+ cp = name_buf;
+ *to_free = NULL;
+ } else {
+ *to_free = cp = xmalloc(n);
+ }
+
+ /* Now fill in the buffer */
+ memcpy(cp, name, label_len);
+ n = label_len;
+ while (slashes--) {
+ memcpy(cp+n, "../", 3);
+ n += 3;
+ }
+ memcpy(cp+n, name+label_len+match_len, name_len);
+ return cp;
+}
+
static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char *name, int tree_name_len)
{
unsigned long size;
char *data;
enum object_type type;
- char *to_free = NULL;
+ void *to_free = NULL;
int hit;
data = read_sha1_file(sha1, &type, &size);
@@ -103,24 +165,9 @@ static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char
error("'%s': unable to read %s", name, sha1_to_hex(sha1));
return 0;
}
- if (opt->relative && opt->prefix_length) {
- static char name_buf[PATH_MAX];
- char *cp;
- int name_len = strlen(name) - opt->prefix_length + 1;
-
- if (!tree_name_len)
- name += opt->prefix_length;
- else {
- if (ARRAY_SIZE(name_buf) <= name_len)
- cp = to_free = xmalloc(name_len);
- else
- cp = name_buf;
- memcpy(cp, name, tree_name_len);
- strcpy(cp + tree_name_len,
- name + tree_name_len + opt->prefix_length);
- name = cp;
- }
- }
+ if (opt->relative)
+ name = make_relative(tree_name_len, opt->prefix,
+ opt->prefix_length, name, &to_free);
hit = grep_buffer(opt, name, data, size);
free(data);
free(to_free);
@@ -132,6 +179,7 @@ static int grep_file(struct grep_opt *opt, const char *filename)
struct stat st;
int i;
char *data;
+ void *to_free = NULL;
size_t sz;
if (lstat(filename, &st) < 0) {
@@ -156,10 +204,12 @@ static int grep_file(struct grep_opt *opt, const char *filename)
return 0;
}
close(i);
- if (opt->relative && opt->prefix_length)
- filename += opt->prefix_length;
+ if (opt->relative)
+ filename = make_relative(0, opt->prefix, opt->prefix_length,
+ filename, &to_free);
i = grep_buffer(opt, filename, data, sz);
free(data);
+ free(to_free);
return i;
}
@@ -528,7 +578,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
int i;
memset(&opt, 0, sizeof(opt));
- opt.prefix_length = (prefix && *prefix) ? strlen(prefix) : 0;
+ opt.prefix = prefix;
+ opt.prefix_length = prefix ? strlen(prefix) : 0;
opt.relative = 1;
opt.pathname = 1;
opt.pattern_tail = &opt.pattern_list;
@@ -787,17 +838,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
verify_filename(prefix, argv[j]);
}
- if (i < argc) {
+ if (i < argc)
paths = get_pathspec(prefix, argv + i);
- if (opt.prefix_length && opt.relative) {
- /* Make sure we do not get outside of paths */
- for (i = 0; paths[i]; i++)
- if (strncmp(prefix, paths[i], opt.prefix_length))
- die("git grep: cannot generate relative filenames containing '..'");
- }
- }
else if (prefix) {
- paths = xcalloc(2, sizeof(const char *));
+ paths = xmalloc(2 * sizeof *paths);
paths[0] = prefix;
paths[1] = NULL;
}
diff --git a/grep.h b/grep.h
index 45a222d..a02dccf 100644
--- a/grep.h
+++ b/grep.h
@@ -56,6 +56,7 @@ struct grep_opt {
struct grep_pat *pattern_list;
struct grep_pat **pattern_tail;
struct grep_expr *pattern_expression;
+ const char *prefix;
int prefix_length;
regex_t regexp;
unsigned linenum:1;
^ permalink raw reply related
* Re: how to edit commit message in history
From: thestar @ 2009-01-16 4:31 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090116035714.GA6984@b2j>
You can't, that would default the whole point of git's sha1 hashes!
If you change a commit, you will change the sha1 hash of that commit,
and every subsequent commit. There is no way around it.
Quoting bill lam <cbill.lam@gmail.com>:
> I made some typos in commit messages, how to edit them without
> affecting everything else?
>
> Thanks in advance.
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> 唐詩311 無名氏 雜詩
> 盡寒食雨草萋萋 著麥苗風柳映堤 等是有家歸未得 杜鵑休向耳邊啼
> --
> 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-difftool
From: David Aguilar @ 2009-01-16 5:05 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Matthieu Moy, git
In-Reply-To: <200901152326.47332.markus.heidelberg@web.de>
On Thu, Jan 15, 2009 at 2:26 PM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> David Aguilar, 02.01.2009:
>> I now have a git-difftool wrapper script that basically just sets up
>> the environment for git-difftool-helper. git-difftool-helper does all
>> of the merge tool configuration stuff ala
>> http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html (it
>> uses the same git config variables and thus works with existing custom
>> commands). If you drop them both into the same directory it should
>> work as-is (it munges $PATH).
>>
>> It's not a two-liner (they do all that git config stuff and handle
>> more than just vimdiff) but it does use GIT_EXTERNAL_DIFF now, which
>> makes the script infinitely more useful. This is much nicer now since
>> you can pass any 'git diff' options to git-difftool and it'll handle
>> it correctly.
>>
>> The usage is simpler now too:
>>
>> usage: git difftool [--no-prompt] [--tool=tool] ["git diff" options]
>
> Now isn't this something for contrib, David?
>
> Markus
>
>
It sure is.
BTW the script worked beautifully on *nix.
I later decided to give it a try on Windows and of course it didn't
work right the first time. Once I added a check to use "git.exe"
instead of "git" then it started working again. I'll prepare some
documentation and post a patch later tonight.
Thanks for reminding me,
--
David
(p.s. Markus: sorry for the double-email -- I forgot to cc: the list)
^ permalink raw reply
* Re: How to exclude some files when using git-archive?
From: Ping Yin @ 2009-01-16 5:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v4p00otpb.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 16, 2009 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Ping Yin <pkufranky@gmail.com> writes:
>
>> I want to exclude .gitignore from the archive, but hasn't find a easy way
>>
>> Ping Yin
>
> "man gitattributes", then look for export-ignore?
>
>
Thanks. That's exactly what i want.
One question: It seems the .gitattributes doesn't take effect when
using following command
GIT_DIR=A/.git git archive HEAD > A.tar
where the files with attribute export-ignore are still exported.
Instead, i have to run
cd A && git archive HEAD > A.tar
Ping Yin
^ permalink raw reply
* Is there a way to exclude some file from a diff?
From: Ping Yin @ 2009-01-16 7:04 UTC (permalink / raw)
To: Git Mailing List
Something similar to
git diff --exclude=".gitignore" A..B
There are so many directories, so using "git diff path1 path2" is inapposite.
Ping Yin
^ permalink raw reply
* [PATCH] contrib: add 'git difftool' for launching common merge tools
From: David Aguilar @ 2009-01-16 8:00 UTC (permalink / raw)
To: git; +Cc: gitster, David Aguilar
'git difftool' is a git command that allows you to compare and edit files
between revisions using common merge tools. 'git difftool' does what
'git mergetool' does but its use is for non-merge situations such as
when preparing commits or comparing changes against the index.
It uses the same configuration variables as 'git mergetool' and
provides the same command-line interface as 'git diff'.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool | 74 +++++++++++
contrib/difftool/git-difftool-helper | 240 ++++++++++++++++++++++++++++++++++
contrib/difftool/git-difftool.txt | 104 +++++++++++++++
3 files changed, 418 insertions(+), 0 deletions(-)
create mode 100755 contrib/difftool/git-difftool
create mode 100755 contrib/difftool/git-difftool-helper
create mode 100644 contrib/difftool/git-difftool.txt
This patch was the result of the following thread on the git-list:
http://thread.gmane.org/gmane.comp.version-control.git/103918
diff --git a/contrib/difftool/git-difftool b/contrib/difftool/git-difftool
new file mode 100755
index 0000000..1fc087c
--- /dev/null
+++ b/contrib/difftool/git-difftool
@@ -0,0 +1,74 @@
+#!/usr/bin/env perl
+# Copyright (c) 2009 David Aguilar
+#
+# This is a wrapper around the GIT_EXTERNAL_DIFF-compatible
+# git-difftool-helper script. This script exports
+# GIT_EXTERNAL_DIFF and GIT_PAGER for use by git, and
+# GIT_NO_PROMPT and GIT_MERGE_TOOL for use by git-difftool-helper.
+# Any arguments that are unknown to this script are forwarded to 'git diff'.
+
+use strict;
+use warnings;
+use Cwd qw(abs_path);
+use File::Basename qw(dirname);
+
+my $DIR = abs_path(dirname($0));
+
+
+sub usage
+{
+ print << 'USAGE';
+
+usage: git difftool [--no-prompt] [--tool=tool] ["git diff" options]
+USAGE
+ exit 1;
+}
+
+sub setup_environment
+{
+ $ENV{PATH} = "$DIR:$ENV{PATH}";
+ $ENV{GIT_PAGER} = '';
+ $ENV{GIT_EXTERNAL_DIFF} = 'git-difftool-helper';
+}
+
+sub exe
+{
+ my $exe = shift;
+ return defined $ENV{COMSPEC} ? "$exe.exe" : $exe;
+}
+
+sub generate_command
+{
+ my @command = (exe('git'), 'diff');
+ my $skip_next = 0;
+ my $idx = -1;
+ for my $arg (@ARGV) {
+ $idx++;
+ if ($skip_next) {
+ $skip_next = 0;
+ next;
+ }
+ if ($arg eq '-t' or $arg eq '--tool') {
+ usage() if $#ARGV <= $idx;
+ $ENV{GIT_MERGE_TOOL} = $ARGV[$idx + 1];
+ $skip_next = 1;
+ next;
+ }
+ if ($arg =~ /^--tool=/) {
+ $ENV{GIT_MERGE_TOOL} = substr($arg, 7);
+ next;
+ }
+ if ($arg eq '--no-prompt') {
+ $ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
+ next;
+ }
+ if ($arg eq '-h' or $arg eq '--help') {
+ usage();
+ }
+ push @command, $arg;
+ }
+ return @command
+}
+
+setup_environment();
+exec(generate_command());
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
new file mode 100755
index 0000000..0b266e3
--- /dev/null
+++ b/contrib/difftool/git-difftool-helper
@@ -0,0 +1,240 @@
+#!/bin/sh
+# git-difftool-helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
+# It supports kdiff3, tkdiff, xxdiff, meld, opendiff, emerge, ecmerge,
+# vimdiff, gvimdiff, and custom user-configurable tools.
+# This script is typically launched by using the 'git difftool'
+# convenience command.
+#
+# Copyright (c) 2009 David Aguilar
+
+# Set GIT_DIFFTOOL_NO_PROMPT to bypass the per-file prompt.
+should_prompt () {
+ ! test -n "$GIT_DIFFTOOL_NO_PROMPT"
+}
+
+# Should we keep the backup .orig file?
+keep_backup_mode="$(git config --bool merge.keepBackup || echo true)"
+keep_backup () {
+ test "$keep_backup_mode" = "true"
+}
+
+# This function manages the backup .orig file.
+# A backup $MERGED.orig file is created if changes are detected.
+cleanup_temp_files () {
+ if test -n "$MERGED"; then
+ if keep_backup && test "$MERGED" -nt "$BACKUP"; then
+ test -f "$BACKUP" && mv -- "$BACKUP" "$MERGED.orig"
+ else
+ rm -f -- "$BACKUP"
+ fi
+ fi
+}
+
+# This is called when users Ctrl-C out of git-difftool-helper
+sigint_handler () {
+ echo
+ cleanup_temp_files
+ exit 1
+}
+
+# This function prepares temporary files and launches the appropriate
+# merge tool.
+launch_merge_tool () {
+ # Merged is the filename as it appears in the work tree
+ # Local is the contents of a/filename
+ # Remote is the contents of b/filename
+ # Custom merge tool commands might use $BASE so we provide it
+ MERGED="$1"
+ LOCAL="$2"
+ REMOTE="$3"
+ BASE="$1"
+ ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
+ BACKUP="$MERGED.BACKUP.$ext"
+
+ # Create and ensure that we clean up $BACKUP
+ test -f "$MERGED" && cp -- "$MERGED" "$BACKUP"
+ trap sigint_handler SIGINT
+
+ # $LOCAL and $REMOTE are temporary files so prompt
+ # the user with the real $MERGED name before launching $merge_tool.
+ if should_prompt; then
+ printf "\nViewing: '$MERGED'\n"
+ printf "Hit return to launch '%s': " "$merge_tool"
+ read ans
+ fi
+
+ # Run the appropriate merge tool command
+ case "$merge_tool" in
+ kdiff3)
+ basename=$(basename "$MERGED")
+ "$merge_tool_path" --auto \
+ --L1 "$basename (A)" \
+ --L2 "$basename (B)" \
+ -o "$MERGED" "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1
+ ;;
+
+ tkdiff)
+ "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
+ ;;
+
+ meld|vimdiff)
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ ;;
+
+ gvimdiff)
+ "$merge_tool_path" -f "$LOCAL" "$REMOTE"
+ ;;
+
+ xxdiff)
+ "$merge_tool_path" \
+ -X \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" \
+ "$LOCAL" "$REMOTE"
+ ;;
+
+ opendiff)
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -merge "$MERGED" | cat
+ ;;
+
+ ecmerge)
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ --default --mode=merge2 --to="$MERGED"
+ ;;
+
+ emerge)
+ "$merge_tool_path" -f emerge-files-command \
+ "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
+ ;;
+
+ *)
+ if test -n "$merge_tool_cmd"; then
+ ( eval $merge_tool_cmd )
+ fi
+ ;;
+ esac
+
+ cleanup_temp_files
+}
+
+# Verifies that mergetool.<tool>.cmd exists
+valid_custom_tool() {
+ merge_tool_cmd="$(git config mergetool.$1.cmd)"
+ test -n "$merge_tool_cmd"
+}
+
+# Verifies that the chosen merge tool is properly setup.
+# Built-in merge tools are always valid.
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ ;; # happy
+ *)
+ if ! valid_custom_tool "$1"
+ then
+ return 1
+ fi
+ ;;
+ esac
+}
+
+# Sets up the merge_tool_path variable.
+# This handles the mergetool.<tool>.path configuration.
+init_merge_tool_path() {
+ merge_tool_path=$(git config mergetool."$1".path)
+ if test -z "$merge_tool_path"; then
+ case "$1" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path="$1"
+ ;;
+ esac
+ fi
+}
+
+# Allow the GIT_MERGE_TOOL variable to provide a default value
+test -n "$GIT_MERGE_TOOL" && merge_tool="$GIT_MERGE_TOOL"
+
+# If not merge tool was specified then use the merge.tool
+# configuration variable. If that's invalid then reset merge_tool.
+if test -z "$merge_tool"; then
+ merge_tool=$(git config merge.tool)
+ if test -n "$merge_tool" && ! valid_tool "$merge_tool"; then
+ echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
+ echo >&2 "Resetting to default..."
+ unset merge_tool
+ fi
+fi
+
+# Try to guess an appropriate merge tool if no tool has been set.
+if test -z "$merge_tool"; then
+
+ # We have a $DISPLAY so try some common UNIX merge tools
+ if test -n "$DISPLAY"; then
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ # If gnome then prefer meld
+ if test -n "$GNOME_DESKTOP_SESSION_ID"; then
+ merge_tool_candidates="meld $merge_tool_candidates"
+ fi
+ # If KDE then prefer kdiff3
+ if test "$KDE_FULL_SESSION" = "true"; then
+ merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ fi
+ fi
+
+ # $EDITOR is emacs so add emerge as a candidate
+ if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates emerge"
+ fi
+
+ # $EDITOR is vim so add vimdiff as a candidate
+ if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates vimdiff"
+ fi
+
+ merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
+ echo "merge tool candidates: $merge_tool_candidates"
+
+ # Loop over each candidate and stop when a valid merge tool is found.
+ for i in $merge_tool_candidates
+ do
+ init_merge_tool_path $i
+ if type "$merge_tool_path" > /dev/null 2>&1; then
+ merge_tool=$i
+ break
+ fi
+ done
+
+ if test -z "$merge_tool" ; then
+ echo "No known merge resolution program available."
+ exit 1
+ fi
+
+else
+ # A merge tool has been set, so verify that it's valid.
+ if ! valid_tool "$merge_tool"; then
+ echo >&2 "Unknown merge tool $merge_tool"
+ exit 1
+ fi
+
+ init_merge_tool_path "$merge_tool"
+
+ if test -z "$merge_tool_cmd" && ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+ fi
+fi
+
+
+# Launch the merge tool on each path provided by 'git diff'
+while test $# -gt 6
+do
+ launch_merge_tool "$1" "$2" "$5"
+ shift 7
+done
diff --git a/contrib/difftool/git-difftool.txt b/contrib/difftool/git-difftool.txt
new file mode 100644
index 0000000..3940c70
--- /dev/null
+++ b/contrib/difftool/git-difftool.txt
@@ -0,0 +1,104 @@
+git-difftool(1)
+===============
+
+NAME
+----
+git-difftool - compare changes using common merge tools
+
+SYNOPSIS
+--------
+'git difftool' [--tool=<tool>] [--no-prompt] ['git diff' options]
+
+DESCRIPTION
+-----------
+'git difftool' is a git command that allows you to compare and edit files
+between revisions using common merge tools. At its most basic level,
+'git difftool' does what 'git mergetool' does but its use is for non-merge
+situations such as when preparing commits or comparing changes against
+the index.
+
+'git difftool' is a frontend to 'git diff' and accepts the same
+arguments and options.
+
+See linkgit:git-diff[7] for the full list of supported options.
+
+OPTIONS
+-------
+-t <tool>::
+--tool=<tool>::
+ Use the merge resolution program specified by <tool>.
+ Valid merge tools are:
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
++
+If a merge resolution program is not specified, 'git difftool'
+will use the configuration variable `merge.tool`. If the
+configuration variable `merge.tool` is not set, 'git difftool'
+will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable `mergetool.<tool>.path`. For example, you
+can configure the absolute path to kdiff3 by setting
+`mergetool.kdiff3.path`. Otherwise, 'git difftool' assumes the
+tool is available in PATH.
++
+Instead of running one of the known merge tool programs,
+'git difftool' can be customized to run an alternative program
+by specifying the command line to invoke in a configuration
+variable `mergetool.<tool>.cmd`.
++
+When 'git difftool' is invoked with this tool (either through the
+`-t` or `--tool` option or the `merge.tool` configuration variable)
+the configured command line will be invoked with the following
+variables available: `$LOCAL` is set to the name of the temporary
+file containing the contents of the diff pre-image and `$REMOTE`
+is set to the name of the temporary file containing the contents
+of the diff post-image. `$BASE` is provided for compatibility
+with custom merge tool commands and has the same value as `$LOCAL`.
+
+--no-prompt::
+ Do not prompt before launching a merge tool.
+
+CONFIG VARIABLES
+----------------
+merge.tool::
+ The default merge tool to use.
++
+See the `--tool=<tool>` option above for more details.
+
+merge.keepBackup::
+ The original, unedited file content can be saved to a file with
+ a `.orig` extension. Defaults to `true` (i.e. keep the backup files).
+
+mergetool.<tool>.path::
+ Override the path for the given tool. This is useful in case
+ your tool is not in the PATH.
+
+mergetool.<tool>.cmd::
+ Specify the command to invoke the specified merge tool.
++
+See the `--tool=<tool>` option above for more details.
+
+
+SEE ALSO
+--------
+linkgit:git-diff[7]::
+ Show changes between commits, commit and working tree, etc
+
+linkgit:git-mergetool[1]::
+ Run merge conflict resolution tools to resolve merge conflicts
+
+linkgit:git-config[7]::
+ Get and set repository or global options
+
+
+AUTHOR
+------
+Written by David Aguilar <davvid@gmail.com>.
+
+Documentation
+--------------
+Documentation by David Aguilar and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.6.1.149.g7bbd8
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Kirill Smelkov @ 2009-01-16 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4eos3rp.fsf@gitster.siamese.dyndns.org>
On Thu, Jan 15, 2009 at 12:39:06PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
>
> > Sorry for the inconvenience, and please pull them all from
> >
> > git://repo.or.cz/git/kirr.git for-junio
> >
> > Kirill Smelkov (4):
> > mailinfo: 'From:' header should be unfold as well
> > mailinfo: more smarter removal of rfc822 comments from 'From'
> > mailinfo: correctly handle multiline 'Subject:' header
> > mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
>
> Sorry, but I cannot _pull_ this one; not because these four patches are
> bad (I haven't looked at them).
>
> They include all the other totally unrelated stuff that happend on the
> master branch since the topic ks/maint-mailinfo-folded forked. I've been
> hoping upon completion of this topic we can merge it down to maint to
> propagate the fix back to v1.6.1.X series.
>
> With this alias:
>
> $ git config alias.lg log --pretty=oneline --abbrev-commit --boundary --left-right
>
> Here are what I have queued so far (and they are in next):
>
> $ git lg master..ks/maint-mailinfo-folded
> >ddfb369... mailinfo: 'From:' header should be unfold as well
> >353aaf2... mailinfo: correctly handle multiline 'Subject:' header
> -141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
>
> $ git lg maint..ks/maint-mailinfo-folded
> >ddfb369... mailinfo: 'From:' header should be unfold as well
> >353aaf2... mailinfo: correctly handle multiline 'Subject:' header
> -141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
>
> 141201d is only three commits ahead of v1.6.0.6 and
>
> $ git lg v1.6.0.6..141201d
>
> will show that we _could_ even issue v1.6.0.7 with the fixes in this topic
> if we cared about this bug deeply enough. If I pull the above to the
> topic, we'll lose the ability to propagate these fixes to the maintenance
> serires.
>
> So please either say "Yes, you are welcome to cherry-pick -- fetching and
> cherry-picking would be easier than e-mail for this kind of patch", or
> "Ok, I'll rebase my series on top of ddfb369".
>
> Well, I just noticed that some of your commits already conflict with the
> two patches that I already have, so I guess we would need at least one
> rebase anyway, so this time around, I'd really prefer you not to say "you
> are welcome to cherry-pick" ;-)
Sure, I've rebased my series on top of ddfb369 :)
git://repo.or.cz/git/kirr.git for-junio-maint
Kirill Smelkov (3):
mailinfo: more smarter removal of rfc822 comments from 'From'
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
mailinfo: tests for RFC2047 examples
Thanks,
Kirill
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Junio C Hamano @ 2009-01-16 8:21 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: git
In-Reply-To: <20090116080807.GA10792@landau.phys.spbu.ru>
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> On Thu, Jan 15, 2009 at 12:39:06PM -0800, Junio C Hamano wrote:
> ...
>> So please either say "Yes, you are welcome to cherry-pick -- fetching and
>> cherry-picking would be easier than e-mail for this kind of patch", or
>> "Ok, I'll rebase my series on top of ddfb369".
>>
>> Well, I just noticed that some of your commits already conflict with the
>> two patches that I already have, so I guess we would need at least one
>> rebase anyway, so this time around, I'd really prefer you not to say "you
>> are welcome to cherry-pick" ;-)
>
> Sure, I've rebased my series on top of ddfb369 :)
>
> git://repo.or.cz/git/kirr.git for-junio-maint
>
>
> Kirill Smelkov (3):
> mailinfo: more smarter removal of rfc822 comments from 'From'
> mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
> mailinfo: tests for RFC2047 examples
Thanks.
I thought there is somebody on this list who insists his name is of form:
From: A U Thor (MonikeR) <a.u@thor.xz>
and vaguely recall the current code was tweaked to keep that extra moniker
in his (or her?) name. It is too late at night for me to double check but
I suspect the first one in the series may break things for that kind of
names.
^ permalink raw reply
* Weird behaviour of git status
From: Nicolas Morey-Chaisemartin @ 2009-01-16 8:42 UTC (permalink / raw)
To: git@vger.kernel.org
Hello everyone,
I just noticed a weird behaviour in git status.
I have created new files in different directories in my project.
I have added all of them in the index with git add.
When I run "git status" It shows me that all my 3 files are in the index.
However if I run git-status specifying a directory, it returns that the
file in this directory are in the index but the other one isn't.
In my opinion, it should
- either display all the files as in the index (specifying a directory
wouldn't have any effect then)
- treat only file in the specified dir. So "external" files wouldn't be
shown at all.
Thanks
Nicolas
Here are the logs
_________________________
moreychn@uranus-ubuntu:~/workspace/git/osmdc$ git --version
git version 1.6.1
moreychn@uranus-ubuntu:~/workspace/git/osmdc/include$ git status
# On branch v3
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: devmgr_common.h
# new file: devmgr_types.h
# new file: ../src/devmgr_common.c
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: ../src/osmdc_devmgr.h
#
moreychn@uranus-ubuntu:~/workspace/git/osmdc/include$ git status .
# On branch v3
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: devmgr_common.h
# new file: devmgr_types.h
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: ../src/osmdc_devmgr.h
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ../src/devmgr_common.c
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Santi Béjar @ 2009-01-16 9:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Teemu Likonen,
Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901160253210.3586@pacific.mpi-cbg.de>
2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 16 Jan 2009, Santi Béjar wrote:
>
>> If everything works as I think (it's late night :-) with the above two lines:
>>
>> matrix[a,b,c]
>> matrix{d,b,c}
>>
>> the word diff would be
>>
>> matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
>
> So I guess that you want something like
>
> [A-Za-z0-9]+|[^A-Za-z0-9 \t]+
>
> Note: I only want to help you finding what you actually want, I am not
> trying to find it for you.
>
Thanks all for the answers.
So, I see, it is a matter of finding the right regexp.
But the only use case for me is of this kind, and I think for the
others too. So maybe an easier way to specify it could be worth. But
I'll write an alias as this is the only regexp I would use, apart from
the default word diff.
Thanks,
Santi
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Jens Seidel @ 2009-01-16 9:03 UTC (permalink / raw)
To: git; +Cc: schacon
In-Reply-To: <20090116015439.GF12275@machine.or.cz>
On Fri, Jan 16, 2009 at 02:54:39AM +0100, Petr Baudis wrote:
> On Thu, Jan 15, 2009 at 04:53:48PM +0100, Johannes Schindelin wrote:
> > sorry to bother you between two games of Go; Could you have a look at the
> > 'mail' link with the commit "Update 1.6.2 draft release notes"? It is not
> > working for me...
> >
> > That is, it links to marc (not gmane?) but finds no matches...
Just a side note: The link to the mailing list on http://git-scm.com/ is also
not optimal as it refers to gmane. I tried to subscribe but found only a link
to http://dir.gmane.org/gmane.comp.version-control.git and no instructions how
to subscribe ...
Jens
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Thomas Rast @ 2009-01-16 9:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151510340.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
Johannes Schindelin wrote:
> - AFAICT your version could never be convinced to resurrect deleted
> branches, without resorting to reflogs anyway.
Speaking of resurrection, there are other possible sources that a
branch tip could be gleaned from. How about the script below? The
advantage is that it can even be used to recover Junio's topic
branches by looking at the merges in 'pu'.
(I'll answer the rest later.)
--- 8< ---
#!/bin/sh
. git-sh-setup
USAGE="<branch>"
test "$#" = 1 || usage
branch="$1"
candidates=
search_reflog () {
next=
git reflog show HEAD |
while read sha ref msg; do
if test -n "$next"; then
next=
echo ${sha%...}
fi
if echo "$msg" | grep -q "^checkout: moving from $branch "; then
next=t
fi
if echo "$msg" | grep -q "^merge $branch:"; then
git rev-list --parents -1 ${sha%...} \
| cut -d' ' -f3
fi
done
}
search_merges () {
git rev-list --pretty=tformat:"%h %p:%s" --all |
grep "Merge branch.*'$branch'.*into" |
while read sha rest; do
parents="$(echo "$rest" | cut -d: -f1)"
case "$parents" in
*' '*' '*)
warn "$branch took part in octopus merge $sha"
warn "check manually!"
;;
*' '*)
echo "$parents" | cut -d' ' -f2
;;
esac
done
}
search_merge_targets () {
git rev-list --pretty=tformat:"%h %s" --all |
grep "Merge branch '[^']*' into $branch$" |
cut -d' ' -f1
}
candidates="$(search_reflog | sort -u)"
if test -z "$candidates"; then
echo "** Searching merges... **"
candidates="$( (search_merges;search_merge_targets) | sort -u)"
fi
echo "** Candidates **"
for cmt in $candidates; do
git --no-pager log --pretty=oneline --abbrev-commit -1 $cmt
done
newest=$(git rev-list -1 $candidates)
if ! git rev-parse --verify --quiet $branch >/dev/null; then
printf "** Restoring $branch to "
git --no-pager log -1 --pretty=tformat:"%h %s" $newest
git branch $branch $newest
else
printf "Most recent among them: "
git --no-pager log -1 --pretty=tformat:"%h %s" $newest
echo "** $branch already exists, doing nothing"
fi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Weird behaviour of git status
From: Wincent Colaiuta @ 2009-01-16 9:44 UTC (permalink / raw)
To: devel; +Cc: git@vger.kernel.org
In-Reply-To: <4970488B.3010608@morey-chaisemartin.com>
El 16/1/2009, a las 9:42, Nicolas Morey-Chaisemartin escribió:
> Hello everyone,
>
> I just noticed a weird behaviour in git status.
> I have created new files in different directories in my project.
> I have added all of them in the index with git add.
> When I run "git status" It shows me that all my 3 files are in the
> index.
> However if I run git-status specifying a directory, it returns that
> the
> file in this directory are in the index but the other one isn't.
>
> In my opinion, it should
> - either display all the files as in the index (specifying a directory
> wouldn't have any effect then)
> - treat only file in the specified dir. So "external" files wouldn't
> be
> shown at all.
"git status" shows you what would be committed if you ran "git commit"
with the same parameters. So in your example, the output for "git
status ." is exactly as you would expect.
This is stated in the man page.
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johan Herland @ 2009-01-16 9:50 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Wincent Colaiuta, Johannes Schindelin,
Junio C Hamano, Sverre Rabbelier, Johannes Sixt,
Anders Melchiorsen
In-Reply-To: <76718490901151226l704d119bh297db4e91a4da05b@mail.gmail.com>
On Thursday 15 January 2009, Jay Soffian wrote:
> On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta <win@wincent.com> wrote:
> > wait - best suggestion so far, seeing as we can't use "stop"
> This is a fun game. I like the color "halt".
Nice. I like this one as well.
After some more thinking (triggered by Junio's recent post in another
subthread), it occured to me that the current behaviour (currently known
as "edit") is not something that is applied to one of the commits in the
rebase list per se, but rather something that affects the rebase machinery
*between* commits. So instead of
edit e8902c1 Foo
we should consider something like
pick e8902c1 Foo
halt
which I think better encapsulates the current behaviour. (IOW, insert "halt"
wherever you'd like to muck about with the history; e.g.
doing "commit --amend", inserting extra commits, etc.)
We can then make shortcuts for common actions:
amend e8902c1 Foo
does a "pick" followed by "commit --amend" (for editing the commit message),
followed by "rebase --continue". Finally, we implement Anders' suggestion:
modify e8902c1 Foo
(or whatever synonym for "edit" we converge on) does a "pick" followed by
a "reset --soft HEAD^", followed by a "halt".
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: autoconf: C99 format check
From: Ralf Wildenhues @ 2009-01-16 9:41 UTC (permalink / raw)
To: Julius Naperkowski; +Cc: git
In-Reply-To: <loom.20090115T123123-915@post.gmane.org>
Hello Julius,
* Julius Naperkowski wrote on Thu, Jan 15, 2009 at 02:22:54PM CET:
> I am trying to cross-compile git for mips on a x86 host. But it seems that it is
> impossible to pass the C99 Format check in the configure script when
> cross_compile mode is activated because the script quits even before it starts
> the testprogramm. Is this behavior intentional?
Cross compilation assumes that test programs can be compiled and linked,
but not executed on the build system, i.e., at configure time. The
fourth argument of AC_RUN_IFELSE may be used to set a default test
result value in the cross compilation case, typically either a
pessimistic default, or one based on $host or so (using $host requires
AC_CANONICAL_HOST, and the config.{guess,sub} scripts).
As a workaround, you the user can pass preset results if you know what
features the host system will have, to configure. git's configure
script uses three runtime tests. You can set them with something like
./configure ac_cv_c_c99_format=yes \
ac_cv_fread_reads_directories=no \
ac_cv_snprintf_returns_bogus=no --host=... ...
although I'm not quite sure if uclibc's *printf functions indeed do
support C99 size specifiers (I think they do though).
I can post a patch to add sane default settings for AC_RUN_IFELSE in
cross compile setups, this weekend.
Cheers,
Ralf
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Anders Melchiorsen @ 2009-01-16 10:27 UTC (permalink / raw)
To: Johan Herland
Cc: git, Jay Soffian, Wincent Colaiuta, Johannes Schindelin,
Junio C Hamano, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <200901161050.13971.johan@herland.net>
Johan Herland wrote:
> edit e8902c1 Foo
>
> we should consider something like
>
> pick e8902c1 Foo
> halt
Of all the suggestions, I like this one the most. Also, when placed like
this, I am suddenly no longer opposed to the word "halt".
> amend e8902c1 Foo
>
> does a "pick" followed by "commit --amend" (for editing the commit
> message), followed by "rebase --continue".
I do not think that "amend" is the best word for editing only the commit
message. A "commit --amend" can also make a new tree, so reusing the word
with a different meaning could be bad.
As for alternatives, however, I can only come up with "copyedit", and that
is so horrible that I will not even propose it :-)
Cheers,
Anders.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johan Herland @ 2009-01-16 10:58 UTC (permalink / raw)
To: Anders Melchiorsen
Cc: git, Jay Soffian, Wincent Colaiuta, Johannes Schindelin,
Junio C Hamano, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <49548.bFoQE3daRhY=.1232101666.squirrel@webmail.hotelhot.dk>
On Friday 16 January 2009, Anders Melchiorsen wrote:
> Johan Herland wrote:
> > amend e8902c1 Foo
> >
> > does a "pick" followed by "commit --amend" (for editing the commit
> > message), followed by "rebase --continue".
>
> I do not think that "amend" is the best word for editing only the
> commit message. A "commit --amend" can also make a new tree, so
> reusing the word with a different meaning could be bad.
>
> As for alternatives, however, I can only come up with "copyedit", and
> that is so horrible that I will not even propose it :-)
"rephrase"?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-16 11:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200901161008.16234.trast@student.ethz.ch>
Hi,
On Fri, 16 Jan 2009, Thomas Rast wrote:
> search_reflog () {
> next=
> git reflog show HEAD |
> while read sha ref msg; do
> if test -n "$next"; then
> next=
> echo ${sha%...}
> fi
> if echo "$msg" | grep -q "^checkout: moving from $branch "; then
> next=t
> fi
> if echo "$msg" | grep -q "^merge $branch:"; then
> git rev-list --parents -1 ${sha%...} \
> | cut -d' ' -f3
> fi
> done
> }
How about this instead:
search_reflog () {
sed -n 's/\([^ ]*\) .*\tcheckout: moving from $branch .*/\1/p' \
< .git/logs/HEAD
}
Of course, this leaves out the merges... but I'd make that a command line
option anyway: would you like to resurrect a branch that you recently were
on, or one that you recently merged, or one that was merged by someone
else?
Ciao,
Dscho
^ permalink raw reply
* Re: how to edit commit message in history
From: Jakub Narebski @ 2009-01-16 11:18 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090116035714.GA6984@b2j>
bill lam <cbill.lam@gmail.com> writes:
> I made some typos in commit messages, how to edit them without
> affecting everything else?
If it is last commit that you want to edit, and if you didn't publish
this commit to soem public repository, you can simply use
$ git commit --amend
If the commit is deeper in history, use "git rebase --interactive".
If you published commit, you are out of luck.
See http://git.or.cz/gitwiki/GitTips
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Johannes Schindelin @ 2009-01-16 11:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
Hi,
On Fri, 16 Jan 2009, Petr Baudis wrote:
> On Fri, Jan 16, 2009 at 03:17:14AM +0100, Johannes Schindelin wrote:
>
> > I wondered what the point was, and I would _welcome_ links that
> > pointed to the mails containing the patches (identified either by
> > patch ids or by manual editing; best would be to have both methods at
> > the same time).
>
> Well, but you already have that, or at least an approximation.
Oh, I see! Somehow I missed that this link exists for all non-merge
commits...
> I was not actually planning to carry the patch over the next gitweb
> update since I got no feedback on it (IIRC) since I implemented it.
Well, now you got one: I find it nice. And I agree with you on the false
positive thing: it is better to have that link also for commits for which
no mails can be found.
I just had to scratch my head about what "mail" is about...
Ciao,
Dscho
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Johannes Schindelin @ 2009-01-16 11:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
Hi,
On Fri, 16 Jan 2009, Petr Baudis wrote:
> On Fri, Jan 16, 2009 at 03:17:14AM +0100, Johannes Schindelin wrote:
> > On Thu, 15 Jan 2009, Junio C Hamano wrote:
> >
> > > Petr Baudis <pasky@suse.cz> writes:
> > >
> > > >> That is, it links to marc (not gmane?) but finds no matches...
> > > >
> > > > what mailing list post should it point to?
> >
> > I found gmane to be much nicer to click through than marc.
>
> IIRC I found no way to actually make a gmane link since it requires POST
> query for the searches or something.
The site seems to be down ATM, but it should be
http://search.gmane.org/search.php?group=gmane.comp.version-control.git&query=pasky
BTW how about calling the link "find mail"? When I saw "mail" first time,
I thought "oh, so I can mail that commitdiff to somebody? Nice, let's
try."
Ciao,
Dscho
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: SZEDER Gábor @ 2009-01-16 11:41 UTC (permalink / raw)
To: George Spelvin; +Cc: Johannes.Schindelin, gitster, git
In-Reply-To: <20090116032708.21156.qmail@science.horizon.com>
On Thu, Jan 15, 2009 at 10:27:08PM -0500, George Spelvin wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Or perhaps someone did more than two years ago with --full-name?
>
> Thank you for pointing that out! It's a bit of a handful to type,
Well, if you happen to use bash, you will find our excellent ;) bash
completion script under contrib/completion.
hth,
Gábor
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Johannes Schindelin @ 2009-01-16 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kirill Smelkov, git
In-Reply-To: <7vd4enacf2.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 16 Jan 2009, Junio C Hamano wrote:
> I thought there is somebody on this list who insists his name is of form:
>
> From: A U Thor (MonikeR) <a.u@thor.xz>
It is Philippe Bruhat (BooK), who sometimes forgets the closing
parenthesis, and who is listed in .mailmap without the moniker.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Johannes Schindelin @ 2009-01-16 11:57 UTC (permalink / raw)
To: Santi Béjar
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Teemu Likonen,
Thomas Rast, git
In-Reply-To: <adf1fd3d0901160102y32a08e26q96728495fc0b6fcf@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 853 bytes --]
Hi,
On Fri, 16 Jan 2009, Santi Béjar wrote:
> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >
> > On Fri, 16 Jan 2009, Santi Béjar wrote:
> >
> >> If everything works as I think (it's late night :-) with the above
> >> two lines:
> >>
> >> matrix[a,b,c]
> >> matrix{d,b,c}
> >>
> >> the word diff would be
> >>
> >> matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
> >
> > So I guess that you want something like
> >
> > [A-Za-z0-9]+|[^A-Za-z0-9 \t]+
> >
>
> So, I see, it is a matter of finding the right regexp.
>
> But the only use case for me is of this kind, and I think for the
> others too. So maybe an easier way to specify it could be worth.
Sure. If you can come up with a nice name for it, we could add special
handling for something like "[[:words:]]" expanding into said regexp.
Ciao,
Dscho
^ 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