* Re: What's in git.git (stable frozen)
From: Jeff King @ 2008-01-06 4:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63y8ble8.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 05, 2008 at 02:46:07AM -0800, Junio C Hamano wrote:
> * 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.
Here is the palette cleanup patch, on top of my others (it should still
be done even if the other patches aren't taken, but backporting it
should be fairly obvious).
-- >8 --
add--interactive: remove unused diff colors
When color support was added, we colored the diffs
ourselves. However, 4af756f3 changed this to simply run
"git diff-files" twice, keeping the colored output
separately.
This makes the internal diff color variables obsolete with
one exception: when splitting hunks, we have to manually
recreate the fragment for each part of the split. Thus we
keep $fraginfo_color around to do that correctly.
Signed-off-by: Jeff King <peff@peff.net>
---
git-add--interactive.perl | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index aaa9b24..5bdcca8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -6,7 +6,7 @@ use Git;
# Prompt colors:
my ($prompt_color, $header_color, $help_color, $normal_color);
# Diff colors:
-my ($new_color, $old_color, $fraginfo_color, $metainfo_color, $whitespace_color);
+my ($fraginfo_color);
my ($use_color, $diff_use_color);
my $repo = Git->repository();
@@ -27,11 +27,7 @@ if ($use_color) {
# Do we also set diff colors?
$diff_use_color = $repo->get_colorbool('color.diff');
if ($diff_use_color) {
- $new_color = $repo->get_color("color.diff.new", "green");
- $old_color = $repo->get_color("color.diff.old", "red");
$fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
- $metainfo_color = $repo->get_color("color.diff.meta", "bold");
- $whitespace_color = $repo->get_color("color.diff.whitespace", "normal red");
}
sub colored {
--
1.5.4.rc2.1147.gaecdf-dirty
^ permalink raw reply related
* Re: What's in git.git (stable frozen)
From: Jeff King @ 2008-01-06 4:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20080106042409.GA4843@coredump.intra.peff.net>
On Sat, Jan 05, 2008 at 11:24:09PM -0500, Jeff King wrote:
> > * 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.
>
> Here is the palette cleanup patch, on top of my others (it should still
And while tracking down the $fraginfo usage, I noticed that my original
patches introduce a bug. Fix is below (it is on top of palette cleanup).
I can also resubmit these in a more sensible order (palette cleanup,
then the other three squashed together) if you prefer.
-- >8 --
add--interactive: colorize split hunk fragment headers
The only diff element which we still color in perl is the
"fraginfo" for the split hunks. When honoring color.diff
without color.interactive, we were failing to actually color
this because the "colored" function checks for interactive
color. Instead, let's just color it by hand (the simple
approach is OK because we know we have a single line
string).
Signed-off-by: Jeff King <peff@peff.net>
---
This is a little uglier than it could be because the "colored" function
does two things: correctly colorize a string, and check the global
$use_color. We could do something like:
local $use_color = 1;
$display_head = colored($fraginfo_color, $head);
which is arguably less ugly. Or we could refactor "colored", which is a
larger change.
git-add--interactive.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 5bdcca8..76dc4e6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -21,8 +21,8 @@ if ($use_color) {
$prompt_color = $repo->get_color("color.interactive.prompt", "bold blue");
$header_color = $repo->get_color("color.interactive.header", "bold");
$help_color = $repo->get_color("color.interactive.help", "red bold");
- $normal_color = $repo->get_color("", "reset");
}
+$normal_color = $repo->get_color("", "reset");
# Do we also set diff colors?
$diff_use_color = $repo->get_colorbool('color.diff');
@@ -648,7 +648,8 @@ sub split_hunk {
my $display_head = $head;
unshift @{$hunk->{TEXT}}, $head;
if ($diff_use_color) {
- $display_head = colored($fraginfo_color, $head);
+ $display_head = join('', $fraginfo_color, $head,
+ $normal_color, "\n");
}
unshift @{$hunk->{DISPLAY}}, $display_head;
}
--
1.5.4.rc2.1147.gaecdf-dirty
^ permalink raw reply related
* rm and mv commands: should I use them?
From: Jon Hancock @ 2008-01-06 7:55 UTC (permalink / raw)
To: git
Hello list,
I'm fairly new to git and coming from svn and have tasted hg and bzr
along the decision path.
Here's my newbie issue:
In reading Aristotle Pagaltzis's article http://plasmasturm.org/log/
487/ the author stresses that a major difference between git and
something like bzr or svn is that git tracks content and not metadata
(or at least less metadata); meaning is inferred through content and
less through metadata.
The heart of Pagaltzis's argument copied here:
<COPY>
Among the systems I did look into, there are really just two
contenders: git and Mercurial. All the other systems track metadata;
git and hg just track content and infer the metadata.
By tracking metadata I mean that these systems keep a record of what
steps were taken. “This file had its name changed.” “Those
modifications came from that file in that branch.” “This file was
copied from that file.” Tracking content alone means doing none of
that. When you commit, the VCS just records what the tree looks like.
It doesn’t care about how the tree got that way. When you ask it about
two revisions, it looks at the tree beforehand and the tree
afterwards, and figures out what happened inbetween. A file is not a
unit that defines any sort of boundary in this view. The VCS always
looks at entire trees; files have no individual identity separate from
their trees at all.
As a consequence, whether you used VCS tools to manipulate your
working copy or regular command line utilities or applied a patch or
whatever is irrelevant. The resulting history is always the same.
</COPY>
So, do I need to use git's mv and rm commands? Can't I just rename,
add, and remove files using any means I like and then just ensure my
"index" is staged properly when I do a commit? Additionally, is there
a simple procedure with git to say: "I want to version exactly what is
in my working tree. If I removed something or added something, just
handle it". This is sort of what "git add ." does, but "git add"
doesn't handling things I removed or moved, correct?
thanks, Jon
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: David Brown @ 2008-01-06 8:04 UTC (permalink / raw)
To: Jon Hancock; +Cc: git
In-Reply-To: <379EDA94-A67B-483A-BC5F-E961DD52AD0C@gmail.com>
On Sun, Jan 06, 2008 at 03:55:22PM +0800, Jon Hancock wrote:
> So, do I need to use git's mv and rm commands? Can't I just rename,
> add, and remove files using any means I like and then just ensure my
> "index" is staged properly when I do a commit?
Yes. You can use either git-rm or 'git-commit -a' to remove files. To
rename, you can use git-mv, or you can rename the file yourself, git-add
the new name, and git-rm the old name.
There is no metadata stored with git-mv and git-rm, they just update the
tree and the index.
Dave
^ permalink raw reply
* Re: how to use git merge -s subtree?
From: Sean @ 2008-01-06 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Soria Parra, git
In-Reply-To: <7vir277jz6.fsf@gitster.siamese.dyndns.org>
On Sat, 05 Jan 2008 18:42:37 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> David Soria Parra <sn_@gmx.net> writes:
>
> > Well yes the history is preserved, but it's not connected to the
> > subdirectory. So you cannot do git-log B/foo.c as git doesnot know where
> > to search it as it thinks
> > it is in /foo.c not in B/foo.c
>
> The thing is, what you are talking is not about the subtree
> merge strategy, but the fundamental philosophy of git. Asking
> for "the history of file B/foo.c" does not make any sense, as
> git never tracks history of individual files.
Hi Junio,
Obviously you are making an important point here about the way Git is designed,
but I think you misspoke slightly. Asking for the history of a file does make
sense. Through path limiting you can ask to see just the subset of history that
touched a certain file or directory etc..
In a simple repo where you don't have any subtree merge, with a file /B/foo.c
that at some point earlier in the history was renamed from /foo.c, the command
"git log --follow B/foo.c" will show changes extending back before the rename.
However, that doesn't seem to work across a subtree merge. Obviously there's
some technical reason for this that i'm overlooking, but on the surface the two
cases seem similar.
It would be nice to be able to do "gitk --follow git-gui.sh" in git.git and
actually see the history of that file. As it stands now, you have to type
"gitk -- git-gui.sh ../git-gui.sh". Is there a fundamental reason Git can't
be taught to notice this particular type of subtree merge "rename" and
support --follow type semantics?
At least the message you referenced from Linus leaves hope that this may be
possible as it makes the case that this is the type of thing that you can do if
you avoid locking yourself into inadequate rename-tracking data structures.
Sean
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Brian Swetland @ 2008-01-06 8:08 UTC (permalink / raw)
To: Jon Hancock; +Cc: git
In-Reply-To: <379EDA94-A67B-483A-BC5F-E961DD52AD0C@gmail.com>
[Jon Hancock <redstarling@gmail.com>]
>
> So, do I need to use git's mv and rm commands? Can't I just rename, add,
> and remove files using any means I like and then just ensure my "index" is
> staged properly when I do a commit? Additionally, is there a simple
> procedure with git to say: "I want to version exactly what is in my working
> tree. If I removed something or added something, just handle it". This is
> sort of what "git add ." does, but "git add" doesn't handling things I
> removed or moved, correct?
"git add ." only adds new or modified files to the index. You can use
"git add -u ." to update the index to reflect any deleted files.
Brian
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Jeff King @ 2008-01-06 8:08 UTC (permalink / raw)
To: Jon Hancock; +Cc: git
In-Reply-To: <379EDA94-A67B-483A-BC5F-E961DD52AD0C@gmail.com>
On Sun, Jan 06, 2008 at 03:55:22PM +0800, Jon Hancock wrote:
> So, do I need to use git's mv and rm commands? Can't I just rename, add,
> and remove files using any means I like and then just ensure my "index" is
> staged properly when I do a commit?
No, you don't need to use those commands. They really are just wrappers
that manipulate the working tree files and the index at the same time.
So instead of "git-mv a b" you can do "mv a b; git rm a; git add b".
> Additionally, is there a simple procedure with git to say: "I want to
> version exactly what is in my working tree. If I removed something or
> added something, just handle it". This is sort of what "git add ."
> does, but "git add" doesn't handling things I removed or moved,
> correct?
"git add ." will add the contents of any modified files to the index, as
well as add any untracked files (which may or may not be what you want).
It will not add removals. Try "git add -u" which updates all files that
git knows about (i.e., modifications and removals). You can also simply
use "git commit -a" which is the moral equivalent of "git add -u ; git
commit".
-Peff
^ permalink raw reply
* something like git-for-each-ref's --format for commits?
From: Brian Swetland @ 2008-01-06 8:52 UTC (permalink / raw)
To: git
I'm trying to obtain various information about commits from a script.
The --format option to git-for-each-ref would be perfect, except that
it only operates on refs, not arbitrary commit objects.
The --pretty=format:... option for git-log, etc has the annoying
property of giving you <unknown> instead of an empty string if an
item isn't example (say if you use %b on a commit with no body).
Am I missing some obvious solution here?
Thanks,
Brian
^ permalink raw reply
* Re: something like git-for-each-ref's --format for commits?
From: Jeff King @ 2008-01-06 9:05 UTC (permalink / raw)
To: Brian Swetland; +Cc: git
In-Reply-To: <20080106085221.GA1729@bulgaria.corp.google.com>
On Sun, Jan 06, 2008 at 12:52:21AM -0800, Brian Swetland wrote:
> The --pretty=format:... option for git-log, etc has the annoying
> property of giving you <unknown> instead of an empty string if an
> item isn't example (say if you use %b on a commit with no body).
>
> Am I missing some obvious solution here?
I think --pretty=format: is what you are looking for. The "<unknown>"
behavior is fixed in the upcoming v1.5.4 (you get the empty string for
your example).
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: work correctly with ambiguous refnames
From: Johannes Schindelin @ 2008-01-06 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x337jgn.fsf@gitster.siamese.dyndns.org>
Hi Junio,
On Sat, 5 Jan 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > In any case, from a cursory look I like the 2 patches (except for the
> > curly brackets around the single-line "else" clause, but I know your
> > opinion about this, so I will not object).
>
> And obviously I care more about correctness, so I'd appreciate a review
> with non cursory look if you have time.
I will be in the train for 5.5 hours tomorrow, and hope to do a less
cursory review then.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Allow git-mergetool to handle paths with a leading space
From: Rogan Dawes @ 2008-01-06 9:25 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Signed-off-by: Rogan Dawes <rogan@dawes.za.net>
---
I am working on a project which has the root directory constructed with
a leading space. i.e. ./ dir/. "read" skips the leading space char, and
ends up with an incorrect filename, which can then not be found. Setting
IFS=\n solves this problem.
Thanks to Mikachu and Tv on #git for assistance and suggestions.
Unfortunately, Thunderbird is not very easy to convince not to mangle
patches, so I am attaching the patch as well. Sorry.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 2f31fa2..8521ca3 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -394,7 +394,7 @@ if test $# -eq 0 ; then
exit 0
fi
echo Merging the files: $files
- git ls-files -u | sed -e 's/^[^ ]* //' | sort -u | while read i
+ git ls-files -u | sed -e 's/^[^ ]* //' | sort -u | while
IFS=\n read i
do
printf "\n"
merge_file "$i" < /dev/tty > /dev/tty
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 417 bytes --]
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 2f31fa2..8521ca3 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -394,7 +394,7 @@ if test $# -eq 0 ; then
exit 0
fi
echo Merging the files: $files
- git ls-files -u | sed -e 's/^[^ ]* //' | sort -u | while read i
+ git ls-files -u | sed -e 's/^[^ ]* //' | sort -u | while IFS=\n read i
do
printf "\n"
merge_file "$i" < /dev/tty > /dev/tty
^ permalink raw reply related
* Re: [PATCH] Allow git-mergetool to handle paths with a leading space
From: Junio C Hamano @ 2008-01-06 10:18 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Git Mailing List
In-Reply-To: <47809E7E.2090708@dawes.za.net>
Rogan Dawes <rogan@dawes.za.net> writes:
> Signed-off-by: Rogan Dawes <rogan@dawes.za.net>
>
> ---
> I am working on a project which has the root directory constructed
> with a leading space. i.e. ./ dir/. "read" skips the leading space
> char, and ends up with an incorrect filename, which can then not be
> found. Setting IFS=\n solves this problem.
Does the project have a file that has letter 'n' (en) in its name?
Have you tested your patch while having a conflict in that file?
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Junio C Hamano @ 2008-01-06 10:33 UTC (permalink / raw)
To: Dan McGee
Cc: Junio C Hamano, git, Tsugikazu Shibata, Marco Costalba, Jeff King,
Dmitry Potapov
In-Reply-To: <449c10960801051908u38e87574i59ec314c3ddc775c@mail.gmail.com>
"Dan McGee" <dpmcgee@gmail.com> writes:
>> Ah, I spoke too fast. I think I need to first do a clean-up
>> patch to fix "gitlink::foobar[1]" that should have been spelled
>> as "gitlink:foobar[1]" in a few places, and your change is good.
>
> It looks like I still blew it and forgot the changes in asciidoc.conf
> in the second patch, sorry about that. Let me know if you need
> anything more,...
I think I got all of what you wanted to do now, although my tree
still is not in a shape I can push it out yet (I have to whip
other parts that does not have anything to do with this
documentation fix into shape first).
Thanks.
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Junio C Hamano @ 2008-01-06 10:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080106042935.GB4843@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is a little uglier than it could be because the "colored" function
> does two things: correctly colorize a string, and check the global
> $use_color.
That fallout is a logical consequence of the semantics change of
color.interactive, which used to color the whole user experience
but now only covers about menus and stuff. $use_color is still
tied to the former semantics.
It may make more sense to:
* unset $prompt_color and friends when color.interactive says
"not to color the menus";
* unset $fraginfo_color and diff related ones when color.diff
says "diff is monochrome";
upfront, and then change "sub colored" to just check if $color
is unset, instead of checking $use_color.
^ permalink raw reply
* Re: [PATCH] Allow git-mergetool to handle paths with a leading space
From: Rogan Dawes @ 2008-01-06 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vodbz5ka9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Rogan Dawes <rogan@dawes.za.net> writes:
>
>> Signed-off-by: Rogan Dawes <rogan@dawes.za.net>
>>
>> ---
>> I am working on a project which has the root directory constructed
>> with a leading space. i.e. ./ dir/. "read" skips the leading space
>> char, and ends up with an incorrect filename, which can then not be
>> found. Setting IFS=\n solves this problem.
>
> Does the project have a file that has letter 'n' (en) in its name?
> Have you tested your patch while having a conflict in that file?
>
Yes, it works correctly.
$ git mergetool
merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff vimdiff
opendiff emerge vimdiff
Merging the files:
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/BackDoors.java
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/BlindSqlInjection.java
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/Challenge2Screen.java
Normal merge conflict for '
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/BackDoors.java':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (kdiff3):
merge of
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/BackDoors.java
failed
$
My copy and paste does not show the spaces properly, since everything
gets wrapped. but the "Normal merge conflict for ' webgoat/" line would
have taken the ' to the next line if the space was not there. :-)
Note that the lines after "Merging the files" don't include the spaces,
but that is just cosmetic, IMO.
Rogan
^ permalink raw reply
* [PATCH 1/3] git.el: Support for getting diffs from inside the log-edit buffer.
From: Alexandre Julliard @ 2008-01-06 11:12 UTC (permalink / raw)
To: git
Take advantage of the new log-edit feature that allows to show a diff
with C-c C-d while editing the log message.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 28a4899..e0e6316 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1024,7 +1024,9 @@ Return the list of files that haven't been handled."
(setq default-directory dir)
(setq buffer-read-only t)))
(display-buffer buffer)
- (shrink-window-if-larger-than-buffer))
+ ; shrink window only if it displays the status buffer
+ (when (eq (window-buffer) (current-buffer))
+ (shrink-window-if-larger-than-buffer)))
(defun git-diff-file ()
"Diff the marked file(s) against HEAD."
@@ -1097,6 +1099,11 @@ Return the list of files that haven't been handled."
(with-current-buffer log-edit-parent-buffer
(git-get-filenames (git-marked-files-state 'added 'deleted 'modified))))
+(defun git-log-edit-diff ()
+ "Run a diff of the current files being committed from a log-edit buffer."
+ (with-current-buffer log-edit-parent-buffer
+ (git-diff-file)))
+
(defun git-append-sign-off (name email)
"Append a Signed-off-by entry to the current buffer, avoiding duplicates."
(let ((sign-off (format "Signed-off-by: %s <%s>" name email))
@@ -1169,7 +1176,10 @@ Return the list of files that haven't been handled."
(when (re-search-forward "^Date: \\(.*\\)$" nil t)
(setq date (match-string 1)))))
(git-setup-log-buffer buffer author-name author-email subject date))
- (log-edit #'git-do-commit nil #'git-log-edit-files buffer)
+ (if (boundp 'log-edit-diff-function)
+ (log-edit 'git-do-commit nil '((log-edit-listfun . git-log-edit-files)
+ (log-edit-diff-function . git-log-edit-diff)) buffer)
+ (log-edit 'git-do-commit nil 'git-log-edit-files buffer))
(setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
(setq buffer-file-coding-system coding-system)
(re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
--
1.5.4.rc2.53.gb6f8
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 2/3] git.el: Retrieve the permissions for up-to-date files.
From: Alexandre Julliard @ 2008-01-06 11:13 UTC (permalink / raw)
To: git
This allows displaying correctly the executable flag for the initial
commit, and will make it possible to show the file type for up-to-date
symlinks and subprojects.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index e0e6316..820df11 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -642,6 +642,22 @@ Return the list of files that haven't been handled."
(git-insert-info-list status infolist)
files))
+(defun git-run-ls-files-cached (status files default-state)
+ "Run git-ls-files -c on FILES and parse the results into STATUS.
+Return the list of files that haven't been handled."
+ (let (infolist)
+ (with-temp-buffer
+ (apply #'git-call-process-env t nil "ls-files" "-z" "-s" "-c" "--" files)
+ (goto-char (point-min))
+ (while (re-search-forward "\\([0-7]\\{6\\}\\) [0-9a-f]\\{40\\} [0-3]\t\\([^\0]+\\)\0" nil t)
+ (let* ((new-perm (string-to-number (match-string 1) 8))
+ (old-perm (if (eq default-state 'added) 0 new-perm))
+ (name (match-string 2)))
+ (push (git-create-fileinfo default-state name old-perm new-perm) infolist)
+ (setq files (delete name files)))))
+ (git-insert-info-list status infolist)
+ files))
+
(defun git-run-ls-unmerged (status files)
"Run git-ls-files -u on FILES and parse the results into STATUS."
(with-temp-buffer
@@ -673,10 +689,10 @@ Return the list of files that haven't been handled."
"Update the status of FILES from the index."
(unless git-status (error "Not in git-status buffer."))
(unless files
- (when git-show-uptodate (git-run-ls-files git-status nil 'uptodate "-c")))
+ (when git-show-uptodate (git-run-ls-files-cached git-status nil 'uptodate)))
(let* ((remaining-files
(if (git-empty-db-p) ; we need some special handling for an empty db
- (git-run-ls-files git-status files 'added "-c")
+ (git-run-ls-files-cached git-status files 'added)
(git-run-diff-index git-status files))))
(git-run-ls-unmerged git-status files)
(when (or remaining-files (and git-show-unknown (not files)))
--
1.5.4.rc2.53.gb6f8
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 3/3] git.el: Display file types and type changes.
From: Alexandre Julliard @ 2008-01-06 11:13 UTC (permalink / raw)
To: git
Handle the T status from git-diff-index to display type changes
between file/symlink/subproject. Also always show the file type for
symlink and subprojects to indicate that they are not normal files.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 34 +++++++++++++++++++++++++++++++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 820df11..5f0d461 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -489,8 +489,7 @@ and returns the process output as a string."
"Set the state of a file info."
(unless (eq (git-fileinfo->state info) state)
(setf (git-fileinfo->state info) state
- (git-fileinfo->old-perm info) 0
- (git-fileinfo->new-perm info) 0
+ (git-fileinfo->new-perm info) (git-fileinfo->old-perm info)
(git-fileinfo->rename-state info) nil
(git-fileinfo->orig-name info) nil
(git-fileinfo->needs-refresh info) t)))
@@ -524,6 +523,7 @@ and returns the process output as a string."
(?A 'added)
(?D 'deleted)
(?U 'unmerged)
+ (?T 'modified)
(t nil)))
(defun git-status-code-as-string (code)
@@ -538,6 +538,33 @@ and returns the process output as a string."
('ignored (propertize "Ignored " 'face 'git-ignored-face))
(t "? ")))
+(defun git-file-type-as-string (info)
+ "Return a string describing the file type of INFO."
+ (let* ((old-type (lsh (or (git-fileinfo->old-perm info) 0) -9))
+ (new-type (lsh (or (git-fileinfo->new-perm info) 0) -9))
+ (str (case new-type
+ (?\100 ;; file
+ (case old-type
+ (?\100 nil)
+ (?\120 " (type change symlink -> file)")
+ (?\160 " (type change subproject -> file)")))
+ (?\120 ;; symlink
+ (case old-type
+ (?\100 " (type change file -> symlink)")
+ (?\160 " (type change subproject -> symlink)")
+ (t " (symlink)")))
+ (?\160 ;; subproject
+ (case old-type
+ (?\100 " (type change file -> subproject)")
+ (?\120 " (type change symlink -> subproject)")
+ (t " (subproject)")))
+ (?\000 ;; deleted or unknown
+ (case old-type
+ (?\120 " (symlink)")
+ (?\160 " (subproject)")))
+ (t (format " (unknown type %o)" new-type)))))
+ (if str (propertize str 'face 'git-status-face) "")))
+
(defun git-rename-as-string (info)
"Return a string describing the copy or rename associated with INFO, or an empty string if none."
(let ((state (git-fileinfo->rename-state info)))
@@ -567,6 +594,7 @@ and returns the process output as a string."
" " (git-status-code-as-string (git-fileinfo->state info))
" " (git-permissions-as-string (git-fileinfo->old-perm info) (git-fileinfo->new-perm info))
" " (git-escape-file-name (git-fileinfo->name info))
+ (git-file-type-as-string info)
(git-rename-as-string info))))
(defun git-insert-info-list (status infolist)
@@ -603,7 +631,7 @@ Return the list of files that haven't been handled."
(apply #'git-call-process-env t nil "diff-index" "-z" "-M" "HEAD" "--" files)
(goto-char (point-min))
(while (re-search-forward
- ":\\([0-7]\\{6\\}\\) \\([0-7]\\{6\\}\\) [0-9a-f]\\{40\\} [0-9a-f]\\{40\\} \\(\\([ADMU]\\)\0\\([^\0]+\\)\\|\\([CR]\\)[0-9]*\0\\([^\0]+\\)\0\\([^\0]+\\)\\)\0"
+ ":\\([0-7]\\{6\\}\\) \\([0-7]\\{6\\}\\) [0-9a-f]\\{40\\} [0-9a-f]\\{40\\} \\(\\([ADMUT]\\)\0\\([^\0]+\\)\\|\\([CR]\\)[0-9]*\0\\([^\0]+\\)\0\\([^\0]+\\)\\)\0"
nil t 1)
(let ((old-perm (string-to-number (match-string 1) 8))
(new-perm (string-to-number (match-string 2) 8))
--
1.5.4.rc2.53.gb6f8
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: What's in git.git (stable frozen)
From: Jeff King @ 2008-01-06 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejcv5is3.fsf@gitster.siamese.dyndns.org>
On Sun, Jan 06, 2008 at 02:51:24AM -0800, Junio C Hamano wrote:
> It may make more sense to:
>
> * unset $prompt_color and friends when color.interactive says
> "not to color the menus";
>
> * unset $fraginfo_color and diff related ones when color.diff
> says "diff is monochrome";
>
> upfront, and then change "sub colored" to just check if $color
> is unset, instead of checking $use_color.
Something like this (instead of my last patch):
-- >8 --
add--interactive: fix "colored" function semantics
Since color.interactive is just for the menus, the "colored"
function can't use it to determine whether to show colors
(this was visible as a bug in which the headers of split
hunks were not colored if color.diff was set but
color.interactive was not).
The new semantics are:
- colors which are unused are set to undef; the "colored"
function knows not to do anything with them
- menu colors are set only when color.interactive is true
- diff colors are set only when color.diff is true
Signed-off-by: Jeff King <peff@peff.net>
---
git-add--interactive.perl | 39 +++++++++++++++------------------------
1 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 5bdcca8..17ca5b8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -3,38 +3,29 @@
use strict;
use Git;
-# Prompt colors:
-my ($prompt_color, $header_color, $help_color, $normal_color);
-# Diff colors:
-my ($fraginfo_color);
-
-my ($use_color, $diff_use_color);
my $repo = Git->repository();
-$use_color = $repo->get_colorbool('color.interactive');
-
-if ($use_color) {
- # Set interactive colors:
+my $menu_use_color = $repo->get_colorbool('color.interactive');
+my ($prompt_color, $header_color, $help_color) =
+ $menu_use_color ? (
+ $repo->get_color('color.interactive.prompt', 'bold blue'),
+ $repo->get_color('color.interactive.header', 'bold'),
+ $repo->get_color('color.interactive.help', 'red bold'),
+ ) : ();
- # Grab the 3 main colors in git color string format, with sane
- # (visible) defaults:
- $prompt_color = $repo->get_color("color.interactive.prompt", "bold blue");
- $header_color = $repo->get_color("color.interactive.header", "bold");
- $help_color = $repo->get_color("color.interactive.help", "red bold");
- $normal_color = $repo->get_color("", "reset");
-}
+my $diff_use_color = $repo->get_colorbool('color.diff');
+my ($fraginfo_color) =
+ $diff_use_color ? (
+ $repo->get_color('color.diff.frag', 'cyan'),
+ ) : ();
-# Do we also set diff colors?
-$diff_use_color = $repo->get_colorbool('color.diff');
-if ($diff_use_color) {
- $fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
-}
+my $normal_color = $repo->get_color("", "reset");
sub colored {
my $color = shift;
my $string = join("", @_);
- if ($use_color) {
+ if (defined $color) {
# Put a color code at the beginning of each line, a reset at the end
# color after newlines that are not at the end of the string
$string =~ s/(\n+)(.)/$1$color$2/g;
@@ -300,7 +291,7 @@ sub highlight_prefix {
return "$prefix$remainder";
}
- if (!$use_color) {
+ if (!$menu_use_color) {
return "[$prefix]$remainder";
}
--
1.5.4.rc2.1148.gf9fe3-dirty
^ permalink raw reply related
* Re: [PATCH] Allow git-mergetool to handle paths with a leading space
From: Junio C Hamano @ 2008-01-06 11:48 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Git Mailing List
In-Reply-To: <4780B2BD.6020109@dawes.za.net>
Rogan Dawes <rogan@dawes.za.net> writes:
>>> I am working on a project which has the root directory constructed
>>> with a leading space. i.e. ./ dir/. "read" skips the leading space
>>> char, and ends up with an incorrect filename, which can then not be
>>> found. Setting IFS=\n solves this problem.
>>
>> Does the project have a file that has letter 'n' (en) in its name?
>> Have you tested your patch while having a conflict in that file?
>
> Yes, it works correctly.
I am curious and puzzled...
$ echo 'ann1' | (IFS=\n read i; echo "<$i>")
<ann1>
$ echo 'ann1' | (IFS=\n read i j; echo "<$i>")
<a>
$ echo 'n1' | (IFS=\n read i j; echo "<$i>")
<>
Ok, "\n" is a funny way to say IFS does not matter as long as it
is set to a non whitespace letter.
It is VERY misleading as it looks as if the issue is fixed by
setting IFS to a single LF alone (excluding SP and HT from the
usual set), but that is not the patch is doing. It is setting
it to a single 'n'.
I think you still will lose backslash by using read, but I guess
you would not care about that too much.
If you really cared, you would do something like this, but you
would also need similar surgery in merge_file function itself
that parses text form of ls-files output that tries to verify
and extract paths, which I did not bother to touch in this
demonstration patch.
git-mergetool.sh | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 2f31fa2..b7c5098 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -388,17 +388,28 @@ fi
if test $# -eq 0 ; then
- files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
- if test -z "$files" ; then
- echo "No files need merging"
- exit 0
- fi
- echo Merging the files: $files
- git ls-files -u | sed -e 's/^[^ ]* //' | sort -u | while read i
- do
- printf "\n"
- merge_file "$i" < /dev/tty > /dev/tty
- done
+ doit=$(perl -e '
+ $/ = "\0";
+ my (%seen, @file);
+ my $ls_files;
+ open($ls_files, "-|", qw(git ls-files -u -z));
+ while (<$ls_files>) {
+ chomp;
+ s/^[^ ]* //;
+ $seen{$_}++;
+ }
+ @file = sort keys %seen;
+ if (!@file) {
+ print "echo No files need merging\n";
+ print "exit 0\n";
+ }
+ for (@file) {
+ s|'\''|'\''\\'\'''\''|g;
+ print "echo\n";
+ print "merge_file '\''$_'\'' </dev/tty >/dev/tty\n";
+ }
+ ')
+ eval "$doit"
else
while test $# -gt 0; do
printf "\n"
^ permalink raw reply related
* Re: What's in git.git (stable frozen)
From: Junio C Hamano @ 2008-01-06 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080106111725.GA11603@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Something like this (instead of my last patch):
Yeah, I like that much better, especially the renaming of
$use_color to more descriptive (but is it really about "menu", I
wonder?).
I might consider rewriting this part
> +my $menu_use_color = $repo->get_colorbool('color.interactive');
> +my ($prompt_color, $header_color, $help_color) =
> + $menu_use_color ? (
> + $repo->get_color('color.interactive.prompt', 'bold blue'),
> + $repo->get_color('color.interactive.header', 'bold'),
> + $repo->get_color('color.interactive.help', 'red bold'),
> + ) : ();
like this:
my ($prompt_color, $header_color, $help_color, $fraginfo_color);
if ($colored_prompt) {
$prompt_color = ...;
$header_color = ...;
}
if ($colored_diff) {
$fraginfo_color = ...;
}
or even like this:
my (%palette);
if ($colored_prompt) {
my %default = (
prompt => 'bold blue',
header => 'bold',
...
);
while (my ($k,$v) = each %default) {
$palette{$k} = $repo->get_color("color.interactive.$k",$v);
}
}
But I realize that's going overboard. Certainly the last one is
doing unnecessary generalization for generalization's sake.
^ permalink raw reply
* [PATCH] Make commit, cherry-pick and revert more silent.
From: Gabriel @ 2008-01-06 15:43 UTC (permalink / raw)
To: git; +Cc: Gabriel
Commit now obeys --quiet more.
Cherry-pick and revert call commit as --quiet.
Prevents us from displaying working-tree status once or even twice.
---
builtin-commit.c | 4 +++-
builtin-revert.c | 6 ++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 73f1e35..96ace77 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -759,7 +759,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!prepare_log_message(index_file, prefix) && !in_merge &&
!allow_empty && !(amend && is_a_merge(head_sha1))) {
- run_status(stdout, index_file, prefix, 0);
+ fprintf(stderr, "There are no changes, not committing.\n");
+ if (!quiet)
+ run_status(stdout, index_file, prefix, 0);
rollback_index_files();
unlink(commit_editmsg);
return 1;
diff --git a/builtin-revert.c b/builtin-revert.c
index 4bf8eb2..b925358 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -392,9 +392,11 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (!no_commit) {
if (edit)
- return execl_git_cmd("commit", "-n", NULL);
+ return execl_git_cmd("commit", "--quiet",
+ "-n", NULL);
else
- return execl_git_cmd("commit", "-n", "-F", defmsg, NULL);
+ return execl_git_cmd("commit", "--quiet",
+ "-n", "-F", defmsg, NULL);
}
if (reencoded_message)
free(reencoded_message);
--
1.5.4.rc2.39.g00d2
^ permalink raw reply related
* [PATCH] rebase interactive: Add hint how to continue after 'Unknown command' error
From: Steffen Prohaska @ 2008-01-06 15:46 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
rebase interactive asks the user to fix unknown commands but it did not
tell how to continue.
This commits adds a hint how to continue.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index acdcc54..d4bd811 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -310,7 +310,7 @@ do_next () {
;;
*)
warn "Unknown command: $command $sha1 $rest"
- die_with_patch $sha1 "Please fix this in the file $TODO."
+ die_with_patch $sha1 "Please fix this in the file $TODO. And run 'git rebase --continue'."
;;
esac
test -s "$TODO" && return
--
1.5.4.rc2.26.g1deb
^ permalink raw reply related
* [PATCH] tree-walk: don't parse incorrect entries
From: Martin Koegler @ 2008-01-06 17:21 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 NUL, 20 bytes sha1).
* Check that the last NUL (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 path must contain at least one character.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
tree-walk.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index 8d4b673..10f21d7 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,16 @@ 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;
+ if (size < 24 || buf[size - 21])
+ die("corrupt tree file");
+
path = get_mode(buf, &mode);
- if (!path)
+ if (!path || !*path)
die("corrupt tree file");
len = strlen(path) + 1;
--
1.4.4.4
^ permalink raw reply related
* Re: [PATCH] tree-walk: don't parse incorrect entries
From: Martin Koegler @ 2008-01-06 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1w8w80a3.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 05, 2008 at 12:50:28PM -0800, Junio C Hamano wrote:
> Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> > * 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?
Yes, I agree with you.
> Rejecting an empty path may be sensible (i.e. checking "!*path"
> instead), though.
I sent a new patch with both changes.
mfg Martin Kögler
^ 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