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

[Torsten Bögershausen]

On 2014-12-07 06.45, Torsten Bögershausen wrote:
[]
>> +
>> +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
> 
My excuse:
I think I am wrong here and I need to correct myself after having looked at 
other TC's.
The "wc -l" should work under Mac OS X.

Another small nit:

This 
"`svn propget svn:keywords foo`" = "FreeBSD=%H")
can be written as
"$(svn propget svn:keywords foo)" = "FreeBSD=%H")

(if you want to use the "Git style" for command substitution)

--
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 Sun, Dec 07, 2014 at 08:42:30AM +0200, Max Kirillov wrote:
>> *) 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?

No, this will not work for submodules, has same issues with
the same config.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

[Jeff King]

On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote:

> The RFC says that they are to be concatenated after decoding (i.e. the
> intervening whitespace is ignored).

Thanks. Both patches look good to me, and I'd be happy to have them
applied as-is. I wrote a few comments below, but in all cases I think I
convinced myself that what you wrote is best.

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

It feels a little weird to have to split and rematch $re_encoded_word in
the loop, but I don't think there is a way around it. ($1, $2, $3) will
have our first word, and ($4, $5, $6) will have the final (if any), but
I don't think we can get access to what is in between.

So I think what you have here is the best we can do.

> + if ($encoding eq 'q' || $encoding eq 'Q') {
> + $_ = $text;
> + s/_/ /g;
> + s/=([0-9A-F]{2})/chr(hex($1))/egi;

It took me a minute to figure out why this works. $_ is a reference to
the iterator for @words, so it is re-assigning that element of the array
first to the encoded text, and then modifying it in place.

I wonder if it would be more obvious like this:

  join '',
  map {
  m/$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;
  } else {
# other encoding not supported yet
  }
  } split($sep, $&);


I dunno. I kind of like your version better now that I understand it,
but it did take me a minute.

One final note on this bit of code: if there are multiple encoded words,
we grab the $charset from the final encoded word, and never report the
earlier charsets. Technically they do not all have to be the same
(rfc2047 even has an example where they are not). I think we can dismiss
this, though, as:

  1. It was like this before your patches (we might have seen multiple
 non-adjacent encoded words; you're just handling adjacent ones),
 and nobody has complained.

  2. Using two separate encodings in the same header is sufficiently
 ridiculous that I can live with us not handling it properly.

> +# 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'
> +"

Cute. :)

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

[Eric Sunshine]

On Sun, Dec 7, 2014 at 3:00 AM, Torsten Bögershausen  wrote:
> On 2014-12-07 06.45, Torsten Bögershausen wrote:
> []
>>> +
>>> +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
>>
> My excuse:
> I think I am wrong here and I need to correct myself after having looked at 
> other TC's.
> The "wc -l" should work under Mac OS X.

More specifically: On Mac OS X, "wc -l" outputs "{whitespace}number"
which won't match "2" with the string '=' operator, however, this case
works because the '-eq' operator coerces the output of "wc -l" to a
number, which can match the 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: [PATCH] git-svn: propset support v2

[Eric Sunshine]

On Sat, Dec 6, 2014 at 5:29 PM, Alfred Perlstein  wrote:
> I have incorporated Eric Wong's feedback into the git-svn propset support 
> patch.
>
> 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.

This is an important nugget of information which would be worthwhile
to mention in the commit message of the patch rather than here as mere
commentary.

> 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.
--
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 07.12.14 07:54, Yi, EungJun wrote:
> 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.
> 
(Just for completeness:)
 locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=



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

On 12/6/14, 9:42 PM, Eric Wong wrote:

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.
Hmm, I refactored tests because it bothered me that I had done all that 
cut and pasting, in doing so I found and fixed a bug with uninitialized 
variables in the check_attr() function.


Let me send my final diff, I will try to properly incorporate your 
changes as well in that diff.


-Alfred




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 fast

Re: Accept-language test fails on Mac OS

[Torsten Bögershausen]

On 07.12.14 08:18, Jeff King wrote:
> 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
> --
(I remember debugging t0204 some time ago)

We may get inspiration from this, either how to adjust the locale to be used,
or if the test should be skipped.

 grep -l is_IS *
lib-gettext.sh
t0200-gettext-basic.sh
t0203-gettext-setlocale-sanity.sh
t0204-gettext-reencode-sanity.sh

--
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] doc: document error handling functions and conventions (Re: [PATCH 03/14] copy_fd: pass error message back through a strbuf)

[Jeff King]

