* Re: Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Matthieu Moy @ 2013-01-20 11:24 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: davvid, git
In-Reply-To: <310504838.1116553.1358607676116.JavaMail.ngmail@webmail10.arcor-online.net>
Thomas Ackermann <th.acker@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/
^ permalink raw reply
* [PATCH] mergetools: Add tortoisegitmerge helper
From: Sven Strickroth @ 2013-01-20 11:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Sebastian Schuberth, davvid, Jeff King
- 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 <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@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 0000000..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" 1>&2
+ return 1
+ fi
+}
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply related
* Re: [RFC] git rm -u
From: Matthieu Moy @ 2013-01-20 11:32 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Eric James Michael Ritz, git, Tomas Carnecky
In-Reply-To: <20130119214921.GE4009@elie.Belkin>
Jonathan Nieder <jrnieder@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/
^ permalink raw reply
* Re: Aw: [PATCH 0/2] GIT, Git, git
From: Thomas Rast @ 2013-01-20 11:56 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <304952858.714413.1358671123163.JavaMail.ngmail@webmail06.arcor-online.net>
Thomas Ackermann <th.acker@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
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: John Keeping @ 2013-01-20 12:58 UTC (permalink / raw)
To: Chris Rorvick; +Cc: git
In-Reply-To: <1357878439-27500-1-git-send-email-chris@rorvick.com>
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
^ permalink raw reply
* [PATCH v3 0/8] Python 3 support for git_remote_helpers
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
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
^ permalink raw reply
* [PATCH v3 1/8] git_remote_helpers: Allow building with Python 3
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@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
^ permalink raw reply related
* [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@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
^ permalink raw reply related
* [PATCH v3 3/8] git_remote_helpers: Force rebuild if python version changes
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@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
^ permalink raw reply related
* [PATCH v3 4/8] git_remote_helpers: Use 2to3 if building with Python 3
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@keeping.me.uk>
Acked-by: Sverre Rabbelier <srabbelier@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 <srabbelier@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
^ permalink raw reply related
* [PATCH v3 5/8] svn-fe: allow svnrdump_sim.py to run with Python 3
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@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 < 0x02040000:
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
^ permalink raw reply related
* [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@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 < 0x02000000:
+ # 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
^ permalink raw reply related
* [PATCH v3 7/8] git-remote-testpy: don't do unbuffered text I/O
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@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
^ permalink raw reply related
* [PATCH v3 8/8] git-remote-testpy: call print as a function
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 <john@keeping.me.uk>
Acked-by: Sverre Rabbelier <srabbelier@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
^ permalink raw reply related
* git interactive rebase 'consume' command
From: Stephen Kelly @ 2013-01-20 14:05 UTC (permalink / raw)
To: git
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.
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: John Keeping @ 2013-01-20 14:17 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <kdgtir$apt$1@ger.gmane.org>
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
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: Stephen Kelly @ 2013-01-20 14:23 UTC (permalink / raw)
To: git
In-Reply-To: <20130120141725.GL31172@serenity.lan>
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.
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-20 15:22 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130120125838.GK31172@serenity.lan>
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping <john@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
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: John Keeping @ 2013-01-20 15:28 UTC (permalink / raw)
To: Chris Rorvick; +Cc: git
In-Reply-To: <CAEUsAPZKd+mw2iK7nd6rTtB8N+B99ud19FkuSx0HVitNxrxxZA@mail.gmail.com>
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping <john@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
^ permalink raw reply
* Re: [PATCH v3] am: invoke perl's strftime in C locale
From: Junio C Hamano @ 2013-01-20 17:47 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Jeff King, Antoine Pelisse, git
In-Reply-To: <20130119202853.GD1652@altlinux.org>
"Dmitry V. Levin" <ldv@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...
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-20 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: git, spearce, mfick
In-Reply-To: <20130119165042.GB12307@sigill.intra.peff.net>
Jeff King <peff@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.
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-20 18:19 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, spearce, mfick
In-Reply-To: <7v38xxnfv3.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Duy Nguyen <pclouds@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.
^ permalink raw reply
* Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Junio C Hamano @ 2013-01-20 18:33 UTC (permalink / raw)
To: David Aguilar; +Cc: Thomas Ackermann, git
In-Reply-To: <CAJDDKr5_AWFF6MR2Kwt5FzA0vaSE-wx8xFO3xcRnKZ168hXBrg@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann <th.acker@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?
^ permalink raw reply
* Re: [PATCH] unpack-trees: do not abort when overwriting an existing file with the same content
From: Junio C Hamano @ 2013-01-20 18:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1358594648-26851-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@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);
> }
^ permalink raw reply
* Re: [RFC] git rm -u
From: Junio C Hamano @ 2013-01-20 18:42 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky
In-Reply-To: <vpq622s9jk1.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@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?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox