* Re: [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-02 19:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e378fs$lpc$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> I renamed "git grip" to "git grep" and "git diffn" to "git diff"
>> both in "next" branch to avoid confusion. Thanks Andreas,
>> Jakub, and others for input.
>
> So, is there a way to use old, script version of those commands?
I'd say that is probably not the real question you wanted to
ask, but let's pretend it is for a moment.
The "master" branch has not been updated to remove the script
one, so you can keep running "master" one (or 1.3.X series). Or
you can fork your own private edition by tweaking git.c (prevent
it from running the builtin one) and Makefile (resurrect the
script based one and prevent it from installing git-grep
hardlinked with git itself). One thing that I will not do in
the long run, however, is to keep the script based one and have
builtin one. It is like carrying all the earlier slightly
incompatible versions as git-grep-1.1.sh, git-grep-1.2.sh, and
git-grep-1.3.sh in the source for fear of backward compatibility
problems -- it is crazy.
So the real question, is what are still missing in the built-in
implementation. What will we lose if we remove the script based
one and replace it with today's built-in one, if we are ready to
do it today, and if not what we are going to do about them. My
answer to the latter questions are "not yet" (obviously, that is
why "master" does not have it yet), and "will support what are
reasonable".
Here are main differences that I am aware of:
- The shell-script one, if you use GNU grep, accepts more
options to grep than what the current built-in one supports.
Notable ones that are missing: fixed strings (-F), patterns
from file (-f), count matches (-c), omit filenames (-h),
skipping binary files (-I, -U), files without match (-L),
pcre (-P), silent (-q), word expression (-w), NUL (-z). They
should be easy to add if somebody cares enough, and I plan to
do a few myself before pushing it out to "master".
- The shell-script one can be coaxed to use different "grep"
implementation from the standard one with an appropriate PATH
settings.
At the lowest level, buitlin-grep.c::grep_buffer() function is
called with the set of parsed options, the "filename" used for
reporting, and the text to grepped in-core. The shell-script
one always worked on working tree files, but the built-in one
can work on working tree files and also alternatively on files
from other versions. Regardless of where the file comes from,
this function is called to look for the pattern the user is
looking for.
You can do two things.
One is to add support for commonly used but still missing
features to built-in one. For this, you would need to extend
"struct grep_opt" to hold new option parameters (e.g. if you
want to do "-f", you would need to hold all patterns you obtain
from the named file so grep_buffer() can use them -- currently
it supports only one pattern), and teach grep_buffer() how to do
the new feature.
Another thing you can do is to detect GIT_EXTERNAL_GREP (in the
same spirit as GIT_EXTERNAL_DIFF) environment variable at the
front of grep_buffer(), and when it is set, spawn the named
external program with the original parameters the user supplied,
probably stashed away in "struct grep_opt" when cmd_grep() does
its parameter parsing, and feed it the contents of the buffer.
^ permalink raw reply
* Re: Features ask for git-send-email
From: Jakub Narebski @ 2006-05-02 15:35 UTC (permalink / raw)
To: git
In-Reply-To: <1146579255.17934.8.camel@pmac.infradead.org>
David Woodhouse wrote:
> On Tue, 2006-05-02 at 14:53 +0200, Jakub Narebski wrote:
>> Doesn't
>> Content-Type: text/plain; charset=$charset
>> header need also
>> MIME-Version: 1.0
>
> Maybe. The use of Content-Type: actually predates RFC2045, and if we
> include a MIME-Version header then we should make 100% sure that we also
> conform to the rest of RFC2045, which I hadn't actually looked at. In
> particular, we should take care of Content-Transfer-Encoding.
>
> I'd prefer to leave MIME-Version out for now, I think.
If I remember correctly _some_ mail applications or news (Usenet) agents
did not respect Content-Type without MIME-Version, I think according to
standard. Perhaps that have changed.
As to the other MIME header:
Content-Transfer-Encoding: 8bit
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Bug in git log
From: Linus Torvalds @ 2006-05-02 15:26 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Junio C Hamano, git
In-Reply-To: <20060502134158.GC4592@spinlock.ch>
On Tue, 2 May 2006, Matthias Kestenholz wrote:
>
> The "double dash" problem is not a big deal since it only happens
> with the deprecated shellscript-version of whatchanged.
Simple enough to fix. Appended.
The problem was that "git-rev-parse --no-flags --no-revs" will show _just_
the filenames from the argument list. That means that it will also remove
the "--" from the original. That's all well and proper, but
git-whatchanged had a bug, and it wouldn't separate the filename arguments
from the flags by adding its own "--".
That bug didn't matter back when we didn't check the parsing all that
carefully. It does now.
> Does anyone get some output with the following command? That was the
> bug I tried to report (sorry for my bad/convoluted english)
>
> $ git log -- unresolve.c
Now, this returns empty, and it actually does that for a reason.
Along the main path, "unresolve.c" has never existed. The modern
"git-whatchanged" (and "git log") is a bit different from the old
big-whatchanged.
The old git-whatchanged would go through _every_ commit, because it
literally did
git-rev-list | git-diff-tree --stdin -- <paths>
and thus the revision list was generated without _any_ regard for the
paths - and every single commit shows up, whether it is relevant or not.
The new revision is based on the revision parsing thing, and the semantics
are a bit different: it semantically does the equivalent of
git-rev-list <paths> | git-diff-tree --stdin -- <paths>
which limits the revision list too on the paths.
And yes, "git log" does the same.
See the discussion a few weeks ago about "path limiting broken", and my
patch that suggested a "--no-prune-merges" flag:
http://www.gelato.unsw.edu.au/archives/git/0604/19180.html
which gives more of an explanation.
Linus
--
diff --git a/git-whatchanged.sh b/git-whatchanged.sh
index 1fb9feb..bb73cff 100755
--- a/git-whatchanged.sh
+++ b/git-whatchanged.sh
@@ -24,5 +24,5 @@ rev_list_args=$(git-rev-parse --sq --def
diff_tree_args=$(git-rev-parse --sq --no-revs --no-flags "$@") &&
eval "git-rev-list $count $rev_list_args" |
-eval "git-diff-tree --stdin --pretty -r $diff_tree_flags $diff_tree_args" |
+eval "git-diff-tree --stdin --pretty -r $diff_tree_flags -- $diff_tree_args" |
LESS="$LESS -S" ${PAGER:-less}
^ permalink raw reply related
* [PATCH] repo-config: trim white-space before comment
From: Johannes Schindelin @ 2006-05-02 14:58 UTC (permalink / raw)
To: git, junkio
Earlier, calling
git-repo-config core.hello
on a .git/config like this:
[core]
hello = world ; a comment
would yield "world " (i.e. with a trailing space).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I wrote:
> Strange thing I realized: A value is white-space-trimmed at the end
> only if the line does not end with a comment. This fact is accounted
> for in the new tests.
It actually was a buglet in parse_value(), so it was not only
repo-config which was affected.
Obviously, this patch comes on top of the --get-regexp patch, but
feel free to apply without that.
config.c | 12 ++++++------
t/t1300-repo-config.sh | 8 ++++++--
2 files changed, 12 insertions(+), 8 deletions(-)
bb874fdd7a55b7adc229ee9eb1b59e5852b41594
diff --git a/config.c b/config.c
index 4e1f0c2..253c48a 100644
--- a/config.c
+++ b/config.c
@@ -60,6 +60,12 @@ static char *parse_value(void)
space = 1;
continue;
}
+ if (!quote) {
+ if (c == ';' || c == '#') {
+ comment = 1;
+ continue;
+ }
+ }
if (space) {
if (len)
value[len++] = ' ';
@@ -93,12 +99,6 @@ static char *parse_value(void)
quote = 1-quote;
continue;
}
- if (!quote) {
- if (c == ';' || c == '#') {
- comment = 1;
- continue;
- }
- }
value[len++] = c;
}
}
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 52e8e33..e3ab661 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -247,8 +247,12 @@ EOF
test_expect_success 'hierarchical section value' 'cmp .git/config expect'
+value="$(git-repo-config beta.noindent)"
+
+test_expect_success 'trim before comment' "test \"$value\" = sillyValue"
+
cat > expect << EOF
-beta.noindent=sillyValue
+beta.noindent=sillyValue
nextsection.nonewline=wow2 for me
123456.a123=987
1.2.3.alpha=beta
@@ -258,7 +262,7 @@ test_expect_success 'working --list' \
'git-repo-config --list > output && cmp output expect'
cat > expect << EOF
-beta.noindent sillyValue
+beta.noindent sillyValue
nextsection.nonewline wow2 for me
EOF
--
1.3.1.g259f
^ permalink raw reply related
* Re: Features ask for git-send-email
From: David Woodhouse @ 2006-05-02 14:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e37km0$vav$1@sea.gmane.org>
On Tue, 2006-05-02 at 14:53 +0200, Jakub Narebski wrote:
> Doesn't
> Content-Type: text/plain; charset=$charset
> header need also
> MIME-Version: 1.0
Maybe. The use of Content-Type: actually predates RFC2045, and if we
include a MIME-Version header then we should make 100% sure that we also
conform to the rest of RFC2045, which I hadn't actually looked at. In
particular, we should take care of Content-Transfer-Encoding.
I'd prefer to leave MIME-Version out for now, I think.
--
dwmw2
^ permalink raw reply
* Re: Bug in git log
From: Matthias Kestenholz @ 2006-05-02 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virooomve.fsf@assigned-by-dhcp.cox.net>
* Junio C Hamano (junkio@cox.net) wrote:
> [...]
> We used to have a build problem where we forgot to remove
> libgit.a and an old object from the archive was used by
> mistake. Could you try rm -f libgit.a and rebuild your git to
> see if it helps?
>
Ok I did that. I also removed all files which were installed by
'make install' and did a complete rebuild and install of the current
master branch. My git version is now 1.3.1.g7464
The "double dash" problem is not a big deal since it only happens
with the deprecated shellscript-version of whatchanged.
Does anyone get some output with the following command? That was the
bug I tried to report (sorry for my bad/convoluted english)
$ git log -- unresolve.c
--
:wq
^ permalink raw reply
* Re: Features ask for git-send-email
From: Jakub Narebski @ 2006-05-02 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <1146573417.14059.21.camel@pmac.infradead.org>
David Woodhouse wrote:
> On Sat, 2006-04-29 at 15:30 +0200, Bertrand Jacquin wrote:
>> Could it be possible to add a features in git-send-email.perl to
>> accept a differrent charset as iso-8859-1 ? I would like to send
>> fr_FR.utf8 mail as I use git to manager a latex files tree which are
>> written in utf8.
>>
>> Any objection ?
>
> Seems reasonable. I think we just forgot to include the Content-Type:
> header. This fixes it...
Doesn't
Content-Type: text/plain; charset=$charset
header need also
MIME-Version: 1.0
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Johannes Schindelin @ 2006-05-02 12:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bfsol9j.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This is what the patch series is all about.
> >
> > If there is no interest in a feature like this, let's just forget
> > about the whole "remote info in config" thing.
>
> Well, I took the liberty of adjusting the first one in the
> series and tonight's "pu" has that one and the second one.
> I haven't touched the third one yet, though.
I don't think it is worth introducing yet another way to specify
short-cuts for remote information, if there is not at least one problem
which can get solved easier with it than with the other two ways.
> About the second one, I think it probably is a good idea to
> rename the "refspec used for fetch" as Sean suggested earlier.
Okay.
> I do not like that hidden environment variable that sits in the
> command I use everyday, waiting to be triggered to update my
> .config file, possibly by my PEBCAK mistake when I did not want
> it to do so.
I will refactor it.
> I am not quite sure what this bit is about in the second one:
>
> sed -n \
> -e "s/^URL: /remote.$name.url . /p" \
> -e "s/^Pull: /remote.$name.pull ^$ /p" \
> -e "s/^Push: /remote.$name.push ^$ /p" \
> < "$f"
That is obviously wrong. Will fix while refactoring.
> I think easy conversion tool is a good idea, but I would sleep
> better if it is outside of git-fetch/push chain and is available
> elsewhere, perhaps in contrib/ area.
Will do.
> On a slightly related topic, I think my aversion to your "push
> remotes into config" series the last time was primarily because
> I do not trust repo-config. Reading an already built config
> seems to work OK and I do not worry too much, but I am still
> wary of letting it write. Typing "git repo-config" in a freshly
> initialized empty repository seems to segfault, which does not
> help my confidence level either.
I fixed this error (see separate patch). This was reintroduced by
carelessly checking argv[1] for "--list" and "-l", even if argc < 2. I am
sorry that I did not review that patch.
I tried to make really sure that repo-config works as expected by
introducing quite a few test cases into t1300, but evidently I forgot to
check for things that do not usually break, like calling without
arguments. This is fixed with the patch I just sent out.
This patch also introduces the "--get-regexp" flag to repo-config, which
makes up for the lacking shell wildcards (you can ask questions like:
which keys in the config end in "coatl"?).
As for the trust in repo-config writing the config: it is all done by
calling git_config_set() or git_config_set_multivar(), which you use
yourself to set core.repositoryformatversion, among other values.
Ciao,
Dscho
^ permalink raw reply
* Re: Features ask for git-send-email
From: David Woodhouse @ 2006-05-02 12:36 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Git Mailing List
In-Reply-To: <4fb292fa0604290630r19edd7ejf88642e33b350d1d@mail.gmail.com>
On Sat, 2006-04-29 at 15:30 +0200, Bertrand Jacquin wrote:
> Could it be possible to add a features in git-send-email.perl to
> accept a differrent charset as iso-8859-1 ? I would like to send
> fr_FR.utf8 mail as I use git to manager a latex files tree which are
> written in utf8.
>
> Any objection ?
Seems reasonable. I think we just forgot to include the Content-Type:
header. This fixes it...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/git-send-email.perl b/git-send-email.perl
index ecfa347..1df75f5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -37,7 +37,7 @@ # Constants (essentially)
my $compose_filename = ".msg.$$";
# Variables we fill in automatically, or via prompting:
-my (@to,@cc,@initial_cc,$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
+my (@to,@cc,@initial_cc,$initial_reply_to,$initial_subject,@files,$from,$compose,$time,$charset);
# Behavior modification variables
my ($chain_reply_to, $smtp_server, $quiet, $suppress_from, $no_signed_off_cc) = (1, "localhost", 0, 0, 0);
@@ -58,6 +58,7 @@ my $rc = GetOptions("from=s" => \$from,
"chain-reply-to!" => \$chain_reply_to,
"smtp-server=s" => \$smtp_server,
"compose" => \$compose,
+ "charset=s" => \$charset,
"quiet" => \$quiet,
"suppress-from" => \$suppress_from,
"no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
@@ -135,6 +136,10 @@ if (!defined $smtp_server) {
$smtp_server = "localhost";
}
+if (!defined $charset) {
+ $charset = "UTF-8";
+}
+
if ($compose) {
# Note that this does not need to be secure, but we will make a small
# effort to have it be unique
@@ -214,6 +219,9 @@ Options:
--cc Specify an initial "Cc:" list for the entire series
of emails.
+ --charset Specify a character set, if legacy character sets are
+ used in change logs instead of UTF-8.
+
--compose Use \$EDITOR to edit an introductory message for the
patch series.
@@ -299,6 +307,7 @@ Subject: $subject
Reply-To: $from
Date: $date
Message-Id: $message_id
+Content-Type: text/plain; charset=$charset
X-Mailer: git-send-email @@GIT_VERSION@@
";
$header .= "In-Reply-To: $reply_to\n" if $reply_to;
--
dwmw2
^ permalink raw reply related
* [PATCH] Give the user a hint for how to continue in the case that git-am fails because it requires user intervention
From: Robert Shearman @ 2006-05-02 12:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
Give the user a hint for how to continue in the case that git-am fails
because it requires user intervention.
Signed-off-by: Robert Shearman <rob@codeweaves.com>
---
When git-am fails because it needs user intervention, the user may not
know what they need to do to continue with applying the mailbox. This
patch gives them a hint to use git-am (as they may have started the
operation from another tool, such as git-rebase). As the threeway,
interactive and dotest options are not persisted, the user may also
forget to include them (or not realise at all that they should be
included), so we should also tell the user to include these options if
they were orignally specified.
git-am.sh | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
[-- Attachment #2: ead48bae7157a30589791165b7b71208b68cf229.diff --]
[-- Type: text/x-patch, Size: 1410 bytes --]
ead48bae7157a30589791165b7b71208b68cf229
diff --git a/git-am.sh b/git-am.sh
index 872145b..507ae4d 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -14,6 +14,26 @@ stop_here () {
exit 1
}
+stop_here_user_resolve () {
+ cmdline=$(basename $0)
+ if test '' != "$interactive"
+ then
+ cmdline="$cmdline -i"
+ fi
+ if test '' != "$threeway"
+ then
+ cmdline="$cmdline -3"
+ fi
+ if test '.dotest' != "$dotest"
+ then
+ cmdline="$cmdline -d=$dotest"
+ fi
+ echo "When you have resolved this problem run \"$cmdline --resolved\"."
+ echo "If you would prefer to skip this patch, instead run \"$cmdline --skip\"."
+
+ stop_here $1
+}
+
go_next () {
rm -f "$dotest/$msgnum" "$dotest/msg" "$dotest/msg-clean" \
"$dotest/patch" "$dotest/info"
@@ -374,14 +394,14 @@ do
if test '' = "$changed"
then
echo "No changes - did you forget update-index?"
- stop_here $this
+ stop_here_user_resolve $this
fi
unmerged=$(git-ls-files -u)
if test -n "$unmerged"
then
echo "You still have unmerged paths in your index"
echo "did you forget update-index?"
- stop_here $this
+ stop_here_user_resolve $this
fi
apply_status=0
;;
@@ -407,7 +427,7 @@ do
if test $apply_status != 0
then
echo Patch failed at $msgnum.
- stop_here $this
+ stop_here_user_resolve $this
fi
if test -x "$GIT_DIR"/hooks/pre-applypatch
^ permalink raw reply related
* [PATCH] repo-config: support --get-regexp and fix crash
From: Johannes Schindelin @ 2006-05-02 12:22 UTC (permalink / raw)
To: git, junkio
With --get-regexp, output all key/value pairs where the key matches a
regexp. Example:
git-repo-config --get-regexp remote.*.url
will output something like
remote.junio.url git://git.kernel.org/pub/scm/git/git.git
remote.gitk.url git://git.kernel.org/pub/scm/gitk/gitk.git
This also fixes a crash when no arguments are given, which was introduced
with the "-l" and "--list" handling.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Junio made me aware of a crash, a fix for which was too easy to
merit a separate patch.
Strange thing I realized: A value is white-space-trimmed at the end
only if the line does not end with a comment. This fact is accounted
for in the new tests.
Documentation/git-repo-config.txt | 5 +++-
repo-config.c | 45 +++++++++++++++++++++++++++++--------
t/t1300-repo-config.sh | 23 +++++++++++++++++++
3 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 566cfa1..ddcf523 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -49,7 +49,7 @@ OPTIONS
--replace-all::
Default behaviour is to replace at most one line. This replaces
- all lines matching the key (and optionally the value_regex)
+ all lines matching the key (and optionally the value_regex).
--get::
Get the value for a given key (optionally filtered by a regex
@@ -59,6 +59,9 @@ OPTIONS
Like get, but does not fail if the number of values for the key
is not exactly one.
+--get-regexp::
+ Like --get-all, but interprets the name as a regular expression.
+
--unset::
Remove the line matching the key from .git/config.
diff --git a/repo-config.c b/repo-config.c
index fa8aba7..722153c 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -6,7 +6,10 @@ static const char git_config_set_usage[]
static char* key = NULL;
static char* value = NULL;
+static regex_t* key_regexp = NULL;
static regex_t* regexp = NULL;
+static int show_keys = 0;
+static int use_key_regexp = 0;
static int do_all = 0;
static int do_not_match = 0;
static int seen = 0;
@@ -26,16 +29,18 @@ static int show_config(const char* key_,
if (value_ == NULL)
value_ = "";
- if (!strcmp(key_, key) &&
+ if ((use_key_regexp || !strcmp(key_, key)) &&
+ (!use_key_regexp ||
+ !regexec(key_regexp, key_, 0, NULL, 0)) &&
(regexp == NULL ||
(do_not_match ^
!regexec(regexp, value_, 0, NULL, 0)))) {
- if (do_all) {
- printf("%s\n", value_);
- return 0;
- }
+ if (show_keys)
+ printf("%s ", key_);
if (seen > 0) {
- fprintf(stderr, "More than one value: %s\n", value);
+ if (!do_all)
+ fprintf(stderr, "More than one value: %s\n",
+ value);
free(value);
}
@@ -50,6 +55,8 @@ static int show_config(const char* key_,
value = strdup(value_);
}
seen++;
+ if (do_all)
+ printf("%s\n", value);
}
return 0;
}
@@ -63,6 +70,14 @@ static int get_value(const char* key_, c
key[i] = tolower(key_[i]);
key[i] = 0;
+ if (use_key_regexp) {
+ key_regexp = (regex_t*)malloc(sizeof(regex_t));
+ if (regcomp(key_regexp, key, REG_EXTENDED)) {
+ fprintf(stderr, "Invalid key pattern: %s\n", regex_);
+ return -1;
+ }
+ }
+
if (regex_) {
if (regex_[0] == '!') {
do_not_match = 1;
@@ -78,7 +93,8 @@ static int get_value(const char* key_, c
git_config(show_config);
if (value) {
- printf("%s\n", value);
+ if (!do_all)
+ printf("%s\n", value);
free(value);
}
free(key);
@@ -102,15 +118,14 @@ int main(int argc, const char **argv)
type = T_INT;
else if (!strcmp(argv[1], "--bool"))
type = T_BOOL;
+ else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
+ return git_config(show_all_config);
else
break;
argc--;
argv++;
}
- if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
- return git_config(show_all_config);
-
switch (argc) {
case 2:
return get_value(argv[1], NULL);
@@ -124,6 +139,11 @@ int main(int argc, const char **argv)
else if (!strcmp(argv[1], "--get-all")) {
do_all = 1;
return get_value(argv[2], NULL);
+ } else if (!strcmp(argv[1], "--get-regexp")) {
+ show_keys = 1;
+ use_key_regexp = 1;
+ do_all = 1;
+ return get_value(argv[2], NULL);
} else
return git_config_set(argv[1], argv[2]);
@@ -137,6 +157,11 @@ int main(int argc, const char **argv)
else if (!strcmp(argv[1], "--get-all")) {
do_all = 1;
return get_value(argv[2], argv[3]);
+ } else if (!strcmp(argv[1], "--get-regexp")) {
+ show_keys = 1;
+ use_key_regexp = 1;
+ do_all = 1;
+ return get_value(argv[2], argv[3]);
} else if (!strcmp(argv[1], "--replace-all"))
return git_config_set_multivar(argv[2], argv[3], NULL, 1);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index ab4dd5c..52e8e33 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -247,6 +247,24 @@ EOF
test_expect_success 'hierarchical section value' 'cmp .git/config expect'
+cat > expect << EOF
+beta.noindent=sillyValue
+nextsection.nonewline=wow2 for me
+123456.a123=987
+1.2.3.alpha=beta
+EOF
+
+test_expect_success 'working --list' \
+ 'git-repo-config --list > output && cmp output expect'
+
+cat > expect << EOF
+beta.noindent sillyValue
+nextsection.nonewline wow2 for me
+EOF
+
+test_expect_success '--get-regexp' \
+ 'git-repo-config --get-regexp in > output && cmp output expect'
+
cat > .git/config << EOF
[novalue]
variable
@@ -255,5 +273,10 @@ EOF
test_expect_success 'get variable with no value' \
'git-repo-config --get novalue.variable ^$'
+git-repo-config > output 2>&1
+
+test_expect_success 'no arguments, but no crash' \
+ "test $? = 129 && grep usage output"
+
test_done
^ permalink raw reply related
* Re: git-bisect broken in 1.2.4
From: Johannes Schindelin @ 2006-05-02 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Olaf Hering, git, Uwe Zeisberger
In-Reply-To: <7vpsiwopkv.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 May 2006, Junio C Hamano wrote:
> Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
>
> > You can rebuild git with USE_SYMLINK_HEAD if you really want the old
> > behaviour.
>
> That probably is a sane thing to do.
>
> We should introduce prefer_symlink_refs configuration to work
> with projects whose older version of build infrastructure
> depends on symlink refs.
>
> The patch is on top of post 1.3.1 git, but .c and .h part should
> apply more-or-less cleanly to older code base. You should
> be able to say:
>
> [core]
> prefersymlinkrefs = true
Why not just use the existing method:
[core]
onlyusesymrefs = false
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Andreas Ericsson @ 2006-05-02 9:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e378fs$lpc$1@sea.gmane.org>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>
>>Andreas Ericsson <ae@op5.se> writes:
>>
>>
>>>"git grip" work just fine for me, since it's only intended for testing
>>>and performance improvements so far. I also think it's clearer for
>>>end-users looking for a grep command if they're not faced with
>>>fgrep/egrep/ggrep/bgrep alongside plain "grep".
>>
>>I renamed "git grip" to "git grep" and "git diffn" to "git diff"
>>both in "next" branch to avoid confusion. Thanks Andreas,
>>Jakub, and others for input.
>
>
> So, is there a way to use old, script version of those commands?
>
Use "master" branch or "git-grep" syntax if you're trying "next" branch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Jakub Narebski @ 2006-05-02 9:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7xkn6kd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> "git grip" work just fine for me, since it's only intended for testing
>> and performance improvements so far. I also think it's clearer for
>> end-users looking for a grep command if they're not faced with
>> fgrep/egrep/ggrep/bgrep alongside plain "grep".
>
> I renamed "git grip" to "git grep" and "git diffn" to "git diff"
> both in "next" branch to avoid confusion. Thanks Andreas,
> Jakub, and others for input.
So, is there a way to use old, script version of those commands?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-02 9:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44571967.7080807@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> "git grip" work just fine for me, since it's only intended for testing
> and performance improvements so far. I also think it's clearer for
> end-users looking for a grep command if they're not faced with
> fgrep/egrep/ggrep/bgrep alongside plain "grep".
I renamed "git grip" to "git grep" and "git diffn" to "git diff"
both in "next" branch to avoid confusion. Thanks Andreas,
Jakub, and others for input.
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Junio C Hamano @ 2006-05-02 8:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This is what the patch series is all about.
>
> If there is no interest in a feature like this, let's just forget
> about the whole "remote info in config" thing.
Well, I took the liberty of adjusting the first one in the
series and tonight's "pu" has that one and the second one.
I haven't touched the third one yet, though.
About the second one, I think it probably is a good idea to
rename the "refspec used for fetch" as Sean suggested earlier.
I do not like that hidden environment variable that sits in the
command I use everyday, waiting to be triggered to update my
.config file, possibly by my PEBCAK mistake when I did not want
it to do so.
I am not quite sure what this bit is about in the second one:
sed -n \
-e "s/^URL: /remote.$name.url . /p" \
-e "s/^Pull: /remote.$name.pull ^$ /p" \
-e "s/^Push: /remote.$name.push ^$ /p" \
< "$f"
I am getting this out of the above:
remote.ko.url . xxx.kernel.org:/pub/scm/git/git.git/
remote.ko.pull ^$ master:refs/tags/ko-master
remote.ko.pull ^$ next:refs/tags/ko-next
remote.ko.pull ^$ +pu:refs/tags/ko-pu
remote.ko.pull ^$ maint:refs/tags/ko-maint
remote.ko.push ^$ heads/master
remote.ko.push ^$ heads/next
remote.ko.push ^$ +heads/pu
remote.ko.push ^$ heads/maint
but I suspect that is not what you intended...
I think easy conversion tool is a good idea, but I would sleep
better if it is outside of git-fetch/push chain and is available
elsewhere, perhaps in contrib/ area.
On a slightly related topic, I think my aversion to your "push
remotes into config" series the last time was primarily because
I do not trust repo-config. Reading an already built config
seems to work OK and I do not worry too much, but I am still
wary of letting it write. Typing "git repo-config" in a freshly
initialized empty repository seems to segfault, which does not
help my confidence level either.
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Jakub Narebski @ 2006-05-02 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <44571967.7080807@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> Yes, I understand, but I just don't like using 'grip'. And it would be
>> nice to have some convention for further not-ready-yet built-in
>> replacements for script versions of commands, for example adding letter
>> 'b' as 'built-in' at the beginning of command name: 'bgrep', 'bdiff'. Or
>> use postfix 'n' or '-ng' to denote transitionary not-ready-yet new
>> version of command: 'grepn', 'diffn' or 'grep-ng', 'diff-ng'.
>>
>
> Forcing the user to remember what's implemented as built-ins is not a
> good idea. It was for that exact reason the "git-<command>-script" were
> all renamed "git-<command>" once upon a time.
>
> "git grip" work just fine for me, since it's only intended for testing
> and performance improvements so far. I also think it's clearer for
> end-users looking for a grep command if they're not faced with
> fgrep/egrep/ggrep/bgrep alongside plain "grep".
Well, scratch 'bgrep' idea, even if I had no intend for 'bgrep' to be
persistent name; it was meant as transitionary name. Well, that doesn't
matter much because someone interested in testing new, not-ready-yet
versions of commands (I like 'grepn' idea) usually would follow git
development, and would know (or not) about new version of 'git grep' being
'git grip' (and not 'git grepn').
What about forcing using external grep, and the fact that grep is linked
with libpcre?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Andreas Ericsson @ 2006-05-02 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e34cb4$is1$1@sea.gmane.org>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> Jakub Narebski <jnareb@gmail.com> writes:
>
>
>>Wouldn't "git ggrep" (from git-aware grep) or "git bgrep" (from built-in
>>grep), similar to the egrep and fgrep from the grep package?
>
>
> Yes, I understand, but I just don't like using 'grip'. And it would be nice
> to have some convention for further not-ready-yet built-in replacements for
> script versions of commands, for example adding letter 'b' as 'built-in' at
> the beginning of command name: 'bgrep', 'bdiff'. Or use postfix 'n' or
> '-ng' to denote transitionary not-ready-yet new version of command:
> 'grepn', 'diffn' or 'grep-ng', 'diff-ng'.
>
Forcing the user to remember what's implemented as built-ins is not a
good idea. It was for that exact reason the "git-<command>-script" were
all renamed "git-<command>" once upon a time.
"git grip" work just fine for me, since it's only intended for testing
and performance improvements so far. I also think it's clearer for
end-users looking for a grep command if they're not faced with
fgrep/egrep/ggrep/bgrep alongside plain "grep".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Bug in git log
From: Junio C Hamano @ 2006-05-02 8:24 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060502075122.GA8203@spinlock.ch>
Matthias Kestenholz <lists@irregular.ch> writes:
> Inside your git source directory, do:
>
> First bug using old whatchanged script (not builtin version)
>
> $ ./git-whatchanged.sh -- unresolve.c
> fatal: ambiguous argument 'unresolve.c': unknown revision or
> filename
> Use '--' to separate filenames from revisions
>
> $ ./git-whatchanged.sh -- -- unresolve.c
> [...] gives the expected output
That indeed sounds funny. I was hoping to see it myself but did
not reproduce for me X-<.
> $ git log -- unresolve.c
> $ git log -- -- unresolve.c
> $ git whatchanged -- unresolve.c
>
> both give no output.
I do not have an older version between 0.99.9m and 1.3.1, but
1.3.1 (the current stale release) does not seem to have this
"double dash" problem. Neither the tonight's "master" version
(746437) nor "next".
We used to have a build problem where we forgot to remove
libgit.a and an old object from the archive was used by
mistake. Could you try rm -f libgit.a and rebuild your git to
see if it helps?
^ permalink raw reply
* Bug in git log
From: Matthias Kestenholz @ 2006-05-02 7:51 UTC (permalink / raw)
To: git
Hello list,
I found a bug in the new builtin git log which I am unable to fix
myself.
Inside your git source directory, do:
First bug using old whatchanged script (not builtin version)
$ ./git-whatchanged.sh -- unresolve.c
fatal: ambiguous argument 'unresolve.c': unknown revision or
filename
Use '--' to separate filenames from revisions
$ ./git-whatchanged.sh -- -- unresolve.c
[...] gives the expected output
$ git log -- unresolve.c
$ git log -- -- unresolve.c
$ git whatchanged -- unresolve.c
both give no output.
I checked the argument parsing stage and everything seemed sane (the
second double-dash was not necessary anymore)
However, the following works as expected:
$ git log -- git-log.sh
It seems that the problem shows only if there was no commit
modifying the asked-for file. unresolve.c is introduced in commit
ec167793d84ba7b765e1eb71b0257ce7baca2d26 and removed in the
subsequent commit 2bd452d3b9f62ecc3406307cd6a5553856d21ff2 and is
never modified.
/Matthias
--
:wq
^ permalink raw reply
* cg-mkpatch use case
From: Belmar-Letelier @ 2006-05-02 7:47 UTC (permalink / raw)
To: git
Hello,
I have 3 questions about cg-mkpatch
1. I've receive a file "xxx.patch", this content came from
cg-mkpatch, but I can't apply it.
For example if I try git-am I get::
$ git-am --signoff xxx.patch
Patch does not have a valid e-mail address.
What is the Cogito way to apply the result of "cg-mkpatch"
2. What are the difference between usecases with "cg-mkpatch"
and "git-format-patch" ?
3. It seem that if a commit as a binary file they are no way to manage
it by email patches. Any plan about this in Cogito ?
--
Luis
^ permalink raw reply
* [PATCH] Transitively read alternatives
From: Martin Waitz @ 2006-05-02 7:38 UTC (permalink / raw)
To: git
In-Reply-To: <20060501225335.GI20847@admingilde.org>
When adding an alternate object store then add entries from its
info/alternates files, too.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
sha1_file.c | 166 +++++++++++++++++++++++++++++++++--------------------------
1 files changed, 94 insertions(+), 72 deletions(-)
6ef777610f4e314fd93ecf672b9898fb95a7d5af
diff --git a/sha1_file.c b/sha1_file.c
index f2d33af..fb5778c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -216,6 +216,8 @@ char *sha1_pack_index_name(const unsigne
struct alternate_object_database *alt_odb_list;
static struct alternate_object_database **alt_odb_tail;
+static void read_info_alternates(const char * alternates);
+
/*
* Prepare alternate object database registry.
*
@@ -231,13 +233,78 @@ static struct alternate_object_database
* SHA1, an extra slash for the first level indirection, and the
* terminating NUL.
*/
+static int link_alt_odb_entry(const char * entry, int len, const char * relative_base)
+{
+ struct stat st;
+ const char *objdir = get_object_directory();
+ struct alternate_object_database *ent;
+ struct alternate_object_database *alt;
+ /* 43 = 40-byte + 2 '/' + terminating NUL */
+ int pfxlen = len;
+ int entlen = pfxlen + 43;
+ int base_len = -1;
+
+ if (*entry != '/' && relative_base) {
+ /* Relative alt-odb */
+ if (base_len < 0)
+ base_len = strlen(relative_base) + 1;
+ entlen += base_len;
+ pfxlen += base_len;
+ }
+ ent = xmalloc(sizeof(*ent) + entlen);
+
+ if (*entry != '/' && relative_base) {
+ memcpy(ent->base, relative_base, base_len - 1);
+ ent->base[base_len - 1] = '/';
+ memcpy(ent->base + base_len, entry, len);
+ }
+ else
+ memcpy(ent->base, entry, pfxlen);
+
+ ent->name = ent->base + pfxlen + 1;
+ ent->base[pfxlen + 3] = '/';
+ ent->base[pfxlen] = ent->base[entlen-1] = 0;
+
+ /* Detect cases where alternate disappeared */
+ if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
+ error("object directory %s does not exist; "
+ "check .git/objects/info/alternates.",
+ ent->base);
+ free(ent);
+ return -1;
+ }
+
+ /* Prevent the common mistake of listing the same
+ * thing twice, or object directory itself.
+ */
+ for (alt = alt_odb_list; alt; alt = alt->next) {
+ if (!memcmp(ent->base, alt->base, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+ }
+ if (!memcmp(ent->base, objdir, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+
+ /* add the alternate entry */
+ *alt_odb_tail = ent;
+ alt_odb_tail = &(ent->next);
+ ent->next = NULL;
+
+ /* recursively add alternates */
+ read_info_alternates(ent->base);
+
+ ent->base[pfxlen] = '/';
+
+ return 0;
+}
+
static void link_alt_odb_entries(const char *alt, const char *ep, int sep,
const char *relative_base)
{
const char *cp, *last;
- struct alternate_object_database *ent;
- const char *objdir = get_object_directory();
- int base_len = -1;
last = alt;
while (last < ep) {
@@ -248,61 +315,10 @@ static void link_alt_odb_entries(const c
last = cp + 1;
continue;
}
- for ( ; cp < ep && *cp != sep; cp++)
- ;
+ while (cp < ep && *cp != sep)
+ cp++;
if (last != cp) {
- struct stat st;
- struct alternate_object_database *alt;
- /* 43 = 40-byte + 2 '/' + terminating NUL */
- int pfxlen = cp - last;
- int entlen = pfxlen + 43;
-
- if (*last != '/' && relative_base) {
- /* Relative alt-odb */
- if (base_len < 0)
- base_len = strlen(relative_base) + 1;
- entlen += base_len;
- pfxlen += base_len;
- }
- ent = xmalloc(sizeof(*ent) + entlen);
-
- if (*last != '/' && relative_base) {
- memcpy(ent->base, relative_base, base_len - 1);
- ent->base[base_len - 1] = '/';
- memcpy(ent->base + base_len,
- last, cp - last);
- }
- else
- memcpy(ent->base, last, pfxlen);
-
- ent->name = ent->base + pfxlen + 1;
- ent->base[pfxlen + 3] = '/';
- ent->base[pfxlen] = ent->base[entlen-1] = 0;
-
- /* Detect cases where alternate disappeared */
- if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
- error("object directory %s does not exist; "
- "check .git/objects/info/alternates.",
- ent->base);
- goto bad;
- }
- ent->base[pfxlen] = '/';
-
- /* Prevent the common mistake of listing the same
- * thing twice, or object directory itself.
- */
- for (alt = alt_odb_list; alt; alt = alt->next)
- if (!memcmp(ent->base, alt->base, pfxlen))
- goto bad;
- if (!memcmp(ent->base, objdir, pfxlen)) {
- bad:
- free(ent);
- }
- else {
- *alt_odb_tail = ent;
- alt_odb_tail = &(ent->next);
- ent->next = NULL;
- }
+ link_alt_odb_entry(last, cp - last, relative_base);
}
while (cp < ep && *cp == sep)
cp++;
@@ -310,23 +326,14 @@ static void link_alt_odb_entries(const c
}
}
-void prepare_alt_odb(void)
+static void read_info_alternates(const char * relative_base)
{
- char path[PATH_MAX];
char *map;
- int fd;
struct stat st;
- char *alt;
-
- alt = getenv(ALTERNATE_DB_ENVIRONMENT);
- if (!alt) alt = "";
-
- if (alt_odb_tail)
- return;
- alt_odb_tail = &alt_odb_list;
- link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+ char path[PATH_MAX];
+ int fd;
- sprintf(path, "%s/info/alternates", get_object_directory());
+ sprintf(path, "%s/info/alternates", relative_base);
fd = open(path, O_RDONLY);
if (fd < 0)
return;
@@ -339,11 +346,26 @@ void prepare_alt_odb(void)
if (map == MAP_FAILED)
return;
- link_alt_odb_entries(map, map + st.st_size, '\n',
- get_object_directory());
+ link_alt_odb_entries(map, map + st.st_size, '\n', relative_base);
+
munmap(map, st.st_size);
}
+void prepare_alt_odb(void)
+{
+ char *alt;
+
+ alt = getenv(ALTERNATE_DB_ENVIRONMENT);
+ if (!alt) alt = "";
+
+ if (alt_odb_tail)
+ return;
+ alt_odb_tail = &alt_odb_list;
+ link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+
+ read_info_alternates(get_object_directory());
+}
+
static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
{
char *name = sha1_file_name(sha1);
--
1.3.1.g6ef7
--
Martin Waitz
^ permalink raw reply related
* Re: git-bisect broken in 1.2.4
From: Olaf Hering @ 2006-05-02 7:33 UTC (permalink / raw)
To: Junio C Hamano, pasky; +Cc: git, Uwe Zeisberger
In-Reply-To: <7vpsiwopkv.fsf@assigned-by-dhcp.cox.net>
On Tue, May 02, Junio C Hamano wrote:
> Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
>
> > Olaf Hering wrote:
> >> Did SuSE just pick up a bad version of git, 1.2.4?
> >> git-bisect doesnt work correctly in the kernel sources, .git/HEAD doesnt
> >> contain the commit id anymore, but 'ref: refs/heads/bisect'
> >>
> >> CONFIG_LOCALVERSION_AUTO depends on the id.
> > Probably you should update to at least linux-v2.6.15-g117a93d. The
> > script to determine the localversion[1] depends on .git/HEAD being a
> > symlink.
> >
> > Since
> >
> > git-1.1.4-g2fabd21
> >
> > .git/HEAD isn't a symlink any more (per default at least).
>
> Ouch. Although what Uwe says is all correct, we should not say
> "don't try kernel older than 2615-117a". That makes bisect
> rather useless.
>
> > You can rebuild git with USE_SYMLINK_HEAD if you really want the old
> > behaviour.
>
> That probably is a sane thing to do.
Ok, thanks for the patch.
Petr, can you update our git package in time?
^ permalink raw reply
* Re: git-bisect broken in 1.2.4
From: Junio C Hamano @ 2006-05-02 7:25 UTC (permalink / raw)
To: Olaf Hering; +Cc: git, Uwe Zeisberger
In-Reply-To: <20060502070155.GA861@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> Olaf Hering wrote:
>> Did SuSE just pick up a bad version of git, 1.2.4?
>> git-bisect doesnt work correctly in the kernel sources, .git/HEAD doesnt
>> contain the commit id anymore, but 'ref: refs/heads/bisect'
>>
>> CONFIG_LOCALVERSION_AUTO depends on the id.
> Probably you should update to at least linux-v2.6.15-g117a93d. The
> script to determine the localversion[1] depends on .git/HEAD being a
> symlink.
>
> Since
>
> git-1.1.4-g2fabd21
>
> .git/HEAD isn't a symlink any more (per default at least).
Ouch. Although what Uwe says is all correct, we should not say
"don't try kernel older than 2615-117a". That makes bisect
rather useless.
> You can rebuild git with USE_SYMLINK_HEAD if you really want the old
> behaviour.
That probably is a sane thing to do.
We should introduce prefer_symlink_refs configuration to work
with projects whose older version of build infrastructure
depends on symlink refs.
The patch is on top of post 1.3.1 git, but .c and .h part should
apply more-or-less cleanly to older code base. You should
be able to say:
[core]
prefersymlinkrefs = true
in .git/config file, maybe do "git checkout -f master" to switch
branch and make .git/HEAD into symlink, and do the bisect again.
Sorry for the screwup.
-- >8 --
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b27b0d5..d1a4bec 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -64,9 +64,11 @@ core.ignoreStat::
slow, such as Microsoft Windows. See gitlink:git-update-index[1].
False by default.
-core.onlyUseSymrefs::
- Always use the "symref" format instead of symbolic links for HEAD
- and other symbolic reference files. True by default.
+core.preferSymlinkRefs::
+ Instead of the default "symref" format for HEAD
+ and other symbolic reference files, use symbolic links.
+ This is sometimes needed to work with old scripts that
+ expect HEAD to be a symbolic link.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/Makefile b/Makefile
index 2374335..ecbdde6 100644
--- a/Makefile
+++ b/Makefile
@@ -28,8 +28,8 @@ # Define NO_STRCASESTR if you don't have
#
# Define NO_SETENV if you don't have setenv in the C library.
#
-# Define USE_SYMLINK_HEAD if you want .git/HEAD to be a symbolic link.
-# Don't enable it on Windows.
+# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
+# Enable it on Windows. By default, symrefs are still used.
#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
@@ -265,6 +265,7 @@ ifeq ($(uname_O),Cygwin)
NO_D_TYPE_IN_DIRENT = YesPlease
NO_D_INO_IN_DIRENT = YesPlease
NO_STRCASESTR = YesPlease
+ NO_SYMLINK_HEAD = YesPlease
NEEDS_LIBICONV = YesPlease
# There are conflicting reports about this.
# On some boxes NO_MMAP is needed, and not so elsewhere.
@@ -388,6 +389,9 @@ endif
ifdef NO_D_INO_IN_DIRENT
ALL_CFLAGS += -DNO_D_INO_IN_DIRENT
endif
+ifdef NO_SYMLINK_HEAD
+ ALL_CFLAGS += -DNO_SYMLINK_HEAD
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/cache.h b/cache.h
index a0cf8ca..d186b44 100644
--- a/cache.h
+++ b/cache.h
@@ -170,7 +170,7 @@ extern void rollback_index_file(struct c
/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
extern int assume_unchanged;
-extern int only_use_symrefs;
+extern int prefer_symlink_refs;
extern int warn_ambiguous_refs;
extern int diff_rename_limit_default;
extern int shared_repository;
diff --git a/config.c b/config.c
index 4e1f0c2..6cd31a3 100644
--- a/config.c
+++ b/config.c
@@ -227,8 +227,8 @@ int git_default_config(const char *var,
return 0;
}
- if (!strcmp(var, "core.symrefsonly")) {
- only_use_symrefs = git_config_bool(var, value);
+ if (!strcmp(var, "core.prefersymlinkrefs")) {
+ prefer_symlink_refs = git_config_bool(var, value);
return 0;
}
diff --git a/environment.c b/environment.c
index 6df6478..444c99e 100644
--- a/environment.c
+++ b/environment.c
@@ -13,7 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
int assume_unchanged = 0;
-int only_use_symrefs = 0;
+int prefer_symlink_refs = 0;
int warn_ambiguous_refs = 1;
int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
diff --git a/refs.c b/refs.c
index 03398cc..275b914 100644
--- a/refs.c
+++ b/refs.c
@@ -76,8 +76,8 @@ int create_symref(const char *git_HEAD,
char ref[1000];
int fd, len, written;
-#ifdef USE_SYMLINK_HEAD
- if (!only_use_symrefs) {
+#ifndef NO_SYMLINK_HEAD
+ if (prefer_symlink_refs) {
unlink(git_HEAD);
if (!symlink(refs_heads_master, git_HEAD))
return 0;
^ permalink raw reply related
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Martin Langhoff @ 2006-05-02 7:08 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <4456A616.6070402@vilain.net>
On 5/2/06, Sam Vilain <sam@vilain.net> wrote:
> Here I'm a little bit confused still. Surely criss-crossing branches
> already don't converge unless the commits are in the same order.
They do under GIT. No matter how much you criss-cross, every time you
identify a merge base for the next merge, you are identifying the last
commit in common on both branches.
While maybe you didn't have that commit being the tip of a head in
your repo, it _is_ the last common point. If your criss-crossing is
messy and a few commits are out of order or cherry picked, git-merge
has a good chance of spotting it. The whole mechanism tends pulls
quite consistently towards convergence.
If the notes in the commit msg aren't consistent and we lose the
natural tendency towards convergence that's a major drawback. On the
other hand, if two branches have exchanged patches "out of band",
git-merge still gets it right most of the time, so perhaps slightly
different headers in the commit messages are tolerable?
Junio had written:
> >On the other hand, a "note" field that records on which branch
> >of which repository each commit was made (you need to give each
> >repository-branch an UUID) when you do create a new commit would
> >be a sensible thing to have if somebody cares deeply enough.
I really don't like that -- goes against the grain of really simple,
portable repos. I cp -pr repo{,_tmp} all the time to do risky merges
or save a heavy download from a remote server. Let me run away from
this idea... quick before Linus kills us all ;-)
I did feel a couple of times the need of remembering where I had
checked this in -- but it went away quite quickly, must have been a
leftover of my Arch days ;-). And it actually got solved by agreeing
within my team to a commit message format pretty much like what's used
in the kernel. Because the truth is that most of my heads and branches
have very "local" names.
cheers,
martin
^ 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