On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > The only downside I can think of is that we may truncate the message in
> > exceptional circumstances. But is it really any less helpful to say:
> >
> >   error: unable to open file: some-incredibly-long-filename-aa...
> >
> > than printing out an extra 100 lines of "a"? And I mean the "..."
> > literally. I think mkerror() should indicate the truncation with a
> > "...", just so that it is clear to the user. It should almost never
> > happen, but when it does, it can be helpful to show the user that yes,
> > we know we are truncating the message, and it is not that git truncated
> > your filename during the operation.
> >
> > Is this truncation really a concern, and/or is there some other downside
> > I'm not thinking of?
> 
> I am more worried about variable length part pushing the information
> that is given later out to the right, e.g. "error: missing file '%s'
> prevents us from doing X".  Chomping to [1024] is not a good
> strategy for that kind of message; abbreviating %s to /path/name/...
> (again, with literally "...") would be.

True. Unfortunately I do not think there is an easy way to truncate the
expanded strings used by placeholders. The two approaches I could think
of are:

  1. Loop over the va_list and tweak any pointers we find. Except that
 loop means we actually need to loop over the _format string_, since
 that is the only thing which tells us which placeholders are strings.
 But I am not even sure there is a portable way to munge a va_list,
 as opposed to just reading it.

  2. Transparently rewrite '%s' in the format string to '%.128s' or
 similar. This also requires iterating over the format string, but
 it's fairly straightforward. Code is below, but it's not _quite_
 right. We would want to conditionally add "..." based on whether or
 not the particular item was truncated. But we cannot know when
 munging the format string if that will happen or not (we know
 _something_ will be truncated, but not which string).

I don't think you can do it right without reimplementing vsnprintf
yourself. Which is obviously a terrible idea.

I still think truncation is going to be a non-issue in practice, and I'd
rather deal with that potential fallout than have to deal with memory
management in every error handler that uses this technique. But I don't
have much more to say on the matter, so if you disagree, I guess that's
that.

Unless we can do something clever with a set of global error strbufs or
something (i.e., that expand as needed, but the caller does not have to
free themselves, as they will get recycled eventually). That has its own
corner cases, though.

Anyway, the truncating-fmt code is below, for fun.

-Peff

static int abbrev_fmt(char *buf, int len, int abbrev, const char *fmt, va_list 
ap)
{
va_list cp;
int got;

va_copy(cp, ap);
got = vsnprintf(buf, len, fmt, ap);
if (got >= len) {
struct strbuf munged = STRBUF_INIT;

while (*fmt) {
char ch = *fmt++;
strbuf_addch(&munged, ch);
if (ch == '%') {
if (*fmt == 's') {
strbuf_addf(&munged, ".%ds...", abbrev);
fmt++;
} else /* skips past %%-quoting */
strbuf_addch(&munged, *fmt);
}
}

got = vsnprintf(buf, len, munged.buf, cp);
strbuf_release(&munged);
}
return got;
}
--
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

[Olivier Croquette]

On 06 Dec 2014, at 16:52, brian m. carlson  wrote:

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

Shouldn’t these checks be implemented in the layers above, eg. in gitolite, 
gitosis, gerrit… ? Having it in git itself makes it impossible in all cases, 
even for projects/repositories with no ref-specific read restrictions (the vast 
majority of projects, I would guess).

It seems pretty straightforward to support access control in these layers. If a 
commit id is provided, go through all references of the repository, if one is 
found that is a child of the given commit, and the user has access to the ref, 
then it’s ok to fetch the commit. Of course it’s an expensive operation, but 
it’s is rarely required.

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

[Alfred Perlstein]

Added:

Eric Sunshine's:
- suggestion to include the comment about propset only
  working on files with content changes.

Eric Wong's:
- 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
- commit message improvements.

Torsten B??gershausen:
- Fixes for test cases.

Finally, I have refactored the test cases to reduce duplicate code
such that further fixes and improvements can be done in one place.


JFYI, branches are here:
1st review changes:
  https://github.com/splbio/git/compare/master-git-svn-propset-upstream?expand=1
Squashed into:
  
https://github.com/splbio/git/compare/master-git-svn-propset-upstream-one-diff?expand=1

Current review in different commits:
  
https://github.com/splbio/git/compare/master-git-svn-propset-upstream2?expand=1
Squashed into:
  
https://github.com/splbio/git/compare/master-git-svn-propset-upstream-one-diff2?expand=1
  
Thank you very much.


Alfred Perlstein (1):
  git-svn: Support for git-svn propset

 git-svn.perl   | 49 ++-
 perl/Git/SVN/Editor.pm | 42 
 t/t9148-git-svn-propset.sh | 97 ++
 3 files changed, 187 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

