Re: Accept-language test fails on Mac OS
On 2014-12-06 00.01, Michael Blume wrote:
On Fri, Dec 5, 2014 at 2:51 PM, Junio C Hamano gits...@pobox.com wrote:
Michael Blume blume.m...@gmail.com writes:
Test #25 'git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG' in t5550 fails consistently on my mac, and has
since the test was introduced. Test 26 and 27 ('git client sends
Accept-Language with many preferred languages' and 'git client does
not send Accept-Language') seem fine.
I'm building git with NO_GETTEXT=1, which may be an issue? But in that
case the test should probably be gated on gettext?
I recall queuing a SQUASH??? on top of the posted patch; does these
tests pass with it reverted?
The test fails both on pu and on 7567fad which is prior to the
SQUASH??? commit, so the squash does not seem to change anything.
pu@c83418638e0c326f:
t5550 fails here under Debian Linux,
I haven't digged further
not ok 25 - git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG
#
# check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language de-DE, *;q=0.1 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language ja-JP, *;q=0.1
ja_JP.UTF-8 en_US.UTF-8
# check_language en-US, *;q=0.1
en_US.UTF-8
#
--
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
Cannot reset a repo
Hi, I am facing this problem: - Using git version 1.9.3 (Apple Git-50) - cloned a fork from GitHub to my local machine: https://github.com/mar10/cdnjs/ - This repo seems to be broken in some way. At least it is not clean from the beginning and I am not able to reset `git reset --hard` only toggles the modified file from .../sortable to .../Sortable and back (see attached screenshot) Is this a known problem (with case sensitivity)? Any suggestions how to fix it? Thanks Martin
Re: Cannot reset a repo
On 2014-12-06 11.27, Martin Wendt wrote: Hi, I am facing this problem: - Using git version 1.9.3 (Apple Git-50) - cloned a fork from GitHub to my local machine: https://github.com/mar10/cdnjs/ - This repo seems to be broken in some way. At least it is not clean from the beginning and I am not able to reset `git reset --hard` only toggles the modified file from .../sortable to .../Sortable and back (see attached screenshot) Is this a known problem (with case sensitivity)? I think so Any suggestions how to fix it? Try to rename Sortable into Sortable.u: git mv Sortable Sortable.upper (When that does not work) git mv sortable sortable.lower If this is not an option, use a USB Stick, format it with HFS+ case sensitive and clone the repo to the stick -- 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
How to repair a shallow clone (?)
I share a bare repo with Sparkleshare which does an auto-synch. Now the synch had stopped, and trying to push to the central repo by hand gives this: git push origin master fatal: protocol error: expected old/new/ref, got 'shallow 72fb4080921221293e28a97a0e8c78d6100c5186' fatal: The remote end hung up unexpectedly Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. error: pack-objects died of signal 13 error: failed to push some refs to x Both machines have Git 2.0.0 Is this a known issue/problem ? I think I started to clone the repo in a shallow way (SparkleShare asked if I want to clone the complete history, and I probably answered no ) Is there a way to repair this situation ? (Except doing a complete re-clone ?) Thanks for help -- 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
Fetching a specific commit by commit ID
Hello everyone, I am trying to fetch a commit using a commit ID instead of a reference. According to the documentation of git-fetch, this is not supported, but I found out that this is not entirely true. If the commit is already available in the repository, I get: $ git fetch origin 7365b1a9bd45fbf12b09381d5779b607e232a8cd From repo1 * branch7365b1a9bd45fbf12b09381d5779b607e232a8cd - FETCH_HEAD $ echo $? 0 If the commit is not in the repository (but it is present in the remote of course), I get: $ git fetch origin fc907b94f69b9bd710ba55b5522258b722fefb3b $ echo $? 1 That brings up following questions/remarks: - the documentation of git-fetch is not entirely correct, commit ids are partially supported, not only refs - “git fetch origin fc907” should print an error message on STDERR specifying what the problem is - more interestingly: is there any reason why git fetch should not support fetching by commit id? There are real world use cases where this can be very useful, for instance when references on the remote have been overwritten or deleted. Olivier -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
Am 05.12.2014 um 02:33 schrieb Duy Nguyen:
On Fri, Dec 5, 2014 at 3:06 AM, Jens Lehmann jens.lehm...@web.de wrote:
Wow, so the .git/config is shared between all worktrees? I
suspect you have very good reasons for that,
most of config vars are at repo-level, not worktree-level, except
maybe submodule.* and something else.
Yeah, that would have been my first guess too.
Technically we could use
include.path to point to a non-shared file, where we store
worktree-specific config.
I like that, but am not sure how hard that would be to
implement.
but I believe
that'll make multiple work trees surprise the user from time
to time when used with submodules. Because initializing a
submodule in one worktree initializes it in all other
worktrees too (I suspect other users regard git submodule
init being a worktree local command too). And setting
submodule.name.update to none will also affect all
other worktrees. But I'd need to have separate settings for
our CI server, e.g. to checkout the sources without the
largish documentation submodule in one test job (=worktree)
while checking out the whole documentation for another job
building the setup in another worktree.
And if I understand the checkout: reject if the branch is
already checked out elsewhere thread correctly, I won't be
able to build master in two jobs at the same time?
If you do git checkout --to ... master^{}, it should run fine.
So I'd have to teach our CI-server that incantation ... and
must hope nothing else breaks because of the detached HEAD.
I'm
still considering doing something better with the read-only refs, but
haven't found time to really think it through yet.
Hmm, what about different namespaces for the refs in the repo
borrowed from? Maybe only when it is bare? Dunno ...
Thanks. But I changed my mind about the details (now that I
know about .git/config and multiple worktrees). I think you'd
have to connect a .git directory in the submodule to the
common git dir directly, as you cannot use the core.worktree
setting (which could be different between commits due to
renames) when putting it into worktree/.git/modules. And
then you couldn't remove or rename a submodule anymore,
because that fails when it contains a .git directory.
Seems like we should put a Warning: may do unexpected things
when used with submodules (with some examples about what might
happen) in the multiple worktrees documentation. And I don't
believe anymore that teaching submodules to use the common git
dir makes that much sense after I know about the restrictions
it imposes.
I'm ok with such a warning fwiw.
I believe you'd need to prominently advertise that changing
settings in .git/config affects all worktrees anyway to avoid
surprising users (at least I didn't expect it ;-), so adding
a word or to that this also impacts submodules should suffice.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
Am 05.12.2014 um 07:32 schrieb Max Kirillov: On Thu, Dec 4, 2014 at 10:06 PM, Jens Lehmann jens.lehm...@web.de wrote: But I'd need to have separate settings for our CI server, e.g. to checkout the sources without the largish documentation submodule in one test job (=worktree) while checking out the whole documentation for another job building the setup in another worktree. Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable submodule.updateIgnoringConfigUrl (because usually the submodule.name.url is what turns on the update). It looks working, maybe I even add setting the variable when chackout --to is used. But it's not only submodule.name.url, the list goes on with update, fetch ignore and then there are the global options like diff.submodule, diff.ignoreSubmodules and some more. And if I understand the checkout: reject if the branch is already checked out elsewhere thread correctly, I won't be able to build master in two jobs at the same time? You are alerady second person complaining about it, but I don't really see how this can be a problem. Make a branch 'master2', it's another 40 bytes. I didn't mean to complain, I'm just explaining. And I cannot easily make it master2, I'd have to teach Jenkins that (and maybe that's easy and I just don't know how to do it). So two reasons against using multiple worktrees on our CI server to save quite some disk space :-( My use is not to save space (working tree files often takes more than the repository itself), but for development, I have like 3-5 checkouts usually, which used to be local clones, but not having to keep synching them is really life changing. Thanks, that explains my confusion. You want those repos to be tightly coupled while I'm looking for completely separate repos which just share their shared objects to reduce disk footprint. Seems like we should put a Warning: may do unexpected things when used with submodules (with some examples about what might happen) in the multiple worktrees documentation. And I don't believe anymore that teaching submodules to use the common git dir makes that much sense after I know about the restrictions it imposes. btw, I thought even about making it an error to add/remove/(de)initialize submodule not in the main working tree. But I'm afraid it would not be considered appropriate for merging. I think an error is too harsh here. If you know what you are doing (and what you cannot do) I see no reason not to use submodules together with multiple worktrees. And if you're sharing branches it might be rather obvious that you share submodule and other worktree settings too in the superproject. Thanks to you and Duy for discussing this with me! I'd sum it up like this: *) Multiple worktrees are meant to couple separate worktrees with a single repository to avoid having to push and fetch each time to sync refs and also to not having to sync settings manually (with the benefit of some disk space savings). That's a cool feature and explains why a branch should be protected against being modified in different worktrees. The first level submodule settings are shared between the multiple worktrees; submodule objects, settings and refs aren't (because the .git/modules directory isn't shared). Looks like that would work with just what we have now, no? Having submodules share repos would need at least a per-worktree core.git setting (which could be achieved via worktree-specific .git/config includes). *) I'd love to see a solution for sharing the object database between otherwise unrelated clones of the same project (so that fetching in one clone updates the objects in the common dir and gc cannot throw anything away used by one of the clones). But I'd expect a bare repository as the common one where we put the worktrees refs into their own namespaces. That's another beast (which nonetheless might be based on what you guys are doing here). And the worktree specific configuration needed here could help to share submodule repos for the multiple worktrees case. Does that make sense? -- 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: bug report on update-index --assume-unchanged
From: Sérgio Basto ser...@serjux.com [..] Part of the implied question is why git commit . would notice when when git commit -a didn't appear to. So it's unclear as to what the user should have expected. I agree with this sentence, this is a bug because: git commit -a ( and -a means all ) is incoherent with git commit . This is stupid because when I want commit part of the tree, commit includes one file that is not included when I say to commit all . So maybe you should fix, git commit -a to be coherent . Ultimately this (-a vs '.' with --assume-unchanged) is not a 'bug', because it does as planned. However the documenation is 'wrong' or at least misguides many readers. Thank you for bring it to the list's attention. [..] Sorry I don't have time to read all messages in thread , but I'm going to test git with the patch suggest in this thread , at least, I solve my problem for some time ... My patch, and Junio's 'squash' are to correct the documentation, and especially remove the line about it having an ignore capability, which is a promise not kept (your -a vs '.' !). I'll be updating the documenation patch today for review, though that doesn't solve the wider problem of: - 'how to temporarily ignore changes to a tracked file'. -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] doc: make clear --assume-unchanged's user contract
Many users misunderstand the --assume-unchanged contract, believing it means Git won't look at the flagged file. Be explicit that the --assume-unchanged contract is by the user that they will NOT change the file so that Git does not need to look (and expend, for example, lstat(2) cycles) Mentioning Git stops checking does not help the reader, as it is only one possible consequence of what that assumption allows Git to do, but (1) there are things other than stop checking that Git can do based on that assumption; and (2) Git is not obliged to stop checking; it merely is allowed to. Also, this is a single flag bit, correct the plural to singular, and the verb, accordingly. Drop the stale and incorrect information about poor-man's ignore, which is not what this flag bit is about at all. Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/git-update-index.txt | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index e0a8702..da1ccbc 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -78,20 +78,18 @@ OPTIONS Set the execute permissions on the updated files. --[no-]assume-unchanged:: - When these flags are specified, the object names recorded - for the paths are not updated. Instead, these options - set and unset the assume unchanged bit for the - paths. When the assume unchanged bit is on, Git stops - checking the working tree files for possible - modifications, so you need to manually unset the bit to - tell Git when you change the working tree file. This is + When this flag is specified, the object names recorded + for the paths are not updated. Instead, this option + sets/unsets the assume unchanged bit for the + paths. When the assume unchanged bit is on, the user + promises not to change the file and allows Git to assume + that the working tree file matches what is recorded in + the index. If you want to change the working tree file, + you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs). + -This option can be also used as a coarse file-level mechanism -to ignore uncommitted changes in tracked files (akin to what -`.gitignore` does for untracked files). Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, -- 1.9.4.msysgit.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Improve --assume-unchanged in the git update-index man page
This version 2 patch squashes in Junio's comments ($gmane/260915) and tidies up the commit message. Previous series at $gmane/260901. In $gmane/260837 the --assume-unchanged flag was reported as buggy because of a misunderstanding about what it is being promised. This clarifies the current situation, rather than change the code as proposed by Duy in $gmane/260865. Philip Oakley (1): doc: make clear --assume-unchanged's user contract Documentation/git-update-index.txt | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) -- 1.9.4.msysgit.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fetching a specific commit by commit ID
On Sat, Dec 06, 2014 at 01:39:12PM +0100, Olivier Croquette wrote: That brings up following questions/remarks: - the documentation of git-fetch is not entirely correct, commit ids are partially supported, not only refs This isn't completely true. What you're seeing here is that git fetch performs a negotiation to find out what each side has. As a consequence, if git does not need to fetch the item in question because it already has it, git fetch succeeds. The two sides essentially never get to the point where they have to determine whether the behavior is allowed. - more interestingly: is there any reason why git fetch should not support fetching by commit id? There are real world use cases where this can be very useful, for instance when references on the remote have been overwritten or deleted. It does in some cases if the remote supports this. See the uploadarchive and uploadpack groups in git-config(1). However, you can still only access existing branches and tags. The reason this isn't supported in the general case is because one might want to restrict access to certain branches. For example, an open source project might want to embargo some security fixes that are in the repository. Allowing a user to specify an arbitrary ID would permit someone to circumvent those access controls. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Cannot reset a repo
Am 06.12.2014 um 13:14 schrieb Torsten Bögershausen tbo...@web.de: On 2014-12-06 11.27, Martin Wendt wrote: Hi, I am facing this problem: - Using git version 1.9.3 (Apple Git-50) - cloned a fork from GitHub to my local machine: https://github.com/mar10/cdnjs/ - This repo seems to be broken in some way. At least it is not clean from the beginning and I am not able to reset `git reset --hard` only toggles the modified file from .../sortable to .../Sortable and back (see attached screenshot) Is this a known problem (with case sensitivity)? I think so Any suggestions how to fix it? Try to rename Sortable into Sortable.u: git mv Sortable Sortable.upper (When that does not work) git mv sortable sortable.lower If this is not an option, use a USB Stick, format it with HFS+ case sensitive and clone the repo to the stick Thanks for responding. It is a fork of the 6GB cdnjs repository and I don't own the sortable lib. So renaming is not an option. Also, I am working on a MacBook, which already has a case sensitive file system. -- 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: Enhancement Request: locale git option
2014-12-05 16:45 GMT+01:00 Torsten Bögershausen tbo...@web.de: I do not know who was first, and who came later, but http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-nachverfolgen uses versioniert as tracked LANG=de_DE.UTF-8 git status gives: nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen Sie git add zum Beobachten) Does it make sense to replace beobachten with versionieren ? I think it makes sense. versionieren describes the concept of tracking better than beobachten, IMO. I'll send a patch for that. Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] l10n: de.po: translate track as versionieren
Suggested-by: Torsten Bögershausen tbo...@web.de Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/po/de.po b/po/de.po index 5a93ea8..bf11225 100644 --- a/po/de.po +++ b/po/de.po @@ -690,7 +690,7 @@ msgstr : vielleicht ein Verzeichnis/Datei-Konflikt? #: merge-recursive.c:727 #, c-format msgid refusing to lose untracked file at '%s' -msgstr verweigere, da unbeobachtete Dateien in '%s' verloren gehen würden +msgstr verweigere, da unversionierte Dateien in '%s' verloren gehen würden #: merge-recursive.c:767 #, c-format @@ -1631,7 +1631,7 @@ msgstr #: wt-status.c:225 msgid (commit or discard the untracked or modified content in submodules) msgstr - (committen oder verwerfen Sie den unbeobachteten oder geänderten Inhalt in + (committen oder verwerfen Sie den unversionierten oder geänderten Inhalt in den Submodulen) #: wt-status.c:237 @@ -1716,7 +1716,7 @@ msgstr geänderter Inhalt, #: wt-status.c:374 msgid untracked content, -msgstr unbeobachteter Inhalt, +msgstr unversionierter Inhalt, #: wt-status.c:391 #, c-format @@ -1932,7 +1932,7 @@ msgstr Initialer Commit #: wt-status.c:1356 msgid Untracked files -msgstr Unbeobachtete Dateien +msgstr Unversionierte Dateien #: wt-status.c:1358 msgid Ignored files @@ -1945,18 +1945,18 @@ msgid may speed it up, but you have to be careful not to forget to add\n new files yourself (see 'git help status'). msgstr -Es dauerte %.2f Sekunden die unbeobachteten Dateien zu bestimmen.\n +Es dauerte %.2f Sekunden die unversionierten Dateien zu bestimmen.\n 'status -uno' könnte das beschleunigen, aber Sie müssen darauf achten,\n neue Dateien selbstständig hinzuzufügen (siehe 'git help status'). #: wt-status.c:1368 #, c-format msgid Untracked files not listed%s -msgstr Unbeobachtete Dateien nicht aufgelistet%s +msgstr Unversionierte Dateien nicht aufgelistet%s #: wt-status.c:1370 msgid (use -u option to show untracked files) -msgstr (benutzen Sie die Option -u, um unbeobachtete Dateien anzuzeigen) +msgstr (benutzen Sie die Option -u, um unversionierte Dateien anzuzeigen) #: wt-status.c:1376 msgid No changes @@ -1980,20 +1980,20 @@ msgid nothing added to commit but untracked files present (use \git add\ to track)\n msgstr -nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen -Sie \git add\ zum Beobachten)\n +nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien (benutzen +Sie \git add\ zum Versionieren)\n #: wt-status.c:1390 #, c-format msgid nothing added to commit but untracked files present\n -msgstr nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien\n +msgstr nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien\n #: wt-status.c:1393 #, c-format msgid nothing to commit (create/copy files and use \git add\ to track)\n msgstr nichts zu committen (Erstellen/Kopieren Sie Dateien und benutzen Sie \git -add\ zum Beobachten)\n +add\ zum Versionieren)\n #: wt-status.c:1396 wt-status.c:1401 #, c-format @@ -2004,7 +2004,7 @@ msgstr nichts zu committen\n #, c-format msgid nothing to commit (use -u to show untracked files)\n msgstr -nichts zu committen (benutzen Sie die Option -u, um unbeobachtete Dateien +nichts zu committen (benutzen Sie die Option -u, um unversionierte Dateien anzuzeigen)\n #: wt-status.c:1403 @@ -2119,7 +2119,7 @@ msgstr das Hinzufügen andernfalls ignorierter Dateien erlauben #: builtin/add.c:255 msgid update tracked files -msgstr beobachtete Dateien aktualisieren +msgstr versionierte Dateien aktualisieren #: builtin/add.c:256 msgid record only the fact that the path will be added later @@ -2128,7 +2128,7 @@ msgstr nur speichern, dass der Pfad später hinzugefügt werden soll #: builtin/add.c:257 msgid add changes from all tracked and untracked files msgstr -Änderungen von allen beobachteten und unbeobachteten Dateien hinzufügen +Änderungen von allen versionierten und unversionierten Dateien hinzufügen #: builtin/add.c:260 msgid ignore paths removed in the working tree (same as --no-all) @@ -4536,7 +4536,7 @@ msgstr Kein existierender Autor mit '%s' gefunden. #: builtin/commit.c:1110 builtin/commit.c:1350 #, c-format msgid Invalid untracked files mode '%s' -msgstr Ungültiger Modus '%s' für unbeobachtete Dateien +msgstr Ungültiger Modus '%s' für unversionierte Dateien #: builtin/commit.c:1147 msgid --long and -z are incompatible @@ -4636,7 +4636,7 @@ msgstr Modus #: builtin/commit.c:1377 builtin/commit.c:1656 msgid show untracked files, optional modes: all, normal, no. (Default: all) msgstr -nicht beobachtete Dateien anzeigen, optionale Modi: all, normal, no. +unversionierte Dateien anzeigen, optionale Modi: all, normal, no. (Standard: all) #: builtin/commit.c:1380 @@ -4657,7 +4657,7 @@ msgstr #: builtin/commit.c:1384 msgid list untracked files in columns
Re: [PATCH] l10n: de.po: translate track as versionieren
Hi, for my feeling Beobachten is better then Versionieren. Its more natural and easier to understand, but okey ;) Phillip On 6 December 2014 20:28:49 CET, Ralf Thielow ralf.thie...@gmail.com wrote: Suggested-by: Torsten Bögershausen tbo...@web.de Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/po/de.po b/po/de.po index 5a93ea8..bf11225 100644 --- a/po/de.po +++ b/po/de.po @@ -690,7 +690,7 @@ msgstr : vielleicht ein Verzeichnis/Datei-Konflikt? #: merge-recursive.c:727 #, c-format msgid refusing to lose untracked file at '%s' -msgstr verweigere, da unbeobachtete Dateien in '%s' verloren gehen würden +msgstr verweigere, da unversionierte Dateien in '%s' verloren gehen würden #: merge-recursive.c:767 #, c-format @@ -1631,7 +1631,7 @@ msgstr #: wt-status.c:225 msgid (commit or discard the untracked or modified content in submodules) msgstr - (committen oder verwerfen Sie den unbeobachteten oder geänderten Inhalt in + (committen oder verwerfen Sie den unversionierten oder geänderten Inhalt in den Submodulen) #: wt-status.c:237 @@ -1716,7 +1716,7 @@ msgstr geänderter Inhalt, #: wt-status.c:374 msgid untracked content, -msgstr unbeobachteter Inhalt, +msgstr unversionierter Inhalt, #: wt-status.c:391 #, c-format @@ -1932,7 +1932,7 @@ msgstr Initialer Commit #: wt-status.c:1356 msgid Untracked files -msgstr Unbeobachtete Dateien +msgstr Unversionierte Dateien #: wt-status.c:1358 msgid Ignored files @@ -1945,18 +1945,18 @@ msgid may speed it up, but you have to be careful not to forget to add\n new files yourself (see 'git help status'). msgstr -Es dauerte %.2f Sekunden die unbeobachteten Dateien zu bestimmen.\n +Es dauerte %.2f Sekunden die unversionierten Dateien zu bestimmen.\n 'status -uno' könnte das beschleunigen, aber Sie müssen darauf achten,\n neue Dateien selbstständig hinzuzufügen (siehe 'git help status'). #: wt-status.c:1368 #, c-format msgid Untracked files not listed%s -msgstr Unbeobachtete Dateien nicht aufgelistet%s +msgstr Unversionierte Dateien nicht aufgelistet%s #: wt-status.c:1370 msgid (use -u option to show untracked files) -msgstr (benutzen Sie die Option -u, um unbeobachtete Dateien anzuzeigen) +msgstr (benutzen Sie die Option -u, um unversionierte Dateien anzuzeigen) #: wt-status.c:1376 msgid No changes @@ -1980,20 +1980,20 @@ msgid nothing added to commit but untracked files present (use \git add\ to track)\n msgstr -nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen -Sie \git add\ zum Beobachten)\n +nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien (benutzen +Sie \git add\ zum Versionieren)\n #: wt-status.c:1390 #, c-format msgid nothing added to commit but untracked files present\n -msgstr nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien\n +msgstr nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien\n #: wt-status.c:1393 #, c-format msgid nothing to commit (create/copy files and use \git add\ to track)\n msgstr nichts zu committen (Erstellen/Kopieren Sie Dateien und benutzen Sie \git -add\ zum Beobachten)\n +add\ zum Versionieren)\n #: wt-status.c:1396 wt-status.c:1401 #, c-format @@ -2004,7 +2004,7 @@ msgstr nichts zu committen\n #, c-format msgid nothing to commit (use -u to show untracked files)\n msgstr -nichts zu committen (benutzen Sie die Option -u, um unbeobachtete Dateien +nichts zu committen (benutzen Sie die Option -u, um unversionierte Dateien anzuzeigen)\n #: wt-status.c:1403 @@ -2119,7 +2119,7 @@ msgstr das Hinzufügen andernfalls ignorierter Dateien erlauben #: builtin/add.c:255 msgid update tracked files -msgstr beobachtete Dateien aktualisieren +msgstr versionierte Dateien aktualisieren #: builtin/add.c:256 msgid record only the fact that the path will be added later @@ -2128,7 +2128,7 @@ msgstr nur speichern, dass der Pfad später hinzugefügt werden soll #: builtin/add.c:257 msgid add changes from all tracked and untracked files msgstr -Änderungen von allen beobachteten und unbeobachteten Dateien hinzufügen +Änderungen von allen versionierten und unversionierten Dateien hinzufügen #: builtin/add.c:260 msgid ignore paths removed in the working tree (same as --no-all) @@ -4536,7 +4536,7 @@ msgstr Kein existierender Autor mit '%s' gefunden. #: builtin/commit.c:1110 builtin/commit.c:1350 #, c-format msgid Invalid untracked files mode '%s' -msgstr Ungültiger Modus '%s' für unbeobachtete Dateien +msgstr Ungültiger Modus '%s' für unversionierte Dateien #: builtin/commit.c:1147 msgid --long and -z are incompatible @@ -4636,7 +4636,7 @@ msgstr Modus #: builtin/commit.c:1377 builtin/commit.c:1656 msgid show untracked files, optional modes: all, normal, no. (Default: all) msgstr -nicht beobachtete Dateien anzeigen, optionale Modi: all, normal, no.
[PATCH v2 1/2] send-email: align RFC 2047 decoding more closely with the spec
More specifically:
* Add \ to the list of characters not allowed in a token (see RFC 2047
errata).
* Share regexes between unquote_rfc2047 and is_rfc2047_quoted. Besides
removing duplication, this also makes unquote_rfc2047 more stringent.
* Allow both q and Q to identify the encoding.
* Allow lowercase hexadecimal digits in the Q encoding.
And, more on the cosmetic side:
* Change the encoded-text regex to exclude rather than include characters,
for clarity and consistency with token.
Signed-off-by: Роман Донченко d...@corrigendum.ru
---
git-send-email.perl | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9949db0..d461ffb 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -145,6 +145,11 @@ my $have_mail_address = eval { require Mail::Address; 1 };
my $smtp;
my $auth;
+# Regexes for RFC 2047 productions.
+my $re_token = qr/[^][()@,;:\\\/?.= \000-\037\177-\377]+/;
+my $re_encoded_text = qr/[^? \000-\037\177-\377]+/;
+my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/;
+
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
$initial_reply_to,$initial_subject,@files,
@@ -913,15 +918,20 @@ $time = time - scalar $#files;
sub unquote_rfc2047 {
local ($_) = @_;
- my $encoding;
- s{=\?([^?]+)\?q\?(.*?)\?=}{
- $encoding = $1;
- my $e = $2;
- $e =~ s/_/ /g;
- $e =~ s/=([0-9A-F]{2})/chr(hex($1))/eg;
- $e;
+ my $charset;
+ s{$re_encoded_word}{
+ $charset = $1;
+ my $encoding = $2;
+ my $text = $3;
+ if ($encoding eq 'q' || $encoding eq 'Q') {
+ $text =~ s/_/ /g;
+ $text =~ s/=([0-9A-F]{2})/chr(hex($1))/egi;
+ $text;
+ } else {
+ $; # other encodings not supported yet
+ }
}eg;
- return wantarray ? ($_, $encoding) : $_;
+ return wantarray ? ($_, $charset) : $_;
}
sub quote_rfc2047 {
@@ -934,10 +944,8 @@ sub quote_rfc2047 {
sub is_rfc2047_quoted {
my $s = shift;
- my $token = qr/[^][()@,;:\/?.= \000-\037\177-\377]+/;
- my $encoded_text = qr/[!-@-~]+/;
length($s) = 75
- $s =~ m/^(?:[[:ascii:]]*|=\?$token\?$token\?$encoded_text\?=)$/o;
+ $s =~ m/^(?:[[:ascii:]]*|$re_encoded_word)$/o;
}
sub subject_needs_rfc2047_quoting {
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly
The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).
---
git-send-email.perl | 26 --
t/t9001-send-email.sh | 7 +++
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d461ffb..7d5cc8a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -919,17 +919,23 @@ $time = time - scalar $#files;
sub unquote_rfc2047 {
local ($_) = @_;
my $charset;
- s{$re_encoded_word}{
- $charset = $1;
- my $encoding = $2;
- my $text = $3;
- if ($encoding eq 'q' || $encoding eq 'Q') {
- $text =~ s/_/ /g;
- $text =~ s/=([0-9A-F]{2})/chr(hex($1))/egi;
- $text;
- } else {
- $; # other encodings not supported yet
+ my $sep = qr/[ \t]+/;
+ s{$re_encoded_word(?:$sep$re_encoded_word)*}{
+ my @words = split $sep, $;
+ foreach (@words) {
+ m/$re_encoded_word/;
+ $charset = $1;
+ my $encoding = $2;
+ my $text = $3;
+ if ($encoding eq 'q' || $encoding eq 'Q') {
+ $_ = $text;
+ s/_/ /g;
+ s/=([0-9A-F]{2})/chr(hex($1))/egi;
+ } else {
+ # other encodings not supported yet
+ }
}
+ join '', @words;
}eg;
return wantarray ? ($_, $charset) : $_;
}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 19a3ced..fa965ff 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -240,6 +240,13 @@ test_expect_success $PREREQ 'non-ascii self name is
suppressed'
'non_ascii_self_suppressed'
+# This name is long enough to force format-patch to split it into multiple
+# encoded-words, assuming it uses UTF-8 with the Q encoding.
+test_expect_success $PREREQ 'long non-ascii self name is suppressed'
+ test_suppress_self_quoted 'Ƒüñníęř €. Nâṁé' 'odd_?=m...@example.com' \
+ 'long_non_ascii_self_suppressed'
+
+
test_expect_success $PREREQ 'sanitized self name is suppressed'
test_suppress_self_unquoted '\A U. Thor\' 'aut...@example.com' \
'self_name_sanitized_suppressed'
--
2.1.1
--
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] l10n: de.po: translate track as versionieren
Hi Phillip Am 6. Dezember 2014 um 20:34 schrieb phillip phillip.sze...@gmail.com: Hi, for my feeling Beobachten is better then Versionieren. Its more natural and easier to understand, but okey ;) I think it's OK as Git is all about versioning content. In other cases beobachten might be the better choice. Ralf -- 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: Accept-language test fails on Mac OS
Could you tell me your locale information from executing 'locale'
command and the verbose message you can get by accessing any git
repository via HTTP protocol? (e.g. GIT_CURL_VERBOSE=1 git clone
http://github.com/foo/bar )
I think the failures are related with your locale information.
On Sat, Dec 6, 2014 at 6:50 PM, Torsten Bögershausen tbo...@web.de wrote:
On 2014-12-06 00.01, Michael Blume wrote:
On Fri, Dec 5, 2014 at 2:51 PM, Junio C Hamano gits...@pobox.com wrote:
Michael Blume blume.m...@gmail.com writes:
Test #25 'git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG' in t5550 fails consistently on my mac, and has
since the test was introduced. Test 26 and 27 ('git client sends
Accept-Language with many preferred languages' and 'git client does
not send Accept-Language') seem fine.
I'm building git with NO_GETTEXT=1, which may be an issue? But in that
case the test should probably be gated on gettext?
I recall queuing a SQUASH??? on top of the posted patch; does these
tests pass with it reverted?
The test fails both on pu and on 7567fad which is prior to the
SQUASH??? commit, so the squash does not seem to change anything.
pu@c83418638e0c326f:
t5550 fails here under Debian Linux,
I haven't digged further
not ok 25 - git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG
#
# check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language de-DE, *;q=0.1 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language ja-JP, *;q=0.1
ja_JP.UTF-8 en_US.UTF-8
# check_language en-US, *;q=0.1
en_US.UTF-8
#
--
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: Accept-language test fails on Mac OS
On 2014-12-06 20.44, Yi, EungJun wrote:
Could you tell me your locale information from executing 'locale'
command and the verbose message you can get by accessing any git
repository via HTTP protocol? (e.g. GIT_CURL_VERBOSE=1 git clone
http://github.com/foo/bar )
locale -a
C
C.UTF-8
en_US.utf8
icelandic
is_IS
is_IS.iso88591
is_IS.utf8
POSIX
-
After patching like this:
diff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh
index fc6e7fc..1e42b42 100755
--- a/t/t5550-http-fetch-dumb.sh
+++ b/t/t5550-http-fetch-dumb.sh
@@ -205,8 +205,8 @@ check_language () {
LANG=$5 \
git ls-remote $HTTPD_URL/dumb/repo.git 21 |
tr -d '\015' |
- sort -u stderr
- grep -i ^Accept-Language: stderr actual
+ sort -u stderr
+ grep -i ^Accept-Language: stderr actual
test_cmp expect actual
}
---
I get this:
expecting success:
check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language de-DE, *;q=0.1 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language ja-JP, *;q=0.1 ja_JP.UTF-8
en_US.UTF-8
check_language en-US, *;q=0.1
en_US.UTF-8
--- expect 2014-12-06 21:00:59.0 +
+++ actual 2014-12-06 21:00:59.0 +
@@ -1 +0,0 @@
-Accept-Language: de-DE, *;q=0.1
not ok 25 - git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG
#
# check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language de-DE, *;q=0.1 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language ja-JP, *;q=0.1
ja_JP.UTF-8 en_US.UTF-8
# check_language en-US, *;q=0.1
en_US.UTF-8
#
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-svn: propset support v2
I have incorporated Eric Wong's feedback into the git-svn propset support patch. Issues resolved: 1) Test-case written. 2) Remove dead code. 3) Use shorter vars for formatting. 4) Fix bool comparisons. 5) Check for filesystem errors on write to .gitattribute file. 6) Use command_output_pipe() instead of open my $fh, '-|', ... 7) Refactor check for existing props. There is a nit that I want to point out. The code does not support adding props unless there are also content changes to the files as well. You can see this in the testcase. That is still sufficient for many people's workflows (FreeBSD at least). So I am wondering if this is OK. I would gladly take any pointers to making it work with unchanged files either for a later diff or to wrap this up. Thank you. Alfred Perlstein (1): git-svn: Support for git-svn propset git-svn.perl | 49 +++- perl/Git/SVN/Editor.pm | 43 t/t9148-git-svn-propset.sh | 71 ++ 3 files changed, 162 insertions(+), 1 deletion(-) create mode 100755 t/t9148-git-svn-propset.sh -- 2.1.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-svn: Support for git-svn propset
This change allows git-svn to support setting subversion properties.
Very useful for manually setting properties when committing to a
subversion repo that *requires* properties to be set without requiring
moving your changeset to separate subversion checkout in order to
set props.
This change is initially from David Fraser davidf () sjsoft ! com
Appearing here:
http://marc.info/?l=gitm=125259772625008w=2
They are now forward ported to most recent git along with fixes to
deal with files in subdirectories.
Style and functional changes from Eric Wong have been taken
in thier entirety from:
http://marc.info/?l=gitm=141742735608544w=2
Reviewed-by: Eric Wong normalper...@yhbt.net
Signed-off-by: Alfred Perlstein alf...@freebsd.org
Signed-off-by: David Fraser dav...@sjsoft.com
---
git-svn.perl | 49 +++-
perl/Git/SVN/Editor.pm | 43
t/t9148-git-svn-propset.sh | 71 ++
3 files changed, 162 insertions(+), 1 deletion(-)
create mode 100755 t/t9148-git-svn-propset.sh
diff --git a/git-svn.perl b/git-svn.perl
index b6e2186..5cdbf39 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -115,7 +115,7 @@ my ($_stdin, $_help, $_edit,
$_before, $_after,
$_merge, $_strategy, $_preserve_merges, $_dry_run, $_parents, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_commit_url, $_tag, $_merge_info, $_interactive);
+ $_commit_url, $_tag, $_merge_info, $_interactive, $_set_svn_props);
# This is a refactoring artifact so Git::SVN can get at this git-svn switch.
sub opt_prefix { return $_prefix || '' }
@@ -193,6 +193,7 @@ my %cmd = (
'dry-run|n' = \$_dry_run,
'fetch-all|all' = \$_fetch_all,
'commit-url=s' = \$_commit_url,
+ 'set-svn-props=s' = \$_set_svn_props,
'revision|r=i' = \$_revision,
'no-rebase' = \$_no_rebase,
'mergeinfo=s' = \$_merge_info,
@@ -228,6 +229,9 @@ my %cmd = (
'propget' = [ \cmd_propget,
'Print the value of a property on a file or directory',
{ 'revision|r=i' = \$_revision } ],
+'propset' = [ \cmd_propset,
+ 'Set the value of a property on a file or directory -
will be set on commit',
+ {} ],
'proplist' = [ \cmd_proplist,
'List all properties of a file or directory',
{ 'revision|r=i' = \$_revision } ],
@@ -1376,6 +1380,49 @@ sub cmd_propget {
print $props-{$prop} . \n;
}
+# cmd_propset (PROPNAME, PROPVAL, PATH)
+#
+# Adjust the SVN property PROPNAME to PROPVAL for PATH.
+sub cmd_propset {
+ my ($propname, $propval, $path) = @_;
+ $path = '.' if not defined $path;
+ $path = $cmd_dir_prefix . $path;
+ usage(1) if not defined $propname;
+ usage(1) if not defined $propval;
+ my $file = basename($path);
+ my $dn = dirname($path);
+ my $cur_props = Git::SVN::Editor::check_attr( svn-properties, $path );
+ my $new_props = ;
+ if ($cur_props eq unset || $cur_props eq || $cur_props eq set) {
+ $new_props = $propname=$propval;
+ } else {
+ # TODO: handle combining properties better
+ my @props = split(/;/, $cur_props);
+ my $replaced_prop;
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ if ($n eq $propname)
+ {
+ $v = $propval;
+ $replaced_prop = 1;
+ }
+ if ($new_props eq ) { $new_props=$n=$v; }
+ else { $new_props=$new_props;$n=$v; }
+ }
+ }
+ if (!$replaced_prop) {
+ $new_props = $new_props;$propname=$propval;
+ }
+ }
+ my $attrfile = $dn/.gitattributes;
+ open my $attrfh, '', $attrfile or die Can't open $attrfile: $!\n;
+ # TODO: don't simply append here if $file already has svn-properties
+ print $attrfh $file svn-properties=$new_props\n or die write to
$attrfile;
+ close $attrfh or die close $attrfile;
+}
+
# cmd_proplist (PATH)
# ---
# Print the list of SVN properties for PATH.
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 34e8af9..dd15318 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -288,6 +288,45 @@ sub apply_autoprops {
}
}
+sub check_attr
+{
+ my
Re: How to repair a shallow clone (?)
On 06/12/2014 19:23, Torsten Bögershausen wrote: I think I started to clone the repo in a shallow way (SparkleShare asked if I want to clone the complete history, and I probably answered no ) Is there a way to repair this situation ? (Except doing a complete re-clone ?) I think git don't accept push from shallow repo. I've ever encounter this problem. I UNshallow it, then every thing will work: $ git fetch --unshallow origin This command will convert a shallow repository to a complete one. See git-fetch(1) and git-clone(1). I hope it helpful! Thanks, -- Trần Ngọc Quân. -- 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: FW: [cygwin] Cygwin's git says error: failed to read delta-pack base object
TLDR = Cygwin remote filesystem sometimes has strange failures - workaround is
to use rename, not link/unlink;
see
https://github.com/pdinc-oss/git/commit/5a36824ed01d4335148ca3846e75cc99c11650e2
-Original Message-
From: Jason Pyeron
Sent: Friday, December 05, 2014 10:30
-Original Message-
From: Jason Pyeron
Sent: Thursday, December 04, 2014 16:34
-Original Message-
From: brian m. carlson
Sent: Wednesday, December 03, 2014 19:55
On Wed, Dec 03, 2014 at 06:31:18PM -0500, Jason Pyeron wrote:
I remember hitting this a while ago, but just gave up.
It seems to be a problem for others too.
Any ideas on how to debug this so it can be patched?
-Original Message-
From: Dave Lindbergh
Sent: Wednesday, December 03, 2014 18:07
To: cygwin
Aha - you're right.
It works fine on a local NTFS volume.
I get the error when I do it on Z:, which is mapped to a
network drive
(on another Windows box).
Is there a workaround? Why does this happen?
I have a really hacky workaround, commit
5a36824ed01d4335148ca3846e75cc99c11650e2 comments out the logic and forces a
rename instead of link and unlink.
https://github.com/pdinc-oss/git/tree/cygwin-issue-remoteCIFS-rename
snip/
Pseudo code and observations
./sha1_file.c:write_loose_object(sha1)
{
filename=sha1_file_name(sha1)
(fd,tmp_file)=create_tmpfile(filename)
write_buffer(fd)
close_sha1_file(fd)
return move_temp_to_file(tmp_file, filename)
}
move_temp_to_file(tmpfile, filename)
{
// I am thinking about forcing renames to see if the problem
exists then as well
// if that works then a per repo config option allowing
for forced renames
if (OBJECT_CREATION_USES_RENAMES) goto try_rename
else if link(tmpfile,filename)
Dave has tested a build I made for him on 64 bit Cygwin and it works. I no
longer have access to the environment I was having this problem in last
February. I will try to investigate this further, but I am not hopeful, maybe
Corinna will have luck on the issue. But I was in a secure corporate
environment and I thought the host based security system (AV), coupled with the
remote file system was causing the problem, namely files created are not
available instantly.
I do think that we should have a config option for this, as most users who
could encounter such a problem are not likely to be able (or allowed) to
rebuild the git executable themselves.
snip/
-Original Message-
From: Corinna Vinschen
Sent: Friday, December 05, 2014 6:35
To: cyg...@cygwin.com
snip/
What I found in the strace is this:
- Create file Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ
- open file, write something, close file.
- link (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ,
Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4)
succeeds.
- unlink (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ) succeeds
- Trying to open
Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4
but the file doesn't exist and NtCreateFile fails with status
0xC034, STATUS_OBJECT_NAME_NOT_FOUND -- ENOENT.
- Subsequent unlink (Z:\pic32mx-bmf\.git\objects\30) fails with a
STATUS_DIRECTORY_NOT_EMPTY -- ENOTEMPTY.
- git seems to be prepared for such a case, the parent process calls
opendir/readdir on the directory. Enumerating the files in
Z:\pic32mx-bmf\.git\objects\30 shows the entries ., .. and
0bdeb2fd209d24afb865584da10b78aa8fefc4.
- Then git calls lstat on the file, which results in NtOpenFile
returning status STATUS_OBJECT_NAME_NOT_FOUND again.
- From a POSIX POV this means somebody else deleted the file,
so the dir is empty now. Git tries to delete the directory again,
which again results in STATUS_DIRECTORY_NOT_EMPTY -- ENOTEMPTY
and, internally, a sharing violation which disallows to move the
directory out of the way.
This looks suspiciously like a bug in the remote filesystem. Link
succeeded, so there are two links to the same file in the directory.
Unlinking link 1 succeeds, so there's still one link to the
file in the
directory, but link 2 is inaccessible as if the file has
been deleted
completely. Thus, a full POSIX git on this drive is broken.
Can you please run
/usr/lib/csih/getVolInfo /cygdrive/z
and paste the output here? Maybe I can workaround this in the next
Cygwin version.
Dave's response: https://www.cygwin.com/ml/cygwin/2014-12/msg00066.html
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
-
Re: [PATCH] introduce git root
On Fri, Dec 5, 2014 at 10:27 AM, Jeff King p...@peff.net wrote: On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote: I do not think git var --exec-path is a good idea, nor GIT_EXEC_PATH for the environment-variable confusion you mentioned. I was thinking of just creating a new namespace, like: git var exec-path git var author-ident I agree that this is nice, but I wonder what we would do for the sequence editor and the default editor. Maybe: git var sequence-editor git var editor Again, I think we're mostly agreeing. Context and hierarchy and falling back are good things. Whatever we call the variables, editor and sequence-editor and foo-editor should have a predictable and consistent form. I like the idea of foo-editor automatically falling back to editor even if we don't know what foo is. Yeah but that means that we have to use something other than - to separate the context from the name, because we already have names like exec-path, html-path and man-path. But the one place I do not agree is: I think sequence.editor and core.editor are better because: - they use the same syntax as the config variables, so they are easier to remember and to discover, and I really don't like using core.editor here, because it has the same name as a config variable, but it is _not_ the config variable. It happens to use the config variable as one of the inputs to its computation, but in many cases: git config core.editor and git var core.editor will produce different values. Yeah, but I don't think it is a problem. They are different commands, so it can be expected that they do different things. For example, if you use git log origin/master you get a different ouput than if you use git show origin/master, though you still use the same origin/master notation. When you use git show you consider only the commit pointed to by origin/master and when you use git log you consider the same commit but also all its ancestors. In the same way, when you use git config core.editor you consider only the value of the core.editor logical variable in the config files, while when you would use git var core.editor you would consider the value of the core.editor logical variable in both the config files and the environment variables. They are entirely different namespaces. Using the same syntax and name seems unnecessarily confusing to me. Even still using dotted hierarchies, but giving them different names (e.g., editor, editor.sequence, editor.foo) would make it more obvious that they are not the same thing. Using yet another namespace or syntax when we could reuse an existing one is what would seem unnecessarily confusing to me. The value of the editor logical variable in the sequence context is related to the sequence.editor logical value in the config file, because the later can directly influence the former. So there is a reason to use the same notation. Best, Christian. -- 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] git-svn: Support for git-svn propset
Alfred Perlstein alf...@freebsd.org wrote:
This change allows git-svn to support setting subversion properties.
Very useful for manually setting properties when committing to a
subversion repo that *requires* properties to be set without requiring
moving your changeset to separate subversion checkout in order to
set props.
This change is initially from David Fraser davidf () sjsoft ! com
No point to obfuscate email addresses in commit messages (especially
it's also in the Signed-off-by :).
Appearing here:
http://marc.info/?l=gitm=125259772625008w=2
They are now forward ported to most recent git along with fixes to
deal with files in subdirectories.
Style and functional changes from Eric Wong have been taken
in thier entirety from:
s/thier/their/
http://marc.info/?l=gitm=141742735608544w=2
Fwiw, I prefer equivalent mid.gmane.org links since the message-ID
remains useful if the web server ever goes away. e.g.:
http://mid.gmane.org/20141201094911.ga13...@dcvr.yhbt.net
Reviewed-by: Eric Wong normalper...@yhbt.net
Signed-off-by: Alfred Perlstein alf...@freebsd.org
Signed-off-by: David Fraser dav...@sjsoft.com
I'd like to squash in the following changes (in order of importance):
- use to chain commands throughout tests
- use svn_cmd wrapper throughout tests
- show $! in die messages
- favor $(...) over `...` in tests
- make new_props an array simplify building the final list
- wrap long comments (help output still needs fixing)
- remove unnecessary FIXME comment
No need to resend if you're OK with these things. Thanks again.
diff --git a/git-svn.perl b/git-svn.perl
index 5cdbf39..ec5cee4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1392,9 +1392,9 @@ sub cmd_propset {
my $file = basename($path);
my $dn = dirname($path);
my $cur_props = Git::SVN::Editor::check_attr( svn-properties, $path );
- my $new_props = ;
+ my @new_props;
if ($cur_props eq unset || $cur_props eq || $cur_props eq set) {
- $new_props = $propname=$propval;
+ push @new_props, $propname=$propval;
} else {
# TODO: handle combining properties better
my @props = split(/;/, $cur_props);
@@ -1403,24 +1403,24 @@ sub cmd_propset {
# Parse 'name=value' syntax and set the property.
if ($prop =~ /([^=]+)=(.*)/) {
my ($n,$v) = ($1,$2);
- if ($n eq $propname)
- {
+ if ($n eq $propname) {
$v = $propval;
$replaced_prop = 1;
}
- if ($new_props eq ) { $new_props=$n=$v; }
- else { $new_props=$new_props;$n=$v; }
+ push @new_props, $n=$v;
}
}
if (!$replaced_prop) {
- $new_props = $new_props;$propname=$propval;
+ push @new_props, $propname=$propval;
}
}
my $attrfile = $dn/.gitattributes;
open my $attrfh, '', $attrfile or die Can't open $attrfile: $!\n;
# TODO: don't simply append here if $file already has svn-properties
- print $attrfh $file svn-properties=$new_props\n or die write to
$attrfile;
- close $attrfh or die close $attrfile;
+ my $new_props = join(';', @new_props);
+ print $attrfh $file svn-properties=$new_props\n or
+ die write to $attrfile: $!\n;
+ close $attrfh or die close $attrfile: $!\n;
}
# cmd_proplist (PATH)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index dd15318..8bed2d9 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -288,8 +288,7 @@ sub apply_autoprops {
}
}
-sub check_attr
-{
+sub check_attr {
my ($attr,$path) = @_;
my $fh = command_output_pipe(check-attr, $attr, --, $path);
return undef if (!$fh);
@@ -306,10 +305,12 @@ sub apply_manualprops {
if ($pending_properties eq ) { return; }
# Parse the list of properties to set.
my @props = split(/;/, $pending_properties);
- # TODO: get existing properties to compare to - this fails for add so
currently not done
+ # TODO: get existing properties to compare to
+ # - this fails for add so currently not done
# my $existing_props = ::get_svnprops($file);
my $existing_props = {};
- # TODO: caching svn properties or storing them in .gitattributes would
make that faster
+ # TODO: caching svn properties or storing them in .gitattributes
+ # would make that faster
foreach my $prop (@props) {
# Parse 'name=value' syntax and set the property.
if ($prop =~ /([^=]+)=(.*)/) {
@@ -317,8 +318,6 @@ sub
Re: [PATCH] git-svn: Support for git-svn propset
diff --git a/t/t9148-git-svn-propset.sh b/t/t9148-git-svn-propset.sh
new file mode 100755
index 000..b36a8a2
--- /dev/null
+++ b/t/t9148-git-svn-propset.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+#
+# Copyright (c) 2014 Alfred Perlstein
+#
+
+test_description='git svn propset tests'
+
+. ./lib-git-svn.sh
+
+foo_subdir2=subdir/subdir2/foo_subdir2
+
In case something goes wrong (for whatever reason):
do we need a chain here ?
+mkdir import
+(cd import
+ mkdir subdir
+ mkdir subdir/subdir2
+ touch foo # for 'add props top level'
touch foo can be written shorter:
foo
+ touch subdir/foo_subdir # for 'add props relative'
+ touch $foo_subdir2# for 'add props subdir'
+ svn_cmd import -m 'import for git svn' . $svnrepo /dev/null
+)
+rm -rf import
+
+test_expect_success 'initialize git svn' 'git svn init $svnrepo'
+test_expect_success 'fetch revisions from svn' 'git svn fetch'
This may look a little bit strange, 2 times test_expect_success in a row,
is the indentention OK ?
+
+# There is a bogus feature about svn propset which means that it will only
+# be taken as a delta for svn dcommit iff the file is also modified.
+# That is fine for now.
there is a bogus feature ?
Small typo: s/iff/if/
How about this:
#The current implementation has a restriction:
#svn propset will be taken as a delta for svn dcommit only
#if the file content is also modified
+test_expect_success 'add props top level' '
+ git svn propset svn:keywords FreeBSD=%H foo
+ echo hello foo
+ git commit -m testing propset foo
+ git svn dcommit
+ svn_cmd co $svnrepo svn_project
+ (cd svn_project test `svn propget svn:keywords foo` =
FreeBSD=%H)
+ rm -rf svn_project
+ '
Is there a reason why there is no after git svn dcommit ?
If yes, it could be better to make this really clear to the readers and write
(This idea is stolen from Peff)
{ git svn dcommit || true }
+
+test_expect_success 'add multiple props' '
+ git svn propset svn:keywords FreeBSD=%H foo
+ git svn propset fbsd:nokeywords yes foo
+ echo hello foo
+ git commit -m testing propset foo
+ git svn dcommit
+ svn_cmd co $svnrepo svn_project
+ (cd svn_project test `svn propget svn:keywords foo` =
FreeBSD=%H)
+ (cd svn_project test `svn propget fbsd:nokeywords foo` = yes)
+ (cd svn_project test `svn proplist -q foo | wc -l` -eq 2)
+ rm -rf svn_project
+ '
+
Ah, another small thing:
the wc -l will not work under Mac OS X.
Please see test_line_count() in t/test-lib-functions.sh
And thanks for improving Git
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Sat, Dec 06, 2014 at 02:06:08PM +0100, Jens Lehmann wrote: Am 05.12.2014 um 07:32 schrieb Max Kirillov: Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable submodule.updateIgnoringConfigUrl (because usually the submodule.name.url is what turns on the update). It looks working, maybe I even add setting the variable when chackout --to is used. But it's not only submodule.name.url, the list goes on with update, fetch ignore and then there are the global options like diff.submodule, diff.ignoreSubmodules and some more. I believe that parameters are important for some use, but I know several tesns of git users who have no idea bout them, and I myself only learned about them while working on this. To have some a submodule not initialized in some sorktree is what I really need. I was sure before it is managed by having the submodule checked out. Probably I just did not run `submodule update` in the worktree where did not use submodules, but I cannot rely on it. I see now from 211b7f19c7 that adding parameter for all updates will break the initalization. Maybe it would be better to have a runtime argument: `git submodule update --ignore-config-url` Thanks to you and Duy for discussing this with me! I'd sum it up like this: *) Multiple worktrees are meant to couple separate worktrees with a single repository to avoid having to push and fetch each time to sync refs and also to not having to sync settings manually (with the benefit of some disk space savings). That's a cool feature and explains why a branch should be protected against being modified in different worktrees. I should notify that I am not the author of the feature, maybe Duy have some other vision. The first level submodule settings are shared between the multiple worktrees; submodule objects, settings and refs aren't (because the .git/modules directory isn't shared). Looks like that would work with just what we have now, no? Yes, very much like what I proposed in $gmane/258173, but I need to have something about preventing checkout. And I should review what I've done since that, maybe there are more things to fix. *) I'd love to see a solution for sharing the object database between otherwise unrelated clones of the same project (so that fetching in one clone updates the objects in the common dir and gc cannot throw anything away used by one of the clones). But I'd expect a bare repository as the common one where we put the worktrees refs into their own namespaces. There is a GIT_NAMESPACE already, maybe it should be just extended to work with all commands? btw, have you tried alternates? It does reduce the number of objects you need to keep very strongly. You can put in the alternate store only released branches which are guaranteed to be not force-updated, to avoid issues with missing objects, and it still helps. For example, the full git repository takes about 70mb, and if I put master to alternate store, the rest takes 7mb, and even if I clone all original repository, debian repository and msysgit repository, thay all take 15mb. It's without worktree, which takes 27mb :) -- Max -- 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: Accept-language test fails on Mac OS
Thank you for providing useful information to fix the failures.
On Sun, Dec 7, 2014 at 6:04 AM, Torsten Bögershausen tbo...@web.de wrote:
On 2014-12-06 20.44, Yi, EungJun wrote:
Could you tell me your locale information from executing 'locale'
command and the verbose message you can get by accessing any git
repository via HTTP protocol? (e.g. GIT_CURL_VERBOSE=1 git clone
http://github.com/foo/bar )
locale -a
C
C.UTF-8
en_US.utf8
icelandic
is_IS
is_IS.iso88591
is_IS.utf8
POSIX
I'm sorry for bothering you, but could you tell me the result of
locale command without -a option? What I want to know is locale
environment variables and its values, so I want to reproduce the test
failures on my laptop.
-
After patching like this:
diff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh
index fc6e7fc..1e42b42 100755
--- a/t/t5550-http-fetch-dumb.sh
+++ b/t/t5550-http-fetch-dumb.sh
@@ -205,8 +205,8 @@ check_language () {
LANG=$5 \
git ls-remote $HTTPD_URL/dumb/repo.git 21 |
tr -d '\015' |
- sort -u stderr
- grep -i ^Accept-Language: stderr actual
+ sort -u stderr
+ grep -i ^Accept-Language: stderr actual
test_cmp expect actual
}
---
I get this:
expecting success:
check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language de-DE, *;q=0.1 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language ja-JP, *;q=0.1 ja_JP.UTF-8
en_US.UTF-8
check_language en-US, *;q=0.1
en_US.UTF-8
--- expect 2014-12-06 21:00:59.0 +
+++ actual 2014-12-06 21:00:59.0 +
@@ -1 +0,0 @@
-Accept-Language: de-DE, *;q=0.1
not ok 25 - git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG
#
# check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language de-DE, *;q=0.1 de_DE.UTF-8
ja_JP.UTF-8 en_US.UTF-8
# check_language ja-JP, *;q=0.1
ja_JP.UTF-8 en_US.UTF-8
# check_language en-US, *;q=0.1
en_US.UTF-8
#
The test seems to fail if LANGUAGE=. I will dig it. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Accept-language test fails on Mac OS
On Sat, Dec 06, 2014 at 10:04:06PM +0100, Torsten Bögershausen wrote:
I get this:
expecting success:
check_language ko-KR, *;q=0.1 ko_KR.UTF-8 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language de-DE, *;q=0.1 de_DE.UTF-8 ja_JP.UTF-8
en_US.UTF-8
check_language ja-JP, *;q=0.1 ja_JP.UTF-8
en_US.UTF-8
check_language en-US, *;q=0.1
en_US.UTF-8
--- expect 2014-12-06 21:00:59.0 +
+++ actual 2014-12-06 21:00:59.0 +
@@ -1 +0,0 @@
-Accept-Language: de-DE, *;q=0.1
not ok 25 - git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG
I can reproduce the same problem here (Debian unstable). I actually ran
into three issues (aside from needing to use Junio's SQUASH commit, to
avoid the \r bash-ism):
1. I couldn't build without including locale.h, for the
definition of setlocale() and the LC_MESSAGES constant (both used
in get_preferred_languages).
I'm not sure what portability issues there are with including it
unconditionally. Should this possibly be tied into gettext.c, which
already uses setlocale?
2. The call to setlocale(LC_MESSAGES, NULL) in get_preferred_languages
always returns C for me. This seems related to building with
NO_GETTEXT (which I typically do), as we never init setlocale
if NO_GETTEXT is set. This program demonstrates it:
#include stdio.h
#include string.h
#include locale.h
int main(int argc, char **argv)
{
if (argv[1] !strcmp(argv[1], init))
setlocale(LC_MESSAGES, );
printf(%s, setlocale(LC_MESSAGES, NULL));
return 0;
}
If I run it as LANG=en_US.UTF-8 ./a.out, it prints C. If I run
it as LANG=en_US.UTF-8 ./a.out init, it prints en_US.UTF-8. I
think we either need to start unconditionally calling setlocale()
as we do in git_setup_gettext, or we need to tie your feature to
using gettext.
This is what causes the failure of the de-DE test for me; building
without NO_GETTEXT makes it work. Note that this doesn't affect the
first test for ko-KR, because that test sets LANGUAGE, which we
read ourselves (so we never make a setlocale() call).
3. Even building with NO_GETTEXT, setlocale() does not want to
report ja_JP.UTF-8 for me, making the third test fail.
I think the issue is that I do not build the ja_JP locale on my
system. Running dpkg-reconfigure locales and asking it to build
ja_JP.UTF-8 makes the test pass. This is somewhat of a Debian-ism.
From man locale-gen:
By default, the locale package which provides the base support
for localisation of libc-based programs does not contain usable
localisation files for every supported language. This limitation
has became necessary because of the substantial size of such
files and the large number of languages supported by libc. As a
result, Debian uses a special mechanism where we prepare the
actual localisation files on the target host and distribute only
the templates for them.
I suspect it is inherited by Debian derivatives like Ubuntu. But I
also don't know that we can count on other platforms having all of
the locales either (e.g., they may ship them as separate packages,
not all of which are installed).
So I'm not sure of an easy way around this. You want 4 separate
locales to thoroughly test, but you cannot rely on any particular
locale being present on the user's system.
Note that this is just a problem with the tests, probably not with
the feature itself. Presumably people setting LANG=ja_JP actually
have that locale on their system (though technically this feature
is about asking the _server_ to use that language, it seems like
you would do so because you were using that language locally, too).
-Peff
--
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
