* Re: [RFC/PATCH 0/4] textconv for show and grep
From: Junio C Hamano @ 2013-02-06 16:55 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jeff King
In-Reply-To: <cover.1360162813.git.git@drmicha.warpmail.net>
The parts for "grep" in the series makes tons of sense to me. I am
not yet convinced about the other two, though.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-02-06 17:40 UTC (permalink / raw)
To: Matthieu Moy
Cc: Junio C Hamano, Jeff King, Michal Nazarewicz, git,
Krzysztof Mazur, Michal Nazarewicz
In-Reply-To: <vpqobfxwg2q.fsf@grenoble-inp.fr>
On Wed, 06 Feb 2013 17:41:01 +0100 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
MM> Ted Zlatanov <tzz@lifelogs.com> writes:
>> - sort the output tokens (after 'url' is extracted) so the output is consistent and testable
MM> Why not, if you want to use the output of credential_write in tests. But
MM> credential_write is essentially used to talk to "git credential", so the
MM> important information is the content of the hash before credential_write
MM> and after credential_read. They are unordered, but consistent and
MM> testable.
I like testing output (especially when it's part of an API), so we
should make the externally observable output consistent and testable.
The change is tiny, just sort the keys instead of calling each(), so I
hope it makes it in the final version.
>> Yup. But what you call "read" and "write" are, to the credential
>> helper, "write" and "read" but it's the same protocol :) So maybe the
>> names should be changed to reflect that, e.g. "query" and "response."
MM> I don't think that would be a better naming. Maybe "serialize" and
MM> "parse" would be better, but "query" would sound like it establishes the
MM> connection and possibly reads the response to me.
I'm OK with anything unambiguous.
Thanks!
Ted
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: demerphq @ 2013-02-06 17:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ted Zlatanov, git, Jeff King
In-Reply-To: <7vvca5mmmt.fsf@alter.siamese.dyndns.org>
On 6 February 2013 17:29, Junio C Hamano <gitster@pobox.com> wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> - As in C (see above), we avoid using braces unnecessarily (but Perl
>> forces braces around if/unless/else/foreach blocks, so this is not
>> always possible).
>
> Is it ever (as opposed to "not always") possible to omit braces?
Only in a statement modifier.
> It sounds as if we encourage the use of statement modifiers, which
> certainly is not what I want to see.
As you mention below statement modifiers have their place. For instance
next if $whatever;
Is considered preferable to
if ($whatever) {
next;
}
Similarly
open my $fh, ">", $filename
or die "Failed to open '$filename': $!";
Is considered preferable by most Perl programmers to:
my $fh;
if ( not open $fh, ">", $filename ) {
die "Failed to open '$filename': $!";
}
> You probably would want to mention that opening braces for
> "if/else/elsif" do not sit on their own line,
> and closing braces for
> them will be followed the next "else/elseif" on the same line
> instead, but that is part of "most of the C guidelines above apply"
> so it may be redundant.
>
>> - Don't abuse statement modifiers (unless $youmust).
>
> It does not make a useful guidance to leave $youmust part
> unspecified.
>
> Incidentally, your sentence is a good example of where use of
> statement modifiers is appropriate: $youmust is rarely true.
"unless" often leads to maintenance errors as the expression gets more
complicated over time, more branches need to be added to the
statement, etc. Basically people are bad at doing De Morgans law in
their head.
> In general:
>
> ... do something ...
> do_this() unless (condition);
> ... do something else ...
>
> is easier to follow the flow of the logic than
>
> ... do something ...
> unless (condition) {
> do_this();
> }
> ... do something else ...
>
> *only* when condition is extremely rare, iow, when do_this() is
> expected to be almost always called.
if (not $condition) {
do_this();
}
Is much less error prone in terms of maintenance than
unless ($condition) {
do_this();
}
Similarly
do_this() if not $condition;
leads to less maintenance errors than
do_this() unless $condition;
So if you objective is maintainability I would just ban "unless" outright.
Cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] Update CodingGuidelines for Perl 5
From: Ted Zlatanov @ 2013-02-06 17:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvca5mmmt.fsf@alter.siamese.dyndns.org>
Update the coding guidelines for Perl 5.
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
Documentation/CodingGuidelines | 44 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 1d7de5f..951d74c 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -179,6 +179,50 @@ For C programs:
- Use Git's gettext wrappers to make the user interface
translatable. See "Marking strings for translation" in po/README.
+For Perl 5 programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - As in C (see above), we avoid using braces unnecessarily (but Perl forces
+ braces around if/unless/else/foreach blocks, so this is not always possible).
+ At least make sure braces do not sit on their own line, like with C.
+
+ - Don't abuse statement modifiers--they are discouraged. But in general:
+
+ ... do something ...
+ do_this() unless (condition);
+ ... do something else ...
+
+ should be used instead of
+
+ ... do something ...
+ unless (condition) {
+ do_this();
+ }
+ ... do something else ...
+
+ *only* when when the condition is so rare that do_this() will be called
+ almost always.
+
+ - We try to avoid assignments inside if().
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+ GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+ ;; note the first part is useful for C editing, too
+ ((nil . ((indent-tabs-mode . t)
+ (tab-width . 8)
+ (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+ (cperl-extra-newline-before-brace . nil)
+ (cperl-merge-trailing-else . t))))
+
Writing Documentation:
Every user-visible change should be reflected in the documentation.
--
1.7.9.rc2
^ permalink raw reply related
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvca5mmmt.fsf@alter.siamese.dyndns.org>
On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
JCH> Is it ever (as opposed to "not always") possible to omit braces?
Oh yes! Not that I recommend it, and I'm not even going to touch on
Perl Golf :)
JCH> It sounds as if we encourage the use of statement modifiers, which
JCH> certainly is not what I want to see.
Yup. I think I captured that in the patch, but please feel free to
revise it after applying or throw it back to me.
JCH> You probably would want to mention that opening braces for
JCH> "if/else/elsif" do not sit on their own line, and closing braces for
JCH> them will be followed the next "else/elseif" on the same line
JCH> instead, but that is part of "most of the C guidelines above apply"
JCH> so it may be redundant.
OK; done.
>> - Don't abuse statement modifiers (unless $youmust).
JCH> It does not make a useful guidance to leave $youmust part
JCH> unspecified.
JCH> Incidentally, your sentence is a good example of where use of
JCH> statement modifiers is appropriate: $youmust is rarely true.
I was trying to be funny, honestly. But OK; reworded.
Ted
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:08 UTC (permalink / raw)
To: demerphq; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <CANgJU+V5bhdpN_kWxQPEJgx24LXLtQJWRbnHwkSgm9zFwzm+fA@mail.gmail.com>
On Wed, 6 Feb 2013 18:45:56 +0100 demerphq <demerphq@gmail.com> wrote:
d> So if you objective is maintainability I would just ban "unless" outright.
Please consider me opposed to such a ban.
Ted
^ permalink raw reply
* Re: How to diff 2 file revisions with gitk
From: Johannes Sixt @ 2013-02-06 18:09 UTC (permalink / raw)
To: R. Diez; +Cc: git@vger.kernel.org
In-Reply-To: <1360166273.33888.YahooMailNeo@web171204.mail.ir2.yahoo.com>
Am 06.02.2013 16:57, schrieb R. Diez:
> I would like to start gitk, select with the mouse 2
> revisions of some file and then compare them, hopefully with an external
> diff tool, very much like I am used to with WinCVS.
>
> The closest I
> got is to start gitk with a filename as an argument, in order to
> restrict the log to that one file. Then I right-click on a commit (a
> file revision) and choose "Mark this commit". However, if I right-click
> on another commit and choose "Compare with marked commit", I get a full
> commit diff with all files, and not just the file I specified on the
> command-line arguments.
Edit->Preferences, tick 'Limit diff to listed paths'.
-- Hannes
^ permalink raw reply
* [PATCH 2/4] perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other directories
From: Matthieu Moy @ 2013-02-06 18:11 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1360174292-14793-1-git-send-email-Matthieu.Moy@imag.fr>
perl.mak uses relative path, which is OK when called from the toplevel,
but won't be anymore if one includes it from elsewhere. It is now
possible to include the file using:
GIT_ROOT_DIR=<whatever>
include $(GIT_ROOT_DIR)/perl.mak
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
perl.mak | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/perl.mak b/perl.mak
index 8bbeef3..a2b8717 100644
--- a/perl.mak
+++ b/perl.mak
@@ -1,5 +1,9 @@
# Rules to build Git commands written in perl
+ifndef GIT_ROOT_DIR
+ GIT_ROOT_DIR = .
+endif
+
ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
endif
@@ -11,12 +15,11 @@ NO_PERL = NoThanks
endif
ifndef NO_PERL
-$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
-
+$(patsubst %.perl,%,$(SCRIPT_PERL)): $(GIT_ROOT_DIR)/perl/perl.mak
-$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl GIT-VERSION-FILE
+$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl $(GIT_ROOT_DIR)/GIT-VERSION-FILE
$(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C $(GIT_ROOT_DIR)/perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e ' h' \
--
1.8.1.2.526.gf51a757
^ permalink raw reply related
* [PATCH 3/4] Makefile: factor common configuration in git-default-config.mak
From: Matthieu Moy @ 2013-02-06 18:11 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1360174292-14793-1-git-send-email-Matthieu.Moy@imag.fr>
Similarly to the extraction of perl-related code in perl.mak, we extract
general default configuration from the Makefile to make it available from
directories other than the toplevel.
This is required to make perl.mak usable because it requires $(pathsep)
to be set.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Makefile | 62 +-----------------------------------------------------
default-config.mak | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 61 deletions(-)
create mode 100644 default-config.mak
diff --git a/Makefile b/Makefile
index f39d4a9..9649a41 100644
--- a/Makefile
+++ b/Makefile
@@ -346,67 +346,7 @@ GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
-# CFLAGS and LDFLAGS are for the users to override from the command line.
-
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
-ALL_LDFLAGS = $(LDFLAGS)
-STRIP ?= strip
-
-# Among the variables below, these:
-# gitexecdir
-# template_dir
-# mandir
-# infodir
-# htmldir
-# sysconfdir
-# can be specified as a relative path some/where/else;
-# this is interpreted as relative to $(prefix) and "git" at
-# runtime figures out where they are based on the path to the executable.
-# This can help installing the suite in a relocatable way.
-
-prefix = $(HOME)
-bindir_relative = bin
-bindir = $(prefix)/$(bindir_relative)
-mandir = share/man
-infodir = share/info
-gitexecdir = libexec/git-core
-mergetoolsdir = $(gitexecdir)/mergetools
-sharedir = $(prefix)/share
-gitwebdir = $(sharedir)/gitweb
-localedir = $(sharedir)/locale
-template_dir = share/git-core/templates
-htmldir = share/doc/git-doc
-ETC_GITCONFIG = $(sysconfdir)/gitconfig
-ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
-lib = lib
-# DESTDIR =
-pathsep = :
-
-export prefix bindir sharedir sysconfdir gitwebdir localedir
-
-CC = cc
-AR = ar
-RM = rm -f
-DIFF = diff
-TAR = tar
-FIND = find
-INSTALL = install
-RPMBUILD = rpmbuild
-TCL_PATH = tclsh
-TCLTK_PATH = wish
-XGETTEXT = xgettext
-MSGFMT = msgfmt
-PTHREAD_LIBS = -lpthread
-PTHREAD_CFLAGS =
-GCOV = gcov
-
-export TCL_PATH TCLTK_PATH
-
-SPARSE_FLAGS =
-
-
+include default-config.mak
### --- END CONFIGURATION SECTION ---
diff --git a/default-config.mak b/default-config.mak
new file mode 100644
index 0000000..b2aab3d
--- /dev/null
+++ b/default-config.mak
@@ -0,0 +1,61 @@
+# CFLAGS and LDFLAGS are for the users to override from the command line.
+
+CFLAGS = -g -O2 -Wall
+LDFLAGS =
+ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
+ALL_LDFLAGS = $(LDFLAGS)
+STRIP ?= strip
+
+# Among the variables below, these:
+# gitexecdir
+# template_dir
+# mandir
+# infodir
+# htmldir
+# sysconfdir
+# can be specified as a relative path some/where/else;
+# this is interpreted as relative to $(prefix) and "git" at
+# runtime figures out where they are based on the path to the executable.
+# This can help installing the suite in a relocatable way.
+
+prefix = $(HOME)
+bindir_relative = bin
+bindir = $(prefix)/$(bindir_relative)
+mandir = share/man
+infodir = share/info
+gitexecdir = libexec/git-core
+mergetoolsdir = $(gitexecdir)/mergetools
+sharedir = $(prefix)/share
+gitwebdir = $(sharedir)/gitweb
+localedir = $(sharedir)/locale
+template_dir = share/git-core/templates
+htmldir = share/doc/git-doc
+ETC_GITCONFIG = $(sysconfdir)/gitconfig
+ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
+lib = lib
+# DESTDIR =
+pathsep = :
+
+export prefix bindir sharedir sysconfdir gitwebdir localedir
+
+CC = cc
+AR = ar
+RM = rm -f
+DIFF = diff
+TAR = tar
+FIND = find
+INSTALL = install
+RPMBUILD = rpmbuild
+TCL_PATH = tclsh
+TCLTK_PATH = wish
+XGETTEXT = xgettext
+MSGFMT = msgfmt
+PTHREAD_LIBS = -lpthread
+PTHREAD_CFLAGS =
+GCOV = gcov
+
+export TCL_PATH TCLTK_PATH
+
+SPARSE_FLAGS =
+
+
--
1.8.1.2.526.gf51a757
^ permalink raw reply related
* [PATCH 1/4] Makefile: extract perl-related rules to make them available from other dirs
From: Matthieu Moy @ 2013-02-06 18:11 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1360174292-14793-1-git-send-email-Matthieu.Moy@imag.fr>
The final goal is to make it easy to write Git commands in perl in the
contrib/ directory. It is currently possible to do so, but without the
benefits of Git's Makefile: adapt first line with $(PERL_PATH),
hardcode the path to Git.pm, ...
We make the perl-related part of the Makefile available from directories
other than the toplevel so that:
* Developers can include it, to avoid code duplication
* Users can get a consistent behavior of "make install"
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Makefile | 46 +---------------------------------------------
perl.mak | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+), 45 deletions(-)
create mode 100644 perl.mak
diff --git a/Makefile b/Makefile
index 731b6a8..f39d4a9 100644
--- a/Makefile
+++ b/Makefile
@@ -573,14 +573,10 @@ BINDIR_PROGRAMS_NO_X += git-cvsserver
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
endif
-ifndef PERL_PATH
- PERL_PATH = /usr/bin/perl
-endif
ifndef PYTHON_PATH
PYTHON_PATH = /usr/bin/python
endif
-export PERL_PATH
export PYTHON_PATH
LIB_FILE = libgit.a
@@ -1441,10 +1437,6 @@ ifeq ($(TCLTK_PATH),)
NO_TCLTK = NoThanks
endif
-ifeq ($(PERL_PATH),)
-NO_PERL = NoThanks
-endif
-
ifeq ($(PYTHON_PATH),)
NO_PYTHON = NoThanks
endif
@@ -1522,7 +1514,6 @@ prefix_SQ = $(subst ','\'',$(prefix))
gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
-PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
DIFF_SQ = $(subst ','\'',$(DIFF))
@@ -1715,9 +1706,6 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
$(QUIET_GEN)$(cmd_munge_script) && \
mv $@+ $@
-ifndef NO_PERL
-$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
-
perl/perl.mak: perl/PM.stamp
perl/PM.stamp: FORCE
@@ -1728,39 +1716,7 @@ perl/PM.stamp: FORCE
perl/perl.mak: GIT-CFLAGS GIT-PREFIX perl/Makefile perl/Makefile.PL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
-$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl GIT-VERSION-FILE
- $(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
- sed -e '1{' \
- -e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
- -e ' h' \
- -e ' s=.*=use lib (split(/$(pathsep)/, $$ENV{GITPERLLIB} || "'"$$INSTLIBDIR"'"));=' \
- -e ' H' \
- -e ' x' \
- -e '}' \
- -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.perl >$@+ && \
- chmod +x $@+ && \
- mv $@+ $@
-
-
-.PHONY: gitweb
-gitweb:
- $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) all
-
-git-instaweb: git-instaweb.sh gitweb GIT-SCRIPT-DEFINES
- $(QUIET_GEN)$(cmd_munge_script) && \
- chmod +x $@+ && \
- mv $@+ $@
-else # NO_PERL
-$(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
- $(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
- -e 's|@@REASON@@|NO_PERL=$(NO_PERL)|g' \
- unimplemented.sh >$@+ && \
- chmod +x $@+ && \
- mv $@+ $@
-endif # NO_PERL
+include perl.mak
ifndef NO_PYTHON
$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS
diff --git a/perl.mak b/perl.mak
new file mode 100644
index 0000000..8bbeef3
--- /dev/null
+++ b/perl.mak
@@ -0,0 +1,49 @@
+# Rules to build Git commands written in perl
+
+ifndef PERL_PATH
+ PERL_PATH = /usr/bin/perl
+endif
+export PERL_PATH
+PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
+
+ifeq ($(PERL_PATH),)
+NO_PERL = NoThanks
+endif
+
+ifndef NO_PERL
+$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
+
+
+$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl GIT-VERSION-FILE
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
+ sed -e '1{' \
+ -e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e ' h' \
+ -e ' s=.*=use lib (split(/$(pathsep)/, $$ENV{GITPERLLIB} || "'"$$INSTLIBDIR"'"));=' \
+ -e ' H' \
+ -e ' x' \
+ -e '}' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ $@.perl >$@+ && \
+ chmod +x $@+ && \
+ mv $@+ $@
+
+
+.PHONY: gitweb
+gitweb:
+ $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) all
+
+git-instaweb: git-instaweb.sh gitweb GIT-SCRIPT-DEFINES
+ $(QUIET_GEN)$(cmd_munge_script) && \
+ chmod +x $@+ && \
+ mv $@+ $@
+else # NO_PERL
+$(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's|@@REASON@@|NO_PERL=$(NO_PERL)|g' \
+ unimplemented.sh >$@+ && \
+ chmod +x $@+ && \
+ mv $@+ $@
+endif # NO_PERL
--
1.8.1.2.526.gf51a757
^ permalink raw reply related
* [PATCH 0/4] Allow contrib/ to use Git's Makefile for perl code
From: Matthieu Moy @ 2013-02-06 18:11 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpqobfxwg2q.fsf@grenoble-inp.fr>
The very final goal is to be able to move painlessly (credential) code
from git-remote-mediawiki to Git.pm, but then it's nice for the user
to be able to say just "cd contrib/mw-to-git && make install" and let
the Makefile set perl's library path just like other Git commands
written in perl.
This series does this while trying to minimize code duplication, and
to make it easy for future other tools in contrib to do the same.
Matthieu Moy (4):
Makefile: extract perl-related rules to make them available from other
dirs
perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other
directories
Makefile: factor common configuration in git-default-config.mak
git-remote-mediawiki: use Git's Makefile to build the script
Makefile | 108 +--------------------
contrib/mw-to-git/.gitignore | 1 +
contrib/mw-to-git/Makefile | 45 ++++++---
...-remote-mediawiki => git-remote-mediawiki.perl} | 0
default-config.mak | 61 ++++++++++++
perl.mak | 52 ++++++++++
6 files changed, 145 insertions(+), 122 deletions(-)
create mode 100644 contrib/mw-to-git/.gitignore
rename contrib/mw-to-git/{git-remote-mediawiki => git-remote-mediawiki.perl} (100%)
create mode 100644 default-config.mak
create mode 100644 perl.mak
--
1.8.1.2.526.gf51a757
^ permalink raw reply
* [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Matthieu Moy @ 2013-02-06 18:11 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1360174292-14793-1-git-send-email-Matthieu.Moy@imag.fr>
The configuration of the install directory is not reused from the
toplevel Makefile: we assume Git is already built, hence just call
"git --exec-path". This avoids too much surgery in the toplevel Makefile.
git-remote-mediawiki.perl can now "use Git;".
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/.gitignore | 1 +
contrib/mw-to-git/Makefile | 45 ++++++++++++++--------
...-remote-mediawiki => git-remote-mediawiki.perl} | 0
3 files changed, 30 insertions(+), 16 deletions(-)
create mode 100644 contrib/mw-to-git/.gitignore
rename contrib/mw-to-git/{git-remote-mediawiki => git-remote-mediawiki.perl} (100%)
diff --git a/contrib/mw-to-git/.gitignore b/contrib/mw-to-git/.gitignore
new file mode 100644
index 0000000..b919655
--- /dev/null
+++ b/contrib/mw-to-git/.gitignore
@@ -0,0 +1 @@
+git-remote-mediawiki
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index 3ed728b..ed8073b 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -8,40 +8,53 @@
#
## Build git-remote-mediawiki
--include ../../config.mak.autogen
--include ../../config.mak
+all:
+
+GIT_ROOT_DIR=../../
+include $(GIT_ROOT_DIR)/default-config.mak
+-include $(GIT_ROOT_DIR)/config.mak.autogen
+-include $(GIT_ROOT_DIR)/config.mak
+-include $(GIT_ROOT_DIR)/GIT-VERSION-FILE
+
+
+SCRIPT_PERL = git-remote-mediawiki.perl
+ALL_PROGRAMS = $(patsubst %.perl,%,$(SCRIPT_PERL))
+
+include $(GIT_ROOT_DIR)/perl.mak
-ifndef PERL_PATH
- PERL_PATH = /usr/bin/perl
-endif
ifndef gitexecdir
gitexecdir = $(shell git --exec-path)
endif
-PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
-gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
-SCRIPT = git-remote-mediawiki
+ifneq ($(filter /%,$(firstword $(gitexecdir))),)
+gitexec_instdir = $(gitexecdir)
+else
+gitexec_instdir = $(prefix)/$(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
.PHONY: install help doc test clean
help:
@echo 'This is the help target of the Makefile. Current configuration:'
- @echo ' gitexecdir = $(gitexecdir_SQ)'
+ @echo ' gitexec_instdir = $(gitexec_instdir_SQ)'
@echo ' PERL_PATH = $(PERL_PATH_SQ)'
- @echo 'Run "$(MAKE) install" to install $(SCRIPT) in gitexecdir'
+ @echo 'Run "$(MAKE) all" to build the script'
+ @echo 'Run "$(MAKE) install" to install $(ALL_PROGRAMS) in gitexec_instdir'
@echo 'Run "$(MAKE) test" to run the testsuite'
-install:
- sed -e '1s|#!.*/perl|#!$(PERL_PATH_SQ)|' $(SCRIPT) \
- > '$(gitexecdir_SQ)/$(SCRIPT)'
- chmod +x '$(gitexecdir)/$(SCRIPT)'
+all: $(ALL_PROGRAMS)
+
+install: $(ALL_PROGRAMS)
+ $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
doc:
- @echo 'Sorry, "make doc" is not implemented yet for $(SCRIPT)'
+ @echo 'Sorry, "make doc" is not implemented yet for $(ALL_PROGRAMS)'
test:
$(MAKE) -C t/ test
clean:
- $(RM) '$(gitexecdir)/$(SCRIPT)'
+ $(RM) $(ALL_PROGRAMS)
+ $(RM) $(patsubst %,$(gitexec_instdir)/%,/$(ALL_PROGRAMS))
$(MAKE) -C t/ clean
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki.perl
similarity index 100%
rename from contrib/mw-to-git/git-remote-mediawiki
rename to contrib/mw-to-git/git-remote-mediawiki.perl
--
1.8.1.2.526.gf51a757
^ permalink raw reply related
* Re: CodingGuidelines Perl amendment
From: Junio C Hamano @ 2013-02-06 18:14 UTC (permalink / raw)
To: demerphq; +Cc: Ted Zlatanov, git, Jeff King
In-Reply-To: <CANgJU+V5bhdpN_kWxQPEJgx24LXLtQJWRbnHwkSgm9zFwzm+fA@mail.gmail.com>
demerphq <demerphq@gmail.com> writes:
> As you mention below statement modifiers have their place. For instance
>
> next if $whatever;
>
> Is considered preferable to
>
> if ($whatever) {
> next;
> }
>
> Similarly
>
> open my $fh, ">", $filename
> or die "Failed to open '$filename': $!";
>
> Is considered preferable by most Perl programmers to:
>
> my $fh;
> if ( not open $fh, ">", $filename ) {
> die "Failed to open '$filename': $!";
> }
Yeah, and that is for the same reason. When you are trying to get a
birds-eye view of the codeflow, the former makes it clear that "we
do something, and then we open, and then we ...", without letting
the error handling (which also is rare case) distract us.
> "unless" often leads to maintenance errors as the expression gets more
> complicated over time,...
That might also be true, but my comment was not an endorsement for
(or suggestion against) use of unless. I was commenting on
statement modifiers, which some people tend to overuse (or abuse)
and make the resulting code harder to follow.
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Junio C Hamano @ 2013-02-06 18:16 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: git, Jeff King
In-Reply-To: <87vca5gvx6.fsf@lifelogs.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>
> Oh yes! Not that I recommend it, and I'm not even going to touch on
> Perl Golf :)
>
> JCH> It sounds as if we encourage the use of statement modifiers, which
> JCH> certainly is not what I want to see.
>
> Yup. I think I captured that in the patch, but please feel free to
> revise it after applying or throw it back to me.
I'd suggest to just drop that "try to write without braces" entirely.
> JCH> Incidentally, your sentence is a good example of where use of
> JCH> statement modifiers is appropriate: $youmust is rarely true.
>
> I was trying to be funny, honestly. But OK; reworded.
It wasn't a useful guidance, but it _was_ funny.
^ permalink raw reply
* Announcement of git-remote-gcrypt (A custom encrypted remote format)
From: Ulrik Sverdrup @ 2013-02-06 18:19 UTC (permalink / raw)
To: git
Hi,
git-remote-gcrypt is a remote helper for git that (ab)uses this format
to make it possible to push, pull and clone directly to and from a
custom encrypted repository format. Available from::
https://github.com/blake2-ppc/git-remote-gcrypt
It is relatively simple, and hopefully the protocol is sound and
secure; it uses GPG and allows multiple participants to possibly
collaborate using an untrusted and even public host. The git-on-git
backend is experimental and probably buggy, but it works.
The format intentionally targets mainly dumb hosts such as various
bulk storage providers and therefore there is nothing smart about the
protocol; when fetching we can do no better than downloading every new
packfile.
I hope it interests someone, and maybe it even reaches the target of
being both usable and secure. It also helps me if you point out
if/how/why it is broken(!).
-ulrik
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: demerphq @ 2013-02-06 18:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ted Zlatanov, git, Jeff King
In-Reply-To: <7vip65cnt3.fsf@alter.siamese.dyndns.org>
On 6 February 2013 19:14, Junio C Hamano <gitster@pobox.com> wrote:
> demerphq <demerphq@gmail.com> writes:
>
>> As you mention below statement modifiers have their place. For instance
>>
>> next if $whatever;
>>
>> Is considered preferable to
>>
>> if ($whatever) {
>> next;
>> }
>>
>> Similarly
>>
>> open my $fh, ">", $filename
>> or die "Failed to open '$filename': $!";
>>
>> Is considered preferable by most Perl programmers to:
>>
>> my $fh;
>> if ( not open $fh, ">", $filename ) {
>> die "Failed to open '$filename': $!";
>> }
>
> Yeah, and that is for the same reason. When you are trying to get a
> birds-eye view of the codeflow, the former makes it clear that "we
> do something, and then we open, and then we ...", without letting
> the error handling (which also is rare case) distract us.
perldoc perlstyle has language which explains this well if you want to
crib a description from somewhere.
>> "unless" often leads to maintenance errors as the expression gets more
>> complicated over time,...
>
> That might also be true, but my comment was not an endorsement for
> (or suggestion against) use of unless. I was commenting on
> statement modifiers, which some people tend to overuse (or abuse)
> and make the resulting code harder to follow.
That's also my point about unless. They tend to get abused and then
lead to maint devs making errors, and people misunderstanding the
code. The only time that unless IMO is "ok" (ish) is when it really is
a very simple statement. As soon as it mentions more than one var it
should be converted to an if. This applies even more so to the
modifier form.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: demerphq @ 2013-02-06 18:25 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <87vca5gvx6.fsf@lifelogs.com>
On 6 February 2013 19:05, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>
> Oh yes! Not that I recommend it, and I'm not even going to touch on
> Perl Golf :)
I think you are wrong. Can you provide an example?
Larry specifically wanted to avoid the "dangling else" problem that C
suffers from, and made it so that blocks are mandatory. The only
exception is statement modifiers, which are not only allowed to omit
the braces but also the parens on the condition.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vehgtcnpm.fsf@alter.siamese.dyndns.org>
On Wed, 06 Feb 2013 10:16:21 -0800 Junio C Hamano <gitster@pobox.com> wrote:
JCH> I'd suggest to just drop that "try to write without braces" entirely.
OK, I'll do it on the reroll, or you can just make the change directly.
I agree it was not going anywhere :)
Ted
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 951d74c..857f4e2 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -187,10 +187,6 @@ For Perl 5 programs:
- use strict and use warnings are strongly preferred.
- - As in C (see above), we avoid using braces unnecessarily (but Perl forces
- braces around if/unless/else/foreach blocks, so this is not always possible).
- At least make sure braces do not sit on their own line, like with C.
-
- Don't abuse statement modifiers--they are discouraged. But in general:
... do something ...
^ permalink raw reply related
* What's cooking in git.git (Feb 2013, #03; Wed, 6)
From: Junio C Hamano @ 2013-02-06 18:29 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'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of this month.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* ft/transport-report-segv (2013-01-31) 1 commit
(merged to 'next' on 2013-02-02 at 6c450a7)
+ push: fix segfault when HEAD points nowhere
A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer when showing an error message.
* jc/fake-ancestor-with-non-blobs (2013-01-31) 3 commits
(merged to 'next' on 2013-02-02 at 86d457a)
+ apply: diagnose incomplete submodule object name better
+ apply: simplify build_fake_ancestor()
+ git-am: record full index line in the patch used while rebasing
(this branch is used by jc/extended-fake-ancestor-for-gitlink.)
Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
* jn/auto-depend-workaround-buggy-ccache (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at db5940a)
+ Makefile: explicitly set target name for autogenerated dependencies
An age-old workaround to prevent buggy versions of ccache from
breaking the auto-generation of dependencies, which unfortunately
is still relevant because some people use ancient distros.
* sb/gpg-plug-fd-leak (2013-01-31) 1 commit
(merged to 'next' on 2013-02-02 at c271a31)
+ gpg: close stderr once finished with it in verify_signed_buffer()
We forgot to close the file descriptor reading from "gpg" output,
killing "git log --show-signature" on a long history.
* ta/doc-no-small-caps (2013-02-01) 6 commits
(merged to 'next' on 2013-02-02 at 77cbd0e)
+ Documentation: StGit is the right spelling, not StGIT
+ Documentation: describe the "repository" in repository-layout
+ Documentation: add a description for 'gitfile' to glossary
+ Documentation: do not use undefined terms git-dir and git-file
+ Documentation: the name of the system is 'Git', not 'git'
+ Documentation: avoid poor-man's small caps GIT
Update documentation to change "GIT" which was a poor-man's small
caps to "Git". The latter was the intended spelling.
Also change "git" spelled in all-lowercase to "Git" when it refers
to the system as the whole or the concept it embodies, as opposed to
the command the end users would type.
--------------------------------------------------
[New Topics]
* jc/extended-fake-ancestor-for-gitlink (2013-02-05) 1 commit
- apply: verify submodule commit object name better
Instead of requiring the full 40-hex object names on the index
line, we can read submodule commit object names from the textual
diff when synthesizing a fake ancestore tree for "git am -3".
Will merge to 'next'.
* tz/credential-authinfo (2013-02-05) 1 commit
- Add contrib/credentials/netrc with GPG support
A new read-only credential helper (in contrib/) to interact with
the .netrc/.authinfo files. Hopefully mn/send-email-authinfo topic
can rebuild on top of something like this.
Waiting for further reviews.
* jx/utf8-printf-width (2013-02-05) 1 commit
- Add utf8_fprintf helper which returns correct columns
Use a new helper that prints a message and counts its display width
to align the help messages parse-options produces.
--------------------------------------------------
[Stalled]
* mn/send-email-authinfo (2013-01-29) 1 commit
- git-send-email: add ~/.authinfo parsing
This triggered a subtopic to add a credential helper for
authinfo/netrc files (with or without GPG encryption), but nobody
seems to be working on connecting send-email to the credential
framework.
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
Expecting a follow-up to add tests.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
--------------------------------------------------
[Cooking]
* dg/subtree-fixes (2013-02-05) 6 commits
- contrib/subtree: make the manual directory if needed
- contrib/subtree: honor DESTDIR
- contrib/subtree: fix synopsis
- contrib/subtree: better error handling for 'subtree add'
- contrib/subtree: use %B for split subject/body
- contrib/subtree: remove test number comments
contrib/subtree updates, but here are only the ones that looked
ready to be merged to 'next'. For the remainder, they will have
another day.
Will merge to 'next'.
* jl/submodule-deinit (2013-02-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Will merge to 'next'.
* ct/autoconf-htmldir (2013-02-02) 1 commit
(merged to 'next' on 2013-02-05 at bba4f8c)
+ Honor configure's htmldir switch
The autoconf subsystem passed --mandir down to generated
config.mak.autogen but forgot to do the same for --htmldir.
Will merge to 'master'.
* mk/tcsh-complete-only-known-paths (2013-02-03) 1 commit
(merged to 'next' on 2013-02-05 at 4409b08)
+ completion: handle path completion and colon for tcsh script
(this branch uses mp/complete-paths.)
Manlio's "complete with known paths only" update to completion
scripts returns directory names without trailing slash to
compensate the addition of '/' done by bash that reads from our
completion result. tcsh completion code that reads from our
internal completion result does not add '/', so let it ask our
complletion code to keep the '/' at the end.
Will merge to 'master'.
* jc/combine-diff-many-parents (2013-02-05) 2 commits
(merged to 'next' on 2013-02-05 at e382aa6)
+ t4038: add tests for "diff --cc --raw <trees>"
+ combine-diff: lift 32-way limit of combined diff
We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
Will merge to 'master'.
* jc/remove-export-from-config-mak-in (2013-02-03) 1 commit
- config.mak.in: remove unused definitions
config.mak.in template had an "export" line to cause a few
common makefile variables to be exported; if they need to be
expoted for autoconf/configure users, they should also be exported
for people who write config.mak the same way. Move the "export" to
the main Makefile.
* jk/apply-similaritly-parsing (2013-02-03) 1 commit
(merged to 'next' on 2013-02-05 at ccf1c97)
+ builtin/apply: tighten (dis)similarity index parsing
Make sure the similarity value shown in the "apply --summary"
output is sensible, even when the input had a bogus value.
Will merge to 'master'.
* nd/status-show-in-progress (2013-02-05) 1 commit
- status: show the branch name if possible in in-progress info
Will merge to 'next'.
* sb/gpg-i18n (2013-01-31) 1 commit
(merged to 'next' on 2013-02-02 at 7a54574)
+ gpg: allow translation of more error messages
Will merge to 'master'.
* sb/run-command-fd-error-reporting (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at be7e970)
+ run-command: be more informative about what failed
Will merge to 'master'.
* jk/remote-helpers-doc (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at ce1461a)
+ Rename {git- => git}remote-helpers.txt
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
Will merge to 'master'.
* sp/smart-http-content-type-check (2013-02-06) 3 commits
(merged to 'next' on 2013-02-06 at 8bc6434)
+ http_request: reset "type" strbuf before adding
(merged to 'next' on 2013-02-05 at 157812c)
+ t5551: fix expected error output
(merged to 'next' on 2013-02-04 at d0759cb)
+ Verify Content-Type from smart HTTP servers
The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit
- doc: mention tracking for pull.default
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.
This is my "don't list it to catch readers' eyes, but make sure it
can be found if the reader looks for it" version; I'm not married
to the layout and will be happy to take a replacement patch.
Waiting for couter-proposal patches.
* jk/doc-makefile-cleanup (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at 86ff373)
+ Documentation/Makefile: clean up MAN*_TXT lists
Will merge to 'master'.
* ab/gitweb-use-same-scheme (2013-01-28) 1 commit
(merged to 'next' on 2013-02-02 at 7e4a108)
+ gitweb: refer to picon/gravatar images over the same scheme
Avoid mixed contents on a page coming via http and https when
gitweb is hosted on a https server.
Will merge to 'master'.
* jk/python-styles (2013-01-30) 1 commit
(merged to 'next' on 2013-02-02 at 293edc1)
+ CodingGuidelines: add Python coding guidelines
Will merge to 'master'.
* mp/complete-paths (2013-01-11) 1 commit
(merged to 'next' on 2013-01-30 at 70e4f1a)
+ git-completion.bash: add support for path completion
(this branch is used by mk/tcsh-complete-only-known-paths.)
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
This is logically the right thing to do, and we would really love
to see people who have been involved in completion code to review
and comment on the implementation.
Will cook in 'next' to see if anybody screams.
* ss/mergetools-tortoise (2013-02-01) 2 commits
(merged to 'next' on 2013-02-03 at d306b83)
+ mergetools: teach tortoisemerge to handle filenames with SP correctly
+ mergetools: support TortoiseGitMerge
Update mergetools to work better with newer merge helper tortoise ships.
Will merge to 'master'.
* da/mergetool-docs (2013-02-02) 5 commits
(merged to 'next' on 2013-02-03 at f822dcf)
+ doc: generate a list of valid merge tools
+ mergetool--lib: list user configured tools in '--tool-help'
+ mergetool--lib: add functions for finding available tools
+ mergetool--lib: improve the help text in guess_merge_tool()
+ mergetool--lib: simplify command expressions
(this branch uses jk/mergetool.)
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
Will merge to 'master'.
* nd/branch-error-cases (2013-01-31) 6 commits
(merged to 'next' on 2013-02-02 at cf5e745)
+ branch: let branch filters imply --list
+ docs: clarify git-branch --list behavior
+ branch: mark more strings for translation
+ Merge branch 'nd/edit-branch-desc-while-detached' into HEAD
+ branch: give a more helpful message on redundant arguments
+ branch: reject -D/-d without branch name
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
Will merge to 'master'.
* jk/mergetool (2013-01-28) 8 commits
(merged to 'next' on 2013-02-03 at 2ff5dee)
+ mergetools: simplify how we handle "vim" and "defaults"
+ mergetool--lib: don't call "exit" in setup_tool
+ mergetool--lib: improve show_tool_help() output
+ mergetools/vim: remove redundant diff command
+ git-difftool: use git-mergetool--lib for "--tool-help"
+ git-mergetool: don't hardcode 'mergetool' in show_tool_help
+ git-mergetool: remove redundant assignment
+ git-mergetool: move show_tool_help to mergetool--lib
(this branch is used by da/mergetool-docs.)
Cleans up mergetool/difftool combo.
Will merge to 'master'.
* jc/hidden-refs (2013-01-30) 7 commits
- fetch: fetch objects by their exact SHA-1 object names
- upload-pack: optionally allow fetching from the tips of hidden refs
- fetch: use struct ref to represent refs to be fetched
- parse_fetch_refspec(): clarify the codeflow a bit
- upload/receive-pack: allow hiding ref hierarchies
- upload-pack: simplify request validation
- upload-pack: share more code
Allow the server side to unclutter the refs/ namespace it shows to
the client. Optionally allow requests for histories leading to the
tips of hidden refs by updated clients.
Need to split the configuration into three (one for sending, one
for receiving, and then another to cover both for convenience)
before this topic can go forward. Perhaps people involved in the
review cycle can help.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will cook in 'next'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* bc/append-signed-off-by (2013-01-27) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Waiting for the final round of reroll before merging to 'next'.
After that we will go incremental.
^ permalink raw reply
* Re: Bug in "git log --graph -p -m" (version 1.7.7.6)
From: Matthieu Moy @ 2013-02-06 18:33 UTC (permalink / raw)
To: John Keeping; +Cc: Dale R. Worley, gitster, git
In-Reply-To: <20130206151447.GZ1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> I would argue that the line should start with "| | ", since it really is
> just a continuation of the same commit.
>
> | |
> | | commit a393ed598e9fb11436f85bd58f1a38c82f2cadb7 (from 33e70e70c0173d634826b998bdc304f93c0966b8)
> | | Merge: 2c1e6a3 33e70e7
> | | Author: Matthieu Moy <Matthieu.Moy@imag.fr>
> | | Date: Tue Feb 5 22:05:33 2013 +0100
Yes.
I had a look at the code, I guess the call to graph_show_commit() in
show_log() (in log-tree.c) should have called graph_show_padding() but
didn't in this case. Then I got lost in graph.c :-(.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:35 UTC (permalink / raw)
To: demerphq; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <CANgJU+VbkQ+xa+_sSAu-3pMe+6gycHi9J4VR18M5YJt=pa9QUw@mail.gmail.com>
On Wed, 6 Feb 2013 19:25:43 +0100 demerphq <demerphq@gmail.com> wrote:
d> On 6 February 2013 19:05, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>>
JCH> Is it ever (as opposed to "not always") possible to omit braces?
>>
>> Oh yes! Not that I recommend it, and I'm not even going to touch on
>> Perl Golf :)
d> I think you are wrong. Can you provide an example?
d> Larry specifically wanted to avoid the "dangling else" problem that C
d> suffers from, and made it so that blocks are mandatory. The only
d> exception is statement modifiers, which are not only allowed to omit
d> the braces but also the parens on the condition.
Oh, perhaps I didn't state it correctly. You can avoid braces, but not
if you want to use if/elsif/else/unless/etc. which require them:
condition && do_this();
condition || do_this();
condition ? do_this() : do_that();
(and others I can't recall right now)
But my point was only that it's always possible to get around these
artificial restrictions; it's more important to ask for legible sensible
code. Sorry if that was unclear!
Ted
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: demerphq @ 2013-02-06 18:44 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <87ip65guj8.fsf@lifelogs.com>
On 6 February 2013 19:35, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 6 Feb 2013 19:25:43 +0100 demerphq <demerphq@gmail.com> wrote:
>
> d> On 6 February 2013 19:05, Ted Zlatanov <tzz@lifelogs.com> wrote:
>>> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>>>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>>>
>>> Oh yes! Not that I recommend it, and I'm not even going to touch on
>>> Perl Golf :)
>
> d> I think you are wrong. Can you provide an example?
>
> d> Larry specifically wanted to avoid the "dangling else" problem that C
> d> suffers from, and made it so that blocks are mandatory. The only
> d> exception is statement modifiers, which are not only allowed to omit
> d> the braces but also the parens on the condition.
>
> Oh, perhaps I didn't state it correctly. You can avoid braces, but not
> if you want to use if/elsif/else/unless/etc. which require them:
>
> condition && do_this();
> condition || do_this();
> condition ? do_this() : do_that();
>
> (and others I can't recall right now)
>
> But my point was only that it's always possible to get around these
> artificial restrictions; it's more important to ask for legible sensible
> code. Sorry if that was unclear!
Ah ok. Right, at a low level:
if (condition) { do_this() }
is identical to
condition && do_this();
IOW, Perl allows logical operators to act as control flow statements.
I hope your document include something that says that using logical
operators as control flow statements should be used sparingly, and
generally should be restricted to low precedence operators and should
never involve more than one operator.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:54 UTC (permalink / raw)
To: demerphq; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <CANgJU+X=Bb=ncqOxsd1hZDWsnFkt-bJw=Zbtuz8_KC0gO-dLaQ@mail.gmail.com>
On Wed, 6 Feb 2013 19:44:16 +0100 demerphq <demerphq@gmail.com> wrote:
d> Ah ok. Right, at a low level:
d> if (condition) { do_this() }
d> is identical to
d> condition && do_this();
d> IOW, Perl allows logical operators to act as control flow statements.
d> I hope your document include something that says that using logical
d> operators as control flow statements should be used sparingly, and
d> generally should be restricted to low precedence operators and should
d> never involve more than one operator.
I'd stay away from wording it so tightly, but instead just say
"Make your code readable and sensible, and don't try to be clever."
But this is good C and shell advice too, so I'd put it under "General
Guidelines" and leave it for Junio to decide if it's appropriate.
Ted
^ permalink raw reply
* Re: [PATCH v3 0/8] Hiding refs
From: Junio C Hamano @ 2013-02-06 19:17 UTC (permalink / raw)
To: Duy Nguyen
Cc: Michael Haggerty, Jonathan Nieder, git, Jeff King, Shawn Pearce
In-Reply-To: <CACsJy8BhL4qDb8BgOVuaUFF_9GXvgu55urYyKqPuZMZCTCoLwA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Hiderefs creates a "dark" corner of a remote git repo that can hold
>> arbitrary content that is impossible for anybody to discover but
>> nevertheless possible for anybody to download (if they know the name of
>> a hidden reference). In earlier versions of the patch series I believe
>> that it was possible to push to a hidden reference hierarchy, which made
>> it possible to upload dark content. The new version appears (from the
>> code) to prohibit adding references in a hidden hierarchy, which would
>> close the main loophole that I was worried about. But the documentation
>> and the unit tests only explicitly say that updates and deletes are
>> prohibited; nothing is said about adding references (unless "update" is
>> understood to include "add"). I think the true behavior should be
>> clarified and tested.
>>
>> I was worried that somehow this "dark" content could be used for
>> malicious purposes; for example, pushing compromised code then
>> convincing somebody to download it by SHA1 with the implicit argument
>> "it's safe since it comes directly from the project's official
>> repository". If it is indeed impossible to populate the dark namespace
>> remotely then I can't think of a way to exploit it.
>
> Or you can think hiderefs is the first step to addressing the
> initial ref advertisment problem. The series says hidden refs are
> to be fetched out of band, but that's not the only way.
Let me help unconfuse this thread.
I think the series as 8-patch series was poorly presented, and
separating it into two will help understanding what they are about.
The first three:
upload-pack: share more code
upload-pack: simplify request validation
upload/receive-pack: allow hiding ref hierarchies
is _the_ topic of the series. As far as I am concerned (I am not
speaking for Gerrit users, but am speaking as the Git maintainer),
the topic is solely about uncluttering. There may be refs that the
server end may need to keep for its operation, but that remote users
have _no_ business knowing about. Allowing the server to keep these
refs in the repository, while not showing these refs over the wire,
is the problem the series solves.
In other words, it is not about "these are *usually* not wanted by
clients, so do not show them by default". It is about "these are
not to be shown, ever".
OK?
Now, there may be some refs that are not *usually* wanted by clients
but there may be cases where clients want to
(1) learn about them via the same protocol; and/or
(2) fetch them over the protocol.
If you want to solve both of these two issues generally, the
solution has to involve a separate protocol from the today's
protocol. It would go like this:
* The upload-pack-2 service sits on a port different from today's,
waits for a ls-remote/fetch/clone client to connect to it, makes
a default advertisement that only includes the refs that are
usually wanted by clients with hints on what other refs the
initial advertisement omitted, to let the client know that it is
allowed to ask for them.
* An updated client, if it sees that some refs are omitted from the
initial advertisement *and* what the user told it to fetch or
list may be one of the omitted ones (this is why the server gives
hints in the previous step in the first step; when the server
says it did not omit anything, or when it says it omitted only
refs/pull/*, a client that wanted to fetch refs/heads/frotz will
know the request will fail without continuing this step), then
makes a "expand-refs" request to the server, asking for the refs
it did not see and the server could supply.
* When the server sees "expand-refs", it responds with additional
advertisement. "expand-refs refs/pull/*" may result in listing
of all refs in that hierarchy. "expand-refs refs/changes/1/1"
would result in listing that single ref. "expand-refs no-such"
may result in nothing, indicating an error.
* After the (possible) expand-refs exchange, the client knows
exactly the same and necessary information as the current
protocol gives it in order to go to the common ancestor discovery
step, and the protocol can continue the same way as the current
protocol.
Note that this cannot sit on the current port in general, as
existing clients will not be able to tell some refs are not
advertised, so unless you are hiding large and truly unused part of
the refspace, interoperability with older clients will render the
mechanism useless. You cannot use this to delay the refs/tags/
hierarchy with this mechanism and have older client come to the
updated service that by default does not advertise tags, for
example.
The above is what I called the "delayed advertisement" in the
discussion, which was brought up several months ago but nothing
materialized as the result. People who are interested in pursuing
this can volunteer and start discussing the design refinements now
and submit implementation for reviews.
But in the meantime, if there is a niche use case where a solution
to only the second problem is sufficient (and Gerrit and GitHub pull
requests could both be such use cases), the remainder of the series
can help, without waiting the solution to solve "usually not wanted
but may need to be learned" problem. That is the latter 4 patches
(the very last one is a demonstration to illustrate why allowing a
push to hidden ref hierarchy would not and should not work, and is
not for application):
parse_fetch_refspec(): clarify the codeflow a bit
fetch: use struct ref to represent refs to be fetched
upload-pack: optionally allow fetching from the tips of hidden refs
fetch: fetch objects by their exact SHA-1 object names
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #03; Wed, 6)
From: Jens Lehmann @ 2013-02-06 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8v71cn3m.fsf@alter.siamese.dyndns.org>
Am 06.02.2013 19:29, schrieb Junio C Hamano:
> * jl/submodule-deinit (2013-02-04) 1 commit
> - submodule: add 'deinit' command
>
> There was no Porcelain way to say "I no longer am interested in
> this submodule", once you express your interest in a submodule with
> "submodule init". "submodule deinit" is the way to do so.
>
> Will merge to 'next'.
Oops, I though you were waiting for a reroll. Currently I'm having the
appended interdiff compared to your version. Changes are:
- Add deinit to the --force documentation of "git submodule"
- Never remove submodules containing a .git dir, even when forced
- diagnostic output when "rm -rf" or "mkdir" fails
- More test cases
And I wanted to add three more test cases for modified submodules before
sending v4. You could squash in the first two hunks into the commit you
have in pu and I'll send a follow up patch with the extra tests soon or
you could wait for me sending an updated patch. What do you think?
---------------8<------------------
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7a149eb..45ee12b 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -227,8 +227,10 @@ OPTIONS
-f::
--force::
- This option is only valid for add and update commands.
+ This option is only valid for add, deinit and update commands.
When running add, allow adding an otherwise ignored submodule path.
+ When running deinit the submodule work trees will be removed even if
+ they contain local changes.
When running update, throw away local changes in submodules when
switching to a different commit; and always run a checkout operation
in the submodule, even if the commit listed in the index of the
diff --git a/git-submodule.sh b/git-submodule.sh
index f05b597..365c6de 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -595,14 +595,25 @@ cmd_deinit()
continue
fi
- # Remove the submodule work tree
- if test -z "$force"
+ # Remove the submodule work tree (unless the user already did it)
+ if test -d "$sm_path"
then
- git rm -n "$sm_path" ||
- die "$(eval_gettext "Submodule work tree $sm_path contains local modifications, use '-f' to discard them")"
+ # Protect submodules containing a .git directory
+ if test -d "$sm_path/.git"
+ then
+ echo >&2 "$(eval_gettext "Submodule work tree $sm_path contains a .git directory")"
+ die "$(eval_gettext "(use 'rm -rf' if you really want to remove it including all of its history)")"
+ fi
+
+ if test -z "$force"
+ then
+ git rm -n "$sm_path" ||
+ die "$(eval_gettext "Submodule work tree $sm_path contains local modifications, use '-f' to discard them")"
+ fi
+ rm -rf "$sm_path" || say "$(eval_gettext "Could not remove submodule work tree '\$sm_path'")"
fi
- rm -rf "$sm_path"
- mkdir "$sm_path"
+
+ mkdir "$sm_path" || say "$(eval_gettext "Could not create empty submodule directory '\$sm_path'")"
# Remove the whole section so we have a clean state when the
# user later decides to init this submodule again
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 34d8274..0567f1a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -757,20 +757,46 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
)
'
+test_expect_success 'set up a second submodule' '
+ git submodule add ./init2 example2 &&
+ git commit -m "submodle example2 added"
+'
+
test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '
git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
git submodule deinit init &&
test -z "$(git config submodule.example.url)" &&
- test -z "$(git config submodule.example.foo)"
+ test -z "$(git config submodule.example.foo)" &&
+ test -n "$(git config submodule.example2.url)" &&
+ test -n "$(git config submodule.example2.frotz)" &&
+ rmdir init
'
test_expect_success 'submodule deinit . deinits all initialized submodules' '
git submodule update --init &&
git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
test_must_fail git submodule deinit &&
git submodule deinit . &&
test -z "$(git config submodule.example.url)" &&
- test -z "$(git config submodule.example.foo)"
+ test -z "$(git config submodule.example.foo)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ test -z "$(git config submodule.example2.frotz)" &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit deinits a submodule when its work tree is missing or empty' '
+ git submodule update --init &&
+ rm -rf init example2/* example2/.git &&
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ git submodule deinit init example2 &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example.foo)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ test -z "$(git config submodule.example2.frotz)" &&
+ rmdir init
'
test_expect_success 'submodule deinit complains when explicitly used on an uninitialized submodule' '
@@ -778,7 +804,24 @@ test_expect_success 'submodule deinit complains when explicitly used on an unini
git submodule deinit init >actual &&
test_i18ngrep "Submodule .example. (.*) unregistered for path .init" actual
git submodule deinit init >actual &&
- test_i18ngrep "No url found for submodule path .init. in .git/config" actual
+ test_i18ngrep "No url found for submodule path .init. in .git/config" actual &&
+ git submodule deinit . >actual &&
+ test_i18ngrep "Submodule .example2. (.*) unregistered for path .example2" actual
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit fails when submodule has a .git directory even when forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ rm .git &&
+ cp -R ../.git/modules/example .git &&
+ GIT_WORK_TREE=. git config --unset core.worktree
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test_must_fail git submodule deinit -f init &&
+ test -d init/.git &&
+ test -n "$(git config submodule.example.url)"
'
test_done
^ permalink raw reply related
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