[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 their entirety from:
  http://mid.gmane.org/20141201094911.ga13...@dcvr.yhbt.net

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.

Reviewed-by: Eric Wong 
Signed-off-by: Alfred Perlstein 
Signed-off-by: David Fraser 
---
 git-svn.perl   | 49 ++-
 perl/Git/SVN/Editor.pm | 42 
 t/t9148-git-svn-propset.sh | 97 ++
 3 files changed, 187 insertions(+), 1 deletion(-)
 create mode 100755 t/t9148-git-svn-propset.sh

diff --git a/git-svn.perl b/git-svn.perl
index b6e2186..60f8814 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 || $cur_props eq "unset" || $cur_props eq "" || 
$cur_props eq "set") {
+   push @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;
+   }
+   push @new_props, "$n=$v";
+   }
+   }
+   if (!$replaced_prop) {
+   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
+   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)
 # ---
 # Print the list of SVN properties for PATH.
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 34e8af9..b84ce13 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Edi

Re: How to repair a shallow clone (?)

[Philip Oakley]

From: "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).

Since v1.9.0 (14 Feb '14.) you can do various push/pull from a shallow 
clone (I'd asked this way back 
http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone 
and noted when it was corrected/improved)


That's not to say that you don't have to take care about your local 
depth being sufficiently inclusive.


I'm sure that sometime a --timedepth= will eventually be 
coded by someone sufficiently in need. ;-)


--
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: How to repair a shallow clone (?)

[Duy Nguyen]

On Sat, Dec 6, 2014 at 7:23 PM, Torsten Bögershausen  wrote:
> 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

Please try again with $GIT_TRACE_PACKET=/some-log-file. receive-pack
>2.0 should recognize this shallow line.

> Is this a known issue/problem ?

No.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git push hung?

[Jason Pyeron]

I am trying to push to our local intranet git (smart https behind apache), and 
it has been at this point for 10+ hours.

jpyeron@black /projects/git/git
$ GIT_TRACE=1 git push
09:08:45.662902 git.c:349   trace: built-in: git 'push'
09:08:45.662902 run-command.c:341   trace: run_command: 'git-remote-https' 
'origin' 'https://intranet.pdinc.us/git/git/'
09:08:46.225700 run-command.c:341   trace: run_command: 'git 
credential-cache --timeout=999 get'
09:08:46.256967 run-command.c:192   trace: exec: '/bin/sh' '-c' 'git 
credential-cache --timeout=999 get' 'git credential-cache 
--timeout=999 get'
09:08:46.366400 git.c:554   trace: exec: 'git-credential-cache' 
'--timeout=999' 'get'
09:08:46.366400 run-command.c:341   trace: run_command: 
'git-credential-cache' '--timeout=999' 'get'
09:08:47.022999 run-command.c:341   trace: run_command: 'git 
credential-cache --timeout=999 store'
09:08:47.038632 run-command.c:192   trace: exec: '/bin/sh' '-c' 'git 
credential-cache --timeout=999 store' 'git credential-cache 
--timeout=999 store'
09:08:47.116799 git.c:554   trace: exec: 'git-credential-cache' 
'--timeout=999' 'store'
09:08:47.116799 run-command.c:341   trace: run_command: 
'git-credential-cache' '--timeout=999' 'store'
09:08:47.366931 run-command.c:341   trace: run_command: 'send-pack' 
'--stateless-rpc' '--helper-status' '--thin' '--progress' 
'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master'
09:08:47.382565 exec_cmd.c:134  trace: exec: 'git' 'send-pack' 
'--stateless-rpc' '--helper-status' '--thin' '--progress' 
'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master'
09:08:47.429465 git.c:349   trace: built-in: git 'send-pack' 
'--stateless-rpc' '--helper-status' '--thin' '--progress' 
'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master'
09:08:47.538898 run-command.c:341   trace: run_command: 'pack-objects' 
'--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' 
'--progress'
09:08:47.695231 exec_cmd.c:134  trace: exec: 'git' 'pack-objects' 
'--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' 
'--progress'
09:08:47.742131 git.c:349   trace: built-in: git 'pack-objects' 
'--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' 
'--progress'
Counting objects: 18734, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5707/5707), done.
Writing objects: 100% (18734/18734), 9.37 MiB | 0 bytes/s, done.
Total 18734 (delta 14519), reused 17108 (delta 12968)

Servier died, this is in the log:

fatal: protocol error: expected old/new/ref, got 'shallow 
3339e9f686bd4c17e3575c71327c4ccf1e8e077b'

What steps can I take to debug this hang in the client?

Git fetch hangs the same way with a server exit of fatal: did not find object 
for shallow 3339e9f686bd4c17e3575c71327c4ccf1e8e077b

Note: I fixed the underlying problem with a git fetch --unshallow upstream

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

[Роман Донченко]

Jeff King  писал в своём письме Sun, 07 Dec 2014 12:18:59  
+0300:



On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote:


The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).


