[PATCH] gitk: Synchronize highlighting in file view when scrolling diff
Whenever the diff pane scrolls, highlight the corresponding file in the
file list on the right. For a large commit with many files and long
per-file diffs, this makes it easier to keep track of what you're looking
at.
This allows simplifying the prevfile and nextfile functions, because
all they have to do is scroll the diff pane.
Signed-off-by: Stefan Haller ste...@haller-berlin.de
---
gitk | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/gitk b/gitk
index d93bd99..9e3ec71 100755
--- a/gitk
+++ b/gitk
@@ -7947,10 +7947,9 @@ proc changediffdisp {} {
$ctext tag conf dresult -elide [lindex $diffelide 1]
}
-proc highlightfile {loc cline} {
-global ctext cflist cflist_top
+proc highlightfile {cline} {
+global cflist cflist_top
-$ctext yview $loc
$cflist tag remove highlight $cflist_top.0 $cflist_top.0 lineend
$cflist tag add highlight $cline.0 $cline.0 lineend
$cflist see $cline.0
@@ -7962,17 +7961,15 @@ proc prevfile {} {
if {$cmitmode eq tree} return
set prev 0.0
-set prevline 1
set here [$ctext index @0,0]
foreach loc $difffilestart {
if {[$ctext compare $loc = $here]} {
- highlightfile $prev $prevline
+ $ctext yview $prev
return
}
set prev $loc
- incr prevline
}
-highlightfile $prev $prevline
+$ctext yview $prev
}
proc nextfile {} {
@@ -7980,11 +7977,9 @@ proc nextfile {} {
if {$cmitmode eq tree} return
set here [$ctext index @0,0]
-set line 1
foreach loc $difffilestart {
- incr line
if {[$ctext compare $loc $here]} {
- highlightfile $loc $line
+ $ctext yview $loc
return
}
}
@@ -8138,7 +8133,17 @@ proc searchmarkvisible {doall} {
}
proc scrolltext {f0 f1} {
-global searchstring
+global searchstring cmitmode
+global ctext cflist cflist_top difffilestart
+
+if {$cmitmode ne tree [info exists difffilestart]} {
+ set top [lindex [split [$ctext index @0,0] .] 0]
+ if {$top [lindex $difffilestart 0]} {
+ highlightfile 0
+ } else {
+ highlightfile [expr {[bsearch $difffilestart $top] + 2}]
+ }
+}
.bleft.bottom.sb set $f0 $f1
if {$searchstring ne {}} {
--
1.7.12.376.g8258bbd
--
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] add t3420-rebase-topology
Add more test cases to check that the topology after a rebase is as
expected. Conflicts are not considered, but patch-equivalence is.
---
Tests pass and fail as indicated by the suffix
(_success/_failure). Your input especially appreciated on whether you
agree with the intent of the test cases. For example, do you agree
that 'rebase --onto does not re-apply patches in onto' is desirable?
And if you do, then do you also agree that 'rebase --root --onto
ignores patch in onto' is desirable? How about 'rebase --root is not a
no-op'? One might think that --force would be necessary, but on the
other hand, if that was the case, the only point (AFAICT) of git
rebase --root branch without --force would be to linearize history,
so I instead made the test case confirm that --root without --onto
effectively behaves as if --force was also passed.
Feedback on the structure/setup and style is of course also
appreciated.
t/t3420-rebase-topology.sh | 348 +
1 file changed, 348 insertions(+)
create mode 100755 t/t3420-rebase-topology.sh
diff --git a/t/t3420-rebase-topology.sh b/t/t3420-rebase-topology.sh
new file mode 100755
index 000..024a2b4
--- /dev/null
+++ b/t/t3420-rebase-topology.sh
@@ -0,0 +1,348 @@
+#!/bin/sh
+
+test_description='effect of rebase on topology'
+. ./test-lib.sh
+
+
+# q---C---r
+# /
+# a---b---c---d!--e---p
+# \
+# f---g!--h
+#\
+# j---E---k
+# \ \
+# n---H---w
+#
+# x---y---B
+#
+#
+# ! = empty
+# uppercase = cherry-picked
+# p = reverted e
+#
+# TODO:
+# prune graph to what's needed
+
+empty () {
+ git commit --allow-empty -m $1
+ git tag $1
+}
+
+cherry_pick () {
+ git cherry-pick -n $1
+ git commit -m $2
+ git tag $2
+}
+
+revert () {
+ git revert -n $1
+ git commit -m $2
+ git tag $2
+}
+
+
+test_expect_success 'setup' '
+ test_commit a
+ test_commit b
+ test_commit c
+ empty d
+ test_commit e
+ revert e p
+ git checkout b
+ test_commit f
+ empty g
+ test_commit h
+ git checkout f
+ test_commit j
+ cherry_pick e E
+ test_commit k
+ git checkout j
+ test_commit n
+ cherry_pick h H
+ git merge -m w E
+ git tag w
+ git checkout b
+ test_commit q
+ cherry_pick c C
+ test_commit r
+ git checkout --orphan disjoint
+ git rm -rf .
+ test_commit x
+ test_commit y
+ cherry_pick b B
+'
+
+reset () {
+ git rebase --abort
+ git reset --hard
+}
+
+test_range () {
+ test $(git log --reverse --topo-order --format=%s $1 | xargs) = $2
+}
+
+test_revisions () {
+ expected=$1
+ shift
+ test $(git log --format=%s --no-walk=unsorted $@ | xargs) =
$expected
+}
+
+same_revision () {
+ test $(git rev-parse $1) = $(git rev-parse $2)
+}
+
+# the following 5 (?) tests copy t3400 tests, but check the history rather
than status code and/or stdout
+run () {
+echo '
+ reset
+ git rebase '$@' c j
+ same_revision HEAD~2 c
+ test_range c.. f j
+'
+}
+test_expect_success 'simple rebase' $(run)
+test_expect_success 'simple rebase -m' $(run -m)
+test_expect_success 'simple rebase -i' $(run -i)
+test_expect_success 'simple rebase -p' $(run -p)
+
+run () {
+echo '
+ reset
+ git rebase '$@' b j
+ same_revision HEAD j
+'
+}
+test_expect_success 'rebase is no-op if upstream is an ancestor' $(run)
+test_expect_success 'rebase -m is no-op if upstream is an ancestor' $(run -m)
+test_expect_success 'rebase -i is no-op if upstream is an ancestor' $(run -i)
+test_expect_success 'rebase -p is no-op if upstream is an ancestor' $(run -p)
+
+run () {
+echo '
+ reset
+ git rebase '$@' --force b j
+ ! same_revision HEAD j
+ test_range b.. f j
+'
+}
+test_expect_success 'rebase --force' $(run)
+test_expect_success 'rebase -m --force' $(run -m)
+test_expect_success 'rebase -i --force' $(run -i)
+test_expect_failure 'rebase -p --force' $(run -p)
+
+run () {
+echo '
+ reset
+ git rebase '$@' j b
+ same_revision HEAD j
+'
+}
+test_expect_success 'rebase fast-forwards if an ancestor of upstream' $(run)
+test_expect_success 'rebase -m fast-forwards if an ancestor of upstream'
$(run -m)
+test_expect_success 'rebase -i fast-forwards if an ancestor of upstream'
$(run -i)
+test_expect_success 'rebase -p fast-forwards if an ancestor of upstream'
$(run -p)
+
+run () {
+echo '
+ reset
+ git rebase '$@' p k
+ test_range p.. f j k
+'
+}
+test_expect_success 'rebase ignores patch in upstream' $(run)
+test_expect_failure 'rebase -m ignores patch in upstream' $(run -m)
+test_expect_success 'rebase -i ignores patch in upstream' $(run -i)
+test_expect_success 'rebase -p ignores patch in upstream' $(run -p)
+
+run () {
+echo '
+ reset
+
Re: [PATCH] t/perf: add trash directory to .gitignore
Hi, Junio C Hamano wrote: Thanks. I _think_ you still want to make sure these are directories, so instead of losing the trailing slash, you would want to keep it and add a leading slash to anchor them to the t/perf directory, i.e. /build/ /test-results/ /trash directory*/ Right. Thanks for taking care of this. Ram -- 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] Port to HP NonStop
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
This needs the 4 compat-poll patches posted earlier.
Needs a different link order in Makefile: libintl before libiconv.
This may affect other platforms, so needs some checking.
Also I'm not really sure how to best #ifdef the #include strings.h
and the typedef (u)intptr_t.
Furthermore the -DHAVE_STRING_H=1, needed for
compat/fnmatch/fnmatch.c doesn't look quite right to me?
Makefile | 54 +-
git-compat-util.h | 10 +-
2 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 3d40860..b1d4ef5 100644
--- a/Makefile
+++ b/Makefile
@@ -1324,6 +1324,52 @@ ifeq ($(uname_S),Minix)
NO_CURL =
NO_EXPAT =
endif
+ifeq ($(uname_S),NONSTOP_KERNEL)
+ CC = cc -c99 # needs some C99 features, inline is just one of them
+ # INLINE='' would just replace one set of warnings with another and
+ # still not compile in c89 mode, for non-const array initializations
+ CFLAGS = -g -O0 # disable all optimization, seems to result in bad code,
+ # with -O1 or -O0 /usr/local/libexec/git-core/git-pack-objects
+ # abends on git push
+ prefix = /usr/local
+ # our's are in ${prefix}/bin
+ PERL_PATH = ${prefix}/bin/perl
+ PYTHON_PATH = ${prefix}/bin/python
+
+ # as detected by './configure'
+ #NO_CURL = YesPlease # missdetected, disabled, see below
+ NEEDS_SSL_WITH_CURL = YesPlease # added manually, see above
+ HAVE_LIBCHARSET_H=YesPlease
+ NEEDS_LIBICONV = YesPlease # needs libiconv first, changed further down
+ NO_SYS_SELECT_H=UnfortunatelyYes
+ NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_HSTRERROR=YesPlease
+ NO_STRCASESTR=YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ OLD_ICONV=UnfortunatelyYes # currently libiconv-1.9.1
+ NO_REGEX=YesPlease # Why? ToDo?
+ NO_PTHREADS=UnfortunatelyYes # ToDo? Using PUT, maybe?
+ #CFLAGS += -put # not suffient? Seems the wrong fnmatch.h gets included?
+ #CFLAGS += -DFNM_CASEFOLD=16 # (1 4), to get dir.c compiled!?!
+ #CFLAGS += -Icompat/fnmatch # this doesn't help
+
+ # not detected (nor checked for) by './configure'
+ COMPAT_CFLAGS += -DSA_RESTART=0 # we don't have SA_RESTART on NonStop
+ COMPAT_CFLAGS += -DHAVE_STRING_H=1 # needed in compat/fnmatch/fnmatch.c
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ NO_PREAD = YesPlease
+ NO_MMAP = YesPlease
+ NO_POLL = YesPlease
+ MKDIR_WO_TRAILING_SLASH = YesPlease
+ NO_SETITIMER = UnfortunatelyYes
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
@@ -1555,6 +1599,11 @@ else
LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto
endif
endif
+ifndef NO_GETTEXT
+ifndef LIBC_CONTAINS_LIBINTL
+ EXTLIBS += -lintl
+endif
+endif
ifdef NEEDS_LIBICONV
ifdef ICONVDIR
BASIC_CFLAGS += -I$(ICONVDIR)/include
@@ -1567,11 +1616,6 @@ endif
ifdef NEEDS_LIBGEN
EXTLIBS += -lgen
endif
-ifndef NO_GETTEXT
-ifndef LIBC_CONTAINS_LIBINTL
- EXTLIBS += -lintl
-endif
-endif
ifdef NEEDS_SOCKET
EXTLIBS += -lsocket
endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 24b5432..7e70361 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -74,7 +74,8 @@
# define _XOPEN_SOURCE 500
# endif
#elif !defined(__APPLE__) !defined(__FreeBSD__) !defined(__USLC__) \
- !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__)
+ !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__) \
+ !defined(__TANDEM)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600
for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
@@ -98,6 +99,9 @@
#include stdlib.h
#include stdarg.h
#include string.h
+#ifdef __TANDEM /* or HAVE_STRINGS_H or !NO_STRINGS_H? */
+#include strings.h /* for strcasecmp() */
+#endif
#include errno.h
#include limits.h
#include sys/param.h
@@ -141,6 +145,10 @@
#else
#include stdint.h
#endif
+#ifdef __TANDEM /* or NO_INTPTR_T resp. NO_UINTPTR_T? */
+typedef int intptr_t;
+typedef unsigned int uintptr_t;
+#endif
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include grp.h
--
1.7.12
--
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] rebase -i: Teach --edit-todo action
Andrew Wong andrew.k...@gmail.com writes: On 09/16/12 02:54, Junio C Hamano wrote: In any case, what information are you discarding and then replacing with the standard boilerplate? It's to strip out the comment that says: # However, if you remove everything, the rebase will be aborted. As there's no way reliable way to know where that line is and remove it, the only way I can think of is to remove all the comments, and append the help messages again. I see. As long as you know that the other things you are removing with the code is irrelevant and giving the standard boilerplate is sufficient, your approach is the simplest way to reliably get what you want. 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: [RFC PATCH] add t3420-rebase-topology
Am 9/18/2012 8:31, schrieb Martin von Zweigbergk:
Add more test cases to check that the topology after a rebase is as
expected. Conflicts are not considered, but patch-equivalence is.
---
Tests pass and fail as indicated by the suffix
(_success/_failure). Your input especially appreciated on whether you
agree with the intent of the test cases. For example, do you agree
that 'rebase --onto does not re-apply patches in onto' is desirable?
And if you do, then do you also agree that 'rebase --root --onto
ignores patch in onto' is desirable? How about 'rebase --root is not a
no-op'? One might think that --force would be necessary, but on the
other hand, if that was the case, the only point (AFAICT) of git
rebase --root branch without --force would be to linearize history,
so I instead made the test case confirm that --root without --onto
effectively behaves as if --force was also passed.
Feedback on the structure/setup and style is of course also
appreciated.
t/t3420-rebase-topology.sh | 348
+
1 file changed, 348 insertions(+)
create mode 100755 t/t3420-rebase-topology.sh
diff --git a/t/t3420-rebase-topology.sh b/t/t3420-rebase-topology.sh
new file mode 100755
index 000..024a2b4
--- /dev/null
+++ b/t/t3420-rebase-topology.sh
@@ -0,0 +1,348 @@
+#!/bin/sh
+
+test_description='effect of rebase on topology'
+. ./test-lib.sh
+
+
+# q---C---r
+# /
+# a---b---c---d!--e---p
+# \
+# f---g!--h
+#\
+# j---E---k
+# \ \
+# n---H---w
+#
+# x---y---B
+#
+#
+# ! = empty
+# uppercase = cherry-picked
+# p = reverted e
+#
+# TODO:
+# prune graph to what's needed
+
+empty () {
Is it is_empty or make_empty/empty_commit?
+ git commit --allow-empty -m $1
+ git tag $1
+}
Obviously the latter.
+
+cherry_pick () {
+ git cherry-pick -n $1
+ git commit -m $2
+ git tag $2
+}
+
+revert () {
+ git revert -n $1
+ git commit -m $2
+ git tag $2
+}
+
+
+test_expect_success 'setup' '
+ test_commit a
+ test_commit b
+ test_commit c
+ empty d
+ test_commit e
+ revert e p
+ git checkout b
+ test_commit f
+ empty g
+ test_commit h
+ git checkout f
+ test_commit j
+ cherry_pick e E
+ test_commit k
+ git checkout j
+ test_commit n
+ cherry_pick h H
+ git merge -m w E
+ git tag w
+ git checkout b
+ test_commit q
+ cherry_pick c C
+ test_commit r
+ git checkout --orphan disjoint
+ git rm -rf .
+ test_commit x
+ test_commit y
+ cherry_pick b B
+'
+
+reset () {
+ git rebase --abort
+ git reset --hard
+}
The 'rebase --abort' can fail, but there is no chain. Good. Using this
function instead of the individual commands in the tests does not break
the chain there. Good.
These following three functions should be and can be consistent with the
order of their arguments: expected actual.
+test_range () {
+ test $(git log --reverse --topo-order --format=%s $1 | xargs) = $2
expected=$1
set -- $(git log --reverse --topo-order --format=%s $2)
test expected = $*
+}
+
+test_revisions () {
+ expected=$1
+ shift
+ test $(git log --format=%s --no-walk=unsorted $@ | xargs) =
$expected
set -- $(git log --format=%s --no-walk=unsorted $@)
test expected = $*
+}
+
+same_revision () {
+ test $(git rev-parse $1) = $(git rev-parse $2)
+}
'test_same_revision'?
+
+# the following 5 (?) tests copy t3400 tests, but check the history rather
than status code and/or stdout
+run () {
+echo '
+ reset
+ git rebase '$@' c j
+ same_revision HEAD~2 c
+ test_range c.. f j
+'
+}
+test_expect_success 'simple rebase' $(run)
+test_expect_success 'simple rebase -m' $(run -m)
+test_expect_success 'simple rebase -i' $(run -i)
+test_expect_success 'simple rebase -p' $(run -p)
Since here and in the following tests the test cases and test descriptions
vary in the same way, wouldn't it make sense to factor the description out
as well?
test_run_rebase () {
test_expect_success simple rebase $*
reset
git rebase $* c j
same_revision HEAD~2 c
test_range c.. 'f j'
}
test_run_rebase ''
test_run_rebase -m
test_run_rebase -i
test_run_rebase -p
(Watch your quoting, though.)
Oh, I see: some tests expect failure. How about:
test_run_rebase () {
result=$1
shift
test_expect_$result simple rebase $* ...
}
test_run_rebase success ''
etc.
+
+run () {
+echo '
+ reset
+ git rebase '$@' b j
+ same_revision HEAD j
+'
+}
+test_expect_success 'rebase is no-op if upstream is an ancestor' $(run)
+test_expect_success 'rebase -m is no-op if upstream is an
RE: Unable to clone GIT project
All, Thanks for reply but its not working still. Things which I have done till now is On Linux machine Installed libiconv-1.14 unded /usr/local/lib path. -rw-r--r-- 1 root root 912 Sep 15 20:40 libiconv.la lrwxrwxrwx 1 root root 17 Sep 15 20:40 libiconv.so - libiconv.so.2.5.1 lrwxrwxrwx 1 root root 17 Sep 15 20:40 libiconv.so.2 - libiconv.so.2.5.1 -rw-r--r-- 1 root root 1262349 Sep 15 20:40 libiconv.so.2.5.1 export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH on local machine I have installed msysgit and trying to clone C:\Ankush Data\work\Test-GIT\trial_1git clone ssh://bea@IP:/home/ankush/GIT/sample_project Cloning into 'sample_project'... bea@IP:'s password: git-upload-pack: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory fatal: The remote end hung up unexpectedly -Original Message- From: Jeff King [mailto:p...@peff.net] Sent: Tuesday, September 18, 2012 1:51 AM To: Erik Faye-Lund Cc: Konstantin Khomoutov; Aggarwal, Ankush; git@vger.kernel.org Subject: Re: Unable to clone GIT project On Sun, Sep 16, 2012 at 09:48:43PM +0200, Erik Faye-Lund wrote: git-upload-pack: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory fatal: The remote end hung up unexpectedly [...] No. This is not a Git for Windows issue. The remote end is the one who isn't able to load libiconv, you can tell from the fact that it complains about libiconv.so.2, not libiconv-2.dll, and from the fact that the client informs us that the remote end hung up. Yeah, it is definitely a problem on the remote system. Ankush: There's something wrong with the setup on your Linux machine; most likely something related to the library path set up. What protocol are you cloning over? If I had to guess, I'd say it was ssh, the library is installed in a non-standard place (e.g., because he built them as a regular user and put them in his home directory), and LD_LIBRARY_PATH does not get set properly by ssh for the incoming ssh session. If that is the case, you can fix it with an entry in ~/.ssh/environment, or by telling git that the remote side needs to do more than just run git-upload-pack, like: git clone -u '. $HOME/.profile git-upload-pack' ... But I am just guessing. We need more information on how the remote system is set up to really know. -Peff
Re: [PATCH] rebase -i: fix misleading error message after 'exec no-such' instruction
Johannes Sixt j.s...@viscovery.net writes: From: Johannes Sixt j...@kdbg.org When the todo sheet of interactive rebase instructs to run a non-existing command, the operation stops with the following error: Execution failed: no-such You can fix the problem, and then run git rebase --continue fatal: 'rebase' appears to be a git command, but we were not able to execute it. Maybe git-rebase is broken? While you're there, maybe you want to turn the first line into Execution failed: no-such (command not found) In any case, the patch sounds good, thanks. -- 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
Can git pull from a mercurial repository?
Is there an easy way to get git to clone/pull from a Mercurial repository? Bye, Jojo -- 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
git installation fails in home directory on ubuntu 12.04
So I did git fetch git rebase git describe v1.7.12-503-g5976753 ./configure --prefix=/home/sb make make install GEN perl/PM.stamp SUBDIR gitweb SUBDIR ../ SUBDIR perl make[1]: `perl.mak' is up to date. make[2]: `GIT-VERSION-FILE' is up to date. GEN git-instaweb SUBDIR git-gui SUBDIR gitk-git make[1]: Nothing to be done for `all'. SUBDIR perl SUBDIR git_remote_helpers SUBDIR templates install -d -m 755 '/home/sb/bin' install -d -m 755 '/home/sb/libexec/git-core' install git-credential-store git-daemon git-fast-import git-http-backend git-imap-send git-sh-i18n--envsubst git-shell git-show-index git-upload-pack git-http-fetch git-http-push git-credential-cache git-credential-cache--daemon git-remote-http git-remote-https git-remote-ftp git-remote-ftps git-am git-bisect git-difftool--helper git-filter-branch git-lost-found git-merge-octopus git-merge-one-file git-merge-resolve git-mergetool git-pull git-quiltimport git-rebase git-repack git-request-pull git-stash git-submodule git-web--browse git-add--interactive git-difftool git-archimport git-cvsexportcommit git-cvsimport git-cvsserver git-relink git-send-email git-svn git-remote-testgit git-p4 git-instaweb '/home/sb/libexec/git-core' install -m 644 git-mergetool--lib git-parse-remote git-rebase--am git-rebase--interactive git-rebase--merge git-sh-setup git-sh-i18n '/home/sb/libexec/git-core' install git git-upload-pack git-receive-pack git-upload-archive git-shell git-cvsserver '/home/sb/bin' make -C templates DESTDIR='' install make[1]: Entering directory `/home/sb/OSS/git/templates' install -d -m 755 '/home/sb/share/git-core/templates' (cd blt tar cf - .) | \ (cd '/home/sb/share/git-core/templates' umask 022 tar xof -) make[1]: Leaving directory `/home/sb/OSS/git/templates' install -d -m 755 '/home/sb/libexec/git-core/mergetools' install -m 644 mergetools/* '/home/sb/libexec/git-core/mergetools' install -d -m 755 '/home/sb/share/locale' (cd po/build/locale tar cf - .) | \ (cd '/home/sb/share/locale' umask 022 tar xof -) make -C perl prefix='/home/sb' DESTDIR='' install make[1]: Entering directory `/home/sb/OSS/git/perl' make[2]: Entering directory `/home/sb/OSS/git/perl' Appending installation info to /usr/local/lib/perl/5.14.2/perllocal.pod mkdir /usr/local/lib/perl: Permission denied at /usr/share/perl/5.14/ExtUtils/Command.pm line 288 make[2]: [doc_site_install] Error 13 (ignored) /bin/sh: 1: cannot create /usr/local/lib/perl/5.14.2/perllocal.pod: Directory nonexistent make[2]: [doc_site_install] Error 2 (ignored) ERROR: Can't create '/usr/local/share/man/man3' mkdir /usr/local/share/man/man3: Permission denied at /usr/share/perl/5.14/ExtUtils/Install.pm line 494 at -e line 1 make[2]: *** [pure_site_install] Error 13 make[2]: Target `install' not remade because of errors. make[2]: Leaving directory `/home/sb/OSS/git/perl' make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/sb/OSS/git/perl' make: *** [install] Error 2 -- 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] rebase -i: fix misleading error message after 'exec no-such' instruction
Am 9/18/2012 13:20, schrieb Matthieu Moy: Johannes Sixt j.s...@viscovery.net writes: From: Johannes Sixt j...@kdbg.org When the todo sheet of interactive rebase instructs to run a non-existing command, the operation stops with the following error: Execution failed: no-such You can fix the problem, and then run git rebase --continue fatal: 'rebase' appears to be a git command, but we were not able to execute it. Maybe git-rebase is broken? While you're there, maybe you want to turn the first line into Execution failed: no-such (command not found) No, I don't want to: Neither do we have errno here, nor can we be specific enough because the whole shell script the user gave after 'exec' is repeated here. I would rather remove the line so that it does not distract from the more specific error message that the shell gave. On top of that, the command is already dumped before it is executed; we don't need to repeat it. -- Hannes -- 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: Can git pull from a mercurial repository?
From: Georgi Chorbadzhiyski [mailto:g...@unixsol.org] Sent: Tuesday, September 18, 2012 2:06 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? Around 09/18/2012 02:22 PM, Joachim Schmitz scribbled: Is there an easy way to get git to clone/pull from a Mercurial repository? I'm using http://offbytwo.com/git-hg/ It works beautifully. Thanks, but that requires Mercurial to be available, installed and in PATH. I want to use git exactly because I don't have Mercurial (yet?) Bye, Jojo -- 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: Can git pull from a mercurial repository?
From: Andreas Ericsson [mailto:a...@op5.se] Sent: Tuesday, September 18, 2012 1:46 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? On 09/18/2012 01:22 PM, Joachim Schmitz wrote: Is there an easy way to get git to clone/pull from a Mercurial repository? Yes. Google git remote helpers and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I only have 2.4), also I have no idea how to get it installed https://github.com/SRabbelier/git is 3 years old, apparently never made it into git, guess for a reason? Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very confusing to me... -- 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: [PATCHv5] clone --single: limit the fetch refspec to fetched branch
On Mon, Sep 17, 2012 at 11:39 PM, Junio C Hamano gits...@pobox.com wrote: Ralf Thielow ralf.thie...@gmail.com writes: - install correct refspec if the value of --branch is a tag (test added) What is the definition of correct? I see the documentation says --branch can also take tags and treat them like detached HEAD, and even though I _think_ allowing tags was a huge mistake, if we claim we treat it like detached HEAD, we should do the same when coming up with the refspec used for the follow-up fetch. This patch would install the refspec +refs/tags/v1.7.10:refs/tags/v1.7.10, so we would do the same with the follow-up fetch, not? This can be seen as it's not a bug, it's a feature. Why not cloning a tag of a repo if someone just want to build a tag without having anything else. Even though I did say I thought allowing tags was a huge mistake, I was not suggesting to break existing users by making such a clone into an error. But the main point of the discussion is what should happen upon the next git fetch in the repository, no? Shouldn't the refspec be the same as the case where you clone --single a repository whose HEAD is detached at v1.7.10 in that example, instead of saying fetch the same tag over and over? After all that is the way I expect that most people would read treat them line detached HEAD in the documentation. Subsequent git fetch would fetch from the HEAD of the upstream just like a clone from a repository with a detached HEAD. IMO if a user uses clone --single-branch --branch tag, then he/she wants to have this tag only. Why should the next git fetch fetching something different? I read treat them like detached HEAD in the way that the resulting repo is in a detached HEAD state. The above is *not* a rhetorical question; I just do not think of a sensible reason why we want a refspec that says keep updating the v1.7.10 tag, as it might change on the other end, and do not bother what other things that happen in that upstream repository. What sensible workflow would benefit from such a refspec? When using a tag in a different meaning than tag this version and do never change it, for example if someone uses a tag to describe which revision of the project was lastly delivered to the customer, then they could use a tag delivered. After a new version was delivered, someone changes this tag from revx to revy. Having such a refspec, you can fetch this tag and always get the delivered version. This example is very theoretically. -- 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: Remove all files except a few files, using filter-branch
--index-filter git rm --cached -qr -- . git reset -q -- filename Hmm... I tried as you said, but it seems to lose history. In the below example, after rewriting there must be two commits for 'b' file but only one exists. ~$ git init filter-branch2 Initialized empty Git repository in /home/nori/mysrc/test/git/filter-branch2/.git/ ~/filter-branch2$ cd filter-branch2 ~/filter-branch2$ echo 1 a ~/filter-branch2$ echo 1 b ~/filter-branch2$ git add a b ~/filter-branch2$ git commit -m 'first' [master (root-commit) ae2b5fd] first 2 files changed, 2 insertions(+) create mode 100644 a create mode 100644 b ~/filter-branch2$ echo 2 b ~/filter-branch2$ git add b ~/filter-branch2$ git commit -m 'second' [master a32b84e] second 1 file changed, 1 insertion(+) ~/filter-branch2$ git filter-branch --index-filter git rm --cached -qr -- . git reset -q -- b Rewrite a32b84ed7cec5686e43a47195dfa8114f83619f3 (2/2) Ref 'refs/heads/master' was rewritten ~/filter-branch2$ git log -- b commit 19611f9eaf412232e237afcc059d0324a862062f Author: Yi EungJun semtlen...@gmail.com Date: Tue Sep 18 23:51:53 2012 +0900 first Am I doing something wrong? On Mon, Sep 17, 2012 at 2:06 AM, Andreas Schwab sch...@linux-m68k.org wrote: Yi, EungJun semtlen...@gmail.com writes: Hi, all. I want to remove all files except a few files, in the history of my git repository. I tried to do that as follows: git filter-branch --index-filter git rm --cached --ignore-unmatch $(git ls-files | grep -v '^filename$' | tr '\n' ' ') Try instead first removing all files, then restoring the files you want to keep. --index-filter git rm --cached -qr -- . git reset -q -- filename Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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: Remove all files except a few files, using filter-branch
Am 9/18/2012 17:01, schrieb Yi, EungJun: --index-filter git rm --cached -qr -- . git reset -q -- filename Hmm... I tried as you said, but it seems to lose history. I think it should be '... git reset -q $GIT_COMMIT -- filename' -- Hannes -- 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: Remove all files except a few files, using filter-branch
I think it should be '... git reset -q $GIT_COMMIT -- filename' It works! Thanks to Hannes and Andreas! On Wed, Sep 19, 2012 at 12:10 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 9/18/2012 17:01, schrieb Yi, EungJun: --index-filter git rm --cached -qr -- . git reset -q -- filename Hmm... I tried as you said, but it seems to lose history. I think it should be '... git reset -q $GIT_COMMIT -- filename' -- Hannes -- 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] Documentation/git-filter-branch: Move note about effect of removing commits
The note that explains that changes introduced by removed commits are preserved should be placed directly after the paragraph that describes such commits removal. Otherwise the reference to the commits appears out of context. Signed-off-by: Andreas Schwab sch...@linux-m68k.org --- Documentation/git-filter-branch.txt | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 15e7ac8..6e2d9ea 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -304,6 +304,11 @@ committed a merge between P1 and P2, it will be propagated properly and all children of the merge will become merge commits with P1,P2 as their parents instead of the merge commit. +*NOTE* the changes introduced by the commits, and which are not reverted +by subsequent commits, will still be in the rewritten branch. If you want +to throw out _changes_ together with the commits, you should use the +interactive mode of 'git rebase'. + You can rewrite the commit log messages using `--msg-filter`. For example, 'git svn-id' strings in a repository created by 'git svn' can be removed this way: @@ -329,11 +334,6 @@ git filter-branch --msg-filter ' ' HEAD~10..HEAD -*NOTE* the changes introduced by the commits, and which are not reverted -by subsequent commits, will still be in the rewritten branch. If you want -to throw out _changes_ together with the commits, you should use the -interactive mode of 'git rebase'. - Consider this history: -- 1.7.12 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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: [PATCHv5] clone --single: limit the fetch refspec to fetched branch
Ralf Thielow ralf.thie...@gmail.com writes: IMO if a user uses clone --single-branch --branch tag, then he/she wants to have this tag only. Why should the next git fetch fetching something different? OK, I can buy 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: [PATCH/RFC] Port to HP NonStop
Joachim Schmitz j...@schmitz-digital.de writes: From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, September 18, 2012 9:57 AM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH/RFC] Port to HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: Needs a different link order in Makefile: libintl before libiconv. This may affect other platforms, so needs some checking. It will, and it needs customization, not checking. How? By not moving things around to affect other people, but having them in the order you want only for your platform (and other future ports that need similar treatment)? For example, if you need libintl before libiconv, a quick and dirty way may be diff --git i/Makefile w/Makefile index a49d1db..9b2cfd6 100644 --- i/Makefile +++ w/Makefile @@ -1552,6 +1552,9 @@ ifdef NEEDS_LIBICONV else ICONV_LINK = endif + ifdef NEEDS_LIBINTL_BEFORE_LIBICONV + ICONV_LINK += -lintl + endif EXTLIBS += $(ICONV_LINK) -liconv endif ifdef NEEDS_LIBGEN and your linker command line may have -lintl -liconv -lintl but that wouldn't be an error, and you know you won't be affecting other platforms that do not use NEEDS_LIBINTL_BEFORE_LIBICONV, no? -- 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] Port to HP NonStop
From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, September 18, 2012 7:03 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH/RFC] Port to HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, September 18, 2012 9:57 AM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH/RFC] Port to HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: Needs a different link order in Makefile: libintl before libiconv. This may affect other platforms, so needs some checking. It will, and it needs customization, not checking. How? By not moving things around to affect other people, but having them in the order you want only for your platform (and other future ports that need similar treatment)? For example, if you need libintl before libiconv, a quick and dirty way may be diff --git i/Makefile w/Makefile index a49d1db..9b2cfd6 100644 --- i/Makefile +++ w/Makefile @@ -1552,6 +1552,9 @@ ifdef NEEDS_LIBICONV else ICONV_LINK = endif + ifdef NEEDS_LIBINTL_BEFORE_LIBICONV + ICONV_LINK += -lintl + endif EXTLIBS += $(ICONV_LINK) -liconv endif ifdef NEEDS_LIBGEN and your linker command line may have -lintl -liconv -lintl but that wouldn't be an error, and you know you won't be affecting other platforms that do not use NEEDS_LIBINTL_BEFORE_LIBICONV, no? OK, sounds good, I'll try that and submit an updated patch if it works that way (and I'm pretty sure it does). Anything else I should change in my patch? -- 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] string_list API: document what sorted means.
Michael Haggerty mhag...@alum.mit.edu writes: If another sort order is needed, then we will either have to audit existing string_list users to make sure that they don't rely on strcmp() ordering, or we will have to implement strcmp() ordering *plus* the new ordering. What I was envisioning was to pass in an optional custom comparison when you instantiate a string_list object. Existing callers that rely on (or can live with, because they do not care about the exact order) the default order will continue to use the byte-value ordering, so there is no need for auditing. Only the new callers that want different ordering would set custom comparison routine. But now I wrote it down, I realize that there is no _harm_ in documenting we sort in byte-value order, so expect iterations on sorted string list to give them in that order to you at all. So let's go with your documentation patch as-is. It's not that I'm unwilling to implement 2; it's just that I still don't see any advantage to doing so before there is a demonstrated need for it. As I said, I have this suspicion that the lack of demonstrated need is largely because the existing code that do _not_ use string-list don't do so because the interface is limited, so the argument is sort of self-fulfilling. -- 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] grep.c: Fix a sparse warning
In particular, sparse complains that ... 'dump_grep_expression'
was not declared. Should it be static?. In order to suppress
the warning, since this function does not need more than file
scope, we simply include the static modifier in it's declaration.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Junio,
I prefer to catch these before they progress to next, but it seems
I've not been quick enough lately! Sorry about that. :( [I will have
to git-fetch more frequently; at present I only fetch about 3 times
a week.]
I've been away for a few days, so I'm well behind ... (I'm just
about to download 350+ emails for me to read tonight!).
ATB,
Ramsay Jones
grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grep.c b/grep.c
index 925aa92..38c4d75 100644
--- a/grep.c
+++ b/grep.c
@@ -403,7 +403,7 @@ static void dump_grep_expression_1(struct grep_expr *x, int
in)
}
}
-void dump_grep_expression(struct grep_opt *opt)
+static void dump_grep_expression(struct grep_opt *opt)
{
struct grep_expr *x = opt-pattern_expression;
--
1.7.12
--
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: git diff across submodules
Am 18.09.2012 05:12, schrieb Kenny Simpson: Is there any nice way to get a diff and/or diffstat of both a project and its submodules between two revisions of the main project? Something like 'git diff --stat tag_a tag_b' but also including the diffstat on the submodule from the revision tied to in tag_a to the revision tied to tag_b. A few shell backflips will do it, but this seems like I'm missing something. Unfortunately that isn't possible yet, git diff still has to learn the --recurse-submodules option. And as far as I know, nobody is currently working on 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: How to create the [PATCH 0/5] first email?
Jeff King p...@peff.net writes: But even without that, I still think format-patch is a reasonable time to do it. It is the time when I proof-read my commit message and patch in its final form, and think do I really want to send this?. But it is not like I cannot sign off because I think it is still iffy. seems to me like a reasonable time to make such a conscious decision to signoff (or not). But your point still stands; commit -s will not see through that official trick either ;-). Yes. :) Actually, no. commit -s does not have any need to see through it. ... hack hack hack ... $ git commit -a -s ... editor opens, you see your Sign-off at the end, with ... the cursor sitting on the first line ... edit the title, move to the line below the Sign-off, ... and do the ---\n\n * comment thing. And this survives rebase -i (but not format-patch | am for obvious reasons). So I take it back. The time you do the git commit for the very first time for this change that may need to be rerolled number of times is the right time to say -s. -- 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
[PATCHv6] clone --single: limit the fetch refspec to fetched branch
After running git clone --single, the resulting repository has the
usual default +refs/heads/*:refs/remotes/origin/* wildcard fetch
refspec installed, which means that a subsequent git fetch will
end up grabbing all the other branches.
Update the fetch refspec to cover only the singly cloned ref instead
to correct this.
That means:
If --single is used without --branch or --mirror, the
fetch refspec covers the branch on which remote's HEAD points to.
If --single is used with --branch, it'll cover only the branch
specified in the --branch option.
If --single is combined with --mirror, then it'll cover all
refs of the cloned repository.
If --single is used with --branch that specifies a tag, then
it'll cover only the ref for this tag.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
changes in v6
- remove initial created tests (they tested in a too deep level)
- add tests for --mirror option
- add tests for the case of cloning a tag
- update commit message
I've tried to update Documentation/git-clone.txt, but I don't
know in which way this patch changes already described behaviour.
The resulting refspec seems only be covered in the last part of
the --single-branch section by describing --no-single-branch,
but this hasn't changed. Or did I miss something?
builtin/clone.c | 66 -
t/t5709-clone-refspec.sh | 145 +++
2 Dateien geändert, 197 Zeilen hinzugefügt(+), 14 Zeilen entfernt(-)
create mode 100755 t/t5709-clone-refspec.sh
diff --git a/builtin/clone.c b/builtin/clone.c
index 5e8f3ba..431635c 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -610,6 +610,55 @@ static void write_config(struct string_list *config)
}
}
+static void write_refspec_config(const char* src_ref_prefix,
+ const struct ref* our_head_points_at,
+ const struct ref* remote_head_points_at, struct strbuf*
branch_top)
+{
+ struct strbuf key = STRBUF_INIT;
+ struct strbuf value = STRBUF_INIT;
+
+ if (option_mirror || !option_bare) {
+ if (option_single_branch !option_mirror) {
+ if (option_branch) {
+ if (strstr(our_head_points_at-name,
refs/tags/))
+ strbuf_addf(value, +%s:%s,
our_head_points_at-name,
+ our_head_points_at-name);
+ else
+ strbuf_addf(value, +%s:%s%s,
our_head_points_at-name,
+ branch_top-buf, option_branch);
+ } else if (remote_head_points_at) {
+ strbuf_addf(value, +%s:%s%s,
remote_head_points_at-name,
+ branch_top-buf,
+
skip_prefix(remote_head_points_at-name, refs/heads/));
+ }
+ /*
+* otherwise, the next git fetch will
+* simply fetch from HEAD without updating
+* any remote tracking branch, which is what
+* we want.
+*/
+ } else {
+ strbuf_addf(value, +%s*:%s*, src_ref_prefix,
branch_top-buf);
+ }
+ /* Configure the remote */
+ if (value.len) {
+ strbuf_reset(key);
+ strbuf_addf(key, remote.%s.fetch, option_origin);
+ git_config_set_multivar(key.buf, value.buf, ^$, 0);
+ strbuf_reset(key);
+
+ if (option_mirror) {
+ strbuf_addf(key, remote.%s.mirror,
option_origin);
+ git_config_set(key.buf, true);
+ strbuf_reset(key);
+ }
+ }
+ }
+
+ strbuf_release(key);
+ strbuf_release(value);
+}
+
int cmd_clone(int argc, const char **argv, const char *prefix)
{
int is_bundle = 0, is_local;
@@ -755,20 +804,6 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
}
strbuf_addf(value, +%s*:%s*, src_ref_prefix, branch_top.buf);
-
- if (option_mirror || !option_bare) {
- /* Configure the remote */
- strbuf_addf(key, remote.%s.fetch, option_origin);
- git_config_set_multivar(key.buf, value.buf, ^$, 0);
- strbuf_reset(key);
-
- if (option_mirror) {
- strbuf_addf(key, remote.%s.mirror, option_origin);
- git_config_set(key.buf, true);
- strbuf_reset(key);
- }
- }
-
strbuf_addf(key, remote.%s.url, option_origin);
git_config_set(key.buf, repo);
strbuf_reset(key);
@@ -853,6 +888,9
Re: How to create the [PATCH 0/5] first email?
On Tue, Sep 18, 2012 at 12:11:58PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: But even without that, I still think format-patch is a reasonable time to do it. It is the time when I proof-read my commit message and patch in its final form, and think do I really want to send this?. But it is not like I cannot sign off because I think it is still iffy. No, that is not the particular reason in my case, but I think I explained other reasons why format-patch -s is not a wrong workflow. But your point still stands; commit -s will not see through that official trick either ;-). Yes. :) Actually, no. commit -s does not have any need to see through it. ... hack hack hack ... $ git commit -a -s ... editor opens, you see your Sign-off at the end, with ... the cursor sitting on the first line ... edit the title, move to the line below the Sign-off, ... and do the ---\n\n * comment thing. And this survives rebase -i (but not format-patch | am for obvious reasons). Yes, if your particular workflow is to signoff the very first time you commit. But it would not work for: ... hack hack hack ... $ git commit -a ... make a note after --- ... ... hack hack hack ... ... OK, looks good, ready to signoff ... $ git commit --amend -s So it can work, but it is workflow dependent, and in general is a little flaky with the automagic signoff. You may want to signoff later for a variety of reasons, not the least of which is that you forgot to type -s the first time. So I take it back. The time you do the git commit for the very first time for this change that may need to be rerolled number of times is the right time to say -s. If you remember to type 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: git diff across submodules
Jens Lehmann jens.lehm...@web.de writes: Am 18.09.2012 05:12, schrieb Kenny Simpson: Is there any nice way to get a diff and/or diffstat of both a project and its submodules between two revisions of the main project? Something like 'git diff --stat tag_a tag_b' but also including the diffstat on the submodule from the revision tied to in tag_a to the revision tied to tag_b. A few shell backflips will do it, but this seems like I'm missing something. Unfortunately that isn't possible yet, git diff still has to learn the --recurse-submodules option. And as far as I know, nobody is currently working on that. I do not think it is _that_ unfortunate, at least for two reasons. When I made something a submodule, not a plain vanilla directory, I did want it to be treated differently from a collection of files in random states (which is what a directory is), but as a logical unit. If I bind another project 'frotz' at my path 'lib/frotz' and ask for diff of two versions of my superproject, e.g. $ git diff v1.0 v1.1 I am more interested in finding out that we used to use v2.5 of 'frotz' back when we were at v1.0 but in our v1.1 we downgraded it to v2.4, perhaps because we found a regression in the 'frotz' library, rather than the whole reverse differences between v2.4 and v2.5 of the frotz project. That difference, when I want to, I can get by going to that submodule and grab it myself with $ cd lib/frotz 7 git diff v2.4 v2.5 I also suspect that you do not have to change git diff at all to show the patch recursively by using the attribute mechanism (look in Documentation/gitattributes.text for a string GIT_EXTERNAL_DIFF). It might be just as simple as doing this: echo .gitattributes /lib/frotz diff=subrecurse git config diff.subrecurse.command $HOME/bin/diff-subrecurse cat $HOME/bin/diff-subrecurse \-EOF #!/bin/sh path=$1 old_hex=$3 new_hex=$6 unset GIT_DIR cd $path || exit 1 git diff $old_hex $new_hex EOF chmod +x $HOME/bin/diff-subrecurse The corner cases like new submodule, removed submodule are left as an exercise to the reader ;-) -- 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: git archive --format zip utf-8 issues
Hello again, so two weeks have passed, and I've moved at a glacial pace towards a method how to measure compatibility of our generated ZIP files. Sorry, I just keep getting distracted. Anyway, the idea is to have a bunch of files with names using different scripts, zip them with several packers (including git archive), unzip them and compare the result with the original files. As test corpus I used files named like the pangrams on this UTF-8 sampler page, the exact commands are attached: http://www.columbia.edu/~fdc/utf8/index.html#quickbrownfox The numbers below are how many lines the output of diff -ru contains for this pair of packer and unpacker. There are 37 files, so the worst result is 74 lines of difference (Only in [...] for both sides), while 0 indicates a perfect score. Hmm, come to think of it, an empty directory would show up as 37, so this metric is not ideal. A better one would be to simply give one point for each correctly unpacked file. WindowsInfo-ZIP unzip 7-Zip PeaZip builtin Linux msysgit Windows 7-Zip 9.20 0 0 4626 43 43 PeaZip 4.7.1 win64 0 0 4626 42 42 Info-ZIP zip 3.0 Linux 0 0 72 0 43 43 Info-ZIP zip 3.0 Windows 45 45 n/a 0 43 43 git-master 72 72 7260 72 72 git-master-patch1 0 0 7260 72 72 git-master-patch2 0 0 72 0 72 72 git-v1.7.11.msysgit.1 72 72 7260 72 72 git-v1.7.11.msysgit.1-patch10 0 7260 72 72 git-v1.7.11.msysgit.1-patch20 0 72 0 72 72 Info-ZIP's programs don't work too well on Windows. The built-in unzipper of Windows 7 even refuses to open the file created by the Windows version of zip. Speaking of which, this is the worst of the unpackers. With the two patches applied, we can say use 7-Zip or PeaZip on Windows and unzip on Linux and filenames with all tested characters will be preserved. I was surprised to see this working fine with msysgit like that, even though no reencoding is introduced by the patches. I wonder what 7-Zip and PeaZip do that gives them a slightly nicer score with the Windows-internal unzipper. Umlauts, Nordic characters and accents are preserved by that combination. It seems that unzip on Linux fails to unpack exactly these names, so perhaps they employ a dirty trick like using the local encoding in the ZIP file, which makes it unportable. I'll reply with the two patches, which contain basically the same code as the previous patch, only split up. The second one declares that filenames with UTF-8 encoding came from Unix (instead of FAT), which makes unzip happy. This, however, implies that we contain Unix permissions for these entries, which is a bit ugly. René #!/bin/sh ( mkdir pangrams cd pangrams echo English The quick brown fox jumps over the lazy dog echo Irish 1 An ḃfuil do Ä‹roà ag bualaḋ ó ḟaitÃos an Ä¡rá a á¹�eall echo Irish 2 lena ṗóg éada ó ṡlà do leasa ṫú echo Irish 3 D'ḟuascail Ã�osa Úrá¹�ac na hÓiÄ¡e Beannaiṫe pór echo Irish 4 Éava agus Ã�ḋaiá¹� echo Dutch Pa's wijze lynx bezag vroom het fikse aquaduct echo German 1 Falsches Ãœben von Xylophonmusik quält echo German 2 jeden größeren Zwerg echo Norwegian BlÃ¥bærsyltetøy echo Danish Høj bly gom vandt fræk sexquiz pÃ¥ wc echo Swedish Flygande bäckasiner söka strax hwila pÃ¥ mjuka tuvor echo Icelandic Sævör grét áðan þvà úlpan var ónýt echo Finnish Törkylempijävongahdus echo Polish Pchnąć w tÄ™ łódź jeża lub osiem skrzyÅ„ fig echo Czech PÅ™ÃliÅ¡ žluÅ¥ouÄ�ký kůň úpÄ›l Ä�ábelské kódy echo Slovak 1 Starý kôň na hÅ•be knÃh žuje tÃÅ¡ko povädnuté ruže echo Slovak 2 na stĺpe sa Ä�ateľ uÄ�à kvákaÅ¥ novú ódu o živote echo monotonic Greek ξεσκεπάζω την ψυχοφθόÏ�α βδελυγμία echo polytonic Greek ξεσκεπάζω τὴν ψυχοφθόÏ�α βδελυγμία echo Russian Съешь же ещё Ñ�тих мÑ�гких французÑ�ких булок да выпей чаю echo Bulgarian 1 Жълтата дюлÑ� беше щаÑ�тлива echo Bulgarian 2 че пухът, който цъфна, замръзна като гьон echo Northern Sami Vuol Ruoŧa geÄ‘ggiid leat máŋga luosa ja Ä�uovžža echo Hungarian Ã�rvÃztűrÅ‘ tükörfúrógép echo Spanish 1 El pingüino Wenceslao hizo kilómetros bajo exhaustiva echo Spanish 2 lluvia y frÃo añoraba a su querido cachorro echo
Re: [PATCHv6] clone --single: limit the fetch refspec to fetched branch
Ralf Thielow ralf.thie...@gmail.com writes: After running git clone --single, the resulting repository has the usual default +refs/heads/*:refs/remotes/origin/* wildcard fetch refspec installed, which means that a subsequent git fetch will end up grabbing all the other branches. Update the fetch refspec to cover only the singly cloned ref instead to correct this. That means: If --single is used without --branch or --mirror, the fetch refspec covers the branch on which remote's HEAD points to. If --single is used with --branch, it'll cover only the branch specified in the --branch option. If --single is combined with --mirror, then it'll cover all refs of the cloned repository. If --single is used with --branch that specifies a tag, then it'll cover only the ref for this tag. Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- changes in v6 - remove initial created tests (they tested in a too deep level) - add tests for --mirror option - add tests for the case of cloning a tag - update commit message I've tried to update Documentation/git-clone.txt, but I don't know in which way this patch changes already described behaviour. The resulting refspec seems only be covered in the last part of the --single-branch section by describing --no-single-branch, but this hasn't changed. Or did I miss something? I do not think we are changing anything. The whole --single-branch was an half-baked afterthought hack that nobody anticipated the user to later issue git fetch in the resulting repository, and everybody involved in the series (the maintainer included) were just happy to see the resulting code only transferred objects needed for the branch without wasting bandwidth for objects needed for other branches, and stopped thinking beyond that X-. If anything, we need to _add_ the description of what happens when further fetches are done. The second and the third paragraph in the DESCRIPTION section talks only about the normal case, so at least at the end of the second paragraph we should say But if you use --single-branch, all of this is different. And what happens when you do use --single-branch should be described in the part that describes that option, e.g. Documentation/git-clone.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git c/Documentation/git-clone.txt w/Documentation/git-clone.txt index c1ddd4c..f59bc49 100644 --- c/Documentation/git-clone.txt +++ w/Documentation/git-clone.txt @@ -29,7 +29,8 @@ currently active branch. After the clone, a plain `git fetch` without arguments will update all the remote-tracking branches, and a `git pull` without arguments will in addition merge the remote master branch into the -current master branch, if any. +current master branch, if any (this is untrue when --single-branch +is given; see below). This default configuration is achieved by creating references to the remote branch heads under `refs/remotes/origin` and @@ -152,9 +153,11 @@ objects from the source repository into a pack in the cloned repository. -b name:: Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository's HEAD, point to `name` branch - instead. `--branch` can also take tags and treat them like - detached HEAD. In a non-bare repository, this is the branch + instead. In a non-bare repository, this is the branch that will be checked out. ++ +`--branch` can also take tags and detaches the HEAD +at that commit in the resulting repository. --upload-pack upload-pack:: -u upload-pack:: @@ -193,6 +196,12 @@ objects from the source repository into a pack in the cloned repository. clone with the `--depth` option, this is the default, unless `--no-single-branch` is given to fetch the histories near the tips of all branches. ++ +Further fetches into the resulting repository will only update the +remote tracking branch for the branch this option was used for the +initial cloning. If the HEAD at the remote did not point at any +branch when `--single-branch` clone was made, no remote tracking +branch is created. --recursive:: --recurse-submodules:: -- 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: [PATCHv6] clone --single: limit the fetch refspec to fetched branch
Ralf Thielow ralf.thie...@gmail.com writes: + ... + # explicit --single with tag + git clone --single-branch --branch two . dir_tag + + # advance both master and side branches + git checkout side + echo five file + git commit -a -m five + git checkout master + echo six file + git commit -a -m six Don't we also want to cover your delivery tag scenario by updating the tag two before letting the clones fetch in the following test? + ... +test_expect_success '--single-branch with explicit --branch tag' ' + ( + cd dir_tag git fetch + git for-each-ref refs/tags ../actual + ) + git for-each-ref refs/tags expect + test_cmp expect actual +' -- 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 1/2] archive-zip: support UTF-8 paths
Set general purpose flag 11 if we encounter a path that contains
non-ASCII characters. We assume that all paths are given as UTF-8; no
conversion is done.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
Changes from previous version: Stop using has_non_ascii(), which does
slightly too much for our purposes, and split off creator version
change into a separate patch.
archive-zip.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/archive-zip.c b/archive-zip.c
index f5af81f..0f763e8 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -4,6 +4,7 @@
#include cache.h
#include archive.h
#include streaming.h
+#include utf8.h
static int zip_date;
static int zip_time;
@@ -16,7 +17,8 @@ static unsigned int zip_dir_offset;
static unsigned int zip_dir_entries;
#define ZIP_DIRECTORY_MIN_SIZE (1024 * 1024)
-#define ZIP_STREAM (8)
+#define ZIP_STREAM (1 3)
+#define ZIP_UTF8 (1 11)
struct zip_local_header {
unsigned char magic[4];
@@ -164,6 +166,17 @@ static void set_zip_header_data_desc(struct
zip_local_header *header,
copy_le32(header-size, size);
}
+static int has_only_ascii(const char *s)
+{
+ for (;;) {
+ int c = *s++;
+ if (c == '\0')
+ return 1;
+ if (!isascii(c))
+ return 0;
+ }
+}
+
#define STREAM_BUFFER_SIZE (1024 * 16)
static int write_zip_entry(struct archiver_args *args,
@@ -187,6 +200,13 @@ static int write_zip_entry(struct archiver_args *args,
crc = crc32(0, NULL, 0);
+ if (!has_only_ascii(path)) {
+ if (is_utf8(path))
+ flags |= ZIP_UTF8;
+ else
+ warning(Path is not valid UTF-8: %s, path);
+ }
+
if (pathlen 0x) {
return error(path too long (%d chars, SHA1: %s): %s,
(int)pathlen, sha1_to_hex(sha1), path);
--
1.7.12
--
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: How to create the [PATCH 0/5] first email?
Jeff King p...@peff.net writes: On Tue, Sep 18, 2012 at 12:11:58PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: But even without that, I still think format-patch is a reasonable time to do it. It is the time when I proof-read my commit message and patch in its final form, and think do I really want to send this?. But it is not like I cannot sign off because I think it is still iffy. No, that is not the particular reason in my case, but I think I explained other reasons why format-patch -s is not a wrong workflow. Then I didn't read it. What does do I really want to send this? have anything to do with DCO in any case? -- 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] grep.c: Fix a sparse warning
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
In particular, sparse complains that ... 'dump_grep_expression'
was not declared. Should it be static?. In order to suppress
the warning, since this function does not need more than file
scope, we simply include the static modifier in it's declaration.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Junio,
I prefer to catch these before they progress to next, but it seems
I've not been quick enough lately! Sorry about that. :( [I will have
to git-fetch more frequently; at present I only fetch about 3 times
a week.]
I've been away for a few days, so I'm well behind ... (I'm just
about to download 350+ emails for me to read tonight!).
Thanks; doesn't 07a7d65 (grep.c: mark private file-scope symbols as
static, 2012-09-15) cover this already, though?
ATB,
Ramsay Jones
grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grep.c b/grep.c
index 925aa92..38c4d75 100644
--- a/grep.c
+++ b/grep.c
@@ -403,7 +403,7 @@ static void dump_grep_expression_1(struct grep_expr *x,
int in)
}
}
-void dump_grep_expression(struct grep_opt *opt)
+static void dump_grep_expression(struct grep_opt *opt)
{
struct grep_expr *x = opt-pattern_expression;
--
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] Documentation/git-filter-branch: Move note about effect of removing commits
Andreas Schwab sch...@linux-m68k.org writes: Junio C Hamano gits...@pobox.com writes: So something like this instead? I agree it's even better. Andreas. Thanks for proofreading. I'll squash in the differences to your patch. -- 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/2] archive-zip: declare creator to be Unix for UTF-8 paths
The UTF-8 flag seems to be ignored by unzip unless we also mark the
archive entry as coming from a Unix system. This is done by setting the
field creator_version (version made by in the standard[1]) to 0x03NN.
The NN part represents the version of the standard supported by us, and
this patch sets it to 3f (for version 6.3) for Unix paths. We keep
creator_version set to 0 (FAT filesystem, standard version 0) in the
non-special cases, as before.
But when we declare a file to have a Unix path, then we have to set the
file mode as well, or unzip will extract the files with the permission
set , i.e. inaccessible by all.
[1] http://www.pkware.com/documents/casestudies/APPNOTE.TXT
---
No sign-off for this, yet. Perhaps there is a better way to convince
unzip to respect the flag? And if not, do we need to offer umask
settings for ZIP as well as we have for tar? And perhaps declare all
files as being from a Unix filesystem, for consistency?
archive-zip.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 0f763e8..e9b3dc9 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -186,7 +186,8 @@ static int write_zip_entry(struct archiver_args *args,
{
struct zip_local_header header;
struct zip_dir_header dirent;
- unsigned long attr2;
+ unsigned int creator_version = 0;
+ unsigned long attr2 = 0;
unsigned long compressed_size;
unsigned long crc;
unsigned long direntsize;
@@ -224,10 +225,15 @@ static int write_zip_entry(struct archiver_args *args,
enum object_type type = sha1_object_info(sha1, size);
method = 0;
- attr2 = S_ISLNK(mode) ? ((mode | 0777) 16) :
- (mode 0111) ? ((mode) 16) : 0;
if (S_ISREG(mode) args-compression_level != 0 size 0)
method = 8;
+ if (S_ISLNK(mode) || (mode 0111) || (flags ZIP_UTF8)) {
+ creator_version = 0x033f;
+ attr2 = mode;
+ if (S_ISLNK(mode))
+ attr2 |= 0777;
+ attr2 = 16;
+ }
compressed_size = size;
if (S_ISREG(mode) type == OBJ_BLOB !args-convert
@@ -274,8 +280,7 @@ static int write_zip_entry(struct archiver_args *args,
}
copy_le32(dirent.magic, 0x02014b50);
- copy_le16(dirent.creator_version,
- S_ISLNK(mode) || (S_ISREG(mode) (mode 0111)) ? 0x0317 : 0);
+ copy_le16(dirent.creator_version, creator_version);
copy_le16(dirent.version, 10);
copy_le16(dirent.flags, flags);
copy_le16(dirent.compression_method, method);
--
1.7.12
--
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: How to create the [PATCH 0/5] first email?
From: Junio C Hamano gits...@pobox.com have anything to do with DCO in any case? Junio, What's DCO an abbreviation of? Philip -- 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: How to create the [PATCH 0/5] first email?
On Tue, Sep 18, 2012 at 12:47:36PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: But even without that, I still think format-patch is a reasonable time to do it. It is the time when I proof-read my commit message and patch in its final form, and think do I really want to send this?. But it is not like I cannot sign off because I think it is still iffy. No, that is not the particular reason in my case, but I think I explained other reasons why format-patch -s is not a wrong workflow. Then I didn't read it. What does do I really want to send this? have anything to do with DCO in any case? Because it is an excellent time to think about am I willing and able to agree to the DCO? As I said, for me personally working on git.git, that is not generally an issue. But I think it is perfectly reasonable for somebody to work and commit in isolation, and then only decide on the DCO during the sending phase (perhaps because they need to clear it with their company's legal department or some such). In other words, it is iffy at the time of commit might be exactly the reason for some people. If you are responding to my that is not the particular reason in my case, I will paraphrase the reason I gave earlier: I find it annoying and pointless to type -s on every commit. We do not have commit.signoff, but we do have format.signoff. -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] rebase -i: fix misleading error message after 'exec no-such' instruction
Johannes Sixt j.s...@viscovery.net writes: From: Johannes Sixt j...@kdbg.org When the todo sheet of interactive rebase instructs to run a non-existing command, the operation stops with the following error: Execution failed: no-such You can fix the problem, and then run git rebase --continue fatal: 'rebase' appears to be a git command, but we were not able to execute it. Maybe git-rebase is broken? The reason is that the shell that attempted to run the command exits with code 127. rebase--interactive just forwards this code to the caller (the git wrapper). But our smart run-command infrastructure detects this special exit code and turns it into ENOENT, which in turn is interpreted by the git wrapper as if the external command that it just executed did not exist. That's a funny one ;-) Will queue. 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: Gitweb characters not encoded/decoded properly
On Mon, Sep 10, 2012 at 1:57 PM, Joseph Leong josephcle...@gmail.com wrote: Hi Everyone, I've noticed an issue in gitweb where git projects are created with characters such as: €酮خد㐁ᠡꀈ༑㘚.git But in the gitweb page content, URL section, a git project is rendered incorrectly? Example screenshot: http://i.imgur.com/06skV.png Joseph, What character set is that supposed to be in? In addition, if it is UTF-(something), what code segment are you using? -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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/8] Doc: Improve shallow depth wording
Junio C Hamano gits...@pobox.com writes: Philip Oakley philipoak...@iee.org writes: Avoid confusion in compound sentence about the start of the commit set and the depth measure. Use two sentences. Dropping the first ',' after positive depth does not seem to make it any easier to read (I personally think it makes it a lot harder to read). Splitting the tail-end of the sentence into a separate sentence does make it easier to read, though. Will add ',' locally and queue; no need to resend. 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: How to create the [PATCH 0/5] first email?
On Monday, September 17, 2012 17:49:39 Junio C Hamano wrote: Philip Oakley philipoak...@iee.org writes: I then applied it (using git am) to a temp branch to see what it produced, and could repeat the cycle until the patches looked right. That's another obvious and valid way to prepare your series. It all depends on how comfortable you are to directly edit patches. Some people fear it. Some don't. Some can do it with their eyes closed ;-). However, when it came to creating the series, with comments, I couldn't see a way of having my comments within my local commits, but preparing a patch series that would properly include the '---' separator. An unofficial trick that works is to write the --- * This is an additional comment yourself when running git commit. That will be propagated to the output from format-patch. You will have another --- in front of the diffstat, but nobody is hurt by that. One thing I have done is to add the additional comments I want with git notes, then give the --notes option to format-patch or send-email. Unfortunately, this sticks the notes right into the commit message section, because the --notes option is actually a diff option, not something format-patch knows about, so you have to make sure to manually move it. But even so, I've found it a a nice way to track comments. -- 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] Allow fancy globs in git-svn init branches
Ammon Riley ammon.ri...@gmail.com wrote:
Branches passed to 'git-svn init' via the -b/--branches flag
automatically had a /* appended to them. When the branch contained
a fancy glob with a {} pattern, this is incorrect behaviour, and
leads to odd branches being created in the git repository.
Signed-off-by: Ammon Riley ammon.ri...@gmail.com
---
git-svn.perl | 2 +-
t/t9141-git-svn-multiple-branches.sh | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0d77ffb..f8e8558 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1678,7 +1678,7 @@ sub complete_url_ls_init {
my $remote_path = join_paths( $gs-path, $repo_path );
$remote_path =~ s{%([0-9A-F]{2})}{chr hex($1)}ieg;
$remote_path =~ s#^/##g;
- $remote_path .= /* if $remote_path !~ /\*/;
+ $remote_path .= /* if $remote_path !~ m#\*|\{[^/]+\}#;
my ($n) = ($switch =~ /^--(\w+)/);
if (length $pfx $pfx !~ m#/$#) {
die --prefix='$pfx' must have a trailing slash '/'\n;
diff --git a/t/t9141-git-svn-multiple-branches.sh
b/t/t9141-git-svn-multiple-branches.sh
index 3cd0671..1b872a9 100755
--- a/t/t9141-git-svn-multiple-branches.sh
+++ b/t/t9141-git-svn-multiple-branches.sh
@@ -119,4 +119,16 @@ test_expect_success 'create new branches and tags' '
svn_cmd up test -e tags_B/Tag2/a.file )
'
+test_expect_success 'clone multiple branch paths using fancy glob' '
+ git svn clone -T trunk \
+ -b b_one/{first} --branches b_two \
I'm concerned encouraging this can cause confusion on the command-line
for bash users.
In bash, b_one/{first} will be passed as-is (and hardly anybody
will have a repo with '{word}' in the path)
However, unless quoted on the command-line, a likely case of:
b_one/{first,second} will expand to: b_one/first b_one/second
...which causes b_one/second to be interpreted as the destination
directory. A knowledgeable bash user can avoid this by using:
-b=b_one/{first,second} to avoid this situation.
But with the above invocation, no explicit support is needed
for command-line parsing in git-svn.
--
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 v3 05/14] Change fetch_pack() and friends to take string_list arguments
Jeff King p...@peff.net writes: What I think would be much more productive is breaking apart gigantic includes like cache.h into more reasonable modules, which would mean less frequent recompilation when an uninteresting part of the header changes. Ideally cache.h should cover what read-cache.c, sha1_file.c and sha1_name.c do and need. The parts related to sha1_name.c may deserve to have its own header file, as its scope is fairly wide and spans from low-level object name get_sha1_hex() to high level parsing like dwim_ref(). Right now, the header also has pieces that are needed only by connect.c and config.c (not even commented as such), pager, base85, alloc, trace, add, piece of diff, etc. Also we may want to move helper functions that are generally useful and do not depend on specific command to more appropriate files. -- 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] t/test-lib: print pretty msg when git isn't built
Ramkumar Ramachandra artag...@gmail.com writes: When tests were run without building git, the following error message was displayed: .: 54: Can't open /path/to/git/source/t/../GIT-BUILD-OPTIONS Does the test stop due to this error, or it just goes on and hit another error? I am guessing that it is the latter, and if that is the case, a more important change to describe here is Change this to display a more user-friendly error message: error: you do not seem to have built git yet. ... and stop the execution. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t-basic.sh | 10 -- t/test-lib.sh|6 ++ 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/t/t-basic.sh b/t/t-basic.sh index ae6a3f0..08677df 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -18,16 +18,6 @@ swapping compression and hashing order, the person who is making the modification *should* take notice and update the test vectors here. ' - -# It appears that people try to run tests without building... - -../git /dev/null -if test $? != 1 -then - echo 2 'You do not seem to have built git yet.' - exit 1 -fi - . ./test-lib.sh diff --git a/t/test-lib.sh b/t/test-lib.sh index f8e3733..c00452a 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -51,6 +51,12 @@ then fi GIT_BUILD_DIR=$TEST_DIRECTORY/.. +if ! test -r $GIT_BUILD_DIR/GIT-BUILD-OPTIONS +then + echo 'error: you do not seem to have built git yet.' 2 + exit 1 +fi + . $GIT_BUILD_DIR/GIT-BUILD-OPTIONS export PERL_PATH SHELL_PATH -- 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] t/test-lib: print pretty msg when git isn't built
Ramkumar Ramachandra artag...@gmail.com writes: Because that emits an ugly ./test-lib.sh: 54: /home/artagnon/src/git/t/../git: not found Don't you deserve it? ;-) The full message would read ./test-lib.sh: 54: /home/artagnon/src/git/t/../git: not found error: you do not seem to have built git yet. which looks perfectly sensible to me. It makes it clear where on the filesystem the test script expects your git, which is an added benefit. Fair enough- use your version then. Let me know if you want me to submit a revised patch. OK, let's do this. -- 8 -- From: Ramkumar Ramachandra artag...@gmail.com Date: Mon, 17 Sep 2012 22:36:19 +0530 Subject: [PATCH] t/test-lib: print pretty msg when git isn't built When tests were run without building git, they stopped with: .: 54: Can't open /path/to/git/source/t/../GIT-BUILD-OPTIONS Move the check that makes sure that git has already been built from t to test-lib, so that any test will do so before it runs. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t-basic.sh | 10 -- t/test-lib.sh| 7 +++ 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/t/t-basic.sh b/t/t-basic.sh index ccb5435..741b6b6 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -18,16 +18,6 @@ swapping compression and hashing order, the person who is making the modification *should* take notice and update the test vectors here. ' - -# It appears that people try to run tests without building... - -../git /dev/null -if test $? != 1 -then - echo 2 'You do not seem to have built git yet.' - exit 1 -fi - . ./test-lib.sh diff --git a/t/test-lib.sh b/t/test-lib.sh index 78c4286..61930fb 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -51,6 +51,13 @@ then fi GIT_BUILD_DIR=$TEST_DIRECTORY/.. +$GIT_BUILD_DIR/git /dev/null +if test $? != 1 +then + echo 2 'error: you do not seem to have built git yet.' + exit 1 +fi + . $GIT_BUILD_DIR/GIT-BUILD-OPTIONS export PERL_PATH SHELL_PATH -- 1.7.12.563.g54818e4 -- 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] Make test output coloring more intuitive
On Mon, Sep 17, 2012 at 04:11:19PM -0400, Jeff King wrote: On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote: The end result of these changes is that: - red is _only_ used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures with the framework, - yellow is _only_ used for known breakages, and - green is _only_ used for things which have gone to plan and require no further work to be done. Sounds reasonable, and I think the new output looks nice. I notice that skipped tests are still in green. I wonder if they should be in yellow, too. They may or may not be a problem, but you are failing to run some portion of the test suite. Fair point, I'll reroll the series and change skipped tests to yellow (non-bold, to distinguish from known breakages which are bold yellow). diff --git a/t/t-basic.sh b/t/t-basic.sh index ae6a3f0..4e111b4 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -81,9 +81,10 @@ test_expect_success 'pretend we have fixed a known breakage (run in sub test-lib ./passing-todo.sh out 2err ! test -s err sed -e 's/^ //' expect -\\EOF -ok 1 - pretend we have fixed a known breakage # TODO known breakage -# fixed 1 known breakage(s) -# passed all 1 test(s) +ok 1 - pretend we have fixed a known breakage # TODO known breakage vanished +# fixed 1 known breakage(s); please update test(s) +# still have 1 known breakage(s) +# passed all remaining 0 test(s) 1..1 EOF test_cmp expect out) This hunk is surprising after reading the commit message. It looks like you are also breaking down expect_fail tests by fixed and not fixed. Correct. I think that is probably an OK thing to do (although it might make more sense in a separate patch), but are your numbers right? They are right (at least as I intended), but I agree it's a bit confusing. It looks from that count as if there are 2 tests expecting failure (one fixed and one still broken). It's actually one test which is both fixed *and* in some sense broken. The confusion arises from the ambiguity of the word broken, which could mean either failed as expected or expected to fail but didn't. Previously it was just the former, but my patch changed it to encompass both cases. The motivation behind this was to avoid the # passed all $count test(s) summary message which is overly comforting when one or more tests were expected to fail but didn't. However perhaps it's cleaner to keep the counter buckets separated. I'll try to come up with a better solution. -- 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] Make test output coloring more intuitive
On Tue, Sep 18, 2012 at 10:59 PM, Jeff King p...@peff.net wrote: TODO is a special token[1] respected by TAP harnesses like prove. I'm not sure what practical impact it has, but it should probably remain. -Peff [1] http://testanything.org/wiki/index.php/TAP_specification#TODO_tests Thanks, I didn't know that. For reasons I just stated elsewhere in this thread, I don't _completely_ agree with the specification where it says: Should a todo test point begin succeeding, the harness should report it as a bonus. This indicates that whatever you were supposed to do has been done and you should promote this to a normal test point. However those semantics are well-defined enough to warrant keeping the TODO as you suggest. -- 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] Allow fancy globs in git-svn init branches
On Tue, Sep 18, 2012 at 1:46 PM, Eric Wong normalper...@yhbt.net wrote:
Ammon Riley ammon.ri...@gmail.com wrote:
Branches passed to 'git-svn init' via the -b/--branches flag
automatically had a /* appended to them. When the branch contained
a fancy glob with a {} pattern, this is incorrect behaviour, and
leads to odd branches being created in the git repository.
Signed-off-by: Ammon Riley ammon.ri...@gmail.com
---
git-svn.perl | 2 +-
t/t9141-git-svn-multiple-branches.sh | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0d77ffb..f8e8558 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1678,7 +1678,7 @@ sub complete_url_ls_init {
my $remote_path = join_paths( $gs-path, $repo_path );
$remote_path =~ s{%([0-9A-F]{2})}{chr hex($1)}ieg;
$remote_path =~ s#^/##g;
- $remote_path .= /* if $remote_path !~ /\*/;
+ $remote_path .= /* if $remote_path !~ m#\*|\{[^/]+\}#;
my ($n) = ($switch =~ /^--(\w+)/);
if (length $pfx $pfx !~ m#/$#) {
die --prefix='$pfx' must have a trailing slash '/'\n;
diff --git a/t/t9141-git-svn-multiple-branches.sh
b/t/t9141-git-svn-multiple-branches.sh
index 3cd0671..1b872a9 100755
--- a/t/t9141-git-svn-multiple-branches.sh
+++ b/t/t9141-git-svn-multiple-branches.sh
@@ -119,4 +119,16 @@ test_expect_success 'create new branches and tags' '
svn_cmd up test -e tags_B/Tag2/a.file )
'
+test_expect_success 'clone multiple branch paths using fancy glob' '
+ git svn clone -T trunk \
+ -b b_one/{first} --branches b_two \
I'm concerned encouraging this can cause confusion on the command-line
for bash users.
In bash, b_one/{first} will be passed as-is (and hardly anybody
will have a repo with '{word}' in the path)
However, unless quoted on the command-line, a likely case of:
b_one/{first,second} will expand to: b_one/first b_one/second
...which causes b_one/second to be interpreted as the destination
directory. A knowledgeable bash user can avoid this by using:
-b=b_one/{first,second} to avoid this situation.
But with the above invocation, no explicit support is needed
for command-line parsing in git-svn.
I confess that I'd completely forgot about the {} expansion in bash.
Perhaps a note in the CAVEATS section of the documentation would
be sufficient?
As a bit of background on the reason for this patch, the branches
in our repository are set up under svnroot as:
project/releases/branchName/branchName/
I have no idea why. So I end up with an init line like so:
git svn init -T trunk -b 'releases/release_7_0/{release_7_0}' \
-b 'releases/release_7_1/{release_7_1}' \
http://server/svnroot/myProj
This, unfortunately, prevents me from using the shorter {A,B}
notation, so I didn't test 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
[ANNOUNCE] Git v1.7.12.1
The latest maintenance release Git v1.7.12.1 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
c5227b5202947bba3d63dca72662fad02d208800 git-1.7.12.1.tar.gz
b42d5db34612825676d0a231cf9c566f8ad45e9f git-htmldocs-1.7.12.1.tar.gz
2d9c267c5370cdceb2e67f67abf5b152b0c18db9 git-manpages-1.7.12.1.tar.gz
Also the following public repositories all have a copy of the v1.7.12.1
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git 1.7.12.1 Release Notes
==
Fixes since v1.7.12
---
* git apply -p0 did not parse pathnames on diff --git line
correctly. This caused patches that had pathnames in no other
places to be mistakenly rejected (most notably, binary patch that
does not rename nor change mode). Textual patches, renames or mode
changes have preimage and postimage pathnames in different places
in a form that can be parsed unambiguously and did not suffer from
this problem.
* git cherry-pick A C B used to replay changes in A and then B and
then C if these three commits had committer timestamps in that
order, which is not what the user who said A C B naturally
expects.
* git commit --amend let the user edit the log message and then
died when the human-readable committer name was given
insufficiently by getpwent(3).
* Some capabilities were asked by fetch-pack even when upload-pack
did not advertise that they are available. fetch-pack has been
fixed not to do so.
* git diff had a confusion between taking data from a path in the
working tree and taking data from an object that happens to have
name 0{40} recorded in a tree.
* git for-each-ref did not correctly support more than one --sort
option.
* git log .. errored out saying it is both rev range and a path
when there is no disambiguating -- is on the command line.
Update the command line parser to interpret .. as a path in such
a case.
* The --topo-order, --date-order (and the lack of either means
the default order) options to rev-list and log family of
commands were poorly described in the documentation.
* git prune without -v used to warn about leftover temporary
files (which is an indication of an earlier aborted operation).
* Pushing to smart HTTP server with recent Git fails without having
the username in the URL to force authentication, if the server is
configured to allow GET anonymously, while requiring authentication
for POST.
* The reflog entries left by git rebase and git rebase -i were
inconsistent (the interactive one gave an abbreviated object name).
* When git push triggered the automatic gc on the receiving end, a
message from git prune that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
* git show --quiet ought to be a synonym for git show -s, but
wasn't.
* git show --format='%ci' did not give timestamp correctly for
commits created without human readable name on committer line.
* git send-email did not unquote encoded words that appear on the
header correctly, and lost _ from strings.
* The interactive prompt git send-email gives was error prone. It
asked What e-mail address do you want to use? with the address it
guessed (correctly) the user would want to use in its prompt,
tempting the user to say y. But the response was taken as No,
please use 'y' as the e-mail address instead, which is most
certainly not what the user meant.
* gitweb when used with PATH_INFO failed to notice directories with
SP (and other characters that need URL-style quoting) in them.
* When the user gives an argument that can be taken as both a
revision name and a pathname without disambiguating with --, we
used to give a help message Use '--' to separate. The message
has been clarified to show where that '--' goes on the command
line.
* When the user exports a non-default IFS without HT, scripts that
rely on being able to parse ls-files -s | while read a b c...
started to fail. Protect them from such a misconfiguration.
* The attribute system may be asked for a path that itself or its
leading directories no longer exists in the working tree, and it is
fine if we cannot open .gitattribute file in such a case. Failure
to open per-directory .gitattributes with error status other than
ENOENT and ENOTDIR should be diagnosed, but it wasn't.
* After gitk showed the contents of a tag, neither Reread
references nor Reload did not update what is shown as the
contents of it, when the user overwrote the tag with git tag -f.
* ciabot script (in contrib/)
A note from the maintainer
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address git@vger.kernel.org. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say Please Cc: me,
I am not subscribed.
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to jump to the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just git does not work. I used git in this
way, but it did not work is not much better, neither is I used git
in this way, and X happend, which is broken. It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the master branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: master, maint, next, and pu.
The master branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a feature
release is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.7.12 done on
Aug 19, 2012. You can expect that the tip of the master branch is always
more stable than any of the released versions.
Whenever a feature release is made, maint branch is forked off from
master at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.12.1. New features never go to this branch. This branch is also
merged into master to propagate the fixes forward.
A new development does not usually happen on master. When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of master and your
[PATCHv2 0/8] Small documentation updates
My first patch series, adds small documentation updates covering points I had noticed or had to research elsewhere. The small 'git' update applies on top of Junio's changes in 'next'. V2 changes are in patches 3, 5, 6, and 7 The updated patches incorporate corrections and suggestions from Junio Hamano and Matthieu Moy. Philip Philip Oakley (8): Doc: Bundle file usage Doc: shallow clone deepens _to_ new depth Doc: Improve shallow depth wording Doc: 'git' has a discussion section Doc: separate gitignore pattern sources Doc add: link gitignore Doc clean: add See Also link Doc branch: show -vv option and alternative Documentation/fetch-options.txt |3 +- Documentation/git-add.txt |2 +- Documentation/git-branch.txt |5 ++- Documentation/git-bundle.txt | 16 -- Documentation/git-clean.txt |4 +++ Documentation/git.txt |1 + Documentation/gitignore.txt | 30 +--- Documentation/technical/pack-protocol.txt |6 +++- Documentation/urls.txt|3 ++ 9 files changed, 45 insertions(+), 25 deletions(-) -- 1.7.8.msysgit.0 -- 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
[PATCHv2 4/8] Doc: 'git' has a discussion section
Highlight there is a further discussion section later in git man page Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git.txt b/Documentation/git.txt index 34d8a1b..d932a3e 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -30,6 +30,7 @@ After you mastered the basic concepts, you can come back to this page to learn what commands git offers. You can learn more about individual git commands with git help command. linkgit:gitcli[7] manual page gives you an overview of the command line command syntax. +See also the Discussion and Further Documentation sections below. Formatted and hyperlinked version of the latest git documentation can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`. -- 1.7.8.msysgit.0 -- 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
[PATCHv2 6/8] Doc add: link gitignore
Use a gitignore link rather than the gitrepository- layout link. Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 9c1d395..fd9e36b 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -155,7 +155,7 @@ Configuration The optional configuration variable `core.excludesfile` indicates a path to a file containing patterns of file names to exclude from git-add, similar to $GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to -those in info/exclude. See linkgit:gitrepository-layout[5]. +those in info/exclude. See linkgit:gitignore[5]. EXAMPLES -- 1.7.8.msysgit.0 -- 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
[PATCHv2 7/8] Doc clean: add See Also link
'git clean' is controlled by gitignore. Provide See Also link for it. Use of core.excludesfile is implied. Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 79fb984..9f42c0d 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -63,6 +63,10 @@ OPTIONS Remove only files ignored by git. This may be useful to rebuild everything from scratch, but keep manually created files. +SEE ALSO + +linkgit:gitignore[5] + GIT --- Part of the linkgit:git[1] suite -- 1.7.8.msysgit.0 -- 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
[PATCHv2 8/8] Doc branch: show -vv option and alternative
Indicate that the -v option can be given twice in the short options. Without it users pass over the option. Also indicate the alternate 'git remote show' method. Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 9c1d2f1..cc7f54c 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -130,12 +130,13 @@ This option is only applicable in non-verbose mode. Activate the list mode. `git branch pattern` would try to create a branch, use `git branch --list pattern` to list matching branches. --v:: +-v, -vv:: --verbose:: When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print - the name of the upstream branch, as well. + the name of the upstream branch, as well (see also `git remote + show remote`). -q:: --quiet:: -- 1.7.8.msysgit.0 -- 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
[PATCHv2 5/8] Doc: separate gitignore pattern sources
Use separate bulleted paragraphs for the three different gitignore pattern sources. Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index c1f692a..96639e0 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -41,18 +41,24 @@ precedence, the last matching pattern decides the outcome): variable 'core.excludesfile'. Which file to place a pattern in depends on how the pattern is meant to -be used. Patterns which should be version-controlled and distributed to -other repositories via clone (i.e., files that all developers will want -to ignore) should go into a `.gitignore` file. Patterns which are -specific to a particular repository but which do not need to be shared -with other related repositories (e.g., auxiliary files that live inside -the repository but are specific to one user's workflow) should go into -the `$GIT_DIR/info/exclude` file. Patterns which a user wants git to -ignore in all situations (e.g., backup or temporary files generated by -the user's editor of choice) generally go into a file specified by -`core.excludesfile` in the user's `~/.gitconfig`. Its default value is -$XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, -$HOME/.config/git/ignore is used instead. +be used. + + * Patterns which should be version-controlled and distributed to + other repositories via clone (i.e., files that all developers will want + to ignore) should go into a `.gitignore` file. + + * Patterns which are + specific to a particular repository but which do not need to be shared + with other related repositories (e.g., auxiliary files that live inside + the repository but are specific to one user's workflow) should go into + the `$GIT_DIR/info/exclude` file. + + * Patterns which a user wants git to + ignore in all situations (e.g., backup or temporary files generated by + the user's editor of choice) generally go into a file specified by + `core.excludesfile` in the user's `~/.gitconfig`. Its default value is + $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or + empty, $HOME/.config/git/ignore is used instead. The underlying git plumbing tools, such as 'git ls-files' and 'git read-tree', read -- 1.7.8.msysgit.0 -- 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
[PATCHv2 2/8] Doc: shallow clone deepens _to_ new depth
Clarify that 'depth=' specifies the new depth from the remote's branch tip. It does not add the depth to the existing shallow clone. (details from pack-protocol.txt). Clarify that tags are not fetched. (details from shallow.txt) Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 39d326a..b4d6476 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -10,7 +10,8 @@ --depth=depth:: Deepen the history of a 'shallow' repository created by `git clone` with `--depth=depth` option (see linkgit:git-clone[1]) - by the specified number of commits. + to the specified number of commits from the tip of each remote + branch history. Tags for the deepened commits are not fetched. ifndef::git-pull[] --dry-run:: -- 1.7.8.msysgit.0 -- 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 v3 02/14] t5500: add tests of fetch-pack --all --depth=N $URL $REF
From: Michael Haggerty mhag...@alum.mit.edu Sent: Monday, September 10, 2012 10:53 PM On 09/10/2012 10:46 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: Document some bugs in git fetch-pack: 1. If git fetch-pack is called with --all, --depth, and an explicit existing non-tag reference to fetch, then it falsely reports that the reference was not found, even though it was fetched correctly. 2. If git fetch-pack is called with --all, --depth, and an explicit existing tag reference to fetch, then it segfaults in filter_refs() because return_refs is used without having been initialized. This probably isn't the right place in the series but I've just see a question on SO http://stackoverflow.com/questions/12475210/git-shallow-clone-along-with-branch which gives a user case that may or may not be covered by the pack-fetch. The user was looking for 'git clone --depth 1 -b master' and comparing it to a plain 'git clone --depth 1' and to 'git clone -b master' with the follow up question That is, why when passing -b it seems like it's changing behaviour of --depth ? Perhaps something to test out. Philip -- 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: [PATCHv2 1/8] Doc: Bundle file usage
Philip Oakley philipoak...@iee.org writes: Git URLs can accept bundle files for fetch, pull and clone, include in that section. Include git clone in the bundle usage description. Correct the quoting of git-rev-list-args. Detail the git-rev-list-args '--all' option for cloning. Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 16a6b0a..be6a5f1 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -21,12 +21,12 @@ Some workflows require that one or more branches of development on one machine be replicated on another machine, but the two machines cannot be directly connected, and therefore the interactive git protocols (git, ssh, rsync, http) cannot be used. This command provides support for -'git fetch' and 'git pull' to operate by packaging objects and references -in an archive at the originating machine, then importing those into -another repository using 'git fetch' and 'git pull' -after moving the archive by some means (e.g., by sneakernet). As no -direct connection between the repositories exists, the user must specify a -basis for the bundle that is held by the destination repository: the +'git fetch', 'git pull' and 'git clone', to operate by packaging +objects and references in an archive at the originating machine, then +importing those into another repository using 'git fetch', 'git pull', +or 'git clone', after moving the archive by some means (e.g., by sneakernet). +As no direct connection between the repositories exists, the user must +specify a basis for the bundle that is held by the destination repository: the bundle assumes that all objects in the basis are already in the destination repository. @@ -35,7 +35,7 @@ OPTIONS create file:: Used to create a bundle named 'file'. This requires the - 'git-rev-list-args' arguments to define the bundle contents. + git-rev-list-args arguments to define the bundle contents. verify file:: Used to check that a bundle file is valid and will apply @@ -92,6 +92,8 @@ It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination. +To create a bundle for 'git clone', use `--all` for the git-rev-list-args. + Hmm, what does this mean? Specifically, it is not clear what for 'git clone' exactly means. It is not for use of 'git clone', because you should be able to create a bundle that has 'master' branch without 'maint', 'next', and 'pu' and clone from it, no? git checkout maint git bundle create /var/tmp/1.bndl HEAD refs/heads/maint cd /var/tmp git clone 1.bndl xprm I also think --all is a bad advice for another reason. Doesn't it shove refs from refs/remotes/* hierarchy in the resulting bundle? It is fine for archiving purposes, but it does not seem to be a good advice to create a bundle to clone from. EXAMPLE --- diff --git a/Documentation/urls.txt b/Documentation/urls.txt index 2890194..2d75cce 100644 --- a/Documentation/urls.txt +++ b/Documentation/urls.txt @@ -42,6 +42,9 @@ These two syntaxes are mostly equivalent, except the former implies --local option. endif::git-clone[] +'git clone', 'git fetch' and 'git pull', but not 'git push', will also +accept a suitable bundle file. See linkgit:git-bundle[1]. + When git doesn't know how to handle a certain transport protocol, it attempts to use the 'remote-transport' remote helper, if one exists. To explicitly request a remote helper, the following syntax -- 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] gitk: Synchronize highlighting in file view when scrolling diff
On Tue, Sep 18, 2012 at 07:57:54AM +0200, Stefan Haller wrote: Whenever the diff pane scrolls, highlight the corresponding file in the file list on the right. For a large commit with many files and long per-file diffs, this makes it easier to keep track of what you're looking at. I like this as far as it goes, but the one criticism I would have is that when you find a string (using the Search button), the filename that gets highlighted is often not the file in which the string was found (because the highlighting is based on the top line visible in the text window), which could be confusing. Can you think of a way to solve that too? Perhaps make the highlighting based on the currently highlighted instance of the search string, if there is one, otherwise based on the top line visible? Paul. -- 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] Allow fancy globs in git-svn init branches
Ammon Riley ammon.ri...@gmail.com wrote:
I confess that I'd completely forgot about the {} expansion in bash.
Perhaps a note in the CAVEATS section of the documentation would
be sufficient?
I think so, yes. Can you send a patch for that instead? 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
[PATCH] Documentation/git-blame.txt: --follow is a NO-OP
Make note that while the --follow option is accepted by git blame it does nothing. Signed-off-by: Drew Northup n1xim.em...@gmail.com --- Documentation/git-blame.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 7ee9236..7465bd8 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] [-L n,m] - [-S revs-file] [-M] [-C] [-C] [-C] [--since=date] [--abbrev=n] + [-S revs-file] [-M] [-C] [-C] [-C] [--since=date] [--abbrev=n] [--follow] [rev | --contents file | --reverse rev] [--] file DESCRIPTION @@ -78,6 +78,9 @@ include::blame-options.txt[] abbreviated object name, use n+1 digits. Note that 1 column is used for a caret to mark the boundary commit. +--follow:: +NO-OP accepted due to using the option parser also used by +'git log' THE PORCELAIN FORMAT -- 1.7.12.rc0.54.g9e2116a -- 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: [PATCHv2 2/8] Doc: shallow clone deepens _to_ new depth
Philip Oakley philipoak...@iee.org writes: Clarify that 'depth=' specifies the new depth from the remote's branch tip. It does not add the depth to the existing shallow clone. (details from pack-protocol.txt). Clarify that tags are not fetched. (details from shallow.txt) Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 39d326a..b4d6476 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -10,7 +10,8 @@ --depth=depth:: Deepen the history of a 'shallow' repository created by `git clone` with `--depth=depth` option (see linkgit:git-clone[1]) - by the specified number of commits. + to the specified number of commits from the tip of each remote + branch history. Tags for the deepened commits are not fetched. Looks good; 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: [PATCHv2 4/8] Doc: 'git' has a discussion section
Philip Oakley philipoak...@iee.org writes: Highlight there is a further discussion section later in git man page Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git.txt b/Documentation/git.txt index 34d8a1b..d932a3e 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -30,6 +30,7 @@ After you mastered the basic concepts, you can come back to this page to learn what commands git offers. You can learn more about individual git commands with git help command. linkgit:gitcli[7] manual page gives you an overview of the command line command syntax. +See also the Discussion and Further Documentation sections below. Formatted and hyperlinked version of the latest git documentation can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`. I am not sure if this is appropriate. The primary objective of this paragraph is to nudge people who try to dive into the body of this document without understanding the fundamentals (which tends to waste their time) without spending too many words. After they visit these pages, they are armed with sufficient prerequisite knowledge and are free to go directly to documentation for individual subcommands, and this page is one of such pages. I do not think Discussion and Further Documentation sections are such prerequisites they should read before coming back here and looking at the list of subcommands. -- 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: [PATCHv2 5/8] Doc: separate gitignore pattern sources
Philip Oakley philipoak...@iee.org writes: Use separate bulleted paragraphs for the three different gitignore pattern sources. Signed-off-by: Philip Oakley philipoak...@iee.org 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: [PATCHv2 6/8] Doc add: link gitignore
Philip Oakley philipoak...@iee.org writes: Use a gitignore link rather than the gitrepository- layout link. Signed-off-by: Philip Oakley philipoak...@iee.org 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: [PATCHv2 7/8] Doc clean: add See Also link
Philip Oakley philipoak...@iee.org writes: 'git clean' is controlled by gitignore. Provide See Also link for it. Use of core.excludesfile is implied. Signed-off-by: Philip Oakley philipoak...@iee.org 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: [PATCHv2 8/8] Doc branch: show -vv option and alternative
Philip Oakley philipoak...@iee.org writes: --v:: +-v, -vv:: --verbose:: When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print - the name of the upstream branch, as well. + the name of the upstream branch, as well (see also `git remote + show remote`). Can you try -v:: -vv:: --verbose:: The description... instead? Cf. http://thread.gmane.org/gmane.comp.version-control.git/205184/focus=205315 -- 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] Documentation/git-blame.txt: --follow is a NO-OP
Drew Northup n1xim.em...@gmail.com writes: Make note that while the --follow option is accepted by git blame it does nothing. Signed-off-by: Drew Northup n1xim.em...@gmail.com --- Documentation/git-blame.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 7ee9236..7465bd8 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] [-L n,m] - [-S revs-file] [-M] [-C] [-C] [-C] [--since=date] [--abbrev=n] + [-S revs-file] [-M] [-C] [-C] [-C] [--since=date] [--abbrev=n] [--follow] [rev | --contents file | --reverse rev] [--] file DESCRIPTION @@ -78,6 +78,9 @@ include::blame-options.txt[] abbreviated object name, use n+1 digits. Note that 1 column is used for a caret to mark the boundary commit. +--follow:: +NO-OP accepted due to using the option parser also used by +'git log' This is triply questionable. If it is a useless NO-OP, it shouldn't be advertised in the SYNOPSIS section to begin with. Your --follow is a no-op for blame is technically correct, but I think the only ones that can appreciate that technical correctness are those like you who know why we can get away by having a seemingly no-op --follow option without losing functionality. git blame follows the whole-file renames correctly [*1*], without any -M/-C options. There is no _need_ to use the keep one global filename to follow, and switch to a different filename when it disappears hack the --follow code uses. That is the reason why blame pays no attention to the --follow option. You know that, and that is why you think it is a sane thing to describe it in technically correct way. But I think most of the readers of the documentation are not aware of that true reason why it can be a No-op. Worse yet, they may have heard of the --follow option that the log command has from any of the numerous misguided web pages, and are led to believe that the --follow option is a true feature, not a checkbox hack. If readers come from that background, thinking --follow is the way to tell Git to follow renames, what message does your description send them? I would read it as git blame accepts --follow from the command line, but it is a no-op. There is no way to make it follow renames. That is a totally wrong message to send. You failed to teach the reader that there is no need to do anything special to tell the command to follow per-line origin across renames. So if anything, I would phrase it this way instead: --follow:: This option is accepted but silently ignored. git blame follows per-line origin across renames without any special options, and there is no reason to use this option. It does not matter to the reader why it is accepted by the parser at the mechanical level (your description of the parser being shared with the log family). What matters to the readers is that it is accepted as a courtesy (as opposed to being rejected as an error), but it is unnecessary to give it in the first place. If you followed the logic along, you would agree that it is a crime to list it in the SYNOPSIS section. [Footnote] *1* Unlike --follow checkbox hack, which follows renames correctly only in a strictly linear history, blame maintains the filename being tracked per history traversal path and will follow a history like this: AB \\ CD where you originally had your file as fileA, one side of the fork renamed it to fileB while the other side of the fork renamed it to fileC, and a merge coalesced it to fileD. git blame fileD will find the line-level origin across all these renames. Try this: git init printf %s\n a a a a a fileA git add fileA git commit -m A git branch side printf %s\n a b b a a fileB git add fileB rm fileA git commit -a -m B git checkout side printf %s\n a a c c a fileC git add fileC rm fileA git commit -a -m C git merge master git rm -f fileA fileB fileC printf %s\n a b d c a fileD git add fileD git commit -a -m D and then in the resulting history git blame fileD -- 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
Git 1.7.12 installer blocked by Gatekeeper - needs signing with an Apple developer ID
Hi, Installing latest stable git on Mac OS X Mountain Lion is blocked by Gatekeeper. Could you provide an installer for latest stable git that is signed with an Apple issued developer ID so gatekeeper will let it through? I upgraded to Mountain Lion and decided to update git as well, but only found out about the installer incompatibility after I'd run the uninstall script on my previous version. For a while I was gitless and witless until I discovered you can bypass gatekeeper by opening the package with Installer.app - was just a bit stressful. Cheers, Torsten Louland -- 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
