* [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-12 6:19 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
It's nice to search for an author by merely clicking on their name in
gitweb. This is usually faster than selecting the name, copying the
selection, pasting it into the search box, selecting between
author/committer and then hitting enter.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Cc'ed Jakub as he seems to be resident gitweb expert.
I thought this might be a nice addition.
The problem is I can't get it to work with UTF-8 characters. I'm not sure
if it's my system or not, so I'm just posting here to see if others
experience the same problem and if there's interest.
gitweb/gitweb.perl | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..349e734 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1604,7 +1604,10 @@ sub format_author_html {
my $author = chop_and_escape_str($co->{'author_name'}, @_);
return "<$tag class=\"author\">" .
git_get_avatar($co->{'author_email'}, -pad_after => 1) .
- $author . "</$tag>";
+ $cgi->a({-href => href(action=>"search", hash=>$hash,
+ searchtext=>$co->{'author_name'},
+ searchtype=>"author"), class=>"list"}, $author) .
+ "</$tag>";
}
# format git diff header line, i.e. "diff --(git|combined|cc) ..."
@@ -3373,10 +3376,13 @@ sub git_print_authorship {
my $co = shift;
my %opts = @_;
my $tag = $opts{-tag} || 'div';
+ my $author = $co->{'author_name'};
my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
print "<$tag class=\"author_date\">" .
- esc_html($co->{'author_name'}) .
+ $cgi->a({-href => href(action=>"search", searchtext=>$author,
+ searchtype=>"author"), class=>"list"},
+ esc_html($author)) .
" [$ad{'rfc2822'}";
print_local_time(%ad) if ($opts{-localtime});
print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
@@ -3395,8 +3401,12 @@ sub git_print_authorship_rows {
@people = ('author', 'committer') unless @people;
foreach my $who (@people) {
my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
- print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
- "<td rowspan=\"2\">" .
+ print "<tr><td>$who</td><td>" .
+ $cgi->a({-href => href(action=>"search",
+ searchtext=>$co->{"${who}_name"},
+ searchtype=>$who), class=>"list"},
+ esc_html($co->{$who})) .
+ "</td><td rowspan=\"2\">" .
git_get_avatar($co->{"${who}_email"}, -size => 'double') .
"</td></tr>\n" .
"<tr>" .
--
1.6.5.1.g53fd
^ permalink raw reply related
* Re: [PATCH/RFC 0/4] plumbing to help fix git-gui
From: Jonathan Nieder @ 2009-10-12 5:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> Perhaps an interface to give a cleaned-up version, e.g.
>>
>> $ git check-ref-format --print refs/heads//foo/bar
>> refs/heads/foo/bar
>>
>> is what you want in order to fix git-gui? I dunno.
>
> The following packages do exactly that.
s/packages/patches/
I better sleep...
Sorry for the confusion,
Jonathan
^ permalink raw reply
* Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 5:28 UTC (permalink / raw)
To: git
Git is good, Git is great! All praise the Git! :-D
What do you people think about this strange phenomena?
localhost / # git --version
git version 1.6.4.4
localhost / # git init
Initialized empty Git repository in //.git/
localhost / # cd etc
localhost etc # git add X11/xorg.conf
fatal: pathspec 'etc/X11/xorg.conf' did not match any files
Aside from the obvious question of why would I want to Git the whole
tree ("But all files deserve the Holy Presence of the Git!"), why does
Git refuse the love offering from "/etc/X11/xorg.conf"? Is it because
it contains font directory configurations?
Commit and [ENTER] to all,
S! :-)
^ permalink raw reply
* [PATCH/RFC 4/4] check-ref-format: simplify --print implementation
From: Jonathan Nieder @ 2009-10-12 5:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
normalize_path_copy() is a complicated function, but most of its
functionality will never apply to a ref name that has been checked
with check_ref_format().
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-check-ref-format.c | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index b97b61a..e439136 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -7,6 +7,28 @@
#include "builtin.h"
#include "strbuf.h"
+/*
+ * Replace each run of adjacent slashes in src with a single slash,
+ * and write the result to dst.
+ *
+ * This function is similar to normalize_path_copy(), but stripped down
+ * to meet check_ref_format's simpler needs.
+ */
+static void collapse_slashes(char *dst, const char *src)
+{
+ char ch;
+ char prev = '\0';
+
+ while (ch = *src++) {
+ if (prev == '/' && ch == prev)
+ continue;
+
+ *dst++ = ch;
+ prev = ch;
+ }
+ *dst = '\0';
+}
+
int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
{
if (argc == 3 && !strcmp(argv[1], "--branch")) {
@@ -22,8 +44,7 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
if (check_ref_format(argv[2]))
exit(1);
- if (normalize_path_copy(refname, argv[2]))
- die("Could not normalize ref name '%s'", argv[2]);
+ collapse_slashes(refname, argv[2]);
printf("%s\n", refname);
exit(0);
}
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH/RFC 3/4] git check-ref-format --print
From: Jonathan Nieder @ 2009-10-12 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
Tolerating empty path components in ref names means each ref does
not have a unique name. This creates difficulty for porcelains
that want to see if two branches are equal. Add a helper associating
to each ref a canonical name.
If a user asks a porcelain to create a ref "refs/heads//master",
the porcelain can run "git check-ref-format --print refs/heads//master"
and only deal with "refs/heads/master" from then on.
In the future, it would be very nice if this command could be
modified to transform Unicode ref names to some appropriate
normalization form, to make Unicode ref names usable in Mac OS X,
too, and less confusing everywhere.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-check-ref-format.txt | 25 +++++++++++++++++++------
builtin-check-ref-format.c | 10 ++++++++++
t/t1402-check-ref-format.sh | 17 +++++++++++++++++
3 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index e9b3b40..0aeef24 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -9,6 +9,7 @@ SYNOPSIS
--------
[verse]
'git check-ref-format' <refname>
+'git check-ref-format' --print <refname>
'git check-ref-format' --branch <branchname-shorthand>
DESCRIPTION
@@ -63,19 +64,31 @@ reference name expressions (see linkgit:git-rev-parse[1]):
. at-open-brace `@{` is used as a notation to access a reflog entry.
+With the `--print` option, if 'refname' is acceptable, it prints the
+canonicalized name of a hypothetical reference with that name. That is,
+it prints 'refname' with any extra `/` characters removed.
+
With the `--branch` option, it expands the ``previous branch syntax''
`@{-n}`. For example, `@{-1}` is a way to refer the last branch you
were on. This option should be used by porcelains to accept this
syntax anywhere a branch name is expected, so they can act as if you
typed the branch name.
-EXAMPLE
--------
-
-git check-ref-format --branch @{-1}::
-
-Print the name of the previous branch.
+EXAMPLES
+--------
+* Print the name of the previous branch:
++
+------------
+$ git check-ref-format --branch @{-1}
+------------
+
+* Determine the reference name to use for a new branch:
++
+------------
+$ ref=$(git check-ref-format --print "refs/heads/$newbranch") ||
+die "we do not like '$newbranch' as a branch name."
+------------
GIT
---
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index f9381e0..b97b61a 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -17,6 +17,16 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
printf("%s\n", sb.buf + 11);
exit(0);
}
+ if (argc == 3 && !strcmp(argv[1], "--print")) {
+ char *refname = xmalloc(strlen(argv[2]) + 1);
+
+ if (check_ref_format(argv[2]))
+ exit(1);
+ if (normalize_path_copy(refname, argv[2]))
+ die("Could not normalize ref name '%s'", argv[2]);
+ printf("%s\n", refname);
+ exit(0);
+ }
if (argc != 2)
usage("git check-ref-format refname");
return !!check_ref_format(argv[1]);
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 382bc6e..eb45afb 100644
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -41,4 +41,21 @@ test_expect_success "check-ref-format --branch @{-1}" '
refname2=$(git check-ref-format --branch @{-2}) &&
test "$refname2" = master'
+valid_ref_normalized() {
+ test_expect_success "ref name '$1' simplifies to '$2'" "
+ refname=\$(git check-ref-format --print '$1') &&
+ test \"\$refname\" = '$2'"
+}
+invalid_ref_normalized() {
+ test_expect_success "check-ref-format --print rejects '$1'" "
+ test_must_fail git check-ref-format --print '$1'"
+}
+
+valid_ref_normalized 'heads/foo' 'heads/foo'
+valid_ref_normalized 'refs///heads/foo' 'refs/heads/foo'
+invalid_ref_normalized 'foo'
+invalid_ref_normalized 'heads/foo/../bar'
+invalid_ref_normalized 'heads/./foo'
+invalid_ref_normalized 'heads\foo'
+
test_done
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH 1/4] Add tests for git check-ref-format
From: Jonathan Nieder @ 2009-10-12 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
The "git check-ref-format" command is a basic command various
porcelains rely on. Test its functionality to make sure it does
not unintentionally change.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
t/t1402-check-ref-format.sh | 44 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 t/t1402-check-ref-format.sh
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
new file mode 100644
index 0000000..382bc6e
--- /dev/null
+++ b/t/t1402-check-ref-format.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+test_description='Test git check-ref-format'
+
+. ./test-lib.sh
+
+valid_ref() {
+ test_expect_success "ref name '$1' is valid" \
+ "git check-ref-format '$1'"
+}
+invalid_ref() {
+ test_expect_success "ref name '$1' is not valid" \
+ "test_must_fail git check-ref-format '$1'"
+}
+
+valid_ref 'heads/foo'
+invalid_ref 'foo'
+valid_ref 'foo/bar/baz'
+valid_ref 'refs///heads/foo'
+invalid_ref 'heads/foo/'
+invalid_ref './foo'
+invalid_ref '.refs/foo'
+invalid_ref 'heads/foo..bar'
+invalid_ref 'heads/foo?bar'
+valid_ref 'foo./bar'
+invalid_ref 'heads/foo.lock'
+valid_ref 'heads/foo@bar'
+invalid_ref 'heads/v@{ation'
+invalid_ref 'heads/foo\bar'
+
+test_expect_success "check-ref-format --branch @{-1}" '
+ T=$(git write-tree) &&
+ sha1=$(echo A | git commit-tree $T) &&
+ git update-ref refs/heads/master $sha1 &&
+ git update-ref refs/remotes/origin/master $sha1
+ git checkout master &&
+ git checkout origin/master &&
+ git checkout master &&
+ refname=$(git check-ref-format --branch @{-1}) &&
+ test "$refname" = "$sha1" &&
+ refname2=$(git check-ref-format --branch @{-2}) &&
+ test "$refname2" = master'
+
+test_done
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH 2/4] Documentation: describe check-ref-format --branch
From: Jonathan Nieder @ 2009-10-12 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
Unless one already knew, it was not obvious what sort of shorthand
"git check-ref-format --branch" expands. Explain it.
The --branch argument is not optional.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-check-ref-format.txt | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 0b7982e..e9b3b40 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git check-ref-format' <refname>
-'git check-ref-format' [--branch] <branchname-shorthand>
+'git check-ref-format' --branch <branchname-shorthand>
DESCRIPTION
-----------
@@ -63,8 +63,11 @@ reference name expressions (see linkgit:git-rev-parse[1]):
. at-open-brace `@{` is used as a notation to access a reflog entry.
-With the `--branch` option, it expands a branch name shorthand and
-prints the name of the branch the shorthand refers to.
+With the `--branch` option, it expands the ``previous branch syntax''
+`@{-n}`. For example, `@{-1}` is a way to refer the last branch you
+were on. This option should be used by porcelains to accept this
+syntax anywhere a branch name is expected, so they can act as if you
+typed the branch name.
EXAMPLE
-------
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH/RFC 0/4] plumbing to help fix git-gui
From: Jonathan Nieder @ 2009-10-12 5:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <7vws327wbp.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> I became aware of this issue while looking into problems occuring
>> when a user created a branch starting with a '/' in git gui (e.g.
>> "/foo"). Strange things happen, while git gui shows the current
>> branch as "/foo" under the hood a branch "foo" (without the slash)
>> had been created. But then you can't delete "/foo" from git gui,
>> because a branch of that name doesn't exist.
>
> Perhaps an interface to give a cleaned-up version, e.g.
>
> $ git check-ref-format --print refs/heads//foo/bar
> refs/heads/foo/bar
>
> is what you want in order to fix git-gui? I dunno.
The following packages do exactly that. I tried to use it to fix
git gui, but my Tcl-fu was not up to it, at least for tonight.
It is not obvious to me that this interface is the one that would be
most helpful for git gui: probably a command to just munge the branch
name would be more convenient, though less general.
Is the --print option useful? Right now, it seems that its main use is
documentation. But in the future, it would be very nice if this command
could be used to transform Unicode ref names to some appropriate
normalization form, to make Unicode ref names usable in Mac OS X and
less confusing everywhere.
I look forward to your thoughts.
Jonathan Nieder (4):
Add tests for git check-ref-format
Documentation: describe check-ref-format --branch in more detail
check-ref-format: add option to print canonical name
check-ref-format: Simplify --print implementation
Documentation/git-check-ref-format.txt | 32 ++++++++++++----
builtin-check-ref-format.c | 31 ++++++++++++++++
t/t1402-check-ref-format.sh | 61 ++++++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 8 deletions(-)
create mode 100644 t/t1402-check-ref-format.sh
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Jeff King @ 2009-10-12 5:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx9pmhae.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 08:18:17PM -0700, Junio C Hamano wrote:
> * jk/1.7.0-status (2009-09-05) 5 commits.
> - docs: note that status configuration affects only long format
> (merged to 'next' on 2009-10-11 at 65c8513)
> + commit: support alternate status formats
> + status: add --porcelain output format
> + status: refactor format option parsing
> + status: refactor short-mode printing to its own function
> (this branch uses jc/1.7.0-status.)
>
> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
> is similar to that of post 1.7.0 "git status".
>
> * jc/1.7.0-status (2009-09-05) 4 commits.
> (merged to 'next' on 2009-10-11 at 9558627)
> + status: typo fix in usage
> + git status: not "commit --dry-run" anymore
> + git stat -s: short status output
> + git stat: the beginning of "status that is not a dry-run of commit"
> (this branch is used by jk/1.7.0-status.)
>
> With this, "git status" is no longer "git commit --dry-run".
Hmm. I thought you wanted to re-order some of these for to put the
porcelain and short formats into v1.6.6, but leave the status switchover
for v1.7.0.
We can always revert selectively, but I though the post-v1.6.5 rewind
would be a good time to re-order.
-Peff
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-12 5:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7v63alpbwx.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 07:46:06PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So now I am doubly confused. Did this feature exist, and was broken, and
> > you actually fixed it in 63d285c, creating what looked like a regression
> > but was actually intentional?
>
> I do not think it was an intentional change. I _think_ the comment at the
> beginning of show_files() tells us quite a bit---we don't do read-dir when
> showing the indexed files, and I suspect that we used to rely on the fact
> that not doing the read-dir made exclusion mechanism a no-op. After the
> lazy .gitignore reading, I suspect that excluded() call started to
> initialize the exclude mechanism lazily, and that is how the bug was
> introduced, isn't it?
I did a bit more looking, and the situation is a bit more complex than
that. Hopefully the commit message below explains it.
-- >8 --
Subject: [PATCH] ls-files: excludes should not impact tracked files
In all parts of git, .gitignore and other exclude files
impact only how we treat untracked files; they should have
no effect on files listed in the index.
This behavior was originally implemented very early on in
9ff768e, but only for --exclude-from. Later, commit 63d285c
accidentally caused us to trigger the behavior for
--exclude-per-directory.
This patch totally ignores excludes for files found in the
index. This means we are reversing the original intent of
9ff768e, while at the same time fixing the accidental
behavior of 63d285c. This is a good thing, though, as the
way that 9ff768e behaved does not really make sense with the
way exclusions are used in modern git.
Signed-off-by: Jeff King <peff@peff.net>
---
One other option would be to retain the --exclude-from behavior but
eliminate the --exclude-per-directory behavior. I don't think this is
very easy, though, as it involves separating out which excludes came
from which file. And I think expecting excludes to impact the list of
index files is crazy, anyway, since no other part of git does so. But we
should recognize that we are changing existing behavior; I consider it a
bug fix, though.
I also still think that Pauli's patch makes sense; there is no point in
passing --exclude-standard there. It should be a no-op.
builtin-ls-files.c | 8 --------
t/t3003-ls-files-exclude.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 8 deletions(-)
create mode 100755 t/t3003-ls-files-exclude.sh
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 2c95ca6..c5c0407 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -170,10 +170,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
if (show_cached | show_stage) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (show_unmerged && !ce_stage(ce))
continue;
if (ce->ce_flags & CE_UPDATE)
@@ -186,10 +182,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
struct cache_entry *ce = active_cache[i];
struct stat st;
int err;
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (ce->ce_flags & CE_UPDATE)
continue;
err = lstat(ce->name, &st);
diff --git a/t/t3003-ls-files-exclude.sh b/t/t3003-ls-files-exclude.sh
new file mode 100755
index 0000000..fc1e379
--- /dev/null
+++ b/t/t3003-ls-files-exclude.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='ls-files --exclude does not affect index files'
+. ./test-lib.sh
+
+test_expect_success 'create repo with file' '
+ echo content >file &&
+ git add file &&
+ git commit -m file &&
+ echo modification >file
+'
+
+check_output() {
+test_expect_success "ls-files output contains file ($1)" "
+ echo '$2' >expect &&
+ git ls-files --exclude-standard --$1 >output &&
+ test_cmp expect output
+"
+}
+
+check_all_output() {
+ check_output 'cached' 'file'
+ check_output 'modified' 'file'
+}
+
+check_all_output
+test_expect_success 'add file to gitignore' '
+ echo file >.gitignore
+'
+check_all_output
+
+test_done
--
1.6.5.rc3.240.g77692
^ permalink raw reply related
* Re: git log --graph
From: B Smith-Mannschott @ 2009-10-12 5:08 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910111127q102aa6a1qc3c0850f8a8a1509@mail.gmail.com>
On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
> I am using: git version 1.6.3.2
>
> Somehow not getting text graph as mentioned in
> http://www.gitready.com/intermediate/2009/01/26/text-based-graph.html
>
> Any hints would really help..
>
> I am trying git log --graph. (has commits in two branches...). But
> always see one line :(
"one line"?
1 of history? (i.e. the history of the current branch, but not the other)
2 of text?
3 --pretty=oneline?
assuming your problem is 1:
git log --all --graph
//ben
^ permalink raw reply
* Re: [PATCH 3/3] user-manual: use 'fast-forward'
From: Junio C Hamano @ 2009-10-12 5:05 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-4-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> It's a compound word.
Thanks.
This removes 7 out of 37 "fast forward" in Documentation/ directory. Are
we going to convert the remaining ones, too?
^ permalink raw reply
* Re: [PATCH 2/3] git config: clarify bool types
From: Junio C Hamano @ 2009-10-12 5:01 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-3-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> The value is what it is, the --bool and --bool-or-int options don't
> specify the value type, just how it is interpreted. For example: a value
> of '1' can be interpreted as 'true'.
It is not really about "interpreting", but about showing, isn't it?
With this in your .git/config file:
[core]
repositoryformatversion = 0
you would see
$ git config --bool-or-int core.repositoryformatversion
0
$ git config --bool core.repositoryformatversion
false
$ git config --int core.repositoryformatversion
0
So it would be more like...
show value as boolean
show value as integer or boolean
show value as integer
wouldn't it?
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> builtin-config.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-config.c b/builtin-config.c
> index a2d656e..29d7b75 100644
> --- a/builtin-config.c
> +++ b/builtin-config.c
> @@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
> OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
> OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
> OPT_GROUP("Type"),
> - OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
> + OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
> OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
> - OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
> + OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
> OPT_GROUP("Other"),
> OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
> OPT_END(),
> --
> 1.6.5.4.g31fc3
^ permalink raw reply
* [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Vietor Liu @ 2009-10-12 3:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
When the screen height equal 600 px(e.g. Asus EeePC 1024x600), The
_main window_ should be hide the _Push button_ and _Status bar_.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..037a1f2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 5 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5
^ permalink raw reply related
* What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-10-12 3:18 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
As a post-release ritual, I've rebuilt 'next' on top of 'master'.
--------------------------------------------------
[Graduated to "master"]
* ch/am-header (2009-09-25) 2 commits
(merged to 'next' on 2009-09-25 at f86e197)
+ git-am: force egrep to use correct characters set
+ git-am: fixed patch_format detection according to RFC2822
* ef/msvc-noreturn (2009-09-30) 2 commits
(merged to 'next' on 2009-10-07 at 66137a0)
+ add NORETURN_PTR for function pointers
+ increase portability of NORETURN declarations
jk: This is the latest round and I think should be ready for at least
'next' (maybe even 'master' as it is really about the build and not about
functionality).
* fc/mutt-alias (2009-09-30) 1 commit
(merged to 'next' on 2009-10-07 at df7ac20)
+ send-email: fix mutt regex for grouped aliases
jk: Latest round that addressed comments. Ready for 'next' if not
'master'.
* jk/reflog-date (2009-09-24) 1 commit
(merged to 'next' on 2009-09-29 at 43d444a)
+ improve reflog date/number heuristic
--------------------------------------------------
[New Topics]
* jp/maint-send-email-fold (2009-10-08) 1 commit.
- git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
* ks/precompute-completion (2009-10-05) 1 commit.
- Speedup bash completion loading
* pv/maint-add-p-no-exclude (2009-10-10) 1 commit.
(merged to 'next' on 2009-10-11 at 0ff2e96)
+ git-add--interactive: never skip files included in index
* sp/smart-http (2009-10-08) 4 commits.
- Smart fetch and push over HTTP: server side
- Add smart-http options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- Document the HTTP transport protocol
--------------------------------------------------
[Stalled]
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Ejected from 'next' as fast-import folks still seem to be discussing with
how to proceed.
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits.
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper. There is a re-roll planned.
* ne/rev-cache (2009-09-07) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
This seems to break at least t6001 when merged to 'pu'.
--------------------------------------------------
[Cooking]
* dk/blame-el (2009-09-29) 1 commit.
- git-blame.el: Change how blame information is shown.
Soon in 'next'.
* ef/msys-imap (2009-10-09) 8 commits.
- MSVC: Enable OpenSSL, and translate -lcrypto
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
- imap-send: remove useless uid code
* jn/gitweb-patch (2009-10-09) 1 commit.
- gitweb: Do not show 'patch' link for merge commits
Soon in 'next'
* mr/gitweb-snapshot (2009-09-26) 2 commits.
- gitweb: append short hash ids to snapshot files
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
* mr/instaweb-cgid (2009-09-26) 1 commit.
(merged to 'next' on 2009-10-11 at 99bcfaf)
+ instaweb: support mod_cgid for apache2
* tf/doc-pt-br (2009-09-23) 1 commit.
- Documentation: update pt-BR
The current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language
definition is not widely distributed yet (it just hit the development
tree). Need to revert these headings (or change the length of the section
underlines to match the length of translated names).
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
I am not happy with this one yet. I am contemplating to introduce a new
syntax "%[magic(param)<anything>%]" to generalize expressions of this and
line wrapping features in an extensible way.
* js/log-rewrap (2008-11-10) 3 commits.
. Add "%w" to pretty formats, which rewraps the commit message
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
... and the first two from this series will be useful to implement an
example magic "wrap", e.g. "%[wrap(i,j,w)%s%+b%]".
* jg/log-format-body-indent (2009-09-19) 1 commit.
- git-log --format: Add %B tag with %B(x) option
I think we should redo this on top of the first two patches from
js/log-rewrap series; %B(x) is just a special case %B(x,x,0), no? If a
magic value 0 (or negative) given to wrap-width does not disable wrapping,
we probably should make it so.
* bg/rebase-reword (2009-10-07) 1 commit.
- Teach 'rebase -i' the command "reword"
Soon in 'next'
* js/diff-verbose-submodule (2009-10-04) 1 commit.
- Add the --submodule-summary option to the diff option family
Dscho sounded like he has some corrections after list comments, but I did
not pick up his interdiff in the middle.
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* jc/fix-tree-walk (2009-09-14) 10 commits.
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- Aggressive three-way merge: fix D/F case
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
- unpack_callback(): use unpack_failed() consistently
- unpack-trees: typofix
- diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
This includes the fix to aggressive mode of three-way merge used by the
resolve strategy. I think the series is Ok for 'next'.
* jp/fetch-tag-match (2009-09-17) 1 commit.
- fetch: Speed up fetch by rewriting find_non_local_tags
I just queued this without reading nor thinking about it very much. I
personally liked my version that had far smaller number of lines changed
(which means I can be fairly certain that it did not introduce any
regression), but perhaps the majorly rewritten logic this patch gives us
may be easier to follow and maintain.
* jc/maint-blank-at-eof (2009-09-15) 0 commits.
(this branch uses jc/maint-1.6.0-blank-at-eof.)
The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'
Soon in 'next'
* db/vcs-helper-rest (2009-09-03) 6 commits.
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged in 1.6.5.
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Add selftests verifying concatenation of multiple notes for the same commit
- Refactor notes code to concatenate multiple notes annotating the same object
- Add selftests verifying that we can parse notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- Teach notes code to free its internal data structures on request
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
Rerolled and queued.
* jn/gitweb-show-size (2009-09-07) 1 commit.
- gitweb: Add 'show-sizes' feature to show blob sizes in tree view
Soon in 'next'
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-10-11 at 7f34fb3)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* cc/reset-merge (2009-09-16) 4 commits.
. reset: add test cases for "--merge-safe" option
. reset: add option "--merge-safe" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
* cc/sequencer-rebase-i (2009-08-28) 15 commits.
. rebase -i: use "git sequencer--helper --cherry-pick"
. sequencer: add "--cherry-pick" option to "git sequencer--helper"
. sequencer: add "do_commit()" and related functions working on "next_commit"
. pick: libify "pick_help_msg()"
. revert: libify cherry-pick and revert functionnality
. rebase -i: use "git sequencer--helper --fast-forward"
. sequencer: let "git sequencer--helper" callers set "allow_dirty"
. sequencer: add "--fast-forward" option to "git sequencer--helper"
. sequencer: add "do_fast_forward()" to perform a fast forward
. rebase -i: use "git sequencer--helper --reset-hard"
. sequencer: add "--reset-hard" option to "git sequencer--helper"
. sequencer: add "reset_almost_hard()" and related functions
. rebase -i: use "git sequencer--helper --make-patch"
. sequencer: add "make_patch" function to save a patch
. sequencer: add "builtin-sequencer--helper.c"
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
. Prepare 'traverse_trees()' for D/F conflict lookahead
^ permalink raw reply
* Re: git log --graph
From: Dilip M @ 2009-10-12 3:01 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0910111135v4f3c75a7v6657f5dcfacf13ac@mail.gmail.com>
On Mon, Oct 12, 2009 at 12:05 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
>> I am trying git log --graph. (has commits in two branches...). But
>> always see one line :(
>
> It'll show you the history of one branch at a time online, you won't
> get the demo-ed multiple lines unless the branch you're looking at
> contains merges.
Understood. it shows only when I have merged conflicts!
In case, it is a fast forward merge. It doesn't show. Which is good :)
Thanks to all.
-
Dilip
^ permalink raw reply
* [PATCH] Aggressive three-way merge: fix D/F case
From: Junio C Hamano @ 2009-10-12 2:53 UTC (permalink / raw)
To: git
When the ancestor used to have a blob "P", your tree removed it, and the
tree you are merging with also removed it, the agressive three-way cleanly
merges to remove that blob. If the other tree added a new blob "P/Q"
while removing "P", it should also merge cleanly to remove "P" and create
"P/Q" (since neither the ancestor nor your tree could have had it, so it
is a typical "created in one").
The "aggressive" rule is not new anymore. Reword the stale comment.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This fixes one problem in the 3-way merge with corrected tree/index
entry order the jc/fix-tree-walk topic exposes.
t/t6035-merge-dir-to-symlink.sh | 2 +-
unpack-trees.c | 13 ++++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/t6035-merge-dir-to-symlink.sh b/t/t6035-merge-dir-to-symlink.sh
index b9a280e..d1b2287 100755
--- a/t/t6035-merge-dir-to-symlink.sh
+++ b/t/t6035-merge-dir-to-symlink.sh
@@ -74,7 +74,7 @@ test_expect_success 'setup a merge where dir a/b-2 changed to symlink' '
git tag test2
'
-test_expect_failure 'merge should not have conflicts (resolve)' '
+test_expect_success 'merge should not have conflicts (resolve)' '
git reset --hard &&
git checkout baseline^0 &&
git merge -s resolve test2 &&
diff --git a/unpack-trees.c b/unpack-trees.c
index c424bab..ec12341 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -767,7 +767,8 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
remote = NULL;
}
- /* First, if there's a #16 situation, note that to prevent #13
+ /*
+ * First, if there's a #16 situation, note that to prevent #13
* and #14.
*/
if (!same(remote, head)) {
@@ -781,7 +782,8 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
}
}
- /* We start with cases where the index is allowed to match
+ /*
+ * We start with cases where the index is allowed to match
* something other than the head: #14(ALT) and #2ALT, where it
* is permitted to match the result instead.
*/
@@ -811,12 +813,13 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
if (!head && !remote && any_anc_missing)
return 0;
- /* Under the new "aggressive" rule, we resolve mostly trivial
+ /*
+ * Under the "aggressive" rule, we resolve mostly trivial
* cases that we historically had git-merge-one-file resolve.
*/
if (o->aggressive) {
- int head_deleted = !head && !df_conflict_head;
- int remote_deleted = !remote && !df_conflict_remote;
+ int head_deleted = !head;
+ int remote_deleted = !remote;
struct cache_entry *ce = NULL;
if (index)
--
1.6.5.59.g7e3f2
^ permalink raw reply related
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-12 2:46 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091012014007.GA7674@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So now I am doubly confused. Did this feature exist, and was broken, and
> you actually fixed it in 63d285c, creating what looked like a regression
> but was actually intentional?
I do not think it was an intentional change. I _think_ the comment at the
beginning of show_files() tells us quite a bit---we don't do read-dir when
showing the indexed files, and I suspect that we used to rely on the fact
that not doing the read-dir made exclusion mechanism a no-op. After the
lazy .gitignore reading, I suspect that excluded() call started to
initialize the exclude mechanism lazily, and that is how the bug was
introduced, isn't it?
Regarding your patch, the loops deal with paths that are already in the
index, so removing the conditional skip looks like a sane thing to do.
^ permalink raw reply
* Re: [PATCH] disallow refs containing successive slashes
From: Nanako Shiraishi @ 2009-10-12 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vbpkdwyo2.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> Yes, one solution could be to fix every application handling branch, tag
>> or repo names to mimic the namechange done in the bowels of git. But i
>> think it is not worth the hassle.
> Besides, by rejecting what we used to accept you are breaking people's
> expectations. So I am moderately negative, unless you can say your "every
> application" is literally _tons_.
Isn't 1.7.0 a good release to break such people's expectations?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-12 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7vpr8tr2pe.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 03:22:05PM -0700, Junio C Hamano wrote:
> > I don't know if it is worth fixing now or not. It does seem a bit
> > inconsistent to me (since everything else is very clear that .gitignore
> > is only about untracked files), but nobody seems to have been
> > complaining for the last two years (and they may have, in fact, been
> > coding to the new behavior).
>
> This is one of those moments when I feel very blessed to have competent
> and diligent people around me ;-)
Well, I have to do _something_ to make up for all the brown paper bag
bugs. ;)
> I think you are right; that we shouldn't filter the output with gitignore
> entries when showing what is _in_ the index.
So being the diligent and competent soul that I am, I started to prepare
a patch for this, which is included below. But the plot thickens.
I bisected the change of behavior to 63d285c, as I mentioned. But when I
found the code that needed to be tweaked, it actually git-blames to a
much earlier date in "git show-files", which later became ls-files. See
9ff768e.
So now I am doubly confused. Did this feature exist, and was broken, and
you actually fixed it in 63d285c, creating what looked like a regression
but was actually intentional?
And more importantly, what do you want to do with it now?
---
builtin-ls-files.c | 8 --------
t/t3003-ls-files-exclude.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 8 deletions(-)
create mode 100755 t/t3003-ls-files-exclude.sh
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 2c95ca6..c5c0407 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -170,10 +170,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
if (show_cached | show_stage) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (show_unmerged && !ce_stage(ce))
continue;
if (ce->ce_flags & CE_UPDATE)
@@ -186,10 +182,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
struct cache_entry *ce = active_cache[i];
struct stat st;
int err;
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (ce->ce_flags & CE_UPDATE)
continue;
err = lstat(ce->name, &st);
diff --git a/t/t3003-ls-files-exclude.sh b/t/t3003-ls-files-exclude.sh
new file mode 100755
index 0000000..fc1e379
--- /dev/null
+++ b/t/t3003-ls-files-exclude.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='ls-files --exclude does not affect index files'
+. ./test-lib.sh
+
+test_expect_success 'create repo with file' '
+ echo content >file &&
+ git add file &&
+ git commit -m file &&
+ echo modification >file
+'
+
+check_output() {
+test_expect_success "ls-files output contains file ($1)" "
+ echo '$2' >expect &&
+ git ls-files --exclude-standard --$1 >output &&
+ test_cmp expect output
+"
+}
+
+check_all_output() {
+ check_output 'cached' 'file'
+ check_output 'modified' 'file'
+}
+
+check_all_output
+test_expect_success 'add file to gitignore' '
+ echo file >.gitignore
+'
+check_all_output
+
+test_done
--
1.6.5.rc3.240.g77692
^ permalink raw reply related
* Re: [PATCH] disallow refs containing successive slashes
From: Jonathan Nieder @ 2009-10-12 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vbpkdwyo2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> When the users make typoes (e.g. /foo//bar) you can accept the only sane
> correction (e.g. foo/bar) instead of rejecting, since the only thing the
> user can do after getting such a rejection is to correct it to that
> corrected name (e.g. foo/bar) himself and re-issue the command anyway.
> You can push the "hassle" down to the user, or you can fix the tool to
> remove the hassle from the user.
Yes, making check-ref-format stricter without changing its users to
massage their input would be a regression.
The problem Jens described is a git-gui bug. In lib/branch_delete.tcl,
line 57, the list of deletable branches is populated as follows:
foreach h [load_all_heads] {
if {$h ne $current_branch} {
$w_heads insert end $h
}
}
Since slashes coalesce, a user-supplied new branch name is not canonical
and checking "$h eq $current_branch" does not actually check if they are
the same branch. git-gui should be using the branch name as output by
"git check-ref-format --branch" after the branch is created.
But what about other scripts that assume each branch has only one
possible name? Maybe they could be forced to fix up the name early on
by making check-ref-format reject names with "//" in them and providing
a "git check-ref-format --print" to help.
Upside: scripts would complain loudly instead of failing subtly on input
with extra slashes if they forget to use "git check-ref-format --print"
when appropriate. Downside: users, including the 22 callers of
check_ref_format() in git, would have to be checked and probably changed
to avoid regressions.
Never having made that typo, I find it hard to consider such a change
worth the trouble, but it sounds doable.
Regards,
Jonathan
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Johannes Schindelin @ 2009-10-12 0:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Eugene Sajine, git
In-Reply-To: <200910102045.13374.jnareb@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 806 bytes --]
Hi,
On Sat, 10 Oct 2009, Jakub Narebski wrote:
> On Sat, 10 Oct 2009, Eugene Sajine wrote:
>
> > [something, but forgot to say whom he quoted:]
>
> > > %
> > > "To be fair, there are uses for XML. On Halloween, for example."
> > >
> > > - Johannes Schindelin, on git@vger.kernel.org
> > > %
> >
> > yeah, to show kids xml print outs as an answer to "trick or treat!".
> > Can save on candies;)
>
> Err, I think Dscho meant here that XML is so *scary*... Isn't it?
XML can be scary. Somebody on usenet once said something like: "XML is
just a skeleton; if you see a skeleton walking around, wouldn't you
be scared?"
What is really scary, though, is how many people really believe that just
using XML will magically solve all problems of this world. They really
believe that.
Ciao,
Dscho
^ permalink raw reply
* Script to convert git patches to Hg format
From: Mark Lodato @ 2009-10-11 22:56 UTC (permalink / raw)
To: git list
To make it easier to submit patches to a project using Hg, I wrote a
small script to convert the output of `git format-patch' to something
suitable for `hg import'. The latest version is available at:
http://github.com/MarkLodato/patch-converter
While `hg import' *can* read a git patch, it does not interpret the
date, and it includes the diffstat in the commit log. This script
fixes those problems.
The script worked well enough for me, but bugs may exist. If you have
ideas for improvement, patches are welcome :)
--
Mark
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-11 22:22 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091011191440.GA2532@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Oct 11, 2009 at 11:52:10AM -0700, Junio C Hamano wrote:
>
>> Thanks.
>>
>> The change looks innocent enough and I do not expect to see any unexpected
>> regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
>> queue this fix and aim for 1.6.5.1.
>
> I think this patch is good to apply, as there is no conceivable reason
> to even look at excludes when listing modified files.
>
> But this triggered my spider sense; shouldn't --exclude-standard simply
> be a no-op for ls-files when we are not listing untracked files? And
> bisecting, it seems that it is a very old regression caused by 63d285c
> (per-directory-exclude: lazily read .gitignore files, 2007-11-29).
>
> I don't know if it is worth fixing now or not. It does seem a bit
> inconsistent to me (since everything else is very clear that .gitignore
> is only about untracked files), but nobody seems to have been
> complaining for the last two years (and they may have, in fact, been
> coding to the new behavior).
This is one of those moments when I feel very blessed to have competent
and diligent people around me ;-)
I think you are right; that we shouldn't filter the output with gitignore
entries when showing what is _in_ the index.
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Jonathan Nieder @ 2009-10-11 22:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> So that users get to know how to configure git from the get-to with good
> practical example (color.ui = auto) that most people would probably like
> anyway.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Good idea. Some comments:
> +Git's configuration is distributed among different locations--this manual will
> +only to deal with 'global' (for the user) and 'repository' variables, where
> +'repository' variables take precedence over 'global' ones.
What are these different locations you speak of? If git’s configuration
is complicated to deal with, maybe that is something that could be
improved.
This is very early in the manual, where every word counts. I am not
very good at wording and do not have any better suggestions, but would
it be possible to more efficiently convey this:
Git reads its per-user configuration from ~/.gitignore.
That file can also be manipulated with the "git config"
command, which can be convenient in scripts or when using
operating systems like Windows where it is not clear where
the home directory is.
For example, if your terminal supports it, you can tell Git
to use color in the output for commands such as "git diff"
with "git config --global color.ui auto".
For more information and a list of possible settings, see
git-config(1).
By the way, this reminds me that I am not sure git-config(1) conveys the
list of configuration items in an ideal way. It can be easy to dismiss
that page as plumbing documentation when seeing it for the first time.
Should we ship a sample .gitconfig with all items included and comments
describing them, or a separate gitconfig(5)? Either would be easy to
generate from config.txt.
Thoughts?
Jonathan
^ 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