Thanks. Both patches look good to me, and I'd be happy to have them
applied as-is. I wrote a few comments below, but in all cases I think I
convinced myself that what you wrote is best.


I had the same concerns myself, and eventually convinced myself of the  
same. :-)



One final note on this bit of code: if there are multiple encoded words,
we grab the $charset from the final encoded word, and never report the
earlier charsets. Technically they do not all have to be the same
(rfc2047 even has an example where they are not). I think we can dismiss
this, though, as:

  1. It was like this before your patches (we might have seen multiple
 non-adjacent encoded words; you're just handling adjacent ones),
 and nobody has complained.

  2. Using two separate encodings in the same header is sufficiently
 ridiculous that I can live with us not handling it properly.


Yeah, that bugs me as well. But I think handling multiple encodings would  
require substantial reworking of the code, so I chickened out (with the  
same excuses :-)).


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

arghh, sorry that's embarrassing. I was sure that the Mac filesystem was case 
sensitive by default, because it's unix based...
Thanks for your  support.

> Am 07.12.2014 um 11:06 schrieb Torsten Bögershausen :
> 
> On 06.12.14 14:39, Martin Wendt wrote:
>>> 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.
> Can you fix it a send a pull request to the author on github ?
>> 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: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

[Philip Oakley]

From: "Роман Донченко" 
Jeff King  писал в своём письме Sun, 07 Dec 2014 
12:18:59  +0300:



On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote:

The RFC says that they are to be concatenated after decoding (i.e. 
the

intervening whitespace is ignored).


Thanks. Both patches look good to me, and I'd be happy to have them
applied as-is. I wrote a few comments below, but in all cases I think 
I

convinced myself that what you wrote is best.


I had the same concerns myself, and eventually convinced myself of the 
same. :-)


One final note on this bit of code: if there are multiple encoded 
words,
we grab the $charset from the final encoded word, and never report 
the

earlier charsets. Technically they do not all have to be the same
(rfc2047 even has an example where they are not). I think we can 
dismiss

this, though, as:

  1. It was like this before your patches (we might have seen 
multiple

 non-adjacent encoded words; you're just handling adjacent ones),
 and nobody has complained.

  2. Using two separate encodings in the same header is sufficiently
 ridiculous that I can live with us not handling it properly.


Yeah, that bugs me as well. But I think handling multiple encodings 
would  require substantial reworking of the code, so I chickened out 
(with the  same excuses :-)).


Would that be worth a terse comment in the documentation change part of 
the patch?

"Multiple  (RFC2047) encodings are not supported.",
or would that be bike shed noise.

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: How to repair a shallow clone (?)

[Torsten Bögershausen]

On 2014-12-07 12.44, Duy Nguyen wrote:
>> Is this a known issue/problem ?
> 
> No.
> 
Thanks everybody for the support.

The machine was equipped with git version 1.7.10.4 in /usr/bin.

I installed 2.1 or so under /usr/local/bin, (and even /root/bin) 
thinking that this would help, but it didn't.

Because the login shell for the user "storage" which manages the push/pull
on the server side was /usr/bin/git-shell, not /usr/local/bin/git-shell.



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git push hung?

[Torsten Bögershausen]

