* What's in git.git (stable frozen)
From: Junio C Hamano @ 2008-01-05 10:46 UTC (permalink / raw)
To: git; +Cc: Tsugikazu Shibata, Marco Costalba, Jeff King, Dan McGee,
Dmitry Potapov
In-Reply-To: <7vfxxtu5ov.fsf@gitster.siamese.dyndns.org>
We are not at -rc3 yet, but we will be soon. What we have
accumulated in 'master' are mostly fixes, and the official
git-gui 0.9.1 is also included tonight.
I have to apologize that tonight I got a bit carried away
enjoying arguing for the sake of arguing. Some patches that
might be worthy even though they are late in the cycle are not
in tonight's 'master', mostly because I have to sleep on them,
and partly because I am running out of time tonight.
* Tsugikazu Shibata's git-diff hunk header change.
I have a counterproposal that I think is more in line with
the other parts of the system. As the kernel project has
ja_JP, ko_KR and zh_CN directories under Documentation these
days, the issue this patch addresses is already real, and we
would want to have a solution in 1.5.4, even though the topic
was raised too late in the cycle. I think my first two
patches could be a good starting point for that. I'd exclude
the last patch in the series that acts on gitattributes for
now.
* Marco's git-stash changes to output to stdout.
I'd probably apply this, with a slightly toned down commit
log message. Marco says some practice is standard, I
disagreed, but that is not a reason to say "this practice is
nonstandard and bad". Simply saying "some do this and it is
better to be helpful to them because there is no strong
reason not to" would be good enough.
* Jeff's git-add--interactive change to always honor color.diff
regardless of color.interactive.
I'd probably apply this, along with the patch to redefine
what color.interactive means. "git am -i" could also learn
to use colors in the future.
Incidentally I noticed that many of the color.diff.* palette
options are read by "git-add -i" but never used by the
script. We might want to fix this while we are at it.
* Dan McGee's workaround to breakage caused by changes in
AsciiDoc 8.2.3.
I have to do my usual "before-and-after comparison" with
copies of AsciiDoc versions that should not be affected by
the breakage, which I did not have time to do so far. But
this is probably a must-have before the release.
* My patch to error out "git stash clear foobar".
This should be applied; it is a good safety measure
regardless of where that "git stash drop" thing would go.
An issue worth addressing before the release is still in limbo.
* Dmitry's git-filter-branch fix to disambiguate the refs being
rewritten.
Addition of "git-rev-parse --symbolic-full" may solve this
more cleanly than the patches in the discussion, but we
haven't reached the conclusion of this thread yet.
Anything I missed?
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Alex Riesen (1):
Allow selection of different cleanup modes for commit messages
Arjen Laarhoven (1):
Fix "git log --diff-filter" bug
Bernt Hansen (1):
git-gui: Make commit log messages end with a newline
Eric Wong (2):
git-svn: allow dcommit --no-rebase to commit multiple, dependent changes
git-svn: unlink index files that were globbed, too
Grégoire Barbier (1):
Fix double-free() in http-push.c:remote_exists()
Gustaf Hendeby (2):
shortlog manpage documentation: work around asciidoc markup issues
Documentation/user-manual.txt: fix typo
J. Bruce Fields (1):
Documentation: fix remote.<name>.skipDefaultUpdate description
Jeff King (6):
cvsimport: die on cvsps errors
config: handle lack of newline at end of file better
git-reset: refuse to do hard reset in a bare repository
add a "basic" diff config callback
diff: load funcname patterns in "basic" config
diff: remove lazy config loading
Jim Meyering (2):
Fix grammar nits in documentation and in code comments.
Don't access line[-1] for a zero-length "line" from fgets.
Johannes Schindelin (1):
Optimize prefixcmp()
Johannes Sixt (1):
git-gui: Move frequently used commands to the top of the context menu.
Junio C Hamano (20):
t7005: do not exit inside test.
builtin-commit: fix amending of the initial commit
builtin-commit: avoid double-negation in the code.
Fix documentation of --first-parent in git-log and copy it to
git-rev-list
combine-diff: Fix path quoting
Fix rewrite_diff() name quoting.
contrib: resurrect scripted git-revert.
GIT 1.5.4-rc2
Documentation/git-submodule.txt: typofix
"git pull --tags": error out with a better message.
git-rebase -i behaves better on commits with incomplete messages
git-rebase -i: clean-up error check codepath.
lock_any_ref_for_update(): reject wildcard return from check_ref_format
Update callers of check_ref_format()
Uninline prefixcmp()
git-clean: make "Would remove ..." path relative to cwd again
t/t7600: avoid GNUism in grep
t/t{3600,3800,5401}: do not use egrep when grep would do
t/t3800: do not use a temporary file to hold expected result.
Update draft release notes for 1.5.4
Marco Costalba (1):
Document git-reset defaults to HEAD if no commit is given
Mark Levedahl (1):
git-gui: Unconditionally use absolute paths with Cygwin
Martin Koegler (2):
receive-pack: check object type of sha1 before using them as commits
receive-pack: reject invalid refnames
Michael Stefaniuc (1):
git-am: Run git gc only once and not for every patch.
Miklos Vajna (2):
git-sh-setup: document git_editor() and get_author_ident_from_commit()
t/t7001: avoid unnecessary ERE when using grep
Peter Karlsson (1):
Added Swedish translation.
René Scharfe (1):
Make "--pretty=format" parser a bit more careful.
Shawn O. Pearce (2):
git-gui: Handle file mode changes (644->755) in diff viewer
Improve error messages when int/long cannot be parsed from config
^ permalink raw reply
* Re: [PATCH/resend] add--interactive: allow diff colors without interactive colors
From: Matthias Kestenholz @ 2008-01-05 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v3atdi0na.fsf@gitster.siamese.dyndns.org>
(trying to resend because vger.kernel.org would not let the previous
email pass to the list. I am very sorry. The Evolution MUA is making
trouble.)
On Fri, 2008-01-04 at 16:20 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Users with color.diff set to true/auto will not see color in
> > "git add -i" unless they also set color.interactive.
> >
> > However, some users may want just one without the other, so
> > there's no reason to tie them together.
> >
> > Note that there is now no way to have color on for "git
> > diff" but not for diffs from "git add -i"; such a
> > configuration seems unlikely, though.
>
> Although I would agree with what this patch does, I think you
> are contradicting with yourself in the above justification.
> Some users may want to color "git diff" output but not
> interaction with "git add -i", and that's also "just one without
> the other", but you just tied them together, only differently,
> and "seems unlikely" is a rather weak excuse.
>
> The justification should instead be: having more independent
> knobs is not necessarily better. The user should not have to
> tweak too many knobs.
>
> In the longer term, I think we should try reducing the number of
> knobs by giving "color.git" that allows you to pretend as if all
> of the "color.interactive", "color.diff", "color.status",
> "color.someothercolorizedcommand" are all set. I do not think
> being able to control the use of colors per command is giving
> much other than confusion to the user.
>
> That may not be so easy with the current structure of the config
> reader, though.
I managed to throw something together which works and passes all
the tests. Documentation included. :-)
I would be happy for feedback and suggestions.
-- 8< --
>From 90663fa5a7ac1a59d74aab3aa4d2bd8397340bd4 Mon Sep 17 00:00:00 2001
From: Matthias Kestenholz <matthias@spinlock.ch>
Date: Sat, 5 Jan 2008 11:20:08 +0100
Subject: [PATCH] Add global color config switch color.git
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/config.txt | 6 ++++++
builtin-branch.c | 4 ++--
builtin-log.c | 3 ++-
cache.h | 1 +
color.c | 12 ++++++++++++
color.h | 3 +++
diff.c | 4 ++--
git-add--interactive.perl | 4 ++--
wt-status.c | 4 ++--
9 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ee08845..0a40102 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -405,6 +405,12 @@ color.diff.<slot>::
whitespace errors). The values of these variables may be specified as
in color.branch.<slot>.
+color.git::
+ 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. Defaults to false.
+
color.interactive::
When set to `always`, always use colors in `git add --interactive`.
When false (or `never`), never. When set to `true` or `auto`, use
diff --git a/builtin-branch.c b/builtin-branch.c
index 089cae5..8179938 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -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_use_color_config(var, value) || git_default_config(var, value);
}
static const char *branch_get_color(enum color_branch ix)
{
- if (branch_use_color)
+ if (branch_use_color || git_use_color)
return branch_colors[ix];
return "";
}
diff --git a/builtin-log.c b/builtin-log.c
index dcc9f81..03ba732 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -436,7 +436,8 @@ static int git_format_config(const char *var, const char *value)
fmt_patch_suffix = xstrdup(value);
return 0;
}
- if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
+ if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")
+ || !strcmp(var, "color.git")) {
return 0;
}
if (!strcmp(var, "format.numbered")) {
diff --git a/cache.h b/cache.h
index 39331c2..0968551 100644
--- a/cache.h
+++ b/cache.h
@@ -329,6 +329,7 @@ extern size_t packed_git_window_size;
extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
extern int auto_crlf;
+extern int git_use_color;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/color.c b/color.c
index 7f66c29..c891fd8 100644
--- a/color.c
+++ b/color.c
@@ -3,6 +3,8 @@
#define COLOR_RESET "\033[m"
+int git_use_color = 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_use_color_config(const char *var, const char *value)
+{
+ if(!strcmp(var, "color.git")) {
+ git_use_color = git_config_colorbool(var, value, -1);
+ return 1;
+ }
+
+ return 0;
+}
+
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..929ebf2 100644
--- a/color.h
+++ b/color.h
@@ -4,7 +4,10 @@
/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
#define COLOR_MAXLEN 24
+extern int git_use_color;
+
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
+int git_use_color_config(const char *var, const char *value);
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
diff --git a/diff.c b/diff.c
index 5bdc111..5fa6d14 100644
--- a/diff.c
+++ b/diff.c
@@ -184,7 +184,7 @@ int git_diff_ui_config(const char *var, const char *value)
return 0;
}
- return git_default_config(var, value);
+ return git_use_color_config(var, value) || git_default_config(var, value);
}
static char *quote_two(const char *one, const char *two)
@@ -2021,7 +2021,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 || git_use_color)
DIFF_OPT_SET(options, COLOR_DIFF);
else
DIFF_OPT_CLR(options, COLOR_DIFF);
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 0cdd800..eaae888 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -11,7 +11,7 @@ my ($new_color, $old_color, $fraginfo_color, $metainfo_color, $whitespace_color)
my ($use_color, $diff_use_color);
my $repo = Git->repository();
-$use_color = $repo->get_colorbool('color.interactive');
+$use_color = $repo->get_colorbool('color.interactive') || $repo->get_colorbool('color.git');
if ($use_color) {
# Set interactive colors:
@@ -24,7 +24,7 @@ if ($use_color) {
$normal_color = $repo->get_color("", "reset");
# Do we also set diff colors?
- $diff_use_color = $repo->get_colorbool('color.diff');
+ $diff_use_color = $repo->get_colorbool('color.diff') || $repo->get_colorbool('color.git');
if ($diff_use_color) {
$new_color = $repo->get_color("color.diff.new", "green");
$old_color = $repo->get_color("color.diff.old", "red");
diff --git a/wt-status.c b/wt-status.c
index c0c2472..1c4169c 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -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 || git_use_color ? 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_use_color_config(k, v) || git_default_config(k, v);
}
--
1.5.4.rc2.1105.g90663f
^ permalink raw reply related
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-01-05 11:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vhci9u5qi.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. Others commits may be stashed in 'offcuts'.
The topics list the commits in reverse chronological order.
----------------------------------------------------------------
[New Topics]
* db/send-email-omit-cc (Tue Dec 25 19:56:29 2007 -0800) 1 commit
- git-send-email: Generalize auto-cc recipient mechanism.
New feature which seems to be nice, but will be postponed.
* bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
. git-remote: make add -f guess HEAD, as clone does
New feature which could be used in rewriting git-clone as a thin
wrapper around other commands, but there are conflicting
proposals from Kristian and Dscho, which are post 1.5.4 item.
We'll see how they pan out.
* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
- sha1-lookup: make selection of 'middle' less aggressive
- sha1-lookup: more memory efficient search in sorted list of SHA-1
Micro-optimization whose real world benefit is not proven.
Definitely post 1.5.4.
* jc/diff-hunk-header (Wed Jan 2 01:50:11 2008 -0800) 2 commits
- diff: do not chomp hunk-header in the middle of a character
- utf8_width(): allow non NUL-terminated input
This is rewritten version of Shibata's patch. We may need this
in 1.5.4 to help the real world issue the kernel documentaiton
i18n folks are already having.
----------------------------------------------------------------
[Graduated to 'master']
Nothing to see, as we are in -rc freeze.
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
Nothing to see, as we are in -rc freeze.
----------------------------------------------------------------
[Actively cooking]
Nothing to see, as we are in -rc freeze.
----------------------------------------------------------------
[On hold]
* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
- Move all dashed-form commands to libexecdir
I think this is a sane thing to do in the longer term. Will be in
'next' after v1.5.4. I think "leave porcelain on PATH" might be also a
good thing as a transition measure.
Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them. I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir. This may
need to happen anyway as mingw fallouts.
* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
. Make git-remote a builtin
. Test "git remote show" and "git remote prune"
. parseopt: add flag to stop on first non option
. path-list: add functions to work with unsorted lists
This and Kristian's "git-clone in C" are on hold and will need
to be rebased, post 1.5.4.
* ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
+ git-name-rev: add a --(no-)undefined option.
+ git-describe: Add a --match option to limit considered tags.
* js/reflog-delete (Fri Jan 4 19:11:37 2008 -0600) 2 commits
+ builtin-reflog.c: fix typo that accesses an unset variable
+ Teach "git reflog" a subcommand to delete single entries
I haven't queued Brandon's "git stash drop", as the command name
and the UI is undecided yet, but this series will serve as the
basis of such a feature.
----------------------------------------------------------------
[Stalled]
* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
. Authentication support for pserver
This needs careful security audit and a fix to its password
database format. Plaintext in .git/config is not acceptable.
* jc/sys-select (Tue Dec 18 01:52:07 2007 -0800) 1 commit
- Do not include <sys/select.h> on pre- POSIX.1-2001 systems
This was done to help HP-UX port, but it appears that HP-UX
headers do not like to cooperate with usual _POSIX_VERSION rule,
so we probably need to scrap it and instead use manual
configuration instead.
* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
- PARK: show-symref protocol extension.
This is a demonstration of a possible component in the future direction
for HEAD discovery done by git-clone.
* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
+ Support builtin aliases
Even the original author has slight NAK on this and I tend to agree.
May want to eventurally revert from 'next' but we are not in a hurry
even to do that.
* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
- Making ce_path_match() more useful by accepting globs
This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex. I tend to agree with him.
* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
- Prepare execv_git_cmd() for removal of builtins from the
filesystem
- git-shell: accept "git foo" form
We do not plan to remove git-foo form completely from the filesystem at
this point, so these are not strictly necessary.
* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
. Make "diff" Porcelain output paths as relative to subdirectory.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
. pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
. ls-tree.c: refactor show_recursive() and rename it.
. tree-diff.c: split out a function to match a single pattern.
* jc/cherry-pick (Mon Dec 24 00:51:01 2007 -0800) 4 commits
- PARK: Start using replay-tree merge in cherry-pick
- revert/cherry-pick: start refactoring call to merge_recursive
- expose a helper function peel_to_type().
- merge-recursive: split low-level merge functions out.
I shouldn't be wasting time arguing and spending a bit more time
on 'master' and also on this.
^ permalink raw reply
* Re: [PATCH/resend] add--interactive: allow diff colors without interactive colors
From: Junio C Hamano @ 2008-01-05 11:11 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Jeff King, git
In-Reply-To: <1199530684.6209.6.camel@futex>
Matthias Kestenholz <mk@spinlock.ch> writes:
> I managed to throw something together which works and passes all
> the tests. Documentation included. :-)
Is it because we do not usually test colours and the tests run
without terminals to make sure "color.* = auto" does not kick
in?
> I would be happy for feedback and suggestions.
* Shouldn't "color.git = true" with "color.diff = false" mean
"I want colour for everything by default but I do not want to
see coloured diff"?
* git_foo_config() callback from git_config() returns 0 on
success; the API change needs to be documented to warn
others.
I haven't studied your patch very deeply so I may have misread
what you tried to do, regarding the first point, though.
^ permalink raw reply
* Re: [PATCH/resend] add--interactive: allow diff colors without interactive colors
From: Jakub Narebski @ 2008-01-05 11:37 UTC (permalink / raw)
To: git
In-Reply-To: <1199530684.6209.6.camel@futex>
Matthias Kestenholz wrote:
> +color.git::
> + 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. Defaults to false.
> +
Not "color.ui"?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-stash: add new 'drop' subcommand
From: Marco Costalba @ 2008-01-05 12:36 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <477EDDD4.5060509@nrlssc.navy.mil>
On Jan 5, 2008 2:31 AM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>
>
> +drop_stash () {
> + if ! have_stash
> + then
> + echo >&2 'No stash entries to drop'
> + exit 0
> + fi
Please, or
> + echo >&2 'No stash entries to drop'
> + exit 1
or
> + echo 'No stash entries to drop'
> + exit 0
I would prefer the latter.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH/resend] add--interactive: allow diff colors without interactive colors
From: Matthias Kestenholz @ 2008-01-05 14:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <7vd4sga5n6.fsf@gitster.siamese.dyndns.org>
On Sat, 2008-01-05 at 03:11 -0800, Junio C Hamano wrote:
> Matthias Kestenholz <mk@spinlock.ch> writes:
>
> > I managed to throw something together which works and passes all
> > the tests. Documentation included. :-)
>
> Is it because we do not usually test colours and the tests run
> without terminals to make sure "color.* = auto" does not kick
> in?
>
Probably, yes. I've to confess that I have not thought too much about
how color output could be tested.
> > I would be happy for feedback and suggestions.
>
> * Shouldn't "color.git = true" with "color.diff = false" mean
> "I want colour for everything by default but I do not want to
> see coloured diff"?
>
This works with the new patch below.
> * git_foo_config() callback from git_config() returns 0 on
> success; the API change needs to be documented to warn
> others.
>
I've changed the config reader. It behaves like the others now.
> I haven't studied your patch very deeply so I may have misread
> what you tried to do, regarding the first point, though.
Still missing are the updates for git add -i and git svn.
I have added a new function git_color_config() which should be called
after git_config() has finished its work. The function needs to run when
all config reading has been done, because otherwise the color setup
would be sensitive to the order in which the variables are placed in the
config file, which I'd rather avoid.
I've also unified the colorbool variables, because otherwise the
individual colorbool variables would need to be exported into other C
files, and I don't see the point of multiple colorbools anyway.
The patch got somewhat big, therefore I've splitted it up into several
pieces:
[PATCH 1/4] Add infrastructure for a single color config variable
[PATCH 2/4] git branch: Use color configuration infrastructure
[PATCH 3/4] status and commit: Use color configuration infrastructure
[PATCH 4/4] diff and log: Use color configuration infrastructure
^ permalink raw reply
* [PATCH 3/4] status and commit: Use color configuration infrastructure
From: Matthias Kestenholz @ 2008-01-05 14:11 UTC (permalink / raw)
To: gitster; +Cc: git, Matthias Kestenholz
In-Reply-To: <1199542299-12082-2-git-send-email-mk@spinlock.ch>
From: Matthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
builtin-commit.c | 8 +++++---
wt-status.c | 7 +++----
wt-status.h | 1 -
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 73f1e35..e442b5f 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"
@@ -435,10 +436,10 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
- saved_color_setting = wt_status_use_color;
- wt_status_use_color = 0;
+ saved_color_setting = git_use_color;
+ git_use_color = 0;
commitable = run_status(fp, index_file, prefix, 1);
- wt_status_use_color = saved_color_setting;
+ git_use_color = saved_color_setting;
fclose(fp);
@@ -639,6 +640,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
int commitable;
git_config(git_status_config);
+ git_color_config();
argc = parse_and_validate_options(argc, argv, builtin_status_usage);
diff --git a/wt-status.c b/wt-status.c
index c0c2472..ebcbe5a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -9,7 +9,6 @@
#include "diffcore.h"
int wt_status_relative_paths = 1;
-int wt_status_use_color = 0;
static char wt_status_colors[][COLOR_MAXLEN] = {
"", /* WT_STATUS_HEADER: normal */
"\033[32m", /* WT_STATUS_UPDATED: green */
@@ -40,7 +39,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 git_use_color > 0 ? wt_status_colors[slot] : "";
}
void wt_status_prepare(struct wt_status *s)
@@ -397,7 +396,7 @@ void wt_status_print(struct wt_status *s)
int git_status_config(const char *k, const char *v)
{
if (!strcmp(k, "status.color") || !strcmp(k, "color.status")) {
- wt_status_use_color = git_config_colorbool(k, v, -1);
+ git_use_color = git_config_colorbool(k, v, -1);
return 0;
}
if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
@@ -409,5 +408,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);
}
diff --git a/wt-status.h b/wt-status.h
index 02afaa6..05b05ba 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -28,7 +28,6 @@ struct wt_status {
};
int git_status_config(const char *var, const char *value);
-int wt_status_use_color;
int wt_status_relative_paths;
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
--
1.5.4.rc2.1104.gec8ae5-dirty
^ permalink raw reply related
* [PATCH 4/4] diff and log: Use color configuration infrastructure
From: Matthias Kestenholz @ 2008-01-05 14:11 UTC (permalink / raw)
To: gitster; +Cc: git, Matthias Kestenholz
In-Reply-To: <1199542299-12082-3-git-send-email-mk@spinlock.ch>
From: Matthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
builtin-diff.c | 2 ++
builtin-log.c | 9 ++++++++-
diff.c | 8 ++++----
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 29365a0..66c5896 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,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
prefix = setup_git_directory_gently(&nongit);
git_config(git_diff_ui_config);
+ git_color_config();
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..c9a23fb 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,7 @@ int cmd_whatchanged(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+ git_color_config();
init_revisions(&rev, prefix);
rev.diff = 1;
rev.simplify_history = 0;
@@ -307,6 +309,7 @@ int cmd_show(int argc, const char **argv, const char *prefix)
int i, count, ret = 0;
git_config(git_log_config);
+ git_color_config();
init_revisions(&rev, prefix);
rev.diff = 1;
rev.combine_merges = 1;
@@ -367,6 +370,7 @@ int cmd_log_reflog(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+ git_color_config();
init_revisions(&rev, prefix);
init_reflog_walk(&rev.reflog_info);
rev.abbrev_commit = 1;
@@ -395,6 +399,7 @@ int cmd_log(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+ git_color_config();
init_revisions(&rev, prefix);
rev.always_show_header = 1;
cmd_log_init(argc, argv, prefix, &rev);
@@ -436,7 +441,8 @@ static int git_format_config(const char *var, const char *value)
fmt_patch_suffix = xstrdup(value);
return 0;
}
- if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
+ if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")
+ || !strcmp(var, "color.ui")) {
return 0;
}
if (!strcmp(var, "format.numbered")) {
@@ -630,6 +636,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
char ref_message_id[1024];
git_config(git_format_config);
+ git_color_config();
init_revisions(&rev, prefix);
rev.commit_format = CMIT_FMT_EMAIL;
rev.verbose_header = 1;
diff --git a/diff.c b/diff.c
index 5bdc111..ccc958e 100644
--- a/diff.c
+++ b/diff.c
@@ -19,7 +19,6 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = 100;
-static int diff_use_color_default;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
@@ -64,6 +63,7 @@ static void read_config_if_needed(void)
if (!user_diff_tail) {
user_diff_tail = &user_diff;
git_config(git_diff_ui_config);
+ git_color_config();
}
}
@@ -147,7 +147,7 @@ int git_diff_ui_config(const char *var, const char *value)
return 0;
}
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
- diff_use_color_default = git_config_colorbool(var, value, -1);
+ git_use_color = git_config_colorbool(var, value, -1);
return 0;
}
if (!strcmp(var, "diff.renames")) {
@@ -184,7 +184,7 @@ int git_diff_ui_config(const char *var, const char *value)
return 0;
}
- return git_default_config(var, value);
+ return git_color_default_config(var, value);
}
static char *quote_two(const char *one, const char *two)
@@ -2021,7 +2021,7 @@ void diff_setup(struct diff_options *options)
options->change = diff_change;
options->add_remove = diff_addremove;
- if (diff_use_color_default)
+ if (git_use_color > 0)
DIFF_OPT_SET(options, COLOR_DIFF);
else
DIFF_OPT_CLR(options, COLOR_DIFF);
--
1.5.4.rc2.1104.gec8ae5-dirty
^ permalink raw reply related
* [PATCH 1/4] Add infrastructure for a single color config variable
From: Matthias Kestenholz @ 2008-01-05 14:11 UTC (permalink / raw)
To: gitster; +Cc: git, Matthias Kestenholz
In-Reply-To: <1199542226.6209.34.camel@futex>
From: Matthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/config.txt | 6 ++++++
color.c | 19 +++++++++++++++++++
color.h | 17 +++++++++++++++++
3 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ee08845..4bebd47 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -438,6 +438,12 @@ 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. 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/color.c b/color.c
index 7f66c29..0792571 100644
--- a/color.c
+++ b/color.c
@@ -3,6 +3,9 @@
#define COLOR_RESET "\033[m"
+int git_use_color = -1;
+int git_use_color_default = -1;
+
static int parse_color(const char *name, int len)
{
static const char * const color_names[] = {
@@ -143,6 +146,22 @@ 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);
+}
+
+void git_color_config()
+{
+ if (git_use_color == -1 && git_use_color_default != -1)
+ git_use_color = git_use_color_default;
+}
+
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..bcb845d 100644
--- a/color.h
+++ b/color.h
@@ -4,7 +4,24 @@
/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
#define COLOR_MAXLEN 24
+/*
+ * Use this variable to store the colorbool when reading from the config file.
+ */
+extern int git_use_color;
+
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
+
+/*
+ * 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);
+
+/*
+ * Call this function after git_config(config_fn_t fn) to set git_use_color,
+ * respecting the value of color.ui.
+ */
+void git_color_config();
+
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
--
1.5.4.rc2.1104.gec8ae5-dirty
^ permalink raw reply related
* [PATCH 2/4] git branch: Use color configuration infrastructure
From: Matthias Kestenholz @ 2008-01-05 14:11 UTC (permalink / raw)
To: gitster; +Cc: git, Matthias Kestenholz
In-Reply-To: <1199542299-12082-1-git-send-email-mk@spinlock.ch>
From: Matthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
builtin-branch.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 089cae5..448144f 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -31,7 +31,6 @@ static unsigned char head_sha1[20];
static int branch_track = 1;
-static int branch_use_color;
static char branch_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
"", /* PLAIN (normal) */
@@ -65,7 +64,7 @@ static int parse_branch_color_slot(const char *var, int ofs)
static int git_branch_config(const char *var, const char *value)
{
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 (!prefixcmp(var, "color.branch.")) {
@@ -76,12 +75,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 (git_use_color > 0)
return branch_colors[ix];
return "";
}
@@ -559,7 +558,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_GROUP("Generic options"),
OPT__VERBOSE(&verbose),
OPT_BOOLEAN( 0 , "track", &track, "set up tracking mode (see git-pull(1))"),
- OPT_BOOLEAN( 0 , "color", &branch_use_color, "use colored output"),
+ OPT_BOOLEAN( 0 , "color", &git_use_color, "use colored output"),
OPT_SET_INT('r', NULL, &kinds, "act on remote-tracking branches",
REF_REMOTE_BRANCH),
OPT_CALLBACK(0, "contains", &with_commit, "commit",
@@ -585,6 +584,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
};
git_config(git_branch_config);
+ git_color_config();
+
track = branch_track;
argc = parse_options(argc, argv, options, builtin_branch_usage, 0);
if (!!delete + !!rename + !!force_create > 1)
--
1.5.4.rc2.1104.gec8ae5-dirty
^ permalink raw reply related
* Re: Multiple shared repositories (including svn) workflow
From: Jakub Narebski @ 2008-01-05 15:07 UTC (permalink / raw)
To: Luke Lu; +Cc: git
In-Reply-To: <DA45FDDC-BEEB-47F6-A2B6-4FE4FFEF8B0D@vicaya.com>
Luke Lu <git@vicaya.com> writes:
> Anyway, I've been using git for only a few months. There might/must
> be better ways to do it. As a user coming from cvs and svn, it seems
> to me that the most confusing command is actually "git pull" as it
> doesn't work with such workflow at all (conflicts with confusing
> messages, until you really understand the implications of rebase). It
> seems to me that if we create a new "git update" command which is
> essentially "git fetch && git rebase <remotebranch>", it would
> greatly alleviate such confusions. Some lessons learned from the
> short experience:
>
> 1. commit first, ask question later.
> 2. rebase is the new update
> 3. reset --hard and reflog are your friends.
I don't remember if it would be in coming 1.5.4 release, but there
is "git pull --rebase", which means fetch + rebase instead of default
fetch + merge.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-filter-branch could be confused by similar names
From: Johannes Schindelin @ 2008-01-05 16:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Potapov, git
In-Reply-To: <7vr6gxjpyn.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 4 Jan 2008, Junio C Hamano wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
> > It works only if the name "unambiguous" for git show-ref, which
> > interprets refname differently than rev-list as I wrote above.
> > Nevertheless, I believe we can use 'git show-ref' if we try something
> > like this:
>
> Ahh.
>
> But at that point I would say that exposing the refname dwimming
> logic to the scripts could be a much cleaner solution.
I considered that when ripping the script from cogito, but it seemed to me
at that time that not requiring an up-to-date git for testing the script
would be better.
Now is a different situation, however, so I agree.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-01-05 16:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhchsa63t.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 5 Jan 2008, Junio C Hamano wrote:
> * bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
> . git-remote: make add -f guess HEAD, as clone does
>
> New feature which could be used in rewriting git-clone as a thin wrapper
> around other commands, but there are conflicting proposals from Kristian
> and Dscho, which are post 1.5.4 item. We'll see how they pan out.
I do not have any objection against using bf/remote-head to introduce this
feature, and will port it to C when it is deemed good enough. After all,
we _use_ shell scripting for prototyping things.
> * jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
> - sha1-lookup: make selection of 'middle' less aggressive
> - sha1-lookup: more memory efficient search in sorted list of SHA-1
>
> Micro-optimization whose real world benefit is not proven.
> Definitely post 1.5.4.
I did not follow this closely... Would this help the "notes" feature as
implemented with refs/notes?
> * jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
> - Making ce_path_match() more useful by accepting globs
>
> This was to allow "git diff-files -- '*.h'" (currently diff family
> knows only the leading directory match and not fileglobs), but was shot
> down by Alex. I tend to agree with him.
I recently needed something like this, and had to script around the lack
of support for this.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-am: Run git gc only once and not for every patch.
From: Michael Stefaniuc @ 2008-01-05 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve68ep78.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> ...
>> I do not think moving "gc --auto" outside the loop hurts in
>> practice because you are not likely to be rebasing a truly huge
>> series every day, but cruft can accumulate during "git am" run
>> and the "gc --auto" inside loop was meant to clean them up. The
>> idea was taken from importers that run repack every once in a
>> while (e.g. cvsimport runs every 1k commits), but "gc --auto"
>> was designed to be much more lightweight than a full repack and
>> that was the reason it was placed in the loop without counting
>> "every N commits".
>
> Having said all that, I'll take your patch as-is except that I'd
Thanks.
> drop the later part of the commit log message that explains
> Wine's practice.
Yeah, sorry about that. That should have been outside of the commit
message anyway. But forgot about it as the Wine maintainer takes only
the subject as commit message.
bye
michael
^ permalink raw reply
* git diff -B: splitting up complete renames
From: Jakub Narebski @ 2008-01-05 17:18 UTC (permalink / raw)
To: git
First: in Documentation/diffcore.txt there is an example of broken pair
diffcore-break: For Splitting Up "Complete Rewrites"
----------------------------------------------------
The second transformation in the chain is diffcore-break, and is
controlled by the -B option to the git-diff-* commands. This is
used to detect a filepair that represents "complete rewrite" and
break such filepair into two filepairs that represent delete and
create. E.g. If the input contained this filepair:
------------------------------------------------
:100644 100644 bcd1234... 0123456... M file0
------------------------------------------------
and if it detects that the file "file0" is completely rewritten,
it changes it to:
------------------------------------------------
:100644 000000 bcd1234... 0000000... D file0
:000000 100644 0000000... 0123456... A file0
------------------------------------------------
Shouldn't the last block read for the modern git read:
------------------------------------------------
:100644 000000 bcd1234... 0123456... M99 file0
------------------------------------------------
or is it only for '-B' togehter with '-M' or '-C'?
Second: do you have per chance good examples of broken (and perhaps
merged together) pair, such that it is affected by --diff-filter=B;
with -B<num> or -B<num1>/<num2> parameters needed, if required. COPYING
and Makefile are one good example, but do you have literal files with
similar behavior?
Third: Do "git diff --no-index" (filesystem diff) can show breaking /
use dissimilarity? I couldn't make it work...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git diff -B: splitting up complete renames
From: Linus Torvalds @ 2008-01-05 17:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200801051818.40009.jnareb@gmail.com>
On Sat, 5 Jan 2008, Jakub Narebski wrote:
>
> Shouldn't the last block read for the modern git read:
>
> ------------------------------------------------
> :100644 000000 bcd1234... 0123456... M99 file0
> ------------------------------------------------
>
> or is it only for '-B' togehter with '-M' or '-C'?
Without -M/C, git re-joins them, so yeah, either the documentation (or
that re-joining logic) is wrong.
> Second: do you have per chance good examples of broken (and perhaps
> merged together) pair, such that it is affected by --diff-filter=B;
> with -B<num> or -B<num1>/<num2> parameters needed, if required. COPYING
> and Makefile are one good example, but do you have literal files with
> similar behavior?
Hmm. A kernel example that shows *something* is
git show -B --raw -r acbbbe9f5ab52da90a8edec02ec973e7f44dae81
which shows
:100644 100644 eb14b18... 1f2d6d5... M093 include/asm-x86/byteorder.h
even though that 093 is the *dissimilarity* index, so according to the
documentation you quote you'd expect it to be
:100644 000000 eb14b18... 0000000... D include/asm-x86/byteorder.h
:000000 100644 0000000... 1f2d6d5... A include/asm-x86/byteorder.h
instead of a M. Whether it's the docs or the behavior that should be
changed, I dunno.
Especially as using -B -M makes it all sane again, because then it shows
it as the real rename:
:100644 100644 435074a... 26b0dcd... M include/asm-x86/Kbuild
:100644 100644 a45470a... 1f2d6d5... R061 include/asm-x86/byteorder_32.h include/asm-x86/byteorde
:100644 000000 5e86c86... 0000000... D include/asm-x86/byteorder_64.h
and it's all good.
My personal opinion is that -B doesn't make much sense without M (or C),
but at least you can see an example of the breaking behaviour in the
kernel for a real case.
Linus
^ permalink raw reply
* [PATCH] tree-walk: don't parse incorrect entries
From: Martin Koegler @ 2008-01-05 17:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
The current code can access memory outside of the tree
buffer in the case of malformed tree entries.
This patch prevent this by:
* The rest of the buffer must be at least 24 bytes
(at least 1 byte mode, 1 blank, at least one byte path name,
1 zero, 20 bytes sha1).
* Check that the last zero (21 bytes before the end) is present.
This ensurse, that strlen and get_mode stay within the buffer.
* The mode may not be empty. We have only to reject a blank at the begin,
as the rest is handled by if (c < '0' || c > '7').
* The blank is ensured by get_mode.
* The start of the path may not be after the last zero (21 bytes before the end).
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
tree-walk.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index 8d4b673..bd88ec7 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -7,6 +7,9 @@ static const char *get_mode(const char *str, unsigned int *modep)
unsigned char c;
unsigned int mode = 0;
+ if (*str == ' ')
+ return NULL;
+
while ((c = *str++) != ' ') {
if (c < '0' || c > '7')
return NULL;
@@ -16,13 +19,17 @@ static const char *get_mode(const char *str, unsigned int *modep)
return str;
}
-static void decode_tree_entry(struct tree_desc *desc, const void *buf, unsigned long size)
+static void decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned long size)
{
const char *path;
unsigned int mode, len;
+ const char *end = buf + size - 21;
+
+ if (size < 24 || *end)
+ die("corrupt tree file");
path = get_mode(buf, &mode);
- if (!path)
+ if (!path || path > end)
die("corrupt tree file");
len = strlen(path) + 1;
--
1.4.4.4
^ permalink raw reply related
* Re: git diff -B: splitting up complete renames
From: Junio C Hamano @ 2008-01-05 19:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200801051818.40009.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> ...
> and if it detects that the file "file0" is completely rewritten,
> it changes it to:
>
> ------------------------------------------------
> :100644 000000 bcd1234... 0000000... D file0
> :000000 100644 0000000... 0123456... A file0
> ------------------------------------------------
>
> Shouldn't the last block read for the modern git read:
>
> ------------------------------------------------
> :100644 000000 bcd1234... 0123456... M99 file0
> ------------------------------------------------
Correct. The description is based on an earlier round of the
code before 366175ef8c3b1e145f4ba846e63a1dea3ec3cacc (Rework -B
output). "git show" of that patch has description in its
changes to Documentation/diffcore.txt.
The original motivation of -B was not about helping three way
renames it allows you when used with -M/-C. It was about
showing textual diff more readably for quite dissimilar
filepairs.
> Third: Do "git diff --no-index" (filesystem diff) can show breaking /
> use dissimilarity? I couldn't make it work...
It doesn't, for two reasons.
* Look at diffcore_break(). It breaks filepairs with identical
paths and nothing else.
The reason for this check is that the caller can call
diffcore_rename() _before_ diffcore_break() [*1*] and a
filepair that was detected as renamed pair ought to be
already found similar enough. These days, I think you can
replace the check with p->renamed_pair.
* Look at diffcore_merge_broken(), which is responsible for
re-merging a broken pair. Because we match them by looking
at their names (iow, we do not use pointers to link halves of
a broken pair pointing at each other).
This was correct before "no-index" stuff because "git diff"
was about comparing pairs of blobs found at corresponding
paths in two tree-like things (i.e. "a/one" and "b/one"
corresponds to each other when you do "git diff -- one").
The modification to introduce no-index forgot to update this
logic.
If you wanted to fix this, you can change p->broken_pair from a
boolean to a pointer that points at the other half of the broken
pair (and record that when we break a pair in diffcore_break()),
and look at that pointer to decide which one to match up with
which other one in diffcore_merge_broken(). Together with a
change to look at p->renamed_pair instead of paths I mentioned,
I think it would work more like the regular git diff for
"no-index" case.
I consider that "no-index" frontend more or less a bolted on
half-baked hack that covers only minimally necessary cases to
serve as non-git "diff" replacement, without sharing enough with
the real "git diff" internals; I would not be surprised at all
if there are more corner cases like this that does not work.
But I do not think it is fundamentally unfixable. The change to
add "no-index" support just needed to be more careful, and it is
not too late to make it so.
[Footnote]
*1* diffcore was designed as a generic library to allow
experimenting more combinations of transformations than what
then-current git used. All of our existing callers ended up
calling the transformations in the same order (i.e. the order
diffcore_std() calls them), but individual transformations were
written not to assume too much about the order they would be
called.
^ permalink raw reply
* [PATCH 1/2] git-rev-parse --symbolic-full-name
From: Junio C Hamano @ 2008-01-05 20:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, git
In-Reply-To: <alpine.LSU.1.00.0801051601490.10101@racer.site>
The plumbing level can understand that the user meant
"refs/heads/master" when the user says "master" or
"heads/master", but there is no easy way for the scripts to
figure it out without duplicating the dwim_ref() logic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is the same patch as I showed yesterday but with a doc
update.
Documentation/git-rev-parse.txt | 7 +++++++
builtin-rev-parse.c | 37 ++++++++++++++++++++++++++++++++++---
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 329fce0..0cedc13 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -70,6 +70,13 @@ OPTIONS
possible '{caret}' prefix); this option makes them output in a
form as close to the original input as possible.
+--symbolic-full-name::
+ This is similar to \--symbolic, but it omits input that
+ are not refs (i.e. branch or tag names; or more
+ explicitly disambiguating "heads/master" form, when you
+ want to name the "master" branch when there is an
+ unfortunately named tag "master"), and show them as full
+ refnames (e.g. "refs/heads/master").
--all::
Show all refs found in `$GIT_DIR/refs`.
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 20d1789..b9af1a5 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -21,6 +21,9 @@ static const char *def;
#define NORMAL 0
#define REVERSED 1
static int show_type = NORMAL;
+
+#define SHOW_SYMBOLIC_ASIS 1
+#define SHOW_SYMBOLIC_FULL 2
static int symbolic;
static int abbrev;
static int output_sq;
@@ -103,8 +106,32 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)
if (type != show_type)
putchar('^');
- if (symbolic && name)
- show(name);
+ if (symbolic && name) {
+ if (symbolic == SHOW_SYMBOLIC_FULL) {
+ unsigned char discard[20];
+ char *full;
+
+ switch (dwim_ref(name, strlen(name), discard, &full)) {
+ case 0:
+ /*
+ * Not found -- not a ref. We could
+ * emit "name" here, but symbolic-full
+ * users are interested in finding the
+ * refs spelled in full, and they would
+ * need to filter non-refs if we did so.
+ */
+ break;
+ case 1: /* happy */
+ show(full);
+ break;
+ default: /* ambiguous */
+ error("refname '%s' is ambiguous", name);
+ break;
+ }
+ } else {
+ show(name);
+ }
+ }
else if (abbrev)
show(find_unique_abbrev(sha1, abbrev));
else
@@ -421,7 +448,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--symbolic")) {
- symbolic = 1;
+ symbolic = SHOW_SYMBOLIC_ASIS;
+ continue;
+ }
+ if (!strcmp(arg, "--symbolic-full-name")) {
+ symbolic = SHOW_SYMBOLIC_FULL;
continue;
}
if (!strcmp(arg, "--all")) {
--
1.5.4.rc2.38.gd6da3
^ permalink raw reply related
* [PATCH 2/2] filter-branch: work correctly with ambiguous refnames
From: Junio C Hamano @ 2008-01-05 20:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, git
In-Reply-To: <alpine.LSU.1.00.0801051601490.10101@racer.site>
'git-filter-branch branch' could fail producing the error:
"Which ref do you want to rewrite?" if existed another branch
or tag, which name was 'branch-something' or 'something/branch'.
[jc: original report and fix were done between Dmitry Potapov
and Dscho; I rewrote it using "rev-parse --symbolic-full-name"]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> But at that point I would say that exposing the refname dwimming
>> logic to the scripts could be a much cleaner solution.
>
> I considered that when ripping the script from cogito, but it seemed to me
> at that time that not requiring an up-to-date git for testing the script
> would be better.
>
> Now is a different situation, however, so I agree.
It was already tied to the specific git version when
git-filter-branch became part of git.git ;-)
I do not use filter-branch myself very often, but I think this
is worth fixing. The additional --no-flags and sed are to deal
with something like:
--topo-order master..next
although I do not offhand know if filter-branch would work with
things like --topo-order and --first-parent.
git-filter-branch.sh | 22 +++-------------------
1 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ae29f47..ebf05ca 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -209,25 +209,9 @@ ORIG_GIT_INDEX_FILE="$GIT_INDEX_FILE"
GIT_WORK_TREE=.
export GIT_DIR GIT_WORK_TREE
-# These refs should be updated if their heads were rewritten
-
-git rev-parse --revs-only --symbolic "$@" |
-while read ref
-do
- # normalize ref
- case "$ref" in
- HEAD)
- ref="$(git symbolic-ref "$ref")"
- ;;
- refs/*)
- ;;
- *)
- ref="$(git for-each-ref --format='%(refname)' |
- grep /"$ref")"
- esac
-
- git check-ref-format "$ref" && echo "$ref"
-done > "$tempdir"/heads
+# The refs should be updated if their heads were rewritten
+git rev-parse --no-flags --revs-only --symbolic-full-name "$@" |
+sed -e '/^^/d' >"$tempdir"/heads
test -s "$tempdir"/heads ||
die "Which ref do you want to rewrite?"
--
1.5.4.rc2.38.gd6da3
^ permalink raw reply related
* Re: [PATCH] tree-walk: don't parse incorrect entries
From: Junio C Hamano @ 2008-01-05 20:50 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <1199555243534-git-send-email-mkoegler@auto.tuwien.ac.at>
Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> The current code can access memory outside of the tree
> buffer in the case of malformed tree entries.
>
> This patch prevent this by:
> * The rest of the buffer must be at least 24 bytes
> (at least 1 byte mode, 1 blank, at least one byte path name,
> 1 zero, 20 bytes sha1).
Good ("zero" in this context is better spelled as "NUL").
> * Check that the last zero (21 bytes before the end) is present.
> This ensurse, that strlen and get_mode stay within the buffer.
Good (ditto).
> * The mode may not be empty. We have only to reject a blank at the begin,
> as the rest is handled by if (c < '0' || c > '7').
I initially thought this was slightly iffy as tree objects were
written with padding for mode bits, but that was padding with
zero ('0') to the left and not with SP, so it is a good change,
I think (I am saying this primarily so that others can say "you
are wrong, there are valid old trees with SP there" to stop me).
> * The blank is ensured by get_mode.
Ok.
> * The start of the path may not be after the last zero (21 bytes before the end).
How can that be possible?
- you know end points at NUL and buf < end;
- get_mode() starts scanning from buf, stops at the first SP if
returns a non NULL pointer; anything non octal digit before
it sees that SP results in a NULL return;
- the return value of get_mode() is the beginning of the path.
The second point above means when get_mode() scans buf, it would
never go beyond end which you already made sure is NUL (which is
not SP and not an octal digit). If it hits end, you would get NULL
pointer back, wouldn't you?
Rejecting an empty path may be sensible (i.e. checking "!*path"
instead), though.
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Dan McGee @ 2008-01-05 21:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Tsugikazu Shibata, Marco Costalba, Jeff King, Dmitry Potapov
In-Reply-To: <7v63y8ble8.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Jan 5, 2008 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> We are not at -rc3 yet, but we will be soon. What we have
> accumulated in 'master' are mostly fixes, and the official
> git-gui 0.9.1 is also included tonight.
> * Dan McGee's workaround to breakage caused by changes in
> AsciiDoc 8.2.3.
>
> I have to do my usual "before-and-after comparison" with
> copies of AsciiDoc versions that should not be affected by
> the breakage, which I did not have time to do so far. But
> this is probably a must-have before the release.
I've updated the patch a bit as I noticed I completely missed the
user-manual.txt and a handful of other files that weren't named
git-*.txt. The new version is attached (gzipped). I also included
instructions on how to regenerate it in the commit message, which may
be a wise idea to ensure no Documentation changes add a gitlink: call
between now and when you apply the patch.
-Dan
[-- Attachment #2: 0001-Documentation-rename-gitlink-macro-to-linkgit.patch.gz --]
[-- Type: application/x-gzip, Size: 50243 bytes --]
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Junio C Hamano @ 2008-01-05 22:11 UTC (permalink / raw)
To: Marco Costalba
Cc: Junio C Hamano, git, Tsugikazu Shibata, Jeff King, Dan McGee,
Dmitry Potapov
In-Reply-To: <e5bfff550801050507x369976b7sd5e112451bc90331@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> I understand the patch series is too intrusive now, but if you want I
> can send a simplified one that just fixes the off by one bug for now.
How about the one that fixes first and see how bad the remainder
looks again? I recall that Réne were not entirely unhappy with
his last round. And I do not think that change does not have to
be "a series" but can be a single change. At least it did not
look so complicated, but I may be misremembering it.
^ permalink raw reply
* [PATCH] Test "git log --diff-filter"
From: Jakub Narebski @ 2008-01-05 22:20 UTC (permalink / raw)
To: git; +Cc: Arjen Laarhoven, Junio C Hamano, Jakub Narebski
In-Reply-To: <1198580807-18802-1-git-send-email-arjen@yaph.org>
Add test to check "git log --diff-filter" works correctly with and
without diff generation by git-log; the main purpose of this test is
to check if "git log --diff-filter" filters revisions correctly.
This is a companion test to commit 0faf2da7e5ee5c2f472d8a7afaf8616101f34e80
(Fix "git log --diff-filter" bug) by Arjen Laarhoven.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:
> Thanks. Some tests?
So there it is...
First, either I don't understand what referred to commit was supposed
to fix, or my test is wrong, or the patch doesn't fix the bug.
Second, I have a few questions about the test itself. I'm not that
sure about it's name: t/README tells us to use 4 as a first digit of
test number for testing diff commands, and 8 for commands concerning
forensics. "git log --diff-filter" is a forensics concerning diff
output. Second digit is for command itself: 0 is used for diff, 2 for
log, so perhaps the test should be named t/t4203-log-diff-filter.sh
The style of writing test is not very consistent across git test
suite. I think that the 'setup' step style is all right, and only
perhas the style of those two-liner tests could be changed.
I use "git diff --exit-code expected current" instead of "diff" or
"cmp" utilities; should all (new) test use this... well of course
except ones testing diff output itself?
t/t4025-diff-filter.sh | 240 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 240 insertions(+), 0 deletions(-)
create mode 100755 t/t4025-diff-filter.sh
diff --git a/t/t4025-diff-filter.sh b/t/t4025-diff-filter.sh
new file mode 100755
index 0000000..3113786
--- /dev/null
+++ b/t/t4025-diff-filter.sh
@@ -0,0 +1,240 @@
+#!/bin/sh
+
+test_description='git log --diff-filter option
+
+Test --diff-filter option with git-log with and without diff output,
+checking both diff output filtering and revision list filtering.
+'
+
+. ./test-lib.sh
+. ../diff-lib.sh ;# test-lib chdir's into trash
+
+# ----------------------------------------------------------------------
+
+test_expect_success setup '
+
+ rm -f foo &&
+ cat ../../COPYING >foo &&
+ git add foo &&
+ git commit -a -m "1st commit: A" &&
+
+ cp foo bar &&
+ git add bar &&
+ git commit -a -m "2nd commit: C" &&
+
+ git rm foo &&
+ git commit -a -m "3rd commit: D" &&
+
+ echo "First added line" >> bar &&
+ git commit -a -m "4th commit: M" &&
+
+ git mv bar foo &&
+ git commit -a -m "5th commit: R" &&
+
+ rm -f foo &&
+ cat ../../Makefile >foo &&
+ git commit -a -m "6th commit: B" &&
+
+ rm -f bar &&
+ echo "bar" > bar &&
+ git add bar &&
+ echo "Second added line" >> foo &&
+ git commit -a -m "7th commit: AM"
+
+ rm -f bar &&
+ ln -s foo bar &&
+ git commit -a -m "8th commit: T"
+
+'
+
+# ----------------------------------------------------------------------
+
+cat >expected <<\EOF
+7th commit: AM
+:000000 100644 0000000000000000000000000000000000000000 5716ca5987cbf97d6bb54920bea6adde242d87e6 A bar
+
+1st commit: A
+:000000 100644 0000000000000000000000000000000000000000 6ff87c4664981e4397625791c8ea3bbb5f2279a3 A foo
+EOF
+
+test_expect_success 'git log --raw --diff-filter=A' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=A >current &&
+ compare_diff_raw expected current
+'
+
+
+cat >expected <<\EOF
+3rd commit: D
+:100644 000000 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0000000000000000000000000000000000000000 D foo
+EOF
+
+test_expect_success 'git log --raw --diff-filter=D' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=D >current &&
+ compare_diff_raw expected current
+'
+
+
+cat >expected <<\EOF
+7th commit: AM
+:100644 100644 21c80e6bf73163b9770cba5331cd48172fa6d43e a892bacce2a80efc14eef1c316e827575a96e5c9 M foo
+
+4th commit: M
+:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 915b225a6c9984e645a8061e05002f8cbd2ce46c M bar
+EOF
+
+test_expect_success 'git log --raw --diff-filter=M' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=M >current &&
+ compare_diff_raw expected current
+'
+
+
+cat >expected <<\EOF
+5th commit: R
+:100644 100644 915b225a6c9984e645a8061e05002f8cbd2ce46c 915b225a6c9984e645a8061e05002f8cbd2ce46c R100 bar foo
+EOF
+
+test_expect_success 'git log --raw --diff-filter=R' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=R >current &&
+ compare_diff_raw expected current
+'
+
+
+cat >expected <<\EOF
+2nd commit: C
+:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 6ff87c4664981e4397625791c8ea3bbb5f2279a3 C100 foo bar
+EOF
+
+test_expect_success 'git log --raw --diff-filter=C' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=C >current &&
+ compare_diff_raw expected current
+'
+
+
+cat >expected <<\EOF
+6th commit: B
+:100644 100644 915b225a6c9984e645a8061e05002f8cbd2ce46c 21c80e6bf73163b9770cba5331cd48172fa6d43e M098 foo
+EOF
+
+test_expect_success 'git log --raw --diff-filter=B' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=B >current &&
+ compare_diff_raw expected current
+'
+
+
+cat >expected <<\EOF
+8th commit: T
+:100644 120000 5716ca5987cbf97d6bb54920bea6adde242d87e6 19102815663d23f8b75a47e7a01965dcdc96468c T bar
+EOF
+
+test_expect_success 'git log --raw --diff-filter=T' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=T >current &&
+ compare_diff_raw expected current
+'
+
+cat >expected <<\EOF
+7th commit: AM
+:000000 100644 0000000000000000000000000000000000000000 5716ca5987cbf97d6bb54920bea6adde242d87e6 A bar
+:100644 100644 21c80e6bf73163b9770cba5331cd48172fa6d43e a892bacce2a80efc14eef1c316e827575a96e5c9 M foo
+
+1st commit: A
+:000000 100644 0000000000000000000000000000000000000000 6ff87c4664981e4397625791c8ea3bbb5f2279a3 A foo
+EOF
+
+test_expect_success 'git log --raw --diff-filter=A*' '
+ git log --raw --no-abbrev --pretty=format:%s -B -C -C --diff-filter=A* >current &&
+ compare_diff_raw expected current
+'
+
+# ----------------------------------------------------------------------
+
+cat >expected <<\EOF
+8th commit: T
+7th commit: AM
+6th commit: B
+5th commit: R
+4th commit: M
+3rd commit: D
+2nd commit: C
+1st commit: A
+EOF
+
+test_expect_success 'git log (no filter)' '
+ git log --pretty=format:%s -B -C -C >current &&
+ git diff --exit-code expected current
+'
+
+
+cat >expected <<\EOF
+7th commit: AM
+1st commit: A
+EOF
+
+test_expect_success 'git log --diff-filter=A' '
+ git log --pretty=format:%s -B -C -C --diff-filter=A >current &&
+ git diff --exit-code expected current
+'
+
+
+cat >expected <<\EOF
+3rd commit: D
+EOF
+
+test_expect_success 'git log --diff-filter=D' '
+ git log --pretty=format:%s -B -C -C --diff-filter=D >current &&
+ git diff --exit-code expected current
+'
+
+
+cat >expected <<\EOF
+7th commit: AM
+4th commit: M
+EOF
+
+test_expect_success 'git log --diff-filter=M' '
+ git log --pretty=format:%s -B -C -C --diff-filter=M >current &&
+ git diff --exit-code expected current
+'
+
+
+cat >expected <<\EOF
+5th commit: R
+EOF
+
+test_expect_success 'git log --diff-filter=R' '
+ git log --pretty=format:%s -B -C -C --diff-filter=R >current &&
+ git diff --exit-code expected current
+'
+
+
+cat >expected <<\EOF
+2nd commit: C
+EOF
+
+test_expect_success 'git log --diff-filter=C' '
+ git log --pretty=format:%s -B -C -C --diff-filter=C >current &&
+ git diff --exit-code expected current
+'
+
+
+cat >expected <<\EOF
+6th commit: B
+EOF
+
+test_expect_success 'git log --diff-filter=B' '
+ git log --pretty=format:%s -B -C -C --diff-filter=A >current &&
+ git diff --exit-code expected current
+'
+
+
+cat >expected <<\EOF
+8th commit: T
+EOF
+
+test_expect_success 'git log --diff-filter=T' '
+ git log --pretty=format:%s -B -C -C --diff-filter=T >current &&
+ git diff --exit-code expected current
+'
+
+# ----------------------------------------------------------------------
+
+test_done
--
1.5.3.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox