Gute Nachrichten
Ich bin Sgt.Monica Lin Brown, ursprünglich aus Lake Jackson Texas USA. Ich habe persönlich eine spezielle Recherche im Internet durchgeführt und bin auf Ihre Informationen gestoßen. Ich sende Ihnen diese E-Mail von der US-Militärbasis Kabul Afghanistan. Ich habe einen gesicherten Geschäftsvorschlag für Sie. Fragen Sie mich, wenn Sie Interesse an weiteren Informationen haben
[no subject]
I didn't get any reply from you concerning my last email.. Br LiN __ Sky Silk, http://aknet.kz
New Order
Dear git@vger.kernel.org How are you? We are in need of your products/service, Kindly send us your FOB and MOQ so that we can place our order. The order will deliver in Taiwain branch Looking forward to your respond asap. Best Regards, Lin Tou Prime Success Co. Ltd Address: Av. Praia Grande, No.367-371, Keng Ou Commercial Building, 17th Fl. C, Macau Tel: 853-2843-7903
UTF-8-safe way for char-level-diff
Git has a diff.wordRegex config that allows the user to specify a regex that defines a word. Setting diff.wordRegex to "." works well for a char-level diff for ASCII chars, but not for UTF-8 chars. For example, if a file (encoded by UTF-8) with text "一人" is changed to "丁人", "git diff --word-diff=color" gets "<80><81>人" (where "<80>" is red and "<81>" is green) instead of desired "一丁人" (where "一" is red and "丁" is green). This could be very annoying when diff-ing files containing CJK chars. Git diff.wordRegex seems to implement a very basic regex that doesn't support matching char range by encoding such as "\x41" for "a". Is there a way to make the char-level diff work correctly? If not, maybe we should implement a way to allow it.
Re: [PATCH] contrib/subtree: fix linefeeds trimming for cmd_split()
Thank you for clearifying this. It seems that it's my terminal trimming the CR from the source code. If I run a script file with: echo -n Hello, world1CR echo -n Hello, world2CR echo -n Hello, world3CR echo -n Hello, world4CR I get this on the screen: Hello, world1Hello, world2Hello, world3Hello, world4 If I run with: printf Hello, world1\r printf Hello, world2\r printf Hello, world3\r printf Hello, world4\r I get this on the screen: Hello, world4 I don't see a problem in 'git fetch' or 'git checkout' Maybe using printf is the way to go? 2015-05-06 3:11 GMT+08:00 Junio C Hamano gits...@pobox.com: Danny Lin danny0...@gmail.com writes: I think this was written knowing that say is merely a thin wrapper of echo (which is a bad manner but happens to be correct) and assuming that everybody's echo understands -n (which is not a good assumption) to implement progress display that shows the N out of M done output over and over on the same physical line. So,... contrary to your makes no sense claim, what it tries to do makes perfect sense to me, even though its execution seems somewhat poor. The original version has a CR (yes, it's CR, not LF) at the end of the say -n string, which is weird. If it's meant to print a linefeed, we should remove the CR and use say. If it's meant not to print a linefeed, we still should remove the CR. Neither. It is meant to print a carriage-return, i.e. go back to the left-most column on the same line, without feeding a new line to the terminal (causing the output to scroll-up by one line). It sounds to me that your terminal is not supporting carriage-return in a way everybody else expects it to? It is not just this script, but all the progress output we generate use CR for that purpose. Do you see a similar garbled output from say git fetch or git checkout that takes more than a few hundred milliseconds? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] diff: do not use creation-half of -B as a rename target candidate
A1 = I am file A. B1 is copied from A1, so B1 = I am file A. B1 changes to B2 = I am file B. A1 changes to A2 = file A is changed a lot, a lot, ..., a lot. At this moment, commit A2 and B2 files. -- View this message in context: http://git.661346.n2.nabble.com/Git-BUG-Please-do-not-use-B-M-in-diff-family-for-now-tp7624794p7624836.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade Git in openSUSE13.1
go https://msysgit.github.io/ -- View this message in context: http://git.661346.n2.nabble.com/Upgrade-Git-in-openSUSE13-1-tp7623397p7623405.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade Git in openSUSE13.1
or http://sourceforge.net/projects/git-osx-installer/files/ for OS X users see https://blog.heroku.com/archives/2014/12/24/update_your_git_clients_on_windows_and_os_x -- View this message in context: http://git.661346.n2.nabble.com/Upgrade-Git-in-openSUSE13-1-tp7623397p7623406.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/1] Use absolute paths of lockfiles
Hi Michael: Good Morning. :) I see mh/lockfile and mh/lockfile-stdio were graduated to master. So. does this patch continue? On top of mh/lockfile-stdio? Thank you. ^_^ Yue Lin Ho -- View this message in context: http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-02-Fri-8-tp7616651p7619900.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/1] Use absolute paths of lockfiles
Hi Duy, Michael, Junio C Hamano: Thanks for working on lock file issue. Thank you! Thank you~ ^_^ Yue Lin Ho -- View this message in context: http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-02-Fri-8-tp7616651p7618314.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)
Hi Michael: 2014-08-27 6:09 GMT+08:00 Junio C Hamano gits...@pobox.com: [snip] -- [Stalled] [snip] * mh/lockfile (2014-04-15) 25 commits . trim_last_path_elm(): replace last_path_elm() . resolve_symlink(): take a strbuf parameter . resolve_symlink(): use a strbuf for internal scratch space . change lock_file::filename into a strbuf . commit_lock_file(): use a strbuf to manage temporary space . try_merge_strategy(): use a statically-allocated lock_file object . try_merge_strategy(): remove redundant lock_file allocation . struct lock_file: declare some fields volatile . lockfile: avoid transitory invalid states . commit_lock_file(): die() if called for unlocked lockfile object . commit_lock_file(): inline temporary variable . remove_lock_file(): call rollback_lock_file() . lock_file(): exit early if lockfile cannot be opened . write_packed_entry_fn(): convert cb_data into a (const int *) . prepare_index(): declare return value to be (const char *) . delete_ref_loose(): don't muck around in the lock_file's filename . cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN . lockfile.c: document the various states of lock_file objects . lock_file(): always add lock_file object to lock_file_list . hold_lock_file_for_append(): release lock on errors . lockfile: unlock file if lockfile permissions cannot be adjusted . rollback_lock_file(): set fd to -1 . rollback_lock_file(): do not clear filename redundantly . api-lockfile: expand the documentation . unable_to_lock_die(): rename function from unable_to_lock_index_die() Ejected from 'pu' to unclutter. Expecting a reroll. [snip] -- [Cooking] [snip] * rs/strbuf-getcwd (2014-08-26) 10 commits (merged to 'next' on 2014-08-26 at 11be0d6) + use strbuf_add_absolute_path() to add absolute paths + abspath: convert absolute_path() to strbuf + use xgetcwd() to set $GIT_DIR + use xgetcwd() to get the current directory or die + wrapper: add xgetcwd() + abspath: convert real_path_internal() to strbuf + abspath: use strbuf_getcwd() to remember original working directory + setup: convert setup_git_directory_gently_1 et al. to strbuf + unix-sockets: use strbuf_getcwd() + strbuf: add strbuf_getcwd() (this branch is tangled with *nd/lock-paths-absolute*.) Originally merged to 'next' on 2014-08-18 Reduce the use of fixed sized buffer passed to getcwd() calls by introducing xgetcwd() helper. Will merge to 'master'. [snip] -- [Discarded] [snip] * nd/lock-paths-absolute (2014-08-01) 3 commits . lockfile.c: store absolute path . lockfile.c: remove PATH_MAX limit in resolve_symlink() . lockfile.c: remove PATH_MAX limitation (except in resolve_symlink) Will drop and ask Michael to possibly cooperate and merge with *mh/lockfile*. I am tracing the lock path issue. (http://git.661346.n2.nabble.com/git-update-index-not-delete-lock-file-when-using-different-worktree-td7615300.html) Do you have any plan on it? Thank you. ^_^ Yue Lin Ho -- View this message in context: http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-04-Tue-26-tp7617534p7617655.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Make locked paths absolute when current directory is changed
Hi: 2014-07-23 19:55 GMT+08:00 Duy Nguyen pclo...@gmail.com: On Tue, Jul 22, 2014 at 12:04 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: [snip] OK, we should center these efforts around the strbuf_getcwd() topic, basing the other topic on realpath() and this one on it then? OK. -- Duy Excuse me. How do I trace these patches applied? I just fetch from https://github.com/gitster/git.git Then tried to find these patches if it is applied. (Seems not.) Then, I took a look at http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Jul-2014-04-Tue-22-td7615627.html seems no related information there. So, could you please tell me how to trace it? Thank you. ^_^ Yue Lin Ho -- View this message in context: http://git.661346.n2.nabble.com/PATCH-Make-locked-paths-absolute-when-current-directory-is-changed-tp7615398p7616119.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git update-index not delete lock file when using different worktree
Hi Duy: I tested your patch. It works. :) (only one case.) Thank you. There are 26 hold_locked_index() in these files: Line 475 of builtin\add.c Line 4234 of \builtin\apply.c Line 259 of \builtin\checkout.c Line 448 of \builtin\checkout.c Line 139 of \builtin\checkout-index.c Line 643 of \builtin\clone.c Line 323 of \builtin\commit.c Line 362 of \builtin\commit.c Line 383 of \builtin\commit.c Line 434 of \builtin\commit.c Line 1295 of \builtin\commit.c Line 479 of \builtin\describe.c Line 211 of \builtin\diff.c Line 660 of \builtin\merge.c Line 700 of \builtin\merge.c Line 88 of \builtin\mv.c Line 152 of \builtin\read-tree.c Line 338 of \builtin\reset.c Line 296 of \builtin\rm.c Line 808 of \builtin\update-index.c Line 588 of \cache-tree.c Line 75 of \merge.c Line 2004 of \merge-recursive.c Line 482 of \rerere.c Line 301 of \sequencer.c Line 671 of \sequencer.c Yue Lin -- View this message in context: http://git.661346.n2.nabble.com/git-update-index-not-delete-lock-file-when-using-different-worktree-tp7615300p7615378.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git update-index not delete lock file when using different worktree
I see that refresh() of update_index.c calls setup_work_tree() to change dir to working tree. And the dir is not changed back to git dir before commit_lock_file() or rollback_lock_file() is called. So, commit_lock_file() rename file failed. or rollback_lock_file() delete file failed. -- View this message in context: http://git.661346.n2.nabble.com/git-update-index-not-delete-lock-file-when-using-different-worktree-tp7615300p7615306.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git update-index not delete lock file when using different worktree
This is a [issue from TortoiseGit](https://code.google.com/p/tortoisegit/issues/detail?id=2233). After doing some test, I report it here. The following is the testing information I have tested. ### Folder Structure ``` Test |-- myrepo | |-- bar.txt | |-- foo.txt | |-- myrepo.git |-- .git ``` Testing repository is [here](https://code.google.com/p/tortoisegit/issues/detail?id=2233#c2). ### Using different worktree Set the config file (in the .git folder) ``` [core] worktree = ../../myrepo ``` ### Test 1 - Git Bash ``` User@PC /d/Repo/myrepo.git (master) $ git --version git version 1.9.4.msysgit.0 User@PC /d/Repo/myrepo.git (master) $ git update-index --refresh fatal: Unable to write new index file ``` D:\Repo\myrepo.git\\**index.lock** is not deleted. ### Test 2 - Git 2.0.0 Copy testing repository into ```C:\msysgit\MyTest``` Execute```msys.bat``` ```$ vagrant up``` ```$ vagrant ssh``` ```vagrant@precise64:/vagrant/git$ cd /vagrant``` ```vagrant@precise64:/vagrant$ cd mytest/myrepo.git``` ``` vagrant@precise64:/vagrant/mytest/myrepo.git$ git --version git version 2.0.0 ``` ``` vagrant@precise64:/vagrant/mytest/myrepo.git$ git update-index --refresh fatal: Unable to write new index file ``` Also, **index.lock is not deleted.** ### Test 3 - gitdll of TortoiseGit (git version 1.9.0) Tracing the source code into **compat/mingw.c** line 289 : xutftowcs_canonical_path() get the value of var. wpathname ``` D:\Repo\myrepo\.git\index.lock ``` It should be ``` D:\Repo\myrepo.git\.git\index.lock ``` line 294 : _wunlink() try to delete the file.(```D:\Repo\myrepo\.git\index.lock```) line 295 : GetLastError() return 3(ERROR_PATH_NOT_FOUND) (Actually, there is no ```D:\Repo\myrepo\.git``` folder.) -- View this message in context: http://git.661346.n2.nabble.com/git-update-index-not-delete-lock-file-when-using-different-worktree-tp7615300.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The different EOL behavior between libgit2-based software and official Git
Wow! P.S. A note: libgit2 just has a PR that try to be identical with official git 2.0.0. See https://github.com/libgit2/libgit2/pull/2432 -- View this message in context: http://git.661346.n2.nabble.com/The-different-EOL-behavior-between-libgit2-based-software-and-official-Git-tp7613670p7613801.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The different EOL behavior between libgit2-based software and official Git
Hi Torsten Bögershausen: Since you mail to msysGit first, I reply there. (https://groups.google.com/forum/#!topic/msysgit/EDD3RipNeBQ) Thank you again. ^_^ Yue Lin Ho -- View this message in context: http://git.661346.n2.nabble.com/The-different-EOL-behavior-between-libgit2-based-software-and-official-Git-tp7613670p7613681.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
The different EOL behavior between libgit2-based software and official Git
Hi: ^_^ I did some test on the EOL behavior between official git and libgit2-based software(TortoiseGit). Then, I got that they have different EOL behavior. The blob stored in repository is a text file with mixed EOLs. Even set core.autocrlf = true, official git checkout the file as it is(means still *mixed EOLs* there). But, libgit2 checkout it with *All CRLF EOLs*. * The steps: * set core.autocrlf = false * add file with mixed EOLs * set core.autocrlf = true * delete that file in the working tree * checkout that file * examine the EOL If you are interested in this, you might take a look at my testing repository on GitHub. (https://github.com/YueLinHo/TestAutoCrlf) Thank you. Yue Lin Ho -- View this message in context: http://git.661346.n2.nabble.com/The-different-EOL-behavior-between-libgit2-based-software-and-official-Git-tp7613670.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