On 2014-12-07 15.24, Jason Pyeron wrote:
> I am trying to push to our local intranet git (smart https behind apache), 
> and it has been at this point for 10+ hours.
> 
> jpyeron@black /projects/git/git
> $ GIT_TRACE=1 git push
> 09:08:45.662902 git.c:349   trace: built-in: git 'push'
> 09:08:45.662902 run-command.c:341   trace: run_command: 
> 'git-remote-https' 'origin' 'https://intranet.pdinc.us/git/git/'
> 09:08:46.225700 run-command.c:341   trace: run_command: 'git 
> credential-cache --timeout=999 get'
> 09:08:46.256967 run-command.c:192   trace: exec: '/bin/sh' '-c' 'git 
> credential-cache --timeout=999 get' 'git credential-cache 
> --timeout=999 get'
> 09:08:46.366400 git.c:554   trace: exec: 'git-credential-cache' 
> '--timeout=999' 'get'
> 09:08:46.366400 run-command.c:341   trace: run_command: 
> 'git-credential-cache' '--timeout=999' 'get'
> 09:08:47.022999 run-command.c:341   trace: run_command: 'git 
> credential-cache --timeout=999 store'
> 09:08:47.038632 run-command.c:192   trace: exec: '/bin/sh' '-c' 'git 
> credential-cache --timeout=999 store' 'git credential-cache 
> --timeout=999 store'
> 09:08:47.116799 git.c:554   trace: exec: 'git-credential-cache' 
> '--timeout=999' 'store'
> 09:08:47.116799 run-command.c:341   trace: run_command: 
> 'git-credential-cache' '--timeout=999' 'store'
> 09:08:47.366931 run-command.c:341   trace: run_command: 'send-pack' 
> '--stateless-rpc' '--helper-status' '--thin' '--progress' 
> 'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master'
> 09:08:47.382565 exec_cmd.c:134  trace: exec: 'git' 'send-pack' 
> '--stateless-rpc' '--helper-status' '--thin' '--progress' 
> 'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master'
> 09:08:47.429465 git.c:349   trace: built-in: git 'send-pack' 
> '--stateless-rpc' '--helper-status' '--thin' '--progress' 
> 'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master'
> 09:08:47.538898 run-command.c:341   trace: run_command: 'pack-objects' 
> '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' 
> '--progress'
> 09:08:47.695231 exec_cmd.c:134  trace: exec: 'git' 'pack-objects' 
> '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' 
> '--progress'
> 09:08:47.742131 git.c:349   trace: built-in: git 'pack-objects' 
> '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' 
> '--progress'
> Counting objects: 18734, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (5707/5707), done.
> Writing objects: 100% (18734/18734), 9.37 MiB | 0 bytes/s, done.
> Total 18734 (delta 14519), reused 17108 (delta 12968)
> 
> Servier died, this is in the log:
> 
> fatal: protocol error: expected old/new/ref, got 'shallow 
> 3339e9f686bd4c17e3575c71327c4ccf1e8e077b'
> 
> What steps can I take to debug this hang in the client?
> 
> Git fetch hangs the same way with a server exit of fatal: did not find object 
> for shallow 3339e9f686bd4c17e3575c71327c4ccf1e8e077b
> 
> Note: I fixed the underlying problem with a git fetch --unshallow upstream
>
Was the log above after the git fetch --unshallow upstream ?
What is the output if you run the following commands on the server:
git show 3339e9f686bd4c17e
git fsck
git --version
which git

(And what on the client)


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

[Роман Донченко]

Philip Oakley  писал в своём письме Sun, 07 Dec 2014  
20:48:05 +0300:



From: "Роман Донченко" 
Jeff King  писал в своём письме Sun, 07 Dec 2014  
12:18:59  +0300:



On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote:
One final note on this bit of code: if there are multiple encoded  
words,

we grab the $charset from the final encoded word, and never report the
earlier charsets. Technically they do not all have to be the same
(rfc2047 even has an example where they are not). I think we can  
dismiss

this, though, as:

  1. It was like this before your patches (we might have seen multiple
 non-adjacent encoded words; you're just handling adjacent ones),
 and nobody has complained.

  2. Using two separate encodings in the same header is sufficiently
 ridiculous that I can live with us not handling it properly.


Yeah, that bugs me as well. But I think handling multiple encodings  
would  require substantial reworking of the code, so I chickened out  
(with the  same excuses :-)).


Would that be worth a terse comment in the documentation change part of  
the patch?

"Multiple  (RFC2047) encodings are not supported.",
or would that be bike shed noise.


I didn't change any documentation... and in either case, they weren't  
supported in the first place, so I don't think it's anything I need to  
mention.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: git push hung?

[Jason Pyeron]

