Test failures in t4034
I've been getting a couple of test failures and finally had the time to track
them down.
t4034-diff-words fails tests 22 diff driver 'bibtex' and 26 diff driver
'html'. Bisecting shows that the file started giving me errors in commit
8d96e72 t4034: bulk verify builtin word regex sanity, which appears to
introduce those tests. I don't see anything obviously wrong with the tests and
I'm not familiar with the diff-words code, so I'm not sure what's wrong.
I am running on OS X 10.8, with Xcode 4.4.1 (llvm-gcc 4.2.1).
Test results follow:
-- 8 --
expecting success:
cp $TEST_DIRECTORY/t4034/bibtex/pre \
$TEST_DIRECTORY/t4034/bibtex/post \
$TEST_DIRECTORY/t4034/bibtex/expect .
echo * diff=bibtex .gitattributes
word_diff --color-words
--- expect 2012-08-18 05:54:29.0 +
+++ output.decrypted2012-08-18 05:54:29.0 +
@@ -8,8 +8,8 @@
author={Aldous, REDD.RESETGREENDavidRESET},
journal={Information Theory, IEEE Transactions on},RESET
volume={RED33RESETGREENBogus.RESET},
- number={RED2RESETGREEN4RESET},
+ number={4},
pages={219--223},RESET
- year=GREEN1987,RESET
-GREEN note={This is in fact a rather funny read since ethernet works well
in practice. TheRESET {RED1987RESETGREEN\em pre} reference is the right
one, however.RESET}RED,RESET
+ year=RED{1987},RESETGREEN1987,RESET
+ note={This is in fact a rather funny read since ethernet works well in
practice. The {\em pre} reference is the right one, however.}
}RESET
not ok - 22 diff driver 'bibtex'
-- 8 --
expecting success:
cp $TEST_DIRECTORY/t4034/html/pre \
$TEST_DIRECTORY/t4034/html/post \
$TEST_DIRECTORY/t4034/html/expect .
echo * diff=html .gitattributes
word_diff --color-words
--- expect 2012-08-18 05:54:29.0 +
+++ output.decrypted2012-08-18 05:54:29.0 +
@@ -4,5 +4,5 @@
BOLD+++ b/postRESET
CYAN@@ -1,3 +1,3 @@RESET
tag GREENnewattr=newvalueRESETGREENaddedRESET content/tag
-tag
attr=REDvalueRESETGREENnewvalueRESETREDcontentRESETGREENchangedRESET/tag
-REDtagRESETGREENnewtagRESETcontent
REDentity;RESETGREENnewentity;RESETRED/tagRESETGREEN/newtagRESET
+tag attr=newvaluechanged/tag
+newtagcontent newentity;/newtag
not ok - 26 diff driver 'html'--
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] git-gui: remove .git/CHERRY_PICK_HEAD after committing
Adding __git_ps1() to one's bash prompt displays various repo status
info after each command. After committing a git cherry-pick -n using
git-gui, the prompt still contains the |CHERRY-PICKING flag.
Delete the file causing this flag when cleaning up.
Signed-off-by: Beat Bolli bbo...@ewanet.ch
---
git-gui/lib/commit.tcl |1 +
1 file changed, 1 insertion(+)
diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index 78c5eeb..864b687 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -409,6 +409,7 @@ A rescan will be automatically started now.
catch {file delete [gitdir MERGE_MSG]}
catch {file delete [gitdir SQUASH_MSG]}
catch {file delete [gitdir GITGUI_MSG]}
+ catch {file delete [gitdir CHERRY_PICK_HEAD]}
# -- Let rerere do its thing.
#
--
1.7.10.4
--
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] git-gui: Fix a loose/lose mistake
No po update needed, as this string is untranslated.
Signed-off-by: Beat Bolli bbo...@ewanet.ch
---
git-gui/lib/commit.tcl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index 0d81432..78c5eeb 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -268,7 +268,7 @@ proc commit_commitmsg {curHEAD msg_p} {
[is_config_true gui.warndetachedcommit]} {
set msg [mc You are about to commit on a detached head.\
This is a potentially dangerous thing to do because if you switch\
-to another branch you will loose your changes and it can be difficult\
+to another branch you will lose your changes and it can be difficult\
to retrieve them later from the reflog. You should probably cancel this\
commit and create a new branch to continue.\n\
\n\
--
1.7.10.4
--
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
Problems with git fetch confusing foo and foo.git repos
A while ago I reported a problem[1] where having: /somewhere/foo and /somewhere/foo.git as bare repositories and trying to clone them using alternates could cause git to confuse them. The conclusion was that I needed to do: git clone -s -n /somewhere/foo/ x to stop it looking at the .git version. Ok, fine. Ugly but I can live with it and we added the workaround[2]. I've now discovered we only half solved the problem. Whilst the alternates might get setup correctly, the branch names and revisions get fetched from the .git version still. It appears that even if you have a repository setup with an origin url of /somewhere/foo/, when you run git fetch origin -f refs/*:refs/*, it will look at foo.git if it exists. The problem is the trailing slash is stripped off by the code in git-fetch itself. It appears to have done this since it was converted from a .sh function. It means it appears impossible to fetch the branchnames/revisions from foo when foo.git exists. I work with build systems that build complete linux systems and we're running into failures caused by this. I really need pre-existing versions of git to work so I can't even patch git to work around the problem without significant cost. So far the only way I've figured out to avoid this is to create a symlink to /somewhere/foo/ and then set url to point at the symlink. This way I can prevent it from finding the other directory. I thought I'd mention this in the hopes git can be fixed to behave better in this situation and perhaps I can drop the hacks I'm going to have to add sometime in the future. If anyone has any ideas for better workarounds I'd love to hear about them... [1] Alternates corruption issue, 2012/1/31 [2] http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/fetch2/git.py?id=64662290d3e7deb0b6093b3959c3f3eddb873893 Cheers, Richard -- 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] test: some testcases failed if cwd is on a symlink
Junio C Hamano gitster at pobox.com writes: Jiang Xin worldhello.net at gmail.com writes: Run command 'git rev-parse --git-dir' under subdir will return realpath of '.git' directory. Some test scripts compare this realpath against $TRASH_DIRECTORY, they are not equal if current working directory is on a symlink. In this fix, get realpath of $TRASH_DIRECTORY, store it in $TRASH_REALPATH variable, and use it when necessary. I wonder if running test in a real directory (in other words, fix your cwd) may be a simpler, more robust and generally a better solution, e.g. something silly like... diff --git a/t/test-lib.sh b/t/test-lib.sh index acda33d..7f6fb0a 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -15,6 +15,8 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/ . +cd $(pwd -P) + # if --tee was passed, write the output not only to the terminal, but # additionally to the file test-results/$BASENAME.out, too. case $GIT_TEST_TEE_STARTED, $* in What is the status of this bug? Today I wasted a bunch of time trying to track down a build breakage that was ultimately caused by this problem. I was running the test suite on master with --root=/dev/shm (my usual setting), but this caused tests t4035 and t9903 to fail as described upthread. (It turns out that on my system, /dev/shm is a symlink to /run/shm.) For me, the failure is fixed by Jiang Xin's patch, but it is not fixed by Junio's. In the case of t4035 in failing test git diff --ignore-all-space, both files outside repo, right before git diff is called, PWD=/run/shm/trash directory.t4035-diff-quiet/test-outside/non/git GIT_CEILING_DIRECTORIES=/dev/shm/trash directory.t4035-diff-quiet/test-outside I can work around the problem by using --root=/run/shm. But it would be good to get this problem fixed one way or the other to spare other people the same pain. Michael -- 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: Problems with git fetch confusing foo and foo.git repos
On Sat, 2012-08-18 at 15:25 +0100, Richard Purdie wrote: A while ago I reported a problem[1] where having: /somewhere/foo and /somewhere/foo.git as bare repositories and trying to clone them using alternates could cause git to confuse them. The conclusion was that I needed to do: git clone -s -n /somewhere/foo/ x to stop it looking at the .git version. Ok, fine. Ugly but I can live with it and we added the workaround[2]. I've now discovered we only half solved the problem. Whilst the alternates might get setup correctly, the branch names and revisions get fetched from the .git version still. It appears that even if you have a repository setup with an origin url of /somewhere/foo/, when you run git fetch origin -f refs/*:refs/*, it will look at foo.git if it exists. The problem is the trailing slash is stripped off by the code in git-fetch itself. It appears to have done this since it was converted from a .sh function. It means it appears impossible to fetch the branchnames/revisions from foo when foo.git exists. I work with build systems that build complete linux systems and we're running into failures caused by this. I really need pre-existing versions of git to work so I can't even patch git to work around the problem without significant cost. So far the only way I've figured out to avoid this is to create a symlink to /somewhere/foo/ and then set url to point at the symlink. This way I can prevent it from finding the other directory. I thought I'd mention this in the hopes git can be fixed to behave better in this situation and perhaps I can drop the hacks I'm going to have to add sometime in the future. I'd add that I think the commit made for the original problem[1] has fixed this scenario since it now will prefer foo over foo.git also in the fetch case even if the / is removed from the url. My test machines don't have that version yet though and I'm left with a problem where git is older than 1.7.9.2. [1]http://git.kernel.org/?p=git/git.git;a=commit;h=b3256eb8b35937192e85725d0c2bcb422295790c Cheers, Richard -- 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 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
From: Michael Haggerty mhag...@alum.mit.edu On 08/17/2012 01:29 AM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: I like the general direction. Perhaps a long distant future direction could be to also use the same trick in the ref namespace so that we can have 'next' branch itself, and 'next/foo', 'next/bar' forks that are based on the 'next' branch at the same time (it obviously is a totally unrelated topic)? I notice that I was responsible for making this topic veer in the wrong direction by bringing up a new feature having 'next' and 'next/bar' at the same time which nobody asked. Perhaps we can drop that for now to simplify the scope of the topic, to bring the log graveyard back on track? Given that a flag day would anyway be required to add a d/f-tolerant system, I could live with a separate graveyard namespace as originally proposed by Jeff. However, I still think that as long as we are making a jump, we could try to land closer to the ultimate destination. So here are some patches that apply on top of Jeff's to show what I mean. (Please also note that I made some technical comments about Jeff's patches in an earlier email.) The first two patches fix a breakage that I see when I apply Jeff's patches to master. The third changes the implementation of refname_to_graveyard_reflog() and graveyard_reflog_to_refname() and touches up some test cases. It changes the naming convention for dead references to $GIT_DIR/logs/refs~d/heads~d/foo~d/bar~d/baz~f I.e., the dead reflogs are stored closer to the living. It is not obvious whether the refs part of the name should be munged to refs~d as I have done, or left unmunged. The argument in favor of munging is that the algorithm is more uniform. On the other hand, extending the same scheme to loose references would produce filenames like $GIT_DIR/refs~d/heads~d/foo~d/bar~d/baz~f or maybe they should be nested inside of the refs directory like $GIT_DIR/refs/refs~d/heads~d/foo~d/bar~d/baz~f (which would also give a better place to store top-level reference names). I structured the patches to apply on top of Jeff's for presentation purposes, but if they are desired it would of course make more sense to squash his and mine together in the obvious way. I am a little bit worried that there are other test cases that use git prune in the belief that it will remove all commits that were referred to by deleted references. The test suite runs cleanly for me with these patches, but before they are integrated we should audit the places where the test suite calls to git prune to make sure that they are still testing what they think. Michael Haggerty (3): t9300: format test in modern style prior to modifying it Delete reflogs for dead references to allow pruning Change naming convention for the reflog graveyard refs.c | 31 --- t/t7701-repack-unpack-unreachable.sh | 4 ++-- t/t9300-fast-import.sh | 13 +++-- 3 files changed, 33 insertions(+), 15 deletions(-) -- 1.7.11.3 -- 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 0/2] Fix two minor problems in the docs for git-config
From: Michael Haggerty mhag...@alum.mit.edu This is just something I stumbled across. Michael Haggerty (2): git-config.txt: properly escape quotation marks in example git-config.txt: fix example Documentation/git-config.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.7.11.3 -- 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] git-config.txt: properly escape quotation marks in example
From: Michael Haggerty mhag...@alum.mit.edu In the example line as written, gitproxy=proxy-command for kernel.org the quotation marks are eaten by the config-file parser. From the history, it looks like this example wanted to have quotation marks in the actual configured value. So quote them as required nowadays. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- The bigger question is whether this example is improved by including quotation marks, or whether they are just a distraction from the main point. I abstain. Documentation/git-config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 2d6ef32..46775fe 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -267,7 +267,7 @@ Given a .git/config like this: ; Proxy settings [core] - gitproxy=proxy-command for kernel.org + gitproxy=\proxy-command\ for kernel.org gitproxy=default-proxy ; for all the rest you can set the filemode to true with -- 1.7.11.3 -- 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 0/2] svn-fetch|push - an alternate approach
This is sort of an RFC/ANN. There has been a whole bunch of traffic of late on git-svn, vcs-svn, the remote helper, etc. I would like to present an alternate solution that I've been playing with for a couple of weeks. I work in a team that uses a mixture of git-svn and svn proper. Whilst it works remarkably well and I largely don't have to deal with svn on a day to day basis, git-svn is still quite limiting compared to git proper. Namely any merges created by myself or another either can't be pushed into svn or information is lost when done so. Switching wholesale to git is problematic due to the disruption this causes. There are also numerous non-core users who want a really simple update and occasionally checkin a single file/folder UI. Tortoise SVN fits their needs perfectly and even with a proper git-svn bridge in place I have no plan on dropping svn support. Possible Solutions -- In general there are a couple of ways of attacking this: 1. Have git-svn push extraneous git context into subversion and pull it back down on the other side. 2. Create a dummy svn server ala git-cvsserver 3. Use both a git server and svn server and have the git server push to the svn server. 4. Same as #3 but have the svn server push to the git server. #1 is frought with issues due to how exacting git is wrt to recreating commits. The recreated commits would have to have the same hash to be able to use git's distributed nature. #2 is possible but a lot of work. SVN clients expect a substantial amount of metadata. This introduces considerable complexity of where to store the metadata and what metadata to generate on the fly. Not all can be generated on the fly as SVN presents a general purpose key value store to clients, which many use and expect to work. #3 and #4 have divergence issues in that you have two servers through which commits can be pushed. If conflicting commits are pushed into both servers at the same time, there has to be some method for conflict resolution. Requiring that an admin go in and fix things manually is unpalatable. The easiest way around this is to delegate one of the two servers as the master and require that commits pushed to the other update the master before suceeding. In this mode #3 has the SVN server as master, and #4 has the git server. There is an existing commercial system that came up a couple of weeks ago that transfers commits asynchronously. I am unsure of how this avoids conflicts if at all. I've been working on a solution using approach #3. The code follows (hopefully) and is currently running an internal beta with 3 or 4 users using it and works very well. In my setup, the SVN server is the master node. The git server has a pre-receive hook which pushes commits onto the SVN server. The hook checks for any SVN errors (SVN hooks, file conflicts, etc), and that no SVN commits are intermingled with the pushed git commits (either before or interspersed). If this fails at all, the pre-receive hook fails, which fails the git push. The git user then pulls or rebases and tries to push again. Kerberos Auth (Off-Topic) - I am also using a kerberos auth http frontend (http://github.com/jmckaskill/krb-httpd). This checks authentication against active directory and uses the remote user for the --user argument of git svn-push. Most clients are windows users. In this case I have built a replacement version of libcurl-4.dll which enables kerberos negotiate (as an aside the msysgit build should enable this by default). I've then added the following to users' global git config: credential.http://domain.name.username=dummy credential.http://domain.name.helper=!echo password=dummy With this in place, git uses the user's domain login and never asks for a password. There is also some equivalent tweaks to get domain logins working in browsers for cgit. How it Works The attached patch adds two commands to git: svn-fetch and svn-push. The names are temporary. My plan is to refactor these into git-remote-svn so that git push/pull/fetch work as expected. svn-fetch fetches svn commits for all branches and creates git commits, branches, tags, etc as it goes along. svn-push takes the remote ref name, from and to sha1 (or a list of these on stdin for use as a pre-receive hook) and pushes the changes to svn, creating/deleting branches/tags as neccessary and failing if there are any intermingled svn commits in the pushed to folders. Metadata is tracked by creating an extra git commit for each svn commit in each branch/tag that is stored in refs/svn/heads|tags as well as refs/svn/latest for the latest fetched commit. These commits look like the following: tree svn tree parent underlying git commit parent previous svn commit for this svn folder author svn author + time committer svn author + time revision svn revision path svn path relative to svn.url Using commits to track the SVN metadata has proven really really handy. The code gets to
[RFC 2/2] add tests for git svn-fetch|push
From: James R. McKaskill ja...@foobar.co.nz
Signed-off-by: James R. McKaskill ja...@foobar.co.nz
---
t/lib-git-svn-fetch.sh | 131 +++
t/t9050-git-svn-fetch.sh| 85 +++
t/t9051-git-svn-fetch-branch.sh | 245
t/t9052-git-svn-push.sh | 140
t/t9053-git-svn-push-branch.sh | 478
5 files changed, 1079 insertions(+)
create mode 100644 t/lib-git-svn-fetch.sh
create mode 100755 t/t9050-git-svn-fetch.sh
create mode 100755 t/t9051-git-svn-fetch-branch.sh
create mode 100755 t/t9052-git-svn-push.sh
create mode 100755 t/t9053-git-svn-push-branch.sh
diff --git a/t/lib-git-svn-fetch.sh b/t/lib-git-svn-fetch.sh
new file mode 100644
index 000..16326a9
--- /dev/null
+++ b/t/lib-git-svn-fetch.sh
@@ -0,0 +1,131 @@
+#!/bin/sh
+
+. ./test-lib.sh
+
+if test -z $SVNSERVE_PORT
+then
+ skip_all='skipping svn-(fetch|push) test. (set $SVNSERVE_PORT to
enable)'
+ test_done
+fi
+
+svn --version | grep version 1.7 /dev/null
+if [ ! $? -eq 0 ]
+then
+ skip_all='skipping svn-(fetch|push) test. (need svn 1.7 or newer)'
+ test_done
+fi
+
+svnrepo=$PWD/svnrepo
+svnconf=$PWD/svnconf
+svnurl=svn://localhost:$SVNSERVE_PORT
+null_sha1=
+
+# We need this, because we should pass empty configuration directory to
+# the 'svn commit' to avoid automated property changes and other stuff
+# that could be set from user's configuration files in ~/.subversion.
+svn_cmd () {
+ [ -d $svnconf ] || mkdir $svnconf
+ cat $svnconf/servers !
+[global]
+store-plaintext-passwords = yes
+!
+ orig_svncmd=$1; shift
+ if [ -z $orig_svncmd ]; then
+ svn
+ return
+ fi
+ echo svn $orig_svncmd $@
+ svn $orig_svncmd --username committer --password pass --no-auth-cache
--non-interactive --config-dir $svnconf $@
+}
+
+function test_file() {
+ file_contents=`cat $1`
+ test_contents=$2
+ test $file_contents == $test_contents
+}
+
+function svn_date() {
+ revision=$1
+ directory=$2
+ svn_cmd log -r $revision --xml -l 1 $directory | grep date |
sed -re 's#^date([^\.Z]*)\.[0-9]+Z/date#\1Z#g'
+}
+
+function test_git_subject() {
+ commit=$1
+ subject=$2
+ commit_subject=`git log -1 --pretty=format:%s $commit`
+ echo test_git_subject $commit_subject $subject
+ test $commit_subject == $subject
+}
+
+function test_git_author() {
+ commit=$1
+ author=$2
+ commit_author=`git log -1 --pretty=format:'%an %ae' $commit`
+ echo test_git_author $commit_author $author
+ test $commit_author == $author
+}
+
+function test_git_date() {
+ commit=$1
+ date=$2
+ commit_date=`git log -1 --pretty=format:%ai $commit | sed -re 's#^([^
]*) ([^ ]*) \+$#\1T\2Z#g'`
+ echo test_git_date $commit_date $date
+ test $commit_date == $date
+}
+
+function test_svn_subject() {
+ subject=$1
+ revision=`test -n $2 echo -r $2`
+ commit_subject=`svn log -l 1 --xml $revision | grep 'msg' | sed -re
's#msg(.*)#\1#g' | sed -re 's#(.*)/msg#\1#g'`
+ echo test_svn_subject $commit_subject $subject
+ test $commit_subject == $subject
+}
+
+function test_svn_author() {
+ author=$1
+ revision=`test -n $2 echo -r $2`
+ commit_author=`svn log -l 1 --xml $revision | grep 'author' | sed
-re 's#author(.*)/author#\1#g'`
+ echo test_svn_author $commit_author $author
+ test $commit_author == $author
+}
+
+show_ref() {
+ (git show-ref --head $1 | head -n 1 | cut -d ' ' -f 1) || echo $1
+}
+
+show_tag() {
+ show_ref refs/tags/$1 | git cat-file --batch | grep object | cut -f 2
-d ' '
+}
+
+merge_base() {
+ git merge-base `show_ref $1` `show_ref $2`
+}
+
+test_expect_success 'start svnserve' '
+ killall svnserve /dev/null
+ killall lt-svnserve /dev/null
+ rm -rf $svnrepo
+ mkdir -p $svnrepo
+ svnadmin create $svnrepo
+ cat $svnrepo/conf/svnserve.conf !
+[general]
+auth-access = write
+password-db = passwd
+!
+ cat $svnrepo/conf/passwd !
+[users]
+committer = pass
+!
+ cat .git/svn-authors !
+committer:pass = C O Mitter commit...@example.com
+!
+ svnserve --daemon \
+ --listen-port $SVNSERVE_PORT \
+ --root $svnrepo \
+ --listen-host localhost
+ git config svn.user committer
+ git config svn.url $svnurl
+ git config svn.remote svn
+ svn_cmd co $svnurl svnco
+'
diff --git a/t/t9050-git-svn-fetch.sh b/t/t9050-git-svn-fetch.sh
new file mode 100755
index 000..7ac3643
--- /dev/null
+++ b/t/t9050-git-svn-fetch.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+test_description='git svn-fetch non trunk'
+. ./lib-git-svn-fetch.sh
+
+test_expect_success 'fetch empty' '
+ git svn-fetch -v
+ test_must_fail test -x .git/refs/svn/latest
+
[PATCH 2/2] git-config.txt: fix example
From: Michael Haggerty mhag...@alum.mit.edu The --add option is required to add a new value to a multivalued configuration entry. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/git-config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 46775fe..584ef51 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -342,7 +342,7 @@ To actually match only values with an exclamation mark, you have to To add a new proxy, without altering any of the existing ones, use -% git config core.gitproxy 'proxy-command for example.com' +% git config --add core.gitproxy 'proxy-command for example.com' An example to use customized color from the configuration in your -- 1.7.11.3 -- 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 v4 01/16] GSOC remote-svn
On Friday 17 August 2012 21:16:59 Junio C Hamano wrote: Comments from mentors and people interested in remote helpers? I did minimum line wrapping, typofix and small compilation fixes and queued these on 'pu'; I think I saw one commit whose message I didn't quite get what it was trying to say, and another that was missing S-o-b (I left them untouched). Should I provide a better version? I found the commit that I forgot to sign- off, but I'm not sure which message you mean. The result merged to 'pu' seems to fail 9020, by the way. That's because contrib/svn-fe isn't built automatically if you call make in the toplevel dir. It dies with fatal: Unable to find remote helper for 'svn', because the helper is not built. We currently need to run make in contrib/svn-fe seperately. That's a bit awkward. Just checked how it works for svn-fe. It has a seperate test program (test- svn-fe.c) which is in the toplevel dir and built here, while for svn-fe itself, it's the same as for remote-svn. Don't know what to do about that. 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 1/5] GSOC: prepare svndump for branch detection
On Sat, Aug 18, 2012 at 6:40 AM, Florian Achleitner florian.achleitner.2.6...@gmail.com wrote: Hi! This patch series should prepare vcs-svn/svndump.* for branch detection. When starting with this feature I found that the existing functions are not yet appropriate for that. These rewrites the node handling part of svndump.c, it is very invasive. The logic in handle_node is not simple, I hope that I understood every case the existing code tries to adress. At least it doesn't break an existing testcase. The series applies on top of: [PATCH/RFC v4 16/16] Add a test script for remote-svn. I could also rebase it onto master if you think it makes sense. Florian [RFC 1/5] vcs-svn: Add sha1 calculaton to fast_export and This change makes me uncomfortable. We are doubling up on hashing with fast-import. This introduces git-specific logic into vcs-svn. [RFC 2/5] svndump: move struct definitions to .h. [RFC 3/5] vcs-svn/svndump: restructure node_ctx, rev_ctx handling [RFC 4/5] vcs-svn/svndump: rewrite handle_node(), [RFC 5/5] vcs-svn: remove repo_tree I haven't read the rest of the series yet but I expect it is less controversial than the first patch. -- David Michael Barr -- 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
Comparing the working tree with a commit should be independent of the index
I've already posted it to SO [1], but got no satisfactory answer. The command git diff mycommit compares the working tree against mycommit, so it should not depend on the index. But it does as this example shows: git init echo A A.txt; git add .; git commit -m A; git branch A echo B B.txt; git add .; git commit -m B; git branch B git reset --hard A echo BB B.txt git diff B File B.txt exists both in the working tree and in the commit B, so a proper diff should be shown. Instead I get deleted file. Adding the file to the index changes it. This is IMHO a bug. [1]: http://stackoverflow.com/questions/8452820/how-to-compare-the-working-tree-with-a-commit -- 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 2/2] git-svn.perl: keep processing all commits in parents_exclude
On 08/11/2012 10:14 AM, Steven Walter wrote:
This fixes a bug where git finds the incorrect merge parent. Consider a
repository with trunk, branch1 of trunk, and branch2 of branch1.
Without this change, git interprets a merge of branch2 into trunk as a
merge of branch1 into trunk.
Signed-off-by: Steven Walter stevenrwal...@gmail.com
---
git-svn.perl |1 -
t/t9164-git-svn-fetch-merge-branch-of-branch2.sh | 53 ++
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100755 t/t9164-git-svn-fetch-merge-branch-of-branch2.sh
diff --git a/git-svn.perl b/git-svn.perl
index abcec11..c4678c1 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3623,7 +3623,6 @@ sub parents_exclude {
if ( $commit eq $excluded ) {
push @excluded, $commit;
$found++;
- last;
}
I could believe that, too. I like this change: one line of code, 53
lines of test and a paragraph of explanation :-).
Cheers,
Sam.
--
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/2] git-gui: remove .git/CHERRY_PICK_HEAD after committing
Beat Bolli bbo...@ewanet.ch writes:
Adding __git_ps1() to one's bash prompt displays various repo status
info after each command. After committing a git cherry-pick -n using
git-gui, the prompt still contains the |CHERRY-PICKING flag.
Delete the file causing this flag when cleaning up.
Signed-off-by: Beat Bolli bbo...@ewanet.ch
---
git-gui/lib/commit.tcl |1 +
1 file changed, 1 insertion(+)
diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index 78c5eeb..864b687 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -409,6 +409,7 @@ A rescan will be automatically started now.
catch {file delete [gitdir MERGE_MSG]}
catch {file delete [gitdir SQUASH_MSG]}
catch {file delete [gitdir GITGUI_MSG]}
+ catch {file delete [gitdir CHERRY_PICK_HEAD]}
# -- Let rerere do its thing.
#
It makes me wonder if the above sequence of file delete should all
be removed and use git commit instead of git commit-tree in the
implementation of this Tcl procedure instead.
Pat?
--
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: Problems with git fetch confusing foo and foo.git repos
Richard Purdie richard.pur...@linuxfoundation.org writes: I'd add that I think the commit made for the original problem[1] has fixed this scenario since it now will prefer foo over foo.git also in the fetch case even if the / is removed from the url. OK. As understand it, these check various possibilities e.g. $name, $name.git $name/.git were never meant to be a way to encourage users to have multiple repositories next to each other under confusing names in the first place. It was merely to allow users to have one of them (some may prefer $name/ that is with working tree, so we allow $name/.git to be discovered, while some may want to have a bare repository at $name.git that is bare, so we also allow it to be discovered). The recent tweak was to favor the case where the name asked explicitly by the user is matched first, and it does not fundamentally change the intent of the basic design in any way. Thanks for confirming that the tweak works well for you. My test machines don't have that version yet though and I'm left with a problem where git is older than 1.7.9.2. So what do you want to see happen next? -- 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] test: some testcases failed if cwd is on a symlink
Michael Haggerty mhag...@alum.mit.edu writes: I can work around the problem by using --root=/run/shm. I do not necessarily think it is a work around. A low-impact approach may be to update the part that parses --root option to do root=$(...) root=$( cd $root /bin/pwd ) or something. -- 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 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
mhag...@alum.mit.edu writes: Given that a flag day would anyway be required to add a d/f-tolerant system, I could live with a separate graveyard namespace as originally proposed by Jeff. However, I still think that as long as we are making a jump, we could try to land closer to the ultimate destination. Do we _know_ already what the ultimate destination looks like? If the answer is yes, then I agree, but otherwise, I doubt it is a good idea to introduce unnecessary complexity to the system that may have to be ripped out and redone. I didn't get the impression that we know the ultimate destination from the previous discussion, especially if we discount the tangent around having next and next/foo at the same time which was on nobody's wish, but I may be misremembering things. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-config.txt: properly escape quotation marks in example
mhag...@alum.mit.edu writes: From: Michael Haggerty mhag...@alum.mit.edu In the example line as written, gitproxy=proxy-command for kernel.org the quotation marks are eaten by the config-file parser. From the history, it looks like this example wanted to have quotation marks in the actual configured value. So quote them as required nowadays. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- The bigger question is whether this example is improved by including quotation marks, or whether they are just a distraction from the main point. I abstain. Thanks for spelling that bigger question out. Given that the example is showing distinction between X vs X for Y, I would say quotation is a distraction. If you spelled it as [core] gitproxy = sh -c 'proxy-command' for kernel.org does the do the right thing? Or do we require the above to be spelled as [core] gitproxy = \sh -c 'proxy-command'\ for kernel.org to work correctly? I suspect that the former would work, and in that case, the quote around proxy-command in the documentation is indeed a distraction, and removing it will not hurt the readers. Documentation/git-config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 2d6ef32..46775fe 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -267,7 +267,7 @@ Given a .git/config like this: ; Proxy settings [core] - gitproxy=proxy-command for kernel.org + gitproxy=\proxy-command\ for kernel.org gitproxy=default-proxy ; for all the rest you can set the filemode to true with -- 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 2/2] git-svn.perl: keep processing all commits in parents_exclude
On Sat, Aug 18, 2012 at 3:51 PM, Sam Vilain s...@vilain.net wrote:
On 08/11/2012 10:14 AM, Steven Walter wrote:
This fixes a bug where git finds the incorrect merge parent. Consider a
repository with trunk, branch1 of trunk, and branch2 of branch1.
Without this change, git interprets a merge of branch2 into trunk as a
merge of branch1 into trunk.
Signed-off-by: Steven Walter stevenrwal...@gmail.com
---
git-svn.perl |1 -
t/t9164-git-svn-fetch-merge-branch-of-branch2.sh | 53
++
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100755 t/t9164-git-svn-fetch-merge-branch-of-branch2.sh
diff --git a/git-svn.perl b/git-svn.perl
index abcec11..c4678c1 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3623,7 +3623,6 @@ sub parents_exclude {
if ( $commit eq $excluded ) {
push @excluded, $commit;
$found++;
- last;
}
I could believe that, too. I like this change: one line of code, 53 lines
of test and a paragraph of explanation :-).
How about a Signed-Off-By?
--
-Steven Walter stevenrwal...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git-config.txt: fix example
mhag...@alum.mit.edu writes: To add a new proxy, without altering any of the existing ones, use -% git config core.gitproxy 'proxy-command for example.com' +% git config --add core.gitproxy 'proxy-command for example.com' Sensible; 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 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
On 18 Aug 2012, at 22:39, Junio C Hamano wrote: Do we _know_ already what the ultimate destination looks like? If the answer is yes, then I agree, but otherwise, I doubt it is a good idea to introduce unnecessary complexity to the system that may have to be ripped out and redone. I didn't get the impression that we know the ultimate destination from the previous discussion, especially if we discount the tangent around having next and next/foo at the same time which was on nobody's wish, but I may be misremembering things. Excuse me if i miss something again, but i might be willing to discuss the ultimate destination. Could you possibly state in simple terms what the problem with determining the ultimate destination is? I hope my opinion might be useful because i do not know anything about the actual implementation of Git, but for a while i thought i was understanding it's intended mathematical model, until i ran into unexpected for me default behavior of not pruning when fetching. To just give a quick idea of my ideas, i thought that 'fetching' in Git was an inevitable evil that stands apart from other operations and is necessary only because the computer communication on Earth is not sufficiently developed to keep all Git repositories constantly in sync, and because one might prefer to work with a somewhat dated snapshot of a remote than with the constantly changing current version. I thought snapshot could be a good alternative name for fetch. -Alexey.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Comparing the working tree with a commit should be independent of the index
Maaartin graj...@seznam.cz writes: Instead I get deleted file. Adding the file to the index changes it. This is IMHO a bug. There are 7 interesting combinations for the state of a path. It either exists in or missing from the commit you are gving to git diff, it either exists in or missing from the index, and it either exists in or missing from the working tree. Missing from all is totally uninteresting, so it leaves 7 combinations. Among the 7 interesting cases, a path missing from the index have 3 interesting cases. In $commit On filesystem Yes Yes Yes No No Yes and your case is the first one. What do you want to see happen for other two cases? I would guess deleted and added, as anything else would not be internally consistent. git diff compares contents in the index and in the working tree. git diff HEAD compares contents in HEAD and in the working tree. The definition of paths in the working tree in these sentences is not all files on the filesystem, or all files on the filesystem, filtered with the ignore mechanism. It is all files on the filesystem that are in the index, and that is why you see a path that is in the commit and on the filesystem but not in the index as deleted. This definition worked well for us, because that will give a clean semantics to git diff HEAD: what change would I be recording if I said git commit -a at this point? And that is why git add on the path changes the output as you observed in your message. It is an intended behaviour. If you did not tell Git that you want a path that does not exist in the index with git add, the path will not participate in the next commit created by git commit -a, and git diff HEAD should not talk about it. If the path is only in the index, not showing it as deletion as you saw is actually dangerous. git commit -a will record the deletion of the path in the commit, even though you checked with the git diff HEAD before you commit to make sure you didn't change it. Of course, our definition of the set of working tree files does not have to be the only one. Instead, it could be something that changes the semantics of git diff HEAD output to: what change would I be recording if I said git add -A git commit at this point? The updated semantics will be far less useful than the current one, but it still is an understandable one. You could introduce a new option (mode of operation to git diff) to make it include untracked but not ignored paths to the set of paths on the working tree side of the comparison, but I do not think it is useful. In short, I do not think there is a bug in the current behaviour. -- 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 feature request: --amend older commit
Jared Hance jaredha...@gmail.com writes: [administrivia: do not deflect a direct response to you away by using mail-followup-to header, thanks] On Fri, Aug 17, 2012 at 11:47:49AM -0400, George Spelvin wrote: Something like git commit --fixup HEAD~3, where git commit --fixup HEAD would be equivalent to git commit --amend. Yes, as an end-user facing command set, git commit --amend HEAD~3 would not be a bad addition. Such a simple task shouldn't require an interactive command. In some cases, yes. But the devil is in the details, and whoever wants to work on must be prepared to see cases where the remainder of the commits after rewriting an older commit will not replay cleanly on top of it. At that point, it won't be a simple task anymore. At least, it must make it clear what the user should do when commit --amend HEAD~3 (and subsequent rebuilding of HEAD~2, HEAD~1 and HEAD on top of the amended result) needs a help from the user to resolve conflicts. It may be just the matter of mentioning from here on, follow the procedure you would use when you are running 'rebase -i', if the chosen mechanism to implement the sequencing behind the commit --amend HEAD~3 UI is rebase -i. -- 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: Problems with git fetch confusing foo and foo.git repos
On Sat, 2012-08-18 at 13:33 -0700, Junio C Hamano wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: I'd add that I think the commit made for the original problem[1] has fixed this scenario since it now will prefer foo over foo.git also in the fetch case even if the / is removed from the url. OK. As understand it, these check various possibilities e.g. $name, $name.git $name/.git were never meant to be a way to encourage users to have multiple repositories next to each other under confusing names in the first place. It was merely to allow users to have one of them (some may prefer $name/ that is with working tree, so we allow $name/.git to be discovered, while some may want to have a bare repository at $name.git that is bare, so we also allow it to be discovered). The recent tweak was to favor the case where the name asked explicitly by the user is matched first, and it does not fundamentally change the intent of the basic design in any way. Thanks for confirming that the tweak works well for you. I'm responsible for generic source fetching infrastructure and unfortunately I haven't been able to prevent users ending up with repositories next to each other under confusing names much as I might like to. Users tend to manage to find all the corner cases in something like this :) My test machines don't have that version yet though and I'm left with a problem where git is older than 1.7.9.2. So what do you want to see happen next? I was a bit confused earlier whether there was any remaining issue. With the recent versions I've now confirmed there isn't and the bug is fixed (which I really appreciate). Sorry for the noise. My remaining question was whether there was any better way to work around this in older versions of git. I've ended up implementing the symlink solution I mentioned which whilst ugly, will hopefully put this issue to rest for me. (http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a86bd422641ce083ba0cdb4efe2a4c307eb36f7e in case anyone cares) Cheers, Richard -- 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 2/2] git-svn.perl: keep processing all commits in parents_exclude
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/18/2012 01:43 PM, Steven Walter wrote: How about a Signed-Off-By? Signed-Off-By: Sam Vilain s...@vilain.net Sam -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCgAGBQJQMCcnAAoJEBdtaL3wGtIoJ1UIAIJ6Xz5OEMmMk1tq546eggHg I+sJIFjqg+mo53VqT0/bKhqg8sLx8F/Gda15nwOUMcslKJdA+sCc+QhAtgSWJ1WK Idw59jtZHbabfopBHNgneSqVBhXSKpNw3e3EvlRVkK1wobO0+c0X6YkBG0eBCZl2 6RYXIAb6jX04k1hSrnxcPn+REkoyl31aEuFBPNz0wRWHjju+G6bPY/x7D/gO1YOc /uRQXveQngJOLwawDR+dGS+0aWPseX/sbZqsVFo0hVQYqoHt+s4uVuriBfHSRKd+ R1eUoY0ikW4UvEwZX74Zf3SeoVLLFnkCW8B5XsGb10IojbvY3uyYevATXI79j1Y= =Lb7H -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-config.txt: properly escape quotation marks in example
Junio C Hamano gits...@pobox.com writes: The bigger question is whether this example is improved by including quotation marks, or whether they are just a distraction from the main point. I abstain. Thanks for spelling that bigger question out. Given that the example is showing distinction between X vs X for Y, I would say quotation is a distraction. If you spelled it as [core] gitproxy = sh -c 'proxy-command' for kernel.org does the do the right thing? Or do we require the above to be spelled as [core] gitproxy = \sh -c 'proxy-command'\ for kernel.org to work correctly? I think the answer is no, there is no way to specify anything other than a path to the command for gitproxy. So I think we should do this instead: -- 8 -- Subject: [PATCH] git-config doc: unconfuse an example One fictitious command proxy-command is enclosed inside a double quote pair, while another fictitious command default-proxy is not in the example, but the quoting does not change anything in the pair of examples. Remove the quotes to avoid unnecessary confusion. Noticed by Michael Haggerty. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 5382753..b24faa8 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -251,7 +251,7 @@ Given a .git/config like this: ; Proxy settings [core] - gitproxy=proxy-command for kernel.org + gitproxy=proxy-command for kernel.org gitproxy=default-proxy ; for all the rest you can set the filemode to true with -- 1.7.12.rc3.96.g0dba3eb -- 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 2/2] git-svn.perl: keep processing all commits in parents_exclude
Sam Vilain s...@vilain.net writes: On 08/18/2012 01:43 PM, Steven Walter wrote: How about a Signed-Off-By? Signed-Off-By: Sam Vilain s...@vilain.net I think you meant reviewed-by or acked-by? -- 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 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
Alexey Muranov alexey.mura...@gmail.com writes: On 18 Aug 2012, at 22:39, Junio C Hamano wrote: Do we _know_ already what the ultimate destination looks like? If the answer is yes, then I agree, but otherwise, I doubt it is a good idea to introduce unnecessary complexity to the system that may have to be ripped out and redone. I didn't get the impression that we know the ultimate destination from the previous discussion, especially if we discount the tangent around having next and next/foo at the same time which was on nobody's wish, but I may be misremembering things. Excuse me if i miss something again, but i might be willing to discuss the ultimate destination. Could you possibly state in simple terms what the problem with determining the ultimate destination is? Decide if it makes sense to break backward compatibility of loose ref representation merely to support having a branch next and another branch next/foo in the same repository, and if it does, what the new loose ref representation looks like. I hope my opinion might be useful because i do not know anything about the actual implementation of Git,... That sounds like contradiction. To just give a quick idea of my ideas, i thought that 'fetching' in Git was an inevitable evil that stands apart from other operations and is necessary only because the computer communication on Earth is not sufficiently developed to keep all Git repositories constantly in sync,... It is a feature, not a symptom of an insufficiently developed technology, that I do not have to know what random tweaks and experiments are done in repositories of 47 thousands people who clone from me, and I can sync with any one of them only when I know there is something worth looking at when I say git fetch. -- 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
