* Re: [PATCH] Fix expected values of setup tests on Windows
From: Junio C Hamano @ 2011-01-02 1:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jonathan Nieder, Nguyen Thai Ngoc Duy, git
In-Reply-To: <201012312321.31294.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Freitag, 31. Dezember 2010, Jonathan Nieder wrote:
>> Johannes Sixt wrote:
>> > On Freitag, 31. Dezember 2010, Nguyen Thai Ngoc Duy wrote:
>> >> in your patch does not. Does bash auto convert value in
>> >> TRASH_DIRECTORY="$TE..." line?
>> >
>> > No. When this line is executed:
>> >
>> > TEST_DIRECTORY=$(pwd)
>> >
>> > $(pwd) still has its default behavior to return the POSIX style path. pwd
>> > is redefined to pwd -W only later.
>>
>> Would it make sense to change it to
>>
>> TEST_DIRECTORY=$PWD
>>
>> for clarity and robustness against code movement, then?
>
> Yes, that would make sense.
It will be very much appreciated to add a few sentences to clarify this to
"Do's and don'ts" section of t/README if you are re-rolling this. Thanks.
^ permalink raw reply
* [RFC PATCH] Why doesn't git rebase --interactive --preserve-merges continue past known conflicts?
From: David D. Kilzer @ 2011-01-02 1:20 UTC (permalink / raw)
To: git; +Cc: David D. Kilzer
In-Reply-To: <282560.39741.qm@web30004.mail.mud.yahoo.com>
On 2010-12-31, David Kilzer wrote:
> When I run "git rebase --interactive --preserve-merges" on a sequence of
> commits, edit an earlier commit, then run "git rebase --continue", the rebase
> operation always stops on a merge commit with a known conflict (in the rr-cache)
> instead of resolving it and continuing.
>
> As long as I'm not rearranging commits, I expect git-rebase to resolve the known
> merge commit conflict and continue. Why does it always stop?
Here's a very rough patch that fixes my original test case so that an interactive
rebase won't stop when git-rerere knows how to resolve all conflicts during a
merge.
However, if there are any changes to a non-conflicted file during the original
merge commit, they will be lost when rebasing, even with --preserve-merges.
Note that this occurs even without this patch applied. You must compare the
current commit with original being rebased to make sure they're not lost.
Why doesn't an interactive rebase serialize to disk all of the changes in a merge
commit like it does for non-merge commits?
Dave
---
git-rebase--interactive.sh | 11 ++++-
t/t3404-rebase-interactive-preserve-merges.sh | 64 +++++++++++++++++++++++++
2 files changed, 73 insertions(+), 2 deletions(-)
create mode 100755 t/t3404-rebase-interactive-preserve-merges.sh
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a5ffd9a..32375bc 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -338,11 +338,18 @@ pick_one_preserving_merges () {
msg="$(commit_message $sha1)"
# No point in merging the first parent, that's HEAD
new_parents=${new_parents# $first_parent}
+ # If rerere is enabled, pass the --rerere-autoupdate flag
+ test "$(git config --bool rerere.enabled)" = "true" &&
+ rerere_autoupdate=--rerere-autoupdate || rerere_autoupdate=
if ! do_with_author output \
- git merge $STRATEGY -m "$msg" $new_parents
+ git merge $STRATEGY $rerere_autoupdate -m "$msg" $new_parents
then
printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
- die_with_patch $sha1 "Error redoing merge $sha1"
+ # Commit the result if rerere resolved all the conflicts.
+ git update-index -q --refresh &&
+ printf "Resolved all conflicts using rerere.\n" &&
+ do_with_author git commit --no-verify -F "$GIT_DIR"/MERGE_MSG ||
+ die_with_patch $sha1 "Error redoing merge $sha1"
fi
echo "$sha1 $(git rev-parse HEAD^0)" >> "$REWRITTEN_LIST"
;;
diff --git a/t/t3404-rebase-interactive-preserve-merges.sh b/t/t3404-rebase-interactive-preserve-merges.sh
new file mode 100755
index 0000000..3479f38
--- /dev/null
+++ b/t/t3404-rebase-interactive-preserve-merges.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+# Copyright (c) 2010 David D. Kilzer
+#
+
+test_description='git rebase --interactive --preserve-matches does not automatically resolve known conflicts in merge commits'
+. ./test-lib.sh
+
+. "$TEST_DIRECTORY"/lib-rebase.sh
+
+set_fake_editor
+
+test_expect_success 'setup' '
+ test_commit A file1 &&
+ test_commit AA file2 &&
+ test_commit B file1 &&
+ git checkout -b topic1 HEAD^ &&
+ test_commit C file1 &&
+ git checkout master
+'
+
+test_expect_success 'rebase --interactive --preserve-merges should use rerere to resolve conflicts' '
+ git config rerere.enabled 1 &&
+ git rerere clear &&
+
+ git checkout -b merge1 master &&
+ test_must_fail git merge topic1 &&
+ printf "B\nC\n" > file1 &&
+ git add file1 &&
+ git commit -m "Merged." &&
+ git branch merge1-baseline &&
+
+ FAKE_LINES="edit 1 2" git rebase -i -p HEAD~2 &&
+ echo BB >> file2 &&
+ git add file2 &&
+ git commit --amend &&
+ git rebase --continue &&
+ git diff --exit-code merge1-baseline..merge1 file1
+'
+
+test_expect_success 'rebase --interactive --preserve-merges should not lose changes in merge commits' '
+ git config rerere.enabled 1 &&
+ git rerere clear &&
+
+ git checkout -b merge2 master &&
+ test_must_fail git merge topic1 &&
+ printf "B\nC\n" > file1 &&
+ git add file1 &&
+ echo BB >> file2 &&
+ git add file2 &&
+ git commit -m "Merged with change to non-conflicted file." &&
+ git branch merge2-baseline &&
+
+ FAKE_LINES="edit 1 2" git rebase -i -p HEAD~2 &&
+ echo AAA > file3 &&
+ git add file3 &&
+ git commit --amend &&
+ git rebase --continue &&
+ git diff --exit-code merge2-baseline..merge2 file1 &&
+ git diff --exit-code merge2-baseline..merge2 file2
+'
+
+test_done
--
1.7.2.1.103.g48452
^ permalink raw reply related
* Web browser and Git wiki (kernel.org) not getting along....
From: Drew Northup @ 2011-01-02 4:16 UTC (permalink / raw)
To: git
Are any other Opera users getting this error when attempting to go to
https://git.wiki.kernel.org ?
"Unable to complete secure transaction
You tried to access the address
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools,
which is currently unavailable. Please make sure that the web address
(URL) is correctly spelled and punctuated, then try reloading the page.
Secure connection: fatal error (112) from server.
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools
Transmission failure.
....."
I'm trying to figure out of this is a pure Opera problem or just a
RedHat problem (ugh). (I'm also pretty darn sure that the server is up,
as it loads up just fine in Firefox.....)
Unless lots of other people on the list are interested I don't see the
point in splattering replies back to it until (unless?) something
interesting comes up, so this may be a case when culling the CC list is
ok...
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
From: Ralf Wildenhues @ 2011-01-02 6:00 UTC (permalink / raw)
To: git
This avoids warnings from Autoconf 2.68 about missing use of
AC_LANG_PROGRAM and friends.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
The patch should not cause any semantic changes in the generated
configure script.
Thanks,
Ralf
aclocal.m4 | 4 ++--
configure.ac | 56 +++++++++++++++++++-------------------------------------
2 files changed, 21 insertions(+), 39 deletions(-)
diff --git a/aclocal.m4 b/aclocal.m4
index d399de2..f11bc7e 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -13,7 +13,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
git_cv_socklen_t_equiv=
for arg2 in "struct sockaddr" void; do
for t in int size_t unsigned long "unsigned long"; do
- AC_TRY_COMPILE([
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
#include <sys/types.h>
#include <sys/socket.h>
@@ -21,7 +21,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
],[
$t len;
getpeername(0,0,&len);
- ],[
+ ])],[
git_cv_socklen_t_equiv="$t"
break 2
])
diff --git a/configure.ac b/configure.ac
index 5792425..20039c5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -345,7 +345,7 @@ esac
AC_CACHE_CHECK([if linker supports -R], git_cv_ld_dashr, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -R /"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_dashr" = "yes"; then
@@ -354,7 +354,7 @@ else
AC_CACHE_CHECK([if linker supports -Wl,-rpath,], git_cv_ld_wl_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -Wl,-rpath,/"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_wl_rpath=yes], [git_cv_ld_wl_rpath=no])
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_rpath=yes], [git_cv_ld_wl_rpath=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_wl_rpath" = "yes"; then
@@ -363,7 +363,7 @@ else
AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -rpath /"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_rpath=yes], [git_cv_ld_rpath=no])
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_rpath=yes], [git_cv_ld_rpath=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_rpath" = "yes"; then
@@ -472,15 +472,9 @@ if test -z "$NO_ICONV"; then
GIT_STASH_FLAGS($ICONVDIR)
-AC_DEFUN([ICONVTEST_SRC], [
-#include <iconv.h>
-
-int main(void)
-{
- iconv_open("", "");
- return 0;
-}
-])
+AC_DEFUN([ICONVTEST_SRC],
+[AC_LANG_PROGRAM([#include <iconv.h>],
+ [iconv_open("", "");])])
if test -n "$ICONVDIR"; then
lib_order="-liconv -lc"
@@ -500,7 +494,7 @@ for l in $lib_order; do
old_LIBS="$LIBS"
LIBS="$LIBS $l"
AC_MSG_CHECKING([for iconv in $l])
- AC_LINK_IFELSE(ICONVTEST_SRC,
+ AC_LINK_IFELSE([ICONVTEST_SRC],
[AC_MSG_RESULT([yes])
NO_ICONV=
break],
@@ -528,18 +522,12 @@ fi
GIT_STASH_FLAGS($ZLIB_PATH)
AC_DEFUN([ZLIBTEST_SRC], [
-#include <zlib.h>
-
-int main(void)
-{
- deflateBound(0, 0);
- return 0;
-}
-])
+AC_LANG_PROGRAM([#include <zlib.h>],
+ [deflateBound(0, 0);])])
AC_MSG_CHECKING([for deflateBound in -lz])
old_LIBS="$LIBS"
LIBS="$LIBS -lz"
-AC_LINK_IFELSE(ZLIBTEST_SRC,
+AC_LINK_IFELSE([ZLIBTEST_SRC],
[AC_MSG_RESULT([yes])],
[AC_MSG_RESULT([no])
NO_DEFLATE_BOUND=yes])
@@ -631,23 +619,19 @@ AC_SUBST(NO_INTTYPES_H)
#
# Define OLD_ICONV if your library has an old iconv(), where the second
# (input buffer pointer) parameter is declared with type (const char **).
-AC_DEFUN([OLDICONVTEST_SRC], [[
+AC_DEFUN([OLDICONVTEST_SRC], [
+AC_LANG_PROGRAM([[
#include <iconv.h>
extern size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
-
-int main(void)
-{
- return 0;
-}
-]])
+]], [])])
GIT_STASH_FLAGS($ICONVDIR)
AC_MSG_CHECKING([for old iconv()])
-AC_COMPILE_IFELSE(OLDICONVTEST_SRC,
+AC_COMPILE_IFELSE([OLDICONVTEST_SRC],
[AC_MSG_RESULT([no])],
[AC_MSG_RESULT([yes])
OLD_ICONV=UnfortunatelyYes])
@@ -931,18 +915,16 @@ AC_SUBST(NO_INITGROUPS)
#
# Define PTHREAD_LIBS to the linker flag used for Pthread support.
AC_DEFUN([PTHREADTEST_SRC], [
+AC_LANG_PROGRAM([[
#include <pthread.h>
-
-int main(void)
-{
+]], [[
pthread_mutex_t test_mutex;
int retcode = 0;
retcode |= pthread_mutex_init(&test_mutex,(void *)0);
retcode |= pthread_mutex_lock(&test_mutex);
retcode |= pthread_mutex_unlock(&test_mutex);
return retcode;
-}
-])
+]])])
dnl AC_LANG_CONFTEST([AC_LANG_PROGRAM(
dnl [[#include <pthread.h>]],
@@ -962,7 +944,7 @@ elif test -z "$PTHREAD_CFLAGS"; then
old_CFLAGS="$CFLAGS"
CFLAGS="$opt $CFLAGS"
AC_MSG_CHECKING([Checking for POSIX Threads with '$opt'])
- AC_LINK_IFELSE(PTHREADTEST_SRC,
+ AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
PTHREAD_LIBS="$opt"
@@ -982,7 +964,7 @@ else
old_CFLAGS="$CFLAGS"
CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
AC_MSG_CHECKING([Checking for POSIX Threads with '$PTHREAD_CFLAGS'])
- AC_LINK_IFELSE(PTHREADTEST_SRC,
+ AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
PTHREAD_LIBS="$PTHREAD_CFLAGS"
--
1.7.4.rc0
^ permalink raw reply related
* [PATCH] Fix typos in the documentation
From: Ralf Wildenhues @ 2011-01-02 5:56 UTC (permalink / raw)
To: git
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
Based on master not maint as the former has more typos.
Thanks for git,
Ralf
Documentation/CodingGuidelines | 2 +-
Documentation/RelNotes/1.7.4.txt | 9 ++++-----
Documentation/config.txt | 4 ++--
Documentation/git-add.txt | 2 +-
Documentation/git-bundle.txt | 2 +-
Documentation/git-fmt-merge-msg.txt | 2 +-
Documentation/git-remote-ext.txt | 16 ++++++++--------
Documentation/git-remote-fd.txt | 8 ++++----
Documentation/git-svn.txt | 2 +-
Documentation/gitmodules.txt | 2 +-
Documentation/merge-config.txt | 2 +-
Documentation/technical/api-sigchain.txt | 2 +-
12 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 1b1c45d..ba2006d 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -157,7 +157,7 @@ Writing Documentation:
--sort=<key>
--abbrev[=<n>]
- Possibility of multiple occurences is indicated by three dots:
+ Possibility of multiple occurrences is indicated by three dots:
<file>...
(One or more of <file>.)
diff --git a/Documentation/RelNotes/1.7.4.txt b/Documentation/RelNotes/1.7.4.txt
index b736d39..5619641 100644
--- a/Documentation/RelNotes/1.7.4.txt
+++ b/Documentation/RelNotes/1.7.4.txt
@@ -8,12 +8,11 @@ Updates since v1.7.3
docbook-xsl >= 1.73. If you have older versions, you can set
ASCIIDOC7 and ASCIIDOC_ROFF, respectively.
- * The option parsers of various commands that create new branch (or
+ * The option parsers of various commands that create new branches (or
rename existing ones to a new name) were too loose and users were
- allowed to call a branch with a name that begins with a dash by
- creative abuse of their command line options, which only lead to
- burn themselves. The name of a branch cannot begin with a dash
- now.
+ allowed to give a branch a name that begins with a dash by creative
+ abuse of their command line options, which only led to burn themselves.
+ The name of a branch cannot begin with a dash now.
* System-wide fallback default attributes can be stored in
/etc/gitattributes; core.attributesfile configuration variable can
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a8759cf..ff7c225 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -892,7 +892,7 @@ diff.wordRegex::
fetch.recurseSubmodules::
A boolean value which changes the behavior for fetch and pull, the
- default is to not recursively fetch populated sumodules unless
+ default is to not recursively fetch populated submodules unless
configured otherwise.
fetch.unpackLimit::
@@ -1811,7 +1811,7 @@ submodule.<name>.update::
submodule.<name>.fetchRecurseSubmodules::
This option can be used to enable/disable recursive fetching of this
- submodule. It can be overriden by using the --[no-]recurse-submodules
+ submodule. It can be overridden by using the --[no-]recurse-submodules
command line option to "git fetch" and "git pull".
This setting will override that from in the linkgit:gitmodules[5]
file.
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 54aaaeb..a03448f 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -333,7 +333,7 @@ likely to introduce confusing changes to the index.
There are also more complex operations that can be performed. But beware
that because the patch is applied only to the index and not the working
tree, the working tree will appear to "undo" the change in the index.
-For example, introducing a a new line into the index that is in neither
+For example, introducing a new line into the index that is in neither
the HEAD nor the working tree will stage the new line for commit, but
the line will appear to be reverted in the working tree.
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 6266a3a..299007b 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -59,7 +59,7 @@ unbundle <file>::
<git-rev-list-args>::
A list of arguments, acceptable to 'git rev-parse' and
- 'git rev-list' (and containg a named ref, see SPECIFYING REFERENCES
+ 'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES
below), that specifies the specific objects and references
to transport. For example, `master{tilde}10..master` causes the
current master reference to be packaged along with all objects
diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt
index 40dba8c..75adf7a 100644
--- a/Documentation/git-fmt-merge-msg.txt
+++ b/Documentation/git-fmt-merge-msg.txt
@@ -57,7 +57,7 @@ merge.log::
In addition to branch names, populate the log message with at
most the specified number of one-line descriptions from the
actual commits that are being merged. Defaults to false, and
- true is a synoym for 20.
+ true is a synonym for 20.
merge.summary::
Synonym to `merge.log`; this is deprecated and will be removed in
diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt
index f4fbf67..2d65cfe 100644
--- a/Documentation/git-remote-ext.txt
+++ b/Documentation/git-remote-ext.txt
@@ -15,12 +15,12 @@ This remote helper uses the specified 'program' to connect
to a remote git server.
Data written to stdin of this specified 'program' is assumed
-to be sent to git:// server, git-upload-pack, git-receive-pack
+to be sent to a git:// server, git-upload-pack, git-receive-pack
or git-upload-archive (depending on situation), and data read
from stdout of this program is assumed to be received from
the same service.
-Command and arguments are separated by unescaped space.
+Command and arguments are separated by an unescaped space.
The following sequences have a special meaning:
@@ -39,19 +39,19 @@ The following sequences have a special meaning:
git-upload-pack, or git-upload-archive) of the service
git wants to invoke.
-'%G' (must be first characters in argument)::
+'%G' (must be the first characters in an argument)::
This argument will not be passed to 'program'. Instead, it
- will cause helper to start by sending git:// service request to
- remote side with service field set to approiate value and
- repository field set to rest of the argument. Default is not to send
- such request.
+ will cause the helper to start by sending git:// service requests to
+ the remote side with the service field set to an appropriate value and
+ the repository field set to rest of the argument. Default is not to send
+ such a request.
+
This is useful if remote side is git:// server accessed over
some tunnel.
'%V' (must be first characters in argument)::
This argument will not be passed to 'program'. Instead it sets
- the vhost field in git:// service request (to rest of the argument).
+ the vhost field in the git:// service request (to rest of the argument).
Default is not to send vhost in such request (if sent).
ENVIRONMENT VARIABLES:
diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt
index abc4944..4aecd4d 100644
--- a/Documentation/git-remote-fd.txt
+++ b/Documentation/git-remote-fd.txt
@@ -11,20 +11,20 @@ SYNOPSIS
DESCRIPTION
-----------
-This helper uses specified file descriptors to connect to remote git server.
+This helper uses specified file descriptors to connect to a remote git server.
This is not meant for end users but for programs and scripts calling git
fetch, push or archive.
-If only <infd> is given, it is assumed to be bidirectional socket connected
+If only <infd> is given, it is assumed to be a bidirectional socket connected
to remote git server (git-upload-pack, git-receive-pack or
git-upload-achive). If both <infd> and <outfd> are given, they are assumed
-to be pipes connected to remote git server (<infd> being the inbound pipe
+to be pipes connected to a remote git server (<infd> being the inbound pipe
and <outfd> being the outbound pipe.
It is assumed that any handshaking procedures have already been completed
(such as sending service request for git://) before this helper is started.
-<anything> can be any string. It is ignored. It is meant for provoding
+<anything> can be any string. It is ignored. It is meant for providing
information to user in the URL in case that URL is displayed in some
context.
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 139d314..254d044 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -613,7 +613,7 @@ old references to SVN revision numbers in existing documentation, bug
reports and archives. If you plan to eventually migrate from SVN to git
and are certain about dropping SVN history, consider
linkgit:git-filter-branch[1] instead. filter-branch also allows
-reformating of metadata for ease-of-reading and rewriting authorship
+reformatting of metadata for ease-of-reading and rewriting authorship
info for non-"svn.authorsFile" users.
svn.useSvmProps::
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 6c93202..6897794 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -49,7 +49,7 @@ submodule.<name>.fetchRecurseSubmodules::
submodule. If this option is also present in the submodules entry in
.git/config of the superproject, the setting there will override the
one found in .gitmodules.
- Both settings can be overriden on the command line by using the
+ Both settings can be overridden on the command line by using the
"--[no-]recurse-submodules" option to "git fetch" and "git pull"..
submodule.<name>.ignore::
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 92772e7..1e5c22c 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -10,7 +10,7 @@ merge.log::
In addition to branch names, populate the log message with at
most the specified number of one-line descriptions from the
actual commits that are being merged. Defaults to false, and
- true is a synoym for 20.
+ true is a synonym for 20.
merge.renameLimit::
The number of files to consider when performing rename detection
diff --git a/Documentation/technical/api-sigchain.txt b/Documentation/technical/api-sigchain.txt
index 535cdff..9e1189e 100644
--- a/Documentation/technical/api-sigchain.txt
+++ b/Documentation/technical/api-sigchain.txt
@@ -32,7 +32,7 @@ and installation code should look something like:
}
------------------------------------------
-Handlers are given the typdef of sigchain_fun. This is the same type
+Handlers are given the typedef of sigchain_fun. This is the same type
that is given to signal() or sigaction(). It is perfectly reasonable to
push SIG_DFL or SIG_IGN onto the stack.
--
1.7.4.rc0
^ permalink raw reply related
* Re: Web browser and Git wiki (kernel.org) not getting along....
From: J.H. @ 2011-01-02 7:58 UTC (permalink / raw)
To: Drew Northup; +Cc: git
In-Reply-To: <1293941768.30849.32.camel@drew-northup.unet.maine.edu>
On 01/01/2011 08:16 PM, Drew Northup wrote:
> Are any other Opera users getting this error when attempting to go to
> https://git.wiki.kernel.org ?
Known bug in Opera, the problem lies in how it handles wild card
certificates. It is claimed to be fixed in the next version by another
user who has pushed the issue with Opera.
> "Unable to complete secure transaction
>
> You tried to access the address
> https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools,
> which is currently unavailable. Please make sure that the web address
> (URL) is correctly spelled and punctuated, then try reloading the page.
>
> Secure connection: fatal error (112) from server.
>
> https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools
>
> Transmission failure.
> ....."
>
> I'm trying to figure out of this is a pure Opera problem or just a
> RedHat problem (ugh). (I'm also pretty darn sure that the server is up,
> as it loads up just fine in Firefox.....)
Pure Opera, it works fine from every other browser.
> Unless lots of other people on the list are interested I don't see the
> point in splattering replies back to it until (unless?) something
> interesting comes up, so this may be a case when culling the CC list is
> ok...
- John 'Warthog9' Hawley
Chief Kernel.org Administrator
^ permalink raw reply
* Re: [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
From: Jonathan Nieder @ 2011-01-02 7:59 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20110102060044.GJ19818@gmx.de>
Ralf Wildenhues wrote:
> This avoids warnings from Autoconf 2.68 about missing use of
> AC_LANG_PROGRAM and friends.
>
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> ---
>
> The patch should not cause any semantic changes in the generated
> configure script.
This part belongs in the commit message too, imho (though no need to
resend just for that, of course).
> --- a/configure.ac
> +++ b/configure.ac
> @@ -345,7 +345,7 @@ esac
> AC_CACHE_CHECK([if linker supports -R], git_cv_ld_dashr, [
> SAVE_LDFLAGS="${LDFLAGS}"
> LDFLAGS="${SAVE_LDFLAGS} -R /"
> - AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
> + AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
Could you say a few words about the effect of this? Mostly because
it would be useful to people down the line tempted to make the same
mistake again.
> @@ -500,7 +494,7 @@ for l in $lib_order; do
> old_LIBS="$LIBS"
> LIBS="$LIBS $l"
> AC_MSG_CHECKING([for iconv in $l])
> - AC_LINK_IFELSE(ICONVTEST_SRC,
> + AC_LINK_IFELSE([ICONVTEST_SRC],
I'm curious about this one, too.
> @@ -931,18 +915,16 @@ AC_SUBST(NO_INITGROUPS)
> #
> # Define PTHREAD_LIBS to the linker flag used for Pthread support.
> AC_DEFUN([PTHREADTEST_SRC], [
> +AC_LANG_PROGRAM([[
> #include <pthread.h>
> -
> -int main(void)
> -{
> +]], [[
> pthread_mutex_t test_mutex;
By the way, what problem is the warning about AC_LANG_PROGRAM meant to
prevent? (Just curious. A five-minute google search didn't reveal
anything obvious.)
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
From: Ralf Wildenhues @ 2011-01-02 9:47 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20110102075953.GB8937@burratino>
* Jonathan Nieder wrote on Sun, Jan 02, 2011 at 08:59:53AM CET:
> Ralf Wildenhues wrote:
>
> > The patch should not cause any semantic changes in the generated
> > configure script.
>
> This part belongs in the commit message too, imho (though no need to
> resend just for that, of course).
Yeah, you're right.
> > - AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
> > + AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
>
> Could you say a few words about the effect of this? Mostly because
> it would be useful to people down the line tempted to make the same
> mistake again.
Allow me to quote autoconf-2.68/NEWS:
** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use
AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file
contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have
a compelling reason why you cannot use AC_LANG_SOURCE but must
avoid the warning.
The underlying reason for this change is that AC_LANG_{SOURCE,PROGRAM}
take care to actually supply the previously computed set of #defines
(and include the standard headers if so desired), for preprocessed
languages like C and C++. In the above case, AC_LANG_PROGRAM is already
used, but not sufficiently m4-quoted, so that the autoconf warning will
be triggered bogusly.
The general rule for m4 quotation is: one set of quotes for each macro
argument, e.g.:
MACRO1([arg with MACRO2([arg], [arg])], [arg], ...)
and for innermost arguments which need to undergo no m4 expansion at all
a double set of quotes should be used, e.g.:
AC_LANG_SOURCE([[int s[42]; /* Program sources containing brackets. */]])
Only for some special macros that need to be expanded before recursion
no quoting should be used.
These and more rules are described in detail in 'info Autoconf
"Programming in M4"'. The rules can often be relaxed when the macro
arguments contain no active characters like comma, brackets or other
macro invocations themselves, but IMVHO it is easier getting used to
just quote things normally.
> > @@ -500,7 +494,7 @@ for l in $lib_order; do
> > old_LIBS="$LIBS"
> > LIBS="$LIBS $l"
> > AC_MSG_CHECKING([for iconv in $l])
> > - AC_LINK_IFELSE(ICONVTEST_SRC,
> > + AC_LINK_IFELSE([ICONVTEST_SRC],
>
> I'm curious about this one, too.
Likewise this is just underquotation leading to false positive.
> > @@ -931,18 +915,16 @@ AC_SUBST(NO_INITGROUPS)
> > #
> > # Define PTHREAD_LIBS to the linker flag used for Pthread support.
> > AC_DEFUN([PTHREADTEST_SRC], [
> > +AC_LANG_PROGRAM([[
> > #include <pthread.h>
> > -
> > -int main(void)
> > -{
> > +]], [[
> > pthread_mutex_t test_mutex;
>
> By the way, what problem is the warning about AC_LANG_PROGRAM meant to
> prevent? (Just curious. A five-minute google search didn't reveal
> anything obvious.)
See above.
I would be happy to update the patch in a way that makes it more
helpful, but most of the above is fairly general Autoconf rules,
so I'm not sure what you need (being blinded by looking at this
stuff too often).
Cheers,
Ralf
^ permalink raw reply
* Re: Push to all repositories
From: Enrico Weigelt @ 2011-01-02 9:54 UTC (permalink / raw)
To: git
In-Reply-To: <20101209195204.GB6884@burratino>
* Jonathan Nieder <jrnieder@gmail.com> wrote:
> Consider a project in a patches+tarballs workflow. It begins like
> this:
>
> 1. Acquire a tarball with the version you want to base your work on.
> 2. Untar.
> 3. Copy the result to save the current state.
> 4. Test it.
> 5. Fix a bug or add a feature.
> 6. Make a patch with "diff -pruN"
> 7. Return to step 3.
> ...
> 8. Looks good; email out the patches to get some feedback.
>
> Now another person wants to test the patches; so she tries:
>
> 1. Acquire a tarball with the version you want to test against.
> 2. Untar.
> 3. Apply patches with "patch -p1".
>
> Wait a second --- the patches don't apply! Or worse, they
> apply but the result is broken. Okay:
>
> 4. Complain to the patch author.
>
> Finally the patch author has more work to do:
>
> 9. Acquire a newer tarball, and use either "patch --reject-file"
> or rcs "merge" to reconcile the differences. Email out the
> result.
Compared to git:
1. Clone repo and checkout the desired version
2. Fix a bug or add a feature and commit to your local branch
3. Do your tests and cleanups (eg. cleanups w/ interactive rebase)
3. Push your branch to some place others can catch it and
announce it to others
Now another person wants to test your version:
1. Clone your repo and checkout your branch.
--> there is nothing that could fail to apply - everything's consistant
by design (assuming the repo was cleanly cloned ;-o)
2. Possibly become an author yourself:
a. rebase to a newer upstream version
--> same as above
> The result is a sequence of snapshots that have been _tested_ to work
> correctly. Now compare the svn workflow I briefly used at work:
>
> 1. svn update
> 2. hack hack hack
> 3. svn update
> 4. hack hack hack
> 5. svn update
> 6. hack hack hack
> 7. send out a patch for feedback
SVN has a quite bad idea of branches and isn't even near to support
things like rebasing anyhow.
> Unfortunately, the version committed (1) does not reflect the
> development history and (2) is not even tested, if changes
> happened in trunk between step 9 and step 10.
The idea of having everything in a big trunk is, aehm, quite suboptimal.
Better: have each issue in its own branch, that gets rebased to the
mainline frequently and merged back there when properly tested.
> Of course in the opposite direction is
>
> - changes to workflow can be hard for a team to adjust to
>
> (i.e., "don't fix what isn't broken").
Well, many people tend to stick in old ideas (including workflows),
no matter what newer developments are made. I currently have to cope
with that in an customer project: most of the people here don't even
consider using branches since the only vcs'es they know have no really
usable support for this (TFS, etc ;-o), and they refuse to learn
something new as long as their old way seems to work somehow (no matter
of costs). I've estimated the productivity loss caused by sticking
backwards cruft like TFS on factors of 5..10 - nobody cares.
(actually, not really bad for me: the longer it takes, the more
money I earn ;-P)
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
From: Jonathan Nieder @ 2011-01-02 10:00 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20110102094730.GA10365@gmx.de>
Ralf Wildenhues wrote:
> See above.
>
> I would be happy to update the patch in a way that makes it more
> helpful, but most of the above is fairly general Autoconf rules,
> so I'm not sure what you need (being blinded by looking at this
> stuff too often).
A little essay in the commit message should be sufficient. Something
vaguely like this, maybe. (cut and pasted from the above)
This avoids warnings from Autoconf 2.68 about missing use of
AC_LANG_PROGRAM and friends.
Allow me to quote autoconf-2.68/NEWS:
** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use
AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file
contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have
a compelling reason why you cannot use AC_LANG_SOURCE but must
avoid the warning.
The underlying reason for this change is that AC_LANG_{SOURCE,PROGRAM}
take care to actually supply the previously computed set of #defines
(and include the standard headers if so desired), for preprocessed
languages like C and C++.
In some cases, AC_LANG_PROGRAM is already used but not sufficiently
m4-quoted, so we just need to add another set of [quotes] to prevent
the autoconf warning from being triggered bogusly. Quoting all
arguments (except when calling special macros that _need_ to be
expanded before recursion) is better style, anyway. These and more
rules are described in detail in 'info Autoconf "Programming in M4"'.
The patch should not cause any semantic changes in the generated
configure script.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
^ permalink raw reply
* [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
From: Ralf Wildenhues @ 2011-01-02 10:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20110102100012.GA12284@burratino>
This avoids warnings from Autoconf 2.68 about missing use of
AC_LANG_PROGRAM and friends.
Quoting autoconf-2.68/NEWS:
** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use
AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file
contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have
a compelling reason why you cannot use AC_LANG_SOURCE but must
avoid the warning.
The underlying reason for this change is that AC_LANG_{SOURCE,PROGRAM}
take care to actually supply the previously computed set of #defines
(and include the standard headers if so desired), for preprocessed
languages like C and C++.
In some cases, AC_LANG_PROGRAM is already used but not sufficiently
m4-quoted, so we just need to add another set of [quotes] to prevent
the autoconf warning from being triggered bogusly. Quoting all
arguments (except when calling special macros that _need_ to be
expanded before recursion) is better style, anyway. These and more
rules are described in detail in 'info Autoconf "Programming in M4"'.
The patch should not cause any semantic changes in the generated
configure script.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
* Jonathan Nieder wrote on Sun, Jan 02, 2011 at 11:00:12AM CET:
> Ralf Wildenhues wrote:
>
> > I would be happy to update the patch in a way that makes it more
> > helpful, but most of the above is fairly general Autoconf rules,
> > so I'm not sure what you need (being blinded by looking at this
> > stuff too often).
>
> A little essay in the commit message should be sufficient. Something
> vaguely like this, maybe. (cut and pasted from the above)
Thank you for your help! Resending like this.
Cheers,
Ralf
aclocal.m4 | 4 ++--
configure.ac | 56 +++++++++++++++++++-------------------------------------
2 files changed, 21 insertions(+), 39 deletions(-)
diff --git a/aclocal.m4 b/aclocal.m4
index d399de2..f11bc7e 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -13,7 +13,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
git_cv_socklen_t_equiv=
for arg2 in "struct sockaddr" void; do
for t in int size_t unsigned long "unsigned long"; do
- AC_TRY_COMPILE([
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
#include <sys/types.h>
#include <sys/socket.h>
@@ -21,7 +21,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
],[
$t len;
getpeername(0,0,&len);
- ],[
+ ])],[
git_cv_socklen_t_equiv="$t"
break 2
])
diff --git a/configure.ac b/configure.ac
index 5792425..20039c5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -345,7 +345,7 @@ esac
AC_CACHE_CHECK([if linker supports -R], git_cv_ld_dashr, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -R /"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_dashr" = "yes"; then
@@ -354,7 +354,7 @@ else
AC_CACHE_CHECK([if linker supports -Wl,-rpath,], git_cv_ld_wl_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -Wl,-rpath,/"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_wl_rpath=yes], [git_cv_ld_wl_rpath=no])
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_rpath=yes], [git_cv_ld_wl_rpath=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_wl_rpath" = "yes"; then
@@ -363,7 +363,7 @@ else
AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -rpath /"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_rpath=yes], [git_cv_ld_rpath=no])
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_rpath=yes], [git_cv_ld_rpath=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_rpath" = "yes"; then
@@ -472,15 +472,9 @@ if test -z "$NO_ICONV"; then
GIT_STASH_FLAGS($ICONVDIR)
-AC_DEFUN([ICONVTEST_SRC], [
-#include <iconv.h>
-
-int main(void)
-{
- iconv_open("", "");
- return 0;
-}
-])
+AC_DEFUN([ICONVTEST_SRC],
+[AC_LANG_PROGRAM([#include <iconv.h>],
+ [iconv_open("", "");])])
if test -n "$ICONVDIR"; then
lib_order="-liconv -lc"
@@ -500,7 +494,7 @@ for l in $lib_order; do
old_LIBS="$LIBS"
LIBS="$LIBS $l"
AC_MSG_CHECKING([for iconv in $l])
- AC_LINK_IFELSE(ICONVTEST_SRC,
+ AC_LINK_IFELSE([ICONVTEST_SRC],
[AC_MSG_RESULT([yes])
NO_ICONV=
break],
@@ -528,18 +522,12 @@ fi
GIT_STASH_FLAGS($ZLIB_PATH)
AC_DEFUN([ZLIBTEST_SRC], [
-#include <zlib.h>
-
-int main(void)
-{
- deflateBound(0, 0);
- return 0;
-}
-])
+AC_LANG_PROGRAM([#include <zlib.h>],
+ [deflateBound(0, 0);])])
AC_MSG_CHECKING([for deflateBound in -lz])
old_LIBS="$LIBS"
LIBS="$LIBS -lz"
-AC_LINK_IFELSE(ZLIBTEST_SRC,
+AC_LINK_IFELSE([ZLIBTEST_SRC],
[AC_MSG_RESULT([yes])],
[AC_MSG_RESULT([no])
NO_DEFLATE_BOUND=yes])
@@ -631,23 +619,19 @@ AC_SUBST(NO_INTTYPES_H)
#
# Define OLD_ICONV if your library has an old iconv(), where the second
# (input buffer pointer) parameter is declared with type (const char **).
-AC_DEFUN([OLDICONVTEST_SRC], [[
+AC_DEFUN([OLDICONVTEST_SRC], [
+AC_LANG_PROGRAM([[
#include <iconv.h>
extern size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
-
-int main(void)
-{
- return 0;
-}
-]])
+]], [])])
GIT_STASH_FLAGS($ICONVDIR)
AC_MSG_CHECKING([for old iconv()])
-AC_COMPILE_IFELSE(OLDICONVTEST_SRC,
+AC_COMPILE_IFELSE([OLDICONVTEST_SRC],
[AC_MSG_RESULT([no])],
[AC_MSG_RESULT([yes])
OLD_ICONV=UnfortunatelyYes])
@@ -931,18 +915,16 @@ AC_SUBST(NO_INITGROUPS)
#
# Define PTHREAD_LIBS to the linker flag used for Pthread support.
AC_DEFUN([PTHREADTEST_SRC], [
+AC_LANG_PROGRAM([[
#include <pthread.h>
-
-int main(void)
-{
+]], [[
pthread_mutex_t test_mutex;
int retcode = 0;
retcode |= pthread_mutex_init(&test_mutex,(void *)0);
retcode |= pthread_mutex_lock(&test_mutex);
retcode |= pthread_mutex_unlock(&test_mutex);
return retcode;
-}
-])
+]])])
dnl AC_LANG_CONFTEST([AC_LANG_PROGRAM(
dnl [[#include <pthread.h>]],
@@ -962,7 +944,7 @@ elif test -z "$PTHREAD_CFLAGS"; then
old_CFLAGS="$CFLAGS"
CFLAGS="$opt $CFLAGS"
AC_MSG_CHECKING([Checking for POSIX Threads with '$opt'])
- AC_LINK_IFELSE(PTHREADTEST_SRC,
+ AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
PTHREAD_LIBS="$opt"
@@ -982,7 +964,7 @@ else
old_CFLAGS="$CFLAGS"
CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
AC_MSG_CHECKING([Checking for POSIX Threads with '$PTHREAD_CFLAGS'])
- AC_LINK_IFELSE(PTHREADTEST_SRC,
+ AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
PTHREAD_LIBS="$PTHREAD_CFLAGS"
--
1.7.4.rc0
^ permalink raw reply related
* Re: how to update a submodule?
From: Jens Lehmann @ 2011-01-02 11:30 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: Seth Robertson, git
In-Reply-To: <20110101203957.GC26920@cs-wsok.swansea.ac.uk>
Am 01.01.2011 21:39, schrieb Oliver Kullmann:
> On Fri, Dec 31, 2010 at 06:42:01PM -0500, Seth Robertson wrote:
> As far as I see that, this doesn't concern the problem how to I update
> one repository with submodules from another repository with "these" submodules
> (as the same paths)?
I'm not sure I completely understand your use case, but submodules are
repositories of their own, so they don't get updated by just pulling
a superproject into another containing the same submodule. The submodule
changes have to be pushed to its own parent repository and can then be
fetched from there into another superproject's submodule.
> Actually, even the simplest case of just cloning a repository with submodules
> doesn't work:
> After cloning, "git submodule status" shows "-", okay so I do "git submodule init",
> which already shows a false understanding --- it shows the URL of the old repository,
> from which the original submodule originated, which is long gone and no longer relevant.
> Then of course "git submodule update" fails, and in the submodule there is just nothing.
Then the URL of the submodule in the .gitmodules file is not up to
date. You can either fix it there or - if you only want to change it
locally - edit the .git/config after the "git submodule init" copied
it there.
> The problem seems to be that the information about the place where to update a
> submodule is in .gitmodules, which git actually has under version control (different
> from other configuration information), and thus copies it verbatimly.
> Okay, then apparently after a clone .gitmodules has to be updated (by hand).
No, the problem seems to be that the remote URL in the submodule has
been changed directly without updating it in the .gitmodules of the
superproject (the recommended way to do that is to change it in the
.gitmodules file and then use "git submodule sync" to activate it).
> So .gitmodules concerns only "git submodule update", not "git pull" from within
> the submodules? This would be good to know, to understand the role of the information
> in .gitmodules (where the task of "git submodule init" is apparently just to
> transport this information to .git/configure ?).
>
> This has the disadvantage, that one has to publish this private
> information about the places where by chance one is pulling from?
Yes, the submodules URL must be available - at least for fetching -
to everyone who wants to clone your superproject (and all changes
made in the submodule which are committed in the superproject must
have been pushed there to be able to check them out in the clone).
> Perhaps I should then put .gitmodules into .gitignore? Or would that have
> bad consequences??
Yes, because then git won't know where the it can clone the submodules
from when you clone your superproject somewhere else.
^ permalink raw reply
* Re: how to update a submodule?
From: Oliver Kullmann @ 2011-01-02 15:55 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Seth Robertson, git
In-Reply-To: <4D2061C7.5050405@web.de>
On Sun, Jan 02, 2011 at 12:30:15PM +0100, Jens Lehmann wrote:
> Am 01.01.2011 21:39, schrieb Oliver Kullmann:
> > On Fri, Dec 31, 2010 at 06:42:01PM -0500, Seth Robertson wrote:
> > As far as I see that, this doesn't concern the problem how to I update
> > one repository with submodules from another repository with "these" submodules
> > (as the same paths)?
>
> I'm not sure I completely understand your use case, but submodules are
> repositories of their own, so they don't get updated by just pulling
> a superproject into another containing the same submodule. The submodule
> changes have to be pushed to its own parent repository and can then be
> fetched from there into another superproject's submodule.
>
I know that --- but if there wouldn't be any savings possible (in terms of using it),
then submodules would be pointless, and so the question is *how* to use them.
I see that my use-case is not understood so I try it:
The good thing with Git is that there are no central repositories.
That's exactly what I want to use, but again and again the automatic
assumptions of "central repositories" are made, which should be actually alien to Git.
More concretely: For a collaboration on a scientific paper (where more and more
people have never seen each other, and this is also the case here) one doesn't
use version-control yet because of all this server-nonsense. Now with Git we can
just toss tarballs of git-archives around! Sent via e-mail (please note that zero
knowledge of git-remotes or whatever is required for that --- that's very important),
these archives float around, without any URL or central repository, but they
are locally merged and whatever. I think that's exactly exploiting the Git philosophy.
So I have a couple of those. Then I have modules to teach, where I organise also various
forms of collaborations with colleagues and students (various networks, various levels
of security).
Then there are software projects. Some private, some not.
All of that happens independently. I have at this time around 15 of such active projects
(some smaller, some rather big).
Now it happens that things are forgotten, updates aren't done, I just forget to copy
a repository from one place to another, etc.
Important that from my main working place at home to the main university working place
there is no network connection, but memory sticks do the job (which is fine and safe).
Sure, I can (and perhaps have to) start writing scripts, which just exploit basic git,
and add some form of super-organisation on top of it.
However I still hope that the task is so common that I can use tools.
To summarise: At some point in time on some machine, a super-repository A is updated,
from various (permanently changing) places etc. No problem with pull itself.
The submodules each needs to be taken care of individually.
Okay, but then I want to take that whole thing, the supermodule with the 15 (or more)
submodules, copy it to the memory stick, and on my workplace untar it (decrypt it ...),
and update a super-repository B *over there*, just from A, which has nothing to
do how I created A (on a different machine, completely different circumstances).
It seems to fully comply with the original Git philosophy, that I can make some
form of "super-pull" from B, getting everything from A --- without the assumption
of some central URL (repository), neither for the supermodule nor for the submodules.
Just pulling everything over, as it happens with ordinary "git pull".
> > Actually, even the simplest case of just cloning a repository with submodules
> > doesn't work:
> > After cloning, "git submodule status" shows "-", okay so I do "git submodule init",
> > which already shows a false understanding --- it shows the URL of the old repository,
> > from which the original submodule originated, which is long gone and no longer relevant.
> > Then of course "git submodule update" fails, and in the submodule there is just nothing.
>
> Then the URL of the submodule in the .gitmodules file is not up to
> date. You can either fix it there or - if you only want to change it
> locally - edit the .git/config after the "git submodule init" copied
> it there.
>
That file .gitmodule seems to enforce the central structure, contradicting the original
(and great!) Git insight of fully distributed version control.
> > The problem seems to be that the information about the place where to update a
> > submodule is in .gitmodules, which git actually has under version control (different
> > from other configuration information), and thus copies it verbatimly.
> > Okay, then apparently after a clone .gitmodules has to be updated (by hand).
>
> No, the problem seems to be that the remote URL in the submodule has
> been changed directly without updating it in the .gitmodules of the
> superproject (the recommended way to do that is to change it in the
> .gitmodules file and then use "git submodule sync" to activate it).
>
Again, I hope by now it is clear that in my cases it makes no sense
to attribute an URL to the submodule.
> > So .gitmodules concerns only "git submodule update", not "git pull" from within
> > the submodules? This would be good to know, to understand the role of the information
> > in .gitmodules (where the task of "git submodule init" is apparently just to
> > transport this information to .git/configure ?).
> >
> > This has the disadvantage, that one has to publish this private
> > information about the places where by chance one is pulling from?
>
> Yes, the submodules URL must be available - at least for fetching -
> to everyone who wants to clone your superproject (and all changes
> made in the submodule which are committed in the superproject must
> have been pushed there to be able to check them out in the clone).
>
Then submodules would be a wrong concept, as it seems to me, contradicting
decentralised version control. Still I have the hope that actually
submodule can be used, but apparently that file .gitmodules is in the way
(false information is much worse than no information!).
> > Perhaps I should then put .gitmodules into .gitignore? Or would that have
> > bad consequences??
>
> Yes, because then git won't know where the it can clone the submodules
> from when you clone your superproject somewhere else.
But that would be what is needed --- there is no "somewhere else", but
just the given repository.
Puuuh, I really really tried hard now to make my use-case clear :-|. Hopefully
now the picture emerges.
Thanks for your considerations! And I hope you don't mind me speaking of
"contradictions" etc., but I feel there are fundamental misunderstandings.
Thanks!
Oliver
^ permalink raw reply
* Re: [PATCH 0/4 v4] minor gitweb modifications
From: Sylvain Rabot @ 2011-01-02 16:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Jakub Narebski
In-Reply-To: <20110101104121.GA12734@burratino>
[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]
On Sat, 2011-01-01 at 04:41 -0600, Jonathan Nieder wrote:
> (adding back cc: jakub)
>
> Hi,
>
> Sylvain Rabot wrote:
>
> > gitweb: add extensions to highlight feature map
> > gitweb: remove unnecessary test when closing file descriptor
>
> I like the above two.
>
> > gitweb: add css class to remote url titles
>
> I had a question (why make the remote url table inconsistent with the
> older projects_list table) and suggested a more generic approach in
> reply to v2[1]:
>
> <table class="projects_list">
> <tr id="metadata_desc">
> <td class="metadata_tag">description</td>
> <td>Unnamed repository; edit this file to name it for gitweb.</td>
> </tr>
> <tr id="metadata_owner">
> <td class="metadata_tag">owner</td>
> <td>UNKNOWN</td>
> </tr>
> ...
>
> The idea was that the rows are already labelled for use by css, so to
> make this stylable all we need to do is use a class for the first
> column. This way if some site operator wants the first column
> *always* be bold then that is easy to do.
So your idea is to use the same class for all this kind of tables' first
column ?
>
> Another approach with similar effect would be
>
> <dl class="projects_list">
> <dt>description</dt>
> <dd id="metadata_desc"
> >Unnamed repository; edit this file to name it for gitweb</dd>
> <dt>owner>
> <dd id="metadata_owner"
> >UNKNOWN</dd>
> ...
>
> but that does not degrade as well to browsers not supporting css. Any
> thoughts on this?
I think table is fine, don't see the need to replace it by dd, dt, dl.
>
> > gitweb: add vim modeline header which describes gitweb coding rule
>
> I don't like this one. Isn't the tabstop whatever the reader wants it
> to be (e.g., 8)? I don't like modelines as a way of documenting
> coding standards because
>
> (1) they are not clear to humans and editors other than vim
> (2) they require annotating each source file separately.
>
> See [1] for an alternative approach to configuring an editor to hack
> on git.
>
> Regards,
> Jonathan
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/109462/focus=109538
--
Sylvain Rabot <sylvain@abstraction.fr>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: how to update a submodule?
From: Jens Lehmann @ 2011-01-02 17:30 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: Seth Robertson, git
In-Reply-To: <20110102155514.GB32745@cs-wsok.swansea.ac.uk>
Am 02.01.2011 16:55, schrieb Oliver Kullmann:
> On Sun, Jan 02, 2011 at 12:30:15PM +0100, Jens Lehmann wrote:
>> Am 01.01.2011 21:39, schrieb Oliver Kullmann:
>>> On Fri, Dec 31, 2010 at 06:42:01PM -0500, Seth Robertson wrote:
>>> As far as I see that, this doesn't concern the problem how to I update
>>> one repository with submodules from another repository with "these" submodules
>>> (as the same paths)?
>>
>> I'm not sure I completely understand your use case, but submodules are
>> repositories of their own, so they don't get updated by just pulling
>> a superproject into another containing the same submodule. The submodule
>> changes have to be pushed to its own parent repository and can then be
>> fetched from there into another superproject's submodule.
>
> I know that --- but if there wouldn't be any savings possible (in terms of using it),
> then submodules would be pointless, and so the question is *how* to use them.
No, they aren't pointless at all. But if you want to collaborate using
submodules they IMO work best if all your coworkers are able to access
the same submodule repos you are pushing to. Otherwise you'll have to
transport all submodule changes additionally to those of the superproject
(which might be more of a hassle than not using submodules in the first
place). Then you might be better off pulling the modules into your repo
using "git subtree" or "gitslave".
A possibility to put all submodule commits in the object directory of
the superproject has been discussed some time ago on this list [1] and
at the last GitTogether. That might be just what you need, but I am not
aware of any work done in that direction yet.
> The good thing with Git is that there are no central repositories.
> That's exactly what I want to use, but again and again the automatic
> assumptions of "central repositories" are made, which should be actually alien to Git.
No, Git works perfectly fine with central repositories too (and that is
a feature :-). But I think I understand where your impression comes from.
Submodules don't work very well when you change URLs (that can result
in forcing your coworkers to do a "git submodule sync" in their repo
every time they switch to a commit with a changed URL). But while that
somehow works not being able to access a submodules repo doesn't work at
all. So the constraint for submodules is to have a repo which is visible
for the people you work with.
But submodules don't really force you into the centralized model, as you
can modify the .gitmodules file e.g. in a downstream fork and let it point
to your own forked version of the submodules repos where you can do your
own development independent of the submodules upstream.
> Puuuh, I really really tried hard now to make my use-case clear :-|. Hopefully
> now the picture emerges.
Yep, thanks for sharing that!
[1] http://thread.gmane.org/gmane.comp.version-control.git/151473/
^ permalink raw reply
* Re: [PATCH 0/4 v4] minor gitweb modifications
From: Jonathan Nieder @ 2011-01-02 17:53 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <1293985641.15404.11.camel@kheops>
Sylvain Rabot wrote:
> On Sat, 2011-01-01 at 04:41 -0600, Jonathan Nieder wrote:
>> <tr id="metadata_owner">
>> <td class="metadata_tag">owner</td>
>> <td>UNKNOWN</td>
>> </tr>
>> ...
>>
>> The idea was that the rows are already labelled for use by css, so to
>> make this stylable all we need to do is use a class for the first
>> column. This way if some site operator wants the first column
>> *always* be bold then that is easy to do.
>
> So your idea is to use the same class for all this kind of tables' first
> column ?
Yes, or more generally to find a way to make the first column always
stylable. Actually
tr#metadata_desc > td:first-child {
...
}
already does the trick (or
table.projects_list > tr > td:first-child {
...
}
for style that should apply to all first columns) but I haven't
checked how widely supported first-child is.
^ permalink raw reply
* Re: how to update a submodule?
From: Jonathan Nieder @ 2011-01-02 17:57 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Oliver Kullmann, Seth Robertson, git
In-Reply-To: <4D20B629.8000107@web.de>
Jens Lehmann wrote:
> Submodules don't work very well when you change URLs (that can result
> in forcing your coworkers to do a "git submodule sync" in their repo
> every time they switch to a commit with a changed URL).
For the future, it is probably most convenient to use URLs starting
with "../" or "./", which would rarely need to change. That can even
work with passing around a tarball of bundles and a script to
reconstitute them, I think.
Thanks for some food for thought.
Jonathan
^ permalink raw reply
* Re: fatal: ambiguous message
From: Bruce Korb @ 2011-01-02 18:03 UTC (permalink / raw)
To: Eric Blake, GIT Development; +Cc: GNU Autoconf mailing list
In-Reply-To: <4D1DFF96.4010004@redhat.com>
On 12/31/10 08:06, Eric Blake wrote:
> On 12/30/2010 06:37 PM, Bruce Korb wrote:
>> Hi,
>>
>> Is this fatal? If so, how come it continued?
>
> It's fatal to git-version-gen, which did not continue.
git-version-gen has but two fatal conditions: invalid arguments
yielding a usage message and an unreadable "tarball version file".
That is not this message, but might be clarified with:
v=`cat $tarball_version_file 2>&1` || {
echo "$0 error: unreadable tarball version file $1: $v" >&2
exit 1
}
In any event, the invocation is:
./git-version-gen .tarball-version
and the file ".tarball-version" does not exist, hence git-version-gen
should not fail at all. So, this message says, "fatal: ..."
and comes from git and all three "git" invocations redirect stderr to
/dev/null. The fact that we see it is a git bug. Error messages
should be directed to stderr and thus written to /dev/null.
So, git-version-gen is correct to continue, but git should fail
with a message that names the program that fails ("git") and
should direct the message to stderr.
Note to GIT list: the message in question:
fatal: ambiguous argument 'v0.1..HEAD': unknown revision \
or path not in the working tree.
Thanks! Regards, Bruce
^ permalink raw reply
* Re: fatal: ambiguous message
From: Jonathan Nieder @ 2011-01-02 18:34 UTC (permalink / raw)
To: Bruce Korb; +Cc: Eric Blake, GIT Development, GNU Autoconf mailing list
In-Reply-To: <4D20BE0B.6040104@gmail.com>
Hi,
Context: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=build-aux/git-version-gen
Bruce Korb wrote:
> So, this message says, "fatal: ..."
> and comes from git and all three "git" invocations redirect stderr to
> /dev/null. The fact that we see it is a git bug. Error messages
> should be directed to stderr and thus written to /dev/null.
Were you been able to reproduce that outside the script?
> So, git-version-gen is correct to continue, but git should fail
> with a message that names the program that fails ("git") and
> should direct the message to stderr.
No thoughts on this part. git has at least four kinds of message it
sends to stderr (fatal:, warning:, error:, and usage:) but I am
not sure it is useful to distinguish them ---
git add: pathspec 'nonsense' did not match any files
might be nicer.
diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 5617eb8..119d7aa 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -119,7 +119,7 @@ then
# result is the same as if we were using the newer version
# of git describe.
vtag=`echo "$v" | sed 's/-.*//'`
- numcommits=`git rev-list "$vtag"..HEAD | wc -l`
+ numcommits=`git rev-list "$vtag"..HEAD 2>/dev/null | wc -l`
v=`echo "$v" | sed "s/\(.*\)-\(.*\)/\1-$numcommits-\2/"`;
;;
esac
^ permalink raw reply related
* Publish website incl. submodules
From: Marcus Gustafsson @ 2011-01-02 19:01 UTC (permalink / raw)
To: git
Hello!
I'm quite, but not completely, new to Git. So far I've figured out everything I needed to know, but I just stumbled upon something which requires some help... I found the link to the mailinglist on https://git.wiki.kernel.org/index.php/GitCommunity
I want to use git to manage a (php-based) website. I'll be using "git submodules" to incorporate a few external tools. My question is: what's the best setup for publishing the latest version to the webserver, making sure even the submodules are updated to the correct version. I suppose I should use master-branch as the "latest version which to push", so the submodules should be updated to the version master is using.
Sincerely,
Marcus Gustafsson
^ permalink raw reply
* Re: fatal: ambiguous message
From: Bruce Korb @ 2011-01-03 0:16 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: GNU Autoconf mailing list, Eric Blake, GIT Development
In-Reply-To: <20110102183453.GA13463@burratino>
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
Hi Jonathan,
On Sun, Jan 2, 2011 at 10:34 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Were you been able to reproduce that outside the script?
No, I was blind to the invocation. You found it. I was looking
without seeing. Thank you.
Given that shells without functions can be considered sufficiently
obsolete to not be a consideration, perhaps a better solution is
to put the I-don't-care-about-error-messages code into a separate
function with stderr redirected. Doing that turned out messier
than I had hoped....
[-- Attachment #2: gvg.patch --]
[-- Type: text/x-patch, Size: 4381 bytes --]
diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index c278f6a..8a238b0 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6 +1,6 @@
#!/bin/sh
# Print a version string.
-scriptversion=2010-10-13.20; # UTC
+scriptversion=2011-01-03.00; # UTC
# Copyright (C) 2007-2011 Free Software Foundation, Inc.
#
@@ -78,76 +78,96 @@ tag_sed_script="${2:-s/x/x/}"
nl='
'
-# Avoid meddling by environment variable of the same name.
-v=
+get_ver()
+{
+ local PS4='>gv> '
+ git status >/dev/null 2>&1 || {
+ printf UNKNOWN
+ exit 0
+ }
-# First see if there is a tarball-only version file.
-# then try "git describe", then default.
-if test -f $tarball_version_file
-then
- v=`cat $tarball_version_file` || exit 1
- case $v in
- *$nl*) v= ;; # reject multi-line output
- [0-9]*) ;;
- *) v= ;;
+ test "`git log -1 --pretty=format:x . 2>&1`" = x || {
+ printf UNKNOWN
+ exit 0
+ }
+
+ X=`git describe --abbrev=4 --match='v*' HEAD || \
+ git describe --abbrev=4 HEAD` || {
+ printf UNKNOWN
+ exit 0
+ }
+
+ case "$X" in
+ v[0-9]* ) : ;;
+ * )
+ printf UNKNOWN
+ exit 0
+ ;;
esac
- test -z "$v" \
- && echo "$0: WARNING: $tarball_version_file seems to be damaged" 1>&2
-fi
-if test -n "$v"
-then
- : # use $v
-# Otherwise, if there is at least one git commit involving the working
-# directory, and "git describe" output looks sensible, use that to
-# derive a version string.
-elif test "`git log -1 --pretty=format:x . 2>&1`" = x \
- && v=`git describe --abbrev=4 --match='v*' HEAD 2>/dev/null \
- || git describe --abbrev=4 HEAD 2>/dev/null` \
- && v=`printf '%s\n' "$v" | sed "$tag_sed_script"` \
- && case $v in
- v[0-9]*) ;;
- *) (exit 1) ;;
- esac
-then
# Is this a new git that lists number of commits since the last
# tag or the previous older version that did not?
# Newer: v6.10-77-g0f8faeb
# Older: v6.10-g0f8faeb
- case $v in
+ case $X in
*-*-*) : git describe is okay three part flavor ;;
*-*)
: git describe is older two part flavor
# Recreate the number of commits and rewrite such that the
# result is the same as if we were using the newer version
# of git describe.
- vtag=`echo "$v" | sed 's/-.*//'`
+ vtag=`echo "$X" | sed 's/-.*//'`
numcommits=`git rev-list "$vtag"..HEAD | wc -l`
- v=`echo "$v" | sed "s/\(.*\)-\(.*\)/\1-$numcommits-\2/"`;
+ X=`echo "$X" | sed "s/\(.*\)-\(.*\)/\1-$numcommits-\2/"`;
;;
esac
+ # Don't declare a version "dirty" merely because a time stamp has changed.
+ silent_git update-index --refresh >/dev/null 2>&1
+
+ dirty=`git diff-index --name-only HEAD` || dirty=
+ case "$dirty" in
+ '') ;;
+ *) # Append the suffix only if there isn't one already.
+ case $X in
+ *-dirty) ;;
+ *) X="$X-dirty" ;;
+ esac
+ ;;
+ esac
+
# Change the first '-' to a '.', so version-comparing tools work properly.
# Remove the "g" in git describe's output string, to save a byte.
- v=`echo "$v" | sed 's/-/./;s/\(.*\)-g/\1-/'`;
+ echo "$X" | sed 's/^v//;s/-/./;s/\(.*\)-g/\1-/'
+}
+
+# First see if there is a tarball-only version file.
+# then try "git describe", then default.
+if test -f $tarball_version_file
+then
+ v=`cat $tarball_version_file` || exit 1
+ case $v in
+ *$nl*) v= ;; # reject multi-line output
+ [0-9]*) ;;
+ *) v= ;;
+ esac
+ test -z "$v" \
+ && echo "$0: WARNING: $tarball_version_file seems to be damaged" 1>&2
else
- v=UNKNOWN
+ v=
fi
-v=`echo "$v" |sed 's/^v//'`
-
-# Don't declare a version "dirty" merely because a time stamp has changed.
-git update-index --refresh > /dev/null 2>&1
+if test -n "$v"
+then
+ : # use $v
-dirty=`sh -c 'git diff-index --name-only HEAD' 2>/dev/null` || dirty=
-case "$dirty" in
- '') ;;
- *) # Append the suffix only if there isn't one already.
- case $v in
- *-dirty) ;;
- *) v="$v-dirty" ;;
- esac ;;
-esac
+else
+ # Otherwise, if there is at least one git commit involving the
+ # working directory, and "git describe" output looks sensible, use
+ # that to derive a version string.
+ #
+ v=`get_ver` 2>/dev/null
+fi
# Omit the trailing newline, so that m4_esyscmd can use the result directly.
echo "$v" | tr -d "$nl"
[-- Attachment #3: Type: text/plain, Size: 134 bytes --]
_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
^ permalink raw reply related
* Re: Commiting automatically (2)
From: Maaartin-1 @ 2011-01-03 0:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201012271304.03915.jnareb@gmail.com>
On 10-12-27 13:04, Jakub Narebski wrote:
> On Wed, 22 Dec 2010, Maaartin-1 wrote:
>> On 10-12-21 14:06, Jakub Narebski wrote:
>>>
>>> Please try to not cull Cc list (use 'reply via email', if possible)
>>
>> I don't know what "cull" means and
>> http://dictionary.reference.com/browse/cull
>> doesn't help me at all. Could you explain?
>
> http://en.wiktionary.org/wiki/cull
>
> to cull
> [...]
> 3. To select animals from a group and then kill them in order to
> reduce the numbers of the group in a controlled manner.
>
> In the context ("to cull Cc list") it means removing entries from Cc
> list (courtesy copy, copy-to), i.e. not replying to all people
> participating in given (sub)thread.
I was using the gmane page, which did it. Next time I replied using
email, but forgot to add the CC. There are things I hate more than
mailing lists, but they're fairly rare.
>> IMHO, it's quite broken. Alone it would be fine, but should really
>> git-show-ref behave that different from git-symbolic-ref?
>
> git-symbolic-ref is about querying and manipulating _single_ symbolic
> reference, using fully qualified branch names (ref names).
OK, this is a sort of acceptable.
> git-show-ref is about querying multiple refs; I think the design goal
> behind its strange pattern matching semantic is to make it easy to get
> all refs with the same short name.
OK, the strange pattern matching is not that bad.
>> Moreover, git-show-ref --head shows all branches and tags, this can't be
>> right, can it? According to your above explanation, getting HEAD using a
>> pattern is impossible, so I'd say that's what is "--head" good for.
>>
>> Moreover, "git-show-ref --heads" shows less than "git-show-ref --head",
>> despite the plural.
>
> "git show-ref --head" is strange in that it doesn't play well
> with '--heads' and '--tags' and '<pattern>'.
>
> I think it is a bit of misdesign, but I don't know how it should be
> fixed; current output of "git show-ref --head" has to be kept because
> of backward compatibility - git-show-ref is plumbing.
I wonder what
git show-ref --head
really does. It seems to output everything, is this the expected (albeit
strange) behavior? Maybe, I know now, s. below.
For sure, either the doc is completely wrong or the implementation. I
hope I understand "Show the HEAD reference" correctly as showing the
HEAD reference, don't I? So it must show a single reference (singular).
Instead I get all tags and all heads. Could anybody either fix the doc
or convince me that the many lines I'm seeing are a single one?
Shouldn't there be an option *really* doing what --head is expected and
documented to do? I mean something like
git show-ref --head --yes-I-really-mean-the-head
with the output consisting of a single line like
4ba2b422cf3cc229d894bb31c429c0c588de85c0 HEAD
Maybe it could be called --head-only.
It could help a lot to add the word "additionally" to the doc like
--head
Additionally show the HEAD reference.
>>> I tripped over strange git-show-ref <pattern> semantic too.
>>>
>>> P.S. there is also git-for-each-ref.
>
> I don't know why there is git-show-ref when we have git-for-each-ref
> for scripting; I guess they were added nearly at the same time...
I guess, I can get the single line I wanted using
git for-each-ref $(git symbolic-ref HEAD)
right?
^ permalink raw reply
* gitattributes don't work
From: Marcin Wiśnicki @ 2011-01-03 0:42 UTC (permalink / raw)
To: git
I'm trying to exclude certain paths (those that contain "xmac/gen/") from
diff output using .git/info/attributes (not .gitattributes).
According to gitattributes(5) it supports patterns from gitignore(5).
Example path that must be excluded:
src/byucc/jhdl/CSRC/xmac/gen/and2_dp_g.xmac
What I've tried but didn't work:
xmac/gen/ -diff
Following works but is not what I want:
*.xmac -diff
It seems I can only get it to work for file names but not for whole paths.
What am I doing wrong or is this a bug ?
git version 1.7.3.4
^ permalink raw reply
* Re: [PATCH 0/4] teach vcs-svn/line_buffer to handle multiple input files
From: Jonathan Nieder @ 2011-01-03 0:49 UTC (permalink / raw)
To: git; +Cc: David Barr, Thomas Rast, Ramkumar Ramachandra
In-Reply-To: <20101224080505.GA29681@burratino>
Jonathan Nieder wrote:
> [*]
> I am not sure whether this is the right approach for reading from the
> report-fd. To avoid deadlock, we cannot issue a blocking read(2)
> after the trailing newline has been read from an expected line or the
> nth byte has been read in fixed-length input.
I think this isn't a problem (even though I haven't found any
comforting text in the standards themselves).
To convince myself so, I wrote a couple of new tests. The change
descriptions explain the reasoning.
These four patches apply on top of
[PATCH 4/4] vcs-svn: teach line_buffer to handle multiple input files
and are numbered accordingly. Thoughts welcome, as always.
Jonathan Nieder (4):
vcs-svn: make test-line-buffer input format more flexible
tests: give vcs-svn/line_buffer its own test script
vcs-svn: tweak test-line-buffer to not assume line-oriented input
t0081 (line-buffer): add buffering test
t/t0080-vcs-svn.sh | 54 ---------------
t/t0081-line-buffer.sh | 174 ++++++++++++++++++++++++++++++++++++++++++++++++
test-line-buffer.c | 76 +++++++++++++++------
3 files changed, 230 insertions(+), 74 deletions(-)
create mode 100755 t/t0081-line-buffer.sh
^ permalink raw reply
* [PATCH 5/8] vcs-svn: make test-line-buffer input format more flexible
From: Jonathan Nieder @ 2011-01-03 0:50 UTC (permalink / raw)
To: git; +Cc: David Barr, Thomas Rast, Ramkumar Ramachandra
In-Reply-To: <20110103004900.GA30506@burratino>
Imitate the input format of test-obj-pool to support arbitrary
sequences of commands rather than alternating read/copy. This should
make it easier to add tests that exercise other line_buffer functions.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
t/t0080-vcs-svn.sh | 18 ++++++++--------
test-line-buffer.c | 56 +++++++++++++++++++++++++++++++++------------------
2 files changed, 45 insertions(+), 29 deletions(-)
diff --git a/t/t0080-vcs-svn.sh b/t/t0080-vcs-svn.sh
index d3225ad..8be9700 100755
--- a/t/t0080-vcs-svn.sh
+++ b/t/t0080-vcs-svn.sh
@@ -85,40 +85,40 @@ test_expect_success 'line buffer' '
printf "%s\n" "" foo >expected6 &&
test-line-buffer <<-\EOF >actual1 &&
- 5
+ read 5
HELLO
EOF
test-line-buffer <<-\EOF >actual2 &&
- 0
+ read 0
- 5
+ copy 5
HELLO
EOF
q_to_nul <<-\EOF |
- 1
+ read 1
Q
EOF
test-line-buffer >actual3 &&
q_to_nul <<-\EOF |
- 0
+ read 0
- 1
+ copy 1
Q
EOF
test-line-buffer >actual4 &&
test-line-buffer <<-\EOF >actual5 &&
- 5
+ read 5
foo
EOF
test-line-buffer <<-\EOF >actual6 &&
- 0
+ read 0
- 5
+ copy 5
foo
EOF
diff --git a/test-line-buffer.c b/test-line-buffer.c
index f9af892..383f35b 100644
--- a/test-line-buffer.c
+++ b/test-line-buffer.c
@@ -1,11 +1,5 @@
/*
* test-line-buffer.c: code to exercise the svn importer's input helper
- *
- * Input format:
- * number NL
- * (number bytes) NL
- * number NL
- * ...
*/
#include "git-compat-util.h"
@@ -20,28 +14,50 @@ static uint32_t strtouint32(const char *s)
return (uint32_t) n;
}
+static void handle_command(const char *command, const char *arg, struct line_buffer *buf)
+{
+ switch (*command) {
+ case 'c':
+ if (!prefixcmp(command, "copy ")) {
+ buffer_copy_bytes(buf, strtouint32(arg) + 1);
+ return;
+ }
+ case 'r':
+ if (!prefixcmp(command, "read ")) {
+ const char *s = buffer_read_string(buf, strtouint32(arg));
+ printf("%s\n", s);
+ buffer_skip_bytes(buf, 1); /* consume newline */
+ return;
+ }
+ default:
+ die("unrecognized command: %s", command);
+ }
+}
+
+static void handle_line(const char *line, struct line_buffer *stdin_buf)
+{
+ const char *arg = strchr(line, ' ');
+ if (!arg)
+ die("no argument in line: %s", line);
+ handle_command(line, arg + 1, stdin_buf);
+}
+
int main(int argc, char *argv[])
{
- struct line_buffer buf = LINE_BUFFER_INIT;
+ struct line_buffer stdin_buf = LINE_BUFFER_INIT;
char *s;
if (argc != 1)
- usage("test-line-buffer < input.txt");
- if (buffer_init(&buf, NULL))
+ usage("test-line-buffer < script");
+
+ if (buffer_init(&stdin_buf, NULL))
die_errno("open error");
- while ((s = buffer_read_line(&buf))) {
- s = buffer_read_string(&buf, strtouint32(s));
- fputs(s, stdout);
- fputc('\n', stdout);
- buffer_skip_bytes(&buf, 1);
- if (!(s = buffer_read_line(&buf)))
- break;
- buffer_copy_bytes(&buf, strtouint32(s) + 1);
- }
- if (buffer_deinit(&buf))
+ while ((s = buffer_read_line(&stdin_buf)))
+ handle_line(s, &stdin_buf);
+ if (buffer_deinit(&stdin_buf))
die("input error");
if (ferror(stdout))
die("output error");
- buffer_reset(&buf);
+ buffer_reset(&stdin_buf);
return 0;
}
--
1.7.4.rc0.580.g89dc.dirty
^ 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