No cc's please, I am on the list.
> -Original Message-
> From: Torsten Bögershausen 
> Sent: Sunday, December 07, 2014 12:58
> 
> On 2014-12-07 15.24, Jason Pyeron wrote:
> > I am trying to push to our local intranet git (smart https 
> behind apache), and it has been at this point for 10+ hours.
> > 
> > jpyeron@black /projects/git/git
> > $ GIT_TRACE=1 git push
> > 09:08:45.662902 git.c:349   trace: built-in: git 'push'
> > 09:08:45.662902 run-command.c:341   trace: run_command: 
> 'git-remote-https' 'origin' 'https://intranet.pdinc.us/git/git/'
> > 09:08:46.225700 run-command.c:341   trace: run_command: 
> 'git credential-cache --timeout=999 get'
> > 09:08:46.256967 run-command.c:192   trace: exec: 
> '/bin/sh' '-c' 'git credential-cache --timeout=999 
> get' 'git credential-cache --timeout=999 get'
> > 09:08:46.366400 git.c:554   trace: exec: 
> 'git-credential-cache' '--timeout=999' 'get'
> > 09:08:46.366400 run-command.c:341   trace: run_command: 
> 'git-credential-cache' '--timeout=999' 'get'
> > 09:08:47.022999 run-command.c:341   trace: run_command: 
> 'git credential-cache --timeout=999 store'
> > 09:08:47.038632 run-command.c:192   trace: exec: 
> '/bin/sh' '-c' 'git credential-cache --timeout=999 
> store' 'git credential-cache --timeout=999 store'
> > 09:08:47.116799 git.c:554   trace: exec: 
> 'git-credential-cache' '--timeout=999' 'store'
> > 09:08:47.116799 run-command.c:341   trace: run_command: 
> 'git-credential-cache' '--timeout=999' 'store'
> > 09:08:47.366931 run-command.c:341   trace: run_command: 
> 'send-pack' '--stateless-rpc' '--helper-status' '--thin' 
> '--progress' 'https://intranet.pdinc.us/git/git/' 
> 'refs/heads/master:refs/heads/master'
> > 09:08:47.382565 exec_cmd.c:134  trace: exec: 'git' 
> 'send-pack' '--stateless-rpc' '--helper-status' '--thin' 
> '--progress' 'https://intranet.pdinc.us/git/git/' 
> 'refs/heads/master:refs/heads/master'
> > 09:08:47.429465 git.c:349   trace: built-in: 
> git 'send-pack' '--stateless-rpc' '--helper-status' '--thin' 
> '--progress' 'https://intranet.pdinc.us/git/git/' 
> 'refs/heads/master:refs/heads/master'
> > 09:08:47.538898 run-command.c:341   trace: run_command: 
> 'pack-objects' '--all-progress-implied' '--revs' '--stdout' 
> '--thin' '--delta-base-offset' '--progress'
> > 09:08:47.695231 exec_cmd.c:134  trace: exec: 'git' 
> 'pack-objects' '--all-progress-implied' '--revs' '--stdout' 
> '--thin' '--delta-base-offset' '--progress'
> > 09:08:47.742131 git.c:349   trace: built-in: 
> git 'pack-objects' '--all-progress-implied' '--revs' 
> '--stdout' '--thin' '--delta-base-offset' '--progress'
> > Counting objects: 18734, done.
> > Delta compression using up to 2 threads.
> > Compressing objects: 100% (5707/5707), done.
> > Writing objects: 100% (18734/18734), 9.37 MiB | 0 bytes/s, done.
> > Total 18734 (delta 14519), reused 17108 (delta 12968)
> > 
> > Servier died, this is in the log:
> > 
> > fatal: protocol error: expected old/new/ref, got 'shallow 
> 3339e9f686bd4c17e3575c71327c4ccf1e8e077b'
> > 
> > What steps can I take to debug this hang in the client?
> > 
> > Git fetch hangs the same way with a server exit of fatal: 
> did not find object for shallow 
> 3339e9f686bd4c17e3575c71327c4ccf1e8e077b
> > 
> > Note: I fixed the underlying problem with a git fetch 
> --unshallow upstream
> >
> Was the log above after the git fetch --unshallow upstream ?
> What is the output if you run the following commands on the server:

I will have to make a testcase, sice the underlying problem was fixed at the 
time.

> git show 3339e9f686bd4c17e

jpyeron@black /projects/git/git
$ git show 3339e9f686bd4c17e
commit 3339e9f686bd4c17e3575c71327c4ccf1e8e077b
Author: Nicolas Pitre 
Date:   Wed Jul 16 02:31:38 2008 -0400
...
> git fsck
jpyeron@black /projects/git/git
$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (188541/188541), done.
Checking connectivity: 183572, done.
> git --version
> which git
> 
> (And what on the client)

jpyeron@black /projects/git/git
$ git --version
git version 2.1.1

root@server /
# git --version
git version 1.7.9.6


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00. 

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

Re: [PATCH] Show number of commits being rebased interactively

[Onno Kortmann]

Hi,

> These lines above "---" will become the only log message text, which
> is probably not what you intended.  Use "-- >8 --" marker instead
> (that is a perforation line with a pair of scissors on it)?
Thanks, hopefully fixed below.

>> +commitcount=$(git stripspace --strip-comments <"$todo"  | wc -l)
>
> Does this count the number of commits?  I suspect it at least needs
> to filter "x|exec" out.
Very true - after reading this, I learned about the '-x' option
to git-rebase -i :-)
I changed the patch so it now properly looks for '^pick ' patterns. I
hope this should do the trick under all circumstances? In the case
of having 'exec' lines interspersed, the $commitcount becomes a lot
less useful (no comparison to editor line numbers), though.

Cheers,

Onno
8< 8< 8< 8< 8< 8< 8< 8< 8<
Subject: [PATCH] Show number of commits being rebased interactively

During 'rebase -i', one wrong edit in a long rebase session might
inadvertently drop commits. This change shows the total number of
commits in the comments below the commit list. After the rebase
edit, the number can be quickly compared to the line number of
the last commit - by scrolling to the last entry in the rebase
TODO list. This gives peace of mind that no commits have been
lost in the edit.

