Re: [PATCH 6/7] build: make clean should not remove configure-generated files
On 07/19/2012 08:56 AM, Matthieu Moy wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: for example, an autotools old-timer that has run: ./configure --prefix /opt/git in the past, without running make distclean afterwards, would expect a make install issued after a make clean to rebuild and install git in '/opt/git'; I've been hit by that behavior once. Thanks for fixing it. The patch looks good. Should I add Acked-by: Matthieu Moy then? (Sorry if it's a dumb question, but I'm not sure which the preferred policy is around here). Thanks, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] autoconf: GIT_CONF_APPEND_LINE - GIT_CONF_SUBST
On 07/19/2012 02:13 AM, Junio C Hamano wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
The new name fits better with the macro signature, and underlines the
similarities with the autoconf-provided macro AC_SUBST (which will be
made even more pronounced in planned future commits).
Once again, no semantic change is intended, and indeed no change to the
generated configure script is expected.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index 14c7960..789926f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,10 +3,10 @@
## Definitions of private macros.
-# GIT_CONF_APPEND_LINE(LINE)
+# GIT_CONF_SUBST(LINE)
I see that [PATCH 1/7] needs to be updated so that it describes the
new two-argument form of GIT_CONF_APPEND_LINE(VAR, VAL), and this
patch needs to be updated for GIT_CONF_SUBST() with the same.
Oops, you're right. I will fix that in the re-roll.
# --
# Append LINE to file ${config_append}
Also the description definitely wants to be updated; it is no longer
LINEness that matters.
Other than that, 1 2 looked very nice and sensible.
Thanks!
Regards,
Stefano
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] build: make clean should not remove configure-generated files
Stefano Lattarini stefano.lattar...@gmail.com writes: Should I add Acked-by: Matthieu Moy then? (Sorry if it's a dumb question, but I'm not sure which the preferred policy is around here). Not necessarily needed if the patch is not otherwise controversial. The email discussions are usually sufficient for that. I'd say you may add it if you need to resend. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] build system: support automatic reconfiguration for autotools user
Except for miniscule nits in the the bottom two, I didn't find anything objectionable---nicely done. Thanks. Here is the re-roll, which should address all the reported nits. Stefano Lattarini (7): autoconf: GIT_CONF_APPEND_LINE: change signature autoconf: GIT_CONF_APPEND_LINE - GIT_CONF_SUBST autoconf: remove some redundant shell indirections autoconf: remove few redundant semicolons autoconf: use AC_CONFIG_COMMANDS instead of ad-hoc 'config.mak.append' build: make clean should not remove configure-generated files build: reconfigure automatically if configure.ac changes Makefile | 17 +++-- configure.ac | 56 +++- 2 files changed, 46 insertions(+), 27 deletions(-) -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] autoconf: GIT_CONF_APPEND_LINE: change signature
From:
GIT_CONF_APPEND_LINE([VAR=VAL])
to:
GIT_CONF_APPEND_LINE([VAR], [VAL])
This is only a preparatory change in view of future refactorings.
No semantic change is intended. In fact, the generated configure
file doesn't change at all.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4e9012f..5f63269 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,11 +3,11 @@
## Definitions of private macros.
-# GIT_CONF_APPEND_LINE(LINE)
-# --
-# Append LINE to file ${config_append}
+# GIT_CONF_APPEND_LINE(VAL, VAR)
+# --
+# Append the line VAR=VAL to file ${config_append}
AC_DEFUN([GIT_CONF_APPEND_LINE],
- [echo $1 ${config_append}])
+ [echo $1=$2 ${config_append}])
# GIT_ARG_SET_PATH(PROGRAM)
# -
@@ -34,8 +34,8 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
if test -n $2; then
GIT_UC_PROGRAM[]_PATH=$withval
AC_MSG_NOTICE([Disabling use of ${PROGRAM}])
- GIT_CONF_APPEND_LINE(NO_${PROGRAM}=YesPlease)
- GIT_CONF_APPEND_LINE(${PROGRAM}_PATH=)
+ GIT_CONF_APPEND_LINE([NO_${PROGRAM}], [YesPlease])
+ GIT_CONF_APPEND_LINE([${PROGRAM}_PATH], [])
else
AC_MSG_ERROR([You cannot use git without $1])
fi
@@ -45,7 +45,7 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
else
GIT_UC_PROGRAM[]_PATH=$withval
AC_MSG_NOTICE([Setting GIT_UC_PROGRAM[]_PATH to $withval])
- GIT_CONF_APPEND_LINE(${PROGRAM}_PATH=$withval)
+ GIT_CONF_APPEND_LINE([${PROGRAM}_PATH], [$withval])
fi
fi
m4_popdef([GIT_UC_PROGRAM])])
@@ -67,7 +67,7 @@ AC_DEFUN([GIT_PARSE_WITH],
NO_[]GIT_UC_PACKAGE=
GIT_UC_PACKAGE[]DIR=$withval
AC_MSG_NOTICE([Setting GIT_UC_PACKAGE[]DIR to $withval])
- GIT_CONF_APPEND_LINE(${PACKAGE}DIR=$withval)
+ GIT_CONF_APPEND_LINE([${PACKAGE}DIR], [$withval])
fi
m4_popdef([GIT_UC_PACKAGE])])
@@ -87,7 +87,7 @@ AC_DEFUN([GIT_PARSE_WITH_SET_MAKE_VAR],
[a value for $1 ($2). Maybe you do...?])
fi
AC_MSG_NOTICE([Setting $2 to $withval])
- GIT_CONF_APPEND_LINE($2=$withval)
+ GIT_CONF_APPEND_LINE([$2], [$withval])
fi)])# GIT_PARSE_WITH_SET_MAKE_VAR
#
@@ -150,7 +150,7 @@ AC_ARG_WITH([sane-tool-path],
else
AC_MSG_NOTICE([Setting SANE_TOOL_PATH to '$withval'])
fi
- GIT_CONF_APPEND_LINE([SANE_TOOL_PATH=$withval])],
+ GIT_CONF_APPEND_LINE([SANE_TOOL_PATH], [$withval])],
[# If the --with-sane-tool-path option was not given, don't touch
# SANE_TOOL_PATH here, but let defaults in Makefile take care of it.
# This should minimize spurious differences in the behaviour of the
@@ -169,7 +169,7 @@ AC_ARG_WITH([lib],
else
lib=$withval
AC_MSG_NOTICE([Setting lib to '$lib'])
- GIT_CONF_APPEND_LINE(lib=$withval)
+ GIT_CONF_APPEND_LINE([lib], [$withval])
fi])
if test -z $lib; then
@@ -205,7 +205,7 @@ AC_ARG_ENABLE([jsmin],
[
JSMIN=$enableval;
AC_MSG_NOTICE([Setting JSMIN to '$JSMIN' to enable JavaScript minifying])
- GIT_CONF_APPEND_LINE(JSMIN=$enableval);
+ GIT_CONF_APPEND_LINE([JSMIN], [$enableval]);
])
# Define option to enable CSS minification
@@ -215,7 +215,7 @@ AC_ARG_ENABLE([cssmin],
[
CSSMIN=$enableval;
AC_MSG_NOTICE([Setting CSSMIN to '$CSSMIN' to enable CSS minifying])
- GIT_CONF_APPEND_LINE(CSSMIN=$enableval);
+ GIT_CONF_APPEND_LINE([CSSMIN], [$enableval]);
])
## Site configuration (override autodetection)
@@ -256,7 +256,7 @@ AS_HELP_STRING([], [ARG can be also prefix for
libpcre library and hea
USE_LIBPCRE=YesPlease
LIBPCREDIR=$withval
AC_MSG_NOTICE([Setting LIBPCREDIR to $withval])
- GIT_CONF_APPEND_LINE(LIBPCREDIR=$withval)
+ GIT_CONF_APPEND_LINE([LIBPCREDIR], [$withval])
fi)
#
# Define NO_CURL if you do not have curl installed. git-http-pull and
--
1.7.10.2.1067.g553d16e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] autoconf: GIT_CONF_APPEND_LINE - GIT_CONF_SUBST
The new name fits better with the macro signature, and underlines the
similarities with the autoconf-provided macro AC_SUBST (which will be
made even more pronounced in planned future commits).
Once again, no semantic change is intended, and indeed no change to the
generated configure script is expected.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5f63269..02b9a49 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,8 +3,8 @@
## Definitions of private macros.
-# GIT_CONF_APPEND_LINE(VAL, VAR)
-# --
+# GIT_CONF_SUBST(VAL, VAR)
+#
# Append the line VAR=VAL to file ${config_append}
AC_DEFUN([GIT_CONF_APPEND_LINE],
[echo $1=$2 ${config_append}])
@@ -34,8 +34,8 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
if test -n $2; then
GIT_UC_PROGRAM[]_PATH=$withval
AC_MSG_NOTICE([Disabling use of ${PROGRAM}])
- GIT_CONF_APPEND_LINE([NO_${PROGRAM}], [YesPlease])
- GIT_CONF_APPEND_LINE([${PROGRAM}_PATH], [])
+ GIT_CONF_SUBST([NO_${PROGRAM}], [YesPlease])
+ GIT_CONF_SUBST([${PROGRAM}_PATH], [])
else
AC_MSG_ERROR([You cannot use git without $1])
fi
@@ -45,7 +45,7 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
else
GIT_UC_PROGRAM[]_PATH=$withval
AC_MSG_NOTICE([Setting GIT_UC_PROGRAM[]_PATH to $withval])
- GIT_CONF_APPEND_LINE([${PROGRAM}_PATH], [$withval])
+ GIT_CONF_SUBST([${PROGRAM}_PATH], [$withval])
fi
fi
m4_popdef([GIT_UC_PROGRAM])])
@@ -67,7 +67,7 @@ AC_DEFUN([GIT_PARSE_WITH],
NO_[]GIT_UC_PACKAGE=
GIT_UC_PACKAGE[]DIR=$withval
AC_MSG_NOTICE([Setting GIT_UC_PACKAGE[]DIR to $withval])
- GIT_CONF_APPEND_LINE([${PACKAGE}DIR], [$withval])
+ GIT_CONF_SUBST([${PACKAGE}DIR], [$withval])
fi
m4_popdef([GIT_UC_PACKAGE])])
@@ -87,7 +87,7 @@ AC_DEFUN([GIT_PARSE_WITH_SET_MAKE_VAR],
[a value for $1 ($2). Maybe you do...?])
fi
AC_MSG_NOTICE([Setting $2 to $withval])
- GIT_CONF_APPEND_LINE([$2], [$withval])
+ GIT_CONF_SUBST([$2], [$withval])
fi)])# GIT_PARSE_WITH_SET_MAKE_VAR
#
@@ -150,7 +150,7 @@ AC_ARG_WITH([sane-tool-path],
else
AC_MSG_NOTICE([Setting SANE_TOOL_PATH to '$withval'])
fi
- GIT_CONF_APPEND_LINE([SANE_TOOL_PATH], [$withval])],
+ GIT_CONF_SUBST([SANE_TOOL_PATH], [$withval])],
[# If the --with-sane-tool-path option was not given, don't touch
# SANE_TOOL_PATH here, but let defaults in Makefile take care of it.
# This should minimize spurious differences in the behaviour of the
@@ -169,7 +169,7 @@ AC_ARG_WITH([lib],
else
lib=$withval
AC_MSG_NOTICE([Setting lib to '$lib'])
- GIT_CONF_APPEND_LINE([lib], [$withval])
+ GIT_CONF_SUBST([lib], [$withval])
fi])
if test -z $lib; then
@@ -205,7 +205,7 @@ AC_ARG_ENABLE([jsmin],
[
JSMIN=$enableval;
AC_MSG_NOTICE([Setting JSMIN to '$JSMIN' to enable JavaScript minifying])
- GIT_CONF_APPEND_LINE([JSMIN], [$enableval]);
+ GIT_CONF_SUBST([JSMIN], [$enableval]);
])
# Define option to enable CSS minification
@@ -215,7 +215,7 @@ AC_ARG_ENABLE([cssmin],
[
CSSMIN=$enableval;
AC_MSG_NOTICE([Setting CSSMIN to '$CSSMIN' to enable CSS minifying])
- GIT_CONF_APPEND_LINE([CSSMIN], [$enableval]);
+ GIT_CONF_SUBST([CSSMIN], [$enableval]);
])
## Site configuration (override autodetection)
@@ -256,7 +256,7 @@ AS_HELP_STRING([], [ARG can be also prefix for
libpcre library and hea
USE_LIBPCRE=YesPlease
LIBPCREDIR=$withval
AC_MSG_NOTICE([Setting LIBPCREDIR to $withval])
- GIT_CONF_APPEND_LINE([LIBPCREDIR], [$withval])
+ GIT_CONF_SUBST([LIBPCREDIR], [$withval])
fi)
#
# Define NO_CURL if you do not have curl installed. git-http-pull and
--
1.7.10.2.1067.g553d16e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] autoconf: remove some redundant shell indirections
They are merely useless now, but would get in the way of future changes.
No semantic change is intended.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 02b9a49..200776f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -29,13 +29,12 @@ AC_DEFUN([GIT_ARG_SET_PATH],
# --without-PROGRAM is used.
AC_DEFUN([GIT_CONF_APPEND_PATH],
[m4_pushdef([GIT_UC_PROGRAM], m4_toupper([$1]))dnl
-PROGRAM=GIT_UC_PROGRAM
if test $withval = no; then
if test -n $2; then
GIT_UC_PROGRAM[]_PATH=$withval
- AC_MSG_NOTICE([Disabling use of ${PROGRAM}])
- GIT_CONF_SUBST([NO_${PROGRAM}], [YesPlease])
- GIT_CONF_SUBST([${PROGRAM}_PATH], [])
+ AC_MSG_NOTICE([Disabling use of GIT_UC_PROGRAM])
+ GIT_CONF_SUBST([NO_]GIT_UC_PROGRAM, [YesPlease])
+ GIT_CONF_SUBST(GIT_UC_PROGRAM[]_PATH, [])
else
AC_MSG_ERROR([You cannot use git without $1])
fi
@@ -45,7 +44,7 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
else
GIT_UC_PROGRAM[]_PATH=$withval
AC_MSG_NOTICE([Setting GIT_UC_PROGRAM[]_PATH to $withval])
- GIT_CONF_SUBST([${PROGRAM}_PATH], [$withval])
+ GIT_CONF_SUBST(GIT_UC_PROGRAM[]_PATH, [$withval])
fi
fi
m4_popdef([GIT_UC_PROGRAM])])
@@ -58,7 +57,6 @@ AC_DEFUN([GIT_CONF_APPEND_PATH],
# * Unset NO_PACKAGE for --with-PACKAGE without ARG
AC_DEFUN([GIT_PARSE_WITH],
[m4_pushdef([GIT_UC_PACKAGE], m4_toupper([$1]))dnl
-PACKAGE=GIT_UC_PACKAGE
if test $withval = no; then
NO_[]GIT_UC_PACKAGE=YesPlease
elif test $withval = yes; then
@@ -67,7 +65,7 @@ AC_DEFUN([GIT_PARSE_WITH],
NO_[]GIT_UC_PACKAGE=
GIT_UC_PACKAGE[]DIR=$withval
AC_MSG_NOTICE([Setting GIT_UC_PACKAGE[]DIR to $withval])
- GIT_CONF_SUBST([${PACKAGE}DIR], [$withval])
+ GIT_CONF_SUBST(GIT_UC_PACKAGE[DIR], [$withval])
fi
m4_popdef([GIT_UC_PACKAGE])])
--
1.7.10.2.1067.g553d16e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] autoconf: use AC_CONFIG_COMMANDS instead of ad-hoc 'config.mak.append'
This will allow ./config.status --recheck; ./config.status to work
correctly as a mean of reconfiguring the tree with the same configure
argument used in the previous ./configure invocation.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/configure.ac b/configure.ac
index b453ba5..a63fe77 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,9 +5,22 @@
# GIT_CONF_SUBST(VAL, VAR)
#
-# Append the line VAR=VAL to file ${config_append}
-AC_DEFUN([GIT_CONF_APPEND_LINE],
- [echo $1=$2 ${config_append}])
+# Cause the line VAR=VAL to be eventually appended to ${config_file}.
+AC_DEFUN([GIT_CONF_SUBST],
+ [AC_REQUIRE([GIT_CONF_SUBST_INIT])
+ config_appended_defs=$config_appended_defs${newline}$1=$2])
+
+# GIT_CONF_SUBST_INIT
+# ---
+# Prepare shell variables and autoconf machine required by later calls
+# to GIT_CONF_SUBST.
+AC_DEFUN([GIT_CONF_SUBST_INIT],
+[config_appended_defs=; newline='
+'
+AC_CONFIG_COMMANDS([$config_file],
+ [echo $config_appended_defs $config_file],
+ [config_file=$config_file
+config_appended_defs=$config_appended_defs])])
# GIT_ARG_SET_PATH(PROGRAM)
# -
@@ -133,11 +146,8 @@ AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
AC_CONFIG_SRCDIR([git.c])
config_file=config.mak.autogen
-config_append=config.mak.append
config_in=config.mak.in
-echo # ${config_append}. Generated by configure. ${config_append}
-
# Directories holding saner versions of common or POSIX binaries.
AC_ARG_WITH([sane-tool-path],
[AS_HELP_STRING(
@@ -1041,9 +1051,5 @@ AC_SUBST(PTHREAD_LIBS)
AC_SUBST(NO_PTHREADS)
## Output files
-AC_CONFIG_FILES([${config_file}:${config_in}:${config_append}])
+AC_CONFIG_FILES([${config_file}:${config_in}])
AC_OUTPUT
-
-
-## Cleanup
-rm -f ${config_append}
--
1.7.10.2.1067.g553d16e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] build: reconfigure automatically if configure.ac changes
This provides a reduced but still useful sibling of the Automake's automatic Makefile rebuild feature. It's important to note that we take care to enable the new rules only if the tree that has already be configured with './configure', so that users relying on manual configuration won't be negatively impacted. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- Makefile | 12 configure.ac | 2 ++ 2 files changed, 14 insertions(+) diff --git a/Makefile b/Makefile index 88a76a3..f4e8fac 100644 --- a/Makefile +++ b/Makefile @@ -2158,6 +2158,18 @@ configure: configure.ac GIT-VERSION-FILE autoconf -o $@ $+ \ $(RM) $+ +ifdef AUTOCONFIGURED +config.status: configure + $(QUIET_GEN)if test -f config.status; then \ + ./config.status --recheck; \ + else \ + ./configure; \ + fi +reconfigure config.mak.autogen: config.status + $(QUIET_GEN)./config.status +.PHONY: reconfigure # This is a convenience target. +endif + XDIFF_OBJS += xdiff/xdiffi.o XDIFF_OBJS += xdiff/xprepare.o XDIFF_OBJS += xdiff/xutils.o diff --git a/configure.ac b/configure.ac index a63fe77..df7e376 100644 --- a/configure.ac +++ b/configure.ac @@ -148,6 +148,8 @@ AC_CONFIG_SRCDIR([git.c]) config_file=config.mak.autogen config_in=config.mak.in +GIT_CONF_SUBST([AUTOCONFIGURED], [YesPlease]) + # Directories holding saner versions of common or POSIX binaries. AC_ARG_WITH([sane-tool-path], [AS_HELP_STRING( -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] build: make clean should not remove configure-generated files
Those filed hold variables, settings and information set by the configuration process run by './configure'; in Autotools-based build system that kind of stuff should only be removed by make distclean. Having it removed by make clean is not only inconsistent, but causes real confusion for that part of the Git audience that is used to the Autotools semantics; for example, an autotools old-timer that has run: ./configure --prefix /opt/git in the past, without running make distclean afterwards, would expect a make install issued after a make clean to rebuild and install git in '/opt/git'; but with the current behaviour, the make clean invocation removes (among the other things) the file 'config.mak.autogen', so that the make install falls back to the default prefix of '$HOME', thus installing git in the user's home directory -- definitely unexpected. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 285c660..88a76a3 100644 --- a/Makefile +++ b/Makefile @@ -2742,6 +2742,9 @@ dist-doc: distclean: clean $(RM) configure + $(RM) config.log config.status config.cache + $(RM) config.mak.autogen config.mak.append + $(RM) -r autom4te.cache profile-clean: $(RM) $(addsuffix *.gcda,$(addprefix $(PROFILE_DIR)/, $(object_dirs))) @@ -2756,8 +2759,6 @@ clean: profile-clean $(RM) -r $(dep_dirs) $(RM) -r po/build/ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h $(ETAGS_TARGET) tags cscope* - $(RM) -r autom4te.cache - $(RM) config.log config.mak.autogen config.mak.append config.status config.cache $(RM) -r $(GIT_TARNAME) .doc-tmp-dir $(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz $(RM) $(htmldocs).tar.gz $(manpages).tar.gz -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] autoconf: remove few redundant semicolons
They are merely useless now, but would get in the way of future changes. No semantic change is intended. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 200776f..b453ba5 100644 --- a/configure.ac +++ b/configure.ac @@ -203,7 +203,7 @@ AC_ARG_ENABLE([jsmin], [ JSMIN=$enableval; AC_MSG_NOTICE([Setting JSMIN to '$JSMIN' to enable JavaScript minifying]) - GIT_CONF_SUBST([JSMIN], [$enableval]); + GIT_CONF_SUBST([JSMIN], [$enableval]) ]) # Define option to enable CSS minification @@ -213,7 +213,7 @@ AC_ARG_ENABLE([cssmin], [ CSSMIN=$enableval; AC_MSG_NOTICE([Setting CSSMIN to '$CSSMIN' to enable CSS minifying]) - GIT_CONF_SUBST([CSSMIN], [$enableval]); + GIT_CONF_SUBST([CSSMIN], [$enableval]) ]) ## Site configuration (override autodetection) -- 1.7.10.2.1067.g553d16e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] git-svn: don't create master if another head exists
Marcin Owsiany mar...@owsiany.pl wrote: On Wed, Jul 18, 2012 at 11:27:22AM +, Eric Wong wrote: Marcin Owsiany mar...@owsiany.pl wrote: Turns out that command_noisy() - has a meaningless return value - throws an exception on command failure so the || bit does not work. Also, for some reason command_noisy does not check for the command being killed by a signal, so I'd prefer to leave the verify_ref there. Ugh, I always forget the Git.pm API, too. Perhaps command_noisy should be made to respect signals in exit codes (the rest of git-svn is compromised by this behavior in command_noisy, too, it turns out... :x) I'm not sure what else would break if command_noisy were changed, git-svn appears to be the only user in git.git. Other command flavours should probably also be changed to match? Probably, I'm not sure if it'd break existing uses. Anyways, that's a separate issue we can deal with another day. I've added my Signed-off-by: to your latest patch and pushed to master of git://bogomips.org/git-svn.git (commit e3bd4ddaa9a60fa4e70efdb143b434b440d6cec4) Marcin Owsiany (1): git-svn: don't create master if another head exists -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] difftool: only copy back files modified during directory diff
From: Tim Henigan tim.heni...@gmail.com
When 'difftool --dir-diff' is used to compare working tree files,
it always copies files from the tmp dir back to the working tree
when the diff tool is closed, even if the files were not modified
by the diff tool.
This causes the file timestamp to change. Files should only be
copied from the tmp dir back to the working copy if they were
actually modified.
Signed-off-by: Tim Henigan tim.heni...@gmail.com
Signed-off-by: David Aguilar dav...@gmail.com
---
Perhaps something like this...
git-difftool.perl | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index ae1e052..c079854 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -15,6 +15,7 @@ use strict;
use warnings;
use File::Basename qw(dirname);
use File::Copy;
+use File::Compare;
use File::Find;
use File::stat;
use File::Path qw(mkpath);
@@ -336,8 +337,10 @@ if (defined($dirdiff)) {
# files were modified during the diff, then the changes
# should be copied back to the working tree
for my $file (@working_tree) {
- copy($b/$file, $workdir/$file) or die $!;
- chmod(stat($b/$file)-mode, $workdir/$file) or die $!;
+ if (-e $b/$file compare($b/$file, $workdir/$file)) {
+ copy($b/$file, $workdir/$file) or die $!;
+ chmod(stat($b/$file)-mode, $workdir/$file) or die
$!;
+ }
}
} else {
if (defined($prompt)) {
--
1.7.11.2.250.g00b4b9a
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
MDaemon Notification -- Attachment Removed
--- MDaemon has detected restricted attachments within an email message --- From : git@vger.kernel.org To: sandyngu...@asmara-vietnam.com Subject : Message could not be delivered Message-ID: - Attachment(s) removed - sandyngu...@asmara-vietnam.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Fix notes handling in rev-list
On Wed, Jul 18, 2012 at 03:39:34PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: So leaving aside the --graph issues, we would need to decide what to show in the non-graph case. And I think your suggestion is good; there is no real need to dereference the blob (if you want that, you can turn on the pretty-printer). I'm just not sure what the output should be. I guess: commit_sha1 notes sha1s is probably the most sensible (it's sort of like --parents). And that solves the --graph issue, too, since it continues to take only a single line. Surely. rev-list --parents --notes would still be usable that way, as a reader that requests such a combination is prepared to tell commits (i.e. parents) and blobs (i.e. notes) apart. I don't think we forbid non-blob values in notes trees, so technically there could be some ambiguity. I doubt it is a big problem in practice (especially since I haven't even heard of a good use case yet for git rev-list --notes, let alone git rev-list --notes --parents). But now would be the time to avoid a crappy format that we will be stuck with later. Unlike elements of the commit object itself, like --parents or --timestamp, notes do not really gain any efficiency by being printed as part of the traversal. So modulo the cost of piping the list of commits, it would not really be any more efficient than git rev-list | git notes list --stdin (except that the latter does not take a --stdin argument, but could easily do so). And the latter is way more flexible. So for plumbing, I think this is the wrong direction, anyway. The real value of this patch is that the pretty-printed code path would work more like git-log (especially the %N format, which lets callers make their own micro-format for specifying all the bits they are interested in). Maybe the best thing is to simply disallow --notes when not using a pretty-printed format. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: respect --no-ext-diff with typechange
On Wed, Jul 18, 2012 at 03:47:21PM -0700, Junio C Hamano wrote:
I don't care too deeply either way, and it is technically a behavior
change. So there is a chance of regression for something that nobody has
actually complained about.
Thanks. I share the same feeling, but the code after the patch looks
much nicer, which is somewhat sad.
If we're not going to do it, perhaps we should at least include the
tests I wrote (modified for the current behavior), since there was no
coverage in this area previously. Patch is below.
To be honest, I doubt many people are using
external diff at all these days; textconv is closer to what most people
want, and is much easier to use.
It depends on the payload and the output you want. I wouldn't think
it is fair to challenge anybody to come up with a solution based on
the textconv machinery to replicate what the compare-cooking.perl in
the 'todo' branch (used as an external diff driver for
whats-cooking.txt) does.
Oh, absolutely. The compare-cooking script is a great example of what
you can do with the flexibility that external diff offers. But based on
my experience and reading the list, the much more common request is to
produce a meaningful diff of two binary word processor documents. :)
Googling around, the other common use seems to be to stuff the output
into a visual diff tool. Though I think that git difftool is a better
approach for that.
-Peff
-- 8 --
Subject: [PATCH] diff: test precedence of external diff drivers
There are three ways to specify an external diff command:
GIT_EXTERNAL_DIFF in the environment, diff.external in the
config, or a diff gitattribute. The current order of
precedence is:
1. gitattribute
2. GIT_EXTERNAL_DIFF
3. diff.external
Usually our rule is that environment variables should take
precedence over on-disk config (i.e., option 2 should come
before option 1). However, this situation is trickier than
some, because option 1 is more specific to the individual
file than option 2 (which affects all files), so it might be
preferable. So the current behavior can be seen as
implementing do the specific thing if we can, but fall back
to this general thing.
This is probably not what we would do if we were writing git
from scratch, but it has been this way for several years,
and is not worth changing. So let's at least document that
this is the way it's supposed to work with a test.
While we're there, let's also make sure that diff.external
(which was not previously tested at all) works by running it
through the same tests as GIT_EXTERNAL_DIFF.
Signed-off-by: Jeff King p...@peff.net
---
t/t4020-diff-external.sh | 40
1 file changed, 40 insertions(+)
diff --git a/t/t4020-diff-external.sh b/t/t4020-diff-external.sh
index 5a5f68c..2e7d73f 100755
--- a/t/t4020-diff-external.sh
+++ b/t/t4020-diff-external.sh
@@ -65,6 +65,33 @@ test_expect_success SYMLINKS 'typechange diff' '
test_cmp expect actual
'
+test_expect_success 'diff.external' '
+ git reset --hard
+ echo third file
+ test_config diff.external echo
+ git diff | {
+ read path oldfile oldhex oldmode newfile newhex newmode
+ test z$path = zfile
+ test z$oldmode = z100644
+ test z$newhex = z$_z40
+ test z$newmode = z100644
+ oh=$(git rev-parse --verify HEAD:file)
+ test z$oh = z$oldhex
+ }
+'
+
+test_expect_success 'diff.external should apply only to diff' '
+ test_config diff.external echo
+ git log -p -1 HEAD |
+ grep ^diff --git a/file b/file
+'
+
+test_expect_success 'diff.external and --no-ext-diff' '
+ test_config diff.external echo
+ git diff --no-ext-diff |
+ grep ^diff --git a/file b/file
+'
+
test_expect_success 'diff attribute' '
git reset --hard
echo third file
@@ -132,6 +159,19 @@ test_expect_success 'diff attribute and --no-ext-diff' '
'
+test_expect_success 'GIT_EXTERNAL_DIFF trumps diff.external' '
+ .gitattributes
+ test_config diff.external echo ext-global
+ GIT_EXTERNAL_DIFF=echo ext-env git diff | grep ext-env
+'
+
+test_expect_success 'attributes trump GIT_EXTERNAL_DIFF and diff.external' '
+ test_config diff.foo.command echo ext-attribute
+ test_config diff.external echo ext-global
+ echo file diff=foo .gitattributes
+ GIT_EXTERNAL_DIFF=echo ext-env git diff | grep ext-attribute
+'
+
test_expect_success 'no diff with -diff' '
echo .gitattributes file -diff
git diff | grep Binary
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote: i would like `git fetch --prune remote` to be the default behavior of `git fetch remote` In fact, i think this is the only reasonable behavior. Keeping copies of deleted remote branches after `fetch` is more confusing than useful. I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. So I think it would be a lot more palatable if we kept reflogs on deleted branches. That, in turn, has a few open issues, such as how to manage namespace conflicts (e.g., the fact that a deleted foo branch can conflict with a new foo/bar branch). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug: Git-Svn creates wrong tag when svn tag contains spaces
I've the problem described here: http://code.google.com/p/git-core/issues/detail?id=16 Kind Regards, Rafal Sent from my iPhone -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, Jul 19, 2012 at 7:55 AM, Jeff King p...@peff.net wrote: On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote: i would like `git fetch --prune remote` to be the default behavior of `git fetch remote` In fact, i think this is the only reasonable behavior. Keeping copies of deleted remote branches after `fetch` is more confusing than useful. I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. So I think it would be a lot more palatable if we kept reflogs on deleted branches. That, in turn, has a few open issues, such as how to manage namespace conflicts (e.g., the fact that a deleted foo branch can conflict with a new foo/bar branch). In the meantime, would it make sense to introduce a configuration variable to request this behavior? If so, should it be global? fetch.prune = always or per-remote? remote.name.prune = always The global option seems to be more in line with what Alexey is looking for, but the per-remote one is similar to the tagopt option, which is a similar idea. Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options. -- -Dan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
Dan Johnson computerdr...@gmail.com wrote: In the meantime, would it make sense to introduce a configuration variable to request this behavior? fetch.prune = always Of course, this might be just a waste of time to introduce a feature no one would use, in which case we obviously should not introduce such options. I would use it. -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
solar lala shared photos with you
Dear sir We supply solar PV system (including solar panels , frame, cable ,inverter and controller , power distribution cabinet) with 1.6$/w FOB shenzhen. Email me or just call me directly if needed. Thank you! Best wishes lala Ecosol PV Tech Co., Ltd Tel: 86-769-8279 2468 Fax: 86-769-879 2478 email:i...@ecsolsolar.com skype:solarlala msn:solarl...@hotmail.com www.ecsolsolar.com attachment: 003.jpg
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 13:55, Jeff King wrote: On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote: i would like `git fetch --prune remote` to be the default behavior of `git fetch remote` In fact, i think this is the only reasonable behavior. Keeping copies of deleted remote branches after `fetch` is more confusing than useful. I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. I do not still understand very well some aspects of Git, like the exact purpose of remote tracking branches (are they for pull or for push?), so i may be wrong. However, i thought that a user was not expected to follow the moves of a remote branch of which the user is not an owner: if the user needs to follow the brach and not lose its commits, he/she should create a remote tracking branch. So I think it would be a lot more palatable if we kept reflogs on deleted branches. That, in turn, has a few open issues, such as how to manage namespace conflicts (e.g., the fact that a deleted foo branch can conflict with a new foo/bar branch). I prefer to think of a remote branch and its local copy as the same thing, which are physically different only because of current real world/hardware/software limitations, which make it necessary to keep a local cache of remote data. With this approach, reflogs should be deleted with the branch, and there will be no namespace conflicts. Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 13:55, Jeff King wrote: I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. If i understand correctly, existence of a reflog entry will not stop gc from removing a commit, will it? In this case, if a remote branch was rebased or reset, commits can be lost anyway, right? Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov alexey.mura...@gmail.com wrote: On 19 Jul 2012, at 13:55, Jeff King wrote: I agree it would be much less confusing. However, one downside is that we do not keep reflogs on deleted branches (and nor did the commits in remote branches necessarily make it into the HEAD reflog). That makes git fetch a potentially destructive operation (you irrevocably lose the notion of which remote branches pointed where before the fetch, and you open up new commits to immediate pruning by gc --auto. If i understand correctly, existence of a reflog entry will not stop gc from removing a commit, will it? In this case, if a remote branch was rebased or reset, commits can be lost anyway, right? From the git-gc man page: git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). So yes, a reflog entry does stop gc from removing objects, including commits. It will expire old reflog entries (90 days by default) though, so it's not like they will stay around forever. -- -Dan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 18:48, Dan Johnson wrote: From the git-gc man page: git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). So yes, a reflog entry does stop gc from removing objects, including commits. It will expire old reflog entries (90 days by default) though, so it's not like they will stay around forever. Dan, thanks for the explanation. Alexey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Fix notes handling in rev-list
Jeff King p...@peff.net writes: Unlike elements of the commit object itself, like --parents or --timestamp, notes do not really gain any efficiency by being printed as part of the traversal. So modulo the cost of piping the list of commits, it would not really be any more efficient than git rev-list | git notes list --stdin (except that the latter does not take a --stdin argument, but could easily do so). And the latter is way more flexible. Yeah, I prefer that (not that I think we need either badly). So for plumbing, I think this is the wrong direction, anyway. The real value of this patch is that the pretty-printed code path would work more like git-log (especially the %N format, which lets callers make their own micro-format for specifying all the bits they are interested in). Yeah, but at that point the obvious question becomes why you aren't using 'git log' in the first place. Maybe the best thing is to simply disallow --notes when not using a pretty-printed format. Yeah, or simply ignore it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] git-svn: don't create master if another head exists
Eric Wong normalper...@yhbt.net writes: Probably, I'm not sure if it'd break existing uses. Anyways, that's a separate issue we can deal with another day. I've added my Signed-off-by: to your latest patch and pushed to master of git://bogomips.org/git-svn.git (commit e3bd4ddaa9a60fa4e70efdb143b434b440d6cec4) Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] autoconf: remove some redundant shell indirections
Stefano Lattarini stefano.lattar...@gmail.com writes: On 07/19/2012 02:29 AM, Junio C Hamano wrote: The inconsistency between the existing one that does not quote the string that is not substituted, i.e. GIT_UC_PROGRAM[]_PATH=$withval and the new one that quotes _PATH, i.e. GIT_CONF_SUBST(GIT_UC_PROGRAM[_PATH], []) looks somewhat strange, though. Will fix that in the re-roll. I see you already used the []_PATH in your reroll, and I do not think it matters either way in pracice, but I suspect that it is technically more correct to have _PATH part inside the bra-ket quotes (of course, changing the style to maximally quote like that is a totally different topic, and should be done as a separate patch, so I think your reroll is the right thing to do within the scope of this series). Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] build: make clean should not remove configure-generated files
Stefano Lattarini stefano.lattar...@gmail.com writes: On 07/19/2012 08:56 AM, Matthieu Moy wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: for example, an autotools old-timer that has run: ./configure --prefix /opt/git in the past, without running make distclean afterwards, would expect a make install issued after a make clean to rebuild and install git in '/opt/git'; I've been hit by that behavior once. Thanks for fixing it. The patch looks good. Should I add Acked-by: Matthieu Moy then? Given that we see nothing in the ouptut from $ git shortlog --no-merges --author='Matthieu Moy' -- Makefile configure.ac that remotely relates to the current state of affairs in this area, I do not think we can say Matthieu _owns_ autoconf-related part of the code in any way, so I do not think it is needed. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Fix notes handling in rev-list
On Thu, Jul 19, 2012 at 10:20:18AM -0700, Junio C Hamano wrote: So for plumbing, I think this is the wrong direction, anyway. The real value of this patch is that the pretty-printed code path would work more like git-log (especially the %N format, which lets callers make their own micro-format for specifying all the bits they are interested in). Yeah, but at that point the obvious question becomes why you aren't using 'git log' in the first place. I dunno. I guess there are other plumbing-like behaviors of rev-list that you would want, but the only ones I can think of are diff options, which rev-list does not handle at all. Maybe the best thing is to simply disallow --notes when not using a pretty-printed format. Yeah, or simply ignore it. I'd rather generate an error to make it more obvious what is happening (and it is not that we are somehow failing to find any notes). And it might help prevent the later question of: why does git rev-list --oneline --notes show notes, but git rev-list --notes silently ignores it? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] difftool: only copy back files modified during directory diff
David Aguilar dav...@gmail.com writes: Perhaps something like this... Yeah, like that ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov alexey.mura...@gmail.com wrote: [...] I do not still understand very well some aspects of Git, like the exact purpose of remote tracking branches (are they for pull or for push?), so i may be wrong. This is wery well explained in the Pro Git book, for instance. And in numerous blog posts etc. However, i thought that a user was not expected to follow the moves of a remote branch of which the user is not an owner: if the user needs to follow the brach and not lose its commits, he/she should create a remote tracking branch. This would present another namespacing issue: how would you name the branches you're interested in so that they don't clash with your own personal local branches? You'd have to invent a scheme which would encode the remote's name in a branch name. But remote branches already do just this. So you create a remote tracking branch when you intend to actually *develop* something on that branch with the final intention to push that work back. So I think it would be a lot more palatable if we kept reflogs on deleted branches. That, in turn, has a few open issues, such as how to manage namespace conflicts (e.g., the fact that a deleted foo branch can conflict with a new foo/bar branch). I prefer to think of a remote branch and its local copy as the same thing, which are physically different only because of current real world/hardware/software limitations, which make it necessary to keep a local cache of remote data. With this approach, reflogs should be deleted with the branch, and there will be no namespace conflicts. It appears, the distributed nature of a DVCS did not fully sink into your mindset yet. ;-) Looks like you mentally treat a Git remote as a thing being used to access a centralized reference server which maintains a master copy of a repository, of which you happen to also have a local copy. Then it's quite logically to think that if someone deleted a branch in the master copy, everyone downstream should have the same remote branch deleted to be in sync with that master copy. But this is not the only way to organize your work. You could fetch from someone else's repository and be interested in their branch foo, but think what happens when you fetch next time from that repo and see Git happily deleting your local branch thatremote/foo simply because someone with push access deleted that branch from the repo. This might *not* be what you really want or expect. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: Git-Svn creates wrong tag when svn tag contains spaces
The problem is as follow:
1. git svn fetch
2.
Found possible branch point: https://xxx/svn/xxx/branches/11-07 D t-m
= https://xxx/svn/xxx/branches/11-09 S t-m, 4332
fatal: Not a valid object name refs/remotes/1-11 M R 2.6
cat-file commit refs/remotes/1-11 M R 2.6: command returned error: 128
I'm using git version 1.7.9.5 on Ubuntu 12.04
I've tried to create the tag manually, but it's not allowed.
$ git tag 11-07 D t-m remotes/11-07%20D
fatal: '11-07 D t-m' is not a valid tag name.
As workaround I've tried:
- to create or rename tag manually as suggested here:
http://stackoverflow.com/questions/11365317/git-svn-clone-fails-fatal-not-a-valid-object-name/11559472#11559472
-
http://qa.celogeek.com/programming/versionning/git/svn/rebase_with_bad_object_after_rm
But without success.
There is also bug report on lunchpad:
https://bugs.launchpad.net/ubuntu/+source/git/+bug/786942
strace log:
[pid 30618] access(.git/config, R_OK) = 0
[pid 30618] open(.git/config, O_RDONLY) = 3
[pid 30618] fstat(3, {st_mode=S_IFREG|0664, st_size=551, ...}) = 0
[pid 30618] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2ed01e9000
[pid 30618] read(3, [core]\n\trepositoryformatversion ..., 4096) = 551
[pid 30618] read(3, , 4096) = 0
[pid 30618] close(3)= 0
[pid 30618] munmap(0x7f2ed01e9000, 4096) = 0
[pid 30618] write(2, fatal: Not a valid object name r..., 76fatal:
Not a valid object name refs/remotes/1-11 M R 2.6
) = 76
[pid 30618] exit_group(128) = ?
---
Kind regards,
Rafal
On 19 July 2012 16:08, Thomas Rast tr...@student.ethz.ch wrote:
Rafal W. ken...@gmail.com writes:
I've the problem described here:
http://code.google.com/p/git-core/issues/detail?id=16
Git does not have a bug tracker. Please post the issue, description,
etc. to this list.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote: On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov alexey.mura...@gmail.com wrote: [...] I do not still understand very well some aspects of Git, like the exact purpose of remote tracking branches (are they for pull or for push?), so i may be wrong. This is wery well explained in the Pro Git book, for instance. And in numerous blog posts etc. I have read the Pro Gut book and numerous blog posts, but i keep forgetting the explanation because it does not make much sense to me: Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git push, Git automatically knows which server and branch to push to. Also, running git pull while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch. etc. Why the same direct relationship for push and pull? What happens if one of the branches was reset (yes, i know, push -f). Most importantly, what is the purpose of it? It is natural to expect that you might be pushing to and pulling from different remotes, i can even imagine pulling from more than one. However, i thought that a user was not expected to follow the moves of a remote branch of which the user is not an owner: if the user needs to follow the brach and not lose its commits, he/she should create a remote tracking branch. This would present another namespacing issue: how would you name the branches you're interested in so that they don't clash with your own personal local branches? You'd have to invent a scheme which would encode the remote's name in a branch name. But remote branches already do just this. So you create a remote tracking branch when you intend to actually *develop* something on that branch with the final intention to push that work back. But i am not interested in remote branches, they are just fetched automatically when i do git fetch. You cannot commit to a remote branch, and i think it is not common to checkout them without a -b option. If i am interested in them, i name them somehow. I think this is the only practical way if i do not want to chase reflogs, because the owner of the branch can reset or rebase it anytime. I do not develop on tracking branches. In fact, i am not even using git pull. So I think it would be a lot more palatable if we kept reflogs on deleted branches. That, in turn, has a few open issues, such as how to manage namespace conflicts (e.g., the fact that a deleted foo branch can conflict with a new foo/bar branch). I prefer to think of a remote branch and its local copy as the same thing, which are physically different only because of current real world/hardware/software limitations, which make it necessary to keep a local cache of remote data. With this approach, reflogs should be deleted with the branch, and there will be no namespace conflicts. It appears, the distributed nature of a DVCS did not fully sink into your mindset yet. ;-) Looks like you mentally treat a Git remote as a thing being used to access a centralized reference server which maintains a master copy of a repository, of which you happen to also have a local copy. Then it's quite logically to think that if someone deleted a branch in the master copy, everyone downstream should have the same remote branch deleted to be in sync with that master copy. But this is not the only way to organize your work. You could fetch from someone else's repository and be interested in their branch foo, but think what happens when you fetch next time from that repo and see Git happily deleting your local branch thatremote/foo simply because someone with push access deleted that branch from the repo. This might *not* be what you really want or expect. But this is true that the object store of Git can be viewed as a single centralized repository. The fact that not everybody has access to every object in Git is a limitation and not a benefit. These are the branches which are individual, and i do not think it is a good habit to treat every reference that was ever fetched with git fetch as your own, and put reflogs of all fetched remote branches under Git version control :D. If i care about thatremote/foo branch, i track it, i do not plan to go through reflogs if it is rebased. Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 0/3] reflog graveyard
On Thu, Jul 19, 2012 at 07:55:58AM -0400, Jeff King wrote: So I think it would be a lot more palatable if we kept reflogs on deleted branches. That, in turn, has a few open issues, such as how to manage namespace conflicts (e.g., the fact that a deleted foo branch can conflict with a new foo/bar branch). Here is a patch series to address that. I think I have smoothed out most of the rough edges, but I wouldn't be surprised if there are some other corner cases. One that I notice is that git log -g will stop walking when it hits a null sha1 in the reflog. [1/3]: retain reflogs for deleted refs [2/3]: teach sha1_name to look in graveyard reflogs [3/3]: add tests for reflogs of deleted refs -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] teach sha1_name to look in graveyard reflogs
The previous commit introduced graveyard reflogs, where the
reflog for a deleted branch foo appears in
logs/graveyard/refs/heads/foo~.
This patch teaches dwim_log to search for these logs if the
ref does not exist, and teaches read_ref_at to fall back to
them when the literal reflog does not exist. This allows
deleted@{1} to refer to the final commit of a deleted
branch (either to view or to re-create the branch). You can
also go further back, or refer to the deleted reflog entries
by time. Accessing deleted@{0} will yield the null sha1.
Similarly, for_each_reflog_ent learns to fallback to
graveyard refs, which allows the reflog walker to work.
However, this is slightly less friendly, as the revision
parser expects the matching ref to exist before it realizes
that we are interested in the reflog. Therefore you must use
git log -g deleted@{1} insted of git log -g deleted to
walk a deleted reflog.
In both cases, we also tighten up the mode-checking when
opening the reflogs. dwim_log checks that the entry we found
is a regular file (not a directory) to avoid D/F confusion
(e.g., you ask for foo but foo/bar exists and we find
the foo but it is a directory).
However, read_ref_at and for_each_reflog_ent did not do this
check, and relied on earlier parts of the code to have
verified the log they are about to open. This meant that
even before this patch, a race condition in changing refs
between dwim_log and the actual read could cause bizarre
errors (e.g., read_ref_at would open and try to mmap a
directory). This patch makes it even easier to trigger those
conditions (because the ref namespace and the fallback
graveyard namespace can have D/F ambiguity for a certain
path). To solve this, we check the mode of the file we open
and treat it as if it did not exist if it is not a regular
file (this is the same way dwim_log handles it).
Signed-off-by: Jeff King p...@peff.net
---
refs.c | 46 +++---
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/refs.c b/refs.c
index 553de77..551a0f9 100644
--- a/refs.c
+++ b/refs.c
@@ -1590,9 +1590,16 @@ int dwim_log(const char *str, int len, unsigned char
*sha1, char **log)
mksnpath(path, sizeof(path), *p, len, str);
ref = resolve_ref_unsafe(path, hash, 1, NULL);
- if (!ref)
- continue;
- if (!stat(git_path(logs/%s, path), st)
+ if (!ref) {
+ if (!stat(refname_to_graveyard_reflog(path), st)
+ S_ISREG(st.st_mode)) {
+ it = path;
+ hashcpy(hash, null_sha1);
+ }
+ else
+ continue;
+ }
+ else if (!stat(git_path(logs/%s, path), st)
S_ISREG(st.st_mode))
it = path;
else if (strcmp(ref, path)
@@ -2201,9 +2208,16 @@ int read_ref_at(const char *refname, unsigned long
at_time, int cnt,
logfile = git_path(logs/%s, refname);
logfd = open(logfile, O_RDONLY, 0);
- if (logfd 0)
- die_errno(Unable to read log '%s', logfile);
- fstat(logfd, st);
+ if (logfd 0 || fstat(logfd, st) 0 || !S_ISREG(st.st_mode)) {
+ const char *deleted_log = refname_to_graveyard_reflog(refname);
+
+ if (logfd = 0)
+ close(logfd);
+ logfd = open(deleted_log, O_RDONLY);
+ if (logfd 0 || fstat(logfd, st) 0 || !S_ISREG(st.st_mode))
+ die_errno(Unable to read log '%s', logfile);
+ logfile = deleted_log;
+ }
if (!st.st_size)
die(Log %s is empty., logfile);
mapsz = xsize_t(st.st_size);
@@ -2296,18 +2310,28 @@ int for_each_recent_reflog_ent(const char *refname,
each_reflog_ent_fn fn, long
{
const char *logfile;
FILE *logfp;
+ struct stat st;
struct strbuf sb = STRBUF_INIT;
int ret = 0;
logfile = git_path(logs/%s, refname);
logfp = fopen(logfile, r);
- if (!logfp)
- return -1;
+ if (!logfp || fstat(fileno(logfp), st) 0 || !S_ISREG(st.st_mode)) {
+ logfile = refname_to_graveyard_reflog(refname);
+
+ if (logfp)
+ fclose(logfp);
+ logfp = fopen(logfile, r);
+ if (!logfp)
+ return -1;
+ if (fstat(fileno(logfp), st) 0 || !S_ISREG(st.st_mode)) {
+ fclose(logfp);
+ return -1;
+ }
+ }
if (ofs) {
- struct stat statbuf;
- if (fstat(fileno(logfp), statbuf) ||
- statbuf.st_size ofs ||
+ if (st.st_size ofs ||
fseek(logfp, -ofs, SEEK_END) ||
[PATCH 3/3] add tests for reflogs of deleted refs
These tests cover the basic functionality of retaining
reflogs for deleted refs.
Signed-off-by: Jeff King p...@peff.net
---
t/t1413-reflog-deletion.sh | 74 ++
1 file changed, 74 insertions(+)
create mode 100755 t/t1413-reflog-deletion.sh
diff --git a/t/t1413-reflog-deletion.sh b/t/t1413-reflog-deletion.sh
new file mode 100755
index 000..e00d038
--- /dev/null
+++ b/t/t1413-reflog-deletion.sh
@@ -0,0 +1,74 @@
+#!/bin/sh
+
+test_description='test retention of reflog after ref deletion'
+. ./test-lib.sh
+
+test_expect_success 'setup deleted branch' '
+ test_tick echo one file git add file git commit -m one
+ test_tick echo two file git add file git commit -m two
+ git checkout -b foo/bar
+ test_tick echo three file git add file git commit -m three
+ git checkout master
+ git branch -D foo/bar
+ rm -f .git/logs/HEAD
+'
+
+test_expect_success 'branch is no longer accessible' '
+ test_must_fail git rev-parse --verify foo/bar
+'
+
+test_expect_success 'final reflog is null sha1' '
+ echo $_z40 expect
+ git rev-parse --verify foo/bar@{0} actual
+ test_cmp expect actual
+'
+
+test_expect_success 'deleted reflog entries are accessible' '
+ cat expect -\EOF
+ three
+ two
+ EOF
+ {
+ git log -1 --format=%s foo/bar@{1}
+ git log -1 --format=%s foo/bar@{2}
+ } actual
+ test_cmp expect actual
+'
+
+test_expect_success 'reflog walker can find deleted entries' '
+ cat expect -\EOF
+ three
+ two
+ EOF
+ git log -g --format=%s foo/bar@{1} actual
+ test_cmp expect actual
+'
+
+test_expect_success 'can still create/delete same ref' '
+ git branch foo/bar
+ git branch -D foo/bar
+'
+
+test_expect_success 'can still create/delete parent ref' '
+ git branch foo
+ git branch -D foo
+'
+
+test_expect_success 'can still create/delete child ref' '
+ git branch foo/bar/baz
+ git branch -D foo/bar/baz
+'
+
+test_expect_success 'deleted reflog entries are still reachable' '
+ expect
+ git fsck --unreachable actual
+ test_cmp expect actual
+'
+
+test_expect_success 'deleted reflog entries are expired normally' '
+ git reflog expire --all --expire=now
+ git fsck --unreachable actual
+ test_line_count = 3 actual
+'
+
+test_done
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: fetch --prune by default
I just want to correct my mistake in what i've just sent: On 19 Jul 2012, at 23:20, Alexey Muranov wrote: because the owner of the branch can reset or rebase it anytime. I do not develop on tracking branches. In fact, i am not even using git pull. I do not develop on tracking branches. Of course i develop on tracking branches, i just got confused once again by pull/push thing: i develop on branches that track origin, not upstream. I think they should be called remotely tracked branches, so there would be remote tracking branches for pull and remotely tracked branches for push. Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] retain reflogs for deleted refs
Jeff, i have no idea about Git source and little idea of how it is working internally, but reading through your message i wonder: wouldn't it be a good idea to timestamp the dead reflogs ? Alexey. On 19 Jul 2012, at 23:33, Jeff King wrote: When a ref is deleted, we completely delete its reflog on the spot, leaving very little help for the user to reverse the action. One can sometimes reconstruct the missing entries based on the HEAD reflog, but not always; the deleted entries may not have ever been on HEAD (for example, in the case of a refs/remotes branch that was pruned). That leaves git fsck --lost-found, which can be quite tedious. Instead, let's keep the reflogs for deleted refs around until their entries naturally expire according to the regular reflog expiration rules. This cannot be done by simply leaving the reflog files in place. The ref namespace does not allow D/F conflicts, so a ref foo would block the creation of another ref foo/bar, and vice versa. This limitation is acceptable for two refs to exist simultaneously, but should not have an impact if one of the refs is deleted. This patch moves reflog entries into a special graveyard namespace, and appends a tilde (~) character, which is not allowed in a valid ref name. This means that the deleted reflogs of these refs: refs/heads/a refs/heads/a/b refs/heads/a/b/c will be stored in: logs/graveyard/refs/heads/a~ logs/graveyard/refs/heads/a/b~ logs/graveyard/refs/heads/a/b/c~ Putting them in the graveyard namespace ensures they will not conflict with live refs, and the tilde prevents D/F conflicts within the graveyard namespace. The implementation is fairly straightforward, but it's worth noting a few things: 1. Updates to logs/graveyard/refs/heads/foo~ happen under the ref-lock for refs/heads/foo. So deletion still takes a single lock, and anyone touching the reflog directly needs to reverse the transformation to find the correct lockfile. 2. We append entries to the graveyard reflog rather than simply renaming the file into place. This means that if you create and delete a branch repeatedly, the graveyard will contain the concatenation of all iterations. 3. We do not resurrect dead entries when a new ref is created with the same name. However, it would be possible to build an undelete feature on top of this if one was so inclined. 4. The for_each_reflog code has been loosened to allow reflogs that do not have a matching ref. In this case, the callback is passed the null_sha1, and callers must be prepared to handle this case (the only caller that cares is the reflog expiration code, which is updated here). Only one test needed to be updated; t7701 tries to create unreachable objects by deleting branches. Of course that no longer works, which is the intent of this patch. The test now works around it by removing the graveyard logs. Signed-off-by: Jeff King p...@peff.net --- builtin/reflog.c | 9 +++-- refs.c | 69 +--- refs.h | 3 ++ t/t7701-repack-unpack-unreachable.sh | 5 ++- 4 files changed, 79 insertions(+), 7 deletions(-) diff --git a/builtin/reflog.c b/builtin/reflog.c index b3c9e27..e79a2ca 100644 --- a/builtin/reflog.c +++ b/builtin/reflog.c @@ -359,6 +359,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused, struct commit *tip_commit; struct commit_list *tips; int status = 0; + int updateref = cmd-updateref !is_null_sha1(sha1); memset(cb, 0, sizeof(cb)); @@ -367,6 +368,10 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused, * getting updated. */ lock = lock_any_ref_for_update(ref, sha1, 0); + if (!lock is_null_sha1(sha1)) + lock = lock_any_ref_for_update( + graveyard_reflog_to_refname(ref), + sha1, 0); if (!lock) return error(cannot lock ref '%s', ref); log_file = git_pathdup(logs/%s, ref); @@ -426,7 +431,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused, status |= error(%s: %s, strerror(errno), newlog_path); unlink(newlog_path); - } else if (cmd-updateref + } else if (updateref (write_in_full(lock-lock_fd, sha1_to_hex(cb.last_kept_sha1), 40) != 40 || write_str_in_full(lock-lock_fd, \n) != 1 || @@ -438,7 +443,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused, status |= error(cannot rename %s to %s,
Re: [PATCH 1/3] retain reflogs for deleted refs
Jeff King p...@peff.net writes: Only one test needed to be updated; t7701 tries to create unreachable objects by deleting branches. Of course that no longer works, which is the intent of this patch. The test now works around it by removing the graveyard logs. I think the work-around indicates the need for regular users to be able to also discover, prune and delete these logs. Do we have prune reflog for _this_ ref (or these refs), removing entries that are older than this threshold? If so the codepath would need to know about the graveyard and the implementation detail of the tilde suffix so that the end users do not need to know about them. I like the general direction. Perhaps a long distant future direction could be to also use the same trick in the ref namespace so that we can have 'next' branch itself, and 'next/foo', 'next/bar' forks that are based on the 'next' branch at the same time (it obviously is a totally unrelated topic)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] teach sha1_name to look in graveyard reflogs
Jeff King p...@peff.net writes:
The previous commit introduced graveyard reflogs, where the
reflog for a deleted branch foo appears in
logs/graveyard/refs/heads/foo~.
This patch teaches dwim_log to search for these logs if the
ref does not exist, and teaches read_ref_at to fall back to
them when the literal reflog does not exist. This allows
deleted@{1} to refer to the final commit of a deleted
branch (either to view or to re-create the branch). You can
also go further back, or refer to the deleted reflog entries
by time. Accessing deleted@{0} will yield the null sha1.
Similarly, for_each_reflog_ent learns to fallback to
graveyard refs, which allows the reflog walker to work.
However, this is slightly less friendly, as the revision
parser expects the matching ref to exist before it realizes
that we are interested in the reflog. Therefore you must use
git log -g deleted@{1} insted of git log -g deleted to
walk a deleted reflog.
In both cases, we also tighten up the mode-checking when
opening the reflogs. dwim_log checks that the entry we found
is a regular file (not a directory) to avoid D/F confusion
(e.g., you ask for foo but foo/bar exists and we find
the foo but it is a directory).
However, read_ref_at and for_each_reflog_ent did not do this
check, and relied on earlier parts of the code to have
verified the log they are about to open. This meant that
even before this patch, a race condition in changing refs
between dwim_log and the actual read could cause bizarre
errors (e.g., read_ref_at would open and try to mmap a
directory). This patch makes it even easier to trigger those
conditions (because the ref namespace and the fallback
graveyard namespace can have D/F ambiguity for a certain
path). To solve this, we check the mode of the file we open
and treat it as if it did not exist if it is not a regular
file (this is the same way dwim_log handles it).
Signed-off-by: Jeff King p...@peff.net
This may or may not be related, but I vaguely recall that log -g
traversal hack had a corner case where the walking stops prematurely
upon seeing a gap (or creation/deletion that has 0{40})? Do you
recall if we have ever dealt with that?
The patch seems fine from a cursory look. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
