Aw: [PATCH 0/2] GIT, Git, git
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the Git system. So change every occurrence of 'GIT and 'git' to 'Git' whenever Git as a system is referred to (but don't do this change in the release notes because they constitute a history orthogonal to the history versioned by Git). [PATCH 1/2] Change old system name 'GIT' to 'Git' [PATCH 2/2] Change 'git' to 'Git' whenever the whole system is referred to My second patch somehow got lost in the mailing system (I suspect due to its size of 300kB). I will wait for some more comments and then do a reroll thereby splitting the second patch in smaller parts ... --- Thomas -- 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: Version 1.8.1 does not compile on Cygwin 1.7.14
Ramsay Jones wrote: --- a/git-compat-util.h +++ b/git-compat-util.h @@ -85,12 +85,6 @@ #define _NETBSD_SOURCE 1 #define _SGI_SOURCE 1 -#ifdef WIN32 /* Both MinGW and MSVC */ -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ -#include winsock2.h -#include windows.h -#endif So, do I understand correctly that the above conditional should be something like #if defined(WIN32) !defined(__CYGWIN__) to allow dropping the CYGWIN_V15_WIN32API setting? defined(WIN32) is used throughout git to mean win32 and not cygwin, so if I understand correctly we would either need to do #if defined(WIN32) defined(__CYGWIN__) # undef WIN32 #endif or define a new GIT_WIN32 (name is just a placeholder) macro to use consistently in its stead. Thanks for investigating. Jonathan -- 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: Version 1.8.1 does not compile on Cygwin 1.7.14
On 20.01.13 11:10, Jonathan Nieder wrote: Ramsay Jones wrote: --- a/git-compat-util.h +++ b/git-compat-util.h @@ -85,12 +85,6 @@ #define _NETBSD_SOURCE 1 #define _SGI_SOURCE 1 -#ifdef WIN32 /* Both MinGW and MSVC */ -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ -#include winsock2.h -#include windows.h -#endif So, do I understand correctly that the above conditional should be something like #if defined(WIN32) !defined(__CYGWIN__) to allow dropping the CYGWIN_V15_WIN32API setting? defined(WIN32) is used throughout git to mean win32 and not cygwin, so if I understand correctly we would either need to do #if defined(WIN32) defined(__CYGWIN__) # undef WIN32 #endif or define a new GIT_WIN32 (name is just a placeholder) macro to use consistently in its stead. Thanks for investigating. Jonathan I wonder, if if we can go one step further: Replace #ifdef WIN32 /* Both MinGW and MSVC */ #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include winsock2.h #include windows.h #endif with #if defined(_MSC_VER) #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include winsock2.h #include windows.h #endif Any thougths from msysGit ? /Torsten -- 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] INSTALL: git-p4 doesn't support Python 3
On Sat, Jan 19, 2013 at 05:31:35PM -0800, David Aguilar wrote: On Sat, Jan 19, 2013 at 4:01 AM, John Keeping j...@keeping.me.uk wrote: Since Pyhton 2.8 will never exist [1] Tiny typo: Python misspelled as Pyhton Thanks. v2 on its way. John -- 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: Version 1.8.1 does not compile on Cygwin 1.7.14
Torsten Bögershausen wrote: I wonder, if if we can go one step further: Replace #ifdef WIN32 /* Both MinGW and MSVC */ [...] with #if defined(_MSC_VER) I thought Git for Windows was built using mingw, which doesn't define _MSC_VER? Puzzled, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] INSTALL: git-p4 doesn't support Python 3
git-p4 supports Python 2.6 and later versions of Python 2. Since Python 2.8 will never exist [1], it is most concise to just list the supported versions. [1] http://www.python.org/dev/peps/pep-0404/ Signed-off-by: John Keeping j...@keeping.me.uk Acked-by: Pete Wyckoff p...@padd.com --- Since v1: - Fixed a typo in the commit message. INSTALL | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/INSTALL b/INSTALL index 28f34bd..c456d1c 100644 --- a/INSTALL +++ b/INSTALL @@ -131,7 +131,7 @@ Issues of note: use English. Under autoconf the configure script will do this automatically if it can't find libintl on the system. - - Python version 2.6 or later is needed to use the git-p4 + - Python version 2.6 or 2.7 is needed to use the git-p4 interface to Perforce. - Some platform specific issues are dealt with Makefile rules, -- 1.8.1.353.gc992d5a.dirty -- 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: Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
Thomas Ackermann th.ac...@arcor.de writes: The whole point of my patch is to use 'Git' consistently when we are talking about the system and not the individual command. I like the idea. git should obviously remain lower-case when talking about the command, but deserves a capital when talking about the software independantly of whether it's called from command-line. Just like I type firefox in a shell to launch a program called Firefox (or even Mozilla Firefox). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mergetools: Add tortoisegitmerge helper
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which have
a space in it. Fixing this required changes in git and also in
TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57.
The new tortoisegitmerge helper was added so that people can still use
TortoiseMerge from TortoiseSVN (and older TortoiseGit versions).
Signed-off-by: Sven Strickroth em...@cs-ware.de
Reported-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/diff-config.txt | 4 ++--
Documentation/git-mergetool.txt| 4 ++--
Documentation/merge-config.txt | 6 +++---
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 2 +-
mergetools/tortoisegitmerge| 17 +
6 files changed, 26 insertions(+), 9 deletions(-)
create mode 100644 mergetools/tortoisegitmerge
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 4314ad0..13cbe5b 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -151,7 +151,7 @@ diff.driver.cachetextconv::
diff.tool::
The diff tool to be used by linkgit:git-difftool[1]. This
option overrides `merge.tool`, and has the same valid built-in
- values as `merge.tool` minus tortoisemerge and plus
- kompare. Any other value is treated as a custom diff tool,
+ values as `merge.tool` minus tortoisemerge/tortoisegitmerge and
+ plus kompare. Any other value is treated as a custom diff tool,
and there must be a corresponding `difftool.tool.cmd`
option.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6b563c5..a80cccd 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -28,8 +28,8 @@ OPTIONS
--tool=tool::
Use the merge resolution program specified by tool.
Valid values include emerge, gvimdiff, kdiff3,
- meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
- for the list of valid tool settings.
+ meld, vimdiff, tortoisegitmerge, and tortoisemerge. Run
+ `git mergetool --tool-help` for the list of valid tool settings.
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 9bb4956..a047646 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -55,9 +55,9 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: araxis,
bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3, meld,
- opendiff, p4merge, tkdiff, tortoisemerge, vimdiff
- and xxdiff. Any other value is treated is custom merge tool
- and there must be a corresponding mergetool.tool.cmd option.
+ opendiff, p4merge, tkdiff, tortoisegitmerge, tortoisemerge,
+ vimdiff and xxdiff. Any other value is treated is custom merge
+ tool and there must be a corresponding mergetool.tool.cmd option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 90f5f05..5332a33 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1345,7 +1345,7 @@ _git_mergetool ()
{
case $cur in
--tool=*)
- __gitcomp $__git_mergetools_common tortoisemerge
${cur##--tool=}
+ __gitcomp $__git_mergetools_common tortoisegitmerge
tortoisemerge ${cur##--tool=}
return
;;
--*)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index f013a03..47183ef 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -150,7 +150,7 @@ run_merge_cmd () {
list_merge_tool_candidates () {
if merge_mode
then
- tools=tortoisemerge
+ tools=tortoisegitmerge tortoisemerge
else
tools=kompare
fi
diff --git a/mergetools/tortoisegitmerge b/mergetools/tortoisegitmerge
new file mode 100644
index 000..5b802a7
--- /dev/null
+++ b/mergetools/tortoisegitmerge
@@ -0,0 +1,17 @@
+can_diff () {
+ return 1
+}
+
+merge_cmd () {
+ if $base_present
+ then
+ touch $BACKUP
+ $merge_tool_path \
+ -base $BASE -mine $LOCAL \
+ -theirs $REMOTE -merged $MERGED
+ check_unchanged
+ else
+ echo TortoiseGitMerge cannot be used without a base 12
+ return 1
+ fi
+}
--
Best regards,
Sven
Re: [RFC] git rm -u
Jonathan Nieder jrnie...@gmail.com writes: Eric James Michael Ritz wrote: When I came to my senses and realized that does not work I began to wonder if `git rm -u` should exist. If any deleted, tracked files are not part of the index to commit then `git rm -u` would add that change to the index. I like it. If you have time to write such a patch, I'll be happy to read it. I can leave with git add -u, but a git rm -u that would only look at deletions, and not stage existing files changes would make sense. One thing to be careful about is what to do when the command is called from a subdirectory. In general, Git commands use this convention: * git foo = tree-wide command * git foo . = restrict to current directory git add -u is one of the only exceptions (with git grep). I consider this as a bug, and think this should be changed. This has been discussed several times here, but no one took the time to actually do the change (changing is easy, but having a correct migration plan wrt backward compatibility is not). Implementing git rm -u as a tree-wide command would create a discrepancy with git add -u. Implementing it as a current directory command would make the migration harder if we eventually try to change git add -u. Perhaps git rm -u should be forbidden from a subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. -- 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
Re: Aw: [PATCH 0/2] GIT, Git, git
Thomas Ackermann th.ac...@arcor.de writes:
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line).
Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
Git system. So change every occurrence of 'GIT and 'git' to 'Git'
whenever Git as a system is referred to (but don't do this change
in the release notes because they constitute a history orthogonal
to the history versioned by Git).
[PATCH 1/2] Change old system name 'GIT' to 'Git'
[PATCH 2/2] Change 'git' to 'Git' whenever the whole system is referred to
My second patch somehow got lost in the mailing system (I suspect
due to its size of 300kB). I will wait for some more comments
and then do a reroll thereby splitting the second patch in smaller
parts ...
For such big patches it also helps if you push them somewhere public,
and post the URL and branch name, so that interested parties can still
have a look.
But yes, vger.kernel.org silently discards all mail above 100KB, see
http://vger.kernel.org/majordomo-info.html
in the last section.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] fixup remaining cvsimport tests
Hi Chris, On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote: These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) Did you post the fix for the revision map publicly anywhere? I'm hoping to publish some fixes to command handling but would like to have the tests passing first - and if you've already done the work... Sorry if you have and I've missed it, John -- 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 v3 0/8] Python 3 support for git_remote_helpers
This series does enough so that everything except git-p4 runs under Python 3. As discussed with Pete, it may not make sense to change git-p4 to support Python 3 until Perforce's Python output mode is changed. So does it make sense to merge this now and say use Python 2 if you want git-p4? Changes since v2: - Change reference URL in commit message of patch 4 (git_remote_helpers: Use 2to3 if building with Python 3) to point at Python documentation instead of the Python wiki. - Add a comment in patch 7 (git-remote-testpy: don't do unbuffered text I/O), as suggested by Sverre. John Keeping (8): git_remote_helpers: Allow building with Python 3 git_remote_helpers: fix input when running under Python 3 git_remote_helpers: Force rebuild if python version changes git_remote_helpers: Use 2to3 if building with Python 3 svn-fe: allow svnrdump_sim.py to run with Python 3 git-remote-testpy: hash bytes explicitly git-remote-testpy: don't do unbuffered text I/O git-remote-testpy: call print as a function contrib/svn-fe/svnrdump_sim.py | 4 ++-- git-remote-testpy.py | 46 +- git_remote_helpers/.gitignore | 1 + git_remote_helpers/Makefile| 10 +++-- git_remote_helpers/git/importer.py | 9 +--- git_remote_helpers/setup.py| 10 + 6 files changed, 52 insertions(+), 28 deletions(-) -- 1.8.1.353.gc992d5a.dirty -- 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 v3 1/8] git_remote_helpers: Allow building with Python 3
Change inline Python to call print as a function not a statement.
This is harmless because Python 2 will see the parentheses as redundant
grouping but they are necessary to run this code with Python 3.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile
index 74b05dc..f65f064 100644
--- a/git_remote_helpers/Makefile
+++ b/git_remote_helpers/Makefile
@@ -23,7 +23,7 @@ endif
PYLIBDIR=$(shell $(PYTHON_PATH) -c \
import sys; \
-print 'lib/python%i.%i/site-packages' % sys.version_info[:2])
+print('lib/python%i.%i/site-packages' % sys.version_info[:2]))
all: $(pysetupfile)
$(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build
--
1.8.1.353.gc992d5a.dirty
--
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 v3 2/8] git_remote_helpers: fix input when running under Python 3
Although 2to3 will fix most issues in Python 2 code to make it run under
Python 3, it does not handle the new strict separation between byte
strings and unicode strings. There is one instance in
git_remote_helpers where we are caught by this, which is when reading
refs from git for-each-ref.
Fix this by operating on the returned string as a byte string rather
than a unicode string. As this method is currently only used internally
by the class this does not affect code anywhere else.
Note that we cannot use byte strings in the source as the 'b' prefix is
not supported before Python 2.7 so in order to maintain compatibility
with the maximum range of Python versions we use an explicit call to
encode().
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/git/importer.py | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/git_remote_helpers/git/importer.py
b/git_remote_helpers/git/importer.py
index e28cc8f..d3f90e1 100644
--- a/git_remote_helpers/git/importer.py
+++ b/git_remote_helpers/git/importer.py
@@ -18,13 +18,16 @@ class GitImporter(object):
def get_refs(self, gitdir):
Returns a dictionary with refs.
+
+Note that the keys in the returned dictionary are byte strings as
+read from git.
args = [git, --git-dir= + gitdir, for-each-ref, refs/heads]
-lines = check_output(args).strip().split('\n')
+lines = check_output(args).strip().split('\n'.encode('ascii'))
refs = {}
for line in lines:
-value, name = line.split(' ')
-name = name.strip('commit\t')
+value, name = line.split(' '.encode('ascii'))
+name = name.strip('commit\t'.encode('ascii'))
refs[name] = value
return refs
--
1.8.1.353.gc992d5a.dirty
--
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 v3 3/8] git_remote_helpers: Force rebuild if python version changes
When different version of python are used to build via distutils, the
behaviour can change. Detect changes in version and pass --force in
this case.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/git_remote_helpers/.gitignore b/git_remote_helpers/.gitignore
index 2247d5f..06c664f 100644
--- a/git_remote_helpers/.gitignore
+++ b/git_remote_helpers/.gitignore
@@ -1,2 +1,3 @@
+/GIT-PYTHON_VERSION
/build
/dist
diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile
index f65f064..91f458f 100644
--- a/git_remote_helpers/Makefile
+++ b/git_remote_helpers/Makefile
@@ -25,8 +25,14 @@ PYLIBDIR=$(shell $(PYTHON_PATH) -c \
import sys; \
print('lib/python%i.%i/site-packages' % sys.version_info[:2]))
+py_version=$(shell $(PYTHON_PATH) -c \
+ 'import sys; print(%i.%i % sys.version_info[:2])')
+
all: $(pysetupfile)
- $(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build
+ $(QUIET)test $$(cat GIT-PYTHON_VERSION 2/dev/null) = $(py_version)
|| \
+ flags=--force; \
+ $(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build $$flags
+ $(QUIET)echo $(py_version) GIT-PYTHON_VERSION
install: $(pysetupfile)
$(PYTHON_PATH) $(pysetupfile) install --prefix $(DESTDIR_SQ)$(prefix)
--
1.8.1.353.gc992d5a.dirty
--
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 v3 4/8] git_remote_helpers: Use 2to3 if building with Python 3
Using the approach detailed in the Python documentation[1], run 2to3 on
the code as part of the build if building with Python 3.
The code itself requires no changes to convert cleanly.
[1] http://docs.python.org/3.3/howto/pyporting.html#during-installation
Signed-off-by: John Keeping j...@keeping.me.uk
Acked-by: Sverre Rabbelier srabbel...@gmail.com
---
On Fri, 18 Jan 2013 23:52:16 -0800, Sverre Rabbelier wrote:
Assuming you tried this out on both 2.x and 3.x:
Acked-by: Sverre Rabbelier srabbel...@gmail.com
I ran the test suite with Python 2.7.3 and 3.2.3.
git_remote_helpers/setup.py | 10 ++
1 file changed, 10 insertions(+)
diff --git a/git_remote_helpers/setup.py b/git_remote_helpers/setup.py
index 4d434b6..6de41de 100644
--- a/git_remote_helpers/setup.py
+++ b/git_remote_helpers/setup.py
@@ -4,6 +4,15 @@
from distutils.core import setup
+# If building under Python3 we need to run 2to3 on the code, do this by
+# trying to import distutils' 2to3 builder, which is only available in
+# Python3.
+try:
+from distutils.command.build_py import build_py_2to3 as build_py
+except ImportError:
+# 2.x
+from distutils.command.build_py import build_py
+
setup(
name = 'git_remote_helpers',
version = '0.1.0',
@@ -14,4 +23,5 @@ setup(
url = 'http://www.git-scm.com/',
package_dir = {'git_remote_helpers': ''},
packages = ['git_remote_helpers', 'git_remote_helpers.git'],
+cmdclass = {'build_py': build_py},
)
--
1.8.1.353.gc992d5a.dirty
--
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 v3 5/8] svn-fe: allow svnrdump_sim.py to run with Python 3
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 17cf6f9..4e78a1c 100755
--- a/contrib/svn-fe/svnrdump_sim.py
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -14,7 +14,7 @@ if sys.hexversion 0x0204:
def getrevlimit():
var = 'SVNRMAX'
-if os.environ.has_key(var):
+if var in os.environ:
return os.environ[var]
return None
@@ -44,7 +44,7 @@ def writedump(url, lower, upper):
if __name__ == __main__:
if not (len(sys.argv) in (3, 4, 5)):
-print usage: %s dump URL -rLOWER:UPPER
+print(usage: %s dump URL -rLOWER:UPPER)
sys.exit(1)
if not sys.argv[1] == 'dump': raise NotImplementedError('only dump
is suppported.')
url = sys.argv[2]
--
1.8.1.353.gc992d5a.dirty
--
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 v3 6/8] git-remote-testpy: hash bytes explicitly
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method to hex
bytes so that we don't need to worry about failures to encode that might
occur if we chose a textual encoding.
This changes the directory used by git-remote-testpy for its git mirror
of the remote repository, but this tool should not have any serious
users as it is used primarily to test the Python remote helper
framework.
The use of encode() moves the required Python version forward to 2.0.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-remote-testpy.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index d94a66a..197b7be 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
from git_remote_helpers.git.importer import GitImporter
from git_remote_helpers.git.non_local import NonLocalGit
-if sys.hexversion 0x01050200:
-# os.makedirs() is the limiter
-sys.stderr.write(git-remote-testgit: requires Python 1.5.2 or later.\n)
+if sys.hexversion 0x0200:
+# string.encode() is the limiter
+sys.stderr.write(git-remote-testgit: requires Python 2.0 or later.\n)
sys.exit(1)
def get_repo(alias, url):
@@ -45,7 +45,7 @@ def get_repo(alias, url):
repo.get_head()
hasher = _digest()
-hasher.update(repo.path)
+hasher.update(repo.path.encode('hex'))
repo.hash = hasher.hexdigest()
repo.get_base_path = lambda base: os.path.join(
--
1.8.1.353.gc992d5a.dirty
--
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 v3 7/8] git-remote-testpy: don't do unbuffered text I/O
Python 3 forbids unbuffered I/O in text mode. Change the reading of
stdin in git-remote-testpy so that we read the lines as bytes and then
decode them a line at a time.
This allows us to keep the I/O unbuffered in order to avoid
reintroducing the bug fixed by commit 7fb8e16 (git-remote-testgit: fix
race when spawning fast-import).
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-remote-testpy.py | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 197b7be..5dbf1cc 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -154,7 +154,7 @@ def do_import(repo, args):
refs = [ref]
while True:
-line = sys.stdin.readline()
+line = sys.stdin.readline().decode()
if line == '\n':
break
if not line.startswith('import '):
@@ -225,7 +225,7 @@ def read_one_line(repo):
line = sys.stdin.readline()
-cmdline = line
+cmdline = line.decode()
if not cmdline:
warn(Unexpected EOF)
@@ -277,7 +277,11 @@ def main(args):
more = True
-sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
+# Use binary mode since Python 3 does not permit unbuffered I/O in text
+# mode. Unbuffered I/O is required to avoid data that should be going
+# to git-fast-import after an export command getting caught in our
+# stdin buffer instead.
+sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
while (more):
more = read_one_line(repo)
--
1.8.1.353.gc992d5a.dirty
--
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 v3 8/8] git-remote-testpy: call print as a function
This is harmless in Python 2, which sees the parentheses as redundant
grouping, but is required for Python 3. Since this is the only change
required to make this script just run under Python 3 without needing
2to3 it seems worthwhile.
The case of an empty print must be handled specially because in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.
Signed-off-by: John Keeping j...@keeping.me.uk
Acked-by: Sverre Rabbelier srabbel...@gmail.com
---
git-remote-testpy.py | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 5dbf1cc..c7a04ec 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -87,9 +87,9 @@ def do_capabilities(repo, args):
Prints the supported capabilities.
-print import
-print export
-print refspec refs/heads/*:%s* % repo.prefix
+print(import)
+print(export)
+print(refspec refs/heads/*:%s* % repo.prefix)
dirname = repo.get_base_path(repo.gitdir)
@@ -98,11 +98,11 @@ def do_capabilities(repo, args):
path = os.path.join(dirname, 'git.marks')
-print *export-marks %s % path
+print(*export-marks %s % path)
if os.path.exists(path):
-print *import-marks %s % path
+print(*import-marks %s % path)
-print # end capabilities
+print('') # end capabilities
def do_list(repo, args):
@@ -115,16 +115,16 @@ def do_list(repo, args):
for ref in repo.revs:
debug(? refs/heads/%s, ref)
-print ? refs/heads/%s % ref
+print(? refs/heads/%s % ref)
if repo.head:
debug(@refs/heads/%s HEAD % repo.head)
-print @refs/heads/%s HEAD % repo.head
+print(@refs/heads/%s HEAD % repo.head)
else:
debug(@refs/heads/master HEAD)
-print @refs/heads/master HEAD
+print(@refs/heads/master HEAD)
-print # end list
+print('') # end list
def update_local_repo(repo):
@@ -164,7 +164,7 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
-print feature done
+print(feature done)
if os.environ.get(GIT_REMOTE_TESTGIT_FAILURE):
die('Told to fail')
@@ -172,7 +172,7 @@ def do_import(repo, args):
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
-print done
+print(done)
def do_export(repo, args):
@@ -192,8 +192,8 @@ def do_export(repo, args):
repo.non_local.push(repo.gitdir)
for ref in changed:
-print ok %s % ref
-print
+print(ok %s % ref)
+print('')
COMMANDS = {
--
1.8.1.353.gc992d5a.dirty
--
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 interactive rebase 'consume' command
Hi there, I find the fixup command during an interactive rebase useful. Sometimes when cleaning up a branch, I end up in a situation like this: pick 07bc3c9 Good commit. pick 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. So, I have to reorder the commits, and change 1313a5e to 'f'. An alternative would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message. The problem with that is it ends up with the wrong author time information. So, I usually reorder and then fixup, but that can also be problematic if I get a conflict during the re-order (which is quite likely). I would prefer to be able to mark a commit as 'should be consumed', so that: pick 07bc3c9 Good commit. consume 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. will result in pick 07bc3c9 Good commit. pick 62a3c2f Another commit. directly. Any thoughts on that? Thanks, Steve. -- 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 interactive rebase 'consume' command
On Sun, Jan 20, 2013 at 03:05:18PM +0100, Stephen Kelly wrote: I find the fixup command during an interactive rebase useful. Sometimes when cleaning up a branch, I end up in a situation like this: pick 07bc3c9 Good commit. pick 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. So, I have to reorder the commits, and change 1313a5e to 'f'. An alternative would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message. The problem with that is it ends up with the wrong author time information. So, I usually reorder and then fixup, but that can also be problematic if I get a conflict during the re-order (which is quite likely). I would prefer to be able to mark a commit as 'should be consumed', so that: pick 07bc3c9 Good commit. consume 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. will result in pick 07bc3c9 Good commit. pick 62a3c2f Another commit. directly. Any thoughts on that? Are you aware of the --autosqush option to git-rebase (and the rebase.autosquash config setting)? I find that using that combined with the --fixup option to git-commit makes this workflow a lot more intuitive. (Which is not to say that I wouldn't find an option like 'consume' useful but I find myself reordering the list very rarely since I started using git commit --fixup=) John -- 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 interactive rebase 'consume' command
John Keeping wrote: Any thoughts on that? Are you aware of the --autosqush option to git-rebase (and the rebase.autosquash config setting)? I find that using that combined with the --fixup option to git-commit makes this workflow a lot more intuitive. Yes, I'm aware of it, but I think it's not related to the proposal I made. Mostly my proposal is about avoiding unnecessary conflict resolution. Thanks, Steve. -- 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 0/3] fixup remaining cvsimport tests
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote: Hi Chris, On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote: These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) Did you post the fix for the revision map publicly anywhere? It's in Eric's repo and included in version 3.8: https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6 Chris -- 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 0/3] fixup remaining cvsimport tests
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote: On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote: On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote: These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) Did you post the fix for the revision map publicly anywhere? It's in Eric's repo and included in version 3.8: https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6 Thanks. For some reason I thought the fix would be to git-cvsimport-3.py. Obviously I should have read more carefully. Sorry for the noise. John -- 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] am: invoke perl's strftime in C locale
Dmitry V. Levin l...@altlinux.org writes: Personally I prefer 2nd edition that is simpler and does the right thing (not that LC_ALL=C is necessary and sufficient, you neither need to add things like LANG=C nor can relax it to LC_TIME=C). I guess everybody involved is in agreement, then. Just FYI, LC_ALL=C LANG=C comes from the inertia dating back when not everybody understood LC_*; I do not personally know of a system that will be helped by the extra LANG=C these days, but I know it will not hurt anybody, so... -- 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 0/2] Hiding some refs in ls-remote
Jeff King p...@peff.net writes: [uploadPack] hiderefs = refs/changes Would you want to do the same thing on receive-pack? It could benefit from the same reduction in network cost (although it tends to be invoked less frequently than upload-pack). Do *I* want to do? Not when there already is a patch exists; I'd rather take existing and tested patch ;-) As I said, I view this primarily as solving the cluttering issue. The use of hiderefs to hide these refs that point at objects I do not consider belong to my repository from the pushers equally makes sense as such, I think. -- 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 0/2] Hiding some refs in ls-remote
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: Should the client side learn how to list hidden refs too? I'm thinking of an extreme case where upload-pack advertises nothing (or maybe just refs/heads/master) and it's up to the client to ask for the ref selection it's interested in. upload-pack may need more updates to do that, I think. What you are talking about is a different goal. Look at this as a mechanism for the repository owner to control the clutter in what is shown to the intended audience of what s/he publishes in the repository. Network bandwidth reduction of advertisement is a side effect of clutter reduction, and not necessarily the primary goal. As a separate and follow-up topic, I can see a future where we also have .delayref (in addition to .hideref) configuration, that causes the upload-pack to: * omit refs that are marked as delayed; * advertise allow-expand-ref=value where the value is the pattern used to specify which refs are omitted via this mechanism (e.g. refs/* in your extreme example, or perhaps refs/tags/ if you only advertise branches in order to limit the bandwidth); and then a fetch-pack that is interested in fetching refs/foo/bar, after seeing that it matches one of the allow-expand-ref patterns, to ask expand-ref refs/foo/bar, expect the upload-pack to respond with refs/foo/bar value of that ref (or refs/foo/bar does not exist), before going into the usual want exchange (ls-remote would of course do the same, and pattern-less ls-remote may even ask to expand everything by saying expand-ref refs/* (where the capability said allow-expand-ref=refs/* in your extreme example) to grab everything discoverable). That is _primarily_ for trading network bandwidth with initial latency; as far as the end-result is concerned, delayed ones to be expanded on demand are just as discoverable as the ones advertised initially. I think we'd want to have both in the end. It just happens I just posted the beginning of clutter-reduction one, as I think developing both in parallel would be messy and hideref is probably less involved than the delayref. -- 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] Change old system name 'GIT' to 'Git'
David Aguilar dav...@gmail.com writes: On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann th.ac...@arcor.de wrote: @@ -55,7 +55,7 @@ History Viewers - *gitweb* (shipped with git-core) - GITweb provides full-fledged web interface for GIT repositories. + GITweb provides full-fledged web interface for Git repositories. What about GITweb? diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index d377a35..0df13ff 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -73,7 +73,7 @@ in ref value. Log lines are formatted as: Where oldsha1 is the 40 character hexadecimal value previously stored in ref, newsha1 is the 40 character hexadecimal value of newvalue and committer is the committer's name, email address -and date in the standard GIT committer ident format. +and date in the standard Git committer ident format. IMO some of these look nicer when everything is lowercase. e.g. standard git committer ident format. I do not think we ever intended to change the *name* of the software. In the early days, we wrote GIT in places where, if we were doing a fancier typography, we would have used drop-caps for the latter two (i.e. it is Git spelled in a font whose lower case alphabets have the same shape as upper case ones but are smaller). So there were only git vs Git. If I were to decide today to change the spellings, with an explicit purpose of making things more consistent across documentation, it may make sense to use even a simpler rule that is less error-prone for people who write new sentences that has to have the word. How about treating it just like any other ordinary word? That is, we say git (without double-quotes, of course), unless it comes at the beginning of a sentence? -- 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] unpack-trees: do not abort when overwriting an existing file with the same content
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+ /*
+ * If it has the same content that we are going to write down,
write down???
+ * there's no point in complaining. We still overwrite it in the
+ * end though. Permission is not checked so it may be lost.
+ */
That is a regression, isn't it? Is it too cumbersome to avoid
losing the permission bits by stopping in that case?
+ if (ce
+ S_ISREG(st-st_mode) S_ISREG(ce-ce_mode)
+ st-st_size 1024 * 1024 /* should be configurable */
+ sha1_object_info(ce-sha1, ce_size) == OBJ_BLOB
+ ce_size == st-st_size) {
+ void *buffer = NULL;
+ unsigned long size;
+ enum object_type type;
+ struct strbuf sb = STRBUF_INIT;
+ int matched =
+ strbuf_read_file(sb, ce-name, ce_size) == ce_size
+ (buffer = read_sha1_file(ce-sha1, type, size)) !=
NULL
+ type == OBJ_BLOB
+ size == ce_size
+ !memcmp(buffer, sb.buf, size);
+ free(buffer);
+ strbuf_release(sb);
+ if (matched)
+ return 0;
+ }
+
return o-gently ? -1 :
add_rejected_path(o, error_type, name);
}
--
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] git rm -u
Matthieu Moy matthieu@grenoble-inp.fr writes: git add -u is one of the only exceptions (with git grep). I consider this as a bug, and think this should be changed. This has been discussed several times here, but no one took the time to actually do the change Did we ever agree that it is a good change to begin with? Pointers? -- 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] git rm -u
Matthieu Moy matthieu@grenoble-inp.fr writes: Implementing git rm -u as a tree-wide command would create a discrepancy with git add -u. Implementing it as a current directory command would make the migration harder if we eventually try to change git add -u. Perhaps git rm -u should be forbidden from a subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. Yeah, that sounds sensible. Start with a 'git rm -u' is forbidden without arguments, give advise to use either . or :/. And stop there. The first step of git add -u migration plan would be to warn when no argument is given and update all the existing index entries, and give the same advise to use either . or :/. Keep this for three cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year. The second step would be to forbid git add -u, and keep the advise. That will make it in-line with git rm -u. -- 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] Change old system name 'GIT' to 'Git'
Junio C Hamano wrote: David Aguilar dav...@gmail.com writes: On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann th.ac...@arcor.de wrote: @@ -55,7 +55,7 @@ History Viewers - *gitweb* (shipped with git-core) - GITweb provides full-fledged web interface for GIT repositories. + GITweb provides full-fledged web interface for Git repositories. What about GITweb? diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index d377a35..0df13ff 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -73,7 +73,7 @@ in ref value. Log lines are formatted as: Where oldsha1 is the 40 character hexadecimal value previously stored in ref, newsha1 is the 40 character hexadecimal value of newvalue and committer is the committer's name, email address -and date in the standard GIT committer ident format. +and date in the standard Git committer ident format. IMO some of these look nicer when everything is lowercase. e.g. standard git committer ident format. I do not think we ever intended to change the *name* of the software. In the early days, we wrote GIT in places where, if we were doing a fancier typography, we would have used drop-caps for the latter two (i.e. it is Git spelled in a font whose lower case alphabets have the same shape as upper case ones but are smaller). So there were only git vs Git. If I were to decide today to change the spellings, with an explicit purpose of making things more consistent across documentation, it may make sense to use even a simpler rule that is less error-prone for people who write new sentences that has to have the word. How about treating it just like any other ordinary word? That is, we say git (without double-quotes, of course), unless it comes at the beginning of a sentence? Because then it could get confused with git, the command? That would be lower case even at the beginning of a sentence, wouldn't it? 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: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
John Keeping j...@keeping.me.uk writes: git-p4 supports Python 2.6 and later versions of Python 2. Since Python 2.8 will never exist [1], it is most concise to just list the supported versions. Thanks; Eric's patch recently updated git-p4.py to require 2.4 I think. Shouldn't it also be updated? [1] http://www.python.org/dev/peps/pep-0404/ Signed-off-by: John Keeping j...@keeping.me.uk Acked-by: Pete Wyckoff p...@padd.com --- Since v1: - Fixed a typo in the commit message. INSTALL | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/INSTALL b/INSTALL index 28f34bd..c456d1c 100644 --- a/INSTALL +++ b/INSTALL @@ -131,7 +131,7 @@ Issues of note: use English. Under autoconf the configure script will do this automatically if it can't find libintl on the system. - - Python version 2.6 or later is needed to use the git-p4 + - Python version 2.6 or 2.7 is needed to use the git-p4 interface to Perforce. - Some platform specific issues are dealt with Makefile rules, -- 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 0/3] fixup remaining cvsimport tests
John Keeping j...@keeping.me.uk writes: On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote: On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote: On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote: These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) Did you post the fix for the revision map publicly anywhere? It's in Eric's repo and included in version 3.8: https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6 Thanks. For some reason I thought the fix would be to git-cvsimport-3.py. Obviously I should have read more carefully. Sorry for the noise. This is not a noise, though. Chris, how would we want to proceed? I'd prefer at some point to see cvsimport-3 to be in sync when the one patched and tested in Eric's repository is proven enough. Will Eric be the gatekeeper, or will you be sending patches this way as well? -- 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] Change old system name 'GIT' to 'Git'
Joachim Schmitz j...@schmitz-digital.de writes: Because then it could get confused with git, the command? That would be lower case even at the beginning of a sentence, wouldn't it? Is it a real-world problem? I think in a prose when you refer to git the command, you would say something like The `git` command started as a thin wrapper to many subcommand of the `git-subcmd` form. -- 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 interactive rebase 'consume' command
Stephen Kelly steve...@gmail.com writes: Hi there, I find the fixup command during an interactive rebase useful. Sometimes when cleaning up a branch, I end up in a situation like this: pick 07bc3c9 Good commit. pick 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. So, I have to reorder the commits, and change 1313a5e to 'f'. An alternative would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message. The problem with that is it ends up with the wrong author time information. So, I usually reorder and then fixup, but that can also be problematic if I get a conflict during the re-order (which is quite likely). I would prefer to be able to mark a commit as 'should be consumed', so that: pick 07bc3c9 Good commit. consume 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. will result in pick 07bc3c9 Good commit. pick 62a3c2f Another commit. directly. Any thoughts on that? Sorry, but I do not understand what you are trying to solve. How can 1313a5e, which fixes misakes made in c2f62a3, come before that commit in the first place? -- 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 interactive rebase 'consume' command
Junio C Hamano wrote: Sorry, but I do not understand what you are trying to solve. How can 1313a5e, which fixes misakes made in c2f62a3, come before that commit in the first place? One scenario is something like this: Start with a clean HEAD (always a good idea :) ) hack hack hack make multiple commits realize that a hunk you committed in an early patch belongs in a later one. use git rebase -i to fix it. Is that more clear? Thanks, Steve. -- 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] git rm -u
On 01/20/2013 01:53 PM, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Implementing git rm -u as a tree-wide command would create a discrepancy with git add -u. Implementing it as a current directory command would make the migration harder if we eventually try to change git add -u. Perhaps git rm -u should be forbidden from a subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. Yeah, that sounds sensible. Start with a 'git rm -u' is forbidden without arguments, give advise to use either . or :/. And stop there. I was unaware of any plan to change `git add -u`, but the above makes sense to me. I will use those suggestions as guidelines for the initial implementation of `git rm -u`. In particular, it will require an argument like `.` or `:/`. It sounds like the future direction of `git add -u` will play a role in how `git rm -u` should behave so that there is consistency between the two, so I will try to take a conservative approach in my implementation. Thank you both for the advice and insight. -- ejmr 南無妙法蓮華經 -- 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 0/3] fixup remaining cvsimport tests
On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote: On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote: On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote: These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) Did you post the fix for the revision map publicly anywhere? It's in Eric's repo and included in version 3.8: https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6 Thanks. For some reason I thought the fix would be to git-cvsimport-3.py. Obviously I should have read more carefully. Sorry for the noise. This is not a noise, though. Chris, how would we want to proceed? I'd prefer at some point to see cvsimport-3 to be in sync when the one patched and tested in Eric's repository is proven enough. Will Eric be the gatekeeper, or will you be sending patches this way as well? In this case the patch was to the C portion of cvsps, not the Python cvs-import, so not relevant for this particular case. I currently have a set of patches on top of jc/cvsimport-upgrade, which is slightly out-of-sync with git-cvsimport.py in Eric's cvsps repository, because I hadn't realised that the latter existed until about an hour ago. I haven't decided yet whether to rebase those onto the git-cvsimport.py in the cvsps repository or send them here to apply on top of jc/cvsimport-upgrade. Given that git-cvsimport is a command which has been around for a while and (although this is a complete re-write) the aim of these changes is to keep it working as the upstream project changes, I have a slight preference for keeping git-cvsimport here and recommending that the copy in the cvsps repository is removed. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: git-p4 supports Python 2.6 and later versions of Python 2. Since Python 2.8 will never exist [1], it is most concise to just list the supported versions. Thanks; Eric's patch recently updated git-p4.py to require 2.4 I think. Shouldn't it also be updated? I haven't done a thorough audit to check what the actual minimum supported version is, this is just the minimal change to say not Python 3. Personally, I'm not sure of the value of having version checks at the top of the Python scripts, I would rather set a project-wide minimum supported version (as in my recent CodingGuidelines patch) and check it once in the Makefile. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Make git selectively and conditionally ignore certain stat fields
- Ursprungligt meddelande - That configurability is a slipperly slope to drag us into giving users more complexity that does not help them very much, I suspect. Earlier somebody mentioned size and mtime is often enough, so I think a single option core.looseStatInfo (substitute loose with short, minimum or whatever adjective that is more appropriate---I am not good at picking phrases, it sounds to me a way to more loosely define stat info cleanliness than we usually do) that makes us ignore all fields (regardless of their zero-ness) other than those two fields might not be a bad way to go. Would something like this be good? core.statinfo = default = all fields minimal = whole seconds of mtime and size medium = seconds, nanos of mtime and size nonzero = all non-zero fields -- robin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
John Keeping j...@keeping.me.uk writes: On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: git-p4 supports Python 2.6 and later versions of Python 2. Since Python 2.8 will never exist [1], it is most concise to just list the supported versions. Thanks; Eric's patch recently updated git-p4.py to require 2.4 I think. Shouldn't it also be updated? I haven't done a thorough audit to check what the actual minimum supported version is, this is just the minimal change to say not Python 3. Personally, I'm not sure of the value of having version checks at the top of the Python scripts, I would rather set a project-wide minimum supported version (as in my recent CodingGuidelines patch) and check it once in the Makefile. OK; I'll leave that for later a day (Cc'ed Eric but stakeholders of other Python scripts may want to express their opinions), and will apply this patch as is. If we end up deciding to rip out the prerequisite per file, that will be a tree-wide change that is independent from your patch we are discussing in this thread. If we end up not doing that, then we would instead be updating git-p4.py to set a higher floor to the prerequiste but that can come as a separate patch. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Allow Git::get_tz_offset to properly handle DST boundary times
On Thu, Jan 17, 2013 at 7:09 PM, Junio C Hamano gits...@pobox.com wrote:
Ben Walton bdwal...@gmail.com writes:
The Git::get_tz_offset is meant to provide a workalike replacement for
the GNU strftime %z format specifier. The algorithm used failed to
properly handle DST boundary cases.
For example, the unix time 1162105199 in CST6CDT saw set_tz_offset
improperly return -0600 instead of -0500.
TZ=CST6CDT date -d @1162105199 +%c %z
Sun 29 Oct 2006 01:59:59 AM CDT -0500
$ zdump -v /usr/share/zoneinfo/CST6CDT | grep 2006
/usr/share/zoneinfo/CST6CDT Sun Apr 2 07:59:59 2006 UTC = Sun Apr 2
01:59:59 2006 CST isdst=0 gmtoff=-21600
/usr/share/zoneinfo/CST6CDT Sun Apr 2 08:00:00 2006 UTC = Sun Apr 2
03:00:00 2006 CDT isdst=1 gmtoff=-18000
/usr/share/zoneinfo/CST6CDT Sun Oct 29 06:59:59 2006 UTC = Sun Oct 29
01:59:59 2006 CDT isdst=1 gmtoff=-18000
/usr/share/zoneinfo/CST6CDT Sun Oct 29 07:00:00 2006 UTC = Sun Oct 29
01:00:00 2006 CST isdst=0 gmtoff=-21600
To determine how many hours/minutes away from GMT a particular time
was, we calculated the gmtime() of the requested time value and then
used Time::Local's timelocal() function to turn the GMT-based time
back into a scalar value representing seconds from the epoch. Because
GMT has no daylight savings time, timelocal() cannot handle the
ambiguous times that occur at DST boundaries since there are two
possible correct results.
To work around the ambiguity at these boundaries, we must take into
account the pre and post conversion values for is_dst as provided by
both the original time value and the value that has been run through
timelocal(). If the is_dst field of the two times disagree then we
must modify the value returned from timelocal() by an hour in the
correct direction.
It seems to me that it is a very roundabout way. It may be correct,
but it is unclear why the magic +/-3600 shift is the right solution
and I suspect even you wouldn't notice if I sent you back your patch
with a slight change to swap $gm += 3600 and $gm -= 3600 lines ;-).
For that timestamp in question, the human-readable representation of
gmtime($t) and localtime($t) look like these two strings:
my $t = 1162105199;
print gmtime($t), \n;# Sun Oct 29 06:59:59 2006
print localtime($t), \n; # Sun Oct 29 01:59:59 2006
As a human, you can easily see that these two stringified timestamps
look 5 hours apart. Think how you managed to do so.
If we convert these back to the seconds-since-epoch, as if these
broken-down times were both in a single timezone that does not have
any DST issues, you can get the offset (in seconds) by subtraction,
and that is essentially the same as the way in which your eyes saw
they are 5 hours apart, no? In other words, why do you need to run
timelocal() at all?
my $t = 1162105199;
my $lct = timegm(localtime($t));
# of course, timegm(gmtime($t)) == $t
my $minutes = int(($lct - $t)/60);
my $sign +;
if ($minutes 0) {
$sign = -;
$minutes = -$minutes;
}
my $hours = int($minutes/60);
$minutes -= $hours * 60;
sprintf(%s%02d%02d, $sign, $hours, $minutes);
Confused...
Signed-off-by: Ben Walton bdwal...@gmail.com
---
perl/Git.pm | 20
1 file changed, 20 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index 5649bcc..788b9b4 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -528,7 +528,27 @@ If TIME is not supplied, the current local time is used.
sub get_tz_offset {
# some systmes don't handle or mishandle %z, so be creative.
my $t = shift || time;
+ # timelocal() has a problem when it comes to DST ambiguity so
+ # times that are on a DST boundary cannot be properly converted
+ # using it. we will possibly adjust its result depending on whehter
+ # pre and post conversions agree on DST
my $gm = timelocal(gmtime($t));
+
+ # we need to know whether we were originally in DST or not
+ my $orig_dst = (localtime($t))[8];
+ # and also whether timelocal thinks we're in DST
+ my $conv_dst = (localtime($gm))[8];
+
+ # re-adjust $gm based on the DST value for the two times we're
+ # handling.
+ if ($orig_dst != $conv_dst) {
+ if ($orig_dst == 1) {
+ $gm -= 3600;
+ } else {
+ $gm += 3600;
+ }
+ }
+
my $sign = qw( + + - )[ $t = $gm ];
return sprintf(%s%02d%02d, $sign, (gmtime(abs($t - $gm)))[2,1]);
}
Sorry for the slow response, I didn't have a good chance to look at
this until now. You are correct; your solution appears simpler and
also avoids the oddball 1/2 hour DST shift. I can re-roll the series
with your code (and credit for it) or you can apply you change on top
of my series...whichever is easiest for you.
Thanks
-Ben
--
git-cvsimport-3 and incremental imports
I've now spent some time looking at git-cvsimport-3.py from jc/cvsimport-upgrade and made some progress in making it pass more of the Git test suite (my work in progress is at [1]). However, I think there is a fundamental problem with the way it handles incremental imports and I'm hoping someone with more git-fast-import experience can point me in the right direction. Currently, cvsps-3 never writes a from ... line in the first commit it outputs for a branch, even when the output is restricted by date (i.e. a continuation of a previously imported branch), which results in failure to update branches since git-fast-import is run without --force. If I make a simple modification so that it does this, it can end up outputting an empty commit (a duplicate of the current tip commit on the branch). Given that the start date for the import is currently just read from HEAD there is probably scope for this being worse on other branches if they have more recent commits than the current branch. I don't think there is any way to solve this without giving cvsps more information, probably the last commit time for all git branches, but perhaps I'm missing a fast-import feature that can help solve this problem. [1] https://github.com/johnkeeping/git/tree/cvsimport-3 John -- 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
Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
If I were to decide today to change the spellings, with an explicit purpose of making things more consistent across documentation, it may make sense to use even a simpler rule that is less error-prone for people who write new sentences that has to have the word. How about treating it just like any other ordinary word? That is, we say git (without double-quotes, of course), unless it comes at the beginning of a sentence? The widely used books on Git by Scott Chacon or Jon Loeliger (and many others) are using 'Git' instead of 'git' when talking about the whole system. So IMHO it would not be wise to change our internal documentation from using 'GIT'/'Git' to using 'git'. The internal documentation should be a natural continuation of these books by content and style. - Just my thoughts. --- Thomas -- 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 0/3] fixup remaining cvsimport tests
On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote: John Keeping j...@keeping.me.uk writes: On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote: On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote: On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote: These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) Did you post the fix for the revision map publicly anywhere? It's in Eric's repo and included in version 3.8: https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6 Thanks. For some reason I thought the fix would be to git-cvsimport-3.py. Obviously I should have read more carefully. Sorry for the noise. This is not a noise, though. Chris, how would we want to proceed? I'd prefer at some point to see cvsimport-3 to be in sync when the one patched and tested in Eric's repository is proven enough. Will Eric be the gatekeeper, or will you be sending patches this way as well? I probably won't be sending any more patches on this. My hope was to get cvsimport-3 (w/ cvsps as the engine) in a state such that one could transition from the previous version seamlessly. But the break in t9605 has convinced me this is not worth the effort--even in this trivial case cvsps is broken. The fuzzing logic aggregates commits into patch sets that have timestamps within a specified window and otherwise matching attributes. This aggregation causes file-level commit timestamps to be lost and we are left with a single timestamp for the patch set: the minimum for all contained CVS commits. When all commits have been processed, the patch sets are ordered chronologically and printed. The problem is that is that a CVS commit is rolled into a patch set regardless of whether the patch set's timestamp falls within the adjacent CVS file-level commits. Even worse, since the patch set timestamp changes as subsequent commits are added (i.e., it's always picking the earliest) it is potentially indeterminate at the time a commit is added. The result is that file revisions can be reordered in resulting Git import (see t9605.) I spent some time last week trying to solve this but I coudln't think of anything that wasn't a substantial re-work of the code. I have never used cvs2git, but I suspect Eric's efforts in making it a potential backend for cvsimport are a better use of time. Chris -- 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 interactive rebase 'consume' command
Stephen Kelly steve...@gmail.com writes: Junio C Hamano wrote: Sorry, but I do not understand what you are trying to solve. How can 1313a5e, which fixes misakes made in c2f62a3, come before that commit in the first place? One scenario is something like this: Start with a clean HEAD (always a good idea :) ) hack hack hack make multiple commits realize that a hunk you committed in an early patch belongs in a later one. use git rebase -i to fix it. Is that more clear? Not really. If you think that the author timestamp is the time the author finished working on the commit, shouldn't the squashed result get the timestamp when you finished squashing, not the timestamp of either of the commits that were squashed? Unlike fixup and reword, the change you are making is very different from any of the original constituent commmits, and you finished working on that change when you squashed these commits into one. Propagating the timestamp from the later ones sounds equally wrong for that purpose. In any case, the intent of the author timestamp is to record the time the author _started_ working on the change and came up with an initial, possibly a partial, draft. It does not record the time when the commit was finalized. git commit --amend preserves the original timestamp, doesn't it? In your example: pick 07bc3c9 Good commit. pick 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. you can view 1313a5e as a preparatory clean-up for the real change in c2f62a3, which could be a separate commit in the final history. If you choose to squash them together into one, the time you recorded 1313a5e was when you started working on the combined change, so it does not sound so wrong to take that author timestamp for the result. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Make git selectively and conditionally ignore certain stat fields
Robin Rosenberg robin.rosenb...@dewire.com writes: - Ursprungligt meddelande - That configurability is a slipperly slope to drag us into giving users more complexity that does not help them very much, I suspect. Earlier somebody mentioned size and mtime is often enough, so I think a single option core.looseStatInfo (substitute loose with short, minimum or whatever adjective that is more appropriate---I am not good at picking phrases, it sounds to me a way to more loosely define stat info cleanliness than we usually do) that makes us ignore all fields (regardless of their zero-ness) other than those two fields might not be a bad way to go. Would something like this be good? core.statinfo = default = all fields minimal = whole seconds of mtime and size medium = seconds, nanos of mtime and size nonzero = all non-zero fields -- robin If you mean to exclude ctime and other fields we already exclude as useless from your all, that may make sense, but do we really need that much flexibility, or do more choices just confuse users? I have this suspicion that it may be the latter. Wouldn't a single boolean that lets users choose between your minimal and default be sufficient? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
On Sun, Jan 20, 2013 at 11:28 AM, John Keeping j...@keeping.me.uk wrote: On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: git-p4 supports Python 2.6 and later versions of Python 2. Since Python 2.8 will never exist [1], it is most concise to just list the supported versions. Thanks; Eric's patch recently updated git-p4.py to require 2.4 I think. Shouldn't it also be updated? Actually, the script does not support python 2.4 in its current state since it uses subprocess.check_call which was introduced in python 2.5. But, this can be trivially worked around. I made the changes in my own tree on Friday and planned to submit them after using it myself for a few days. Personally, I prefer to continue to provide the ability to compile and install a fully working git on platforms in common use without pulling in additional dependencies. At least while it's fairly easy to do so. So, in my opinion, git-p4 should be patched to support python 2.4 and the comment in INSTALL should be updated. But, this opinion should be taken with the appropriate grain of salt since I'm not really a contributor to any of the python infrastructure. -Brandon -- 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] Allow Git::get_tz_offset to properly handle DST boundary times
Ben Walton bdwal...@gmail.com writes: also avoids the oddball 1/2 hour DST shift. I can re-roll the series with your code (and credit for it) or you can apply you change on top of my series...whichever is easiest for you. Please reroll, as I do not have patience either to set up a test case and verify the end result is correct, or to come up with a test case for it. For this particular case, I think the identification of the issue weighs more than the implementation for fix it, so please retain the authorship for the fix; mentioning taking the implementation idea from Junio in the log message is the right amount of credit due to me. 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: Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
Thomas Ackermann th.ac...@arcor.de writes: If I were to decide today to change the spellings, with an explicit purpose of making things more consistent across documentation, it may make sense to use even a simpler rule that is less error-prone for people who write new sentences that has to have the word. How about treating it just like any other ordinary word? That is, we say git (without double-quotes, of course), unless it comes at the beginning of a sentence? The widely used books on Git by Scott Chacon or Jon Loeliger (and many others) are using 'Git' instead of 'git' when talking about the whole system. So IMHO it would not be wise to change our internal documentation from using 'GIT'/'Git' to using 'git'. The internal documentation should be a natural continuation of these books by content and style. That argument is going the other way around (we _are_ the authoritative source). But I am OK with Git as a proper noun (which always begins with capital letter), using git only when it is something the user would type. Just come up with a simple-to-explain rule so that people will have no doubt which one to use in their new text and stick to it. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] fixup remaining cvsimport tests
On Sun, Jan 20, 2013 at 1:24 PM, John Keeping j...@keeping.me.uk wrote: On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote: This is not a noise, though. Chris, how would we want to proceed? I'd prefer at some point to see cvsimport-3 to be in sync when the one patched and tested in Eric's repository is proven enough. Will Eric be the gatekeeper, or will you be sending patches this way as well? In this case the patch was to the C portion of cvsps, not the Python cvs-import, so not relevant for this particular case. Oh, I think I misunderstood the question. The only time I passed a patch specifically for git-cvsimport.py directly to Eric was before the his patch was in Junio's repository. Unless I'm mistaken, only the second patch Eric sent was actually imported. Subsequent to this I would have submitted any patches for git-cvsimport.py directly to the git list. I just didn't have any--cvsps had several problems that needed to be worked out before it made sense to look at the importer. In other words, I don't think Eric should be a gatekeeper of this code. Chris -- 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 0/7] guilt patches, including git 1.8 support
On Sun, Jan 20, 2013 at 10:19:39PM +0100, Per Cederqvist wrote: On 01/16/13 03:26, Jonathan Nieder wrote: Hi Jeff and other guilty parties, I collected all the guilt patches I could find on-list and added one of my own. Completely untested, except for running the regression tests. These are also available via git protocol from git://repo.or.cz/guilt/mob.git mob Thoughts? Regarding the Change git branch when patches are applied feature, it has saved me a number of times since I implemented it. I've been using it extensively, and have not had any problems with it. Nevertheless, for backwards compatibility with the currently released guilt version I think it should be conditional, and disabled per default for one full release cycle. I've implemented this. My code is available from git://repo.or.cz/guilt/ceder.git The following commits are not included in your list: a194375 Added guilt.reusebranch configuration option. 1dd97bd Minor testsuite fix. 640caee The tests should not fail if guilt.diffstat is set. At $WORK, we started doing thorough reviews before committing. I'm kinda sold on this feature. I agree with the off-by-default config flag. I don't want Guilt to fork. Jeff, it would be really great if you could set up a public repo again! Yep. I'm trying to reclaim control of the repo.or.cz guilt repo... I no longer have access to jsi...@cs.sunysb.edu and I don't remember the password. Jeff. -- NT is to UNIX what a doughnut is to a particle accelerator. -- 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] git rm -u
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: git add -u is one of the only exceptions (with git grep). I consider this as a bug, and think this should be changed. This has been discussed several times here, but no one took the time to actually do the change Did we ever agree that it is a good change to begin with? Pointers? I think you can guess but I no longer need pointers. Others may still be helped, though. The argument IIRC boils down to - git add -u was made a whole-tree operation when there weren't the :/ magic pathspec, but add -u is very often something you want to do whole tree, and (cd ../../..; git add -u) or git add -u ../../.. are too cumbersome to type. - git add -u . to limit it to the current directory is easy to type. - As we have the from the root magic pathspec these days, requiring git add -u :/ when the user really means to add everything is no longer too much of a burden, but if we suddenly changed git add -u to mean git add -u ., that is too much of a change in the semantics. -- 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 0/7] guilt patches, including git 1.8 support
On 01/16/13 03:26, Jonathan Nieder wrote: Hi Jeff and other guilty parties, I collected all the guilt patches I could find on-list and added one of my own. Completely untested, except for running the regression tests. These are also available via git protocol from git://repo.or.cz/guilt/mob.git mob Thoughts? Regarding the Change git branch when patches are applied feature, it has saved me a number of times since I implemented it. I've been using it extensively, and have not had any problems with it. Nevertheless, for backwards compatibility with the currently released guilt version I think it should be conditional, and disabled per default for one full release cycle. I've implemented this. My code is available from git://repo.or.cz/guilt/ceder.git The following commits are not included in your list: a194375 Added guilt.reusebranch configuration option. 1dd97bd Minor testsuite fix. 640caee The tests should not fail if guilt.diffstat is set. I don't want Guilt to fork. Jeff, it would be really great if you could set up a public repo again! /ceder Jonathan Nieder (1): Drop unneeded git version check. Per Cederqvist (6): get rid of cat: write error: Broken pipe error message The tests should not fail if log.date or log.decorate are set. Testsuite: get rid of Broken pipe errors from yes. Handle empty patches and patches with only a header. Fix fatal guilt graph error in sha1sum invocation. Change git branch when patches are applied. Documentation/guilt.7 | 4 + guilt | 73 +--- guilt-branch | 12 +- guilt-commit | 7 + guilt-import-commit | 4 +- guilt-repair | 7 +- os.Darwin | 7 +- os.Linux | 7 +- os.SunOS | 7 +- regression/scaffold | 7 +- regression/t-029.sh | 6 +- regression/t-052.out | 24 +-- regression/t-052.sh | 7 +- regression/t-061.out | 468 ++ regression/t-061.sh | 148 15 files changed, 743 insertions(+), 45 deletions(-) create mode 100644 regression/t-061.out create mode 100755 regression/t-061.sh -- 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 0/2] Hiding some refs in ls-remote
Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: [uploadPack] hiderefs = refs/changes Would you want to do the same thing on receive-pack? It could benefit from the same reduction in network cost (although it tends to be invoked less frequently than upload-pack). ... As I said, I view this primarily as solving the cluttering issue. The use of hiderefs to hide these refs that point at objects I do not consider belong to my repository from the pushers equally makes sense as such, I think. Now that raises one question. Should this be transfer.hiderefs that governs both upload-pack and receive-pack? I tend to think the answer is yes. It may even make sense to have git push honor it, excluding them from git push --mirror (or git push --all if some of the branches are hidden); I haven't thought things through, though. -- 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] git rm -u
On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: git add -u is one of the only exceptions (with git grep). I consider this as a bug, and think this should be changed. This has been discussed several times here, but no one took the time to actually do the change - As we have the from the root magic pathspec these days, requiring git add -u :/ when the user really means to add everything is no longer too much of a burden, but if we suddenly changed git add -u to mean git add -u ., that is too much of a change in the semantics. And I think someone (Jeff?) pointed out that that last part is even more true for git clean, which also currently works on the current directory if not told otherwise. -- 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-cvsimport-3 and incremental imports
John Keeping j...@keeping.me.uk: I don't think there is any way to solve this without giving cvsps more information, probably the last commit time for all git branches, but perhaps I'm missing a fast-import feature that can help solve this problem. Yes, you are. The magic incantation is from refs/heads/branch^0 I've just pushed a cvsps-3.9 with an -i option that generates these at each branch root. Combine it with -d and you get incremental fast-export. You get to integrate this. I think the transition strategy Junio has chosen is seriously mistaken, leading to unnecessary grief for users who will be fooled into thinking it's OK to still use cvsps-2.x. Because I do not wish to encourage or endorse this mistake and am tired of arguing against stubborn determination to do the wrong thing, I am not going to sink more effort into the git project's end of the CVS-lifting problem. There are too many better uses for my time. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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-cvsimport-3 and incremental imports
Eric S. Raymond wrote: You get to integrate this. I think the transition strategy Junio has chosen is seriously mistaken, leading to unnecessary grief for users who will be fooled into thinking it's OK to still use cvsps-2.x. So our choices are: a. support current users, offend ESR, don't benefit from ESR improvements b. give up on current users, please ESR, benefit from ESR improvements c. some option yet undiscovered In that case, (c) sounds like our best bet. Do I understand correctly? Sigh, Jonathan -- 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-cvsimport-3 and incremental imports
Eric S. Raymond wrote: You get to integrate this. I think the transition strategy Junio has chosen is seriously mistaken, leading to unnecessary grief for users who will be fooled into thinking it's OK to still use cvsps-2. Ah, I missed a detail on first reading. I think there has been a small misunderstanding. Junio proposed a transition strategy, but I don't think it's fair to say he has chosen it without discussion or is imposing it on you. If you or someone else comes up with a better transition strategy, you are free to completely ignore Junio's proposal. If the affected users generally prefer your alternate proposal, in my experience that means it will be integrated. Hoping that clarifies a little, Jonathan -- 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-cvsimport-3 and incremental imports
Jonathan Nieder jrnie...@gmail.com writes: Eric S. Raymond wrote: You get to integrate this. I think the transition strategy Junio has chosen is seriously mistaken, leading to unnecessary grief for users who will be fooled into thinking it's OK to still use cvsps-2.x. So our choices are: a. support current users, offend ESR, don't benefit from ESR improvements b. give up on current users, please ESR, benefit from ESR improvements c. some option yet undiscovered In that case, (c) sounds like our best bet. Do I understand correctly? Sigh, Jonathan Isn't (c) is to just build on cvsimport-2 and cvsimport-3 combo? If Eric does not want to get involved in cvsimport-2 (and cvsps2), that is perfectly fine. We have the beginning of cvsimport-3 code that was released with Sign-off, and as long as cvsps3 produces a more corrrect output stream (either traditional cvsps2 style or as a fast-import stream) than cvsps2 conversion describes, cvsimport-3 can get the full benefit of his work, no? I do not think that Eric will be the only person who understands cvsps3 output who can fix bugs that may potentially still exist in cvsimport-3 code [*1*]. We live in real world, and distro inertia makes it likely that a new version of git that does not work for people who have been happy with cvsps2 will get resistance from them, when they do not trust the 0.x releases of a new piece of software cvsps3 that happens to have a name similar to what they have been shipping, i.e. cvsps2. Shipping such a crippled Git will not be an effective way to promote adoption of cvsps3. [Footnote] *1* This of course assumes Eric's two major claims are true, that is, (1) cvsimport-3 is already mature and better than cvsimport-2, and (2) the code is so simple that it does not even need its own tests as long as the front-end conversion that happens at the cvsps3 end is tested well. Choosing b. will have to assume them to be true anyway, so I do not think it is a big loss to rely on the same assumptions and choose b. from our point of view. -- 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-cvsimport-3 and incremental imports
Junio C Hamano gits...@pobox.com writes: ..., so I do not think it is a big loss to rely on the same assumptions and choose b. from our point of view. Of course the last sentence is a typo: choose c. is what I meant. -- 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] mergetools: Add tortoisegitmerge helper
Sven Strickroth sven.strickr...@tu-clausthal.de writes: - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe (starting with 1.8.0) in order to make clear that this one has special support for git and prevent confusion with the TortoiseSVN TortoiseMerge version. - The tortoisemerge mergetool does not work with filenames which have a space in it. Fixing this required changes in git and also in TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57. The new tortoisegitmerge helper was added so that people can still use TortoiseMerge from TortoiseSVN (and older TortoiseGit versions). Signed-off-by: Sven Strickroth em...@cs-ware.de Reported-by: Sebastian Schuberth sschube...@gmail.com --- Applying: mergetools: Add tortoisegitmerge helper fatal: corrupt patch at line 56 That comes from here: diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt index 9bb4956..a047646 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -55,9 +55,9 @@ merge.tool:: Controls which merge resolution program is used by linkgit:git-mergetool[1]. Valid built-in values are: araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3, meld, - opendiff, p4merge, tkdiff, tortoisemerge, vimdiff - and xxdiff. Any other value is treated is custom merge tool - and there must be a corresponding mergetool.tool.cmd option. + opendiff, p4merge, tkdiff, tortoisegitmerge, tortoisemerge, + vimdiff and xxdiff. Any other value is treated is custom merge + tool and there must be a corresponding mergetool.tool.cmd option. merge.verbosity:: Controls the amount of output shown by the recursive merge diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash Notice that we have three pre-context lines but only two post-context lines for this hunk. There is one context line missing at the end of this hunk. I'd usually try to queue a corrupt patch by manually fixing up when it is a trivial corruption, but a corruption that _loses_ lines is too dangerous to be handled that way. There may be additions in other hunks you wanted to make that were lost for the same reason why the post-context line was lost here, and my fix-up would end up committing a wrong patch. Please investigate how this happened, and re-send after hearing reviews from others. 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: git-cvsimport-3 and incremental imports
Jonathan Nieder jrnie...@gmail.com: Junio proposed a transition strategy, but I don't think it's fair to say he has chosen it without discussion or is imposing it on you. I have said everything I could about the bad effects of encouraging people to continue to use cvsps-2.x, it didn't budge Junio an inch, and I'm tired of fighting about it. Quibbling about the semantics of 'impose' will neither change these facts nor make me any less frustrated with the outcome. I will continue to do what I can to make cvsps-3.x and cvs-fast-export as bug-free as possible, given the innate perverseness of CVS. They won't be perfect; they will be *better*. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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-svn: Add test for git-svn repositories with a gitdir link
Signed-off-by: Barry Wardell barry.ward...@gmail.com --- t/t9100-git-svn-basic.sh | 8 1 file changed, 8 insertions(+) diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh index 749b75e..4fea8d9 100755 --- a/t/t9100-git-svn-basic.sh +++ b/t/t9100-git-svn-basic.sh @@ -306,5 +306,13 @@ test_expect_success 'git-svn works in a bare repository' ' git svn fetch ) rm -rf bare-repo ' +test_expect_success 'git-svn works in in a repository with a gitdir: link' ' + mkdir worktree gitdir + ( cd worktree + git svn init $svnrepo + git init --separate-git-dir ../gitdir + git svn fetch ) + rm -rf worktree gitdir + ' test_done -- 1.8.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
[PATCH 2/2] git-svn: Simplify calculation of GIT_DIR
Since git-rev-parse already checks for the $GIT_DIR environment
variable and that it returns an actual git repository, there is no
need to repeat the checks again here.
This also fixes a problem where git-svn did not work in cases where
.git was a file with a gitdir: link.
Signed-off-by: Barry Wardell barry.ward...@gmail.com
---
git-svn.perl | 36 +---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index bd5266c..3bcd769 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -61,8 +61,6 @@ my $cmd_dir_prefix = eval {
command_oneline([qw/rev-parse --show-prefix/], STDERR = 0)
} || '';
-my $git_dir_user_set = 1 if defined $ENV{GIT_DIR};
-$ENV{GIT_DIR} ||= '.git';
$Git::SVN::Ra::_log_window_size = 100;
if (! exists $ENV{SVN_SSH} exists $ENV{GIT_SSH}) {
@@ -325,27 +323,19 @@ for (my $i = 0; $i @ARGV; $i++) {
};
# make sure we're always running at the top-level working directory
-unless ($cmd $cmd =~ /(?:clone|init|multi-init)$/) {
- unless (-d $ENV{GIT_DIR}) {
- if ($git_dir_user_set) {
- die GIT_DIR=$ENV{GIT_DIR} explicitly set, ,
- but it is not a directory\n;
- }
- my $git_dir = delete $ENV{GIT_DIR};
- my $cdup = undef;
- git_cmd_try {
- $cdup = command_oneline(qw/rev-parse --show-cdup/);
- $git_dir = '.' unless ($cdup);
- chomp $cdup if ($cdup);
- $cdup = . unless ($cdup length $cdup);
- } Already at toplevel, but $git_dir not found\n;
- chdir $cdup or die Unable to chdir up to '$cdup'\n;
- unless (-d $git_dir) {
- die $git_dir still not found after going to ,
- '$cdup'\n;
- }
- $ENV{GIT_DIR} = $git_dir;
- }
+if ($cmd $cmd =~ /(?:clone|init|multi-init)$/) {
+ $ENV{GIT_DIR} ||= .git;
+} else {
+ git_cmd_try {
+ $ENV{GIT_DIR} = command_oneline([qw/rev-parse --git-dir/]);
+ } Unable to find .git directory\n;
+ my $cdup = undef;
+ git_cmd_try {
+ $cdup = command_oneline(qw/rev-parse --show-cdup/);
+ chomp $cdup if ($cdup);
+ $cdup = . unless ($cdup length $cdup);
+ } Already at toplevel, but $ENV{GIT_DIR} not found\n;
+ chdir $cdup or die Unable to chdir up to '$cdup'\n;
$_repository = Git-repository(Repository = $ENV{GIT_DIR});
}
--
1.8.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
[PATCH v3 0/2] Make git-svn work with gitdir links
These patches fix a bug which prevented git-svn from working with repositories which use gitdir links. Changes since v2: - Rebased onto latest master. - Added test case which verifies that the problem has been fixed. - Fixed problems with git svn (init|clone|multi-init). - All git-svn test cases now pass (except two in t9101 which also failed before these patches). Barry Wardell (2): git-svn: Add test for git-svn repositories with a gitdir link git-svn: Simplify calculation of GIT_DIR git-svn.perl | 36 +--- t/t9100-git-svn-basic.sh | 8 2 files changed, 21 insertions(+), 23 deletions(-) -- 1.8.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 0/3] fixup remaining cvsimport tests
On Sun, Jan 20, 2013 at 2:17 PM, Chris Rorvick ch...@rorvick.com wrote: On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote: John Keeping j...@keeping.me.uk writes: On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote: On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote: On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote: These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15 tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent to Eric (fixes revision map.) Did you post the fix for the revision map publicly anywhere? It's in Eric's repo and included in version 3.8: https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6 Thanks. For some reason I thought the fix would be to git-cvsimport-3.py. Obviously I should have read more carefully. Sorry for the noise. This is not a noise, though. Chris, how would we want to proceed? I'd prefer at some point to see cvsimport-3 to be in sync when the one patched and tested in Eric's repository is proven enough. Will Eric be the gatekeeper, or will you be sending patches this way as well? I probably won't be sending any more patches on this. My hope was to get cvsimport-3 (w/ cvsps as the engine) in a state such that one could transition from the previous version seamlessly. But the break in t9605 has convinced me this is not worth the effort--even in this trivial case cvsps is broken. The fuzzing logic aggregates commits into patch sets that have timestamps within a specified window and otherwise matching attributes. This aggregation causes file-level commit timestamps to be lost and we are left with a single timestamp for the patch set: the minimum for all contained CVS commits. When all commits have been processed, the patch sets are ordered chronologically and printed. The problem is that is that a CVS commit is rolled into a patch set regardless of whether the patch set's timestamp falls within the adjacent CVS file-level commits. Even worse, since the patch set timestamp changes as subsequent commits are added (i.e., it's always picking the earliest) it is potentially indeterminate at the time a commit is added. The result is that file revisions can be reordered in resulting Git import (see t9605.) I spent some time last week trying to solve this but I coudln't think of anything that wasn't a substantial re-work of the code. I have never used cvs2git, but I suspect Eric's efforts in making it a potential backend for cvsimport are a better use of time. Chris Hi Eric, I noticed you were taken off this thread. As I mention above, I looked into the bug tested in the t9605 patch Junio applied on top of your cvsimport patch. The test was actually written for master to test the Perl/cvsps2 import, but with minor modification you can verify the problem still exists in the 3.x versions of cvsps. I think the email above explains the problem pretty well. It's not clear to me what all the nastiness is that you've resolved with cvsps since taking over; I've been mostly concerned with importing an almost branchless repository which I thought avoided the types of problems you were addressing. But this bug can actually cause Git's main import branch to become inconsistent with CVS HEAD and you don't have to do anything too weird to get hit by it. Fixing this seemed like it would require splitting the processing out into a couple phases and would be a fair amount of work, but maybe I'm just not looking at the problem right. Chris -- 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] unpack-trees: do not abort when overwriting an existing file with the same content
On Mon, Jan 21, 2013 at 1:35 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: + /* + * If it has the same content that we are going to write down, write down??? hmm.. overwrite then. + * there's no point in complaining. We still overwrite it in the + * end though. Permission is not checked so it may be lost. + */ That is a regression, isn't it? Is it too cumbersome to avoid losing the permission bits by stopping in that case? I'm not sure how to deal with this case. (Lack of) Executable bit can be easily restored (unlike file content) if we give the user the list of changed files. On the other hand, not everybody runs git with a huge scrollback buffer and warnings can be lost. I guess abort is a safe choice. -- Duy -- 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: [PULL] Module fixes, and a virtio block fix.
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think this should be fixed in modern git versions. And it sure as hell knows the proper tag name, since you *gave* it the name and it used it for generating the actual contents. The fact that some versions then screw that up and re-write the tag-name to something randomly matching that isn't a tag was just a bug. For want of a better solution, I'll now resort to sending pull requests with the anti-social gitolite URL in it, like so: That's even worse, fwiw. It means that the pull request address makes no sense to anybody who doesn't have a kernel.org address, and then I'm forced to just edit things by hand instead to not pollute the kernel changelog history with crap. Junio, didn't git request-pull get fixed so that it *warns* about missing tagnames/branches, but never actually corrupts the pull request? Or did it just get fixed to be a hard error instead of corrupting things? Because this is annoying. Linus -- 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 0/2] Hiding some refs in ls-remote
On Sun, Jan 20, 2013 at 2:16 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: Should the client side learn how to list hidden refs too? I'm thinking of an extreme case where upload-pack advertises nothing (or maybe just refs/heads/master) and it's up to the client to ask for the ref selection it's interested in. upload-pack may need more updates to do that, I think. What you are talking about is a different goal. Look at this as a mechanism for the repository owner to control the clutter in what is shown to the intended audience of what s/he publishes in the repository. Network bandwidth reduction of advertisement is a side effect of clutter reduction, and not necessarily the primary goal. Probably stupid question: does gitnamespaces.txt attempt to achieve the same? The document says smart http supports passing namespace, nothing about git protocol so I guess we need some extension in upload-pack (or git-daemon) for specifying namespace over git protocol. -- Duy -- 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 interactive rebase 'consume' command
On Sun, Jan 20, 2013 at 12:23:41PM -0800, Junio C Hamano wrote: In any case, the intent of the author timestamp is to record the time the author _started_ working on the change and came up with an initial, possibly a partial, draft. It does not record the time when the commit was finalized. git commit --amend preserves the original timestamp, doesn't it? And we have --reset-author if you want to do that. It seems like just doing git commit --amend --reset-author at the end[1] would solve the original problem. Perhaps that is something that we could better support directly from the instruction sheet. -Peff [1] or after an edit break in the instruction sheet, if it is in the middle of a set of commits -- 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 0/2] Make git-svn work with gitdir links
Barry Wardell barry.ward...@gmail.com writes: These patches fix a bug which prevented git-svn from working with repositories which use gitdir links. Changes since v2: - Rebased onto latest master. - Added test case which verifies that the problem has been fixed. - Fixed problems with git svn (init|clone|multi-init). - All git-svn test cases now pass (except two in t9101 which also failed before these patches). Barry Wardell (2): git-svn: Add test for git-svn repositories with a gitdir link git-svn: Simplify calculation of GIT_DIR Thanks for your persistence ;-) As this is a pretty old topic, I'll give two URLs for people who are interested to view the previous threads: http://thread.gmane.org/gmane.comp.version-control.git/192133 http://thread.gmane.org/gmane.comp.version-control.git/192127 You would want to mark it as test_expect_failure in the first patch and then flip it to text_expect_success in the second patch where you fix the breakage? Otherwise, after applying the first patch, the testsuite will break needlessly. I've Cc'ed Eric Wong (git-svn maintainer) and CMN who helped in the previous round. If the only issue is the above success/failure one, I think Eric can tweak the patches while applying them (I didn't look at the changes carefully myself, by the way). 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: [PULL] Module fixes, and a virtio block fix.
Linus Torvalds torva...@linux-foundation.org writes: On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think this should be fixed in modern git versions. ... Junio, didn't git request-pull get fixed so that it *warns* about missing tagnames/branches, but never actually corrupts the pull request? Or did it just get fixed to be a hard error instead of corrupting things? Because this is annoying. What you mean by corrupt is not clear to me, but the last change to the script is from 6 months ago to solve a related (perhaps the same?) problem, which should be in v1.7.11.2 and later: request-pull: really favor a matching tag After tagging the tip of dev branch with a for-linus tag and pushing both out, running $ git request-pull $url $last_release dev would produce an output asking the 'dev' branch of $url to be pulled, because that is what the user asked the message to say. We already detect this situation locally and include the contents of the tag in the output; if the $url has that tag, favor that tag (i.e. for-linus) in the generated message over the branch name the user gave us (i.e. dev) from the command line, to make the output look more consistent. -- 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
fgdrf
tgredgtrfb -- View this message in context: http://git.661346.n2.nabble.com/fgdrf-tp7575606.html Sent from the git mailing list archive at Nabble.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: [PULL] Module fixes, and a virtio block fix.
On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano gits...@pobox.com wrote: What you mean by corrupt is not clear to me Some versions would just silently change the actual name you were using. So if you said for-linus, it might change it to linus, just because that branch happened to have the same SHA1 commit ID. That's not right. Other versions would replace the for-linus with **missing-branch** because for-linus hadn't mirrored out yet. That's not right either. Basically, if git request-pull is given a branch/tag name, that is the only valid output (although going from branch-tag *might* be acceptable). The whole verify that it actually exists on the remote side must never *ever* actually change the message itself, it should just cause a warning outside of the message. I can't say from the commit message whether that's the thing that fixed it or not, but at least some people stopped sending me broken pull requests after updating to git. I'm just not sure which of the two different failure cases they happened to have (Rusty seems to have hit both) Linus -- 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 0/3] fixup remaining cvsimport tests
I probably won't be sending any more patches on this. My hope was to get cvsimport-3 (w/ cvsps as the engine) in a state such that one could transition from the previous version seamlessly. But the break in t9605 has convinced me this is not worth the effort--even in this trivial case cvsps is broken. The fuzzing logic aggregates commits into patch sets that have timestamps within a specified window and otherwise matching attributes. This aggregation causes file-level commit timestamps to be lost and we are left with a single timestamp for the patch set: the minimum for all contained CVS commits. When all commits have been processed, the patch sets are ordered chronologically and printed. The problem is that is that a CVS commit is rolled into a patch set regardless of whether the patch set's timestamp falls within the adjacent CVS file-level commits. Even worse, since the patch set timestamp changes as subsequent commits are added (i.e., it's always picking the earliest) it is potentially indeterminate at the time a commit is added. The result is that file revisions can be reordered in resulting Git import (see t9605.) I spent some time last week trying to solve this but I coudln't think of anything that wasn't a substantial re-work of the code. I've lost who was who in the comment thread, but I think it is rather likely that the above diagnosis is correct in every respect. I won't know for certain until I finish the test suite and apply it to all three tools (cvsps, cvs2git, cvs-fast-export) but what I've seen of their code indicates that cvsps has the weakest changeset analysis of the three, even after my fixes. I have never used cvs2git, but I suspect Eric's efforts in making it a potential backend for cvsimport are a better use of time. Agreed. I didn't add multiengine support to csvsimport at random or just because Heiko Vogt was bugging me about parsecvs. I was half-expecting cvsps to manifest a showstopper like this - hoping it wouldn't, but hedging against the possibility by making alternate engines easy to plug into git-cvsimport seemed like a *really good idea* from the beginning of my work on it. Sometimes being that kind of right really sucks. While I am going to have a try at modifying cvsps to make Chris's t9605 case work, I'm going to strictly limit the amount of time I spend on that effort since (as you imply) it is fairly likely this would be throwing good money after bad. Fixing this seemed like it would require splitting the processing out into a couple phases and would be a fair amount of work, but maybe I'm just not looking at the problem right. Actually I think you've called it *exactly* right. The job has to be done in multiple clique-spitting phases - that's why cvs2git has 7 passes (though a few of those, perhaps as many as 3, are artifactual). This is why the next step in my current work plan for CVS-related stuff will be unbundling my test suite from the cvsps tree and running it to see if cvs-fast-export dominates cvsps. I'm expecting that it will, in which case my plan will be to salvage the CVS client code out of cvsps (*that* part is quite good - fast, clean, effective) gluing it to the better analysis stage in cvs-fast-export, and then shooting cvsps through the head and burying it behind the barn. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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: [PULL] Module fixes, and a virtio block fix.
Linus Torvalds torva...@linux-foundation.org writes: On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think this should be fixed in modern git versions. And it sure as hell knows the proper tag name, since you *gave* it the name and it used it for generating the actual contents. The fact that some versions then screw that up and re-write the tag-name to something randomly matching that isn't a tag was just a bug. I'm confused. The default argument is HEAD: what does it know about tag names? git request-pull master korg The bug is that if it can't find that commit at the remote end, it still generates a valid-looking request (with a warning at the end), where it guesses you're talking about the master branch. For want of a better solution, I'll now resort to sending pull requests with the anti-social gitolite URL in it, like so: That's even worse, fwiw. It means that the pull request address makes no sense to anybody who doesn't have a kernel.org address, and then I'm forced to just edit things by hand instead to not pollute the kernel changelog history with crap. Since I use a wrapper script now for your pull requests I can use sed to unscrew it: [alias] for-linus = !check-commits TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus git tag -f -u D1ADB8F1 $TAGNAME HEAD git push korg tag $TAGNAME git request-pull master korg | sed s,gitol...@ra.kernel.org:/pub,git://git.kernel.org/pub, git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'sta...@kernel.org' | sed 's/^/Cc: /' Junio, didn't git request-pull get fixed so that it *warns* about missing tagnames/branches, but never actually corrupts the pull request? Or did it just get fixed to be a hard error instead of corrupting things? Because this is annoying. Here: git version 1.7.10.4 Cheers, Rusty. -- 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: [PULL] Module fixes, and a virtio block fix.
On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell ru...@rustcorp.com.au wrote: I'm confused. The default argument is HEAD: what does it know about tag names? Ugh. I actually thought that if you give it the tag name directly (as the end) it will use that. But no. It figures it out with git describe --exact internally. Regardless, if your HEAD is actually tagged, it *will* have the tag-name in git-request-pull. And it will have it based on your *local* repo, so the fact that it hasn't been mirrored out yet doesn't really matter. git request-pull knows that tag name regardless of mirroring issues. The bug is that if it can't find that commit at the remote end, it still generates a valid-looking request (with a warning at the end), where it guesses you're talking about the master branch. It really shouldn't do that any more, but you seem to have the older version with the bug. At least one of the annoying problems was fixed in the 1.7.11 series, you have 1.7.10. The nice thing about git is that it is *really* easy to upgrade. Just fetch the sources, do make; make install all as a normal user, and you do not need to worry about package management or distro issues or any crap like that. It installs into your $(HOME)/bin, and as long as your PATH has that first, you'll get it. I've long suggested that as the workaround for distros having old versions (some more so than others). Since I use a wrapper script now for your pull requests I can use sed to unscrew it: [alias] for-linus = !check-commits TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus git tag -f -u D1ADB8F1 $TAGNAME HEAD git push korg tag $TAGNAME git request-pull master korg | sed s,gitol...@ra.kernel.org:/pub,git://git.kernel.org/pub, git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'sta...@kernel.org' | sed 's/^/Cc: /' Heh. Ok. That will at least hide the breakage. But I suspect you could fix it by just updating git. Linus -- 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 setup bash completion for alias of git command
On Sun, Jan 20, 2013 at 7:14 PM, Jonathan Nieder jrnie...@gmail.com wrote: Hi Ping, Ping Yin wrote: However, in debian (testing, wheezy), it doesn't work $ gtlg orTAB gtlg or-bash: [: 1: unary operator expected -bash: [: 1: unary operator expected Yes, I can reproduce this. git bisect tells me it was introduced by v1.7.6-rc0~65^2~4 (completion: remove unnecessary _get_comp_words_by_ref() invocations, 2011-04-28). Since then, Felipe has done work to make reusing subcommand completion easy again, so you can do __git_complete gtlg _git_log Thanks very much. by following your advice, it works now. Ping Yin -- 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: [msysGit] Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 20.01.13 12:06, Jonathan Nieder wrote: Torsten Bögershausen wrote: I wonder, if if we can go one step further: Replace #ifdef WIN32 /* Both MinGW and MSVC */ [...] with #if defined(_MSC_VER) I thought Git for Windows was built using mingw, which doesn't define _MSC_VER? Puzzled, Jonathan Yes, After removing these lines in the git-compat-util.h of msysgit v1.8.1 it still compiled. So I start to speculate if the comment is still valid for mingw, or if that was true in the old days and not now any more. More investigation is needed, sorry for confusion. /Torsten -- 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
components that are out of round links of london sale
Ideals extremely stunning and really unpleasant, but i even now surrounding the failure, was that failure is the mother of results. on the other hand, quite a few fail to get a victory. this kind of is life in all his existence to comprehensive all hungry glimpse, all the dreams, and then went to heaven to go with you. how many individuals with out accomplishment and gray life can be stated to be challenging function is not hungry. life is a lifestyle. sadly, But however, than be joyful to death by death. when the sound came. we have no time to full their back [url=http://www.cheaplinksoflondonbracelet.co.uk/]links of london bracelets[/url], we have time to transform it. don't know from what time do you discover that also a want to be protected.mobile phone charms i truly don't is sturdy, but considering that i have a, i grew quite sturdy.Feel difficult to find your favorite Tiffany jewelry like earrings? Tiffany is your best destination. Tiffany earrings are well known for their highest quality and characteristic designs. We offer tiffany Co silver earrings, fashion earrings, hoop earrings, drop earrings,heart earrings , unique tiffany earrings , dangle tiffany earrings and so on. We guarantee that all our fashion tiffany earrings are at hotest price among on-line jewelry stores.. http://www.cheaplinksoflondonbracelet.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/components-that-are-out-of-round-links-of-london-sale-tp7575616.html Sent from the git mailing list archive at Nabble.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
pandora bracelets but by the time it has charms on
I'm a man, a pretty common one particular at that, and as these kinds of current obtaining has in no way been my sturdy position. So soon after getting my other-50 percent a pair of wellies for Christmas final 12 months, I quickly learned my lesson that this wasn't heading to be an acceptable option this yr, and so had to do some analysis forward of Christmas 2010. Now, to make it less difficult for me soon after the Wellington debacle, [url=http://www.buycheappandorabracelets.co.uk/]pandora uk[/url]. All effectively and beneficial, but as any of you who have ever Googled charm bracelets or tried to brave the neighborhood jewellery store fronted by pushy camp gross sales assistants will know, it's a minefield. http://www.buycheappandorabracelets.co.uk/ So I thought I would provide all of us out there the advantage of my extensive analysis and (until finally just lately) pretty restricted but expanding knowledge in the place.So very first, you have to negotiate all the diverse possibilities out there, and there are a whole lot! Chamilia, Nomination, Reality, Pandora, the record is seemingly endless. By far the most secure alternative, and one particular of the most well-known by all accounts, is Pandora. They are Danish designers who only retail their merchandise by way of their own stores or via selected prime-stop jewellers. Their ranges seem far more in depth than some of the other makes, the high quality would seem wonderful, and the lifespan and longevity of their items is what actually swung it for me... a [url=http://www.buycheappandorabracelets.co.uk/]pandora bracelets[/url] is following all meant to be build upon about a period of time, so you want to know that you will be ready to add to it for some time to come, and I felt far more assured of that with the Pandora variety than I did with any of the other folks. http://www.buycheappandorabracelets.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/pandora-bracelets-but-by-the-time-it-has-charms-on-tp7575617.html Sent from the git mailing list archive at Nabble.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
pandora canada also advocate this as a implies of evenly
Now there are some beautiful leather and restricted edition selections which I think begin from just 30, all the way via to gold alternatives for a little more than a thousand kilos. The silver or the silver with a gold clasp are apparently the most common, but here's a word of suggestions if at all doable, have your lady with you for the sizing of it. [url=http://www.pandoraclub.org/]pandora bracelets[/url] but by the time it has charms on it this wouldn't have been massive enough. That explained, the outlets are fantastic with this, and if the size had been wrong, they would have been joyful to alter it following the celebration.So as soon as you have your bracelet, what else do you want? Effectively it would seem there are one thing termed clips of which it's helpful (although not vital) to have two. These clips sit equidistantly spaced opposite the clasp and let any charms in the early days to sit neatly between them at the top rated of the bracelet.[url=http://www.pandoraclub.org/]pandora canada[/url] also advocate this as a implies of evenly distributing the excess weight of the bracelet and I have to say this does make sense. They are priced from??25 upwards relying on your decision of content, and I feel they're a should. Furthermore, as these charm bracelet issues can be carrying a great deal of value (both in cash and sentimental terms) quite quickly, I'd also propose a security chain. Once more whilst they aren't totally needed they do look incredibly quite, and you know that in the unlikely occasion of the clasp coming loose, you have the backup of the chain. These begin from 70 relying on how elaborate you want to be.Then of course come the charms, and I need to acknowledge I've created very an addiction to purchasing these, browsing a more two jewellers immediately after producing my authentic purchase, the two of whom were similarly delightful and useful and not scary at all AJ Parkes in Northwich, Cheshire and Silvertree in Lancaster, Lancashire. You can actually get nearly something in any materials, with any stone, carrying any sentiment. http://www.pandoraclub.org/ -- View this message in context: http://git.661346.n2.nabble.com/pandora-canada-also-advocate-this-as-a-implies-of-evenly-tp7575618.html Sent from the git mailing list archive at Nabble.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: git-cvsimport-3 and incremental imports
Eric S. Raymond wrote: I have said everything I could about the bad effects of encouraging people to continue to use cvsps-2.x, it didn't budge Junio an inch, and I'm tired of fighting about it. What I think you misunderstood is that Junio is not the person you would have needed to convince. (Nor is it me.) [...] I will continue to do what I can to make cvsps-3.x and cvs-fast-export as bug-free as possible, given the innate perverseness of CVS. That's all anyone could hope for. :) Thanks. Ciao, Jonathan -- 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-cvsimport-3 and incremental imports
Eric S. Raymond e...@thyrsus.com writes: Jonathan Nieder jrnie...@gmail.com: Junio proposed a transition strategy, but I don't think it's fair to say he has chosen it without discussion or is imposing it on you. I have said everything I could about the bad effects of encouraging people to continue to use cvsps-2.x, it didn't budge Junio an inch, and I'm tired of fighting about it. Quibbling about the semantics of 'impose' will neither change these facts nor make me any less frustrated with the outcome. I am not quite sure if I follow you. The primary thing I am aiming for is to rob an excuse from people and from their distros to block newer Git and cvsps3. I've already cited a few URLs where we can see cvsps3 is blocked with an excuse it does not work with Git yet. If we ship new version of Git that only works with cvsps3, we will end up giving an excuse this version of Git no longer works with cvsps2 for distro packagers whose cvsps distro maintainer is slower than others to pick up cvsps3 for whatever reason. You may care deeply about CVS conversion part of the system, but you need to realize that majority of Git users do not care a whit about cvsimport. I do not want to give those distros that ship stale cvsps an excuse to pin their users at an old version of Git. By shipping both cvsimport-2 and cvsimport-3, we will rob from these distros the excuse to block shipping the version of Git that does support cvsps3 output. They can choose to update cvsps to 3.x and disable cvsimport-2 altogether at the build time, or if their cvsps distro maintainer is slow, they can ship both cvsimport-2 and -3 and let the user install cvsps 3.x under their $HOME if they want. If you want to abandon cvsps2 users, that is perfectly fine by me. As long as cvsps3 and cvsimport-3 combo works, Git before this series will have a _working_ cvsimport as far as I am concerned. In other words, I am fine to add a paragraph at the top of the Release Notes saying that (1) cvsps2 is no longer maintained; (2) using cvsps3 is the future direction for the users; and (3) if their distro is slow to adopt cvsps3, however, cvsimport can still be used with cvsps2, but bugs in it or cvsps2 are not expected to be fixed. to nudge distros to adopt cvsps3. I will continue to do what I can to make cvsps-3.x and cvs-fast-export as bug-free as possible, given the innate perverseness of CVS. They won't be perfect; they will be *better*. Yes, that is what we want. -- 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-cvsimport-3 and incremental imports
Junio C Hamano gits...@pobox.com writes: If you want to abandon cvsps2 users, that is perfectly fine by me. As long as cvsps3 and cvsimport-3 combo works, Git before this series will have a _working_ cvsimport as far as I am concerned. The above obviously is Git _after_ this series. Git before this series that only has cvsps2 support may be broken and Git after this series, when used with cvsps2, may be broken, but is broken the same way as before, so it is not a net loss. The users of distros that are slow to update cvsps can still use cvsimport-3 with cvsps3 that is manually installed, and the users of distros that ship cvsps3 will use cvsimport-3 and they can migrate away from cvsps2's breakage. -- 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
