* [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Junio C Hamano @ 2012-01-23 22:04 UTC (permalink / raw)
To: Git Mailing List
Cc: Alex Riesen, Ævar Arnfjörð Bjarmason,
Jonathan Nieder
In-Reply-To: <7vwr8i6prk.fsf_-_@alter.siamese.dyndns.org>
From: Alex Riesen <raa.lkml@gmail.com>
Some systems have gettext.sh (GNU gettext) installed, but it is either
broken or misconfigured in such a way so its output is not usable. In
case the users of these systems are unable or not interested in fixing
them, setting the new Makefile switch should help:
make USE_GETTEXT_SCHEME=fallthrough
This will replace the translation routines with fallthrough versions,
that does not use gettext from the platform.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 4 ++++
git-sh-i18n.sh | 5 ++++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 9470a10..4435854 100644
--- a/Makefile
+++ b/Makefile
@@ -47,6 +47,9 @@ all::
# A translated Git requires GNU libintl or another gettext implementation,
# plus libintl-perl at runtime.
#
+# Define USE_GETTEXT_SCHEME and set it to 'fallthrough', if you don't trust
+# the installed gettext translation of the shell scripts output.
+#
# Define HAVE_LIBCHARSET_H if you haven't set NO_GETTEXT and you can't
# trust the langinfo.h's nl_langinfo(CODESET) function to return the
# current character set. GNU and Solaris have a nl_langinfo(CODESET),
@@ -1874,6 +1877,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's|@@LOCALEDIR@@|$(localedir_SQ)|g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@USE_GETTEXT_SCHEME@@/$(USE_GETTEXT_SCHEME)/g' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+
endef
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index 6648bd3..d5fae99 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -18,7 +18,10 @@ export TEXTDOMAINDIR
# First decide what scheme to use...
GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
-if test -n "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
+if test -n "@@USE_GETTEXT_SCHEME@@"
+then
+ GIT_INTERNAL_GETTEXT_SH_SCHEME="@@USE_GETTEXT_SCHEME@@"
+elif test -n "@@USE_FALLTHROUGH_GETTEXT_SCHEME@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
then
: no probing necessary
elif test -n "$GIT_GETTEXT_POISON"
--
1.7.9.rc2.48.g92994
^ permalink raw reply related
* Re: [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Jonathan Nieder @ 2012-01-23 22:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Alex Riesen,
Ævar Arnfjörð Bjarmason
In-Reply-To: <7vr4yq6poy.fsf_-_@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> make USE_GETTEXT_SCHEME=fallthrough
>
> This will replace the translation routines with fallthrough versions,
> that does not use gettext from the platform.
Nice implementation. I still don't understand why NO_GETTEXT=YesPlease
should not imply this. Is it to ensure the GETTEXT_SCHEME=gnu mode
gets more testing?
Here's a patch to consider squashing in that makes the option take
effect if it changes between builds.
diff --git i/Makefile w/Makefile
index 63dfd64d..b2b738bb 100644
--- i/Makefile
+++ w/Makefile
@@ -2268,7 +2268,7 @@ cscope:
### Detect prefix changes
TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):\
- $(localedir_SQ)
+ $(localedir_SQ):$(USE_GETTEXT_SCHEME)
GIT-CFLAGS: FORCE
@FLAGS='$(TRACK_CFLAGS)'; \
^ permalink raw reply related
* [PATCH] merge: use editor by default in interactive sessions
From: Junio C Hamano @ 2012-01-23 22:18 UTC (permalink / raw)
To: git
Traditionally, a cleanly resolved merge was committed by "git merge" using
the auto-generated merge commit log message with invoking the editor.
After 5 years of use in the field, it turns out that people perform too
many unjustified merges of the upstream history into their topic branches.
These merges are not just useless, but they are often not explained well,
and making the end result unreadable when it gets time for merging their
history back to their upstream.
Earlier we added the "--edit" option to the command, so that people can
edit the log message to explain and justify their merge commits. Let's
take it one step further and spawn the editor by default when we are in an
interactive session (i.e. the standard input and the standard output are
pointing at the same tty device).
There may be existing scripts that leave the standard input and the
standard output of the "git merge" connected to whatever environment the
scripts were started, and such invocation might trigger the above
"interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable
can be set to "no" at the beginning of such scripts to use the historical
behaviour while the script runs.
Note that this backward compatibility is meant only for scripts, and we
deliberately do *not* support "merge.edit = yes/no/auto" configuration
option to allow people to keep the historical behaviour.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* With an update to the documentation, so that I won't forget, even
though this topic came too late in the cycle and not meant for the
upcoming 1.7.9.
Documentation/git-merge.txt | 2 +-
Documentation/merge-options.txt | 16 +++++++++++++---
builtin/merge.c | 38 ++++++++++++++++++++++++++++++++++----
t/test-lib.sh | 3 ++-
4 files changed, 50 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index e2e6aba..3ceefb8 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -9,7 +9,7 @@ git-merge - Join two or more development histories together
SYNOPSIS
--------
[verse]
-'git merge' [-n] [--stat] [--no-commit] [--squash]
+'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[-s <strategy>] [-X <strategy-option>]
[--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
'git merge' <msg> HEAD <commit>...
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 6bd0b04..f2f1d0f 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -8,10 +8,20 @@ failed and do not autocommit, to give the user a chance to
inspect and further tweak the merge result before committing.
--edit::
--e::
+--no-edit::
+ Invoke an editor before committing successful mechanical merge to
+ further edit the auto-generated merge message, so that the user
+ can explain and justify the merge. The `--no-edit` option can be
+ used to accept the auto-generated message (this is generally
+ discouraged). The `--edit` option is still useful if you are
+ giving a draft message with the `-m` option from the command line
+ and want to edit it in the editor.
+
- Invoke editor before committing successful merge to further
- edit the default merge message.
+Older scripts may depend on the historical behaviour of not allowing the
+user to edit the merge log message. They will see an editor opened when
+they run `git merge`. To make it easier to adjust such scripts to the
+updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be
+set to `no` at the beginning of them.
--ff::
--no-ff::
diff --git a/builtin/merge.c b/builtin/merge.c
index 99f1429..0006175 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -46,7 +46,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, shortlog_len, squash;
static int option_commit = 1, allow_fast_forward = 1;
-static int fast_forward_only, option_edit;
+static int fast_forward_only, option_edit = -1;
static int allow_trivial = 1, have_message;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
@@ -189,7 +189,7 @@ static struct option builtin_merge_options[] = {
"create a single commit instead of doing a merge"),
OPT_BOOLEAN(0, "commit", &option_commit,
"perform a commit if the merge succeeds (default)"),
- OPT_BOOLEAN('e', "edit", &option_edit,
+ OPT_BOOL('e', "edit", &option_edit,
"edit message before committing"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast-forward (default)"),
@@ -877,12 +877,12 @@ static void prepare_to_commit(void)
write_merge_msg(&msg);
run_hook(get_index_file(), "prepare-commit-msg",
git_path("MERGE_MSG"), "merge", NULL, NULL);
- if (option_edit) {
+ if (0 < option_edit) {
if (launch_editor(git_path("MERGE_MSG"), NULL, NULL))
abort_commit(NULL);
}
read_merge_msg(&msg);
- stripspace(&msg, option_edit);
+ stripspace(&msg, 0 < option_edit);
if (!msg.len)
abort_commit(_("Empty commit message."));
strbuf_release(&merge_msg);
@@ -1076,6 +1076,33 @@ static void write_merge_state(void)
close(fd);
}
+static int default_edit_option(void)
+{
+ static const char name[] = "GIT_MERGE_AUTOEDIT";
+ const char *e = getenv(name);
+ struct stat st_stdin, st_stdout;
+
+ if (have_message)
+ /* an explicit -m msg without --[no-]edit */
+ return 0;
+
+ if (e) {
+ int v = git_config_maybe_bool(name, e);
+ if (v < 0)
+ die("Bad value '%s' in environment '%s'", e, name);
+ return v;
+ }
+
+ /* Use editor if stdin and stdout are the same and is a tty */
+ return (!fstat(0, &st_stdin) &&
+ !fstat(1, &st_stdout) &&
+ isatty(0) &&
+ st_stdin.st_dev == st_stdout.st_dev &&
+ st_stdin.st_ino == st_stdout.st_ino &&
+ st_stdin.st_mode == st_stdout.st_mode);
+}
+
+
int cmd_merge(int argc, const char **argv, const char *prefix)
{
unsigned char result_tree[20];
@@ -1261,6 +1288,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
+ if (option_edit < 0)
+ option_edit = default_edit_option();
+
if (!use_strategies) {
if (!remoteheads->next)
add_strategies(pull_twohead, DEFAULT_TWOHEAD);
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bdd9513..ed32c2a 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -63,7 +63,8 @@ GIT_AUTHOR_NAME='A U Thor'
GIT_COMMITTER_EMAIL=committer@example.com
GIT_COMMITTER_NAME='C O Mitter'
GIT_MERGE_VERBOSITY=5
-export GIT_MERGE_VERBOSITY
+GIT_MERGE_AUTOEDIT=no
+export GIT_MERGE_VERBOSITY GIT_MERGE_AUTOEDIT
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR
--
1.7.9.rc2.48.g92994
^ permalink raw reply related
* Re: [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Junio C Hamano @ 2012-01-23 22:23 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git Mailing List, Alex Riesen,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20120123221256.GG20833@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> make USE_GETTEXT_SCHEME=fallthrough
>>
>> This will replace the translation routines with fallthrough versions,
>> that does not use gettext from the platform.
>
> Nice implementation. I still don't understand why NO_GETTEXT=YesPlease
> should not imply this.
Should be easy to do so, like this?
diff --git a/Makefile b/Makefile
index a782409..c4c1066 100644
--- a/Makefile
+++ b/Makefile
@@ -1521,6 +1521,7 @@ ifdef GETTEXT_POISON
endif
ifdef NO_GETTEXT
BASIC_CFLAGS += -DNO_GETTEXT
+ USE_GETTEXT_SCHEME = fallthrough
endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
^ permalink raw reply related
* Re: [PATCH] merge: use editor by default in interactive sessions
From: Michael Haggerty @ 2012-01-23 22:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vipk26p1b.fsf@alter.siamese.dyndns.org>
On 01/23/2012 11:18 PM, Junio C Hamano wrote:
> Traditionally, a cleanly resolved merge was committed by "git merge" using
> the auto-generated merge commit log message with invoking the editor.
s/with/without/
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] merge: use editor by default in interactive sessions
From: Junio C Hamano @ 2012-01-23 22:34 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4F1DDECB.5080904@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 01/23/2012 11:18 PM, Junio C Hamano wrote:
>> Traditionally, a cleanly resolved merge was committed by "git merge" using
>> the auto-generated merge commit log message with invoking the editor.
>
> s/with/without/
Oops, thanks, ... goes to find a hole to crawl into ...
^ permalink raw reply
* Re: [PATCH v2 3/3] git-p4: Add test case for complex branch import
From: Pete Wyckoff @ 2012-01-23 22:40 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Luke Diamand, Junio C Hamano, git
In-Reply-To: <CAOpHH-W1LY3Q50otrcNJTYWN67k_pCZHEOkgbKy7kPgfUbGeQw@mail.gmail.com>
vitor.hda@gmail.com wrote on Mon, 23 Jan 2012 14:01 +0000:
> On Sat, Jan 21, 2012 at 5:11 PM, Pete Wyckoff <pw@padd.com> wrote:
> > luke@diamand.org wrote on Sat, 21 Jan 2012 10:51 +0000:
> >> However, one thing I noticed in reading through is that it will
> >> break if you end up importing a P4 branch that has spaces (or other
> >> shell chars) in its name. A quick test confirms this.
> >>
> >> - the code doesn't handle the names properly
> >> - git and p4 have different ideas about valid branch names
> >>
> >> But before rejecting Vitor's changes because of that it would be
> >> worth considering whether we care (much). My own opinion is that if
> >> you have developers who are daft enough to put spaces or dollars in
> >> their branch names then their project is already doomed anyway....
> >>
> >> Perhaps it would be enough just to issue a warning ("your project is
> >> doomed; start working on your CV") and skip such branch names rather
> >> than falling over with inexplicable error messages.
> >
> > This doesn't seem like a big deal. The read_pipe and
> > read_pipe_lines calls shoud be list-ified. That gets rid
> > of the problem with shell interactions.
> >
> > For git branch name reserved characters, a little function
> > to replace the bogus characters with "_" would avoid needing
> > to go work on the resume. Anything in bad_ref_char() and
> > check_refname_component(). I agree this doesn't have to be
> > perfect.
> >
> > This could be a new patch unrelated to Vitor's series, which
> > verifies branch names anywhere a new commit is made.
>
> I would also prefer to include that fix on a separate patch series that
> would include the test case Luke already prepared. In my opinion,
> updating read_pipe and read_pipe_lines is out of scope for the current
> patch series.
How about taking what's below and just squashing it in. It's
incremental on your changes and would go well with Luke's series
that fixes a bunch of scattered quoting issues similarly.
The change to "describe %s" is unnecessary, but makes all the
invocations look similar. You can leave it out.
This may conflict if you've already factored out the big
"if self.detectBranches" chunk into a separate function as
Junio recommended.
> BTW, and on an unrelated topic, are any test cases failing on your side?
I do run the tests regularly, and your series is good. There's
the 'clone --use-client-spec' one that is broken until my
2ea09b5 (git-p4: adjust test to adhere to stricter useClientSpec,
2012-01-11) is merged. It's on pu.
-- Pete
-----------8<-------------------
From f1cfb3836f5150dca86238225da56fe0bd577df8 Mon Sep 17 00:00:00 2001
From: Pete Wyckoff <pw@padd.com>
Date: Thu, 10 Nov 2011 07:40:14 -0500
Subject: [PATCH] git-p4: use list invoctaions to avoid shell mangling
Change git and p4 command invocations to avoid going through
the shell. This allows branch names with spaces and wildcards
to work.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2e3b741..b440966 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1961,7 +1961,7 @@ class P4Sync(Command, P4UserMap):
def importChanges(self, changes):
cnt = 1
for change in changes:
- description = p4Cmd("describe %s" % change)
+ description = p4Cmd(["describe", str(change)])
self.updateOptionDict(description)
if not self.silent:
@@ -2022,9 +2022,9 @@ class P4Sync(Command, P4UserMap):
self.commit(description, filesForCommit, tempBranch, [branchPrefix])
self.tempBranches.append(tempBranch)
self.checkpoint()
- for blob in read_pipe_lines("git rev-list --reverse --no-merges %s" % parent):
+ for blob in read_pipe_lines(["git", "rev-list", "--reverse", "--no-merges", parent]):
blob = blob.strip()
- if len( read_pipe("git diff-tree %s %s" % (blob, tempBranch)) ) == 0:
+ if len(read_pipe(["git", "diff-tree", blob, tempBranch])) == 0:
parentFound = True
if self.verbose:
print "Found parent of %s in commit %s" % (branch, blob)
--
1.7.9.rc2.33.g492ae
^ permalink raw reply related
* Re: [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Jonathan Nieder @ 2012-01-23 22:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Alex Riesen,
Ævar Arnfjörð Bjarmason
In-Reply-To: <7vehuq6ote.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Nice implementation. I still don't understand why NO_GETTEXT=YesPlease
>> should not imply this.
>
> Should be easy to do so, like this?
>
> diff --git a/Makefile b/Makefile
> index a782409..c4c1066 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1521,6 +1521,7 @@ ifdef GETTEXT_POISON
> endif
> ifdef NO_GETTEXT
> BASIC_CFLAGS += -DNO_GETTEXT
> + USE_GETTEXT_SCHEME = fallthrough
> endif
Yep, that would make my worries about intuitive behavior evaporate. :)
(Maybe "USE_GETTEXT_SCHEME ?= fallthrough" to make it easier to
override in config.mak.)
Thanks. I also would not actually mind the behavior without that
tweak, as long as it's explained somewhere.
Ciao,
Jonathan
^ permalink raw reply
* [PATCH] Don't search files with an unset "grep" attribute
From: Conrad Irwin @ 2012-01-23 22:59 UTC (permalink / raw)
To: git; +Cc: Nguyen Thai Ngoc Duy, Conrad Irwin, Junio C Hamano, Dov Grobgeld
In-Reply-To: <7vy5sy8e0y.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> Please reword this to describe the problem being solved first (why it
> needs to be solved, in what situation you cannot live without the
> feature), and then describe the approach you used to solve it.
>
Done — I also removed the extraneous braces from the patch.
>
> in order to avoid uselessly spewing garbage at you while reminding you
> that the command is not showing the whole truth and you _might_ want to
> look into the elided file if you wanted to with "grep -a world hello.o".
> Compared to this, it feels that the result your patch goes too far and
> hides the truth a bit too much to my taste. Maybe it is just me.
I used to use this approach, hooking into the "diff" attribute directly to mark
a file as binary, however that was clearly a hack. When developing this patch I
went through a few iterations, one in which -grep meant "treat this file as
binary", however explaining that in the man page is subtle and ugly: "HINT: you
might want to set a file as binary because you don't want to see results from it
when grepping". It's much more obvious to have -grep mean "don't show me
results".
A nicer alternative could be to allow "grep=binary" (and for completeness
"grep=text") in addition to "-grep". Then people who want to see matches but not
the contents of the matches can tell grep that their files are "binary". It
would also make sense to add "grep=binary" to the binary macro-attribute. We
could even extend the system arbitrarily to allow something like the textconv
attributes of git-diff... one step at a time is probably better though.
> Perhaps you, or all participants of your particular project, usually do
> not want to see any grep hits from minified.js, but you may still want to
> be able to say "I want to dig deeper and make sure I have copyright
> strings in all files", for example. It is unclear how you envision to
> support such a use case building on top of this patch.
I think that it would be very reasonable to add a flag to grep to tell it to
ignore the attribute temporarily (like --no-textconv on git-diff) and update the
"-a" shorthand to imply "--text --no-exclude-attribute".
Yours,
Conrad
---8<---
Git grep is used by developers to search the code stored in their repositories,
however it can give noisy results when the repository contains files that are
not of direct interest to development. Examples of such files include test
fixtures, dlls, or minified source code.
To help these developers search efficiently, git grep will now use the
gitattributes mechanism to ignore all files with an unset "grep" attribute.
Another approach considered was to allow an --exclude flag to grep at runtime,
however this is more clunky to use when the set of files to be excluded is
fixed.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
Documentation/git-grep.txt | 7 +++++++
Documentation/gitattributes.txt | 9 +++++++++
builtin/grep.c | 6 ++++++
grep.c | 21 +++++++++++++++++++++
grep.h | 1 +
t/t7810-grep.sh | 30 ++++++++++++++++++++++++++++++
6 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 6a8b1e3..7c74165 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -242,6 +242,13 @@ OPTIONS
If given, limit the search to paths matching at least one pattern.
Both leading paths match and glob(7) patterns are supported.
+ATTRIBUTES
+----------
+
+grep::
+ If the grep attribute is unset on a file using the linkgit:gitattributes[1]
+ mechanism, then that file will not be searched.
+
Examples
--------
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index a85b187..3ffcec7 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -869,6 +869,15 @@ If this attribute is not set or has an invalid value, the value of the
`gui.encoding` configuration variable is used instead
(See linkgit:git-config[1]).
+Configuring files to search
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`grep`
+^^^^^^
+
+If the attribute `grep` is unset for a file then linkgit:git-grep[1]
+will ignore that file while searching for matches.
+
USING MACRO ATTRIBUTES
----------------------
diff --git a/builtin/grep.c b/builtin/grep.c
index 9ce064a..a7817fe 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -398,6 +398,9 @@ static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1,
struct strbuf pathbuf = STRBUF_INIT;
char *name;
+ if (!should_grep_path(opt, filename + tree_name_len))
+ return 0;
+
if (opt->relative && opt->prefix_length) {
quote_path_relative(filename + tree_name_len, -1, &pathbuf,
opt->prefix);
@@ -464,6 +467,9 @@ static int grep_file(struct grep_opt *opt, const char *filename)
struct strbuf buf = STRBUF_INIT;
char *name;
+ if (!should_grep_path(opt, filename))
+ return 0;
+
if (opt->relative && opt->prefix_length)
quote_path_relative(filename, -1, &buf, opt->prefix);
else
diff --git a/grep.c b/grep.c
index 486230b..e948576 100644
--- a/grep.c
+++ b/grep.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "grep.h"
+#include "attr.h"
#include "userdiff.h"
#include "xdiff-interface.h"
@@ -829,6 +830,26 @@ static inline void grep_attr_unlock(struct grep_opt *opt)
#define grep_attr_unlock(opt)
#endif
+static struct git_attr_check attr_check[1];
+static void setup_attr_check(void)
+{
+ if (attr_check[0].attr)
+ return; /* already done */
+ attr_check[0].attr = git_attr("grep");
+}
+int should_grep_path(struct grep_opt *opt, const char *name) {
+ int ret = 1;
+
+ grep_attr_lock(opt);
+ setup_attr_check();
+ git_check_attr(name, 1, attr_check);
+ if (ATTR_FALSE(attr_check[0].value))
+ ret = 0;
+ grep_attr_unlock(opt);
+
+ return ret;
+}
+
static int match_funcname(struct grep_opt *opt, const char *name, char *bol, char *eol)
{
xdemitconf_t *xecfg = opt->priv;
diff --git a/grep.h b/grep.h
index fb205f3..266002d 100644
--- a/grep.h
+++ b/grep.h
@@ -129,6 +129,7 @@ extern void append_header_grep_pattern(struct grep_opt *, enum grep_header_field
extern void compile_grep_patterns(struct grep_opt *opt);
extern void free_grep_patterns(struct grep_opt *opt);
extern int grep_buffer(struct grep_opt *opt, const char *name, char *buf, unsigned long size);
+extern int should_grep_path(struct grep_opt *opt, const char *name);
extern struct grep_opt *grep_opt_dup(const struct grep_opt *opt);
extern int grep_threads_ok(const struct grep_opt *opt);
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 7ba5b16..c991518 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -871,4 +871,34 @@ test_expect_success 'mimic ack-grep --group' '
test_cmp expected actual
'
+test_expect_success 'with -grep attribute' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf &&
+ rm .gitattributes
+'
+
+test_expect_success 'with -grep attribute on specific file' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf hello.c &&
+ rm .gitattributes
+'
+
+test_expect_success 'with -grep attribute on specific revision' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf HEAD &&
+ rm .gitattributes
+'
+
+test_expect_success 'with -grep attribute on specific file/revision' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf HEAD hello.c &&
+ rm .gitattributes
+'
+
+test_expect_failure 'with -grep attribute on specific tree' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf HEAD:hello.c &&
+ rm .gitattributes
+'
+
test_done
--
1.7.9.rc2.1.g1fdd3
^ permalink raw reply related
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Junio C Hamano @ 2012-01-24 0:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King
In-Reply-To: <1326189427-20800-7-git-send-email-pclouds@gmail.com>
I wanted to merge this series to 'next' and further merge it early in the
next cycle to 'master', but with this my pushes (!!) seem to fail.
It breaks pushing to multiple URLs like this:
$ cat .git/config
[remote "origin"]
url = https://code.google.com/p/git-htmldocs/
url = github.com:gitster/git-htmldocs.git
push = refs/heads/master:refs/heads/master
$ git push
The second url that is supposed to use the git-over-ssh transport
mistakenly use https:// and fails with:
error: Couldn't resolve host 'github.com:gitster' while accessing
github.com:gitster/git-htmldocs.git/info/refs
fatal: HTTP request failed
^ permalink raw reply
* [PATCH/RFC 3/2] i18n: do not use gettext.sh by default when NO_GETTEXT is set
From: Jonathan Nieder @ 2012-01-24 0:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Alex Riesen,
Ævar Arnfjörð Bjarmason
In-Reply-To: <7vehuq6ote.fsf@alter.siamese.dyndns.org>
From: Junio C Hamano <gitster@pobox.com>
When NO_GETTEXT is set, even if a usable installed gettext.sh is
detected to be present, it can only help to use git's simple fallback
stub implementations of gettext and eval_gettext for shell scripts
instead. That way:
1) we avoid the complication of autodetection of gettext.sh support
at runtime;
2) in particular, if the operating system provides gettext.sh but
it is unusable, we will not be tricked into trying to use it.
So this patch makes USE_GETTEXT_SCHEME default to fallthrough when
NO_GETTEXT is set. This is only a default so the operator can set
USE_GETTEXT_SCHEME=gnu or ...=gettext_without_eval_gettext to try the
other schemes.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Should be easy to do so, like this?
Probably too late to be useful, but here's a patch with commit message
implementing the same.
Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b2b738bb..e9b4a2f9 100644
--- a/Makefile
+++ b/Makefile
@@ -1524,6 +1524,9 @@ ifdef GETTEXT_POISON
endif
ifdef NO_GETTEXT
BASIC_CFLAGS += -DNO_GETTEXT
+ ifndef USE_GETTEXT_SCHEME
+ USE_GETTEXT_SCHEME = fallthrough
+ endif
endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
--
1.7.9.rc2
^ permalink raw reply related
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Junio C Hamano @ 2012-01-24 0:34 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King
In-Reply-To: <7v62g26jm3.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> It breaks pushing to multiple URLs like this:
>
> $ cat .git/config
> [remote "origin"]
> url = https://code.google.com/p/git-htmldocs/
> url = github.com:gitster/git-htmldocs.git
> push = refs/heads/master:refs/heads/master
> $ git push
>
> The second url that is supposed to use the git-over-ssh transport
> mistakenly use https:// and fails with:
>
> error: Couldn't resolve host 'github.com:gitster' while accessing
> github.com:gitster/git-htmldocs.git/info/refs
> fatal: HTTP request failed
And here is an obvious band-aid to work it around.
^ permalink raw reply
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Junio C Hamano @ 2012-01-24 0:39 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King
In-Reply-To: <7vzkde546x.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> It breaks pushing to multiple URLs like this:
>>
>> $ cat .git/config
>> [remote "origin"]
>> url = https://code.google.com/p/git-htmldocs/
>> url = github.com:gitster/git-htmldocs.git
>> push = refs/heads/master:refs/heads/master
>> $ git push
>>
>> The second url that is supposed to use the git-over-ssh transport
>> mistakenly use https:// and fails with:
>>
>> error: Couldn't resolve host 'github.com:gitster' while accessing
>> github.com:gitster/git-htmldocs.git/info/refs
>> fatal: HTTP request failed
>
> And here is an obvious band-aid to work it around.
-- >8 --
Subject: [PATCH] push: do not let configured foreign-vcs permanently clobbered
Recently, 6f48d39 (clone: delay cloning until after remote HEAD checking,
2012-01-16) tried to record if a remote helper needs to be called after
parsing the remote when transport_get() is called, by overwriting the
field meant to store the configured remote helper name in the remote
structure.
This is OK when a remote represents a single remote repository, but fails
miserably when pushing to locations with multiple URLs, like this:
$ cat .git/config
[remote "origin"]
url = https://code.google.com/p/git-htmldocs/
url = github.com:gitster/git-htmldocs.git
push = refs/heads/master:refs/heads/master
$ git push
The second url that is supposed to use the git-over-ssh transport
mistakenly use https:// and fails with:
error: Couldn't resolve host 'github.com:gitster' while accessing
github.com:gitster/git-htmldocs.git/info/refs
fatal: HTTP request failed
The right solution would probably be to dedicate a separate field to store
the detected external helper to be used, which is valid only during a
single use of transport until it is disconnected, instead of overwriting
foreign_vcs field, but in the meantime, this band-aid should suffice.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/push.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 35cce53..5fb98a0 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -204,11 +204,13 @@ static int do_push(const char *repo, int flags)
url_nr = remote->url_nr;
}
if (url_nr) {
+ const char *configured_foreign_vcs = remote->foreign_vcs;
for (i = 0; i < url_nr; i++) {
struct transport *transport =
transport_get(remote, url[i]);
if (push_with_options(transport, flags))
errs++;
+ remote->foreign_vcs = configured_foreign_vcs;
}
} else {
struct transport *transport =
--
1.7.9.rc2.100.gfd863d
^ permalink raw reply related
* Re: [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Ævar Arnfjörð Bjarmason @ 2012-01-24 0:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Git Mailing List, Alex Riesen
In-Reply-To: <20120123221256.GG20833@burratino>
On Mon, Jan 23, 2012 at 23:12, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Junio C Hamano wrote:
>
>> make USE_GETTEXT_SCHEME=fallthrough
>>
>> This will replace the translation routines with fallthrough versions,
>> that does not use gettext from the platform.
>
> Nice implementation. I still don't understand why NO_GETTEXT=YesPlease
> should not imply this. Is it to ensure the GETTEXT_SCHEME=gnu mode
> gets more testing?
I was the only one with an objection to doing that. The main (and I
admit, at least slightly irrational) reason being that I simply don't
like using fallback functions when the system supplies us with
perfectly good functions we can use instead.
It means we're less likely to share code / fixes / eyeballs / cache
with other programs. I.e. by using envsubst(1) instead of
git-sh-i18n--envsubst--variables(1).
Ironically this is all my fault by naming the option for turning off
translations NO_GETTEXT. What it should be called is
DO_NOT_TRANSLATE_OUTPUT, but since we *need* shell functions to output
anything it might have used a system gettext library to do that,
NO_GETTEXT should have been "I don't have any gettext library, please
supply some fallbacks".
Which would have meant that for people who simply don't want
translated output we'd be using the maintained by upstream envsubst(1)
instead of the doomed to bitrot forever hack I ripped out of some old
GPL2 version of GNU gettext.
Anyway in the grand scheme of things none of this really matters,
these patches can all go in as far as I'm concerned. I can submit
patches to improve it once the dust has settled if I still care
enough.
Aside from this I think not having the ability to run a pre-processor
on the shellscripts results in some really ugly workarounds. This
stuff would be much nicer if we could just generate git-sh-i18n.sh at
compile time depending on some autoconf tests or Makefile options.
And by hacking up a pre-processor that just searches/replaces all the
gettext/eval_gettext calls out of the shell code we could sidestep
this whole issue and there wouldn't be any need for fallback
functions, ever. This would also result in a real improvement on
Windows where exec overhead is much larger.
Like this hack, which doesn't even work, but gives you some idea of
what we could do:
#!/usr/bin/env perl
BEGIN { $^I = ""; }
sub unescape {
my $str = shift;
$str =~ s/\\\$/\$/gs;
$str;
}
LINE: while (defined($_ = <ARGV>)) {
s["\$\(gettext "([^"]+?)"\)"]["$1"]g;
s["\$\(eval_gettext "([^"]+?)"\)"]['"' . unescape($1) . '"']eg;
s[eval_gettextln "([^"]+?)"]['echo "' . unescape($1) . '"']eg;
s[gettext "([^"]+?)"][printf "%s" "$1"]g;
s[gettextln "([^"]+?)"][echo "$1"]g;
# s[gettextln "([^"]+?)"][echo "$1"]g;
# s/foo/bar/;
print;
}
When run:
for f in $(git grep -l gettext -- *.sh); do perl replace-gettext.pl $f; done
Produces output like:
@@ -351 +351 @@ split_patches () {
- clean_abort "$(eval_gettext "Patch format
\$patch_format is not supported.")"
+ clean_abort "Patch format $patch_format is
not supported."
@@ -353 +353 @@ split_patches () {
- clean_abort "$(gettext "Patch format
detection failed.")"
+ clean_abort "Patch format detection failed."
@@ -403 +403 @@ do
- die "$(gettext "-d option is no longer supported.
Do not use.")"
+ die "-d option is no longer supported. Do not use."
@@ -466 +466 @@ then
- die "$(eval_gettext "previous rebase directory \$dotest
still exists but mbox given.")"
+ die "previous rebase directory $dotest still exists but mbox given."
It would be relatively easy to hack up a basic POSIX shell
pre-processor like this that would work on our *.sh files, thus
eliminating the need for all of this fallback business.
^ permalink raw reply
* What's cooking in git.git (Jan 2012, #05; Mon, 23)
From: Junio C Hamano @ 2012-01-24 0:56 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
I had 1.7.9-rc3 planned in the Git calendar (http://tinyurl.com/gitcal)
for today, but it turns out that we didn't have embarrassing urgent
regression to fix so far up to -rc2, so I'd skip doing -rc3 and hopefully
be able to tag the final later this week.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[Graduated to "master"]
* jc/pull-signed-tag-doc (2012-01-17) 1 commit
+ pulling signed tag: add howto document
* jk/credentials (2012-01-16) 4 commits
(merged to 'next' on 2012-01-16 at 2810b82)
+ credential-cache: ignore "connection refused" errors
(merged to 'next' on 2012-01-16 at 1c6c94a)
+ unix-socket: do not let close() or chdir() clobber errno during cleanup
+ credential-cache: report more daemon connection errors
+ unix-socket: handle long socket pathnames
Minor fix-ups to the new feature.
* mh/maint-show-ref-doc (2012-01-13) 2 commits
(merged to 'next' on 2012-01-16 at 8573f09)
+ git-show-ref doc: typeset regexp in fixed width font
+ git-show-ref: fix escaping in asciidoc source
* nd/pathspec-recursion-cleanup (2012-01-16) 2 commits
(merged to 'next' on 2012-01-16 at 0189264)
+ diff-index: enable recursive pathspec matching in unpack_trees
+ Document limited recursion pathspec matching with wildcards
* tr/maint-word-diff-incomplete-line (2012-01-12) 1 commit
(merged to 'next' on 2012-01-16 at 58ddaaf)
+ word-diff: ignore '\ No newline at eof' marker
--------------------------------------------------
[New Topics]
* jl/test-pause (2012-01-17) 1 commit
(merged to 'next' on 2012-01-20 at ee56335)
+ test-lib: add the test_pause convenience function
Looked reasonable.
Will merge early in the next cycle.
* mh/ref-clone-without-extra-refs (2012-01-17) 4 commits
(merged to 'next' on 2012-01-20 at 2e9645e)
+ write_remote_refs(): create packed (rather than extra) refs
+ add_packed_ref(): new function in the refs API.
+ ref_array: keep track of whether references are sorted
+ pack_refs(): remove redundant check
Looked reasonable; will hopefully help making mh/ref-api-rest simpler and
cleaner.
Will merge early in the next cycle.
* mm/zsh-completion-regression-fix (2012-01-17) 1 commit
(merged to 'next' on 2012-01-23 at 7bc2e0a)
+ bash-completion: don't add quoted space for ZSH (fix regression)
Will merge early in the next cycle and deal with any fallout in 'master'.
* ar/i18n-no-gettext (2012-01-23) 3 commits
(merged to 'next' on 2012-01-23 at 694a94e)
+ i18n: Make NO_GETTEXT imply fallthrough scheme in shell l10n
+ add a Makefile switch to avoid gettext translation in shell scripts
+ git-sh-i18n: restructure the logic to compute gettext.sh scheme
Will merge early in the next cycle and deal with any fallout in 'master'.
* da/maint-mergetool-twoway (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at f927323)
+ mergetool: Provide an empty file when needed
Caters to GUI merge backends that cannot merge two files without
a base by giving them an empty file as a "pretend" common ancestor.
Will merge early in the next cycle and deal with any fallout in 'master'.
* jc/maint-log-first-parent-pathspec (2012-01-19) 1 commit
(merged to 'next' on 2012-01-20 at fb2b35f)
+ Making pathspec limited log play nicer with --first-parent
A bugfix.
Will merge early in the next cycle.
* ld/git-p4-branches-and-labels (2012-01-20) 5 commits
(merged to 'next' on 2012-01-23 at 9020ec4)
+ git-p4: label import fails with multiple labels at the same changelist
+ git-p4: add test for p4 labels
+ git-p4: importing labels should cope with missing owner
+ git-p4: cope with labels with empty descriptions
+ git-p4: handle p4 branches and labels containing shell chars
(this branch is used by va/git-p4-branch.)
Will merge early in the next cycle.
* va/git-p4-branch (2012-01-20) 3 commits
- git-p4: Add test case for complex branch import
- git-p4: Search for parent commit on branch creation
- git-p4: Add checkpoint() task
(this branch uses ld/git-p4-branches-and-labels.)
A handful of review comments seen.
Expecting a re-roll.
* sp/smart-http-failure-to-push (2012-01-20) 1 commit
(merged to 'next' on 2012-01-20 at a892434)
+ remote-curl: Fix push status report when all branches fail
Looked reasonable.
Will merge early in the next cycle.
* ks/sort-wildcard-in-makefile (2012-01-22) 1 commit
(merged to 'next' on 2012-01-23 at e2e0c1d)
+ t/Makefile: Use $(sort ...) explicitly where needed
Looked reasonable.
Will merge early in the next cycle.
* tr/grep-l-with-decoration (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 42b8795)
+ grep: fix -l/-L interaction with decoration lines
Looked reasonable.
Will merge early in the next cycle.
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
At least pack-objects and fsck need to learn the new encoding for the
series to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.
* mh/ref-api-rest (2011-12-12) 35 commits
. repack_without_ref(): call clear_packed_ref_cache()
. read_packed_refs(): keep track of the directory being worked in
. is_refname_available(): query only possibly-conflicting references
. refs: read loose references lazily
. read_loose_refs(): take a (ref_entry *) as argument
. struct ref_dir: store a reference to the enclosing ref_cache
. sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
. do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
. add_entry(): take (ref_entry *) instead of (ref_dir *)
. search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
. find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
. add_ref(): take (ref_entry *) instead of (ref_dir *)
. read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
. find_ref(): take (ref_entry *) instead of (ref_dir *)
. is_refname_available(): take (ref_entry *) instead of (ref_dir *)
. get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
. get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
. refs: wrap top-level ref_dirs in ref_entries
. get_ref_dir(): keep track of the current ref_dir
. do_for_each_ref(): only iterate over the subtree that was requested
. refs: sort ref_dirs lazily
. sort_ref_dir(): do not sort if already sorted
. refs: store references hierarchically
. refs.c: rename ref_array -> ref_dir
. struct ref_entry: nest the value part in a union
. check_refname_component(): return 0 for zero-length components
. free_ref_entry(): new function
. refs.c: reorder definitions more logically
. is_refname_available(): reimplement using do_for_each_ref_in_array()
. names_conflict(): simplify implementation
. names_conflict(): new function, extracted from is_refname_available()
. repack_without_ref(): reimplement using do_for_each_ref_in_array()
. do_for_each_ref_in_arrays(): new function
. do_for_each_ref_in_array(): new function
. do_for_each_ref(): correctly terminate while processesing extra_refs
I had to remove this temporarily out of 'pu' as I didn't want to deal with
merge conflicts with the mh/ref-clone-without-extra-refs topic that
removes yet another caller of add_extra_ref() that this series touches.
Will defer till the next cycle.
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
(merged to 'next' on 2012-01-05 at 954f125)
+ perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
Will defer till the next cycle.
* nd/commit-ignore-i-t-a (2012-01-16) 2 commits
- commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
- cache-tree: update API to take abitrary flags
May want to consider this as fixing an earlier UI mistake, and not as a
feature that devides the userbase.
Will defer till the next cycle.
--------------------------------------------------
[Cooking]
* jc/pull-signed-tag (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 4257553)
+ merge: use editor by default in interactive sessions
Per Linus's strong suggestion, sugarcoated (aka "taking blame for the
original UI screw-ups") so that it is easier for me to swallow and accept
a potentially huge backward incompatibility issue, "git merge" is made to
launch an editor to explain the merge in the merge commit by default in
interactive sessions.
I've updated the special-case environment variable to MERGE_AUTOEDIT that
scripts can set to "no" when they start. There is no plan to encourage
humans to keep using the historical behaviour, hence there is no support
for configuration variable (e.g. merge.autoedit) that can be set to 'no'.
Oh, also I updated the documentation a bit.
Will merge early in the next cycle and deal with any fallout in 'master'.
* nd/maint-refname-in-hierarchy-check (2012-01-11) 1 commit
(merged to 'next' on 2012-01-20 at acb5611)
+ Fix incorrect ref namespace check
Avoid getting confused by "ref/headxxx" and mistaking it as if it is under
the "refs/heads/" hierarchy.
Will merge early in the next cycle.
* jc/advise-i18n (2011-12-22) 1 commit
(merged to 'next' on 2012-01-23 at 6447013)
+ i18n of multi-line advice messages
Allow localization of advice messages that tend to be longer and
multi-line formatted. For now this is deliberately limited to advise()
interface and not vreportf() in general as touching the latter has
interactions with error() that has plumbing callers whose prefix "error: "
should never be translated.
Will merge early in the next cycle.
* rr/sequencer (2012-01-11) 2 commits
(merged to 'next' on 2012-01-23 at f349b56)
+ sequencer: factor code out of revert builtin
+ revert: prepare to move replay_action to header
Moving large chunk of code out of cherry-pick/revert for later reuse,
primarily to prepare for the next cycle.
Will merge early in the next cycle.
* tr/maint-mailinfo (2012-01-16) 2 commits
(merged to 'next' on 2012-01-20 at 278fae1)
+ mailinfo: with -b, keep space after [foo]
+ am: learn passing -b to mailinfo
Looked reasonable.
Will merge early in the next cycle.
* pw/p4-view-updates (2012-01-11) 5 commits
(merged to 'next' on 2012-01-20 at 8ca2c7b)
+ git-p4: add tests demonstrating spec overlay ambiguities
+ git-p4: adjust test to adhere to stricter useClientSpec
+ git-p4: clarify comment
+ git-p4: fix verbose comment typo
+ git-p4: only a single ... wildcard is supported
Will merge early in the next cycle.
* rs/diff-postimage-in-context (2012-01-06) 1 commit
(merged to 'next' on 2012-01-09 at 9635032)
+ xdiff: print post-image for common records instead of pre-image
Looked reasonable.
Will merge early in the next cycle and deal with any fallout in 'master'.
* cb/push-quiet (2012-01-08) 3 commits
(merged to 'next' on 2012-01-20 at 4326dda)
+ t5541: avoid TAP test miscounting
+ fix push --quiet: add 'quiet' capability to receive-pack
+ server_supports(): parse feature list more carefully
Looked reasonable.
Will merge early in the next cycle.
* nd/clone-detached (2012-01-23) 11 commits
(merged to 'next' on 2012-01-23 at bee31c6)
+ push: do not let configured foreign-vcs permanently clobbered
(merged to 'next' on 2012-01-23 at 9cab64e)
+ clone: print advice on checking out detached HEAD
+ clone: allow --branch to take a tag
+ clone: refuse to clone if --branch points to bogus ref
+ clone: --branch=<branch> always means refs/heads/<branch>
+ clone: delay cloning until after remote HEAD checking
+ clone: factor out remote ref writing
+ clone: factor out HEAD update code
+ clone: factor out checkout code
+ clone: write detached HEAD in bare repositories
+ t5601: add missing && cascade
(this branch uses nd/clone-single-branch.)
Applied a band-aid to a corner-case regression.
Will merge early in the next cycle and deal with any fallout in 'master'.
* nd/clone-single-branch (2012-01-08) 1 commit
(merged to 'next' on 2012-01-09 at 6c3c759)
+ clone: add --single-branch to fetch only one branch
(this branch is used by nd/clone-detached.)
Looked reasonable.
Will merge early in the next cycle.
* jn/gitweb-unspecified-action (2012-01-09) 1 commit
(merged to 'next' on 2012-01-20 at 2b31714)
+ gitweb: Fix actionless dispatch for non-existent objects
Looked reasonable.
Will merge early in the next cycle.
* nd/index-pack-no-recurse (2012-01-16) 3 commits
(merged to 'next' on 2012-01-20 at d1e964e)
+ index-pack: eliminate unlimited recursion in get_base_data()
+ index-pack: eliminate recursion in find_unresolved_deltas
+ Eliminate recursion in setting/clearing marks in commit list
Much better explained than the previous round.
Will merge early in the next cycle and deal with any fallout in 'master'.
* cb/git-daemon-tests (2012-01-08) 5 commits
(merged to 'next' on 2012-01-08 at 1db8351)
+ git-daemon tests: wait until daemon is ready
+ git-daemon: produce output when ready
+ git-daemon: add tests
+ dashed externals: kill children on exit
+ run-command: optionally kill children on exit
Will merge early in the next cycle.
* jk/parse-object-cached (2012-01-06) 3 commits
(merged to 'next' on 2012-01-08 at 8c6fa4a)
+ upload-pack: avoid parsing tag destinations
+ upload-pack: avoid parsing objects during ref advertisement
+ parse_object: try internal cache before reading object db
These are a bit scary changes, but I do think they are worth doing.
Will merge early in the next cycle and deal with any fallout in 'master'.
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 0:58 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Neal Kreitzinger, git, Linus Torvalds, Junio C Hamano
In-Reply-To: <41090.38.96.167.131.1327335283.squirrel@mail.lo-cal.org>
[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]
[Note: CC main authors of the code surrounding the patch]
On Mon, Jan 23, 2012 at 5:14 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>> On 1/20/2012 3:35 PM, Neal Groothuis wrote:
>>> I'm trying to find /all/ commits that change a file in the
>>> repository...and its proving to be trickier than I thought. :-)
>
> On 1/21/2012 6:16 PM, Neal Kreitzinger wrote:
>> Does git-log --all help?
>
> I don't see how it would. The commits are all reachable from HEAD, which
> would seem to be the problem that --all would correct.
>
> What I'm trying to do is find the commits in which a file differs from
> that same file in any of its parents.
If you add parent rewriting (--parent, --graph or see it in gitk, with
--full-history) you'll get your B2 commit as it adds commits to have a
meaningful history. But I don't think this is what you are asking for.
You could try the following patch (sorry for the whitespace damage,
also attatched):
Subject: [PATCH/RFC] revision: merging branches with different content
is interesting in --full-history
---
revision.c | 2 +-
t/t6016-rev-list-graph-simplify-history.sh | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 064e351..db97250 100644
--- a/revision.c
+++ b/revision.c
@@ -492,7 +492,7 @@ static void try_to_simplify_commit(struct rev_info
*revs, struct commit *commit)
}
die("bad tree compare for commit %s",
sha1_to_hex(commit->object.sha1));
}
- if (tree_changed && !tree_same)
+ if ((tree_changed && !tree_same) || (!revs->simplify_history
&& tree_changed))
return;
commit->object.flags |= TREESAME;
}
diff --git a/t/t6016-rev-list-graph-simplify-history.sh
b/t/t6016-rev-list-graph-simplify-history.sh
index f7181d1..50ffcf4 100755
--- a/t/t6016-rev-list-graph-simplify-history.sh
+++ b/t/t6016-rev-list-graph-simplify-history.sh
@@ -168,6 +168,7 @@ test_expect_success '--graph --full-history
--simplify-merges -- bar.txt' '
echo "|\\ " >> expected &&
echo "| * $C4" >> expected &&
echo "* | $A5" >> expected &&
+ echo "* | $A4" >> expected &&
echo "* | $A3" >> expected &&
echo "|/ " >> expected &&
echo "* $A2" >> expected &&
(I could rewrite the condition but I think it is cleaner).
This patch changes the semantics of --full-history to consider all
commits with at least one modified parent as an interesting commit
(even for merges). This is almost as enabling --parent:
git $ git rev-list --full-history HEAD Makefile | wc -l
1769
$ git rev-list --full-history --parents HEAD Makefile | wc -l
6732
git $ ./git rev-list --full-history HEAD Makefile | wc -l
6052
I think that --full-history should list these extra merges as you are
asking for the full history and a merge merging two branches with
different content is an interesting event in this case (full history).
But maybe we should just add an extra flag...
HTH,
Santi
[-- Attachment #2: 0001-revision-merging-branches-with-different-content-is-.patch --]
[-- Type: text/x-patch, Size: 1446 bytes --]
From 36a09f1a39212eb4b45268215cc9c336a7afebda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Santi=20B=C3=A9jar?= <santi@agolina.net>
Date: Tue, 24 Jan 2012 00:46:23 +0100
Subject: [PATCH] revision: merging branches with different content is interesting in --full-history
---
revision.c | 2 +-
t/t6016-rev-list-graph-simplify-history.sh | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 064e351..db97250 100644
--- a/revision.c
+++ b/revision.c
@@ -492,7 +492,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
}
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
}
- if (tree_changed && !tree_same)
+ if ((tree_changed && !tree_same) || (!revs->simplify_history && tree_changed))
return;
commit->object.flags |= TREESAME;
}
diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
index f7181d1..50ffcf4 100755
--- a/t/t6016-rev-list-graph-simplify-history.sh
+++ b/t/t6016-rev-list-graph-simplify-history.sh
@@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '
echo "|\\ " >> expected &&
echo "| * $C4" >> expected &&
echo "* | $A5" >> expected &&
+ echo "* | $A4" >> expected &&
echo "* | $A3" >> expected &&
echo "|/ " >> expected &&
echo "* $A2" >> expected &&
--
1.7.4.rc3.8.gd2d4
^ permalink raw reply related
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 1:15 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Neal Kreitzinger, git, Linus Torvalds, Junio C Hamano
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
On Tue, Jan 24, 2012 at 1:58 AM, Santi Béjar <santi@agolina.net> wrote:
> [Note: CC main authors of the code surrounding the patch]
>
> On Mon, Jan 23, 2012 at 5:14 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>>> On 1/20/2012 3:35 PM, Neal Groothuis wrote:
>>>> I'm trying to find /all/ commits that change a file in the
>>>> repository...and its proving to be trickier than I thought. :-)
>>
>> On 1/21/2012 6:16 PM, Neal Kreitzinger wrote:
>>> Does git-log --all help?
>>
>> I don't see how it would. The commits are all reachable from HEAD, which
>> would seem to be the problem that --all would correct.
>>
>> What I'm trying to do is find the commits in which a file differs from
>> that same file in any of its parents.
>
> If you add parent rewriting (--parent, --graph or see it in gitk, with
> --full-history) you'll get your B2 commit as it adds commits to have a
> meaningful history. But I don't think this is what you are asking for.
Note that even if it get listed, you won't get a diff for foo.txt
because it is an evil merge as the result is not the expected (using
the three way merge) one but is equal to one of the branches.
HTH,
Santi
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Linus Torvalds @ 2012-01-24 1:15 UTC (permalink / raw)
To: Santi Béjar; +Cc: Neal Groothuis, Neal Kreitzinger, git, Junio C Hamano
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
On Mon, Jan 23, 2012 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
>
> If you add parent rewriting (--parent, --graph or see it in gitk, with
> --full-history) you'll get your B2 commit as it adds commits to have a
> meaningful history. But I don't think this is what you are asking for.
>
> You could try the following patch (sorry for the whitespace damage,
> also attatched):
>
> Subject: [PATCH/RFC] revision: merging branches with different content
> is interesting in --full-history
The concept seems sane.
But please check the interaction with "--simplify-merges" too, just in
case. The merge simplification looks at TREESAME too, so I suspect
your change may break merge simplification.
Linus
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 1:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Neal Groothuis, Neal Kreitzinger, git, Junio C Hamano
In-Reply-To: <CA+55aFynLN7kBYh7i-kh+Xd1Qn-wKBePcokmJRNfe8RYA0cCZA@mail.gmail.com>
On Tue, Jan 24, 2012 at 2:15 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jan 23, 2012 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
>>
>> If you add parent rewriting (--parent, --graph or see it in gitk, with
>> --full-history) you'll get your B2 commit as it adds commits to have a
>> meaningful history. But I don't think this is what you are asking for.
>>
>> You could try the following patch (sorry for the whitespace damage,
>> also attatched):
>>
>> Subject: [PATCH/RFC] revision: merging branches with different content
>> is interesting in --full-history
>
> The concept seems sane.
>
> But please check the interaction with "--simplify-merges" too, just in
> case. The merge simplification looks at TREESAME too, so I suspect
> your change may break merge simplification.
Indeed, there is a bad interaction with --simplify-merges. If you add
--simplify-merges it not only increase the number of commit but
changes them :-(
$ ./git rev-list --full-history --simplify-merges HEAD Makefile >
rev-list.simp-merges
$ ./git rev-list --full-history HEAD Makefile > rev-list.new
$ diff rev-list.new rev-list.simp-merges -u | diffstat
rev-list.simp-merges | 1841 ++++++++++++++++++++++++++-------------------------
1 file changed, 944 insertions(+), 897 deletions(-)
Santi
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Junio C Hamano @ 2012-01-24 1:40 UTC (permalink / raw)
To: Santi Béjar; +Cc: Neal Groothuis, Neal Kreitzinger, git, Linus Torvalds
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
Santi Béjar <santi@agolina.net> writes:
> diff --git a/revision.c b/revision.c
> index 064e351..db97250 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -492,7 +492,7 @@ static void try_to_simplify_commit(struct rev_info
> *revs, struct commit *commit)
> }
> die("bad tree compare for commit %s",
> sha1_to_hex(commit->object.sha1));
> }
> - if (tree_changed && !tree_same)
> + if ((tree_changed && !tree_same) || (!revs->simplify_history
> && tree_changed))
Is that the same as saying this?
if (!(tree_same && revs->simplify_history) && tree_changed)
return;
Which reads: unless we find a parent that matches the result and we are
simplifying the history, a child different from at least one parent is
worth showing.
Which makes sort of sense at the conceptual level, but I am not sure if it
is practically useful (the same issue with --full-history that makes
complex history almost unreadable).
^ permalink raw reply
* HEAD file location
From: mfine @ 2012-01-24 3:42 UTC (permalink / raw)
To: git
I'm working on a Git project and had a question about HEAD.
In our remote Git repository, I see the file
git_repo_home/HEAD
and another file
git_repo_home/refs/heads/HEAD
The content of the former file is refs/heads/master which looks ok because
we want HEAD pointing at master.
However, should the latter file exist? I had thought only branches
should exist in /refs/heads and HEAD isn't a branch right? I'm wondering
if we erroneously created a HEAD branch.
Thanks for any help!
^ permalink raw reply
* Re: HEAD file location
From: Sitaram Chamarty @ 2012-01-24 3:52 UTC (permalink / raw)
To: mfine; +Cc: git
In-Reply-To: <loom.20120124T043119-263@post.gmane.org>
On Tue, Jan 24, 2012 at 9:12 AM, mfine <eboats@gmail.com> wrote:
> I'm working on a Git project and had a question about HEAD.
>
> In our remote Git repository, I see the file
>
> git_repo_home/HEAD
>
> and another file
>
> git_repo_home/refs/heads/HEAD
>
> The content of the former file is refs/heads/master which looks ok because
> we want HEAD pointing at master.
>
> However, should the latter file exist? I had thought only branches
> should exist in /refs/heads and HEAD isn't a branch right? I'm wondering
> if we erroneously created a HEAD branch.
Yes. Someone did something like 'git push origin HEAD:HEAD'
^ permalink raw reply
* Re: Cannot push a commit
From: Matthias Fechner @ 2012-01-24 6:53 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120119020913.GA20219@sigill.intra.peff.net>
Am 19.01.2012 03:09, schrieb Jeff King:
> Thanks for following up on this. It does seem like openssh is dropping
> your connection in a half-duplex way, though we don't know why. A bug in
> openssh sounds like a reasonable candidate...
I was now able to track the problem down to the command which is causing
the problem.
If you install git and you have tortoise-svn installed the installer
select as ssh client tortoiseplink.exe and this is the program which has
the bug.
I changed the system back to the ssh.exe which comes with the git
installer and it is working fine.
I downloaded the plink.exe (dev version) for the putty homepage and it
works fine.
If i use the tortoiseplink.exe again it fails.
Hopefully this will help some ppl to solve there problem too.
I'll start to do some tests if the same problem will raise with svn too
and I ask the tortoise-svn devs to replace the tortoiseplink.exe by a
newer version.
Thanks a lot for your help.
Bye
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Junio C Hamano @ 2012-01-24 6:59 UTC (permalink / raw)
To: Conrad Irwin; +Cc: git, Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <1327359555-29457-1-git-send-email-conrad.irwin@gmail.com>
Conrad Irwin <conrad.irwin@gmail.com> writes:
>> in order to avoid uselessly spewing garbage at you while reminding you
>> that the command is not showing the whole truth and you _might_ want to
>> look into the elided file if you wanted to with "grep -a world hello.o".
>> Compared to this, it feels that the result your patch goes too far and
>> hides the truth a bit too much to my taste. Maybe it is just me.
>
> I used to use this approach, hooking into the "diff" attribute directly to mark
> a file as binary, however that was clearly a hack.
After thinking about this a bit more, I have to say I disagree that it is
a hack.
I agree that the issue you are trying to address is real, but I think the
approach taken by the patch is flawed on three counts:
- You cannot do "grep -a" equivalent once you set your "-grep" attribute;
- The user has flexibility to set "diff" and "grep" independently, which
is an unnecessary complication [*1*]; and
- The user does not get any hint that potential hits are elided, like
normal "grep" would do.
I also think we can fix the above problems, while simplifying the external
interface visible to the end users.
So let's step back a bit and take a look at the handling of files for
which you do not want to see patch output and/or you do not want to see
grep hits, in a fictional but realisitic use scenario.
I am building a small embedded applicance that links with a binary blob
firmware, xyzzy.so, supplied by an upstream vendor, and this blob is
updated from time to time. In order to keep track of what binary blob went
into which product release, this binary blob is stored in the repository
together with the source files. Because it is useless to view binary
changes in "git log -p" output, I would naturally mark this as "binary".
Now, is it realistic to expect that I might want to see "grep" hits from
this binary blob? I do not think so [*2*].
When I say "xyzzy.so is a binary" in my .gitattributes file, according to
the current documentation, I am saying that "do not run diff, and also do
not run EOL conversion on this file" [*3*], but from the end user's point
of view, it is natural that I am entitled to expect much more than that.
Without having to know how many different kinds of textual operations the
SCM I happen to be using supports, I am telling it that I do not want to
see _any_ textual operations done on it. If a new version of "git grep"
learns to honor the attributes system, I want my "this is binary" to be
considered by the improved "git grep".
If you think about it this way from the very high level description of the
problem, aka, end user's point of view, it is fairly clear that tying the
"binary" attribute to "git grep" to allow us to override the built-in
buffer_is_binary() call you see in grep.c gives the most intuitive result,
without forcing the user to do anything more than they are already doing.
Because "binary" decomposes to "-diff" and "-text", we have two choices.
We _could_ say "-text" should be the one that overrides buffer_is_binary()
autodetection, but using "-diff" instead for that purpose opens the door
for us to give our users even more intuitive and consistent experience.
Suppose that this binary blob firmware came with an API manual formatted
in PDF, xyzzy.pdf, also supplied by the vendor. It is also kept in the
repository, but again, running textual diff between updated versions of
the PDF documentation would not be very useful. I however may have a
textconv filter defined for it to grab the text by running pdf2ascii.
Now if my "git show --textconv xyzzy.pdf" has an output line that says a
string "XYZZY API 2.0" was added to the current version, wouldn't it be
natural for me to expect that "git grep --textconv 'XYZZY API' xyzzy.pdf"
to find it [*4*]?
As an added bonus, if you truly want to omit _any_ hit from "git grep" for
your minified.js files, you can easily do so. Just define a textconv
filter that yields an empty string for them, and "grep --textconv" won't
produce any matches, not even "Binary file ... matches".
So I am inclined to think that reusing the infrastructure we already have
for the `diff` attribute as much as possible would be a better design for
this new feature you are proposing.
The name of the attribute `diff` is somewhat unfortunate, but the end user
interface to the feature at the highest level is already called "binary"
attribute (macro), and our low-level documentation can give precise
meaning of the attribute while alluding to the origin of the name so that
intelligent readers would understand it pretty easily (see attached
patch).
Besides, we already tell the users in "Marking files as binary" section to
mark them with "-diff" in the attributes file if they want their contents
treated as binary.
[Footnotes]
*1* An unused flexibility like this does nothing useful, other than
forcing the user to flip two attributes always as a pair, when one should
suffice.
*2* The essence of my previous message was "why it is insufficient to mark
them binary, i.e. uninteresting for the purpose of all textual operations
not just grep but also for diff." which was unanswered.
*3* This is because "binary" is defined as an attribute macro that expands
to "-diff -text".
*4* This also suggests that the infrastructure we already have for driving
"git diff" is a good match for "git grep". The "funcname" patterns, which
"git grep -p" already can borrow and use from "diff" infrastructure, is
another indication that using `diff` is a good match for "git grep".
Documentation/gitattributes.txt | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index a85b187..63844c4 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -388,9 +388,18 @@ Generating diff text
`diff`
^^^^^^
-The attribute `diff` affects how 'git' generates diffs for particular
-files. It can tell git whether to generate a textual patch for the path
-or to treat the path as a binary file. It can also affect what line is
+The attribute `diff` affects if `git` treats the contents of file as text
+or binary. Historically, `git diff` and its friends were the first to use
+this attribute, hence its name, but the attribute governs textual
+operations in general, including `git grep`.
+
+For `git diff` and its friends, differences in contents marked as text
+produces a textual patch, while differences in non-text are reported only
+as "Binary files differ". For `git grep`, matches in contents marked as
+text are reported by showing lines that contain them, while matches in
+non-text are reported only as "Binary file ... matches".
+
+This attribute can also affect what line is
shown on the hunk header `@@ -k,l +n,m @@` line, tell git to use an
external command to generate the diff, or ask git to convert binary
files to a text format before generating the diff.
^ permalink raw reply related
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Nguyen Thai Ngoc Duy @ 2012-01-24 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvco253xx.fsf@alter.siamese.dyndns.org>
2012/1/24 Junio C Hamano <gitster@pobox.com>:
> Recently, 6f48d39 (clone: delay cloning until after remote HEAD checking,
> 2012-01-16) tried to record if a remote helper needs to be called after
> parsing the remote when transport_get() is called, by overwriting the
> field meant to store the configured remote helper name in the remote
> structure.
>
> This is OK when a remote represents a single remote repository, but fails
> miserably when pushing to locations with multiple URLs, like this:
>
> $ cat .git/config
> [remote "origin"]
> url = https://code.google.com/p/git-htmldocs/
> url = github.com:gitster/git-htmldocs.git
> push = refs/heads/master:refs/heads/master
My bad. remote.*.vcs (or remote->foreign_vcs) is designed to override
remote helper detection based on url. Once you have pushed over https,
the following urls will be over https too. Luckily no other places
perform an operation over multiple urls like push so we're safe with
your bandage.
We should have another way to detect whether remote helper being used
(comparing some function pointers like transport->connect or
transport->disconnect may help). But I need to think a bit about
delaying cloning for http(s) too even though remote helper is used.
--
Duy
^ 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