From: Junio C Hamano <hidden> Date: 2016-06-15 22:50:38
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
--------------------------------------------------
[New Topics]
* ab/i18n (2011-02-22) 73 commits
- i18n: git-shortlog basic messages
- i18n: git-revert split up "could not revert/apply" message
- i18n: git-revert literal "me" messages
- i18n: git-revert "Your local changes" message
- i18n: git-revert basic messages
- i18n: git-notes GIT_NOTES_REWRITE_MODE error message
- i18n: git-notes basic commands
- i18n: git-gc "Auto packing the repository" message
- i18n: git-gc basic messages
- i18n: git-describe basic messages
- i18n: git-clean clean.requireForce messages
- i18n: git-clean basic messages
- i18n: git-bundle basic messages
- i18n: git-archive basic messages
- i18n: git-status "renamed: " message
- i18n: git-status "Initial commit" message
- i18n: git-status "Changes to be committed" message
- i18n: git-status shortstatus messages
- i18n: git-status "nothing to commit" messages
- i18n: git-status basic messages
- i18n: git-push "prevent you from losing" message
- i18n: git-push basic messages
- i18n: git-tag tag_template message
- i18n: git-tag basic messages
- i18n: git-reset "Unstaged changes after reset" message
- i18n: git-reset reset_type_names messages
- i18n: git-reset basic messages
- i18n: git-rm basic messages
- i18n: git-mv "bad" messages
- i18n: git-mv basic messages
- i18n: git-merge "Wonderful" message
- i18n: git-merge "You have not concluded your merge" messages
- i18n: git-merge "Updating %s..%s" message
- i18n: git-merge basic messages
- i18n: git-log "--OPT does not make sense" messages
- i18n: git-log basic messages
- i18n: git-grep "--open-files-in-pager" message
- i18n: git-grep basic messages
- i18n: git-fetch split up "(non-fast-forward)" message
- i18n: git-fetch update_local_ref messages
- i18n: git-fetch formatting messages
- i18n: git-fetch basic messages
- i18n: git-diff basic messages
- i18n: git-commit advice messages
- i18n: git-commit "enter the commit message" message
- i18n: git-commit print_summary messages
- i18n: git-commit formatting messages
- i18n: git-commit "middle of a merge" message
- i18n: git-commit basic messages
- i18n: git-checkout "Switched to a .. branch" message
- i18n: git-checkout "HEAD is now at" message
- i18n: git-checkout describe_detached_head messages
- i18n: git-checkout: our/their version message
- i18n: git-checkout basic messages
- i18n: git-branch "(no branch)" message
- i18n: git-branch "git branch -v" messages
- i18n: git-branch "Deleted branch [...]" message
- i18n: git-branch "remote branch '%s' not found" message
- i18n: git-branch basic messages
- i18n: git-add "Unstaged changes" message
- i18n: git-add "remove '%s'" message
- i18n: git-add "did not match any files" message
- i18n: git-add "The following paths are ignored" message
- i18n: git-add basic messages
- i18n: git-clone "Cloning into" message
- i18n: git-clone "Cloning into" message
- i18n: git-clone basic messages
- i18n: git-init "Initialized [...] repository" message
- i18n: git-init basic messages
- i18n: Makefile: "pot" target to extract messages marked for translation
- i18n: do not poison translations unless GIT_GETTEXT_POISON envvar is set
- i18n: add GETTEXT_POISON to simulate translated messages unfriendly translator
- i18n: add no-op _() and N_() wrappers
Re^4-roll, coordinated between Ævar and Jonathan.
I'd like to fast-track the basics (especially the bottom 3 patches), and
am even tempted to rebase other patches on 'pu' that are not yet in 'next'
on top of them, to make the transition easier, so please lend extra sets
of eyeballs on an earlier ones to make sure they are sane (I thought they
were, but I am far from perfect).
* gr/cvsimport-alternative-cvspass-location (2011-02-18) 1 commit
- Look for password in both CVS and CVSNT password files.
* jc/checkout-orphan-warning (2011-02-18) 1 commit
- commit: give final warning when reattaching HEAD to leave commits behind
Likes, dislikes?
* jh/maint-do-not-track-non-branches (2011-02-17) 1 commit
- branch/checkout --track: Ensure that upstream branch is indeed a branch
This supersedes "do not track HEAD" from Thomas.
* jk/diffstat-binary (2011-02-19) 2 commits
(merged to 'next' on 2011-02-23 at 49da967)
+ diff: don't retrieve binary blobs for diffstat
+ diff: handle diffstat of rewritten binary files
* jk/fail-null-clone (2011-02-17) 1 commit
(merged to 'next' on 2011-02-23 at a4217f5)
+ clone: die when trying to clone missing local path
* jk/merge-rename-ux (2011-02-20) 6 commits
- pull: propagate --progress to merge
- merge: enable progress reporting for rename detection
- add inexact rename detection progress infrastructure
- commit: stop setting rename limit
- bump rename limit defaults (again)
- merge: improve inexact rename limit warning
The above three all seemed sensible improvements.
* jn/test-terminal-punt-on-osx-breakage (2011-02-17) 1 commit
(merged to 'next' on 2011-02-23 at d754139)
+ tests: skip terminal output tests on OS X
* js/cherry-pick-usability (2011-02-19) 4 commits
(merged to 'next' on 2011-02-23 at 95db30e)
+ Teach commit about CHERRY_PICK_HEAD
+ bash: teach __git_ps1 about CHERRY_PICK_HEAD
+ Introduce CHERRY_PICK_HEAD
+ t3507: introduce pristine-detach helper
* js/detach-doc (2011-02-20) 1 commit
(merged to 'next' on 2011-02-21 at c384c3c)
+ git-checkout.txt: improve detached HEAD documentation
* lt/rename-no-extra-copy-detection (2011-02-18) 3 commits
(merged to 'next' on 2011-02-23 at 2c1f271)
+ diffcore-rename: improve estimate_similarity() heuristics
+ diffcore-rename: properly honor the difference between -M and -C
+ for_each_hash: allow passing a 'void *data' pointer to callback
* mg/rev-list-one-side-only (2011-02-22) 6 commits
- t6007: test rev-list --cherry
- log --cherry: a synonym
- rev-list: --left/right-only are mutually exclusive
- rev-list: documentation and test for --left/right-only
- t6007: Make sure we test --cherry-pick
- revlist.c: introduce --left/right-only for unsymmetric picking
* so/submodule-no-update-first-time (2011-02-17) 2 commits
(merged to 'next' on 2011-02-23 at 2c6e8c9)
+ t7406: "git submodule update {--merge|--rebase]" with new submodules
+ submodule: no [--merge|--rebase] when newly cloned
* va/p4 (2011-02-20) 2 commits
(merged to 'next' on 2011-02-21 at d981b23)
+ git-p4: Add copy detection support
+ git-p4: Improve rename detection support
* jc/complete-symmetric-diff (2011-02-23) 1 commit
- completion: complete "git diff ...branc<TAB>"
* jh/submodule-fetch-on-demand (2011-02-23) 6 commits
- submodule update: Don't fetch when the submodule commit is already present
- fetch/pull: Don't recurse into a submodule when commits are already present
- Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option
- config: teach the fetch.recurseSubmodules option the 'on-demand' value
- fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
- fetch/pull: recurse into submodules when necessary
* jk/format-patch-multiline-header (2011-02-23) 2 commits
- format-patch: wrap long header lines
- strbuf: add fixed-length version of add_wrapped_text
* cp/mergetool-beyondcompare (2011-02-18) 1 commit
- mergetool--lib: add support for beyond compare
May want to have an independent success report on Windows.
--------------------------------------------------
[Stalled]
* jh/merge-sans-branch (2011-02-10) 4 commits
. merge: add support for merging from upstream by default
- merge: introduce per-branch-configuration helper function
- merge: introduce setup_merge_commit helper function
- merge: update the usage information to be more modern
There was an objection to the tip one that determines the upstream in a
wrong way?
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
* jc/rename-degrade-cc-to-c (2011-01-06) 3 commits
. diffcore-rename: fall back to -C when -C -C busts the rename limit
. diffcore-rename: record filepair for rename src
. diffcore-rename: refactor "too many candidates" logic
* nd/index-doc (2010-09-06) 1 commit
. doc: technical details about the index file format
--------------------------------------------------
[Cooking]
* js/checkout-untracked-symlink (2011-02-20) 2 commits
(merged to 'next' on 2011-02-23 at 52a35ce)
+ do not overwrite untracked symlinks
+ Demonstrate breakage: checkout overwrites untracked symlink with directory
* pw/p4 (2011-02-19) 8 commits
(merged to 'next' on 2011-02-21 at 1a7b7d2)
+ git-p4: support clone --bare
+ git-p4: decode p4 wildcard characters
+ git-p4: better message for "git-p4 sync" when not cloned
+ git-p4: reinterpret confusing p4 message
+ git-p4: accommodate new move/delete type in p4
+ git-p4: add missing newline in initial import message
+ git-p4: fix key error for p4 problem
+ git-p4: test script
* jh/push-default-upstream-configname (2011-02-16) 1 commit
(merged to 'next' on 2011-02-23 at b5c25fa)
+ push.default: Rename 'tracking' to 'upstream'
This is not "renaming" in the sense that breaks existing practice, but
giving a new official name and deprecating the existing one.
* js/maint-merge-use-prepare-commit-msg-hook (2011-02-14) 1 commit
(merged to 'next' on 2011-02-22 at 6458c4b)
+ merge: honor prepare-commit-msg hook
* mg/patch-id (2011-02-17) 2 commits
(merged to 'next' on 2011-02-22 at 6f4acd8)
+ git-patch-id: do not trip over "no newline" markers
+ git-patch-id: test for "no newline" markers
* mg/placeholders-are-lowercase (2011-02-17) 5 commits
(merged to 'next' on 2011-02-22 at 2754e21)
+ Make <identifier> lowercase in Documentation
+ Make <identifier> lowercase as per CodingGuidelines
+ Make <identifier> lowercase as per CodingGuidelines
+ Make <identifier> lowercase as per CodingGuidelines
+ CodingGuidelines: downcase placeholders in usage messages
* mo/perl-bidi-pipe-envfix (2011-02-15) 1 commit
(merged to 'next' on 2011-02-15 at c36e816)
+ perl: command_bidi_pipe() method should set-up git environmens
Looked reasonable.
* nd/sorted-builtin-command-list (2011-02-15) 1 commit
(merged to 'next' on 2011-02-22 at 91fccd1)
+ git.c: reorder builtin command list
* sp/maint-smart-http-sans-100-continue (2011-02-15) 1 commit
(merged to 'next' on 2011-02-15 at 553e3e5)
+ smart-http: Don't use Expect: 100-Continue
* jc/grep--no-index-pathspec-fix (2011-02-16) 1 commit
(merged to 'next' on 2011-02-23 at 58b03b1)
+ grep --no-index: honor pathspecs correctly
(this branch uses nd/struct-pathspec; is tangled with en/object-list-with-pathspec.)
* mz/rebase (2011-02-09) 32 commits
(merged to 'next' on 2011-02-22 at 3219155)
+ rebase: use @{upstream} if no upstream specified
+ rebase -i: remove unnecessary state rebase-root
+ rebase -i: don't read unused variable preserve_merges
+ git-rebase--am: remove unnecessary --3way option
+ rebase -m: don't print exit code 2 when merge fails
+ rebase -m: remember allow_rerere_autoupdate option
+ rebase: remember strategy and strategy options
+ rebase: remember verbose option
+ rebase: extract code for writing basic state
+ rebase: factor out sub command handling
+ rebase: make -v a tiny bit more verbose
+ rebase -i: align variable names
+ rebase: show consistent conflict resolution hint
+ rebase: extract am code to new source file
+ rebase: extract merge code to new source file
+ rebase: remove $branch as synonym for $orig_head
+ rebase -i: support --stat
+ rebase: factor out call to pre-rebase hook
+ rebase: factor out clean work tree check
+ rebase: factor out reference parsing
+ rebase: reorder validation steps
+ rebase -i: remove now unnecessary directory checks
+ rebase: factor out command line option processing
+ rebase: align variable content
+ rebase: align variable names
+ rebase: stricter check of standalone sub command
+ rebase: act on command line outside parsing loop
+ rebase: improve detection of rebase in progress
+ rebase: remove unused rebase state 'prev_head'
+ rebase: read state outside loop
+ rebase: refactor reading of state
+ rebase: clearer names for directory variables
Minor UI regression was reported but otherwise it looked like that the
topic is in a good shape.
* lp/config-vername-check (2011-02-01) 2 commits
(merged to 'next' on 2011-02-23 at 426d48d)
+ Disallow empty section and variable names
+ Sanity-check config variable names
* mz/rerere-remaining (2011-02-16) 2 commits
(merged to 'next' on 2011-02-22 at fa2d5ab)
+ mergetool: don't skip modify/remove conflicts
+ rerere "remaining"
Looked much better than my weatherbaloon patch.
* nd/hash-object-sanity (2011-02-05) 1 commit
(merged to 'next' on 2011-02-22 at 09acf6f)
+ Make hash-object more robust against malformed objects
* hv/mingw-fs-funnies (2011-02-07) 5 commits
(merged to 'next' on 2011-02-09 at 3d0bb1a)
+ mingw_rmdir: set errno=ENOTEMPTY when appropriate
+ mingw: add fallback for rmdir in case directory is in use
+ mingw: make failures to unlink or move raise a question
+ mingw: work around irregular failures of unlink on windows
+ mingw: move unlink wrapper to mingw.c
Rerolled and seems ready to move forward.
* nd/struct-pathspec (2011-01-31) 22 commits
(merged to 'next' on 2011-02-09 at b1e64ee)
+ t6004: add pathspec globbing test for log family
+ t7810: overlapping pathspecs and depth limit
+ grep: drop pathspec_matches() in favor of tree_entry_interesting()
+ grep: use writable strbuf from caller for grep_tree()
+ grep: use match_pathspec_depth() for cache/worktree grepping
+ grep: convert to use struct pathspec
+ Convert ce_path_match() to use match_pathspec_depth()
+ Convert ce_path_match() to use struct pathspec
+ struct rev_info: convert prune_data to struct pathspec
+ pathspec: add match_pathspec_depth()
+ tree_entry_interesting(): optimize wildcard matching when base is matched
+ tree_entry_interesting(): support wildcard matching
+ tree_entry_interesting(): fix depth limit with overlapping pathspecs
+ tree_entry_interesting(): support depth limit
+ tree_entry_interesting(): refactor into separate smaller functions
+ diff-tree: convert base+baselen to writable strbuf
+ glossary: define pathspec
+ Move tree_entry_interesting() to tree-walk.c and export it
+ tree_entry_interesting(): remove dependency on struct diff_options
+ Convert struct diff_options to use struct pathspec
+ diff-no-index: use diff_tree_setup_paths()
+ Add struct pathspec
(this branch is used by en/object-list-with-pathspec and jc/grep--no-index-pathspec-fix.)
* en/object-list-with-pathspec (2010-09-20) 2 commits
(merged to 'next' on 2011-02-09 at ccf6c6a)
+ Add testcases showing how pathspecs are handled with rev-list --objects
+ Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec; is tangled with jc/grep--no-index-pathspec-fix.)
* uk/checkout-ambiguous-ref (2011-02-15) 5 commits
(merged to 'next' on 2011-02-15 at 645dad6)
+ Rename t2019 with typo "amiguous" that meant "ambiguous"
+ checkout: rearrange update_refs_for_switch for clarity
+ checkout: introduce --detach synonym for "git checkout foo^{commit}"
+ checkout: split off a function to peel away branchname arg
(merged to 'next' on 2011-02-03 at 9044724)
+ checkout: fix bug with ambiguous refs
The topic has become about "checkout --detach" ;-).
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:50:38
Junio C Hamano wrote:
* ab/i18n (2011-02-22) 73 commits
[...]
- i18n: do not poison translations unless GIT_GETTEXT_POISON envvar is set
- i18n: add GETTEXT_POISON to simulate translated messages unfriendly translator
- i18n: add no-op _() and N_() wrappers
Re^4-roll, coordinated between Ævar and Jonathan.
I'd like to fast-track the basics (especially the bottom 3 patches), and
am even tempted to rebase other patches on 'pu' that are not yet in 'next'
on top of them, to make the transition easier, so please lend extra sets
of eyeballs on an earlier ones to make sure they are sane (I thought they
were, but I am far from perfect).
The commit message for the second one seems to have been mangled:
i18n: add GETTEXT_POISON to simulate translated messages unfriendly translator
Before, it said "simulate unfriendly translator", as in "turn on this
option to see what the translator from hell could do to your program".
(Well, it's not _that_ bad because it takes out format strings.)
I still don't like the #-sign business in this commit. Couldn't it
be split into a separate patch, not to be applied until just before
the strings in commit/tag/wt-status are marked for translation?
There is also a patch out there to make this use rot13, which I am
somewhat fond of. Unfortunately, it leaks (because it is not clear
how long translated strings are supposed to last).
I'd be happy with renaming use_poison() to gettext_poison() or
similar. I suppose that is not urgent.
Regards,
Jonathan
From: Johan Herland <hidden> Date: 2016-06-15 22:50:38
On Thursday 24 February 2011, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with '-'
are only in 'pu' while commits prefixed with '+' are in 'next'.
[...]
* jh/maint-do-not-track-non-branches (2011-02-17) 1 commit
- branch/checkout --track: Ensure that upstream branch is indeed a
branch
This supersedes "do not track HEAD" from Thomas.
What do you mean by "supersedes"? It builds on top of Thomas' patch (v2 was
rebased on top it), but it does not _replace_ Thomas' patch.
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
On Thu, Feb 24, 2011 at 00:26, Junio C Hamano [off-list ref] wrote:
* ab/i18n (2011-02-22) 73 commits
[...]
Re^4-roll, coordinated between Ævar and Jonathan.
I'd like to fast-track the basics (especially the bottom 3 patches), and
am even tempted to rebase other patches on 'pu' that are not yet in 'next'
on top of them, to make the transition easier, so please lend extra sets
of eyeballs on an earlier ones to make sure they are sane (I thought they
were, but I am far from perfect).
Great that we're moving this forward. After this has made it to next
(or master) I'm going to fix this up a bit and submit the shellscript
i18n-ize patches:
https://github.com/avar/git/compare/5bd8b10...8fd2407
Open issues:
* Write documentation for git-sh-i18n.sh and git-sh-i18n--envsubst
like we have for git-sh-setup (already in WIP form).
* git-sh-i18n--envsubst is still too fat:
$ ldd -r git-sh-i18n--envsubst
linux-vdso.so.1 => (0x00007fffc60fd000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f25cff9e000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
(0x00007f25cfbfd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f25cf9e0000)
libc.so.6 => /lib/libc.so.6 (0x00007f25cf67f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f25cf47b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f25d01c0000)
It only needs to link to libc, but I didn't find out when I last
checked how to convince the Makefile to only link against
that. Help welcome :)
* Deal with the changes in 92c62a3f4f93432c0c82e3031a9e64e03ba290f7:
$ git --no-pager grep -A1 abomination *.sh
git-pull.sh: # XXX: This is an abomination
git-pull.sh- require_clean_work_tree "pull with
rebase" "Please commit or stash them."
The changes Ramkumar Ramachandra made in 92c62a3f4f, while good,
are hard to square with i18n.
I think I'll just leave those bits untranslated for now and deal
with them later, since I'm trying to keep this minimal.
And then there's the issue that unlike the C patches these will not be
a no-op that'll be optimized away by the compiler. We'll be calling an
external program for displaying messages. While this is a trivial cost
on Unix (especially in the context we're using it, i.e. not in tight
loops) it's more expensive on Windows.
I don't see any way to deal with that short of implementing some
pre-processor, but I think the cost is worth it, but others might
disagree of course.
Anyway, I can submit these patches (around 53) real soon, or wait
until the current series settles. It's the same to me, which would you
prefer?
* gr/cvsimport-alternative-cvspass-location (2011-02-18) 1 commit
- Look for password in both CVS and CVSNT password files.
Given that this solves someone's problem I don't think there's any
harm in letting it through. The code and overall behavior is somewhat
nasty, but then so is the rest of git-cvs*.perl, so meh.
* jc/checkout-orphan-warning (2011-02-18) 1 commit
- commit: give final warning when reattaching HEAD to leave commits behind
I like this sort of thing.
Generally speaking I don't mind Git being more friendly and verbose
about this sort of thing. I.e. for common pitfalls print a few lines
of help because it'll help more than it hurts. I think we've been to
conservative about that in the past.
There's a grammar error here though if I'm not mistaken:
w git ((f11f53c...) $%) $ ./git co pu
Warning: you are leaving 1 commit behind that are not connected to
any of your branches:
For the singular this should be "1 commit behind which is not
corrected to any of your branches".
We're also being somewhat inaccurate by omission here, since we won't
give this warning if the commit is reachable from any named referenc,
i.e. if the user just tagged it. So perhaps this should say something
about "not reachable from any named reference" or something, but then
again that would confuse the sort of users that need this the most.
* jh/maint-do-not-track-non-branches (2011-02-17) 1 commit
- branch/checkout --track: Ensure that upstream branch is indeed a branch
* jn/test-terminal-punt-on-osx-breakage (2011-02-17) 1 commit
(merged to 'next' on 2011-02-23 at d754139)
+ tests: skip terminal output tests on OS X
Looks good, and maybe I'll debug the Perl one of these days.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
I really like this as noted elsewhere. But it seems that it would go
down better if the helper was submitted later on.
* jh/push-default-upstream-configname (2011-02-16) 1 commit
(merged to 'next' on 2011-02-23 at b5c25fa)
+ push.default: Rename 'tracking' to 'upstream'
This is not "renaming" in the sense that breaks existing practice, but
giving a new official name and deprecating the existing one.
I like the new name.
* mo/perl-bidi-pipe-envfix (2011-02-15) 1 commit
(merged to 'next' on 2011-02-15 at c36e816)
+ perl: command_bidi_pipe() method should set-up git environmens
Looked reasonable.
Yeah, but fix up the typo in the subject. Should be "environments" :)
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:50:39
On Thu, Feb 24, 2011 at 1:32 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
And then there's the issue that unlike the C patches these will not be
a no-op that'll be optimized away by the compiler. We'll be calling an
external program for displaying messages. While this is a trivial cost
on Unix (especially in the context we're using it, i.e. not in tight
loops) it's more expensive on Windows.
Ouch. I remember this being brought up earlier, but I just assumed it
had been fixed somehow. The shell-scripts are already pretty slow on
Windows, and the overhead of starting a new process here is quite
significant.
It sounds to me like we should revert these patches in msysGit, at
least until there's some actual translations in place (and that time
actually goes into something useful)...
I don't see any way to deal with that short of implementing some
pre-processor, but I think the cost is worth it, but others might
disagree of course.
I'm not so sure. This is mostly a problem with the no-op version on
Windows (due to the slow process-startup there), but I think Git for
Windows probably wants to have i18n support in it's distribution as it
strives to be the canonical Git-distribution for Windows. But if we
do, there's nothing to optimize. There's no no-op-stuff, and we need
to spend that time getting translations.
It might be that some people that build Git for Windows themselves and
know that they don't want a translated Git could benefit from a
pre-processor, but I'm not so sure. Translated strings occur when
there's communication going on between Git and the user, and then
we're some times waiting for user-input, and even when we aren't it
should be relatively few messages (unless verbose flags are turned on,
which isn't an important use-case performance-wise to me).
Anyway, I can submit these patches (around 53) real soon, or wait
until the current series settles. It's the same to me, which would you
prefer?
If we're going to revert these patches in 4msysgit.git, then I can
imagine that the process becomes very awkward and error-prone if we're
going to diverge for a long time. So I think it'd make more sense for
us (the msysgit-developers, that is) if it was merged together with
the first translations. But that might be sub-optimal for the rest of
you guys.
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:50:39
On Thu, Feb 24, 2011 at 12:48 AM, Jonathan Nieder [off-list ref] wrote:
There is also a patch out there to make this use rot13, which I am
somewhat fond of. Unfortunately, it leaks (because it is not clear
how long translated strings are supposed to last).
I like the idea, but perhaps we could auto-generate a Pig Latin
translation or something instead? Pig Latin has the benefit over
rot-13 of the strings being of a different length than the original,
which might trigger some bugs that same-length translations might
not...
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:50:39
Erik Faye-Lund wrote:
I like the idea, but perhaps we could auto-generate a Pig Latin
translation or something instead?
Sorry for the fuss. If I understand correctly, the remaining
issues with the current ab/i18n branch in 'pu' are:
* The series is too long to read in one sitting.
Suggested fix: deal with some arbitrary early subset (35 patches?
I'd even prefer around 20) first.
* Patch 2 (add GETTEXT_POISON) is conceptually complicated since
its arbitrary string is not arbitrary.
Suggested fix: split it into two patches. But I am still not sure
if that's considered acceptable?
* Patch 2 squats on a valuable use_poison() identifier space.
Suggested fix: rename it to gettext_poison().
* Patches 5 (i18n: git-init basic messages) and onward do not
explain "we are marking strings for translation, in
preparation for translating them later" in their commit messages.
Suggested fix: use titles like «i18n: mark some "git init" messages
for translation». Or ignore the problem --- it's not a big deal.
* We haven't run an automated tool to check that this is a no-op
in the -UGETTEXT_POISON case.
Suggested fix: build without debugging symbols and compare the
binaries. Or invent a tool to check patches. Or just use our
eyes, like we always have.
Does that sound like a fair summary? I'd be happy to reroll the
first 30 or so patches following whatever approach is the consensus
for these things to move this forward.
On Thu, Feb 24, 2011 at 10:56, Erik Faye-Lund [off-list ref] wrote:
On Thu, Feb 24, 2011 at 12:48 AM, Jonathan Nieder [off-list ref] wrote:
quoted
There is also a patch out there to make this use rot13, which I am
somewhat fond of. Unfortunately, it leaks (because it is not clear
how long translated strings are supposed to last).
I like the idea, but perhaps we could auto-generate a Pig Latin
translation or something instead? Pig Latin has the benefit over
rot-13 of the strings being of a different length than the original,
which might trigger some bugs that same-length translations might
not...
On Thu, Feb 24, 2011 at 10:45, Erik Faye-Lund [off-list ref] wrote:
On Thu, Feb 24, 2011 at 1:32 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
And then there's the issue that unlike the C patches these will not be
a no-op that'll be optimized away by the compiler. We'll be calling an
external program for displaying messages. While this is a trivial cost
on Unix (especially in the context we're using it, i.e. not in tight
loops) it's more expensive on Windows.
Ouch. I remember this being brought up earlier, but I just assumed it
had been fixed somehow. The shell-scripts are already pretty slow on
Windows, and the overhead of starting a new process here is quite
significant.
It sounds to me like we should revert these patches in msysGit, at
least until there's some actual translations in place (and that time
actually goes into something useful)...
IIRC last time this was discussed I asked whether the size of the
binary mattered for execution startup time (i.e. more so than on
Unix). We're only invoking printf(1) and git-sh-i18n--envsubst, both
of which only are (or only need to be) linked to libc.
It would also be interesting to have some real world benchmarks on
Windows with and without this series, maybe it won't be so bad.
I think in the long term we probably want to rewrite the remaining
*.sh programs in C anyway.
quoted
I don't see any way to deal with that short of implementing some
pre-processor, but I think the cost is worth it, but others might
disagree of course.
I'm not so sure. This is mostly a problem with the no-op version on
Windows (due to the slow process-startup there), but I think Git for
Windows probably wants to have i18n support in it's distribution as it
strives to be the canonical Git-distribution for Windows. But if we
do, there's nothing to optimize. There's no no-op-stuff, and we need
to spend that time getting translations.
It might be that some people that build Git for Windows themselves and
know that they don't want a translated Git could benefit from a
pre-processor, but I'm not so sure. Translated strings occur when
there's communication going on between Git and the user, and then
we're some times waiting for user-input, and even when we aren't it
should be relatively few messages (unless verbose flags are turned on,
which isn't an important use-case performance-wise to me).
quoted
Anyway, I can submit these patches (around 53) real soon, or wait
until the current series settles. It's the same to me, which would you
prefer?
If we're going to revert these patches in 4msysgit.git, then I can
imagine that the process becomes very awkward and error-prone if we're
going to diverge for a long time. So I think it'd make more sense for
us (the msysgit-developers, that is) if it was merged together with
the first translations. But that might be sub-optimal for the rest of
you guys.
If it comes to that it'll be easier to have some perl script that
converts C<"$(eval_gettext "foobar: \$whatever")"> back to C<"foobar:
$whataver"> at build time than revert the patches.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:50:39
Ævar Arnfjörð Bjarmason wrote:
IIRC last time this was discussed I asked whether the size of the
binary mattered for execution startup time (i.e. more so than on
Unix). We're only invoking printf(1) and git-sh-i18n--envsubst, both
of which only are (or only need to be) linked to libc.
printf is usually built in to the shell. I think if we're very
careful about quoting shell metacharacters then we can get by using
eval in place of envsubst. See the message that
http://thread.gmane.org/gmane.comp.version-control.git/160396
is a reply to (which does not seem to have hit the ml; sorry about
that).
I hope preprocessing away the "eval" is not needed. :)
It would also be interesting to have some real world benchmarks on
Windows with and without this series, maybe it won't be so bad.
Yes, e.g. timing from running the rebase tests in the testsuite
might be interesting.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:50:39
Hi,
On Thu, 24 Feb 2011, Ævar Arnfjörð Bjarmason wrote:
I think in the long term we probably want to rewrite the remaining *.sh
programs in C anyway.
Good luck with that, and also the Perl programs (it's not so much the
technical side which I wish you luck with; the technical issues are
straight-forward :-)
Ciao,
Dscho
+Dscho
On Thu, Feb 24, 2011 at 10:45:33AM +0100, Erik Faye-Lund wrote:
On Thu, Feb 24, 2011 at 1:32 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
And then there's the issue that unlike the C patches these will not be
a no-op that'll be optimized away by the compiler. We'll be calling an
external program for displaying messages. While this is a trivial cost
on Unix (especially in the context we're using it, i.e. not in tight
loops) it's more expensive on Windows.
Ouch. I remember this being brought up earlier, but I just assumed it
had been fixed somehow. The shell-scripts are already pretty slow on
Windows, and the overhead of starting a new process here is quite
significant.
Three things:
[2] does not apply cleanly, so I am still desperately trying to find some
time to finish it off (the patches are to msys.git, not the 'msys' branch
of msysgit.git, so I had to find a quarter an hour in order to put them
there in the first place, taking up all the Git time budget I wanted to
allow myself for this week).
Further, I think that my beloved Shift+Insert will no longer work with
your [2].
And lastly, in [2] you claim that you cross-built msys-1.0.dll. I would
like to have a script doing that in msysgit.git.
Ciao,
Dscho
For [1] please do
git://repo.or.cz/msysgit/kirr.git ks/no-user32-in-msysdll # into msys
Kirill Smelkov (1):
msys.dll: Don't pull user32.dll & friends just to detect whether right alt should be used as meta
...n-t-pull-user32.dll-friends-just-to-detec.patch | 98 ++++++++++++++++++++
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 src/rt/patches/0011-msys.dll-Don-t-pull-user32.dll-friends-just-to-detec.patch
Three things:
[2] does not apply cleanly, so I am still desperately trying to find some
time to finish it off (the patches are to msys.git, not the 'msys' branch
of msysgit.git, so I had to find a quarter an hour in order to put them
there in the first place, taking up all the Git time budget I wanted to
allow myself for this week).
For [2] please do
git pull git://repo.or.cz/msysgit/kirr.git ks/xser32.dll # into devel
Kirill Smelkov (3):
hack: xser32.dll -- Fake user32.dll like stub (for sh.exe not to load user32.dll)
xser32.dll: Fake user32.dll like stub (for sh.exe not to load user32.dll)
hack: sh.exe -- link to xser32.dll instead of user32.dll
bin/sh.exe | Bin 567296 -> 567296 bytes
bin/xser32.dll | Bin 0 -> 4373 bytes
src/xser32/Makefile | 13 +++++++++++++
src/xser32/release.sh | 7 +++++++
src/xser32/xser32.c | 27 +++++++++++++++++++++++++++
5 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 bin/xser32.dll
create mode 100644 src/xser32/Makefile
create mode 100644 src/xser32/release.sh
create mode 100644 src/xser32/xser32.c
Further, I think that my beloved Shift+Insert will no longer work with
your [2].
Probably yes, but this is only an experiment to see whether sh.exe starts to be
really faster. For proper solution we'll need to patch bash to use msys's
/dev/clipboard, or link to user32 symbols lazily.
And lastly, in [2] you claim that you cross-built msys-1.0.dll. I would
like to have a script doing that in msysgit.git.
For [1] please do
git://repo.or.cz/msysgit/kirr.git ks/no-user32-in-msysdll # into msys
Too late. I already did the work.
quoted
Three things:
[2] does not apply cleanly, so I am still desperately trying to find some
time to finish it off (the patches are to msys.git, not the 'msys' branch
of msysgit.git, so I had to find a quarter an hour in order to put them
there in the first place, taking up all the Git time budget I wanted to
allow myself for this week).
For [2] please do
git pull git://repo.or.cz/msysgit/kirr.git ks/xser32.dll # into devel
Again, too late. I already did the work.
quoted
Further, I think that my beloved Shift+Insert will no longer work with
your [2].
Probably yes,
In my experiment after rebuilding msys-1.0.dll, it still works.
quoted
And lastly, in [2] you claim that you cross-built msys-1.0.dll. I
would like to have a script doing that in msysgit.git.
Thanks, I will try to find some time to test this next week.
The problem for now is that when I time /share/msysGit/run-tests.sh, there
is hardly any gain from your patches:
Old:
real 18m1.031s
user 6m17.861s
sys 19m25.257s
New:
real 17m54.500s
user 6m12.319s
sys 19m28.567s
Ciao,
Dscho
From: Sebastian Schuberth <hidden> Date: 2016-06-15 22:50:40
On 24.02.2011 00:26, Junio C Hamano wrote:
* cp/mergetool-beyondcompare (2011-02-18) 1 commit
- mergetool--lib: add support for beyond compare
Sorry for not responding earlier to this, but problems at my news
provider seem to have swallowed mails from several days, including the
original post of
http://marc.info/?l=git&m=129801656713478&w=2
A while ago, I had already proposed
http://marc.info/?l=git&m=129007741814521&w=2
I'm not entirely sure why it was ignored in the end, probably I did not
report back to have tested it in Linux.
A few things that I like better in my patch than in Chris':
- Beyond Compare is added as "bc3" instead of "bcompare", which is both
shorter and indicates that only version 3, not version 2, is supported.
- Chris seems to be missing the patch to git-gui/lib/mergetool.tcl
- To the best of my knownledge, the Beyond Compare executable is called
"BCompare" (note the case), that means even with the merge tool named
"bcompare" a translation step in git-mergetool--lib.sh should by
required (as done in my patch). Chris, as you seem to have tested ion
Linux, could you shed a light on this?
- Using dashes for the options to Beyond Compare is fine on Windows,
however, I believe the order of the files is wrong, although that might
be a bit subjective. For a 3-way merge the syntax is
BCompare.exe C:\Left.ext C:\Right.ext C:\Center.ext
So the file that should go to the center panel is specified last. AFAIK,
all other merge tools are called such that $BASE goes to the center.
This is why my patch specifies $BASE last.
Any more opinions? Chris, in case you'd agree to prefer my patch, I'd be
very grateful if you could test it on Linux.
For your convenience, I've rebased onto the current master and attached
the patch files.
--
Sebastian Schuberth
For [1] please do
git://repo.or.cz/msysgit/kirr.git ks/no-user32-in-msysdll # into msys
Too late. I already did the work.
Sorry for the confision. This one is ok to stay the way as you did it.
quoted
quoted
Three things:
[2] does not apply cleanly, so I am still desperately trying to find some
time to finish it off (the patches are to msys.git, not the 'msys' branch
of msysgit.git, so I had to find a quarter an hour in order to put them
there in the first place, taking up all the Git time budget I wanted to
allow myself for this week).
For [2] please do
git pull git://repo.or.cz/msysgit/kirr.git ks/xser32.dll # into devel
Again, too late. I already did the work.
Sorry again, but as done in my ks/xser32.dll this is not tied to msys,
so maybe better please pull my branch into devel instead?
quoted
quoted
Further, I think that my beloved Shift+Insert will no longer work with
your [2].
Probably yes,
In my experiment after rebuilding msys-1.0.dll, it still works.
Thanks, I will try to find some time to test this next week.
Please don't - it does not build out of the box from msysgit yet. I just
wanted to show it is not staying stale. When it is finished, I'll let
you know.
The problem for now is that when I time /share/msysGit/run-tests.sh, there
is hardly any gain from your patches:
Old:
real 18m1.031s
user 6m17.861s
sys 19m25.257s
New:
real 17m54.500s
user 6m12.319s
sys 19m28.567s
Did you patch sh.exe to link to xser32.dll instead of user32.dll?
This is important because even with rebuilt msys.dll, original sh.exe
still links to user32.dll and this hides all the effort put into
stripping user32.dll from msys.dll.
Also I can't say for sure (hope yet) how sh-intensitive git tests are,
but at least running configure for say gettext or whatever should be
visibly faster, at least on wine.
Thanks, I will try to find some time to test this next week.
Please don't - it does not build out of the box from msysgit yet. I just
wanted to show it is not staying stale. When it is finished, I'll let
you know.
@@ -0,0 +1,45 @@+From bcf492ef90d866cced91f6fd8f57fd0b4cd05691 Mon Sep 17 00:00:00 2001+From: Kirill Smelkov <kirr@mns.spb.ru>+Date: Fri, 25 Feb 2011 21:57:51 +0300+Subject: [PATCH] winsup/cygwin: Build with -fno-threadsafe-statics++msys is low-level enough to do it's own synchronisation when neccessary,+and also gcc3 does not seem to be implementing threadsafe statics, so+msys never used this mechanics.++But when compiled with gcc4, threadsafe statics are default - this adds+to code size, and also pulls __cxa_guard_acquire and __cxa_guard_release+from libstdc++.++Avoid it for compilers that understand threadsafe statics (gcc4). The+goal is to avoid libstdc++ dependency completly in the end.++See also:++http://lists.apple.com/archives/darwin-drivers/2005/May/msg00067.html+http://gcc.gnu.org/ml/libstdc++/2002-11/msg00279.html++Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>+---+msys/rt/src/winsup/Makefile.common | 5 ++++++1 files changed, 5 insertions(+), 0 deletions(-)++diff --git a/msys/rt/src/winsup/Makefile.common b/msys/rt/src/winsup/Makefile.common+index 78595d2..798c374 100644+--- a/msys/rt/src/winsup/Makefile.common++++ b/msys/rt/src/winsup/Makefile.common+@@ -99,6 +99,11 @@ CPP_TARGET_INCLUDE:=/usr/include/c++/3.2.2/i686-pc-msys+COMPILE_CXX:=$(CXX) $c -nostdinc++ $(ALL_CXXFLAGS) -I$(GCC_INCLUDE) \+ -I$(CPP_INCLUDE) -I$(CPP_TARGET_INCLUDE) \+ -fno-rtti -fno-exceptions++++# add -fno-threadsafe-statics if compiler supports it++COMPILE_CXX+=$(shell $(CXX) -fno-threadsafe-statics -c -xc++ /dev/null >/dev/null 2>&1 \++ && echo -fno-threadsafe-statics)+++COMPILE_CC:=$(CC) $c -nostdinc $(ALL_CFLAGS) -I$(GCC_INCLUDE)++vpath %.a $(cygwin_build):$(w32api_lib):$(newlib_build)/libc:$(newlib_build)/libm+-- +1.7.4.1.48.g5673d+
@@ -8,7 +8,26 @@ die () {cd"$(dirname"$0")"debug=-test"a$1"="a--debug"&&debug=t+cross=++whiletest$#!=0+do+case"$1"in+"--debug")+debug=t+;;++"--cross")+cross=t+;;+*)+die"Unknown option $1"+;;+esac++shift+done+debug_clean=test"$debug"="$(catdebug.txt2>/dev/null)"||debug_clean=techo"$debug">debug.txt
@@ -36,26 +55,143 @@ doi=$(($i+1))done-test-f/bin/cc.exe||lngcc.exe/bin/cc.exe||-die"Could not make sure that MSys cc is found instead of MinGW one"cdmsys/rt&&-release=MSYS-g$(gitshow-s--pretty=%hHEAD)&&-(exportMSYSTEM=MSYS&&-exportPATH=/bin:$PATH&&-(test-dbld||mkdirbld)&&-cdbld&&-DLL=i686-pc-msys/winsup/cygwin/new-msys-1.0.dll&&-(test-fMakefile&&test-z"$debug_clean"||-../src/configure--prefix=/usr)&&-(test-z"$debug"||perl-i.bak-pe's/-O2//g'$(find-nameMakefile))&&-(test-z"$debug_clean"||makeclean)&&-(make||test-f$DLL)&&-(test!-z"$debug"||strip$DLL)&&-rebase-b0x68000000$DLL&&-mv$DLL/bin/)&&-cd/&&-hash=$(githash-object-wbin/new-msys-1.0.dll)&&-gitupdate-index--cacheinfo100755$hashbin/msys-1.0.dll&&-gitcommit-s-m"Updated msys-1.0.dll to $release"&&-/share/msysGit/post-checkout-hookHEAD^HEAD1+release=MSYS-g$(gitshow-s--pretty=%hHEAD)||+die"Could not detect MSYS release"+++# build msys.dll in native win32/msys environment+release_native(){+test-f/bin/cc.exe||lngcc.exe/bin/cc.exe||+die"Could not make sure that MSys cc is found instead of MinGW one"++(exportMSYSTEM=MSYS&&+exportPATH=/bin:$PATH&&+(test-dbld||mkdirbld)&&+cdbld&&+DLL=i686-pc-msys/winsup/cygwin/new-msys-1.0.dll&&+(test-fMakefile&&test-z"$debug_clean"||+../src/configure--prefix=/usr)&&+(test-z"$debug"||perl-i.bak-pe's/-O2//g'$(find-nameMakefile))&&+(test-z"$debug_clean"||makeclean)&&+(make||test-f$DLL)&&+(test!-z"$debug"||strip$DLL)&&+rebase-b0x68000000$DLL&&+mv$DLL/bin/)&&+cd/&&+hash=$(githash-object-wbin/new-msys-1.0.dll)&&+gitupdate-index--cacheinfo100755$hashbin/msys-1.0.dll&&+gitcommit-s-m"Updated msys-1.0.dll to $release"&&+/share/msysGit/post-checkout-hookHEAD^HEAD1+}++# cross-build msys.dll+# XXX $debug not handled+# XXX $debug_clean not handled+release_cross(){+root=$(cd../../../../&&pwd)&&+w32api=$root/mingw/include&&+(+(test-dbld||mkdirbld)&&+cdbld++# this is the cross prefix for mingw gcc on Debian+X=i586-mingw32msvc++DLL=$X/winsup/cygwin/new-msys-1.0.dll++exportCC=$X-gcc+exportCXX=$X-g+++exportAR=$X-ar+exportAS=$X-as+exportRANLIB=$X-ranlib+exportLD=$X-ld+exportDLLTOOL=$X-dlltool+exportWINDRES=$X-windres+exportSTRIP=$X-strip++(+test-d$X||mkdir$X||die+cd$X++# strip0d config.sub in srctree+# Unfortunately I have to do this in scrtree, yes :( or else on linux configure says:+#+# configure: error: can not run+# .../config.sub+#+# and manually inspecting config.sub gives:+#+# $ ./config.sub+# bash: ./config.sub: /bin/sh^M: bad interpreter: No such file or directory+#+# this is better done in a patch, but git has problems applying+# patches with trailing ^M, and also it would be fragile to apply+# such patch from under msys. Another possibility would be to somehow+# fool configure to take config.sub from objtree, and yes, this can+# be done for newlib, but not for winsup/cygwin - the latter looks+# for aux files only in srctree.+#+# So be it - we'll dirty the tree a bit, but this is relatively+# harmles, since noone of us usually touches config.sub, and also+# even after stripping, it runs ok under msys.+ac_config_sub=../../src/config.sub+tmpfile=`mktemp-tstrip0d.XXXXXX`&&+tr-d'\015'<$ac_config_sub>$tmpfile&&+mv$tmpfile$ac_config_sub&&+chmod+x$ac_config_sub||+die"Could not tweak config.sub"++# shadow for needed libiberty bits+test-dlibiberty||+(echo">>> shadow libiberty ..."&&+mkdirlibiberty&&+ln-s-tlibiberty/../../../src/libiberty/{random,strsignal}.c&&+ln-s-tlibiberty/../../../src/include/{ansidecl,libiberty}.h+)||+die"Could not shadow libiberty"++test-fnewlib/Makefile||+(echo-e">>> configure newlib ...\n"&&+mkdir-pnewlib&&+cdnewlib&&++# NOTE i686-pc-cygwin here!+CPPFLAGS="-D__MSYS__"\+../../../src/newlib/configure\+--host=i686-pc-cygwin+)||+die"Could not cross-configure newlib"++test-fwinsup/cygwin/Makefile||+(echo-e"\n\n>>> configure winsup/cygwin ...\n"+mkdir-pwinsup/cygwin&&+cdwinsup/cygwin&&++# NOTE CFLAGS="-gstabs+ ..." is incompatible with wine loader+# -isystem mingw/include for w32api *.h files+CFLAGS="-O2 -D__MSYS__ -isystem $w32api"\+../../../../src/winsup/cygwin/configure\+--host=$X\+)||+die"Could not cross-configure winsup/cygwin"++make-Cnewlib||die"Could not build newlib"+make-Cwinsup/cygwin||die"Could not build msys.dll"+)&&++# TODO rebase $DLL (?)++mv$DLL$root/bin/msys-1.0.dll&&+cd$root&&+gitcommit-s-m"Updated msys-1.0.dll to cross-compiled $release"bin/msys-1.0.dll+)+}+++iftest-z"$cross";then+release_native+else+release_cross+fi
Thanks, I will try to find some time to test this next week.
Please don't - it does not build out of the box from msysgit yet. I
just wanted to show it is not staying stale. When it is finished, I'll
let you know.
Done. Please do
git pull git://repo.or.cz/msysgit/kirr.git ks/crossmsys # into msys
This is beautiful work. I will keep this as my candy tomorrow, because I
still have to finish something else (after which I want to provide myself
with some reward).
Ciao,
Dscho
From: Chris Packham <hidden> Date: 2016-06-15 22:50:40
On 26/02/11 23:24, Sebastian Schuberth wrote:
On 24.02.2011 00:26, Junio C Hamano wrote:
quoted
* cp/mergetool-beyondcompare (2011-02-18) 1 commit
- mergetool--lib: add support for beyond compare
Sorry for not responding earlier to this, but problems at my news
provider seem to have swallowed mails from several days, including the
original post of
http://marc.info/?l=git&m=129801656713478&w=2
A while ago, I had already proposed
http://marc.info/?l=git&m=129007741814521&w=2
I'm not entirely sure why it was ignored in the end, probably I did not
report back to have tested it in Linux.
Sorry that I missed it (I didn't really look too hard).
A few things that I like better in my patch than in Chris':
- Beyond Compare is added as "bc3" instead of "bcompare", which is both
shorter and indicates that only version 3, not version 2, is supported.
v2 isn't natively available for linux, although it works quite well
under wine. Either way you're quite correct that v2 is not much use as a
3-way merge tool. Trying to indicate v3 only make sense to me (at least
until they release a v4 :)
- Chris seems to be missing the patch to git-gui/lib/mergetool.tcl
Didn't know to add it, thanks for pointing it out. If my patch get's
picked up I'll include it in the next round.
- To the best of my knownledge, the Beyond Compare executable is called
"BCompare" (note the case), that means even with the merge tool named
"bcompare" a translation step in git-mergetool--lib.sh should by
required (as done in my patch). Chris, as you seem to have tested ion
Linux, could you shed a light on this?
In linux it's bcompare, although BCompare is the eventual executable
chrisp@laptop:~> rpm -q --filesbypkg bcompare
bcompare /usr/bin/bcompare
bcompare /usr/lib/beyondcompare/BCompare
Unfortunately /usr/bin/bcompare is a little more involved than a symlink
so for linux we need to call bcompare. Do we have a nice way of handling
this? We could just treat them completely separate but that seems a but
like sweeping the problem under the carpet.
- Using dashes for the options to Beyond Compare is fine on Windows,
Good to hear. I was meaning to fire up a vbox windows XP image to double
check but you've saved me the hassle.
however, I believe the order of the files is wrong, although that might
be a bit subjective. For a 3-way merge the syntax is
BCompare.exe C:\Left.ext C:\Right.ext C:\Center.ext
So the file that should go to the center panel is specified last. AFAIK,
all other merge tools are called such that $BASE goes to the center.
This is why my patch specifies $BASE last.
I actually prefer base on the left a-la kdiff3 and araxis (and from my
previous life as a clearcase user). I've since found that with beyond
compare it is a pain to take changes from the center version so I agree
with your suggestion. We should probably make use of the -title options
to remove ambiguity.
Any more opinions? Chris, in case you'd agree to prefer my patch, I'd be
very grateful if you could test it on Linux.
For your convenience, I've rebased onto the current master and attached
the patch files.
I'll give it a whirl when I get a chance. I suspect I'll need to handle
the BCompare/bcompare thing but that's not a huge issue.
From: Sebastian Schuberth <hidden> Date: 2016-06-15 22:50:40
On Sun, Feb 27, 2011 at 06:38, Chris Packham [off-list ref] wrote:
Sorry that I missed it (I didn't really look too hard).
No problem, at least this got me dig out my series again ;-)
3-way merge tool. Trying to indicate v3 only make sense to me (at least
until they release a v4 :)
True. In that case, read it as "Beyond Compare version 3 an up" ;-)
In linux it's bcompare, although BCompare is the eventual executable
chrisp@laptop:~> rpm -q --filesbypkg bcompare
bcompare /usr/bin/bcompare
bcompare /usr/lib/beyondcompare/BCompare
Ah, OK, being on Windows I just checked the TAR.GZ file, which does
not contain /usr/bin/bcompare (but bcompare.sh, which probably gets
installed by install.sh).
Unfortunately /usr/bin/bcompare is a little more involved than a symlink
so for linux we need to call bcompare. Do we have a nice way of handling
this? We could just treat them completely separate but that seems a but
like sweeping the problem under the carpet.
We could just call "bcompare" on Windows, too. As Windows is
case-insensitive, it will just work.
with your suggestion. We should probably make use of the -title options
to remove ambiguity.
Good idea, I'll look into this.
I'll give it a whirl when I get a chance. I suspect I'll need to handle
the BCompare/bcompare thing but that's not a huge issue.
You could probably just wait a few minutes until I have pushed out an
update for this patch.
--
Sebastian Schuberth
From: Sebastian Schuberth <hidden> Date: 2016-06-15 22:50:40
On Sun, Feb 27, 2011 at 11:57, Sebastian Schuberth [off-list ref] wrote:
quoted
with your suggestion. We should probably make use of the -title options
to remove ambiguity.
Good idea, I'll look into this.
Given that the -title options actually replace the display of the file
name (instead of displaying the title in addition), I'd prefer not to
make use of these options. In fact, the file names Git uses for
merging already contain "BASE", "LOCAL", "REMOTE", so there should be
no real need for additional titles, IMHO.
I'll push out the updated series now.
--
Sebastian Schuberth
Ah. I had to add -Wl,-kill-at to the LDFLAGS so it works.
See the ks/xser32 branch (and the ks/msys branch) of msysgit.git.
quoted
The problem for now is that when I time /share/msysGit/run-tests.sh,
there is hardly any gain from your patches:
Old:
real 18m1.031s
user 6m17.861s
sys 19m25.257s
New:
real 17m54.500s
user 6m12.319s
sys 19m28.567s
Did you patch sh.exe to link to xser32.dll instead of user32.dll?
Now I did, and the difference is quite noticable:
real 15m37.281s
user 5m6.934s
sys 15m53.911s
(Note that I did not spend time to increase the N, so there is no point in
putting a percentage on the difference.)
I wonder whether we could patch sh.exe so it loads user32.dll _lazily_
rather than using the xser32.dll hack?
(This would also fix the issue that I can no longer use Shift+Insert to
paste the clipboard into the Git Bash...)
Also I can't say for sure (hope yet) how sh-intensitive git tests are,
but at least running configure for say gettext or whatever should be
visibly faster, at least on wine.
They are pretty intensive, as they are shell scripts all over the place in
their own right. I fear, however, that the real problem (maybe not on
WINE, but with real Windows) is that sh.exe needs to provide too many
POSIX-like things when starting new processes.
I fear, further, that the only way to make things more efficient on
Windows is to get rid of the many exec() calls and do more things
in-process. (If this is true, JGit should kick msysGit's ass.) This would
not apply to the test suite, though, which needs to stay a shell script
suite.
But maybe I am wrong, and the performance is lost through memory
management and filesystem interaction.
Ciao,
Dscho
Ah. I had to add -Wl,-kill-at to the LDFLAGS so it works.
See the ks/xser32 branch (and the ks/msys branch) of msysgit.git.
Hm, strange how it used to work on my side :) but you are right, thanks.
quoted
quoted
The problem for now is that when I time /share/msysGit/run-tests.sh,
there is hardly any gain from your patches:
Old:
real 18m1.031s
user 6m17.861s
sys 19m25.257s
New:
real 17m54.500s
user 6m12.319s
sys 19m28.567s
Did you patch sh.exe to link to xser32.dll instead of user32.dll?
Now I did, and the difference is quite noticable:
real 15m37.281s
user 5m6.934s
sys 15m53.911s
This is on real windows, yes?
(Note that I did not spend time to increase the N, so there is no point in
putting a percentage on the difference.)
I wonder whether we could patch sh.exe so it loads user32.dll _lazily_
rather than using the xser32.dll hack?
(This would also fix the issue that I can no longer use Shift+Insert to
paste the clipboard into the Git Bash...)
The patch for bash would be simple enough to re-link it with user32.dll
`dlltool -y` 'ed (-y creates delay-load import lobrary), or simply to
patch lib/readline/kill.c to delay-load clipboard functions manually
here:
/* A special paste command for users of Cygnus's cygwin32. */
#if defined (__CYGWIN__)
#include <windows.h>
int
rl_paste_from_clipboard (count, key)
int count, key;
{
char *data, *ptr;
int len;
if (OpenClipboard (NULL) == 0)
return (0);
data = (char *)GetClipboardData (CF_TEXT);
if (data)
...
Now this is simple only after we have infrastructure for rebuilding bash
in place, and untill we don't, something like this could help in the
meantime (sorry, can't test it properly under wine):
---- 8< ----
From 92151fe8325aa8c39e1b77b9780ed562703ba008 Mon Sep 17 00:00:00 2001
From: Kirill Smelkov <redacted>
Date: Sat, 12 Mar 2011 15:20:19 +0300
Subject: [PATCH] xser32: be a delay-load proxy to real user32.dll
This way we'll hopefully make clipboard work in shell again. The proper
way is of course to rebuild sh.exe with user32 being `dlltool -y` 'ed.
Signed-off-by: Kirill Smelkov <redacted>
---
src/xser32/Makefile | 3 +-
src/xser32/release.sh | 2 +-
src/xser32/xser32.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 61 insertions(+), 5 deletions(-)
@@ -5,4 +5,4 @@ cd "$(dirname "$0")" && make&& install-m775xser32.dll$DEST&& gitadd$DEST&&-gitcommit-s-m"xser32.dll: Fake user32.dll like stub (for sh.exe not to load user32.dll)"$DEST+gitcommit-s-m"xser32.dll: Delay-load proxy to real user32.dll (for sh.exe not to load user32.dll on every call)"$DEST
@@ -1,22 +1,77 @@/* fake clipboard routines for sh.exe not to load user32.dll */#include<windef.h>+#include<stdarg.h>+#include<winbase.h>++staticHMODULEuser32;++staticvoiddie(constchar*msg)+{+constchar*p;+DWORDmsglen;+DWORDwritten;++/* hand-made strlen */+for(p=msg,msglen=0;*p;++p,++msglen)+;++WriteFile(GetStdHandle(STD_ERROR_HANDLE),msg,msglen,&written,0);+ExitProcess(1);+}++staticvoidimport_user32()+{+if(user32)+return;++user32=LoadLibrary("user32.dll");+if(!user32)+die("E: cannot load user32.dll\n");+}__declspec(dllexport)BOOLWINAPIOpenClipboard(HWNDhWndNewOwner){-returnFALSE;/* always fails */+staticBOOLWINAPI(*pOpenClipboard)(HWND);++if(!pOpenClipboard){+import_user32();+pOpenClipboard=GetProcAddress(user32,"OpenClipboard");+if(!pOpenClipboard)+die("E: cannot import OpenClipboard from user32.dll\n");+}++returnpOpenClipboard(hWndNewOwner);}__declspec(dllexport)BOOLWINAPICloseClipboard(void){-returnTRUE;/* ok */+staticBOOLWINAPI(*pCloseClipboard)(void);++if(!pCloseClipboard){+import_user32();+pCloseClipboard=GetProcAddress(user32,"CloseClipboard");+if(!pCloseClipboard)+die("E: cannot import CloseClipboard from user32.dll\n");+}++returnpCloseClipboard();}__declspec(dllexport)HANDLEWINAPIGetClipboardData(UINTuFormat){-returnNULL;/* always fail */+staticHANDLEWINAPI(*pGetClipboardData)(UINT);++if(!pGetClipboardData){+import_user32();+pGetClipboardData=GetProcAddress(user32,"GetClipboardData");+if(!pGetClipboardData)+die("E: cannot import GetClipboardData from user32.dll\n");+}++returnGetClipboardData(uFormat);}
--
1.7.4.1.225.g83c3c
---- 8< ----
>
> > Also I can't say for sure (hope yet) how sh-intensitive git tests are,
> > but at least running configure for say gettext or whatever should be
> > visibly faster, at least on wine.
>
> They are pretty intensive, as they are shell scripts all over the place in
> their own right.
Yes, thanks, your timing justifies that.
> I fear, however, that the real problem (maybe not on
> WINE, but with real Windows) is that sh.exe needs to provide too many
> POSIX-like things when starting new processes.
>
> I fear, further, that the only way to make things more efficient on
> Windows is to get rid of the many exec() calls and do more things
> in-process. (If this is true, JGit should kick msysGit's ass.) This would
> not apply to the test suite, though, which needs to stay a shell script
> suite.
>
> But maybe I am wrong, and the performance is lost through memory
> management and filesystem interaction.
I'd say we should not fear and we should not guess. The user32.dll
stripping was low-hanging-fruit, and judging from it I'd say there
should be other such places where time is wasted because nobody cared
yet.
Only could we please move forward, and try to integrate somehow the
result to devel? Or else I fear we'll have too many half-done work/* branches...
> Ciao,
> Dscho
Thanks,
Kirill
Thanks, I will try to find some time to test this next week.
Please don't - it does not build out of the box from msysgit yet. I
just wanted to show it is not staying stale. When it is finished, I'll
let you know.
Done. Please do
git pull git://repo.or.cz/msysgit/kirr.git ks/crossmsys # into msys
This is beautiful work. I will keep this as my candy tomorrow, because I
still have to finish something else (after which I want to provide myself
with some reward).
Thanks, I will try to find some time to test this next week.
Please don't - it does not build out of the box from msysgit yet. I
just wanted to show it is not staying stale. When it is finished, I'll
let you know.
Done. Please do
git pull git://repo.or.cz/msysgit/kirr.git ks/crossmsys # into msys
This is beautiful work. I will keep this as my candy tomorrow, because I
still have to finish something else (after which I want to provide myself
with some reward).
So how was it, tasteful? :)
Yep, but I got interrupted, and did not have time to come back yet. Please
bear with me for a few more days!
Ciao,
Dscho