Signed-off-by: Onno Kortmann 
---
 git-rebase--interactive.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index b64dd28..b26e5e6 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1031,9 +1031,13 @@ test -s "$todo" || echo noop >> "$todo"
 test -n "$autosquash" && rearrange_squash "$todo"
 test -n "$cmd" && add_exec_commands "$todo"

+commitcount=$(git stripspace --strip-comments <"$todo"  | \
+ sane_grep "^pick " | \
+ wc -l)
+
 cat >>"$todo" <>"$todo" <<\EOF
-- 
2.2.0.rc0.18.g1c09766


--
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] fsck: properly bound "invalid tag name" error message

[Jeff King]

When we detect an invalid tag-name header in a tag object,
like, "tag foo bar\n", we feed the pointer starting at "foo
bar" to a printf "%s" formatter. This shows the name, as we
want, but then it keeps printing the rest of the tag buffer,
rather than stopping at the end of the line.

Our tests did not notice because they look only for the
matching line, but the bug is that we print much more than
we wanted to. So we also adjust the test to be more exact.

Note that when fscking tags with "index-pack --strict", this
is even worse. index-pack does not add a trailing
NUL-terminator after the object, so we may actually read
past the buffer and print uninitialized memory. Running
t5302 with valgrind does notice the bug for that reason.

Signed-off-by: Jeff King 
---
I'm generally nervous about adding too-specific stderr wording or
formatting to our tests, as I do not want them to be brittle. But I do
not actually think this is substantially different than what other fsck
tests do (i.e., they are already grepping for _half_ the wording
already, so if it changes, they are likely to break, too).

If we care, the test can check test_line_count or similar to make sure
there isn't extra data. But I think the way I have written it below is a
lot easier for a reader coming later to understand what is going on.

 fsck.c  | 3 ++-
 t/t1450-fsck.sh | 8 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/fsck.c b/fsck.c
index 2fffa43..88c92e8 100644
--- a/fsck.c
+++ b/fsck.c
@@ -423,7 +423,8 @@ static int fsck_tag_buffer(struct tag *tag, const char 
*data,
}
strbuf_addf(&sb, "refs/tags/%.*s", (int)(eol - buffer), buffer);
if (check_refname_format(sb.buf, 0))
-   error_func(&tag->object, FSCK_WARN, "invalid 'tag' name: %s", 
buffer);
+   error_func(&tag->object, FSCK_WARN, "invalid 'tag' name: %.*s",
+  (int)(eol - buffer), buffer);
buffer = eol + 1;
 
if (!skip_prefix(buffer, "tagger ", &buffer))
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 019fddd..57ccce5 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -229,8 +229,12 @@ test_expect_success 'tag with incorrect tag name & missing 
tagger' '
echo $tag >.git/refs/tags/wrong &&
test_when_finished "git update-ref -d refs/tags/wrong" &&
git fsck --tags 2>out &&
-   grep "invalid .tag. name" out &&
-   grep "expected .tagger. line" out
+
+   cat >expect <<-EOF &&
+   warning in tag $tag: invalid '\''tag'\'' name: wrong name format
+   warning in tag $tag: invalid format - expected '\''tagger'\'' line
+   EOF
+   test_cmp expect out
 '
 
 test_expect_success 'tag with bad tagger' '
-- 
2.2.0.390.gf60752d
--
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] fsck: properly bound "invalid tag name" error message

[Jeff King]

On Mon, Dec 08, 2014 at 12:48:12AM -0500, Jeff King wrote:

> Note that when fscking tags with "index-pack --strict", this
> is even worse. index-pack does not add a trailing
> NUL-terminator after the object, so we may actually read
> past the buffer and print uninitialized memory. Running
> t5302 with valgrind does notice the bug for that reason.

This merits an additional note (but fortunately not a patch :) ).

After writing the above, I thought for a moment that we might actually
read past the end of the buffer in some cases, but I convinced myself
otherwise. And I think Dscho and I might have even had this conversation
off-list a while ago, but I think it is worth pointing out so that
nobody else has to dig into it.

For the most part, we are fine because we parse the object
left-to-right, and barf as soon as we see something unusual (and for
this reason, fsck_commit_buffer is also fine). The two suspicious places
are:

  1. We call strchr(buffer, '\n'), which looks like it could read
 unbounded when "buffer" is not NUL-terminated. However, early in
 the function we confirm that it contains "\n\n", and we will not
 have parsed past that here. Therefore we know that we will always
 hit a newline.

  2. After finding and parsing a line whose trailing newline is marked
 by "eol", we then set "buffer = eol + 1". This would be wrong if
 eol is at the very end of the buffer (the next step would then
 start reading uninitialized memory).

 But again we are saved by the "\n\n" check. The strchr will always
 find the first, so we know that we have at least one character
 after it (and that character is a newline, which cannot be the
 start of a new header, which will cause us to stop parsing).

