Re: Accept-language test fails on Mac OS

[Jeff King]

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 
#include 
#include 

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

Re: Accept-language test fails on Mac OS

[Yi, EungJun]

Thank you for providing useful information to fix the failures.

On Sun, Dec 7, 2014 at 6:04 AM, Torsten Bögershausen  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" 2>&1 |
> 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: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

[Max Kirillov]

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..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..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: [PATCH] git-svn: Support for git-svn propset

[Torsten Bögershausen]

> 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] git-svn: Support for git-svn propset

[Eric Wong]

Alfred Perlstein  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 

No point to obfuscate email addresses in commit messages (especially
it's also in the Signed-off-by :).

> Appearing here:
>   http://marc.info/?l=git&m=125259772625008&w=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=git&m=141742735608544&w=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 
> Signed-off-by: Alfred Perlstein 
> Signed-off-by: David Fraser 

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 apply_manualprops {

Re: [PATCH] introduce git root

[Christian Couder]

On Fri, Dec 5, 2014 at 10:27 AM, Jeff King  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: FW: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"

[Jason Pyeron]

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



> 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.



> > -Original Message-
> > From: Corinna Vinschen
> > Sent: Friday, December 05, 2014 6:35
> > To: cyg...@cygwin.com
> 
> > 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

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -

Re: How to repair a shallow clone (?)

[Trần Ngọc Quân]

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

[PATCH] git-svn: Support for git-svn propset

[Alfred Perlstein]

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 
Appearing here:
  http://marc.info/?l=git&m=125259772625008&w=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=git&m=141742735608544&w=2

Reviewed-by: Eric Wong 
Signed-off-by: Alfred Perlstein 
Signed-off-by: David Fraser 
---
 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 ($attr,$path) = @_;
+   my $fh

[PATCH] git-svn: propset support v2

[Alfred Perlstein]

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

Re: Accept-language test fails on Mac OS

[Torsten Bögershausen]

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" 2>&1 |
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

Re: Accept-language test fails on Mac OS

[Yi, EungJun]

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  wrote:
> On 2014-12-06 00.01, Michael Blume wrote:
>> On Fri, Dec 5, 2014 at 2:51 PM, Junio C Hamano  wrote:
>>> Michael Blume  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: [PATCH] l10n: de.po: translate "track" as "versionieren"

[Ralf Thielow]

Hi Phillip

Am 6. Dezember 2014 um 20:34 schrieb phillip :
>
>
> 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

[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: Роман Донченко 
---
 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"

[phillip]

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  wrote:
>Suggested-by: Torsten Bögershausen 
>Signed-off-by: Ralf Thielow 
>---
> 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"
>@@ 

[PATCH] l10n: de.po: translate "track" as "versionieren"

[Ralf Thielow]

Suggested-by: Torsten Bögershausen 
Signed-off-by: Ralf Thielow 
---
 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:

Re: Enhancement Request: "locale" git option

[Ralf Thielow]

2014-12-05 16:45 GMT+01:00 Torsten Bögershausen :
>
> I do not know who was first, and who came later, but
> 
>
> 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

Re: Cannot reset a repo

[Martin Wendt]

> Am 06.12.2014 um 13:14 schrieb Torsten Bögershausen :
> 
> 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: Fetching a specific commit by commit ID

[brian m. carlson]

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

[PATCH v2] Improve --assume-unchanged in the git update-index man page

[Philip Oakley]

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

[PATCH v2] doc: make clear --assume-unchanged's user contract

[Philip Oakley]

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 
---
 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

Re: bug report on update-index --assume-unchanged

[Philip Oakley]

From: "Sérgio Basto" 
[..]

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

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

[Jens Lehmann]

Am 05.12.2014 um 07:32 schrieb Max Kirillov:

On Thu, Dec 4, 2014 at 10:06 PM, Jens Lehmann  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..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..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: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

[Jens Lehmann]

Am 05.12.2014 um 02:33 schrieb Duy Nguyen:

On Fri, Dec 5, 2014 at 3:06 AM, Jens Lehmann  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..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 /.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

Fetching a specific commit by commit ID

[Olivier Croquette]

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

How to repair a shallow clone (?)

[Torsten Bögershausen]

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

Re: Cannot reset a repo

[Torsten Bögershausen]

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

Cannot reset a repo

[Martin Wendt]

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: Accept-language test fails on Mac OS

[Torsten Bögershausen]

On 2014-12-06 00.01, Michael Blume wrote:
> On Fri, Dec 5, 2014 at 2:51 PM, Junio C Hamano  wrote:
>> Michael Blume  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