* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Junio C Hamano @ 2012-01-23 18:33 UTC (permalink / raw)
To: conrad.irwin; +Cc: git, Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <4f1d2a8b.a2d8320a.50ec.576d@mx.google.com>
conrad.irwin@gmail.com writes:
> ---8<---
>
> To set -grep on an file in .gitattributes will cause that file to be
> skipped completely while grepping. This can be used to reduce the number
> of false positives when your repository contains files that are
> uninteresting to you, for example test fixtures, dlls or minified source
> code.
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.
Plain "grep" does this:
$ grep world hello.*
hello.c: printf("Hello, world.\n");
Binary file hello.o matches
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.
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.
Your "attributes only" is not an acceptable solution in the longer run,
even though it is a good first step (i.e. "attributes first and other
enhancement later"). There should be an easy way to get the best of both
worlds.
> The other approach considered was to allow an --exclude flag to grep at
> runtime, however that better serves the less common use-case of wanting
> to customise the list of files per-invocation rather than statically.
I doubt that it is justifiable to call per-invocation "the less common".
By the way, if the uninteresting ones are dll and minified.js, I wonder
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.
I am *not* going to ask why they are treated as source and tracked by git
to begin with.
^ permalink raw reply
* Re: What does "modified" in git status mean?
From: Phillip Susi @ 2012-01-23 20:07 UTC (permalink / raw)
To: Mikolas; +Cc: git
In-Reply-To: <loom.20120122T174204-274@post.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/22/2012 11:57 AM, Mikolas wrote:
> I am using git version 1.7.5.1 under cygwin and I'm getting
> behavior that I'm not understanding.
>
> When I do 'git status' in the root directory of the repository, it
> shows no difference. Once I cd to a subdirectory, it starts showing
> modifications. However, 'git diff' shows nothing.
>
> So it looks something like this: $ git status # On branch master
> nothing to commit (working directory clean)
>
> $ cd foo $ git status # On branch master # Changes not staged for
> commit: # (use "git add <file>..." to update what will be
> committed) # (use "git checkout -- <file>..." to discard changes
> in working directory) # # modified: ../foo/bar
>
> $ git diff $
>
> I put the following in my gitconfig but that doesn't seem to be
> doing much. [core] trustctime = false autocrlf = input
autocrlf is basically broken, don't use it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPHb4EAAoJEJrBOlT6nu75NmsIALPYuRTdGPLigxmiAWfH4e/i
d516AR8AgkWtJzK3TbaD2HxgnQK9dmWYysppT7WR2SetrBrpsEUvQnw0b3jUewkb
lL97cEcDfiYbKXnkpfHRtAawUIXhrQeT/8XpOrvc7d8wPCWt4Zd7hrLo3TTuBGmN
tQcJtUqPwxreUYWOR5dPMV3oaeclptavEoeGc+2BlTiAuti6aw89G7lRvgVZQDGr
y0uCL4QIyOuMU9xUaeiFm/pCqY5MWSTs6Nv3mnAiw6PwK+aR1OcUkJjRw6dM6xWY
7futPNLEph8fptltaLhzMoeSzct3vNd+Al7synmOTh8bGitJeyaiCZOR55CG/eY=
=i8Zy
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: make install rewrites source files
From: Junio C Hamano @ 2012-01-23 20:15 UTC (permalink / raw)
To: Hallvard Breien Furuseth; +Cc: git
In-Reply-To: <hbf.20120123bz2f@bombur.uio.no>
Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> writes:
> INSTALL says we can install a profiled Git with
> $ make profile-all
> # make install prefix=...
> This does not work...
We should just drop prefix=... from that line, as the "prefix=value must
be the same while building and installing" is not only about the "profile"
build but applies to any other build.
I however wonder why you would need a separate profile-install target,
though. Shouldn't
$ make foo-build && make install
install a funky 'foo' variant of the build for any supported value of
'foo'?
^ permalink raw reply
* Re: make install rewrites source files
From: Phillip Susi @ 2012-01-23 20:28 UTC (permalink / raw)
To: Hallvard Breien Furuseth; +Cc: git
In-Reply-To: <hbf.20120123bz2f@bombur.uio.no>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/23/2012 9:18 AM, Hallvard Breien Furuseth wrote:
> INSTALL says we can install a profiled Git with $ make profile-all
> # make install prefix=...
prefix should be an argument to configure, not make.
> This does not work: 'make install' notices that the build flags
> has changed and rebuilds Git - presumably without using the profile
> info. The patch below fixes this.
make install implicitly includes make all; it is supposed to rebuild
anything that needs rebuilt.
> However, make install should not write to the source directory in
> any case. That fails as root if root lacks write access there, due
> to NFS mounts that map root to nobody etc. At least git-instaweb
> and GIT-BUILD-OPTIONS are rewritten. You can simulate this with su
> nobody -s /bin/bash -c 'make -k install' after configuring with
> prefix=<directory owned by nobody>.
If you want to build locally from a read only nfs mount, then you
should run the configure script in a local directory:
mkdir /tmp/build
cd /tmp/build
/path/to/nfs/source/configure
make
make install
> Index: Makefile --- Makefile~ 2012-01-19 01:36:02.000000000 +0100
> +++ Makefile 2012-01-23 14:44:56.554980323 +0100
Hrm... Makefile should itself be a generated file from Makefile.in or
Makefile.am, but it appears that git isn't doing this. Perhaps that
should be fixed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPHcL3AAoJEJrBOlT6nu759U8IANCtJDWnCizSDWrJAFWe3ISr
FemiFgW347qjLcWlJS036nPfKnrxrJ88rF2e9+8Tj/hfPojNwCmyvN7rz+guI0uA
qqOfk9uN38Qd/jwfW5gv/7raKP4eUyRZ9ioptX3NqQtP5Co4TFuajOfswpN8f/DL
QiU7os62Df5HWW2U8A3XT9KiU9oWRala8dcrp5EJkEOfYDvQG2o3e1N/D91KC4el
lAyVEnzrvoLr5NzHCnFe7dQqvAB2S3PE/NP4anZHyNRp3SDLu1iZbD9MKC21Bd3n
BmCn9Vh7U+reC/NBMq8qaM69jLRk2Dx12brFoyY5/cjdQuaLj+n6h1nN9MqSKYI=
=/qLy
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: make install rewrites source files
From: Junio C Hamano @ 2012-01-23 20:52 UTC (permalink / raw)
To: Phillip Susi; +Cc: Hallvard Breien Furuseth, git
In-Reply-To: <4F1DC2F7.2070502@ubuntu.com>
Phillip Susi <psusi@ubuntu.com> writes:
> On 1/23/2012 9:18 AM, Hallvard Breien Furuseth wrote:
>> INSTALL says we can install a profiled Git with $ make profile-all
>> # make install prefix=...
>
> prefix should be an argument to configure, not make.
What are you talking about? Use of ./configure is entirely optional, and
our Makefile _does_ support giving prefix on the command line.
^ permalink raw reply
* Re: make install rewrites source files
From: Hallvard Breien Furuseth @ 2012-01-23 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhazm89bo.fsf@alter.siamese.dyndns.org>
On Mon, 23 Jan 2012 12:15:07 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> writes:
>
>> INSTALL says we can install a profiled Git with
>> $ make profile-all
>> # make install prefix=...
>> This does not work...
>
> We should just drop prefix=... from that line, as the "prefix=value must
> be the same while building and installing" is not only about the "profile"
> build but applies to any other build.
Either add or remove a prefix so they match, yes. Fine by me either way.
> I however wonder why you would need a separate profile-install target,
> though. Shouldn't
>
> $ make foo-build && make install
>
> install a funky 'foo' variant of the build for any supported value of
> 'foo'?
'profile-all' makes 'all' with different CFLAGS from those in
Makefile. 'install' makes 'all' which notices CFLAGS has changed
since last build, so it rebuilds:
$ make install
* new build flags or prefix
...
That's also how the 2nd '$(MAKE) ... all' in profile-all can tell
that it should do anything. Thus my new 'profile-install:' target
with the same flags as the final $(MAKE) in profile-all.
This looks way too clever to me. 'make' can detect that flags have
changed, but should then fail (optionally?) instead of rebuilding.
That'd likely solve my issue with other files rewritten as root too.
But I'm not volunteering to rewrite your build system.
BTW, it'd be useful to split up 'profile-all' so it is possible
to ignore 'make test' failure and compilete the build anyway:
.PHONY: profile-all profile-clean profile-gen profile-use profile-install
profile-all: profile-clean profile-gen profile-use
profile-gen:
$(MAKE) CFLAGS="$(PROFILE_GEN_CFLAGS)" all
$(MAKE) CFLAGS="$(PROFILE_GEN_CFLAGS)" -j1 test
profile-use:
$(MAKE) CFLAGS="$(PROFILE_USE_CFLAGS)" all
--
Hallvard
^ permalink raw reply
* Re: [PATCH] add a Makefile switch to avoid gettext translation in shell scripts
From: Junio C Hamano @ 2012-01-23 22:01 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Ævar Arnfjörð Bjarmason,
Jonathan Nieder
In-Reply-To: <20120119195222.GA5011@blimp.dmz>
Alex Riesen <raa.lkml@gmail.com> writes:
> 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.
> For instance, on this particular system, a Cygwin installations gettext
> produces no output whatsoever.
>
> In case the users of these systems are unable or not interested in fixing
> them, setting the new Makefile switch should help:
>
> USE_FALLTHROUGH_GETTEXT_SCHEME=yes
>
> This will replace the translation routines with fallthrough versions, which
> currently used only for regression testing.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
I'll split this into two, the first one only to restructure the code and
the guts of this one that avoids the autodetection.
Also I'd rename this so that:
$ make USE_GETTEXT_SCHEME=fallthrough
$ make USE_GETTEXT_SCHEME=gnu
could be used to avoid extra and unnecessary runtime overhead when the
person building git knows what is on the system.
^ permalink raw reply
* [PATCH 1/2] git-sh-i18n: restructure the logic to compute gettext.sh scheme
From: Junio C Hamano @ 2012-01-23 22:02 UTC (permalink / raw)
To: Git Mailing List
Cc: Alex Riesen, Ævar Arnfjörð Bjarmason,
Jonathan Nieder
In-Reply-To: <7v1uqq84es.fsf@alter.siamese.dyndns.org>
Instead of having a single long and complex chain of commands to decide
what to do and carry out the decision, split the code so that we first
decide which scheme to use, and in the second section define what exactly
is done by the chosen scheme. It makes the code much easier to follow and
update.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-sh-i18n.sh | 103 +++++++++++++++++++++++++++-----------------------------
1 files changed, 50 insertions(+), 53 deletions(-)
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index b4575fb..6648bd3 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -16,61 +16,45 @@ else
fi
export TEXTDOMAINDIR
-if test -z "$GIT_GETTEXT_POISON"
+# First decide what scheme to use...
+GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
+if test -n "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
+then
+ : no probing necessary
+elif test -n "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
- then
- # This is GNU libintl's gettext.sh, we don't need to do anything
- # else than setting up the environment and loading gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Try to use libintl's gettext.sh, or fall back to English if we
- # can't.
- . gettext.sh
-
- elif test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" = "-h"
- then
- # We don't have gettext.sh, but there's a gettext binary in our
- # path. This is probably Solaris or something like it which has a
- # gettext implementation that isn't GNU libintl.
- GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Solaris has a gettext(1) but no eval_gettext(1)
- eval_gettext () {
- gettext "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
-
- else
- # Since gettext.sh isn't available we'll have to define our own
- # dummy pass-through functions.
-
- # Tell our tests that we don't have the real gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- gettext () {
- printf "%s" "$1"
- }
-
- eval_gettext () {
- printf "%s" "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
- fi
-else
- # Emit garbage under GETTEXT_POISON=YesPlease. Unlike the C tests
- # this relies on an environment variable
-
GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
+elif type gettext.sh >/dev/null 2>&1
+then
+ # GNU libintl's gettext.sh
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
+elif test "$(gettext -h 2>&1)" = "-h"
+then
+ # gettext binary exists but no gettext.sh. likely to be a gettext
+ # binary on a Solaris or something that is not GNU libintl and
+ # lack eval_gettext.
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gettext_without_eval_gettext
+fi
+export GIT_INTERNAL_GETTEXT_SH_SCHEME
+# ... and then follow that decision.
+case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
+gnu)
+ # Use libintl's gettext.sh, or fall back to English if we can't.
+ . gettext.sh
+ ;;
+gettext_without_eval_gettext)
+ # Solaris has a gettext(1) but no eval_gettext(1)
+ eval_gettext () {
+ gettext "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+poison)
+ # Emit garbage so that tests that incorrectly rely on translatable
+ # strings will fail.
gettext () {
printf "%s" "# GETTEXT POISON #"
}
@@ -78,7 +62,20 @@ else
eval_gettext () {
printf "%s" "# GETTEXT POISON #"
}
-fi
+ ;;
+*)
+ gettext () {
+ printf "%s" "$1"
+ }
+
+ eval_gettext () {
+ printf "%s" "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+esac
# Git-specific wrapper functions
gettextln () {
--
1.7.9.rc2.48.g92994
^ permalink raw reply related
* [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
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