I do admit that I am tempted to teach index-pack to always NUL-terminate
objects in memory that we feed to fsck, just to be on the safe side. It
doesn't cost much, and could prevent a silly mistake (either in the
future, or one that I missed in my analysis). The fsck code otherwise
generally expects to get the output of read_sha1_file, which has the
safety-NUL appended.

-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

Antw: Re: Enhancement Request: "locale" git option

[Ulrich Windl]

>>> Ralf Thielow  schrieb am 04.12.2014 um 20:02 in
Nachricht
:
> Hi Ulrich,
> 
> 2014-12-04 8:32 GMT+01:00 Ulrich Windl :
>> Hi!
>>
>> I'm native German, but German git messages confuse me (yopu'll have to 
> correlate them with the man pages). At the moment git uses the
> 
> What in particular makes the German git messages confusing you? What
> `git version` do you use?
> Maybe we can find something to improve in the translation.

The problem is (as others found out already) that all documentation I have use 
english Git messages, and lots of documentation is in English.

You could compare it to C++ (for example): If you read the language reference 
in English, you can only be confused by German compiler messages, and if you 
have a German book on C++, the phrases the book uses are quite likely not the 
ones the compiler uses...

Back to Git: Assuming (pure Science Fiction) that you participate in several 
projects using Git: One from a French maintainer expects that Git messages are 
in French, one Project uses English, another Project uses German... The a 
per-project locale setting would make sense (despite of the fact that I believe 
that every international project should use English for communication (just 
because it's a kind of "industry standard", not giving any personal preference).

Regards,
Ulrich

> 
> Thanks,
> 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] t: support clang/gcc AddressSanitizer

[Jeff King]

When git is compiled with "-fsanitize=address" (using clang
or gcc >= 4.8), all invocations of git will check for buffer
overflows. This is similar to running with valgrind, except
that it is more thorough (because of the compiler support,
function-local buffers can be checked, too) and runs much
faster (making it much less painful to run the whole test
suite with the checks turned on).

Unlike valgrind, the magic happens at compile-time, so we
don't need the same infrastructure in the test suite that we
did to support --valgrind. But there are two things we can
help with:

  1. On some platforms, the leak-detector is on by default,
 and causes every invocation of "git init" (and thus
 every test script) to fail. Since running git with
 the leak detector is pointless, let's shut it off
 automatically in the tests, unless the user has already
 configured it.

  2. When apache runs a CGI, it clears the environment of
 unknown variables. This means that the $ASAN_OPTIONS
 config doesn't make it to git-http-backend, and it
 dies due to the leak detector. Let's mark the variable
 as OK for apache to pass.

With these two changes, running

make CC=clang CFLAGS=-fsanitize=address test

works out of the box.

Signed-off-by: Jeff King 
---
This is actually how I found the fsck bug I posted a few hours ago, but
I followed up with "./t5032-* --valgrind-only=32" because valgrind seems
to produce better output.

We could get fancier with $ASAN_OPTIONS, like appending "detect_leaks=0"
if it is already set. But I figured that people who are setting
$ASAN_OPTIONS already know what they are doing, and they can deal with
configuring the leak detector themselves.

We could also provide a "make sanitize-test" target, but given how
simple the make command above is, I don't see much point.

 t/lib-httpd/apache.conf | 1 +
 t/test-lib.sh   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 7713dd2..03a4c2e 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -69,6 +69,7 @@ LockFile accept.lock
 PassEnv GIT_VALGRIND
 PassEnv GIT_VALGRIND_OPTIONS
 PassEnv GNUPGHOME
+PassEnv ASAN_OPTIONS
 
 Alias /dumb/ www/
 Alias /auth/dumb/ www/auth/dumb/
diff --git a/t/test-lib.sh b/t/test-lib.sh
index cf19339..3177298 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -140,6 +140,9 @@ else
}
 fi
 
+: ${ASAN_OPTIONS=detect_leaks=0}
+export ASAN_OPTIONS
+
 # Protect ourselves from common misconfiguration to export
 # CDPATH into the environment
 unset CDPATH
-- 
2.2.0.390.gf60752d
--
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

Antw: Re: Enhancement Request: "locale" git option

[Ulrich Windl]

>>> Ralf Thielow  schrieb am 06.12.2014 um 20:28 in
Nachricht
:
> 2014-12-05 16:45 GMT+01:00 Torsten Bögershausen :
>>
>> I do not know who was first, and who came later, but
>> 
>
 chverfolgen>
>>
>> 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.

Isolated from usage, "versionieren" and "tracking" have no common translation;
what about "verfolgen" (~follow) for "tracking"?

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